draft-bryant-pwe3-packet-pw-00.txt to WG draft?

IMHO and FWIW the need for = asymmetric BW allocation stems from the fact that predominant client traffic today uses asymmetric BW.

So the requirement to support= asymmetric BW allocation in MPLS-TP is actually the requirement to accommo= date the predominant client traffic without unnecessary waste of resources.= The fact that MPLS, being a packet-based technology, is capable of doing that, means only that this requirement can= be met; and the desire to use available resources effectively is, AFAIK, a= major drive for switch packet-based transport.

At the same time I suspect th= at combining asymmetric BW allocation with co-routed bidirectional paths wi= ll result (again) in BW waste, since (physical) links used in transport net= works presumably are symmetrical (I have not heard yet about MPLS-TP being run over ADSL:-). Removing the &quo= t;co-routed" requirement provides a chance to improve BW utilization i= n the transport network.

The actual BW utilization gai= n may vary depending on actual client traffic distribution, so that the ope= rator will have to decide on a per-case bases whether it justifies dropping= some traditions and some (yet unspecified) advantages implied by these traditions.

Regards,

Sash= a

From:= BUSI ITALO [Italo.Busi@alcatel-lucent.it]
Sent: Thursday, April 16, 2009 5:57 PM
To: Alexander Vainshtein; Adrian Farrel
Cc: mpls-tp@ietf.org
Subject: RE: [mpls-tp] Associated bidirectional transport path requi= rements

Sasha,

transport networks support co-routed bid= irectional P2P as well as unidirectional P2P and P2MP paths.<= /div>

In line with this obeservation, MPLS-TP MUST = support co-routed bidirectional P2P transport paths as well as unidirection= al P2P and P2MP transport paths.

As MPLS-TP is not only a transport technology= but also a packet terchnology, asymmetric BW allocation is required for MP= LS-TP.

As a consequence, co-routed bidirectional P2P= transport paths MUST support asymmetric BW allocation as perfectly documen= ted in Req.37.

The key issue is that I do not see requiremen= ts for associated bidirectional P2P transport paths in MPLS-TP rather altho= ugh I see requirements for them only in traditional MPLS.

Italo

From: Alexander Vainshtein [mailto:= Alexander.Vainshtein@ecitele.com]
Sent: Thursday, April 16, 2009 12:02 PM
To: Adrian Farrel
Cc: BUSI@core3.amsl.com; BUSI ITALO; mpls-tp@ietf.org
Subject: RE: [mpls-tp] Associated bidirectional transport path requi= rements

Adrian,

My previous response to your message has been too long already while dea= ling only with one item in this message.

I'd like to add that I fully agree with what I perceive as the other key st= atement in your message:

<quote>
     Isn't that the case with 75% of the MPLS-TP requir= ements?

     ("That" standing for "Experience with exi= sting transport networks rather than any specific benefit")
     Which is not to say it is a bad thing.

     A large driver for MPLS-TP is to give the packet n= etwork the look, feel, and
     behavioral characteristics of a "legacy"= transport network
<end quote>

The only question here is, to what extent this experience and thes= e behavioral characteristics (which, to the best of my understanding, mainl= y have dealt with P2P co-routed bidirectional paths with symmetric BW alloc= ation) can advance the proclaimed MPLS-TP goals, which include:

Unidirectional P2MP paths
Bidirectional paths with asymmetric= BW allocation
Associated (not co-routed) bidirect= ional paths.

E.g., I suspect that the need for associated bidirectional paths may be = closely related to the need to support bidirectional paths with asymme= tric BW allocation...

My 2c,

     Sasha

________________________________________
From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein [Alexander.Vainshtein@ecitele.com]
Sent: Thursday, April 16, 2009 10:04 AM
To: Adrian Farrel
Cc: BUSI@core3.amsl.com; ITALO; mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements=

Adrian,
Thank you for a prompt and detailed response.

Unfortunately I cannot fully agree with your statement:

<quote>
     From the point of view of hardware, co-routed bidi= rectional LSPs
     are a special case of associated bidirectional LSP= s.
<end quote>

This statement would be obviously correct, were it not for Requirement 34 i= n the latest
MPLS-TP requirements draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.txt= ):

<quote>
      The intermediate nodes (including MEPs, MIPs= and other internal
       functions as appropriate) of a co-rout= ed bidirectional transport
       path at each (sub-)layer MUST be aware= of the pairing
       relationship of the forward and the ba= ckward directions of that
       transport path.
<end quote>

Please note that Requirement 34 is the ONLY item in the list that is specif= ic
for co-routed bidirectional LSPs. (The pairing requirements at end points for co-routed and associated bidirectional paths are exactly the same even<= br> if they appear in two different items in the requirements' list).
In other words, without Requirement 34 the notion of co-routed bidirectiona= l
paths would be void of any data plane content.

The somewhat vague scope of this requirement ("other internal function= s
as appropriate") creates a suspicion that HW support of the pairing aw= areness
may be required in order to comply with it.

The following text in the draft increases this suspicion:

<quote>
   Tandem Connection: A tandem connection is an arbitrary part of= a
   transport path that can be monitored (via OAM) independently f= rom the
   end-to-end monitoring (OAM). It may be a monitored segme= nt or a
   monitored concatenated segment of a transport path. The = tandem
   connection may also include the forwarding engine(s) of the no= de(s)
   at the edge(s) of the segment or concatenated segment.
<end quote>

Doesn't "forwarding engine" sound like hardware to you?

IMHO it is worth noting that neither the MPLS-TP Requirements draft
nor the MPLS-TP OAM requirements one
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01= .txt)
contain any requirements dealing with tandem connections.

But tandem connections are discussed in the MPLS-TP OAM Framework draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.tx= t).

The bottom line, IMHO, is that some clarity regarding co-routed vs. associa= ted bidirectional
paths is still required. One way to provide that could be by explicitly lim= iting Requirement 34
to specific functionality.

My 2c,
     Sasha

________________________________________
From: Adrian Farrel [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 12:13 AM
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements=

Hi Sasha,

Not really sure whether you are misrepresenting anyone, but...

> 1. My reading of one of Ben's messages is that associated<= br> > bidirectional paths are the only types of paths that can be
> created in the existing networks; "true" co-routed bidirecti= onal
> paths will have to wait until (if ever) new equipment becomes
> available.

This is clearly nonsense!
>From the point of view of hardware, co-routed bidirectional LSPs are a
special case of associated bidirectional LSPs.

If you can set up two unidirectional LSPs (e.g. using the management plane)=
you can surely set up a co-routed bidirectional LSP.

There are shipping solutions that achieve co-routed bidirectional LSPs usin= g
the control plane. These either use the GMPLS (which is cleaner) or
non-standard proprietary solutions (which is messy but functional).

But (of course) the management plane or control plane solutions have nothin= g
to do with availability of equipment as they are software solutions.

> 2. My reading of one of Neil's messages is that the actual driver for<= br> > co-routed
> bidirectional paths may be experience with existing transport networks=
> rather
> than any specific benefit.

Isn't that the case with 75% of the MPLS-TP requirements?
Which is not to say it is a bad thing.

A large driver for MPLS-TP is to give the packet network the look, feel, an= d
behavioral characteristics of a "legacy" transport network.

> Based on these observations, I'd guess (FWIW) that:
> * associated bidirectional paths are, at least for the time
>    being, the most important type of bidirectional path= s in
>    MPLS-TP

I think that is wrong both given my statement above, and given that other upgrades to existing MPLS solutions will be needed to reach the full
function level of MPLS-TP.

> * they had a good chance to remain the only type of bidirectional
>   paths in real deployments.

I don't see what that follows from.

Cheers,
Adrian
_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

--_000_A3C5DF08D38B6049839A6F553B331C76A8CEED909FILPTMAIL02eci_-- From benjamin.niven-jenkins@bt.com Thu Apr 16 09:52:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCFA3A6E22 for ; Thu, 16 Apr 2009 09:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olpKMjgrnBZR for ; Thu, 16 Apr 2009 09:52:30 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 339F73A69D7 for ; Thu, 16 Apr 2009 09:52:29 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 17:53:41 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Apr 2009 16:53:41 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 16 Apr 2009 17:53:39 +0100 From: Ben Niven-Jenkins To: Alexander Vainshtein , Adrian Farrel Message-ID: Thread-Topic: Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rft In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Apr 2009 16:53:41.0947 (UTC) FILETIME=[E5BB98B0:01C9BEB3] Cc: BUSI ITALO , "mpls-tp@ietf.org" Subject: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:52:31 -0000 On 16/04/2009 12:39, "Alexander Vainshtein" > I fully support your proposal to get rid (in a consistent manner) from the TC > stuff in MPLS-TP, especially since, to the best of my knowledge, operational > experience with SONET/SDH TCM (ITU-T definitions notwithstanding) did not > prove its worth. If this is based on mis-perception, I would be glad to hear > that (especially from the operators on this list). BT has no requirement for TCM. We do not have it deployed in our TDM networks today and have no current plans to use it in any of our networks in the future. Ben From Alexander.Vainshtein@ecitele.com Thu Apr 16 09:55:36 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD883A6DBC for ; Thu, 16 Apr 2009 09:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyAGTYOsxVVn for ; Thu, 16 Apr 2009 09:55:33 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 54C3E3A69D7 for ; Thu, 16 Apr 2009 09:55:32 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 16 Apr 2009 20:02:09 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 19:56:44 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 16 Apr 2009 19:56:43 +0300 From: Alexander Vainshtein To: Maarten Vissers Date: Thu, 16 Apr 2009 19:56:43 +0300 Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmY= Message-ID: References: <5403F90D2C87494EA46E4EB3370FC1C1@your029b8cecfe>, <007601c9be8e$497c82e0$6570ca0a@china.huawei.com> In-Reply-To: <007601c9be8e$497c82e0$6570ca0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A0ILPTMAIL02eci_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2009 16:56:44.0092 (UTC) FILETIME=[524CB7C0:01C9BEB4] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:55:36 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A0ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten, It seems that you've just (implicitly and, probably, inadvertently) stated = the following: MPLS-TP OAM will not ever support MIP loopback function (and fault localiza= tion which requires this function ) for unidirectional P2MP and P2P paths. If this statement is correct, this (IMHO and FWIW) raises a valid question: Is MPLS-TP an appropriate solution for these types of transport paths? For the reference, IP/MPLS provides this kind of functionality today for (u= nidirectional - but it does not know any other type) P2P LSPs as described= in RFC 4379. And its extension to P2MP LSPs seems easy... Regards, Sasha ________________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maar= ten Vissers [maarten.vissers@huawei.com] Sent: Thursday, April 16, 2009 3:24 PM To: 'Adrian Farrel' Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Adrian, >> >> The intermediate nodes (including MEPs, MIPs and other internal >> functions as appropriate) of a co-routed bidirectional transport >> path at each (sub-)layer MUST be aware of the pairing >> relationship of the forward and the backward directions of that >> transport path. >> > > There is no way this is a functional requirement. That is, there is > *nothing* that can be observed from a black box point of view that > results from adhering to this requirement. Your understanding is not correct. It is very much observable if this requirement is met from a black box point of view. The MIP functions can only perform the Loopback when there is a co-routed bidirectional transport path. The MPLS-TP LBM packet received at a MIP needs to be returned (as LBR packet) to the originating MEP function via the other direction of the co-routed bidirectional transport path. This other direction would not be available in an associated bidirectional transport path... and thus the loopback test would fail. Similarly, when we have to apply TCM MEPs to monitor a segment, then this i= s possible in a co-routed bidir transport path but not in a associated bidir transport path. In the first case the TCM MEP Source and Sink functions are co-located and can exchange what is called "remote information" which is necessary for performance monitoring. In the latter case the TCM MEP Source and Sink functions are in e.g. different nodes in the network and TCM would not be able to provide performance monitoring. > The entirety of the bracketted text "(including MEPs, MIPs and other internal > functions as appropriate)" should be deleted. It does not add to "The > intermediate nodes." Your understanding is not correct. This text must not be deleted at all. > Actually, I am quite fed up about this persistent insistence on the inclusion > of "Tandem Connection." The definition within the ITU-T of this term is poorly > specified and comes from the monitoring of a path that is parallel (i.e. tandem) > to the data path being monitored. This definition of TC seems to be at variance, > and would be if the ACH was actually in band. I don't understand where your interpretation of tandem connection is described in ITU-T recommendations. I.e. "from the monitoring of a path tha= t is parallel (i.e. tandem) to the data path being monitored."? There is a "network connection" and this network connection is a set of interconnected "link connections" and "matrix connections". A subset of those interconnected link connections and matrix connections can be monitored and is then referred to as a "tandem connection". There is no "path that is parallel to the data path". There is only additional OAM inserted inside the data path by the TCM MEP_So function and this OAM is extracted from the data path by the TCM MEP_Sk function. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: donderdag 16 april 2009 11:59 To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com Cc: BUSI ITALO; mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Hi Sasha, > Unfortunately I cannot fully agree with your statement: > > > From the point of view of hardware, co-routed bidirectional LSPs > are a special case of associated bidirectional LSPs. > > > This statement would be obviously correct, were it not for Requirement > 34 in the latest MPLS-TP requirements draft OK. Got it. But what is this doing in the data plane requirements section? In fact, what is this requirement actually saying? > > The intermediate nodes (including MEPs, MIPs and other internal > functions as appropriate) of a co-routed bidirectional transport > path at each (sub-)layer MUST be aware of the pairing > relationship of the forward and the backward directions of that > transport path. > There is no way this is a functional requirement. That is, there is *nothing* that can be observed from a black box point of view that results from adhering to this requirement. Therefore it could be assumed that this requirement is met by configuring some data plane database component through the management plane. The database component is not used for anything except to satisfy this requirement for "awareness". Ben! Can we please try to rewrite this requirement in terms of behavior? > Please note that Requirement 34 is the ONLY item in the list that is > specific for co-routed bidirectional LSPs. (The pairing requirements > at end points for co-routed and associated bidirectional paths are > exactly the same even if they appear in two different items in the > requirements' list). > In other words, without Requirement 34 the notion of co-routed > bidirectional paths would be void of any data plane content. > > The somewhat vague scope of this requirement ("other internal > functions as appropriate") creates a suspicion that HW support of the > pairing awareness may be required in order to comply with it. The entirety of the bracketted text "(including MEPs, MIPs and other internal functions as appropriate)" should be deleted. It does not add to "The intermediate nodes." > The following text in the draft increases this suspicion: > > > Tandem Connection: A tandem connection is an arbitrary part of a > transport path that can be monitored (via OAM) independently from the > end-to-end monitoring (OAM). It may be a monitored segment or a > monitored concatenated segment of a transport path. The tandem > connection may also include the forwarding engine(s) of the node(s) > at the edge(s) of the segment or concatenated segment. > Actually, I am quite fed up about this persistent insistence on the inclusion of "Tandem Connection." The definition within the ITU-T of this term is poorly specified and comes from the monitoring of a path that is parallel (i.e. tandem) to the data path being monitored. This definition of TC seems to be at variance, and would be if the ACH was actually in band. > Doesn't "forwarding engine" sound like hardware to you? Yes, but so what? > IMHO it is worth noting that neither the MPLS-TP Requirements draft > nor the MPLS-TP OAM requirements one > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > ts-01.txt) contain any requirements dealing with tandem connections. > > But tandem connections are discussed in the MPLS-TP OAM Framework > draft (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.tx= t ). Right. Let's just get rid of an unnecessary term and bring all the I-Ds into line. > The bottom line, IMHO, is that some clarity regarding co-routed vs. > associated > bidirectional paths is still required. One way to provide that could > be by explicitly limiting Requirement 34 to specific functionality. Agreed. Adrian ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Thursday, April 16, 2009 12:13 AM To: Alexander Vainshtein; Lou Berger; BUSI ITALO Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Hi Sasha, Not really sure whether you are misrepresenting anyone, but... > 1. My reading of one of Ben's messages is that associated > bidirectional paths are the only types of paths that can be created in > the existing networks; "true" co-routed bidirectional paths will have > to wait until (if ever) new equipment becomes available. This is clearly nonsense! >From the point of view of hardware, co-routed bidirectional LSPs are a special case of associated bidirectional LSPs. If you can set up two unidirectional LSPs (e.g. using the management plane) you can surely set up a co-routed bidirectional LSP. There are shipping solutions that achieve co-routed bidirectional LSPs usin= g the control plane. These either use the GMPLS (which is cleaner) or non-standard proprietary solutions (which is messy but functional). But (of course) the management plane or control plane solutions have nothin= g to do with availability of equipment as they are software solutions. > 2. My reading of one of Neil's messages is that the actual driver for > co-routed bidirectional paths may be experience with existing > transport networks rather than any specific benefit. Isn't that the case with 75% of the MPLS-TP requirements? Which is not to say it is a bad thing. A large driver for MPLS-TP is to give the packet network the look, feel, an= d behavioral characteristics of a "legacy" transport network. > Based on these observations, I'd guess (FWIW) that: > * associated bidirectional paths are, at least for the time > being, the most important type of bidirectional paths in > MPLS-TP I think that is wrong both given my statement above, and given that other upgrades to existing MPLS solutions will be needed to reach the full function level of MPLS-TP. > * they had a good chance to remain the only type of bidirectional > paths in real deployments. I don't see what that follows from. Cheers, Adrian _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A0ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maarten,
It seems that you've just (implicitly and, probably, inadvertently) stated = the following:

MPLS-TP OAM will not ever support MIP lo= opback function (and fault localization which requires this functi= on ) for unidirectional P2MP and P2P paths.

If this sta= tement is correct, this (IMHO and FWIW) raises a valid question:

Is = MPLS-TP an appropriate solution for these types of transport paths?

For the ref= erence, IP/MPLS provides this kind of functionality today for (unidirection= al - but it does not know any other type) P2P LSPs  as described = in RFC 4379. And its extension to P2MP LSPs seems easy...

&nbs= p;

Regards,

  = ;   Sasha

________________________________________
From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maar= ten Vissers [maarten.vissers@huawei.com]
Sent: Thursday, April 16, 2009 3:24 PM
To: 'Adrian Farrel'
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements=

Adrian,

>> <quote>
>>      The intermediate nodes (including ME= Ps, MIPs and other internal
>>       functions as appropriate) of a= co-routed bidirectional transport
>>       path at each (sub-)layer MUST = be aware of the pairing
>>       relationship of the forward an= d the backward directions of that
>>       transport path.
>> <end quote>
>
> There is no way this is a functional requirement. That is, there is > *nothing* that can be observed from a black box point of view that
> results from adhering to this requirement.

Your understanding is not correct. It is very much observable if this
requirement is met from a black box point of view. The MIP functions can only perform the Loopback when there is a co-routed bidirectional transport=
path. The MPLS-TP LBM packet received at a MIP needs to be returned (as LBR=
packet) to the originating MEP function via the other direction of the
co-routed bidirectional transport path. This other direction would not be available in an associated bidirectional transport path... and thus the
loopback test would fail.

Similarly, when we have to apply TCM MEPs to monitor a segment, then this i= s
possible in a co-routed bidir transport path but not in a associated bidir<= br> transport path. In the first case the TCM MEP Source and Sink functions are=
co-located and can exchange what is called "remote information" w= hich is
necessary for performance monitoring. In the latter case the TCM MEP Source=
and Sink functions are in e.g. different nodes in the network and TCM would=
not be able to provide performance monitoring.

> The entirety of the bracketted text "(including MEPs, MIPs and ot= her
internal
> functions as appropriate)" should be deleted. It does not add to = "The
> intermediate nodes."

Your understanding is not correct. This text must not be deleted at all.
> Actually, I am quite fed up about this persistent insistence on the inclusion
> of "Tandem Connection." The definition within the ITU-T of t= his term is
poorly
> specified and comes from the monitoring of a path that is parallel (i.= e.
tandem)
> to the data path being monitored. This definition of TC seems to be at=
variance,
> and would be if the ACH was actually in band.

I don't understand where your interpretation of tandem connection is
described in ITU-T recommendations. I.e. "from the monitoring of a pat= h that
is parallel (i.e. tandem) to the data path being monitored."?

There is a "network connection" and this network connection is a = set of
interconnected "link connections" and "matrix connections&qu= ot;. A subset of
those interconnected link connections and matrix connections can be
monitored and is then referred to as a "tandem connection". There= is no
"path that is parallel to the data path". There is only additiona= l OAM
inserted inside the data path by the TCM MEP_So function and this OAM is extracted from the data path by the TCM MEP_Sk function.

Regards,
Maarten

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf<= br> Of Adrian Farrel
Sent: donderdag 16 april 2009 11:59
To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com
Cc: BUSI ITALO; mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements=

Hi Sasha,

> Unfortunately I cannot fully agree with your statement:
>
> <quote>
>     From the point of view of hardware, co-routed = bidirectional LSPs
>     are a special case of associated bidirectional= LSPs.
> <end quote>
>
> This statement would be obviously correct, were it not for Requirement=
> 34 in the latest MPLS-TP requirements draft

OK. Got it.

But what is this doing in the data plane requirements section?

In fact, what is this requirement actually saying?

> <quote>
>      The intermediate nodes (including MEPs, = MIPs and other internal
>       functions as appropriate) of a co-= routed bidirectional transport
>       path at each (sub-)layer MUST be a= ware of the pairing
>       relationship of the forward and th= e backward directions of that
>       transport path.
> <end quote>

There is no way this is a functional requirement. That is, there is
*nothing* that can be observed from a black box point of view that results<= br> from adhering to this requirement.

Therefore it could be assumed that this requirement is met by configuring some data plane database component through the management plane. The
database component is not used for anything except to satisfy this
requirement for "awareness".

Ben! Can we please try to rewrite this requirement in terms of behavior?
> Please note that Requirement 34 is the ONLY item in the list that is > specific for co-routed bidirectional LSPs. (The pairing requirements > at end points for co-routed and associated bidirectional paths are
> exactly the same even if they appear in two different items in the
> requirements' list).
> In other words, without Requirement 34 the notion of co-routed
> bidirectional paths would be void of any data plane content.
>
> The somewhat vague scope of this requirement ("other internal
> functions as appropriate") creates a suspicion that HW support of= the
> pairing awareness may be required in order to comply with it.

The entirety of the bracketted text "(including MEPs, MIPs and other internal functions as appropriate)" should be deleted. It does not add= to
"The intermediate nodes."

> The following text in the draft increases this suspicion:
>
> <quote>
>   Tandem Connection: A tandem connection is an arbitrary par= t of a
>   transport path that can be monitored (via OAM) independent= ly from the
>   end-to-end monitoring (OAM). It may be a monitored s= egment or a
>   monitored concatenated segment of a transport path. = The tandem
>   connection may also include the forwarding engine(s) of th= e node(s)
>   at the edge(s) of the segment or concatenated segment.
> <end quote>

Actually, I am quite fed up about this persistent insistence on the
inclusion of "Tandem Connection." The definition within the ITU-T= of this
term is poorly specified and comes from the monitoring of a path that is parallel (i.e. tandem) to the data path being monitored. This definition of=
TC seems to be at variance, and would be if the ACH was actually in band.
> Doesn't "forwarding engine" sound like hardware to you?

Yes, but so what?

> IMHO it is worth noting that neither the MPLS-TP Requirements draft > nor the MPLS-TP OAM requirements one
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen=
> ts-01.txt) contain any requirements dealing with tandem connections. >
> But tandem connections are discussed in the MPLS-TP OAM Framework
> draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.tx= t
).

Right.
Let's just get rid of an unnecessary term and bring all the I-Ds into line.=

> The bottom line, IMHO, is that some clarity regarding co-routed vs. > associated
> bidirectional paths is still required. One way to provide that could > be by explicitly limiting Requirement 34 to specific functionality.
Agreed.

Adrian

________________________________________
From: Adrian Farrel [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 12:13 AM
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements=

Hi Sasha,

Not really sure whether you are misrepresenting anyone, but...

> 1. My reading of one of Ben's messages is that associated<= br> > bidirectional paths are the only types of paths that can be created in=
> the existing networks; "true" co-routed bidirectional paths = will have
> to wait until (if ever) new equipment becomes available.

This is clearly nonsense!
>From the point of view of hardware, co-routed bidirectional LSPs are a
special case of associated bidirectional LSPs.

If you can set up two unidirectional LSPs (e.g. using the management plane)=
you can surely set up a co-routed bidirectional LSP.

There are shipping solutions that achieve co-routed bidirectional LSPs usin= g
the control plane. These either use the GMPLS (which is cleaner) or
non-standard proprietary solutions (which is messy but functional).

But (of course) the management plane or control plane solutions have nothin= g
to do with availability of equipment as they are software solutions.

> 2. My reading of one of Neil's messages is that the actual driver for<= br> > co-routed bidirectional paths may be experience with existing
> transport networks rather than any specific benefit.

Isn't that the case with 75% of the MPLS-TP requirements?
Which is not to say it is a bad thing.

A large driver for MPLS-TP is to give the packet network the look, feel, an= d
behavioral characteristics of a "legacy" transport network.

> Based on these observations, I'd guess (FWIW) that:
> * associated bidirectional paths are, at least for the time
>    being, the most important type of bidirectional path= s in
>    MPLS-TP

I think that is wrong both given my statement above, and given that other upgrades to existing MPLS solutions will be needed to reach the full
function level of MPLS-TP.

> * they had a good chance to remain the only type of bidirectional
>   paths in real deployments.

I don't see what that follows from.

Cheers,
Adrian

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp
--_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A0ILPTMAIL02eci_-- From benjamin.niven-jenkins@bt.com Thu Apr 16 09:57:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F003A6D81 for ; Thu, 16 Apr 2009 09:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MVkkDr81jLl for ; Thu, 16 Apr 2009 09:57:44 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id E8FDC3A6BC6 for ; Thu, 16 Apr 2009 09:57:43 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 17:58:56 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Apr 2009 16:58:55 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 16 Apr 2009 17:58:47 +0100 From: Ben Niven-Jenkins To: Adrian Farrel , Maarten Vissers Message-ID: Thread-Topic: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] Thread-Index: Acm+tJuOTknZdff0ik2hm8OGNyx6+g== In-Reply-To: <8E1BB972CF3B4CAD83881CAD192D6BD8@your029b8cecfe> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Apr 2009 16:58:56.0299 (UTC) FILETIME=[A119E7B0:01C9BEB4] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:57:45 -0000 Adrian, On 16/04/2009 13:48, "Adrian Farrel" wrote: > The original text reads... > > The intermediate nodes (including MEPs, MIPs and other internal > functions as appropriate) of a co-routed bidirectional transport > path > > Since MEPs, MIPs and other internal functions are just examples of > intermediate nodes, the sentence loses nothing if it reads > > The intermediate nodes of a co-routed bidirectional transport > path > > Furthermore, *any* text that reaches me as AD including "as appropriate" is > highly likely to be turned around. If the authors do not know what they mean > and have used the phrase to avoid working it out, then it needs to be fixed. > If the authors do know what they mean, they should say it. "as appropriate" is because I wrote the text of the requirement based on asks for it to be a requirement from others and I didn't entirely know what was being asked for so I took an educated guess. What I was trying to do was highlight some of the functions in a node that may make use of such information to try and add clarity as to how it may be used. I have no problem removing the text if it doesn't add that clarity and just leave as "The intermediate nodes of a co-routed..." If other participants want the text kept then they need to propose alternative text that is acceptable to our ADs as the current text is the best I can come up with on my own. Ben From benjamin.niven-jenkins@bt.com Thu Apr 16 10:05:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7C328C254 for ; Thu, 16 Apr 2009 10:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Db1w+mFSwq3 for ; Thu, 16 Apr 2009 10:05:19 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 4E43F28C24C for ; Thu, 16 Apr 2009 10:05:18 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 18:06:31 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Apr 2009 17:06:30 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 16 Apr 2009 18:06:28 +0100 From: Ben Niven-Jenkins To: Alexander Vainshtein , BUSI ITALO Message-ID: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+Dw6DXAlhaXrxRx+qdHqMTeGOlwAS3BVxAAc1NjEACuC60AADI6ywAAGSQxQ= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Apr 2009 17:06:31.0150 (UTC) FILETIME=[B036A8E0:01C9BEB5] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:05:20 -0000 Colleagues, On 16/04/2009 17:41, "Alexander Vainshtein" wrote: > Italo, > > IMHO and FWIW the need for asymmetric BW allocation stems from the fact that > predominant client traffic today uses asymmetric BW. Let's close this one on asymmetric bandwidth requirement. It is a requirement because a large Tier 1 US operator publicly stated on this list they had a requirement for it. You can debate its use and applicability to death when it comes to defining solutions. For the requirements draft, it is a real operator requirement and that's all we need to worry about at this time unless anyone feels the text of the requirement is not clear. Ben P.S. Sasha, although I replied to your mail my comment is not directed specifically at you. From nurit.sprecher@nsn.com Thu Apr 16 10:24:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BD63A6E9B for ; Thu, 16 Apr 2009 10:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnPNHUVQZBaP for ; Thu, 16 Apr 2009 10:24:10 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 402A13A6DD2 for ; Thu, 16 Apr 2009 10:24:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3GHPB6u001338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 19:25:11 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3GHPAj8021015; Thu, 16 Apr 2009 19:25:11 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 19:25:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 19:25:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3A= References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Ben Niven-Jenkins" , "Alexander Vainshtein" , "Adrian Farrel" X-OriginalArrivalTime: 16 Apr 2009 17:25:10.0821 (UTC) FILETIME=[4B96E550:01C9BEB8] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:24:11 -0000 Hi, TC is a solution to the requirement to manage, monitor and protect the network at different nested levels. The work on MPLS-TP started with this basic requirement that came from the ITU-T.=20 I think we should continue and address this requirement as our commitment to the ITU-T.=20 About the solution, there is room for discussion. Is it TC, PST or something else? As promised I'll provide next week some text about this. Best regards, Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins Sent: Thursday, April 16, 2009 7:54 PM To: Alexander Vainshtein; Adrian Farrel Cc: BUSI ITALO; mpls-tp@ietf.org Subject: [mpls-tp] Requirement for TCM or not. On 16/04/2009 12:39, "Alexander Vainshtein" > I fully support your proposal to get rid (in a consistent manner) from the TC > stuff in MPLS-TP, especially since, to the best of my knowledge, operational > experience with SONET/SDH TCM (ITU-T definitions notwithstanding) did not > prove its worth. If this is based on mis-perception, I would be glad to hear > that (especially from the operators on this list). BT has no requirement for TCM. We do not have it deployed in our TDM networks today and have no current plans to use it in any of our networks in the future. Ben _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From John.E.Drake2@boeing.com Thu Apr 16 10:34:24 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE85828C252 for ; Thu, 16 Apr 2009 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQkPkODKtYz5 for ; Thu, 16 Apr 2009 10:34:24 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id ED2E028C0F3 for ; Thu, 16 Apr 2009 10:34:23 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3GHVcSv022157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 10:31:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3GHVcDg003551; Thu, 16 Apr 2009 12:31:38 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3GHVZ0w003449; Thu, 16 Apr 2009 12:31:38 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 10:31:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 10:31:36 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BADD@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Asymmetric Bandwidth LSPs was RE: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+Dw6DXAlhaXrxRx+qdHqMTeGOlwAS3BVxAAc1NjEACuC60AADI6ywAAJQYiA= References: <001901c9bc0a$dc6fd060$6802a8c0@china.huawei.com><6FD21B53861BF44AA90A288402036AB402145621@FRVELSMBS21.ad2.ad.alcatel.com>, <49E5EEC8.6080101@labn.net>, <0872841F306444EE8655C6AF6983AF32@your029b8cecfe>, , <6FD21B53861BF44AA90A288402036AB4021B170F@FRVELSMBS21.ad2.ad.alcatel.com> From: "Drake, John E" To: "Alexander Vainshtein" , "BUSI ITALO" X-OriginalArrivalTime: 16 Apr 2009 17:31:37.0338 (UTC) FILETIME=[31F8B5A0:01C9BEB9] Cc: mpls-tp@ietf.org Subject: [mpls-tp] Asymmetric Bandwidth LSPs was RE: Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:34:24 -0000 Snipped...=20 >=20 > At the same time I suspect that combining asymmetric BW=20 > allocation with co-routed bidirectional paths will result=20 > (again) in BW waste, since (physical) links used in transport=20 > networks presumably are symmetrical (I have not heard yet=20 > about MPLS-TP being run over ADSL:-). Removing the=20 > "co-routed" requirement provides a chance to improve BW=20 > utilization in the transport network. JD: That's not necessarily the case. There can be many asymmetric BW bi-directional LSPs placed on a given link and it's unlikely that the fat and skinny directions of each will line up. From John.E.Drake2@boeing.com Thu Apr 16 10:51:06 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A74D3A6BBA for ; Thu, 16 Apr 2009 10:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.734 X-Spam-Level: X-Spam-Status: No, score=-5.734 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUrUyMH2NZVY for ; Thu, 16 Apr 2009 10:51:04 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id D4D083A6B3D for ; Thu, 16 Apr 2009 10:50:38 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3GHmGet002684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 10:48:17 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3GHmGQO006078; Thu, 16 Apr 2009 12:48:16 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3GHmFVK006042; Thu, 16 Apr 2009 12:48:16 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 10:48:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 10:48:14 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BB09@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAAePz4A== References: <5403F90D2C87494EA46E4EB3370FC1C1@your029b8cecfe>, <007601c9be8e$497c82e0$6570ca0a@china.huawei.com> From: "Drake, John E" To: "Alexander Vainshtein" , "Maarten Vissers" X-OriginalArrivalTime: 16 Apr 2009 17:48:15.0755 (UTC) FILETIME=[85130DB0:01C9BEBB] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:51:06 -0000 http://www.ietf.org/internet-drafts/draft-ietf-mpls-remote-lsp-ping-03.t xt=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 > Sent: Thursday, April 16, 2009 9:57 AM > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Maarten, > It seems that you've just (implicitly and, probably,=20 > inadvertently) stated the following: >=20 > MPLS-TP OAM will not ever support MIP loopback function=20 > (and fault localization which requires this function ) for=20 > unidirectional P2MP and P2P paths. >=20 > If this statement is correct, this (IMHO and FWIW) raises a=20 > valid question:=20 >=20 > Is MPLS-TP an appropriate solution for these types of=20 > transport paths? >=20 > For the reference, IP/MPLS provides this kind of=20 > functionality today for (unidirectional - but it does not=20 > know any other type) P2P LSPs as described in RFC 4379. And=20 > its extension to P2MP LSPs seems easy... JD: See http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-07=20 and=20 http://www.ietf.org/internet-drafts/draft-ietf-mpls-remote-lsp-ping-03.t xt At the meeting last fall at Juniper in Massachusetts, I think it was agreed that an MPLS TP network needs to have a forwarding capability for management, control, and OAM packets (e.g., sending replies to OAM requests sent on uni-directional LSPs) even if it does not have an IP forwarding data plane.=20 >=20 > =20 >=20 > Regards, >=20 > Sasha >=20 >=20 >=20 > ________________________________________ > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On=20 > Behalf Of Maarten Vissers [maarten.vissers@huawei.com] > Sent: Thursday, April 16, 2009 3:24 PM > To: 'Adrian Farrel' > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Adrian, >=20 > >> > >> The intermediate nodes (including MEPs, MIPs and=20 > other internal > >> functions as appropriate) of a co-routed=20 > bidirectional transport > >> path at each (sub-)layer MUST be aware of the pairing > >> relationship of the forward and the backward=20 > directions of that > >> transport path. > >> > > > > There is no way this is a functional requirement. That is, there is > > *nothing* that can be observed from a black box point of view that=20 > > results from adhering to this requirement. >=20 > Your understanding is not correct. It is very much observable=20 > if this requirement is met from a black box point of view.=20 > The MIP functions can only perform the Loopback when there is=20 > a co-routed bidirectional transport path. The MPLS-TP LBM=20 > packet received at a MIP needs to be returned (as LBR > packet) to the originating MEP function via the other=20 > direction of the co-routed bidirectional transport path. This=20 > other direction would not be available in an associated=20 > bidirectional transport path... and thus the loopback test would fail. >=20 > Similarly, when we have to apply TCM MEPs to monitor a=20 > segment, then this is possible in a co-routed bidir transport=20 > path but not in a associated bidir transport path. In the=20 > first case the TCM MEP Source and Sink functions are=20 > co-located and can exchange what is called "remote=20 > information" which is necessary for performance monitoring.=20 > In the latter case the TCM MEP Source and Sink functions are=20 > in e.g. different nodes in the network and TCM would not be=20 > able to provide performance monitoring. >=20 > > The entirety of the bracketted text "(including MEPs, MIPs and other > internal > > functions as appropriate)" should be deleted. It does not=20 > add to "The=20 > > intermediate nodes." >=20 > Your understanding is not correct. This text must not be=20 > deleted at all. >=20 > > Actually, I am quite fed up about this persistent insistence on the > inclusion > > of "Tandem Connection." The definition within the ITU-T of=20 > this term=20 > > is > poorly > > specified and comes from the monitoring of a path that is=20 > parallel (i.e. > tandem) > > to the data path being monitored. This definition of TC=20 > seems to be at > variance, > > and would be if the ACH was actually in band. >=20 > I don't understand where your interpretation of tandem=20 > connection is described in ITU-T recommendations. I.e. "from=20 > the monitoring of a path that is parallel (i.e. tandem) to=20 > the data path being monitored."? >=20 > There is a "network connection" and this network connection=20 > is a set of interconnected "link connections" and "matrix=20 > connections". A subset of those interconnected link=20 > connections and matrix connections can be monitored and is=20 > then referred to as a "tandem connection". There is no "path=20 > that is parallel to the data path". There is only additional=20 > OAM inserted inside the data path by the TCM MEP_So function=20 > and this OAM is extracted from the data path by the TCM=20 > MEP_Sk function. >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: donderdag 16 april 2009 11:59 > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Hi Sasha, >=20 > > Unfortunately I cannot fully agree with your statement: > > > > > > From the point of view of hardware, co-routed bidirectional LSPs > > are a special case of associated bidirectional LSPs. > > > > > > This statement would be obviously correct, were it not for=20 > Requirement > > 34 in the latest MPLS-TP requirements draft >=20 > OK. Got it. >=20 > But what is this doing in the data plane requirements section? >=20 > In fact, what is this requirement actually saying? >=20 > > > > The intermediate nodes (including MEPs, MIPs and other internal > > functions as appropriate) of a co-routed=20 > bidirectional transport > > path at each (sub-)layer MUST be aware of the pairing > > relationship of the forward and the backward=20 > directions of that > > transport path. > > >=20 > There is no way this is a functional requirement. That is, there is > *nothing* that can be observed from a black box point of view=20 > that results from adhering to this requirement. >=20 > Therefore it could be assumed that this requirement is met by=20 > configuring some data plane database component through the=20 > management plane. The database component is not used for=20 > anything except to satisfy this requirement for "awareness". >=20 > Ben! Can we please try to rewrite this requirement in terms=20 > of behavior? >=20 > > Please note that Requirement 34 is the ONLY item in the=20 > list that is=20 > > specific for co-routed bidirectional LSPs. (The pairing=20 > requirements=20 > > at end points for co-routed and associated bidirectional paths are=20 > > exactly the same even if they appear in two different items in the=20 > > requirements' list). > > In other words, without Requirement 34 the notion of co-routed=20 > > bidirectional paths would be void of any data plane content. > > > > The somewhat vague scope of this requirement ("other internal=20 > > functions as appropriate") creates a suspicion that HW=20 > support of the=20 > > pairing awareness may be required in order to comply with it. >=20 > The entirety of the bracketted text "(including MEPs, MIPs=20 > and other internal functions as appropriate)" should be=20 > deleted. It does not add to "The intermediate nodes." >=20 > > The following text in the draft increases this suspicion: > > > > > > Tandem Connection: A tandem connection is an arbitrary part of a > > transport path that can be monitored (via OAM)=20 > independently from the > > end-to-end monitoring (OAM). It may be a monitored segment or a > > monitored concatenated segment of a transport path. The tandem > > connection may also include the forwarding engine(s) of=20 > the node(s) > > at the edge(s) of the segment or concatenated segment. > > >=20 > Actually, I am quite fed up about this persistent insistence=20 > on the inclusion of "Tandem Connection." The definition=20 > within the ITU-T of this term is poorly specified and comes=20 > from the monitoring of a path that is parallel (i.e. tandem)=20 > to the data path being monitored. This definition of TC seems=20 > to be at variance, and would be if the ACH was actually in band. >=20 > > Doesn't "forwarding engine" sound like hardware to you? >=20 > Yes, but so what? >=20 > > IMHO it is worth noting that neither the MPLS-TP Requirements draft=20 > > nor the MPLS-TP OAM requirements one=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > ts-01.txt) contain any requirements dealing with tandem connections. > > > > But tandem connections are discussed in the MPLS-TP OAM Framework=20 > > draft > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > amework-00.txt > ). >=20 > Right. > Let's just get rid of an unnecessary term and bring all the=20 > I-Ds into line. >=20 > > The bottom line, IMHO, is that some clarity regarding co-routed vs. > > associated > > bidirectional paths is still required. One way to provide=20 > that could=20 > > be by explicitly limiting Requirement 34 to specific functionality. >=20 > Agreed. >=20 > Adrian >=20 >=20 >=20 >=20 > ________________________________________ > From: Adrian Farrel [adrian@olddog.co.uk] > Sent: Thursday, April 16, 2009 12:13 AM > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Hi Sasha, >=20 > Not really sure whether you are misrepresenting anyone, but... >=20 > > 1. My reading of one of Ben's messages is that associated=20 > > bidirectional paths are the only types of paths that can be=20 > created in=20 > > the existing networks; "true" co-routed bidirectional paths=20 > will have=20 > > to wait until (if ever) new equipment becomes available. >=20 > This is clearly nonsense! > From the point of view of hardware, co-routed bidirectional=20 > LSPs are a special case of associated bidirectional LSPs. >=20 > If you can set up two unidirectional LSPs (e.g. using the=20 > management plane) you can surely set up a co-routed bidirectional LSP. >=20 > There are shipping solutions that achieve co-routed=20 > bidirectional LSPs using the control plane. These either use=20 > the GMPLS (which is cleaner) or non-standard proprietary=20 > solutions (which is messy but functional). >=20 > But (of course) the management plane or control plane=20 > solutions have nothing to do with availability of equipment=20 > as they are software solutions. >=20 > > 2. My reading of one of Neil's messages is that the actual=20 > driver for=20 > > co-routed bidirectional paths may be experience with existing=20 > > transport networks rather than any specific benefit. >=20 > Isn't that the case with 75% of the MPLS-TP requirements? > Which is not to say it is a bad thing. >=20 > A large driver for MPLS-TP is to give the packet network the=20 > look, feel, and behavioral characteristics of a "legacy"=20 > transport network. >=20 > > Based on these observations, I'd guess (FWIW) that: > > * associated bidirectional paths are, at least for the time > > being, the most important type of bidirectional paths in > > MPLS-TP >=20 > I think that is wrong both given my statement above, and=20 > given that other upgrades to existing MPLS solutions will be=20 > needed to reach the full function level of MPLS-TP. >=20 > > * they had a good chance to remain the only type of bidirectional > > paths in real deployments. >=20 > I don't see what that follows from. >=20 > Cheers, > Adrian >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 From John.E.Drake2@boeing.com Thu Apr 16 10:57:15 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108193A67AF for ; Thu, 16 Apr 2009 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJyX6uu7foPx for ; Thu, 16 Apr 2009 10:57:14 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id CD7F23A6801 for ; Thu, 16 Apr 2009 10:57:10 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3GHsf8r024177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 12:54:41 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3GHsf3k020084; Thu, 16 Apr 2009 12:54:41 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3GHseLp020074; Thu, 16 Apr 2009 12:54:41 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 10:54:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 10:54:39 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BB14@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAAAhgIA== References: <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> From: "Drake, John E" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Ben Niven-Jenkins" , "Alexander Vainshtein" , "Adrian Farrel" X-OriginalArrivalTime: 16 Apr 2009 17:54:40.0490 (UTC) FILETIME=[6A64F4A0:01C9BEBC] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:57:15 -0000 Nurit, As I recall, there is a 1:1 relationship between a TCM instance and the LSP it is monitoring. I thought we had agreed (a long time ago) to generalize this into a 1:N capability, and hence TCM became PST. Thanks, John=20 > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > [mailto:nurit.sprecher@nsn.com]=20 > Sent: Thursday, April 16, 2009 10:25 AM > To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Requirement for TCM or not. >=20 > Hi, > TC is a solution to the requirement to manage, monitor and=20 > protect the network at different nested levels. > The work on MPLS-TP started with this basic requirement that=20 > came from the ITU-T.=20 > I think we should continue and address this requirement as=20 > our commitment to the ITU-T.=20 > About the solution, there is room for discussion. Is it TC,=20 > PST or something else? As promised I'll provide next week=20 > some text about this. >=20 > Best regards, > Nurit >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins > Sent: Thursday, April 16, 2009 7:54 PM > To: Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: [mpls-tp] Requirement for TCM or not. >=20 > On 16/04/2009 12:39, "Alexander Vainshtein" > > I fully support your proposal to get rid (in a consistent=20 > manner) from > the TC > > stuff in MPLS-TP, especially since, to the best of my knowledge, > operational > > experience with SONET/SDH TCM (ITU-T definitions=20 > notwithstanding) did > not > > prove its worth. If this is based on mis-perception, I would be glad > to hear > > that (especially from the operators on this list). >=20 > BT has no requirement for TCM. We do not have it deployed in=20 > our TDM networks today and have no current plans to use it in=20 > any of our networks in the future. >=20 > Ben >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From John.E.Drake2@boeing.com Thu Apr 16 11:02:22 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6C33A696C for ; Thu, 16 Apr 2009 11:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRZ+2UXgTVOL for ; Thu, 16 Apr 2009 11:02:21 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 280AF3A6929 for ; Thu, 16 Apr 2009 11:02:21 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3GHxqds027257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Apr 2009 10:59:54 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3GHxquP001022; Thu, 16 Apr 2009 12:59:52 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3GHxoi0000948; Thu, 16 Apr 2009 12:59:52 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 10:59:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 10:59:50 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BB1D@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kA== References: <5403F90D2C87494EA46E4EB3370FC1C1@your029b8cecfe>, <007601c9be8e$497c82e0$6570ca0a@china.huawei.com> From: "Drake, John E" To: "Alexander Vainshtein" , "Maarten Vissers" X-OriginalArrivalTime: 16 Apr 2009 17:59:52.0027 (UTC) FILETIME=[2415BAB0:01C9BEBD] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:02:22 -0000 At the meeting last fall at Juniper in Massachusetts, I think it was agreed that an MPLS TP network needs to have a forwarding capability for management, control, and OAM packets (e.g., sending replies to OAM requests sent on uni-directional LSPs) even if it does not have an IP forwarding data plane. =20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 > Sent: Thursday, April 16, 2009 9:57 AM > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Maarten, > It seems that you've just (implicitly and, probably,=20 > inadvertently) stated the following: >=20 > MPLS-TP OAM will not ever support MIP loopback function=20 > (and fault localization which requires this function ) for=20 > unidirectional P2MP and P2P paths. >=20 > If this statement is correct, this (IMHO and FWIW) raises a=20 > valid question:=20 >=20 > Is MPLS-TP an appropriate solution for these types of=20 > transport paths? >=20 > For the reference, IP/MPLS provides this kind of=20 > functionality today for (unidirectional - but it does not=20 > know any other type) P2P LSPs as described in RFC 4379. And=20 > its extension to P2MP LSPs seems easy... >=20 > =20 >=20 > Regards, >=20 > Sasha >=20 >=20 >=20 > ________________________________________ > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On=20 > Behalf Of Maarten Vissers [maarten.vissers@huawei.com] > Sent: Thursday, April 16, 2009 3:24 PM > To: 'Adrian Farrel' > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Adrian, >=20 > >> > >> The intermediate nodes (including MEPs, MIPs and=20 > other internal > >> functions as appropriate) of a co-routed=20 > bidirectional transport > >> path at each (sub-)layer MUST be aware of the pairing > >> relationship of the forward and the backward=20 > directions of that > >> transport path. > >> > > > > There is no way this is a functional requirement. That is, there is > > *nothing* that can be observed from a black box point of view that=20 > > results from adhering to this requirement. >=20 > Your understanding is not correct. It is very much observable=20 > if this requirement is met from a black box point of view.=20 > The MIP functions can only perform the Loopback when there is=20 > a co-routed bidirectional transport path. The MPLS-TP LBM=20 > packet received at a MIP needs to be returned (as LBR > packet) to the originating MEP function via the other=20 > direction of the co-routed bidirectional transport path. This=20 > other direction would not be available in an associated=20 > bidirectional transport path... and thus the loopback test would fail. >=20 > Similarly, when we have to apply TCM MEPs to monitor a=20 > segment, then this is possible in a co-routed bidir transport=20 > path but not in a associated bidir transport path. In the=20 > first case the TCM MEP Source and Sink functions are=20 > co-located and can exchange what is called "remote=20 > information" which is necessary for performance monitoring.=20 > In the latter case the TCM MEP Source and Sink functions are=20 > in e.g. different nodes in the network and TCM would not be=20 > able to provide performance monitoring. >=20 > > The entirety of the bracketted text "(including MEPs, MIPs and other > internal > > functions as appropriate)" should be deleted. It does not=20 > add to "The=20 > > intermediate nodes." >=20 > Your understanding is not correct. This text must not be=20 > deleted at all. >=20 > > Actually, I am quite fed up about this persistent insistence on the > inclusion > > of "Tandem Connection." The definition within the ITU-T of=20 > this term=20 > > is > poorly > > specified and comes from the monitoring of a path that is=20 > parallel (i.e. > tandem) > > to the data path being monitored. This definition of TC=20 > seems to be at > variance, > > and would be if the ACH was actually in band. >=20 > I don't understand where your interpretation of tandem=20 > connection is described in ITU-T recommendations. I.e. "from=20 > the monitoring of a path that is parallel (i.e. tandem) to=20 > the data path being monitored."? >=20 > There is a "network connection" and this network connection=20 > is a set of interconnected "link connections" and "matrix=20 > connections". A subset of those interconnected link=20 > connections and matrix connections can be monitored and is=20 > then referred to as a "tandem connection". There is no "path=20 > that is parallel to the data path". There is only additional=20 > OAM inserted inside the data path by the TCM MEP_So function=20 > and this OAM is extracted from the data path by the TCM=20 > MEP_Sk function. >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: donderdag 16 april 2009 11:59 > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Hi Sasha, >=20 > > Unfortunately I cannot fully agree with your statement: > > > > > > From the point of view of hardware, co-routed bidirectional LSPs > > are a special case of associated bidirectional LSPs. > > > > > > This statement would be obviously correct, were it not for=20 > Requirement > > 34 in the latest MPLS-TP requirements draft >=20 > OK. Got it. >=20 > But what is this doing in the data plane requirements section? >=20 > In fact, what is this requirement actually saying? >=20 > > > > The intermediate nodes (including MEPs, MIPs and other internal > > functions as appropriate) of a co-routed=20 > bidirectional transport > > path at each (sub-)layer MUST be aware of the pairing > > relationship of the forward and the backward=20 > directions of that > > transport path. > > >=20 > There is no way this is a functional requirement. That is, there is > *nothing* that can be observed from a black box point of view=20 > that results from adhering to this requirement. >=20 > Therefore it could be assumed that this requirement is met by=20 > configuring some data plane database component through the=20 > management plane. The database component is not used for=20 > anything except to satisfy this requirement for "awareness". >=20 > Ben! Can we please try to rewrite this requirement in terms=20 > of behavior? >=20 > > Please note that Requirement 34 is the ONLY item in the=20 > list that is=20 > > specific for co-routed bidirectional LSPs. (The pairing=20 > requirements=20 > > at end points for co-routed and associated bidirectional paths are=20 > > exactly the same even if they appear in two different items in the=20 > > requirements' list). > > In other words, without Requirement 34 the notion of co-routed=20 > > bidirectional paths would be void of any data plane content. > > > > The somewhat vague scope of this requirement ("other internal=20 > > functions as appropriate") creates a suspicion that HW=20 > support of the=20 > > pairing awareness may be required in order to comply with it. >=20 > The entirety of the bracketted text "(including MEPs, MIPs=20 > and other internal functions as appropriate)" should be=20 > deleted. It does not add to "The intermediate nodes." >=20 > > The following text in the draft increases this suspicion: > > > > > > Tandem Connection: A tandem connection is an arbitrary part of a > > transport path that can be monitored (via OAM)=20 > independently from the > > end-to-end monitoring (OAM). It may be a monitored segment or a > > monitored concatenated segment of a transport path. The tandem > > connection may also include the forwarding engine(s) of=20 > the node(s) > > at the edge(s) of the segment or concatenated segment. > > >=20 > Actually, I am quite fed up about this persistent insistence=20 > on the inclusion of "Tandem Connection." The definition=20 > within the ITU-T of this term is poorly specified and comes=20 > from the monitoring of a path that is parallel (i.e. tandem)=20 > to the data path being monitored. This definition of TC seems=20 > to be at variance, and would be if the ACH was actually in band. >=20 > > Doesn't "forwarding engine" sound like hardware to you? >=20 > Yes, but so what? >=20 > > IMHO it is worth noting that neither the MPLS-TP Requirements draft=20 > > nor the MPLS-TP OAM requirements one=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > ts-01.txt) contain any requirements dealing with tandem connections. > > > > But tandem connections are discussed in the MPLS-TP OAM Framework=20 > > draft > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > amework-00.txt > ). >=20 > Right. > Let's just get rid of an unnecessary term and bring all the=20 > I-Ds into line. >=20 > > The bottom line, IMHO, is that some clarity regarding co-routed vs. > > associated > > bidirectional paths is still required. One way to provide=20 > that could=20 > > be by explicitly limiting Requirement 34 to specific functionality. >=20 > Agreed. >=20 > Adrian >=20 >=20 >=20 >=20 > ________________________________________ > From: Adrian Farrel [adrian@olddog.co.uk] > Sent: Thursday, April 16, 2009 12:13 AM > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Hi Sasha, >=20 > Not really sure whether you are misrepresenting anyone, but... >=20 > > 1. My reading of one of Ben's messages is that associated=20 > > bidirectional paths are the only types of paths that can be=20 > created in=20 > > the existing networks; "true" co-routed bidirectional paths=20 > will have=20 > > to wait until (if ever) new equipment becomes available. >=20 > This is clearly nonsense! > From the point of view of hardware, co-routed bidirectional=20 > LSPs are a special case of associated bidirectional LSPs. >=20 > If you can set up two unidirectional LSPs (e.g. using the=20 > management plane) you can surely set up a co-routed bidirectional LSP. >=20 > There are shipping solutions that achieve co-routed=20 > bidirectional LSPs using the control plane. These either use=20 > the GMPLS (which is cleaner) or non-standard proprietary=20 > solutions (which is messy but functional). >=20 > But (of course) the management plane or control plane=20 > solutions have nothing to do with availability of equipment=20 > as they are software solutions. >=20 > > 2. My reading of one of Neil's messages is that the actual=20 > driver for=20 > > co-routed bidirectional paths may be experience with existing=20 > > transport networks rather than any specific benefit. >=20 > Isn't that the case with 75% of the MPLS-TP requirements? > Which is not to say it is a bad thing. >=20 > A large driver for MPLS-TP is to give the packet network the=20 > look, feel, and behavioral characteristics of a "legacy"=20 > transport network. >=20 > > Based on these observations, I'd guess (FWIW) that: > > * associated bidirectional paths are, at least for the time > > being, the most important type of bidirectional paths in > > MPLS-TP >=20 > I think that is wrong both given my statement above, and=20 > given that other upgrades to existing MPLS solutions will be=20 > needed to reach the full function level of MPLS-TP. >=20 > > * they had a good chance to remain the only type of bidirectional > > paths in real deployments. >=20 > I don't see what that follows from. >=20 > Cheers, > Adrian >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 From neil.2.harrison@bt.com Thu Apr 16 11:28:23 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4801E3A68B8 for ; Thu, 16 Apr 2009 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWSnXU-UpNFw for ; Thu, 16 Apr 2009 11:28:18 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 922623A682D for ; Thu, 16 Apr 2009 11:28:18 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 19:29:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 19:29:25 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FF9D8@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. thread-index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAIXJA= From: To: , , X-OriginalArrivalTime: 16 Apr 2009 18:29:30.0710 (UTC) FILETIME=[48433760:01C9BEC1] Cc: Italo.Busi@alcatel-lucent.it, mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:28:23 -0000 Ben wrote 16 April 2009 17:54 > To: Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: [mpls-tp] Requirement for TCM or not. >=20 > On 16/04/2009 12:39, "Alexander Vainshtein" > > I fully support your proposal to get rid (in a consistent=20 > manner) from the TC > > stuff in MPLS-TP, especially since, to the best of my=20 > knowledge, operational > > experience with SONET/SDH TCM (ITU-T definitions=20 > notwithstanding) did not > > prove its worth. If this is based on mis-perception, I=20 > would be glad to hear > > that (especially from the operators on this list). >=20 > BT has no requirement for TCM. We do not have it deployed in our TDM > networks today and have no current plans to use it in any of=20 > our networks in > the future. >=20 > Ben >=20 I could not agree more with Ben on this. I have, several times in the past and on various IETF/ITU lists, attempted to explain why we in BT hold this view. But to very briefly recap: - the intrinsic reliability of the network technology/equipment we expect our suppliers to provide us with should have a low intrinsic defect probability....and in such cases an OAM philosophy that is predicated on blanket configuration of multiple nested TCM levels is totally at odds with the *rare* defect cases where one needs to look *inside* an end-end *connection*. {Aside=3D> Here I would prefer we tap-off and end-end OAM flow on the *rare* occasions we need to.} I also highlight the word 'connection' here because the concept of TCM in a cl-ps mode network is ridiculous IMO....but if it's that great then please let us see it implemented in IPv4 and IPv6 first.....the fact this has never been seen necessary here speaks volumes to me. - the 'always-on' defect detection/handling OAM *must* be orders of magnitude more reliable than the *rare* defects we expect the network to create. So this 'always-on' type of OAM needs to be as sparse/simple as is possible. Configuration and processing of OAM also has a real cost. Moreover, having lots of configuration (read as 'TCM') is completely the wrong direction to be going in wrt improving reliability and reducing cost. - I have painstakingly explained in the past why network technologies that are not top-of-stack have no needs for UNIs/E-NNIs....let alone wasting ones time/money attempting peer-interworking between technologies that are not even the same network mode! Those promoting this FUD should be ashamed of themselves IMO as the technical justification is simply absent. However, the key point here is that nested TCM cannot be 'sold' on the basis of OAM being ascribed to different party partitions of a single layer network. - the only points that remain invariant across failure/recovery events are trail termination points (I am ignoring flow termination points of cl-ps mode networks like IP because I see no reason for TCM whatsoever here). This means any nested TCM levels will need reconfiguration across these events....unless one purposely creates 'pinch-points' and is thus is happy to compromise the potential availability performance of a layer network just so one can see the TCM working. regards, Neil From Alexander.Vainshtein@ecitele.com Thu Apr 16 12:29:06 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D4928C121 for ; Thu, 16 Apr 2009 12:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FizWh+Sqsjvu for ; Thu, 16 Apr 2009 12:29:05 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 6095C3A689B for ; Thu, 16 Apr 2009 12:29:04 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 16 Apr 2009 22:35:44 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 22:30:16 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 16 Apr 2009 22:30:16 +0300 From: Alexander Vainshtein To: "Drake, John E" Date: Thu, 16 Apr 2009 22:29:22 +0300 Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAAePz4AAD9l8d Message-ID: References: <5403F90D2C87494EA46E4EB3370FC1C1@your029b8cecfe>, <007601c9be8e$497c82e0$6570ca0a@china.huawei.com> , <51661468CBD1354294533DA79E85955A01A6BB09@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <51661468CBD1354294533DA79E85955A01A6BB09@XCH-SW-5V2.sw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2009 19:30:16.0531 (UTC) FILETIME=[C5575A30:01C9BEC9] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:29:07 -0000 John, Lots of thanks for pointing to the P2MP LSP Ping draft. I have been pretty = sure it exists but did not find it when responding to Maarten. Regards, Sasha ________________________________________ From: Drake, John E [John.E.Drake2@boeing.com] Sent: Thursday, April 16, 2009 8:48 PM To: Alexander Vainshtein; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements http://www.ietf.org/internet-drafts/draft-ietf-mpls-remote-lsp-ping-03.t xt > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 16, 2009 9:57 AM > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport > path requirements > > Maarten, > It seems that you've just (implicitly and, probably, > inadvertently) stated the following: > > MPLS-TP OAM will not ever support MIP loopback function > (and fault localization which requires this function ) for > unidirectional P2MP and P2P paths. > > If this statement is correct, this (IMHO and FWIW) raises a > valid question: > > Is MPLS-TP an appropriate solution for these types of > transport paths? > > For the reference, IP/MPLS provides this kind of > functionality today for (unidirectional - but it does not > know any other type) P2P LSPs as described in RFC 4379. And > its extension to P2MP LSPs seems easy... JD: See http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-07 and http://www.ietf.org/internet-drafts/draft-ietf-mpls-remote-lsp-ping-03.t xt At the meeting last fall at Juniper in Massachusetts, I think it was agreed that an MPLS TP network needs to have a forwarding capability for management, control, and OAM packets (e.g., sending replies to OAM requests sent on uni-directional LSPs) even if it does not have an IP forwarding data plane. > > > > Regards, > > Sasha > > > > ________________________________________ > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On > Behalf Of Maarten Vissers [maarten.vissers@huawei.com] > Sent: Thursday, April 16, 2009 3:24 PM > To: 'Adrian Farrel' > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport > path requirements > > Adrian, > > >> > >> The intermediate nodes (including MEPs, MIPs and > other internal > >> functions as appropriate) of a co-routed > bidirectional transport > >> path at each (sub-)layer MUST be aware of the pairing > >> relationship of the forward and the backward > directions of that > >> transport path. > >> > > > > There is no way this is a functional requirement. That is, there is > > *nothing* that can be observed from a black box point of view that > > results from adhering to this requirement. > > Your understanding is not correct. It is very much observable > if this requirement is met from a black box point of view. > The MIP functions can only perform the Loopback when there is > a co-routed bidirectional transport path. The MPLS-TP LBM > packet received at a MIP needs to be returned (as LBR > packet) to the originating MEP function via the other > direction of the co-routed bidirectional transport path. This > other direction would not be available in an associated > bidirectional transport path... and thus the loopback test would fail. > > Similarly, when we have to apply TCM MEPs to monitor a > segment, then this is possible in a co-routed bidir transport > path but not in a associated bidir transport path. In the > first case the TCM MEP Source and Sink functions are > co-located and can exchange what is called "remote > information" which is necessary for performance monitoring. > In the latter case the TCM MEP Source and Sink functions are > in e.g. different nodes in the network and TCM would not be > able to provide performance monitoring. > > > The entirety of the bracketted text "(including MEPs, MIPs and other > internal > > functions as appropriate)" should be deleted. It does not > add to "The > > intermediate nodes." > > Your understanding is not correct. This text must not be > deleted at all. > > > Actually, I am quite fed up about this persistent insistence on the > inclusion > > of "Tandem Connection." The definition within the ITU-T of > this term > > is > poorly > > specified and comes from the monitoring of a path that is > parallel (i.e. > tandem) > > to the data path being monitored. This definition of TC > seems to be at > variance, > > and would be if the ACH was actually in band. > > I don't understand where your interpretation of tandem > connection is described in ITU-T recommendations. I.e. "from > the monitoring of a path that is parallel (i.e. tandem) to > the data path being monitored."? > > There is a "network connection" and this network connection > is a set of interconnected "link connections" and "matrix > connections". A subset of those interconnected link > connections and matrix connections can be monitored and is > then referred to as a "tandem connection". There is no "path > that is parallel to the data path". There is only additional > OAM inserted inside the data path by the TCM MEP_So function > and this OAM is extracted from the data path by the TCM > MEP_Sk function. > > Regards, > Maarten > > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: donderdag 16 april 2009 11:59 > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport > path requirements > > Hi Sasha, > > > Unfortunately I cannot fully agree with your statement: > > > > > > From the point of view of hardware, co-routed bidirectional LSPs > > are a special case of associated bidirectional LSPs. > > > > > > This statement would be obviously correct, were it not for > Requirement > > 34 in the latest MPLS-TP requirements draft > > OK. Got it. > > But what is this doing in the data plane requirements section? > > In fact, what is this requirement actually saying? > > > > > The intermediate nodes (including MEPs, MIPs and other internal > > functions as appropriate) of a co-routed > bidirectional transport > > path at each (sub-)layer MUST be aware of the pairing > > relationship of the forward and the backward > directions of that > > transport path. > > > > There is no way this is a functional requirement. That is, there is > *nothing* that can be observed from a black box point of view > that results from adhering to this requirement. > > Therefore it could be assumed that this requirement is met by > configuring some data plane database component through the > management plane. The database component is not used for > anything except to satisfy this requirement for "awareness". > > Ben! Can we please try to rewrite this requirement in terms > of behavior? > > > Please note that Requirement 34 is the ONLY item in the > list that is > > specific for co-routed bidirectional LSPs. (The pairing > requirements > > at end points for co-routed and associated bidirectional paths are > > exactly the same even if they appear in two different items in the > > requirements' list). > > In other words, without Requirement 34 the notion of co-routed > > bidirectional paths would be void of any data plane content. > > > > The somewhat vague scope of this requirement ("other internal > > functions as appropriate") creates a suspicion that HW > support of the > > pairing awareness may be required in order to comply with it. > > The entirety of the bracketted text "(including MEPs, MIPs > and other internal functions as appropriate)" should be > deleted. It does not add to "The intermediate nodes." > > > The following text in the draft increases this suspicion: > > > > > > Tandem Connection: A tandem connection is an arbitrary part of a > > transport path that can be monitored (via OAM) > independently from the > > end-to-end monitoring (OAM). It may be a monitored segment or a > > monitored concatenated segment of a transport path. The tandem > > connection may also include the forwarding engine(s) of > the node(s) > > at the edge(s) of the segment or concatenated segment. > > > > Actually, I am quite fed up about this persistent insistence > on the inclusion of "Tandem Connection." The definition > within the ITU-T of this term is poorly specified and comes > from the monitoring of a path that is parallel (i.e. tandem) > to the data path being monitored. This definition of TC seems > to be at variance, and would be if the ACH was actually in band. > > > Doesn't "forwarding engine" sound like hardware to you? > > Yes, but so what? > > > IMHO it is worth noting that neither the MPLS-TP Requirements draft > > nor the MPLS-TP OAM requirements one > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > ts-01.txt) contain any requirements dealing with tandem connections. > > > > But tandem connections are discussed in the MPLS-TP OAM Framework > > draft > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > amework-00.txt > ). > > Right. > Let's just get rid of an unnecessary term and bring all the > I-Ds into line. > > > The bottom line, IMHO, is that some clarity regarding co-routed vs. > > associated > > bidirectional paths is still required. One way to provide > that could > > be by explicitly limiting Requirement 34 to specific functionality. > > Agreed. > > Adrian > > > > > ________________________________________ > From: Adrian Farrel [adrian@olddog.co.uk] > Sent: Thursday, April 16, 2009 12:13 AM > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport > path requirements > > Hi Sasha, > > Not really sure whether you are misrepresenting anyone, but... > > > 1. My reading of one of Ben's messages is that associated > > bidirectional paths are the only types of paths that can be > created in > > the existing networks; "true" co-routed bidirectional paths > will have > > to wait until (if ever) new equipment becomes available. > > This is clearly nonsense! > From the point of view of hardware, co-routed bidirectional > LSPs are a special case of associated bidirectional LSPs. > > If you can set up two unidirectional LSPs (e.g. using the > management plane) you can surely set up a co-routed bidirectional LSP. > > There are shipping solutions that achieve co-routed > bidirectional LSPs using the control plane. These either use > the GMPLS (which is cleaner) or non-standard proprietary > solutions (which is messy but functional). > > But (of course) the management plane or control plane > solutions have nothing to do with availability of equipment > as they are software solutions. > > > 2. My reading of one of Neil's messages is that the actual > driver for > > co-routed bidirectional paths may be experience with existing > > transport networks rather than any specific benefit. > > Isn't that the case with 75% of the MPLS-TP requirements? > Which is not to say it is a bad thing. > > A large driver for MPLS-TP is to give the packet network the > look, feel, and behavioral characteristics of a "legacy" > transport network. > > > Based on these observations, I'd guess (FWIW) that: > > * associated bidirectional paths are, at least for the time > > being, the most important type of bidirectional paths in > > MPLS-TP > > I think that is wrong both given my statement above, and > given that other upgrades to existing MPLS solutions will be > needed to reach the full function level of MPLS-TP. > > > * they had a good chance to remain the only type of bidirectional > > paths in real deployments. > > I don't see what that follows from. > > Cheers, > Adrian > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > >= From Alexander.Vainshtein@ecitele.com Thu Apr 16 12:41:06 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A21C3A6D3C for ; Thu, 16 Apr 2009 12:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTrKWIN0rJMB for ; Thu, 16 Apr 2009 12:41:05 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id CEE833A6F81 for ; Thu, 16 Apr 2009 12:40:59 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 16 Apr 2009 22:47:39 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 22:42:11 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 16 Apr 2009 22:42:11 +0300 From: Alexander Vainshtein To: "neil.2.harrison@bt.com" , "adrian@olddog.co.uk" Date: Thu, 16 Apr 2009 22:42:10 +0300 Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAIXJCAACPToQ== Message-ID: References: , <2ECAA42C79676B42AEBAC11229CA7D0C046FF9D8@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C046FF9D8@E03MVB2-UKBR.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: 16 Apr 2009 19:42:11.0393 (UTC) FILETIME=[6F6EA310:01C9BECB] Cc: "Italo.Busi@alcatel-lucent.it" , "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:41:06 -0000 Neil, Lots of thanks for clarifying your (and BT) position and the rationale behi= nd it. I'd like to note that so far I haven't heard any major transport operator a= ctively advocating=20 usage of TCM in the existing (SONET/SDH) transport networks. Or did I miss = something? Regards, Sasha ________________________________________ From: neil.2.harrison@bt.com [neil.2.harrison@bt.com] Sent: Thursday, April 16, 2009 9:29 PM To: benjamin.niven-jenkins@bt.com; Alexander Vainshtein; adrian@olddog.co.u= k Cc: Italo.Busi@alcatel-lucent.it; mpls-tp@ietf.org Subject: RE: [mpls-tp] Requirement for TCM or not. Ben wrote 16 April 2009 17:54 > To: Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: [mpls-tp] Requirement for TCM or not. > > On 16/04/2009 12:39, "Alexander Vainshtein" > > I fully support your proposal to get rid (in a consistent > manner) from the TC > > stuff in MPLS-TP, especially since, to the best of my > knowledge, operational > > experience with SONET/SDH TCM (ITU-T definitions > notwithstanding) did not > > prove its worth. If this is based on mis-perception, I > would be glad to hear > > that (especially from the operators on this list). > > BT has no requirement for TCM. We do not have it deployed in our TDM > networks today and have no current plans to use it in any of > our networks in > the future. > > Ben > I could not agree more with Ben on this. I have, several times in the past and on various IETF/ITU lists, attempted to explain why we in BT hold this view. But to very briefly recap: - the intrinsic reliability of the network technology/equipment we expect our suppliers to provide us with should have a low intrinsic defect probability....and in such cases an OAM philosophy that is predicated on blanket configuration of multiple nested TCM levels is totally at odds with the *rare* defect cases where one needs to look *inside* an end-end *connection*. {Aside=3D> Here I would prefer we tap-off and end-end OAM flow on the *rare* occasions we need to.} I also highlight the word 'connection' here because the concept of TCM in a cl-ps mode network is ridiculous IMO....but if it's that great then please let us see it implemented in IPv4 and IPv6 first.....the fact this has never been seen necessary here speaks volumes to me. - the 'always-on' defect detection/handling OAM *must* be orders of magnitude more reliable than the *rare* defects we expect the network to create. So this 'always-on' type of OAM needs to be as sparse/simple as is possible. Configuration and processing of OAM also has a real cost. Moreover, having lots of configuration (read as 'TCM') is completely the wrong direction to be going in wrt improving reliability and reducing cost. - I have painstakingly explained in the past why network technologies that are not top-of-stack have no needs for UNIs/E-NNIs....let alone wasting ones time/money attempting peer-interworking between technologies that are not even the same network mode! Those promoting this FUD should be ashamed of themselves IMO as the technical justification is simply absent. However, the key point here is that nested TCM cannot be 'sold' on the basis of OAM being ascribed to different party partitions of a single layer network. - the only points that remain invariant across failure/recovery events are trail termination points (I am ignoring flow termination points of cl-ps mode networks like IP because I see no reason for TCM whatsoever here). This means any nested TCM levels will need reconfiguration across these events....unless one purposely creates 'pinch-points' and is thus is happy to compromise the potential availability performance of a layer network just so one can see the TCM working. regards, Neil= From Alexander.Vainshtein@ecitele.com Thu Apr 16 12:47:51 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843043A6A4C for ; Thu, 16 Apr 2009 12:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVfQGz+WLEhN for ; Thu, 16 Apr 2009 12:47:50 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 4B59828C13A for ; Thu, 16 Apr 2009 12:47:50 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 16 Apr 2009 22:54:30 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 22:49:02 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 16 Apr 2009 22:49:02 +0300 From: Alexander Vainshtein To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Date: Thu, 16 Apr 2009 22:49:01 +0300 Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDQ== Message-ID: References: , <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.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: 16 Apr 2009 19:49:02.0310 (UTC) FILETIME=[645B9860:01C9BECC] Cc: BUSI ITALO , "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:47:51 -0000 Nurit hi, Two comments: 1. As I see it, the actual operational need to monitor network at different= nested levels is, at the very least, arguable (Neil explains this much better that I can ever can hope). 2. We should understand and agree upon the requirement first and then look = for the suitable solution, not the the other way round.=20 Regards, Sasha ________________________________________ From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [nurit.sprecher@nsn.com] Sent: Thursday, April 16, 2009 8:25 PM To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel Cc: BUSI ITALO; mpls-tp@ietf.org Subject: RE: [mpls-tp] Requirement for TCM or not. Hi, TC is a solution to the requirement to manage, monitor and protect the network at different nested levels. The work on MPLS-TP started with this basic requirement that came from the ITU-T. I think we should continue and address this requirement as our commitment to the ITU-T. About the solution, there is room for discussion. Is it TC, PST or something else? As promised I'll provide next week some text about this. Best regards, Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins Sent: Thursday, April 16, 2009 7:54 PM To: Alexander Vainshtein; Adrian Farrel Cc: BUSI ITALO; mpls-tp@ietf.org Subject: [mpls-tp] Requirement for TCM or not. On 16/04/2009 12:39, "Alexander Vainshtein" > I fully support your proposal to get rid (in a consistent manner) from the TC > stuff in MPLS-TP, especially since, to the best of my knowledge, operational > experience with SONET/SDH TCM (ITU-T definitions notwithstanding) did not > prove its worth. If this is based on mis-perception, I would be glad to hear > that (especially from the operators on this list). BT has no requirement for TCM. We do not have it deployed in our TDM networks today and have no current plans to use it in any of our networks in the future. Ben _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= From nurit.sprecher@nsn.com Thu Apr 16 13:05:06 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5134B3A6F84 for ; Thu, 16 Apr 2009 13:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=1.352, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsaX7wgrRWzE for ; Thu, 16 Apr 2009 13:05:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DC37B3A6F7B for ; Thu, 16 Apr 2009 13:05:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3GK679D018254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 22:06:07 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3GK66pO003400; Thu, 16 Apr 2009 22:06:06 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 22:06:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 16 Apr 2009 22:05:59 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326490D7B1@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQ References: , <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Alexander Vainshtein" X-OriginalArrivalTime: 16 Apr 2009 20:06:06.0199 (UTC) FILETIME=[C6A4A870:01C9BECE] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:05:06 -0000 Sasha, I absolutely agree with your second point. Regarding the first one, it was agreed that the MPLS-TP addresses the transport requirements of the ITU-T and additional requirements from SPs.=20 This was one of the first set of requirements the ITU-T brought to the work and we need to address it. Best regards, Nurit -----Original Message----- From: ext Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 16, 2009 10:49 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: BUSI ITALO; mpls-tp@ietf.org; ext Ben Niven-Jenkins; Adrian Farrel; neil.2.harrison@bt.com Subject: RE: [mpls-tp] Requirement for TCM or not. Nurit hi, Two comments: 1. As I see it, the actual operational need to monitor network at different nested levels is, at the very least, arguable (Neil explains this much better that I can ever can hope). 2. We should understand and agree upon the requirement first and then look for the suitable solution, not the the other way round.=20 Regards, Sasha ________________________________________ From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [nurit.sprecher@nsn.com] Sent: Thursday, April 16, 2009 8:25 PM To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel Cc: BUSI ITALO; mpls-tp@ietf.org Subject: RE: [mpls-tp] Requirement for TCM or not. Hi, TC is a solution to the requirement to manage, monitor and protect the network at different nested levels. The work on MPLS-TP started with this basic requirement that came from the ITU-T. I think we should continue and address this requirement as our commitment to the ITU-T. About the solution, there is room for discussion. Is it TC, PST or something else? As promised I'll provide next week some text about this. Best regards, Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins Sent: Thursday, April 16, 2009 7:54 PM To: Alexander Vainshtein; Adrian Farrel Cc: BUSI ITALO; mpls-tp@ietf.org Subject: [mpls-tp] Requirement for TCM or not. On 16/04/2009 12:39, "Alexander Vainshtein" > I fully support your proposal to get rid (in a consistent manner) from the TC > stuff in MPLS-TP, especially since, to the best of my knowledge, operational > experience with SONET/SDH TCM (ITU-T definitions notwithstanding) did not > prove its worth. If this is based on mis-perception, I would be glad to hear > that (especially from the operators on this list). BT has no requirement for TCM. We do not have it deployed in our TDM networks today and have no current plans to use it in any of our networks in the future. Ben _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From benjamin.niven-jenkins@bt.com Thu Apr 16 13:19:09 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A4E3A6BBA for ; Thu, 16 Apr 2009 13:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9x08Jr50rdd for ; Thu, 16 Apr 2009 13:19:08 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 951013A6B2F for ; Thu, 16 Apr 2009 13:19:08 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 21:20:21 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Apr 2009 20:20:20 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 16 Apr 2009 21:20:18 +0100 From: Ben Niven-Jenkins To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , ext Alexander Vainshtein Message-ID: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgAAEgtU= In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326490D7B1@DEMUEXC014.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Apr 2009 20:20:21.0262 (UTC) FILETIME=[C44CEAE0:01C9BED0] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:19:09 -0000 Colleagues, On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > Regarding the first one, it was agreed that the MPLS-TP addresses the > transport requirements of the ITU-T and additional requirements from > SPs. > This was one of the first set of requirements the ITU-T brought to the > work and we need to address it. This does raise a question in my mind that goes back to something I have said before. Is TCM a requirement because it is a real requirement that operators are asking for or because we are recreating SDH/SONET functionality blindly without considering its relevance in the world we now live in? I appreciate that there are many operators who do not participate in standards, however it would be most useful if just one operator who requires TCM were to step forward and say so. I am not a TDM expert but what my TDM experts tell me is that TCM has been deployed in the past by some operators (I have no idea of its current state of deployment except in BT) but that its use in the past can be considered (in their opinion) to be in the minority of deployments. I do wonder if we are therefore expending a lot of energy (and later on time both in standardisation and possibly development effort) for a function that may be seldom, if ever, used. It won't be the first time we have standardised something that is seldom, if ever, used but we do have an opportunity now to take a step back and consider: is TCM really required and if it is required, is it a priority in the development of MPLS-TP? Ben From John.E.Drake2@boeing.com Thu Apr 16 13:36:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ACA93A6D9C for ; Thu, 16 Apr 2009 13:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iBhKYMLkUyn for ; Thu, 16 Apr 2009 13:36:11 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 5D8423A6F17 for ; Thu, 16 Apr 2009 13:36:11 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3GKbBCv029497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 13:37:11 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3GKbBO5009751; Thu, 16 Apr 2009 13:37:11 -0700 (PDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3GKbBAp009740; Thu, 16 Apr 2009 13:37:11 -0700 (PDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 13:37:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 13:37:08 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BBDB@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectionaltransport path requirements] Thread-Index: Acm+tJuOTknZdff0ik2hm8OGNyx6+gAHkfng References: <8E1BB972CF3B4CAD83881CAD192D6BD8@your029b8cecfe> From: "Drake, John E" To: "Ben Niven-Jenkins" , "Adrian Farrel" , "Maarten Vissers" X-OriginalArrivalTime: 16 Apr 2009 20:37:10.0799 (UTC) FILETIME=[1E0809F0:01C9BED3] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectionaltransport path requirements] X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:36:12 -0000 Why don't we use 'and lots of other important technical stuff' instead?=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Thursday, April 16, 2009 9:59 AM > To: Adrian Farrel; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated=20 > bidirectionaltransport path requirements] >=20 > Adrian, >=20 > On 16/04/2009 13:48, "Adrian Farrel" wrote: > > The original text reads... > >=20 > > The intermediate nodes (including MEPs, MIPs and=20 > other internal > > functions as appropriate) of a co-routed=20 > bidirectional transport > > path > >=20 > > Since MEPs, MIPs and other internal functions are just examples of=20 > > intermediate nodes, the sentence loses nothing if it reads > >=20 > > The intermediate nodes of a co-routed bidirectional transport > > path > >=20 > > Furthermore, *any* text that reaches me as AD including "as=20 > > appropriate" is highly likely to be turned around. If the=20 > authors do=20 > > not know what they mean and have used the phrase to avoid=20 > working it out, then it needs to be fixed. > > If the authors do know what they mean, they should say it. >=20 > "as appropriate" is because I wrote the text of the=20 > requirement based on asks for it to be a requirement from=20 > others and I didn't entirely know what was being asked for so=20 > I took an educated guess. >=20 > What I was trying to do was highlight some of the functions=20 > in a node that may make use of such information to try and=20 > add clarity as to how it may be used. I have no problem=20 > removing the text if it doesn't add that clarity and just=20 > leave as "The intermediate nodes of a co-routed..." >=20 > If other participants want the text kept then they need to=20 > propose alternative text that is acceptable to our ADs as the=20 > current text is the best I can come up with on my own. >=20 > Ben >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From hshah@ciena.com Thu Apr 16 13:39:55 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1771B3A6F31 for ; Thu, 16 Apr 2009 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0l+VZnOIca6 for ; Thu, 16 Apr 2009 13:39:54 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id D23CA3A6F41 for ; Thu, 16 Apr 2009 13:39:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_335629_01C9BEB2.24438270" Date: Thu, 16 Apr 2009 16:41:04 -0400 Message-ID: <6535C9CED6F87446B41D20EF170F23623161F0@mamxm01.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Importance: normal Priority: normal thread-index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgAAEgtWAAARmIw== References: From: "Shah, Himanshu" To: "Ben Niven-Jenkins" , "Sprecher, Nurit ¥(NSN - IL/Hod HaSharon¥)" , "ext Alexander Vainshtein" X-OriginalArrivalTime: 16 Apr 2009 20:41:07.0582 (UTC) FILETIME=[AB2A41E0:01C9BED3] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:39:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_335629_01C9BEB2.24438270 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BED3.A99D7B2E" ------_=_NextPart_001_01C9BED3.A99D7B2E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If I am not mistaken, this is the third iteration of the discussion cycle on this subject matter (each with different heading). As they say, third time is a charm. seriously though, I agree. Lets put this behind us if=20 there is no 'real' requirement for it. /himanshu -----Original Message----- From: mpls-tp-bounces@ietf.org on behalf of Ben Niven-Jenkins Sent: Thu 4/16/2009 4:20 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein Cc: BUSI ITALO; mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. =20 Colleagues, On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > Regarding the first one, it was agreed that the MPLS-TP addresses the > transport requirements of the ITU-T and additional requirements from > SPs.=20 > This was one of the first set of requirements the ITU-T brought to the > work and we need to address it. This does raise a question in my mind that goes back to something I have said before. Is TCM a requirement because it is a real requirement that operators are asking for or because we are recreating SDH/SONET functionality blindly without considering its relevance in the world we = now live in? I appreciate that there are many operators who do not participate in standards, however it would be most useful if just one operator who = requires TCM were to step forward and say so. I am not a TDM expert but what my TDM experts tell me is that TCM has = been deployed in the past by some operators (I have no idea of its current = state of deployment except in BT) but that its use in the past can be = considered (in their opinion) to be in the minority of deployments. I do wonder if we are therefore expending a lot of energy (and later on = time both in standardisation and possibly development effort) for a function = that may be seldom, if ever, used. It won't be the first time we have standardised something that is seldom, if ever, used but we do have an opportunity now to take a step back and consider: is TCM really required = and if it is required, is it a priority in the development of MPLS-TP? Ben _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ------_=_NextPart_001_01C9BED3.A99D7B2E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [mpls-tp] Requirement for TCM or not.
If I am not mistaken, this is the third iteration of = the
discussion cycle on this subject matter (each with
different heading). As they say, third time is a charm.

seriously though, I agree. Lets put this behind us if
there is no 'real' requirement for it.

/himanshu

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

From: mpls-tp-bounces@ietf.org on behalf of Ben Niven-Jenkins
Sent: Thu 4/16/2009 4:20 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander = Vainshtein
Cc: BUSI ITALO; mpls-tp@ietf.org
Subject: Re: [mpls-tp] Requirement for TCM or not.

Colleagues,

On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod = HaSharon)"
> Regarding the first one, it was agreed that the MPLS-TP addresses = the
> transport requirements of the ITU-T and additional requirements = from
> SPs.
> This was one of the first set of requirements the ITU-T brought to = the
> work and we need to address it.

This does raise a question in my mind that goes back to something I = have
said before. Is TCM a requirement because it is a real requirement = that
operators are asking for or because we are recreating SDH/SONET
functionality blindly without considering its relevance in the world we = now
live in?

I appreciate that there are many operators who do not participate in
standards, however it would be most useful if just one operator who = requires
TCM were to step forward and say so.

I am not a TDM expert but what my TDM experts tell me is that TCM has = been
deployed in the past by some operators (I have no idea of its current = state
of deployment except in BT) but that its use in the past can be = considered
(in their opinion) to be in the minority of deployments.

I do wonder if we are therefore expending a lot of energy (and later on = time
both in standardisation and possibly development effort) for a function = that
may be seldom, if ever, used. It won't be the first time we have
standardised something that is seldom, if ever, used but we do have = an
opportunity now to take a step back and consider: is TCM really required = and
if it is required, is it a priority in the development of MPLS-TP?

Ben

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mpls-tp

------_=_NextPart_001_01C9BED3.A99D7B2E-- ------=_NextPart_000_335629_01C9BEB2.24438270 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------=_NextPart_000_335629_01C9BEB2.24438270-- From John.E.Drake2@boeing.com Thu Apr 16 13:49:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C8D3A6B4A for ; Thu, 16 Apr 2009 13:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYuALaCj7keU for ; Thu, 16 Apr 2009 13:49:13 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 170553A6BDA for ; Thu, 16 Apr 2009 13:49:13 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3GKkcw2018058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 13:46:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3GKkc8N010680; Thu, 16 Apr 2009 15:46:38 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3GKkb7P010660; Thu, 16 Apr 2009 15:46:37 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 13:46:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 13:46:35 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BBE9@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <6535C9CED6F87446B41D20EF170F23623161F0@mamxm01.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgAAEgtWAAARmI4AAAu3w References: <6535C9CED6F87446B41D20EF170F23623161F0@mamxm01.ciena.com> From: "Drake, John E" To: "Shah, Himanshu" , "Ben Niven-Jenkins" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Alexander Vainshtein" X-OriginalArrivalTime: 16 Apr 2009 20:46:37.0139 (UTC) FILETIME=[6F98AA30:01C9BED4] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:49:14 -0000 +1=20 > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com]=20 > Sent: Thursday, April 16, 2009 1:41 PM > To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod=20 > HaSharon); ext Alexander Vainshtein > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Requirement for TCM or not. >=20 > If I am not mistaken, this is the third iteration of the=20 > discussion cycle on this subject matter (each with different=20 > heading). As they say, third time is a charm. >=20 > seriously though, I agree. Lets put this behind us if there=20 > is no 'real' requirement for it. >=20 > /himanshu >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- >=20 >=20 > From: mpls-tp-bounces@ietf.org on behalf of Ben Niven-Jenkins > Sent: Thu 4/16/2009 4:20 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Requirement for TCM or not. >=20 > Colleagues, >=20 > On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > Regarding the first one, it was agreed that the MPLS-TP=20 > addresses the=20 > > transport requirements of the ITU-T and additional=20 > requirements from=20 > > SPs. > > This was one of the first set of requirements the ITU-T=20 > brought to the=20 > > work and we need to address it. >=20 > This does raise a question in my mind that goes back to=20 > something I have said before. Is TCM a requirement because it=20 > is a real requirement that operators are asking for or=20 > because we are recreating SDH/SONET functionality blindly=20 > without considering its relevance in the world we now live in? >=20 > I appreciate that there are many operators who do not=20 > participate in standards, however it would be most useful if=20 > just one operator who requires TCM were to step forward and say so. >=20 > I am not a TDM expert but what my TDM experts tell me is that=20 > TCM has been deployed in the past by some operators (I have=20 > no idea of its current state of deployment except in BT) but=20 > that its use in the past can be considered (in their opinion)=20 > to be in the minority of deployments. >=20 > I do wonder if we are therefore expending a lot of energy=20 > (and later on time both in standardisation and possibly=20 > development effort) for a function that may be seldom, if=20 > ever, used. It won't be the first time we have standardised=20 > something that is seldom, if ever, used but we do have an=20 > opportunity now to take a step back and consider: is TCM=20 > really required and if it is required, is it a priority in=20 > the development of MPLS-TP? >=20 > Ben >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 >=20 >=20 From liu.guoman@zte.com.cn Thu Apr 16 18:16:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25A73A68E5 for ; Thu, 16 Apr 2009 18:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25hMhtuLC7sI for ; Thu, 16 Apr 2009 18:16:29 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 12E5E3A6831 for ; Thu, 16 Apr 2009 18:16:28 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Fri, 17 Apr 2009 09:10:39 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 47274.2258151844; Fri, 17 Apr 2009 09:14:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3H1HcYE054811; Fri, 17 Apr 2009 09:17:38 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <49E735ED.3060402@labn.net> To: Lou Berger , Ben Niven-Jenkins MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 17 Apr 2009 09:15:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-17 09:17:36, Serialize complete at 2009-04-17 09:17:36 Content-Type: multipart/alternative; boundary="=_alternative 000719294825759B_=" X-MAIL: mse2.zte.com.cn n3H1HcYE054811 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 01:16:31 -0000 This is a multipart message in MIME format. --=_alternative 000719294825759B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91Og0KIEkgYWdyZWUgeW91ciBhZHZpY2UsIGJ1dCBmb3Igc3ltbWV0cmljIGJhbmR3aWR0aCBy ZXF1aXJlbWVudCwgSSB0aGluayB0aGUgDQpyZXF1aXJlbWVudCBjYW4gb25seSBiZSBmaXQgZm9y IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRocywgDQp3aGlsZSBpdCBpc24n dCBuZWNlc3NhcnkgZm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyAuc28gYWRkaW5n IGEgDQoiY28tcm91dGVkIiAgd29yZCBpbiB0aGUgcmVxdWlyZW1lbnQgMzMgaXMgbmVjZXNzYXJ5 Lg0KdGhhbmsgeW91Lg0KbGl1DQoNCg0KDQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiAN CreivP7IyzogIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0wNC0xNiAyMTo0Mw0KDQrK 1bz+yMsNCkJlbiBOaXZlbi1KZW5raW5zIDxiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbT4N CrOty80NCkJVU0lAY29yZTMuYW1zbC5jb20sICJtcGxzLXRwQGlldGYub3JnIiA8bXBscy10cEBp ZXRmLm9yZz4sIElUQUxPIA0KPEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+DQrW98ziDQpS ZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1 aXJlbWVudHMNCg0KDQoNCg0KDQoNCkJlbiwNCiAgICAgICAgICAgICAgICAgSXQgc2VlbXMgdG8g bWUgdGhhdCBtdWNoIG9mIHRoZSBkaXNjdXNzaW9uIHN0ZW1zIGZyb20gdGhlIA0Kc2VjdGlvbiBp biANCndoaWNoIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgbGlzdGVkLg0KDQpSZXF1aXJlbWVudCAz MiBpcyBhIHNlcnZpY2UgbGV2ZWwgcmVxdWlyZW1lbnQgYW5kIHByaW1hcmlseSBpbXBhY3QgdGhl IA0KbWFuYWdlbWVudCBhbmQgY29udHJvbCBwbGFuZXMuICBBcyB0aGVyZSBpcyBubyBzZWN0aW9u IGRlc2NyaWJpbmcgDQpzZXJ2aWNlIHJlcXVpcmVtZW50cywgSSBzdWdnZXN0IG1vdmluZyB0aGlz IHJlcXVpcmVtZW50IHRvIGZvbGxvdyANCnJlcXVpcmVtZW50IDYsIGFuZCBhZGRpbmcgdGhlIGZv bGxvd2luZyBpbiBpdHMgcGxhY2U6DQogICAgMzMgIE1QTFMtVFAgTVVTVCBzdXBwb3J0IGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGhzIHdpdGgNCiAgICAgICAgc3ltbWV0cmljIGJhbmR3aWR0 aCByZXF1aXJlbWVudHMsIGkuZS4gdGhlIGFtb3VudCBvZiByZXNlcnZlZA0KICAgICAgICBiYW5k d2lkdGggaXMgdGhlIHNhbWUgYmV0d2VlbiB0aGUgZm9yd2FyZCBhbmQgYmFja3dhcmQNCiAgICAg ICAgZGlyZWN0aW9ucy4NCg0KV2hpbGUgdGhpcyB0b28gaXMgYSBzZXJ2aWNlIHJlcXVpcmVtZW50 IGFuZCBkb2Vzbid0IHJlcXVpcmUgYW55IGhhcmR3YXJlIA0KbW9kaWZpY2F0aW9ucywgaXQgcGFy YWxsZWxzIGN1cnJlbnQgcmVxdWlyZW1lbnRzIDM3LCA0MCBhbmQgNDEuICBJdCBhbHNvIA0KbWFr ZXMgYSBjdXJyZW50bHkgaW1wbGljaXQgcmVxdWlyZW1lbnQgZXhwbGljaXQuDQoNClJlcXVpcmVt ZW50cyAzMy0yNiByZWxhdGUgdG8gImF3YXJlbmVzcyIgc2hvdWxkIGhhdmUgbm8gaW1wbGljYXRp b24gb24gDQp0aGUgZGF0YS9mb3J3YXJkaW5nIHBsYW5lIGFuZCBhcmUgSU1PIGJvdGggbWFuYWdl bWVudCBhbmQgY29udHJvbCBwbGFuZSANCnJlcXVpcmVtZW50cy4gKEFuZCB5ZXMsIHRoZXkgaGF2 ZSBpbXBsaWNhdGlvbnMgb24gT0FNIGFuZCByZWNvdmVyeS4pICBJIA0KdGhpbmsgQWRyaWFuIHJh aXNlcyBhIGdvb2QgcG9pbnQgV1JUIHRoZXNlIHJlcXVpcmVtZW50cywgaS5lLiwgYXJlIHRoZXNl IA0KcmVxdWlyZW1lbnRzIGxpc3RlZCBhcyBzb2x1dGlvbnMgdG8gc29tZSB1bmxpc3RlZCByZXF1 aXJlbWVudHMuICBJZiBzbywgDQp0aGUgdW5saXN0ZWQgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSBp bmNsdWRlZCBhbmQgdGhlc2Ugc2hvdWxkIGJlIA0KZHJvcHBlZC4gIElmIG5vdCwgc28gYmUgaXQs IGJ1dCB0aGV5IHNob3VsZCBiZSBtb3ZlZCBmcm9tIHNlY3Rpb24gMi4zLg0KDQpXaGlsZSBJJ20g c3VyZSB0aGlzIHdvbid0IGVuZCB0aGUgZGlzY3Vzc2lvbiwgSSB0aGluayB0aGVzZSBjaGFuZ2Vz IHdpbGwgDQpoZWxwIG1ha2UgInRoZSByZXF1aXJlbWVudHMgY2xlYXIgZW5vdWdoIC4uLiINCg0K TG91DQoNCk9uIDQvMTYvMjAwOSA1OjU4IEFNLCBCZW4gTml2ZW4tSmVua2lucyB3cm90ZToNCj4g Q29sbGVhZ3VlcywNCj4NCj4gSSBjYW4ndCBoZWxwIGJ1dCBmZWVsIHdlIGFyZSBvdmVyYW5hbHlz aW5nIHRoaW5ncyBoZXJlLiBIb3cgbWFueQ0KPiB0ZWNobm9sb2dpZXMvcHJvdG9jb2xzL21lY2hh bmlzbXMgaGF2ZSB3ZSBzdWNjZXNzZnVsbHkgZGVmaW5lZCBpbiBib3RoIA0KSUVURg0KPiAmICBJ VFUtVCB3aXRob3V0IHRoaXMgbGV2ZWwgb2YgYW5hbHlzaXMgb2YgdGhlIGluaXRpYWwgcmVxdWly ZW1lbnRzIC0gYSANCmdyZWF0DQo+IG1hbnkgKGEgZ29vZCBjaHVuayBvZiB3aGljaCB3ZXJlIGV4 dHJlbWVseSBzdWNjZXNzZnVsKS4NCj4NCj4gVGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBpcyBu b3QgYWJvdXQgc3BlY2lmeWluZyBzb2x1dGlvbnMuDQo+DQo+IFRoZSBrZXkgcXVlc3Rpb24gaXM6 IGFyZSB0aGUgcmVxdWlyZW1lbnRzIGNsZWFyIGVub3VnaCB0aGF0IGl0IGlzIA0KdW5kZXJzdG9v ZA0KPiB3aGF0IGlzIHJlcXVpcmVkIHNvIHNvbWVvbmUgY291bGQgYnVpbGQgYSBib3gvcHJvdG9j b2wvd2hhdGV2ZXIgdG8gbWVldA0KPiB0aGVtPw0KPg0KPiBJZiB3ZSB3YW50IHRvIGdvIGludG8g dGhlIG50aCBsZXZlbCBvZiBkZXRhaWwgb24gZWFjaCByZXF1aXJlbWVudCB3ZSANCndpbGwNCj4g c3RpbGwgYmUgZGViYXRpbmcgdGhpcyBieSB0aGUgdGltZSBJIHJldGlyZSAod2hpY2ggaXNuJ3Qg ZHVlIHVudGlsIA0KMjA0NSkuDQo+DQo+IEJlbg0KPg0KPg0KPiBPbiAxNi8wNC8yMDA5IDA4OjA0 LCAiQWxleGFuZGVyIFZhaW5zaHRlaW4iDQo+IDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4gIHdyb3RlOg0KPg0KPj4gQWRyaWFuLA0KPj4gVGhhbmsgeW91IGZvciBhIHByb21wdCBh bmQgZGV0YWlsZWQgcmVzcG9uc2UuDQo+Pg0KPj4gVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxs eSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50Og0KPj4NCj4+IDxxdW90ZT4NCj4+ICAgICAgICBG cm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCBMU1BzDQo+PiAgICAgICBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIExTUHMuDQo+PiA8ZW5kIHF1b3RlPg0KPj4NCj4+IFRoaXMgc3RhdGVtZW50IHdvdWxk IGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0IG5vdCBmb3IgUmVxdWlyZW1lbnQgDQozNCBp bg0KPj4gdGhlIGxhdGVzdA0KPj4gTVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQNCj4+ICgNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1yZXF1 aXJlbWVudHMtMDYudHh0DQopOg0KPj4NCj4+IDxxdW90ZT4NCj4+ICAgICAgICBUaGUgaW50ZXJt ZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQgb3RoZXIgaW50ZXJuYWwNCj4+ ICAgICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIA0KdHJhbnNwb3J0DQo+PiAgICAgICAgIHBhdGggYXQgZWFjaCAoc3ViLSlsYXllciBN VVNUIGJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nDQo+PiAgICAgICAgIHJlbGF0aW9uc2hpcCBvZiB0 aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkIGRpcmVjdGlvbnMgb2YgdGhhdA0KPj4gICAgICAg ICB0cmFuc3BvcnQgcGF0aC4NCj4+IDxlbmQgcXVvdGU+DQo+Pg0KPj4gUGxlYXNlIG5vdGUgdGhh dCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZSBsaXN0IHRoYXQgaXMgDQpz cGVjaWZpYw0KPj4gZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChUaGUgcGFpcmlu ZyByZXF1aXJlbWVudHMgYXQgZW5kIA0KcG9pbnRzDQo+PiBmb3IgY28tcm91dGVkIGFuZCBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIGV4YWN0bHkgdGhlIHNhbWUgDQpldmVuDQo+ PiBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50IGl0ZW1zIGluIHRoZSByZXF1aXJlbWVu dHMnIGxpc3QpLg0KPj4gSW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhl IG5vdGlvbiBvZiBjby1yb3V0ZWQgDQpiaWRpcmVjdGlvbmFsDQo+PiBwYXRocyB3b3VsZCBiZSB2 b2lkIG9mIGFueSBkYXRhIHBsYW5lIGNvbnRlbnQuDQo+Pg0KPj4gVGhlIHNvbWV3aGF0IHZhZ3Vl IHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbCBmdW5jdGlvbnMNCj4+ IGFzIGFwcHJvcHJpYXRlIikgY3JlYXRlcyBhIHN1c3BpY2lvbiB0aGF0IEhXIHN1cHBvcnQgb2Yg dGhlIHBhaXJpbmcgDQphd2FyZW5lc3MNCj4+IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBj b21wbHkgd2l0aCBpdC4NCj4+DQo+PiBUaGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIGRyYWZ0IGlu Y3JlYXNlcyB0aGlzIHN1c3BpY2lvbjoNCj4+DQo+PiA8cXVvdGU+DQo+PiAgICAgVGFuZGVtIENv bm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW4gYXJiaXRyYXJ5IHBhcnQgb2YgYQ0K Pj4gICAgIHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5k ZXBlbmRlbnRseSBmcm9tIA0KdGhlDQo+PiAgICAgZW5kLXRvLWVuZCBtb25pdG9yaW5nIChPQU0p LiAgSXQgbWF5IGJlIGEgbW9uaXRvcmVkIHNlZ21lbnQgb3IgYQ0KPj4gICAgIG1vbml0b3JlZCBj b25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIHRyYW5zcG9ydCBwYXRoLiAgVGhlIHRhbmRlbQ0KPj4g ICAgIGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0aGUgZm9yd2FyZGluZyBlbmdpbmUocykg b2YgdGhlIG5vZGUocykNCj4+ICAgICBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBvciBj b25jYXRlbmF0ZWQgc2VnbWVudC4NCj4+IDxlbmQgcXVvdGU+DQo+Pg0KPj4gRG9lc24ndCAiZm9y d2FyZGluZyBlbmdpbmUiIHNvdW5kIGxpa2UgaGFyZHdhcmUgdG8geW91Pw0KPj4NCj4+IElNSE8g aXQgaXMgd29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUCBSZXF1aXJlbWVudHMg ZHJhZnQNCj4+IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZQ0KPj4gKA0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1y ZXF1aXJlbWVudHMtMDEudHgNCg0KPj4gdCkNCj4+IGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBk ZWFsaW5nIHdpdGggdGFuZGVtIGNvbm5lY3Rpb25zLg0KPj4NCj4+IEJ1dCB0YW5kZW0gY29ubmVj dGlvbnMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgTVBMUy1UUCBPQU0gRnJhbWV3b3JrIGRyYWZ0DQo+ PiAoDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMt dHAtb2FtLWZyYW1ld29yay0wMC50eHQNCikuDQo+Pg0KPj4gVGhlIGJvdHRvbSBsaW5lLCBJTUhP LCBpcyB0aGF0IHNvbWUgY2xhcml0eSByZWdhcmRpbmcgY28tcm91dGVkIHZzLiANCmFzc29jaWF0 ZWQNCj4+IGJpZGlyZWN0aW9uYWwNCj4+IHBhdGhzIGlzIHN0aWxsIHJlcXVpcmVkLiBPbmUgd2F5 IHRvIHByb3ZpZGUgdGhhdCBjb3VsZCBiZSBieSBleHBsaWNpdGx5DQo+PiBsaW1pdGluZyBSZXF1 aXJlbWVudCAzNA0KPj4gdG8gc3BlY2lmaWMgZnVuY3Rpb25hbGl0eS4NCj4+DQo+PiBNeSAyYywN Cj4+ICAgICAgIFNhc2hhDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IEZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBv bGRkb2cuY28udWtdDQo+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMTI6MTMgQU0N Cj4+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTw0KPj4g Q2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KcmVxdWlyZW1lbnRzDQo+Pg0KPj4gSGkg U2FzaGEsDQo+Pg0KPj4gTm90IHJlYWxseSBzdXJlIHdoZXRoZXIgeW91IGFyZSBtaXNyZXByZXNl bnRpbmcgYW55b25lLCBidXQuLi4NCj4+DQo+Pj4gMS4gTXkgcmVhZGluZyBvZiAgb25lIG9mIEJl bidzICBtZXNzYWdlcyBpcyB0aGF0IGFzc29jaWF0ZWQNCj4+PiBiaWRpcmVjdGlvbmFsIHBhdGhz IGFyZSB0aGUgb25seSB0eXBlcyBvZiBwYXRocyB0aGF0IGNhbiBiZQ0KPj4+IGNyZWF0ZWQgaW4g dGhlIGV4aXN0aW5nIG5ldHdvcmtzOyAidHJ1ZSIgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwNCj4+ PiBwYXRocyB3aWxsIGhhdmUgdG8gd2FpdCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVudCBi ZWNvbWVzDQo+Pj4gYXZhaWxhYmxlLg0KPj4gVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlIQ0KPj4g IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIExTUHMgYXJlIGENCj4+IHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgTFNQcy4NCj4+DQo+PiBJZiB5b3UgY2FuIHNldCB1cCB0d28gdW5pZGlyZWN0aW9uYWwgTFNQ cyAoZS5nLiB1c2luZyB0aGUgbWFuYWdlbWVudCANCnBsYW5lKQ0KPj4geW91IGNhbiBzdXJlbHkg c2V0IHVwIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPj4NCj4+IFRoZXJlIGFyZSBz aGlwcGluZyBzb2x1dGlvbnMgdGhhdCBhY2hpZXZlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExT UHMgDQp1c2luZw0KPj4gdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVpdGhlciB1c2UgdGhlIEdN UExTICh3aGljaCBpcyBjbGVhbmVyKSBvcg0KPj4gbm9uLXN0YW5kYXJkIHByb3ByaWV0YXJ5IHNv bHV0aW9ucyAod2hpY2ggaXMgbWVzc3kgYnV0IGZ1bmN0aW9uYWwpLg0KPj4NCj4+IEJ1dCAob2Yg Y291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lIHNvbHV0aW9ucyBo YXZlIA0Kbm90aGluZw0KPj4gdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50IGFz IHRoZXkgYXJlIHNvZnR3YXJlIHNvbHV0aW9ucy4NCj4+DQo+Pj4gMi4gTXkgcmVhZGluZyBvZiBv bmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRoYXQgdGhlIGFjdHVhbCBkcml2ZXIgZm9yDQo+Pj4g Y28tcm91dGVkDQo+Pj4gYmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRo IGV4aXN0aW5nIHRyYW5zcG9ydCBuZXR3b3Jrcw0KPj4+IHJhdGhlcg0KPj4+IHRoYW4gYW55IHNw ZWNpZmljIGJlbmVmaXQuDQo+PiBJc24ndCB0aGF0IHRoZSBjYXNlIHdpdGggNzUlIG9mIHRoZSBN UExTLVRQIHJlcXVpcmVtZW50cz8NCj4+IFdoaWNoIGlzIG5vdCB0byBzYXkgaXQgaXMgYSBiYWQg dGhpbmcuDQo+Pg0KPj4gQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUg cGFja2V0IG5ldHdvcmsgdGhlIGxvb2ssIA0KZmVlbCwgYW5kDQo+PiBiZWhhdmlvcmFsIGNoYXJh Y3RlcmlzdGljcyBvZiBhICJsZWdhY3kiIHRyYW5zcG9ydCBuZXR3b3JrLg0KPj4NCj4+PiBCYXNl ZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVzcyAoRldJVykgdGhhdDoNCj4+PiAqIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0IGZvciB0aGUgdGltZQ0K Pj4+ICAgICBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2YgYmlkaXJlY3Rpb25hbCBw YXRocyBpbg0KPj4+ICAgICBNUExTLVRQDQo+PiBJIHRoaW5rIHRoYXQgaXMgd3JvbmcgYm90aCBn aXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZCBnaXZlbiB0aGF0IA0Kb3RoZXINCj4+IHVwZ3Jh ZGVzIHRvIGV4aXN0aW5nIE1QTFMgc29sdXRpb25zIHdpbGwgYmUgbmVlZGVkIHRvIHJlYWNoIHRo ZSBmdWxsDQo+PiBmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLg0KPj4NCj4+PiAqIHRoZXkgaGFk IGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUgb2YgYmlkaXJlY3Rpb25hbA0K Pj4+ICAgIHBhdGhzIGluICByZWFsIGRlcGxveW1lbnRzLg0KPj4gSSBkb24ndCBzZWUgd2hhdCB0 aGF0IGZvbGxvd3MgZnJvbS4NCj4+DQo+PiBDaGVlcnMsDQo+PiBBZHJpYW4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtcGxzLXRwIG1haWxp bmcgbGlzdA0KPj4gbXBscy10cEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ DQo+DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000719294825759B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0kgYWdyZWUgeW91ciBhZHZpY2UsIGJ1 dCBmb3Igc3ltbWV0cmljDQpiYW5kd2lkdGggcmVxdWlyZW1lbnQsIEkgdGhpbmsgdGhlIHJlcXVp cmVtZW50IGNhbiBvbmx5IGJlIGZpdCBmb3IgY28tcm91dGVkDQpiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRocywgd2hpbGUgaXQgaXNuJ3QgbmVjZXNzYXJ5IGZvciBhc3NvY2lhdGVkDQpiaWRp cmVjdGlvbmFsIHBhdGhzIC5zbyBhZGRpbmcgYSAmcXVvdDtjby1yb3V0ZWQmcXVvdDsgJm5ic3A7 d29yZCBpbiB0aGUNCnJlcXVpcmVtZW50IDMzIGlzIG5lY2Vzc2FyeS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoYW5rIHlvdS48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxpdTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0 Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8 /sjLOiAmbmJzcDttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0xNiAyMTo0MzwvZm9udD4NCjx0ZCB3aWR0aD03 MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5CZW4gTml2ZW4tSmVua2lucyAm bHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5C VVNJQGNvcmUzLmFtc2wuY29tLCAmcXVvdDttcGxzLXRwQGlldGYub3JnJnF1b3Q7DQombHQ7bXBs cy10cEBpZXRmLm9yZyZndDssIElUQUxPICZsdDtJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0 Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwNCnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czwvZm9udD48L3RhYmxlPg0KPGJyPg0K PHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+QmVuLDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpJdCBzZWVtcyB0 byBtZSB0aGF0IG11Y2ggb2YgdGhlIGRpc2N1c3Npb24gc3RlbXMgZnJvbSB0aGUgc2VjdGlvbiBp biA8YnI+DQp3aGljaCB0aGVzZSByZXF1aXJlbWVudHMgYXJlIGxpc3RlZC48YnI+DQo8YnI+DQpS ZXF1aXJlbWVudCAzMiBpcyBhIHNlcnZpY2UgbGV2ZWwgcmVxdWlyZW1lbnQgYW5kIHByaW1hcmls eSBpbXBhY3QgdGhlDQo8YnI+DQptYW5hZ2VtZW50IGFuZCBjb250cm9sIHBsYW5lcy4gJm5ic3A7 QXMgdGhlcmUgaXMgbm8gc2VjdGlvbiBkZXNjcmliaW5nDQo8YnI+DQpzZXJ2aWNlIHJlcXVpcmVt ZW50cywgSSBzdWdnZXN0IG1vdmluZyB0aGlzIHJlcXVpcmVtZW50IHRvIGZvbGxvdyA8YnI+DQpy ZXF1aXJlbWVudCA2LCBhbmQgYWRkaW5nIHRoZSBmb2xsb3dpbmcgaW4gaXRzIHBsYWNlOjxicj4N CiAmbmJzcDsgJm5ic3A7MzMgJm5ic3A7TVBMUy1UUCBNVVNUIHN1cHBvcnQgYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQgcGF0aHMNCndpdGg8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 c3ltbWV0cmljIGJhbmR3aWR0aCByZXF1aXJlbWVudHMsIGkuZS4gdGhlDQphbW91bnQgb2YgcmVz ZXJ2ZWQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmFuZHdpZHRoIGlzIHRoZSBz YW1lIGJldHdlZW4gdGhlIGZvcndhcmQgYW5kDQpiYWNrd2FyZDxicj4NCiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtkaXJlY3Rpb25zLjxicj4NCjxicj4NCldoaWxlIHRoaXMgdG9vIGlzIGEg c2VydmljZSByZXF1aXJlbWVudCBhbmQgZG9lc24ndCByZXF1aXJlIGFueSBoYXJkd2FyZQ0KPGJy Pg0KbW9kaWZpY2F0aW9ucywgaXQgcGFyYWxsZWxzIGN1cnJlbnQgcmVxdWlyZW1lbnRzIDM3LCA0 MCBhbmQgNDEuICZuYnNwO0l0DQphbHNvIDxicj4NCm1ha2VzIGEgY3VycmVudGx5IGltcGxpY2l0 IHJlcXVpcmVtZW50IGV4cGxpY2l0Ljxicj4NCjxicj4NClJlcXVpcmVtZW50cyAzMy0yNiByZWxh dGUgdG8gJnF1b3Q7YXdhcmVuZXNzJnF1b3Q7IHNob3VsZCBoYXZlIG5vIGltcGxpY2F0aW9uDQpv biA8YnI+DQp0aGUgZGF0YS9mb3J3YXJkaW5nIHBsYW5lIGFuZCBhcmUgSU1PIGJvdGggbWFuYWdl bWVudCBhbmQgY29udHJvbCBwbGFuZQ0KPGJyPg0KcmVxdWlyZW1lbnRzLiAoQW5kIHllcywgdGhl eSBoYXZlIGltcGxpY2F0aW9ucyBvbiBPQU0gYW5kIHJlY292ZXJ5LikgJm5ic3A7SQ0KPGJyPg0K dGhpbmsgQWRyaWFuIHJhaXNlcyBhIGdvb2QgcG9pbnQgV1JUIHRoZXNlIHJlcXVpcmVtZW50cywg aS5lLiwgYXJlIHRoZXNlDQo8YnI+DQpyZXF1aXJlbWVudHMgbGlzdGVkIGFzIHNvbHV0aW9ucyB0 byBzb21lIHVubGlzdGVkIHJlcXVpcmVtZW50cy4gJm5ic3A7SWYNCnNvLCA8YnI+DQp0aGUgdW5s aXN0ZWQgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSBpbmNsdWRlZCBhbmQgdGhlc2Ugc2hvdWxkIGJl IDxicj4NCmRyb3BwZWQuICZuYnNwO0lmIG5vdCwgc28gYmUgaXQsIGJ1dCB0aGV5IHNob3VsZCBi ZSBtb3ZlZCBmcm9tIHNlY3Rpb24NCjIuMy48YnI+DQo8YnI+DQpXaGlsZSBJJ20gc3VyZSB0aGlz IHdvbid0IGVuZCB0aGUgZGlzY3Vzc2lvbiwgSSB0aGluayB0aGVzZSBjaGFuZ2VzIHdpbGwNCjxi cj4NCmhlbHAgbWFrZSAmcXVvdDt0aGUgcmVxdWlyZW1lbnRzIGNsZWFyIGVub3VnaCAuLi4mcXVv dDs8YnI+DQo8YnI+DQpMb3U8YnI+DQo8YnI+DQpPbiA0LzE2LzIwMDkgNTo1OCBBTSwgQmVuIE5p dmVuLUplbmtpbnMgd3JvdGU6PGJyPg0KJmd0OyBDb2xsZWFndWVzLDxicj4NCiZndDs8YnI+DQom Z3Q7IEkgY2FuJ3QgaGVscCBidXQgZmVlbCB3ZSBhcmUgb3ZlcmFuYWx5c2luZyB0aGluZ3MgaGVy ZS4gSG93IG1hbnk8YnI+DQomZ3Q7IHRlY2hub2xvZ2llcy9wcm90b2NvbHMvbWVjaGFuaXNtcyBo YXZlIHdlIHN1Y2Nlc3NmdWxseSBkZWZpbmVkIGluDQpib3RoIElFVEY8YnI+DQomZ3Q7ICZhbXA7 ICZuYnNwO0lUVS1UIHdpdGhvdXQgdGhpcyBsZXZlbCBvZiBhbmFseXNpcyBvZiB0aGUgaW5pdGlh bCByZXF1aXJlbWVudHMNCi0gYSBncmVhdDxicj4NCiZndDsgbWFueSAoYSBnb29kIGNodW5rIG9m IHdoaWNoIHdlcmUgZXh0cmVtZWx5IHN1Y2Nlc3NmdWwpLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRo ZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgaXMgbm90IGFib3V0IHNwZWNpZnlpbmcgc29sdXRpb25z Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBrZXkgcXVlc3Rpb24gaXM6IGFyZSB0aGUgcmVxdWly ZW1lbnRzIGNsZWFyIGVub3VnaCB0aGF0IGl0IGlzDQp1bmRlcnN0b29kPGJyPg0KJmd0OyB3aGF0 IGlzIHJlcXVpcmVkIHNvIHNvbWVvbmUgY291bGQgYnVpbGQgYSBib3gvcHJvdG9jb2wvd2hhdGV2 ZXIgdG8NCm1lZXQ8YnI+DQomZ3Q7IHRoZW0/PGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgd2Ugd2Fu dCB0byBnbyBpbnRvIHRoZSBudGggbGV2ZWwgb2YgZGV0YWlsIG9uIGVhY2ggcmVxdWlyZW1lbnQN CndlIHdpbGw8YnI+DQomZ3Q7IHN0aWxsIGJlIGRlYmF0aW5nIHRoaXMgYnkgdGhlIHRpbWUgSSBy ZXRpcmUgKHdoaWNoIGlzbid0IGR1ZSB1bnRpbA0KMjA0NSkuPGJyPg0KJmd0Ozxicj4NCiZndDsg QmVuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDE2LzA0LzIwMDkgMDg6MDQsICZx dW90O0FsZXhhbmRlciBWYWluc2h0ZWluJnF1b3Q7PGJyPg0KJmd0OyAmbHQ7QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7ICZuYnNwO3dyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7 Jmd0OyBBZHJpYW4sPGJyPg0KJmd0OyZndDsgVGhhbmsgeW91IGZvciBhIHByb21wdCBhbmQgZGV0 YWlsZWQgcmVzcG9uc2UuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBVbmZvcnR1bmF0ZWx5 IEkgY2Fubm90IGZ1bGx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQ6PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwNCmNvLXJvdXRl ZCBiaWRpcmVjdGlvbmFsIExTUHM8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBh cmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpMU1BzLjxicj4N CiZndDsmZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBU aGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZSBpdCBub3QgZm9y IFJlcXVpcmVtZW50DQozNCBpbjxicj4NCiZndDsmZ3Q7IHRoZSBsYXRlc3Q8YnI+DQomZ3Q7Jmd0 OyBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdDxicj4NCiZndDsmZ3Q7IChodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtcmVxdWlyZW1lbnRzLTA2 LnR4dCk6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0 OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIGludGVybWVkaWF0ZSBub2RlcyAo aW5jbHVkaW5nIE1FUHMsDQpNSVBzIGFuZCBvdGhlciBpbnRlcm5hbDxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEg Y28tcm91dGVkDQpiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2Fy ZQ0Kb2YgdGhlIHBhaXJpbmc8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUNCmJhY2t3YXJkIGRpcmVjdGlv bnMgb2YgdGhhdDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFu c3BvcnQgcGF0aC48YnI+DQomZ3Q7Jmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05M WSBpdGVtIGluIHRoZSBsaXN0IHRoYXQNCmlzIHNwZWNpZmljPGJyPg0KJmd0OyZndDsgZm9yIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChUaGUgcGFpcmluZyByZXF1aXJlbWVudHMgYXQN CmVuZCBwb2ludHM8YnI+DQomZ3Q7Jmd0OyBmb3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgcGF0aHMgYXJlIGV4YWN0bHkgdGhlDQpzYW1lIGV2ZW48YnI+DQomZ3Q7Jmd0 OyBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50IGl0ZW1zIGluIHRoZSByZXF1aXJlbWVu dHMnIGxpc3QpLjxicj4NCiZndDsmZ3Q7IEluIG90aGVyIHdvcmRzLCB3aXRob3V0IFJlcXVpcmVt ZW50IDM0IHRoZSBub3Rpb24gb2YgY28tcm91dGVkDQpiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyZn dDsgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50Ljxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVx dWlyZW1lbnQgKCZxdW90O290aGVyIGludGVybmFsDQpmdW5jdGlvbnM8YnI+DQomZ3Q7Jmd0OyBh cyBhcHByb3ByaWF0ZSZxdW90OykgY3JlYXRlcyBhIHN1c3BpY2lvbiB0aGF0IEhXIHN1cHBvcnQg b2YgdGhlDQpwYWlyaW5nIGF3YXJlbmVzczxicj4NCiZndDsmZ3Q7IG1heSBiZSByZXF1aXJlZCBp biBvcmRlciB0byBjb21wbHkgd2l0aCBpdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRo ZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW4g YXJiaXRyYXJ5DQpwYXJ0IG9mIGE8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9y dCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5kZXBlbmRlbnRseQ0KZnJv bSB0aGU8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IGVuZC10by1lbmQgbW9uaXRvcmluZyAo T0FNKS4gJm5ic3A7SXQgbWF5IGJlIGEgbW9uaXRvcmVkDQpzZWdtZW50IG9yIGE8YnI+DQomZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7IG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIHRy YW5zcG9ydCBwYXRoLg0KJm5ic3A7VGhlIHRhbmRlbTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJz cDsgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVuZ2luZShzKQ0K b2YgdGhlIG5vZGUocyk8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IGF0IHRoZSBlZGdlKHMp IG9mIHRoZSBzZWdtZW50IG9yIGNvbmNhdGVuYXRlZCBzZWdtZW50Ljxicj4NCiZndDsmZ3Q7ICZs dDtlbmQgcXVvdGUmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEb2Vzbid0ICZxdW90 O2ZvcndhcmRpbmcgZW5naW5lJnF1b3Q7IHNvdW5kIGxpa2UgaGFyZHdhcmUgdG8geW91Pzxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0 aGVyIHRoZSBNUExTLVRQIFJlcXVpcmVtZW50cw0KZHJhZnQ8YnI+DQomZ3Q7Jmd0OyBub3IgdGhl IE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50cyBvbmU8YnI+DQomZ3Q7Jmd0OyAoaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1yZXF1aXJlbWVu dHMtMDEudHg8YnI+DQomZ3Q7Jmd0OyB0KTxicj4NCiZndDsmZ3Q7IGNvbnRhaW4gYW55IHJlcXVp cmVtZW50cyBkZWFsaW5nIHdpdGggdGFuZGVtIGNvbm5lY3Rpb25zLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBN UExTLVRQIE9BTSBGcmFtZXdvcmsNCmRyYWZ0PGJyPg0KJmd0OyZndDsgKGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tZnJhbWV3b3JrLTAw LnR4dCkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgYm90dG9tIGxpbmUsIElNSE8s IGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZyBjby1yb3V0ZWQNCnZzLiBhc3NvY2lhdGVk PGJyPg0KJmd0OyZndDsgYmlkaXJlY3Rpb25hbDxicj4NCiZndDsmZ3Q7IHBhdGhzIGlzIHN0aWxs IHJlcXVpcmVkLiBPbmUgd2F5IHRvIHByb3ZpZGUgdGhhdCBjb3VsZCBiZSBieSBleHBsaWNpdGx5 PGJyPg0KJmd0OyZndDsgbGltaXRpbmcgUmVxdWlyZW1lbnQgMzQ8YnI+DQomZ3Q7Jmd0OyB0byBz cGVjaWZpYyBmdW5jdGlvbmFsaXR5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTXkgMmMs PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2FzaGE8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7IEZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdPGJyPg0K Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjEzIEFNPGJyPg0KJmd0 OyZndDsgVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPGJy Pg0KJmd0OyZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBS ZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KcmVx dWlyZW1lbnRzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBIaSBTYXNoYSw8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVw cmVzZW50aW5nIGFueW9uZSwgYnV0Li4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg MS4gTXkgcmVhZGluZyBvZiAmbmJzcDtvbmUgb2YgQmVuJ3MgJm5ic3A7bWVzc2FnZXMgaXMgdGhh dA0KYXNzb2NpYXRlZDxicj4NCiZndDsmZ3Q7Jmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0 aGUgb25seSB0eXBlcyBvZiBwYXRocyB0aGF0IGNhbiBiZTxicj4NCiZndDsmZ3Q7Jmd0OyBjcmVh dGVkIGluIHRoZSBleGlzdGluZyBuZXR3b3JrczsgJnF1b3Q7dHJ1ZSZxdW90OyBjby1yb3V0ZWQN CmJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7Jmd0OyZndDsgcGF0aHMgd2lsbCBoYXZlIHRvIHdhaXQg dW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lczxicj4NCiZndDsmZ3Q7Jmd0OyBh dmFpbGFibGUuPGJyPg0KJmd0OyZndDsgVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlITxicj4NCiZn dDsmZ3Q7ICZuYnNwO0Zyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRl ZCBiaWRpcmVjdGlvbmFsDQpMU1BzIGFyZSBhPGJyPg0KJmd0OyZndDsgc3BlY2lhbCBjYXNlIG9m IGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgKGUuZy4gdXNpbmcg dGhlIG1hbmFnZW1lbnQNCnBsYW5lKTxicj4NCiZndDsmZ3Q7IHlvdSBjYW4gc3VyZWx5IHNldCB1 cCBhIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IFRoZXJlIGFyZSBzaGlwcGluZyBzb2x1dGlvbnMgdGhhdCBhY2hpZXZlIGNvLXJvdXRlZCBi aWRpcmVjdGlvbmFsDQpMU1BzIHVzaW5nPGJyPg0KJmd0OyZndDsgdGhlIGNvbnRyb2wgcGxhbmUu IFRoZXNlIGVpdGhlciB1c2UgdGhlIEdNUExTICh3aGljaCBpcyBjbGVhbmVyKQ0Kb3I8YnI+DQom Z3Q7Jmd0OyBub24tc3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpcyBtZXNz eSBidXQgZnVuY3Rpb25hbCkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCdXQgKG9mIGNv dXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29udHJvbCBwbGFuZSBzb2x1dGlvbnMNCmhh dmUgbm90aGluZzxicj4NCiZndDsmZ3Q7IHRvIGRvIHdpdGggYXZhaWxhYmlsaXR5IG9mIGVxdWlw bWVudCBhcyB0aGV5IGFyZSBzb2Z0d2FyZSBzb2x1dGlvbnMuPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgMi4gTXkgcmVhZGluZyBvZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRo YXQgdGhlIGFjdHVhbA0KZHJpdmVyIGZvcjxicj4NCiZndDsmZ3Q7Jmd0OyBjby1yb3V0ZWQ8YnI+ DQomZ3Q7Jmd0OyZndDsgYmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRo IGV4aXN0aW5nIHRyYW5zcG9ydA0KbmV0d29ya3M8YnI+DQomZ3Q7Jmd0OyZndDsgcmF0aGVyPGJy Pg0KJmd0OyZndDsmZ3Q7IHRoYW4gYW55IHNwZWNpZmljIGJlbmVmaXQuPGJyPg0KJmd0OyZndDsg SXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUgTVBMUy1UUCByZXF1aXJlbWVudHM/ PGJyPg0KJmd0OyZndDsgV2hpY2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0aGluZy48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEEgbGFyZ2UgZHJpdmVyIGZvciBNUExTLVRQIGlzIHRv IGdpdmUgdGhlIHBhY2tldCBuZXR3b3JrIHRoZSBsb29rLA0KZmVlbCwgYW5kPGJyPg0KJmd0OyZn dDsgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSAmcXVvdDtsZWdhY3kmcXVvdDsgdHJh bnNwb3J0IG5ldHdvcmsuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQmFzZWQgb24g dGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRoYXQ6PGJyPg0KJmd0OyZndDsm Z3Q7ICogYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSwgYXQgbGVhc3QgZm9yIHRo ZSB0aW1lPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgYmVpbmcsIHRoZSBtb3N0IGlt cG9ydGFudCB0eXBlIG9mIGJpZGlyZWN0aW9uYWwNCnBhdGhzIGluPGJyPg0KJmd0OyZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgTVBMUy1UUDxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgdGhhdCBpcyB3cm9u ZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5kIGdpdmVuDQp0aGF0IG90aGVyPGJy Pg0KJmd0OyZndDsgdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZSBu ZWVkZWQgdG8gcmVhY2ggdGhlDQpmdWxsPGJyPg0KJmd0OyZndDsgZnVuY3Rpb24gbGV2ZWwgb2Yg TVBMUy1UUC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAqIHRoZXkgaGFkIGEgZ29v ZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUgb2YgYmlkaXJlY3Rpb25hbDxicj4NCiZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7cGF0aHMgaW4gJm5ic3A7cmVhbCBkZXBsb3ltZW50cy48 YnI+DQomZ3Q7Jmd0OyBJIGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93cyBmcm9tLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7IEFkcmlhbjxicj4NCiZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyBtcGxzLXRwQGll dGYub3JnPGJyPg0KJmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzLXRwPGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMt dHAgbWFpbGluZyBsaXN0PGJyPg0KbXBscy10cEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K PGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGlj ZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7 bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtS ZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZu YnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7 bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2Nv bnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7 b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJz cDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlh bCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRp dHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZu YnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2Vt YWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZu YnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5i c3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5i c3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtz ZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVk Jm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pU RSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000719294825759B_=-- From benjamin.niven-jenkins@bt.com Thu Apr 16 18:34:30 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380A33A69FD for ; Thu, 16 Apr 2009 18:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Et+-oHwRnk7 for ; Thu, 16 Apr 2009 18:34:29 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 415863A69CC for ; Thu, 16 Apr 2009 18:34:28 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 02:35:41 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Apr 2009 01:35:40 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 02:35:39 +0100 From: Ben Niven-Jenkins To: BUSI ITALO , Adrian Farrel , Alexander Vainshtein Message-ID: Thread-Topic: Tandem Connections in MPLS-TP (was RE: [mpls-tp] Associated bidirectional transport path requirements) Thread-Index: Acm+e9jj1HoQiXHcQhKAYvhbYuJx6wAKYxBAABXawM0= In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B172F@FRVELSMBS21.ad2.ad.alcatel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Apr 2009 01:35:41.0576 (UTC) FILETIME=[D1AFB880:01C9BEFC] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 01:34:30 -0000 Italo, In turn I am a little worried by your statement. On 16/04/2009 16:24, "BUSI ITALO" wrote: > I am a little bit worried by our statement: > >> Actually, I am quite fed up about this persistent insistence on the >> inclusion of "Tandem Connection." The definition within the >> ITU-T of this >> term is poorly specified and comes from the monitoring of a >> path that is >> parallel (i.e. tandem) to the data path being monitored. This >> definition of >> TC seems to be at variance, and would be if the ACH was >> actually in band. > > This is a strong requirement for transport networks and ITU-T has > clearly communicated this to IETF during the JWT analysis. > > We will be very persistent in maintaining what has been agreed by the > JWT. While our aim is to follow the JWT agreement I do not think we should blindly follow it because it was agreed by the JWT. As our understanding of MPLS-TP and its requirements evolves so it may be that some things agreed by the JWT are no longer relevant. Remember when the JWT made its agreement the requirements for T-MPLS/MPLS-TP were in general poorly specified and therefore I have to assume some assumptions had to be made. With all assumptions there is risk that although they were the best available assumption at the time that subsequently they are shown to be incorrect. So, IMO, something is not a requirement because the JWT agreed it. It is a requirement because operators require it. If operators require it then fine, but I have yet to hear an operator state publicly either in ITU or IETF that they require TCM in MPLS-TP. Like I said earlier tonight I know not all operators participate in standards but if just one operator were to step forward and say they require TCM it would put an end to this debate. Ben From liu.guoman@zte.com.cn Thu Apr 16 20:04:47 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605D23A689B for ; Thu, 16 Apr 2009 20:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NldNoRMHtro5 for ; Thu, 16 Apr 2009 20:04:45 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B66123A67A4 for ; Thu, 16 Apr 2009 20:04:44 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Fri, 17 Apr 2009 10:58:54 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 47274.801372902; Fri, 17 Apr 2009 11:02:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3H35nX3040634; Fri, 17 Apr 2009 11:05:50 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: Alexander Vainshtein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 17 Apr 2009 11:03:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-17 11:05:45, Serialize complete at 2009-04-17 11:05:45 Content-Type: multipart/alternative; boundary="=_alternative 001100384825759B_=" X-MAIL: mse2.zte.com.cn n3H35nX3040634 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 03:04:47 -0000 This is a multipart message in MIME format. --=_alternative 001100384825759B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c2FzaGE6DQogaSBkb24ndCBhZ3JlZSB5b3VyIGFkdmljZSwgaSB0aGluayBpdCBpcyBuZWNlc3Nh cnkgdG8gY29uc2lkZXIgVENNIA0KZnVuY3Rpb25hbGl0eSBhbmQgcHJvdGVjdGlvbnMgaW4gTVBM Uy1UUCBzdXJ2aXZlIGZyYW1ld29yay4NCml0IGlzIGNvbXBsZXggYW5kIGNvc3QgdG8gYXBwbHkg ZW5kIHRvIGVuZCBwcm90ZWN0aW9uLg0KdGhhbmsgeW91Lg0KbGl1DQoNCg0KDQpBbGV4YW5kZXIg VmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+IA0Kt6K8/sjLOiAg bXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoyMDA5LTA0LTE2IDIyOjMyDQoNCsrVvP7Iyw0KTWFh cnRlbiBWaXNzZXJzIDxtYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbT4NCrOty80NCiJtcGxzLXRw QGlldGYub3JnIiA8bXBscy10cEBpZXRmLm9yZz4NCtb3zOINClJlOiBbbXBscy10cF0gQ28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnQgKHdhczogDQpBc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQoNCg0K DQoNCg0KTWFhcnRlbiwNCkkndmUgc2Nhbm5lZCB0aGUgTVBMUy1UUCBTdXJ2aXZhYmlsaXR5IEZy YW1ld29yayBkcmFmdCAoDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLW1wbHMtdHAtc3Vydml2ZS1md2stMDAudHh0KSANCmJ1dCBkaWQgbm90IGZpbmQgdGhl cmUgYW55IHJlcXVpcmVtZW50cyBmb3IgIDE6MSBTTkMgcHJvdGVjdGlvbiAoaW5kZWVkLCANCnRo ZSB0ZXJtIFNOQyBpcyBub3QgbWVudGlvbmVkIGluIHRoaXMgZG9jdW1lbnQpLg0KIA0KQW5kIEFG QUlLIDE6MSBsaW5lYXIgcHJvdGVjdGlvbiAod2hpY2ggaXMgbWVudGlvbmVkIGluIHRoZSBkcmFm dCkgZG9lcyBub3QgDQpyZXF1aXJlIGFueSBUQ00gZnVuY3Rpb25hbGl0eS4NCiANCklmIHRoZSBm dW5jdGlvbmFsaXR5IHlvdSBoYXZlIGluIG1pbmQgaXMgY2FsbGVkIGJ5IGFueSBvdGhlciBuYW1l IGluIHRoZSANCk1QTFMtVFAgU3Vydml2YWJpbGl0eSBGcmFtZXdvcmsgLCBpdCB3b3VsZCBiZSBu aWNlIGlmIHlvdSBjb3VsZCBwcm92aWRlIGFuIA0KYXBwcm9wcmlhdGUgbWFwcGluZy4gSWYgbm90 LCBsZXQgdXMgbm90IHVzZSBpdCBhcyBhIGp1c3RpZmljYXRpb24gZm9yIA0KYWRkaXRpb25hbCBP QU0gZnVuY3Rpb25hbGl0eSBsaWtlIFRDTS4NCiANClJlZ2FyZHMsDQogICAgIFNhc2hhDQogDQog DQogDQogDQogDQogDQpGcm9tOiBNYWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3 ZWkuY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDM6MjkgUE0NClRvOiBBbGV4 YW5kZXIgVmFpbnNodGVpbg0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBs cy10cF0gQ28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnQg DQood2FzOiBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1l bnRzKQ0KDQpTYXNoYSwNCiANCkkgZG8gbm90IGFncmVlIHdpdGggeW91IG5vciBBZHJpYW4gaW4g dGhpcyBtYXR0ZXIgYXMgZXhwbGFpbmVkIGluIG15IA0KcmVzcG9uc2UgdG8gQWRyaWFuJ3MgZW1h aWwgYSBmZXcgbWludXRlcyBhZ28uDQogDQpPbmUgb2YgdGhlIGFwcGxpY2F0aW9ucyB0aGF0IHdv dWxkIG5vdCBsb25nZXIgYmUgYWJsZSB0byBmdW5jdGlvbiB3b3VsZCBiZSANCjE6MSBQVyBTTkMg cHJvdGVjdGlvbiBvciAxOjEgTFNQIFNOQyBwcm90ZWN0aW9uLiBGb3IgdGhvc2UgcHJvdGVjdGlv biANCm1lY2hhbmlzbXMgd2UgbmVlZCBUQ00gTUVQIGZ1bmN0aW9ucyB0byBkZXRlcm1pbmUgdGhl IHN0YXR1cyBvZiBlYWNoIFNOQy4NCiANClJlZ2FyZHMsDQpNYWFydGVuDQoNCkZyb206IG1wbHMt dHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIA0KT2YgQWxleGFuZGVyIFZhaW5zaHRlaW4NClNlbnQ6IGRvbmRlcmRhZyAxNiBhcHJp bCAyMDA5IDEzOjQwDQpUbzogQWRyaWFuIEZhcnJlbA0KQ2M6IEJVU0lAY29yZTMuYW1zbC5jb207 IElUQUxPOyBtcGxzLXRwQGlldGYub3JnDQpTdWJqZWN0OiBbbXBscy10cF0gQ28tcm91dGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnQgDQood2FzOiBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQpBZHJpYW4sDQpM b29rcyBhcyB3ZSBhcmUgbXVjaCBtb3JlIGluIGFncmVlbWVudCB0aGFuIGl0IGNvdWxkIGJlIGd1 ZXNzZWQgZnJvbSB0aGUgDQpmaXJzdCByb3VuZCBvZiBleGNoYW5nZXMuDQpJJ3ZlIGNoYW5nZWQg dGhlIHN1YmplY3Qgc2luY2Ugd2UgYXJlIGFjdHVhbGx5IGRpc2N1c3Npbmcgc3BlY2lmaWNzIG9m IA0KY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMuDQogDQpJIGZ1bGx5IHN1cHBvcnQgeW91 ciBwcm9wb3NhbCB0byBnZXQgcmlkIChpbiBhIGNvbnNpc3RlbnQgbWFubmVyKSBmcm9tIHRoZSAN ClRDIHN0dWZmIGluIE1QTFMtVFAsIGVzcGVjaWFsbHkgc2luY2UsIHRvIHRoZSBiZXN0IG9mIG15 IGtub3dsZWRnZSwgDQpvcGVyYXRpb25hbCBleHBlcmllbmNlIHdpdGggU09ORVQvU0RIIFRDTSAo SVRVLVQgZGVmaW5pdGlvbnMgDQpub3R3aXRoc3RhbmRpbmcpIGRpZCBub3QgcHJvdmUgaXRzIHdv cnRoLiBJZiB0aGlzIGlzIGJhc2VkIG9uIA0KbWlzLXBlcmNlcHRpb24sIEkgd291bGQgYmUgZ2xh ZCB0byBoZWFyIHRoYXQgKGVzcGVjaWFsbHkgZnJvbSB0aGUgDQpvcGVyYXRvcnMgb24gdGhpcyBs aXN0KS4NCiANCkFuZCBpZiBpdCBpcyBwb3NzaWJsZSB0byByZS13cml0ZSBSZXF1aXJlbWVudCAz NCBhcyBhIGZ1bmN0aW9uYWwvYmVoYXZpb3IgDQpyZXF1aXJlbWVudCwgaXQgd291bGQgYmUgZ3Jl YXQsIHRvby4NCkhvd2V2ZXIsIEkgYW0gbm90IHN1cmUgdGhpcyB3b3VsZCBiZSBlYXN5IChCZW4s IG15IGFwb2xvZ2llcyBhZ2FpbikuDQogDQpSZWdhcmRzLA0KICAgICBTYXNoYQ0KIA0KIA0KIA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBZHJpYW4g RmFycmVsIFthZHJpYW5Ab2xkZG9nLmNvLnVrXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAy MDA5IDEyOjU5IFBNDQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGJlbmphbWluLm5pdmVuLWpl bmtpbnNAYnQuY29tDQpDYzogbXBscy10cEBpZXRmLm9yZzsgTG91IEJlcmdlcjsgQlVTSSBJVEFM Tw0KU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggDQpyZXF1aXJlbWVudHMNCg0KSGkgU2FzaGEsDQoNCj4gVW5mb3J0dW5hdGVseSBJ IGNhbm5vdCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50Og0KPg0KPiA8cXVvdGU+DQo+ ICAgICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1BzDQo+ICAgICBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIExTUHMuDQo+IDxlbmQgcXVvdGU+DQo+DQo+IFRoaXMgc3RhdGVtZW50IHdvdWxk IGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0IG5vdCBmb3IgUmVxdWlyZW1lbnQgDQozNA0K PiBpbiB0aGUgbGF0ZXN0DQo+IE1QTFMtVFAgcmVxdWlyZW1lbnRzIGRyYWZ0DQoNCk9LLiBHb3Qg aXQuDQoNCkJ1dCB3aGF0IGlzIHRoaXMgZG9pbmcgaW4gdGhlIGRhdGEgcGxhbmUgcmVxdWlyZW1l bnRzIHNlY3Rpb24/DQoNCkluIGZhY3QsIHdoYXQgaXMgdGhpcyByZXF1aXJlbWVudCBhY3R1YWxs eSBzYXlpbmc/DQoNCj4gPHF1b3RlPg0KPiAgICAgIFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGlu Y2x1ZGluZyBNRVBzLCBNSVBzIGFuZCBvdGhlciBpbnRlcm5hbA0KPiAgICAgICBmdW5jdGlvbnMg YXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ ICAgICAgIHBhdGggYXQgZWFjaCAoc3ViLSlsYXllciBNVVNUIGJlIGF3YXJlIG9mIHRoZSBwYWly aW5nDQo+ICAgICAgIHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJk IGRpcmVjdGlvbnMgb2YgdGhhdA0KPiAgICAgICB0cmFuc3BvcnQgcGF0aC4NCj4gPGVuZCBxdW90 ZT4NCg0KVGhlcmUgaXMgbm8gd2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBU aGF0IGlzLCB0aGVyZSBpcw0KKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBi bGFjayBib3ggcG9pbnQgb2YgdmlldyB0aGF0IHJlc3VsdHMNCmZyb20gYWRoZXJpbmcgdG8gdGhp cyByZXF1aXJlbWVudC4NCg0KVGhlcmVmb3JlIGl0IGNvdWxkIGJlIGFzc3VtZWQgdGhhdCB0aGlz IHJlcXVpcmVtZW50IGlzIG1ldCBieSBjb25maWd1cmluZw0Kc29tZSBkYXRhIHBsYW5lIGRhdGFi YXNlIGNvbXBvbmVudCB0aHJvdWdoIHRoZSBtYW5hZ2VtZW50IHBsYW5lLiBUaGUNCmRhdGFiYXNl IGNvbXBvbmVudCBpcyBub3QgdXNlZCBmb3IgYW55dGhpbmcgZXhjZXB0IHRvIHNhdGlzZnkgdGhp cw0KcmVxdWlyZW1lbnQgZm9yICJhd2FyZW5lc3MiLg0KDQpCZW4hIENhbiB3ZSBwbGVhc2UgdHJ5 IHRvIHJld3JpdGUgdGhpcyByZXF1aXJlbWVudCBpbiB0ZXJtcyBvZiBiZWhhdmlvcj8NCg0KPiBQ bGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4gdGhlIGxp c3QgdGhhdCBpcw0KPiBzcGVjaWZpYw0KPiBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQ cy4gKFRoZSBwYWlyaW5nIHJlcXVpcmVtZW50cyBhdCBlbmQgDQpwb2ludHMNCj4gZm9yIGNvLXJv dXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSBleGFjdGx5IHRoZSBz YW1lIA0KZXZlbg0KPiBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50IGl0ZW1zIGluIHRo ZSByZXF1aXJlbWVudHMnIGxpc3QpLg0KPiBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJl bWVudCAzNCB0aGUgbm90aW9uIG9mIGNvLXJvdXRlZA0KPiBiaWRpcmVjdGlvbmFsDQo+IHBhdGhz IHdvdWxkIGJlIHZvaWQgb2YgYW55IGRhdGEgcGxhbmUgY29udGVudC4NCj4NCj4gVGhlIHNvbWV3 aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbCBmdW5j dGlvbnMNCj4gYXMgYXBwcm9wcmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcgc3Vw cG9ydCBvZiB0aGUgcGFpcmluZw0KPiBhd2FyZW5lc3MNCj4gbWF5IGJlIHJlcXVpcmVkIGluIG9y ZGVyIHRvIGNvbXBseSB3aXRoIGl0Lg0KDQpUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQg dGV4dCAiKGluY2x1ZGluZyBNRVBzLCBNSVBzIGFuZCBvdGhlcg0KaW50ZXJuYWwgZnVuY3Rpb25z IGFzIGFwcHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90IGFkZCB0bw0K IlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KDQo+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUg ZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KPg0KPiA8cXVvdGU+DQo+ICAgVGFuZGVt IENvbm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW4gYXJiaXRyYXJ5IHBhcnQgb2Yg YQ0KPiAgIHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5k ZXBlbmRlbnRseSBmcm9tIHRoZQ0KPiAgIGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gIEl0 IG1heSBiZSBhIG1vbml0b3JlZCBzZWdtZW50IG9yIGENCj4gICBtb25pdG9yZWQgY29uY2F0ZW5h dGVkIHNlZ21lbnQgb2YgYSB0cmFuc3BvcnQgcGF0aC4gIFRoZSB0YW5kZW0NCj4gICBjb25uZWN0 aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRpbmcgZW5naW5lKHMpIG9mIHRoZSBub2Rl KHMpDQo+ICAgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNl Z21lbnQuDQo+IDxlbmQgcXVvdGU+DQoNCkFjdHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91 dCB0aGlzIHBlcnNpc3RlbnQgaW5zaXN0ZW5jZSBvbiB0aGUNCmluY2x1c2lvbiBvZiAiVGFuZGVt IENvbm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3aXRoaW4gdGhlIElUVS1UIG9mIHRoaXMNCnRl cm0gaXMgcG9vcmx5IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUgbW9uaXRvcmluZyBvZiBh IHBhdGggdGhhdCBpcw0KcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJl aW5nIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIA0Kb2YNClRDIHNlZW1zIHRvIGJlIGF0IHZh cmlhbmNlLCBhbmQgd291bGQgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC4NCg0K PiBEb2Vzbid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgc291bmQgbGlrZSBoYXJkd2FyZSB0byB5b3U/ DQoNClllcywgYnV0IHNvIHdoYXQ/DQoNCj4gSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBu ZWl0aGVyIHRoZSBNUExTLVRQIFJlcXVpcmVtZW50cw0KPiBkcmFmdCBub3IgdGhlIE1QTFMtVFAg T0FNIHJlcXVpcmVtZW50cyBvbmUNCj4gKA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1yZXF1aXJlbWVudHMtMDEudHh0DQopDQo+IGNv bnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGggdGFuZGVtIGNvbm5lY3Rpb25zLg0K Pg0KPiBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAg T0FNIEZyYW1ld29yayBkcmFmdA0KPiAoDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWZyYW1ld29yay0wMC50eHQNCikuDQoNClJpZ2h0 Lg0KTGV0J3MganVzdCBnZXQgcmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nIGFs bCB0aGUgSS1EcyBpbnRvIA0KbGluZS4NCg0KPiBUaGUgYm90dG9tIGxpbmUsIElNSE8sIGlzIHRo YXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZyBjby1yb3V0ZWQgdnMuDQo+IGFzc29jaWF0ZWQNCj4g YmlkaXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdheSB0byBwcm92aWRl IHRoYXQgY291bGQgYmUgDQpieQ0KPiBleHBsaWNpdGx5DQo+IGxpbWl0aW5nIFJlcXVpcmVtZW50 IDM0IHRvIHNwZWNpZmljIGZ1bmN0aW9uYWxpdHkuDQoNCkFncmVlZC4NCg0KQWRyaWFuDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEFkcmlh biBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTYs IDIwMDkgMTI6MTMgQU0NClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsgQlVT SSBJVEFMTw0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KcmVxdWlyZW1lbnRzDQoNCkhp IFNhc2hhLA0KDQpOb3QgcmVhbGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3JlcHJlc2VudGlu ZyBhbnlvbmUsIGJ1dC4uLg0KDQo+IDEuIE15IHJlYWRpbmcgb2YgIG9uZSBvZiBCZW4ncyAgbWVz c2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkDQo+IGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBv bmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQgY2FuIGJlDQo+IGNyZWF0ZWQgaW4gdGhlIGV4aXN0aW5n IG5ldHdvcmtzOyAidHJ1ZSIgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwNCj4gcGF0aHMgd2lsbCBo YXZlIHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lcw0KPiBhdmFp bGFibGUuDQoNClRoaXMgaXMgY2xlYXJseSBub25zZW5zZSENCkZyb20gdGhlIHBvaW50IG9mIHZp ZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMgYXJlIGENCnNwZWNp YWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCg0KSWYgeW91IGNhbiBz ZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgKGUuZy4gdXNpbmcgdGhlIG1hbmFnZW1lbnQg DQpwbGFuZSkNCnlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFs IExTUC4NCg0KVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQcyANCnVzaW5nDQp0aGUgY29udHJvbCBwbGFuZS4gVGhlc2Ug ZWl0aGVyIHVzZSB0aGUgR01QTFMgKHdoaWNoIGlzIGNsZWFuZXIpIG9yDQpub24tc3RhbmRhcmQg cHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpcyBtZXNzeSBidXQgZnVuY3Rpb25hbCkuDQoN CkJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lIHNv bHV0aW9ucyBoYXZlIA0Kbm90aGluZw0KdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBt ZW50IGFzIHRoZXkgYXJlIHNvZnR3YXJlIHNvbHV0aW9ucy4NCg0KPiAyLiBNeSByZWFkaW5nIG9m IG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMgaXMgdGhhdCB0aGUgYWN0dWFsIGRyaXZlciBmb3INCj4g Y28tcm91dGVkDQo+IGJpZGlyZWN0aW9uYWwgcGF0aHMgbWF5IGJlIGV4cGVyaWVuY2Ugd2l0aCBl eGlzdGluZyB0cmFuc3BvcnQgbmV0d29ya3MNCj4gcmF0aGVyDQo+IHRoYW4gYW55IHNwZWNpZmlj IGJlbmVmaXQuDQoNCklzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAg cmVxdWlyZW1lbnRzPw0KV2hpY2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0aGluZy4NCg0K QSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsg dGhlIGxvb2ssIGZlZWwsIA0KYW5kDQpiZWhhdmlvcmFsIGNoYXJhY3RlcmlzdGljcyBvZiBhICJs ZWdhY3kiIHRyYW5zcG9ydCBuZXR3b3JrLg0KDQo+IEJhc2VkIG9uIHRoZXNlIG9ic2VydmF0aW9u cywgSSdkIGd1ZXNzIChGV0lXKSB0aGF0Og0KPiAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBw YXRocyBhcmUsIGF0IGxlYXN0IGZvciB0aGUgdGltZQ0KPiAgICBiZWluZywgdGhlIG1vc3QgaW1w b3J0YW50IHR5cGUgb2YgYmlkaXJlY3Rpb25hbCBwYXRocyBpbg0KPiAgICBNUExTLVRQDQoNCkkg dGhpbmsgdGhhdCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5kIGdp dmVuIHRoYXQgb3RoZXINCnVwZ3JhZGVzIHRvIGV4aXN0aW5nIE1QTFMgc29sdXRpb25zIHdpbGwg YmUgbmVlZGVkIHRvIHJlYWNoIHRoZSBmdWxsDQpmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLg0K DQo+ICogdGhleSBoYWQgYSBnb29kIGNoYW5jZSB0byByZW1haW4gdGhlIG9ubHkgdHlwZSBvZiBi aWRpcmVjdGlvbmFsDQo+ICAgcGF0aHMgaW4gIHJlYWwgZGVwbG95bWVudHMuDQoNCkkgZG9uJ3Qg c2VlIHdoYXQgdGhhdCBmb2xsb3dzIGZyb20uDQoNCkNoZWVycywNCkFkcmlhbl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzLXRwIG1haWxpbmcgbGlz dA0KbXBscy10cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzLXRwDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIu DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 001100384825759B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNhc2hhOjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7aSBkb24ndCBhZ3JlZSB5b3VyIGFk dmljZSwgaSB0aGluaw0KaXQgaXMgbmVjZXNzYXJ5IHRvIGNvbnNpZGVyIFRDTSBmdW5jdGlvbmFs aXR5IGFuZCBwcm90ZWN0aW9ucyBpbiBNUExTLVRQDQpzdXJ2aXZlIGZyYW1ld29yay48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPml0IGlzIGNvbXBsZXggYW5kIGNv c3QgdG8gYXBwbHkgZW5kDQp0byBlbmQgcHJvdGVjdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoYW5rIHlvdS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPmxpdTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5BbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTE2IDIyOjMy PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pk1hYXJ0ZW4gVmlzc2VycyAmbHQ7bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20mZ3Q7PC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDttcGxzLXRwQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzLXRwQGll dGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzLXRwXSBDby1yb3V0ZWQgYmlk aXJlY3Rpb25hbA0KdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnQgKHdhczogQXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQpyZXF1aXJlbWVudHMpPC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+TWFhcnRlbiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+SSd2ZSBzY2FubmVkIHRoZSBNUExTLVRQIFN1cnZpdmFiaWxpdHkNCkZyYW1ld29yayBk cmFmdCAoPC9mb250PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtbXBscy10cC1zdXJ2aXZlLWZ3ay0wMC50eHQiPjxmb250IHNpemU9MyBjb2xv cj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXN1cnZpdmUtZndrLTAwLnR4dDwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPikNCmJ1dCBkaWQgbm90 IGZpbmQgdGhlcmUgYW55IHJlcXVpcmVtZW50cyBmb3IgJm5ic3A7MToxIFNOQyBwcm90ZWN0aW9u IChpbmRlZWQsDQp0aGUgdGVybSBTTkMgaXMgbm90IG1lbnRpb25lZCBpbiB0aGlzIGRvY3VtZW50 KS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5BbmQgQUZBSUsgMToxIGxpbmVhciBwcm90ZWN0aW9u DQood2hpY2ggaXMgbWVudGlvbmVkIGluIHRoZSBkcmFmdCkgZG9lcyBub3QgcmVxdWlyZSBhbnkg VENNIGZ1bmN0aW9uYWxpdHkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SWYgdGhlIGZ1bmN0aW9u YWxpdHkgeW91IGhhdmUgaW4NCm1pbmQgaXMgY2FsbGVkIGJ5IGFueSBvdGhlciBuYW1lIGluIHRo ZSBNUExTLVRQIFN1cnZpdmFiaWxpdHkgRnJhbWV3b3JrDQosIGl0IHdvdWxkIGJlIG5pY2UgaWYg eW91IGNvdWxkIHByb3ZpZGUgYW4gYXBwcm9wcmlhdGUgbWFwcGluZy4gSWYgbm90LA0KbGV0IHVz IG5vdCB1c2UgaXQgYXMgYSBqdXN0aWZpY2F0aW9uIGZvciBhZGRpdGlvbmFsIE9BTSBmdW5jdGlv bmFsaXR5IGxpa2UNClRDTS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRzLDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsgJm5ic3A7ICZu YnNwO1Nhc2hhPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGhyPjxmb250IHNp emU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBNYWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4u dmlzc2Vyc0BodWF3ZWkuY29tXTxiPjxicj4NClNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTYs IDIwMDkgMzoyOSBQTTxiPjxicj4NClRvOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW48Yj48YnI+ DQpDYzo8L2I+IG1wbHMtdHBAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUkU6IFttcGxz LXRwXSBDby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudA0K KHdhczogQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50 cyk8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJBcmlhbCI+U2FzaGEsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkkgZG8g bm90IGFncmVlIHdpdGggeW91IG5vciBBZHJpYW4NCmluIHRoaXMgbWF0dGVyIGFzIGV4cGxhaW5l ZCBpbiBteSByZXNwb25zZSB0byBBZHJpYW4ncyBlbWFpbCBhIGZldyBtaW51dGVzDQphZ28uPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0iQXJpYWwiPk9uZSBvZiB0aGUgYXBwbGljYXRpb25zIHRoYXQgd291bGQN Cm5vdCBsb25nZXIgYmUgYWJsZSB0byBmdW5jdGlvbiB3b3VsZCBiZSAxOjEgUFcgU05DIHByb3Rl Y3Rpb24gb3IgMToxIExTUA0KU05DIHByb3RlY3Rpb24uIEZvciB0aG9zZSBwcm90ZWN0aW9uIG1l Y2hhbmlzbXMgd2UgbmVlZCBUQ00gTUVQIGZ1bmN0aW9ucw0KdG8gZGV0ZXJtaW5lIHRoZSBzdGF0 dXMgb2YgZWFjaCBTTkMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPlJlZ2FyZHMsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5NYWFydGVuPC9mb250Pg0K PGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsZXhhbmRlciBWYWluc2h0ZWluPGI+PGJyPg0KU2VudDo8 L2I+IGRvbmRlcmRhZyAxNiBhcHJpbCAyMDA5IDEzOjQwPGI+PGJyPg0KVG86PC9iPiBBZHJpYW4g RmFycmVsPGI+PGJyPg0KQ2M6PC9iPiBCVVNJQGNvcmUzLmFtc2wuY29tOyBJVEFMTzsgbXBscy10 cEBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBbbXBscy10cF0gQ28tcm91dGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnQNCih3YXM6IEFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpPC9mb250Pjxmb250IHNpemU9 Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+QWRyaWFuLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT5Mb29rcyBhcyB3ZSBhcmUgbXVjaCBtb3Jl IGluIGFncmVlbWVudCB0aGFuDQppdCBjb3VsZCBiZSBndWVzc2VkIGZyb20gdGhlIGZpcnN0IHJv dW5kIG9mIGV4Y2hhbmdlcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj5JJ3ZlIGNoYW5nZWQgdGhlIHN1YmplY3QNCnNpbmNlIHdlIGFy ZSBhY3R1YWxseSBkaXNjdXNzaW5nIHNwZWNpZmljcyBvZiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCBwYXRocy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkkgZnVsbHkgc3VwcG9y dCB5b3VyDQpwcm9wb3NhbCB0byBnZXQgcmlkIChpbiBhIGNvbnNpc3RlbnQgbWFubmVyKSBmcm9t IHRoZSBUQyBzdHVmZiBpbiBNUExTLVRQLA0KZXNwZWNpYWxseSBzaW5jZSwgdG8gdGhlIGJlc3Qg b2YgbXkga25vd2xlZGdlLCBvcGVyYXRpb25hbCBleHBlcmllbmNlIHdpdGgNClNPTkVUL1NESCBU Q00gKElUVS1UIGRlZmluaXRpb25zIG5vdHdpdGhzdGFuZGluZykgZGlkIG5vdCBwcm92ZSBpdHMg d29ydGguDQpJZiB0aGlzIGlzIGJhc2VkIG9uIG1pcy1wZXJjZXB0aW9uLCBJIHdvdWxkIGJlIGds YWQgdG8gaGVhciB0aGF0IChlc3BlY2lhbGx5DQpmcm9tIHRoZSBvcGVyYXRvcnMgb24gdGhpcyBs aXN0KS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkFuZCBpZiBpdCBpcyBwb3Nz aWJsZQ0KdG8gcmUtd3JpdGUgUmVxdWlyZW1lbnQgMzQgYXMgYSBmdW5jdGlvbmFsL2JlaGF2aW9y IHJlcXVpcmVtZW50LCBpdCB3b3VsZA0KYmUgZ3JlYXQsIHRvby48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5Ib3dldmVyLCBJIGFtIG5v dCBzdXJlDQp0aGlzIHdvdWxkIGJlIGVhc3kgKEJlbiwgbXkgYXBvbG9naWVzIGFnYWluKS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDtTYXNoYTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCkZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdPGJy Pg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjU5IFBNPGJyPg0KVG86IEFsZXhh bmRlciBWYWluc2h0ZWluOyBiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbTxicj4NCkNjOiBt cGxzLXRwQGlldGYub3JnOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPGJyPg0KU3ViamVjdDogUmU6 IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWly ZW1lbnRzPGJyPg0KPGJyPg0KSGkgU2FzaGEsPGJyPg0KPGJyPg0KJmd0OyBVbmZvcnR1bmF0ZWx5 IEkgY2Fubm90IGZ1bGx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQ6PGJyPg0KJmd0Ozxicj4N CiZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBGcm9tIHRoZSBwb2lu dCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KTFNQczxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIExTUHMuPGJyPg0KJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoaXMgc3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0 IG5vdCBmb3IgUmVxdWlyZW1lbnQNCjM0PGJyPg0KJmd0OyBpbiB0aGUgbGF0ZXN0PGJyPg0KJmd0 OyBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdDxicj4NCjxicj4NCk9LLiBHb3QgaXQuPGJyPg0K PGJyPg0KQnV0IHdoYXQgaXMgdGhpcyBkb2luZyBpbiB0aGUgZGF0YSBwbGFuZSByZXF1aXJlbWVu dHMgc2VjdGlvbj88YnI+DQo8YnI+DQpJbiBmYWN0LCB3aGF0IGlzIHRoaXMgcmVxdWlyZW1lbnQg YWN0dWFsbHkgc2F5aW5nPzxicj4NCjxicj4NCiZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQ cywgTUlQcyBhbmQNCm90aGVyIGludGVybmFsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwN CnRyYW5zcG9ydDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF0aCBhdCBlYWNoIChz dWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlDQpwYWlyaW5nPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2Fy ZA0KZGlyZWN0aW9ucyBvZiB0aGF0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFu c3BvcnQgcGF0aC48YnI+DQomZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJyPg0KPGJyPg0KVGhlcmUg aXMgbm8gd2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBUaGF0IGlzLCB0aGVy ZSBpczxicj4NCipub3RoaW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94 IHBvaW50IG9mIHZpZXcgdGhhdCByZXN1bHRzPGJyPg0KZnJvbSBhZGhlcmluZyB0byB0aGlzIHJl cXVpcmVtZW50Ljxicj4NCjxicj4NClRoZXJlZm9yZSBpdCBjb3VsZCBiZSBhc3N1bWVkIHRoYXQg dGhpcyByZXF1aXJlbWVudCBpcyBtZXQgYnkgY29uZmlndXJpbmc8YnI+DQpzb21lIGRhdGEgcGxh bmUgZGF0YWJhc2UgY29tcG9uZW50IHRocm91Z2ggdGhlIG1hbmFnZW1lbnQgcGxhbmUuIFRoZTxi cj4NCmRhdGFiYXNlIGNvbXBvbmVudCBpcyBub3QgdXNlZCBmb3IgYW55dGhpbmcgZXhjZXB0IHRv IHNhdGlzZnkgdGhpczxicj4NCnJlcXVpcmVtZW50IGZvciAmcXVvdDthd2FyZW5lc3MmcXVvdDsu PGJyPg0KPGJyPg0KQmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdyaXRlIHRoaXMgcmVxdWly ZW1lbnQgaW4gdGVybXMgb2YgYmVoYXZpb3I/PGJyPg0KPGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0 aGF0IFJlcXVpcmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4gdGhlIGxpc3QgdGhhdA0KaXM8 YnI+DQomZ3Q7IHNwZWNpZmljPGJyPg0KJmd0OyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg TFNQcy4gKFRoZSBwYWlyaW5nIHJlcXVpcmVtZW50cyBhdCBlbmQNCnBvaW50czxicj4NCiZndDsg Zm9yIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSBleGFj dGx5IHRoZSBzYW1lDQpldmVuPGJyPg0KJmd0OyBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVy ZW50IGl0ZW1zIGluIHRoZSByZXF1aXJlbWVudHMnIGxpc3QpLjxicj4NCiZndDsgSW4gb3RoZXIg d29yZHMsIHdpdGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlvbiBvZiBjby1yb3V0ZWQ8YnI+ DQomZ3Q7IGJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7IHBhdGhzIHdvdWxkIGJlIHZvaWQgb2YgYW55 IGRhdGEgcGxhbmUgY29udGVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgc29tZXdoYXQgdmFn dWUgc2NvcGUgb2YgdGhpcyByZXF1aXJlbWVudCAoJnF1b3Q7b3RoZXIgaW50ZXJuYWwNCmZ1bmN0 aW9uczxicj4NCiZndDsgYXMgYXBwcm9wcmlhdGUmcXVvdDspIGNyZWF0ZXMgYSBzdXNwaWNpb24g dGhhdCBIVyBzdXBwb3J0IG9mIHRoZSBwYWlyaW5nPGJyPg0KJmd0OyBhd2FyZW5lc3M8YnI+DQom Z3Q7IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC48YnI+DQo8YnI+ DQpUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAmcXVvdDsoaW5jbHVkaW5nIE1F UHMsIE1JUHMgYW5kIG90aGVyPGJyPg0KaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRl KSZxdW90OyBzaG91bGQgYmUgZGVsZXRlZC4gSXQgZG9lcyBub3QNCmFkZCB0bzxicj4NCiZxdW90 O1RoZSBpbnRlcm1lZGlhdGUgbm9kZXMuJnF1b3Q7PGJyPg0KPGJyPg0KJmd0OyBUaGUgZm9sbG93 aW5nIHRleHQgaW4gdGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzIHN1c3BpY2lvbjo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgVGFuZGVtIENvbm5lY3Rp b246IEEgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW4gYXJiaXRyYXJ5IHBhcnQNCm9mIGE8YnI+DQom Z3Q7ICZuYnNwOyB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0p IGluZGVwZW5kZW50bHkNCmZyb20gdGhlPGJyPg0KJmd0OyAmbmJzcDsgZW5kLXRvLWVuZCBtb25p dG9yaW5nIChPQU0pLiAmbmJzcDtJdCBtYXkgYmUgYSBtb25pdG9yZWQgc2VnbWVudA0Kb3IgYTxi cj4NCiZndDsgJm5ic3A7IG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIHRyYW5z cG9ydCBwYXRoLiAmbmJzcDtUaGUNCnRhbmRlbTxicj4NCiZndDsgJm5ic3A7IGNvbm5lY3Rpb24g bWF5IGFsc28gaW5jbHVkZSB0aGUgZm9yd2FyZGluZyBlbmdpbmUocykgb2YgdGhlDQpub2RlKHMp PGJyPg0KJmd0OyAmbmJzcDsgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0 ZW5hdGVkIHNlZ21lbnQuPGJyPg0KJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCjxicj4NCkFj dHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQgaW5zaXN0ZW5j ZSBvbiB0aGU8YnI+DQppbmNsdXNpb24gb2YgJnF1b3Q7VGFuZGVtIENvbm5lY3Rpb24uJnF1b3Q7 IFRoZSBkZWZpbml0aW9uIHdpdGhpbiB0aGUgSVRVLVQNCm9mIHRoaXM8YnI+DQp0ZXJtIGlzIHBv b3JseSBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1vbml0b3Jpbmcgb2YgYSBwYXRoIHRo YXQgaXM8YnI+DQpwYXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBhdGggYmVpbmcg bW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24NCm9mPGJyPg0KVEMgc2VlbXMgdG8gYmUgYXQgdmFy aWFuY2UsIGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLjxicj4N Cjxicj4NCiZndDsgRG9lc24ndCAmcXVvdDtmb3J3YXJkaW5nIGVuZ2luZSZxdW90OyBzb3VuZCBs aWtlIGhhcmR3YXJlIHRvIHlvdT88YnI+DQo8YnI+DQpZZXMsIGJ1dCBzbyB3aGF0Pzxicj4NCjxi cj4NCiZndDsgSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0aGVyIHRoZSBNUExTLVRQ IFJlcXVpcmVtZW50czxicj4NCiZndDsgZHJhZnQgbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJl bWVudHMgb25lPGJyPg0KJmd0OyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1yZXF1aXJlbWVudHMtMDEudHh0KTxicj4NCiZndDsgY29u dGFpbiBhbnkgcmVxdWlyZW1lbnRzIGRlYWxpbmcgd2l0aCB0YW5kZW0gY29ubmVjdGlvbnMuPGJy Pg0KJmd0Ozxicj4NCiZndDsgQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGlu IHRoZSBNUExTLVRQIE9BTSBGcmFtZXdvcmsNCmRyYWZ0PGJyPg0KJmd0OyAoaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcmFtZXdvcmst MDAudHh0KS48YnI+DQo8YnI+DQpSaWdodC48YnI+DQpMZXQncyBqdXN0IGdldCByaWQgb2YgYW4g dW5uZWNlc3NhcnkgdGVybSBhbmQgYnJpbmcgYWxsIHRoZSBJLURzIGludG8gbGluZS48YnI+DQo8 YnI+DQomZ3Q7IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21lIGNsYXJpdHkgcmVn YXJkaW5nIGNvLXJvdXRlZCB2cy48YnI+DQomZ3Q7IGFzc29jaWF0ZWQ8YnI+DQomZ3Q7IGJpZGly ZWN0aW9uYWwgcGF0aHMgaXMgc3RpbGwgcmVxdWlyZWQuIE9uZSB3YXkgdG8gcHJvdmlkZSB0aGF0 IGNvdWxkDQpiZSBieTxicj4NCiZndDsgZXhwbGljaXRseTxicj4NCiZndDsgbGltaXRpbmcgUmVx dWlyZW1lbnQgMzQgdG8gc3BlY2lmaWMgZnVuY3Rpb25hbGl0eS48YnI+DQo8YnI+DQpBZ3JlZWQu PGJyPg0KPGJyPg0KQWRyaWFuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkZyb206IEFkcmlhbiBGYXJyZWwg W2FkcmlhbkBvbGRkb2cuY28udWtdPGJyPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5 IDEyOjEzIEFNPGJyPg0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJ IElUQUxPPGJyPg0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHM8 YnI+DQo8YnI+DQpIaSBTYXNoYSw8YnI+DQo8YnI+DQpOb3QgcmVhbGx5IHN1cmUgd2hldGhlciB5 b3UgYXJlIG1pc3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLjxicj4NCjxicj4NCiZndDsgMS4g TXkgcmVhZGluZyBvZiAmbmJzcDtvbmUgb2YgQmVuJ3MgJm5ic3A7bWVzc2FnZXMgaXMgdGhhdCBh c3NvY2lhdGVkPGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBl cyBvZiBwYXRocyB0aGF0IGNhbiBiZTxicj4NCiZndDsgY3JlYXRlZCBpbiB0aGUgZXhpc3Rpbmcg bmV0d29ya3M7ICZxdW90O3RydWUmcXVvdDsgY28tcm91dGVkIGJpZGlyZWN0aW9uYWw8YnI+DQom Z3Q7IHBhdGhzIHdpbGwgaGF2ZSB0byB3YWl0IHVudGlsIChpZiBldmVyKSBuZXcgZXF1aXBtZW50 IGJlY29tZXM8YnI+DQomZ3Q7IGF2YWlsYWJsZS48YnI+DQo8YnI+DQpUaGlzIGlzIGNsZWFybHkg bm9uc2Vuc2UhPGJyPg0KRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQcyBhcmUgYTxicj4NCnNwZWNpYWwgY2FzZSBvZiBhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy48YnI+DQo8YnI+DQpJZiB5b3UgY2FuIHNldCB1cCB0d28g dW5pZGlyZWN0aW9uYWwgTFNQcyAoZS5nLiB1c2luZyB0aGUgbWFuYWdlbWVudCBwbGFuZSk8YnI+ DQp5b3UgY2FuIHN1cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuPGJy Pg0KPGJyPg0KVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQcw0KdXNpbmc8YnI+DQp0aGUgY29udHJvbCBwbGFuZS4gVGhl c2UgZWl0aGVyIHVzZSB0aGUgR01QTFMgKHdoaWNoIGlzIGNsZWFuZXIpIG9yPGJyPg0Kbm9uLXN0 YW5kYXJkIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMgbWVzc3kgYnV0IGZ1bmN0aW9u YWwpLjxicj4NCjxicj4NCkJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBj b250cm9sIHBsYW5lIHNvbHV0aW9ucyBoYXZlIG5vdGhpbmc8YnI+DQp0byBkbyB3aXRoIGF2YWls YWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMgdGhleSBhcmUgc29mdHdhcmUgc29sdXRpb25zLjxicj4N Cjxicj4NCiZndDsgMi4gTXkgcmVhZGluZyBvZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRo YXQgdGhlIGFjdHVhbCBkcml2ZXINCmZvcjxicj4NCiZndDsgY28tcm91dGVkPGJyPg0KJmd0OyBi aWRpcmVjdGlvbmFsIHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcgdHJhbnNw b3J0IG5ldHdvcmtzPGJyPg0KJmd0OyByYXRoZXI8YnI+DQomZ3Q7IHRoYW4gYW55IHNwZWNpZmlj IGJlbmVmaXQuPGJyPg0KPGJyPg0KSXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUg TVBMUy1UUCByZXF1aXJlbWVudHM/PGJyPg0KV2hpY2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJh ZCB0aGluZy48YnI+DQo8YnI+DQpBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZl IHRoZSBwYWNrZXQgbmV0d29yayB0aGUgbG9vaywgZmVlbCwNCmFuZDxicj4NCmJlaGF2aW9yYWwg Y2hhcmFjdGVyaXN0aWNzIG9mIGEgJnF1b3Q7bGVnYWN5JnF1b3Q7IHRyYW5zcG9ydCBuZXR3b3Jr Ljxicj4NCjxicj4NCiZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3Mg KEZXSVcpIHRoYXQ6PGJyPg0KJmd0OyAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBh cmUsIGF0IGxlYXN0IGZvciB0aGUgdGltZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2JlaW5nLCB0 aGUgbW9zdCBpbXBvcnRhbnQgdHlwZSBvZiBiaWRpcmVjdGlvbmFsIHBhdGhzDQppbjxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO01QTFMtVFA8YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgaXMgd3Jvbmcg Ym90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZCBnaXZlbiB0aGF0IG90aGVyPGJyPg0K dXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZSBuZWVkZWQgdG8gcmVh Y2ggdGhlIGZ1bGw8YnI+DQpmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLjxicj4NCjxicj4NCiZn dDsgKiB0aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBlIG9mIGJp ZGlyZWN0aW9uYWw8YnI+DQomZ3Q7ICZuYnNwOyBwYXRocyBpbiAmbmJzcDtyZWFsIGRlcGxveW1l bnRzLjxicj4NCjxicj4NCkkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBmb2xsb3dzIGZyb20uPGJyPg0K PGJyPg0KQ2hlZXJzLDxicj4NCkFkcmlhbjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscy10cCBtYWls aW5nIGxpc3Q8YnI+DQptcGxzLXRwQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHBy ZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNw O1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVu dHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8m bmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJz cDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMm bmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMu DQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5z bWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7 YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNw O3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYm bmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJz cDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3Jp Z2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3 cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUm bmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4N ClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtm b3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7 QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001100384825759B_=-- From Alexander.Vainshtein@ecitele.com Fri Apr 17 00:48:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4113A6D30 for ; Fri, 17 Apr 2009 00:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=-1.971, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPgFNwwDtDQG for ; Fri, 17 Apr 2009 00:48:26 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 331AA3A6809 for ; Fri, 17 Apr 2009 00:48:23 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 17 Apr 2009 10:55:12 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:49:36 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 17 Apr 2009 10:49:35 +0300 From: Alexander Vainshtein To: "liu.guoman@zte.com.cn" Date: Fri, 17 Apr 2009 10:49:35 +0300 Thread-Topic: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) Thread-Index: Acm/Cad9hqNrjpRXT9mlHYkXHM7cJwAIEDRQ Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A6ILPTMAIL02eci_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2009 07:49:36.0375 (UTC) FILETIME=[0DDE6070:01C9BF31] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:48:28 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A6ILPTMAIL02eci_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TGl1LA0KVGhhbmsgeW91IGZvciBhIHByb21wdCByZXNwb25zZS4NCg0KVG8gbWFrZSBpdCBjbGVh ciwgSSBkaWQgbm90IGFkdm9jYXRlIDE6MSBsaW5lYXIgKGEuay5hLiBlbmQtdG8tZW5kKSBwcm90 ZWN0aW9uIGZvciBNUExTLVRQLiBJJ3ZlIG9ubHkgbWVudGlvbmVkIGl0IGFzIHRoZSBvbmx5IDE6 MSBwcm90ZWN0aW9uIHNjaGVtZSBJJ3ZlIGZvdW5kIGluIHRoZSBNUExTLVRQIFN1cnZpdmFiaWxp dHkgRnJhbWV3b3JrIGRyYWZ0Lg0KDQpUbyB0YWtlIG9uZSBzdGVwIGZ1cnRoZXIsIElNSE8gYW5k IEZXSVcsIHNwZWNpZmljIHByb3RlY3Rpb24gc2NoZW1lcyBhbmQgbW9uaXRvcmluZyBtZWNoYW5p c21zIGFyZSBub3QgdGlnaHRseSBjb3VwbGVkLCBhbmQgcHJlZmVyYWJseSBzaG91bGQgcmVtYWlu IHNvLiBIZW5jZSBhbnkgYXR0ZW1wdCB0byBqdXN0aWZ5IGV4aXN0ZW5jZSBvZiBhIGNlcnRhaW4g bW9uaXRvcmluZyBtZWNoYW5pc20gKGFuZCBUQ00gY2xlYXJseSBmYWxscyBpbiB0aGUgdGhpcyBj YXRlZ29yeSAtIGl0IHN0YW5kcyBmb3IgVGFuZGVtIENvbm5lY3Rpb24gTW9uaXRvcmluZykgYnkg cmVmZXJlbmNlIHRvIGEgY2VydGFpbiBwcm90ZWN0aW9uIHNjaGVtZSB3b3VsZCBsb29rIGZhdWx0 eSB0byBtZS4gQW5kIGlmLCBvbiB0b3Agb2YgdGhpcywgdGhlIHByb3RlY3Rpb24gc2NoZW1lIGlu IHF1ZXN0aW9uIGlzIG5vdCBldmVuIG1lbnRpb25lZCBuIHRoZSBTdXJ2aXZhYmlsaXR5IEZyYW1l d29yayBkcmFmdC4uLiBubyBuZWVkIHRvIGNvbnRpbnVlLCBJIHRoaW5rLg0KDQooT2YgY291cnNl IHRoaXMgZG9lcyBub3QgbWVhbiB0aGF0IGFkZGl0aW9uYWwgcHJvdGVjdGlvbiBzY2hlbWVzIGNh bm5vdCBhcHBlYXIgaW4gdGhlIE1QTFMtVFAgU3Vydml2YWJpbGl0eSBGcmFtZXdvcmsgZHJhZnQu IE9uIHRoZSBvdGhlciBoYW5kLCBzb21lIG9mIHRoZSBzY2hlbWVzIG5vdyBpbiB0aGUgZHJhZnQg bWF5IGJlIGV2ZW50dWFsbHkgZHJvcHBlZCBvciwgYXQgbGVhc3QsIGRvd25ncmFkZWQgZnJvbSBN VVNUIHRvIFNIT1VMRCBvciBNQVkuIEJ1dCB0aGlzIGlzIGEgZGlmZmVyZW50IHRvcGljKS4NCg0K TGFzdCBidXQgbm90IGxlYXN0LCB3ZSBhcmUgY3VycmVudGx5IGRpc2N1c3NpbmcgTVBMUy1UUCBy ZXF1aXJlbWVudHMsIGFuZCB0aGVzZSByZXF1aXJlbWVudHMgcHJlc3VtYWJseSBzaG91bGQgYmUg YmFzZWQgb24gZXhwZXJpZW5jZSBvZiB0aGUgdHJhbnNwb3J0IG9wZXJhdG9ycy4gQXMgc29tZSBw ZW9wbGUgKGluY2x1ZGluZyBteXNlbGYpIGhhdmUgbm90ZWQsIGluIHRoZSB0d28gcm91bmRzIG9m IGVhcmxpZXIgZGlzY3Vzc2lvbnMgbm8gdHJhbnNwb3J0IG9wZXJhdG9ycyBoYXZlIG5vdCBleHBs aWNpdGx5IHJlcXVpcmVkIFRDTS4gIEluIHRoaXMgKDNyZCEpIHJvdW5kIGF0IGxlYXN0IG9uZSBt YWpvciBvcGVyYXRvciBoYXMgZXhwbGljaXRseSBzdGF0ZWQgdGhhdCBUQ00gaXMgbm90IG5lZWRl ZC4NCg0KUmVnYXJkcywNCiAgICAgU2FzaGENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBsaXUuZ3VvbWFuQHp0ZS5jb20uY24gW2xpdS5ndW9tYW5AenRlLmNv bS5jbl0NClNlbnQ6IEZyaWRheSwgQXByaWwgMTcsIDIwMDkgNjowMyBBTQ0KVG86IEFsZXhhbmRl ciBWYWluc2h0ZWluDQpDYzogbXBscy10cEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzLXRw XSBDby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudCAod2Fz OiBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0K DQoNCnNhc2hhOg0KIGkgZG9uJ3QgYWdyZWUgeW91ciBhZHZpY2UsIGkgdGhpbmsgaXQgaXMgbmVj ZXNzYXJ5IHRvIGNvbnNpZGVyIFRDTSBmdW5jdGlvbmFsaXR5IGFuZCBwcm90ZWN0aW9ucyBpbiBN UExTLVRQIHN1cnZpdmUgZnJhbWV3b3JrLg0KaXQgaXMgY29tcGxleCBhbmQgY29zdCB0byBhcHBs eSBlbmQgdG8gZW5kIHByb3RlY3Rpb24uDQp0aGFuayB5b3UuDQpsaXUNCg0KDQpBbGV4YW5kZXIg VmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQq3orz+yMs6ICBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAwOS0wNC0xNiAyMjozMg0KDQoNCsrVvP7Iyw0K ICAgICAgICBNYWFydGVuIFZpc3NlcnMgPG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPg0Ks63L zQ0KICAgICAgICAibXBscy10cEBpZXRmLm9yZyIgPG1wbHMtdHBAaWV0Zi5vcmc+DQrW98ziDQog ICAgICAgIFJlOiBbbXBscy10cF0gQ28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnQgKHdhczogQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBw YXRoIHJlcXVpcmVtZW50cykNCg0KDQoNCg0KDQoNCg0KTWFhcnRlbiwNCkkndmUgc2Nhbm5lZCB0 aGUgTVBMUy1UUCBTdXJ2aXZhYmlsaXR5IEZyYW1ld29yayBkcmFmdCAoaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXN1cnZpdmUtZndrLTAwLnR4 dCkgYnV0IGRpZCBub3QgZmluZCB0aGVyZSBhbnkgcmVxdWlyZW1lbnRzIGZvciAgMToxIFNOQyBw cm90ZWN0aW9uIChpbmRlZWQsIHRoZSB0ZXJtIFNOQyBpcyBub3QgbWVudGlvbmVkIGluIHRoaXMg ZG9jdW1lbnQpLg0KDQpBbmQgQUZBSUsgMToxIGxpbmVhciBwcm90ZWN0aW9uICh3aGljaCBpcyBt ZW50aW9uZWQgaW4gdGhlIGRyYWZ0KSBkb2VzIG5vdCByZXF1aXJlIGFueSBUQ00gZnVuY3Rpb25h bGl0eS4NCg0KSWYgdGhlIGZ1bmN0aW9uYWxpdHkgeW91IGhhdmUgaW4gbWluZCBpcyBjYWxsZWQg YnkgYW55IG90aGVyIG5hbWUgaW4gdGhlIE1QTFMtVFAgU3Vydml2YWJpbGl0eSBGcmFtZXdvcmsg LCBpdCB3b3VsZCBiZSBuaWNlIGlmIHlvdSBjb3VsZCBwcm92aWRlIGFuIGFwcHJvcHJpYXRlIG1h cHBpbmcuIElmIG5vdCwgbGV0IHVzIG5vdCB1c2UgaXQgYXMgYSBqdXN0aWZpY2F0aW9uIGZvciBh ZGRpdGlvbmFsIE9BTSBmdW5jdGlvbmFsaXR5IGxpa2UgVENNLg0KDQpSZWdhcmRzLA0KICAgICBT YXNoYQ0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206 IE1hYXJ0ZW4gVmlzc2VycyBbbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dDQpTZW50OiBUaHVy c2RheSwgQXByaWwgMTYsIDIwMDkgMzoyOSBQTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQpD YzogbXBscy10cEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzLXRwXSBDby1yb3V0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudCAod2FzOiBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQpTYXNoYSwNCg0KSSBk byBub3QgYWdyZWUgd2l0aCB5b3Ugbm9yIEFkcmlhbiBpbiB0aGlzIG1hdHRlciBhcyBleHBsYWlu ZWQgaW4gbXkgcmVzcG9uc2UgdG8gQWRyaWFuJ3MgZW1haWwgYSBmZXcgbWludXRlcyBhZ28uDQoN Ck9uZSBvZiB0aGUgYXBwbGljYXRpb25zIHRoYXQgd291bGQgbm90IGxvbmdlciBiZSBhYmxlIHRv IGZ1bmN0aW9uIHdvdWxkIGJlIDE6MSBQVyBTTkMgcHJvdGVjdGlvbiBvciAxOjEgTFNQIFNOQyBw cm90ZWN0aW9uLiBGb3IgdGhvc2UgcHJvdGVjdGlvbiBtZWNoYW5pc21zIHdlIG5lZWQgVENNIE1F UCBmdW5jdGlvbnMgdG8gZGV0ZXJtaW5lIHRoZSBzdGF0dXMgb2YgZWFjaCBTTkMuDQoNClJlZ2Fy ZHMsDQpNYWFydGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KU2VudDogZG9uZGVyZGFnIDE2IGFw cmlsIDIwMDkgMTM6NDANClRvOiBBZHJpYW4gRmFycmVsDQpDYzogQlVTSUBjb3JlMy5hbXNsLmNv bTsgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzLXRwXSBDby1yb3V0ZWQg YmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudCAod2FzOiBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQpBZHJpYW4sDQpM b29rcyBhcyB3ZSBhcmUgbXVjaCBtb3JlIGluIGFncmVlbWVudCB0aGFuIGl0IGNvdWxkIGJlIGd1 ZXNzZWQgZnJvbSB0aGUgZmlyc3Qgcm91bmQgb2YgZXhjaGFuZ2VzLg0KSSd2ZSBjaGFuZ2VkIHRo ZSBzdWJqZWN0IHNpbmNlIHdlIGFyZSBhY3R1YWxseSBkaXNjdXNzaW5nIHNwZWNpZmljcyBvZiBj by1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocy4NCg0KSSBmdWxseSBzdXBwb3J0IHlvdXIgcHJv cG9zYWwgdG8gZ2V0IHJpZCAoaW4gYSBjb25zaXN0ZW50IG1hbm5lcikgZnJvbSB0aGUgVEMgc3R1 ZmYgaW4gTVBMUy1UUCwgZXNwZWNpYWxseSBzaW5jZSwgdG8gdGhlIGJlc3Qgb2YgbXkga25vd2xl ZGdlLCBvcGVyYXRpb25hbCBleHBlcmllbmNlIHdpdGggU09ORVQvU0RIIFRDTSAoSVRVLVQgZGVm aW5pdGlvbnMgbm90d2l0aHN0YW5kaW5nKSBkaWQgbm90IHByb3ZlIGl0cyB3b3J0aC4gSWYgdGhp cyBpcyBiYXNlZCBvbiBtaXMtcGVyY2VwdGlvbiwgSSB3b3VsZCBiZSBnbGFkIHRvIGhlYXIgdGhh dCAoZXNwZWNpYWxseSBmcm9tIHRoZSBvcGVyYXRvcnMgb24gdGhpcyBsaXN0KS4NCg0KQW5kIGlm IGl0IGlzIHBvc3NpYmxlIHRvIHJlLXdyaXRlIFJlcXVpcmVtZW50IDM0IGFzIGEgZnVuY3Rpb25h bC9iZWhhdmlvciByZXF1aXJlbWVudCwgaXQgd291bGQgYmUgZ3JlYXQsIHRvby4NCkhvd2V2ZXIs IEkgYW0gbm90IHN1cmUgdGhpcyB3b3VsZCBiZSBlYXN5IChCZW4sIG15IGFwb2xvZ2llcyBhZ2Fp bikuDQoNClJlZ2FyZHMsDQogICAgIFNhc2hhDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cu Y28udWtdDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMTI6NTkgUE0NClRvOiBBbGV4 YW5kZXIgVmFpbnNodGVpbjsgYmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20NCkNjOiBtcGxz LXRwQGlldGYub3JnOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPDQpTdWJqZWN0OiBSZTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMN Cg0KSGkgU2FzaGEsDQoNCj4gVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxseSBhZ3JlZSB3aXRo IHlvdXIgc3RhdGVtZW50Og0KPg0KPiA8cXVvdGU+DQo+ICAgICBGcm9tIHRoZSBwb2ludCBvZiB2 aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzDQo+ICAgICBhcmUg YSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuDQo+IDxlbmQg cXVvdGU+DQo+DQo+IFRoaXMgc3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3JyZWN0LCB3 ZXJlIGl0IG5vdCBmb3IgUmVxdWlyZW1lbnQgMzQNCj4gaW4gdGhlIGxhdGVzdA0KPiBNUExTLVRQ IHJlcXVpcmVtZW50cyBkcmFmdA0KDQpPSy4gR290IGl0Lg0KDQpCdXQgd2hhdCBpcyB0aGlzIGRv aW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cyBzZWN0aW9uPw0KDQpJbiBmYWN0LCB3 aGF0IGlzIHRoaXMgcmVxdWlyZW1lbnQgYWN0dWFsbHkgc2F5aW5nPw0KDQo+IDxxdW90ZT4NCj4g ICAgICBUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQgb3Ro ZXIgaW50ZXJuYWwNCj4gICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJv dXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPiAgICAgICBwYXRoIGF0IGVhY2ggKHN1Yi0p bGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KPiAgICAgICByZWxhdGlvbnNoaXAg b2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZCBkaXJlY3Rpb25zIG9mIHRoYXQNCj4gICAg ICAgdHJhbnNwb3J0IHBhdGguDQo+IDxlbmQgcXVvdGU+DQoNClRoZXJlIGlzIG5vIHdheSB0aGlz IGlzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdCBpcywgdGhlcmUgaXMNCipub3RoaW5n KiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZpZXcgdGhh dCByZXN1bHRzDQpmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuDQoNClRoZXJlZm9y ZSBpdCBjb3VsZCBiZSBhc3N1bWVkIHRoYXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgYnkgY29u ZmlndXJpbmcNCnNvbWUgZGF0YSBwbGFuZSBkYXRhYmFzZSBjb21wb25lbnQgdGhyb3VnaCB0aGUg bWFuYWdlbWVudCBwbGFuZS4gVGhlDQpkYXRhYmFzZSBjb21wb25lbnQgaXMgbm90IHVzZWQgZm9y IGFueXRoaW5nIGV4Y2VwdCB0byBzYXRpc2Z5IHRoaXMNCnJlcXVpcmVtZW50IGZvciAiYXdhcmVu ZXNzIi4NCg0KQmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdyaXRlIHRoaXMgcmVxdWlyZW1l bnQgaW4gdGVybXMgb2YgYmVoYXZpb3I/DQoNCj4gUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJlbWVu dCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZSBsaXN0IHRoYXQgaXMNCj4gc3BlY2lmaWMNCj4g Zm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChUaGUgcGFpcmluZyByZXF1aXJlbWVu dHMgYXQgZW5kIHBvaW50cw0KPiBmb3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgcGF0aHMgYXJlIGV4YWN0bHkgdGhlIHNhbWUgZXZlbg0KPiBpZiB0aGV5IGFwcGVhciBp biB0d28gZGlmZmVyZW50IGl0ZW1zIGluIHRoZSByZXF1aXJlbWVudHMnIGxpc3QpLg0KPiBJbiBv dGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mIGNvLXJvdXRl ZA0KPiBiaWRpcmVjdGlvbmFsDQo+IHBhdGhzIHdvdWxkIGJlIHZvaWQgb2YgYW55IGRhdGEgcGxh bmUgY29udGVudC4NCj4NCj4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWly ZW1lbnQgKCJvdGhlciBpbnRlcm5hbCBmdW5jdGlvbnMNCj4gYXMgYXBwcm9wcmlhdGUiKSBjcmVh dGVzIGEgc3VzcGljaW9uIHRoYXQgSFcgc3VwcG9ydCBvZiB0aGUgcGFpcmluZw0KPiBhd2FyZW5l c3MNCj4gbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRvIGNvbXBseSB3aXRoIGl0Lg0KDQpUaGUg ZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBzLCBNSVBzIGFu ZCBvdGhlcg0KaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRl bGV0ZWQuIEl0IGRvZXMgbm90IGFkZCB0bw0KIlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KDQo+ IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9u Og0KPg0KPiA8cXVvdGU+DQo+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rp b24gaXMgYW4gYXJiaXRyYXJ5IHBhcnQgb2YgYQ0KPiAgIHRyYW5zcG9ydCBwYXRoIHRoYXQgY2Fu IGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5kZXBlbmRlbnRseSBmcm9tIHRoZQ0KPiAgIGVuZC10 by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gIEl0IG1heSBiZSBhIG1vbml0b3JlZCBzZWdtZW50IG9y IGENCj4gICBtb25pdG9yZWQgY29uY2F0ZW5hdGVkIHNlZ21lbnQgb2YgYSB0cmFuc3BvcnQgcGF0 aC4gIFRoZSB0YW5kZW0NCj4gICBjb25uZWN0aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndh cmRpbmcgZW5naW5lKHMpIG9mIHRoZSBub2RlKHMpDQo+ICAgYXQgdGhlIGVkZ2Uocykgb2YgdGhl IHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21lbnQuDQo+IDxlbmQgcXVvdGU+DQoNCkFjdHVh bGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQgaW5zaXN0ZW5jZSBv biB0aGUNCmluY2x1c2lvbiBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3 aXRoaW4gdGhlIElUVS1UIG9mIHRoaXMNCnRlcm0gaXMgcG9vcmx5IHNwZWNpZmllZCBhbmQgY29t ZXMgZnJvbSB0aGUgbW9uaXRvcmluZyBvZiBhIHBhdGggdGhhdCBpcw0KcGFyYWxsZWwgKGkuZS4g dGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9u IG9mDQpUQyBzZWVtcyB0byBiZSBhdCB2YXJpYW5jZSwgYW5kIHdvdWxkIGJlIGlmIHRoZSBBQ0gg d2FzIGFjdHVhbGx5IGluIGJhbmQuDQoNCj4gRG9lc24ndCAiZm9yd2FyZGluZyBlbmdpbmUiIHNv dW5kIGxpa2UgaGFyZHdhcmUgdG8geW91Pw0KDQpZZXMsIGJ1dCBzbyB3aGF0Pw0KDQo+IElNSE8g aXQgaXMgd29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUCBSZXF1aXJlbWVudHMN Cj4gZHJhZnQgbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25lDQo+IChodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVp cmVtZW50cy0wMS50eHQpDQo+IGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGgg dGFuZGVtIGNvbm5lY3Rpb25zLg0KPg0KPiBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNj dXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNIEZyYW1ld29yayBkcmFmdA0KPiAoaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcmFtZXdvcmst MDAudHh0KS4NCg0KUmlnaHQuDQpMZXQncyBqdXN0IGdldCByaWQgb2YgYW4gdW5uZWNlc3Nhcnkg dGVybSBhbmQgYnJpbmcgYWxsIHRoZSBJLURzIGludG8gbGluZS4NCg0KPiBUaGUgYm90dG9tIGxp bmUsIElNSE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZyBjby1yb3V0ZWQgdnMuDQo+ IGFzc29jaWF0ZWQNCj4gYmlkaXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25l IHdheSB0byBwcm92aWRlIHRoYXQgY291bGQgYmUgYnkNCj4gZXhwbGljaXRseQ0KPiBsaW1pdGlu ZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5Lg0KDQpBZ3JlZWQuDQoN CkFkcmlhbg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpGcm9tOiBBZHJpYW4gRmFycmVsIFthZHJpYW5Ab2xkZG9nLmNvLnVrXQ0KU2VudDogVGh1cnNk YXksIEFwcmlsIDE2LCAyMDA5IDEyOjEzIEFNDQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IExv dSBCZXJnZXI7IEJVU0kgSVRBTE8NCkNjOiBtcGxzLXRwQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJl bWVudHMNCg0KSGkgU2FzaGEsDQoNCk5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlz cmVwcmVzZW50aW5nIGFueW9uZSwgYnV0Li4uDQoNCj4gMS4gTXkgcmVhZGluZyBvZiAgb25lIG9m IEJlbidzICBtZXNzYWdlcyBpcyB0aGF0IGFzc29jaWF0ZWQNCj4gYmlkaXJlY3Rpb25hbCBwYXRo cyBhcmUgdGhlIG9ubHkgdHlwZXMgb2YgcGF0aHMgdGhhdCBjYW4gYmUNCj4gY3JlYXRlZCBpbiB0 aGUgZXhpc3RpbmcgbmV0d29ya3M7ICJ0cnVlIiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KPiBw YXRocyB3aWxsIGhhdmUgdG8gd2FpdCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVudCBiZWNv bWVzDQo+IGF2YWlsYWJsZS4NCg0KVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlIQ0KRnJvbSB0aGUg cG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcyBh cmUgYQ0Kc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KDQpJ ZiB5b3UgY2FuIHNldCB1cCB0d28gdW5pZGlyZWN0aW9uYWwgTFNQcyAoZS5nLiB1c2luZyB0aGUg bWFuYWdlbWVudCBwbGFuZSkNCnlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZCBiaWRp cmVjdGlvbmFsIExTUC4NCg0KVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGll dmUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcyB1c2luZw0KdGhlIGNvbnRyb2wgcGxhbmUu IFRoZXNlIGVpdGhlciB1c2UgdGhlIEdNUExTICh3aGljaCBpcyBjbGVhbmVyKSBvcg0Kbm9uLXN0 YW5kYXJkIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMgbWVzc3kgYnV0IGZ1bmN0aW9u YWwpLg0KDQpCdXQgKG9mIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29udHJvbCBw bGFuZSBzb2x1dGlvbnMgaGF2ZSBub3RoaW5nDQp0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBl cXVpcG1lbnQgYXMgdGhleSBhcmUgc29mdHdhcmUgc29sdXRpb25zLg0KDQo+IDIuIE15IHJlYWRp bmcgb2Ygb25lIG9mIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWwgZHJpdmVyIGZv cg0KPiBjby1yb3V0ZWQNCj4gYmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3 aXRoIGV4aXN0aW5nIHRyYW5zcG9ydCBuZXR3b3Jrcw0KPiByYXRoZXINCj4gdGhhbiBhbnkgc3Bl Y2lmaWMgYmVuZWZpdC4NCg0KSXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUgTVBM Uy1UUCByZXF1aXJlbWVudHM/DQpXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFkIHRoaW5n Lg0KDQpBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNrZXQgbmV0 d29yayB0aGUgbG9vaywgZmVlbCwgYW5kDQpiZWhhdmlvcmFsIGNoYXJhY3RlcmlzdGljcyBvZiBh ICJsZWdhY3kiIHRyYW5zcG9ydCBuZXR3b3JrLg0KDQo+IEJhc2VkIG9uIHRoZXNlIG9ic2VydmF0 aW9ucywgSSdkIGd1ZXNzIChGV0lXKSB0aGF0Og0KPiAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCBwYXRocyBhcmUsIGF0IGxlYXN0IGZvciB0aGUgdGltZQ0KPiAgICBiZWluZywgdGhlIG1vc3Qg aW1wb3J0YW50IHR5cGUgb2YgYmlkaXJlY3Rpb25hbCBwYXRocyBpbg0KPiAgICBNUExTLVRQDQoN CkkgdGhpbmsgdGhhdCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5k IGdpdmVuIHRoYXQgb3RoZXINCnVwZ3JhZGVzIHRvIGV4aXN0aW5nIE1QTFMgc29sdXRpb25zIHdp bGwgYmUgbmVlZGVkIHRvIHJlYWNoIHRoZSBmdWxsDQpmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQ Lg0KDQo+ICogdGhleSBoYWQgYSBnb29kIGNoYW5jZSB0byByZW1haW4gdGhlIG9ubHkgdHlwZSBv ZiBiaWRpcmVjdGlvbmFsDQo+ICAgcGF0aHMgaW4gIHJlYWwgZGVwbG95bWVudHMuDQoNCkkgZG9u J3Qgc2VlIHdoYXQgdGhhdCBmb2xsb3dzIGZyb20uDQoNCkNoZWVycywNCkFkcmlhbl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzLXRwIG1haWxpbmcg bGlzdA0KbXBscy10cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzLXRwDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy Lg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkg WlRFIEFudGktU3BhbSBzeXN0ZW0uDQoNCg== --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A6ILPTMAIL02eci_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Liu,

Thank you for a prompt resp= onse.

To make it clear, I did not= advocate 1:1 linear (a.k.a. end-to-end) protection for MPLS-TP. I've only = mentioned it as the only 1:1 protection scheme I've found in the MPLS-TP Su= rvivability Framework draft.

To take one step further, I= MHO and FWIW, specific protection schemes and monitoring mechanisms are not= tightly coupled, and preferably should remain so. Hence any attempt to jus= tify existence of a certain monitoring mechanism (and TCM clearly falls in the this category - it stands for = Tandem Connection Monitoring) by reference to a certain protection sch= eme would look faulty to me. And if, on top of this, the protection sc= heme in question is not even mentioned n the Survivability Framework draft... no need to continue, I think.

(Of course this does not me= an that additional protection schemes cannot appear in the MPLS-TP Survivab= ility Framework draft. On the other hand, some of the schemes now in the dr= aft may be eventually dropped or, at least, downgraded from MUST to SHOULD or MAY. But this is a different topi= c).

Last but not least, we are currently discussing MPLS-TP re= quirements, and these requirements presumably should be based on experience= of the transport operators. As some people (including myself) have noted,&= nbsp;in the two rounds of earlier discussions no transport operators have not explicitly required TCM. In thi= s (3rd!) round at least one major operator has explicitly stated that TCM i= s not needed.

Regards,

     Sa= sha

From: liu.guoman@zte.com.cn [liu.gu= oman@zte.com.cn]
Sent: Friday, April 17, 2009 6:03 AM
To: Alexander Vainshtein
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Co-routed bidirectional transport path requir= ement (was: Associated bidirectional transport path requirements)

sasha:
i don't agree your advice, i thi= nk it is necessary to consider TCM functionality and protections in MPLS-TP= survive framework.
it is complex and cost to apply end to= end protection.
thank you.
liu

Alexander Vainsht= ein <Alexander.Vainshtein@ecitele.com>
=B7=A2=BC=FE=C8=CB: mpls-tp-boun= ces@ietf.org
2009-04-16 22:32

=CA=D5=BC=FE=C8= =CB
Maarten Vissers <maarten.visser= s@huawei.com>

=B3=AD=CB=CD
"mpls-tp@ietf.org" <m= pls-tp@ietf.org>

=D6=F7=CC=E2
Re: [mpls-tp] Co-routed bidirectio= nal transport path requirement (was: Associated bidirectional transport pat= h requirements)

Maarten,
I've scanned the MPLS-TP Survivab= ility Framework draft (http://www.ietf.org/internet-dr= afts/draft-ietf-mpls-tp-survive-fwk-00.txt) but did not find there any requirements for 1:1 SNC protection (inde= ed, the term SNC is not mentioned in this document).

And AFAIK 1:1 linear protection (= which is mentioned in the draft) does not require any TCM functionality.

If the functionality you have in = mind is called by any other name in the MPLS-TP Survivability Framework , i= t would be nice if you could provide an appropriate mapping. If not, let us= not use it as a justification for additional OAM functionality like TCM.

Regards,
Sasha =

From: Maarten Vissers [maarten.viss= ers@huawei.com]
Sent: Thursday, April 16, 2009 3:29 PM
To: Alexander Vainshtein
Cc: mpls-tp@ietf.org
Subject: RE: [mpls-tp] Co-routed bidirectional transport path requireme= nt (was: Associated bidirectional transport path requirements)

Sasha,

I do not agree with you nor = Adrian in this matter as explained in my response to Adrian's email a few m= inutes ago.

One of the applications that= would not longer be able to function would be 1:1 PW SNC protection or 1:1= LSP SNC protection. For those protection mechanisms we need TCM MEP functi= ons to determine the status of each SNC.

Regards,
Maarten

From: mpls-tp-bounces@ietf.org [mai= lto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: donderdag 16 april 2009 13:40
To: Adrian Farrel
Cc: BUSI@core3.amsl.com; ITALO; mpls-tp@ietf.org
Subject: [mpls-tp] Co-routed bidirectional transport path requirement (= was: Associated bidirectional transport path requirements)

Adrian,
Looks as we are much more in agreement than= it could be guessed from the first round of exchanges.
I've changed the s= ubject since we are actually discussing specifics of co-routed bidirectiona= l paths.

I fully support yo= ur proposal to get rid (in a consistent manner) from the TC stuff in MPLS-T= P, especially since, to the best of my knowledge, operational experience wi= th SONET/SDH TCM (ITU-T definitions notwithstanding) did not prove its worth. If this is based on mis-perception, I would be gl= ad to hear that (especially from the operators on this list).

And if it is possi= ble to re-write Requirement 34 as a functional/behavior requirement, it wou= ld be great, too.
However, I am not = sure this would be easy (Ben, my apologies again).

Regards, &nbs= p;Sasha

________________________________________
From: Adrian Farrel [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 12:59 PM
To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com
Cc: mpls-tp@ietf.org; Lou Berger; BUSI ITALO
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements=

Hi Sasha,

> Unfortunately I cannot fully agree with your statement:
>
> <quote>
> From the point of view of hardware, co-routed bidirectio= nal LSPs
> are a special case of associated bidirectional LSPs.
> <end quote>
>
> This statement would be obviously correct, were it not for Requirement= 34
> in the latest
> MPLS-TP requirements draft

OK. Got it.

But what is this doing in the data plane requirements section?

In fact, what is this requirement actually saying?

> <quote>
> The intermediate nodes (including MEPs, MIPs and o= ther internal
> functions as appropriate) of a co-routed bidirect= ional transport
> path at each (sub-)layer MUST be aware of the pai= ring
> relationship of the forward and the backward dire= ctions of that
> transport path.
> <end quote>

There is no way this is a functional requirement. That is, there is
*nothing* that can be observed from a black box point of view that results<= br> from adhering to this requirement.

Therefore it could be assumed that this requirement is met by configuring some data plane database component through the management plane. The
database component is not used for anything except to satisfy this
requirement for "awareness".

Ben! Can we please try to rewrite this requirement in terms of behavior?
> Please note that Requirement 34 is the ONLY item in the list that is > specific
> for co-routed bidirectional LSPs. (The pairing requirements at end poi= nts
> for co-routed and associated bidirectional paths are exactly the same = even
> if they appear in two different items in the requirements' list).
> In other words, without Requirement 34 the notion of co-routed
> bidirectional
> paths would be void of any data plane content.
>
> The somewhat vague scope of this requirement ("other internal fun= ctions
> as appropriate") creates a suspicion that HW support of the pairi= ng
> awareness
> may be required in order to comply with it.

The entirety of the bracketted text "(including MEPs, MIPs and other internal functions as appropriate)" should be deleted. It does not add= to
"The intermediate nodes."

> The following text in the draft increases this suspicion:
>
> <quote>
> Tandem Connection: A tandem connection is an arbitrary part of = a
> transport path that can be monitored (via OAM) independently fr= om the
> end-to-end monitoring (OAM). It may be a monitored segmen= t or a
> monitored concatenated segment of a transport path. The t= andem
> connection may also include the forwarding engine(s) of the nod= e(s)
> at the edge(s) of the segment or concatenated segment.
> <end quote>

Actually, I am quite fed up about this persistent insistence on the
inclusion of "Tandem Connection." The definition within the ITU-T= of this
term is poorly specified and comes from the monitoring of a path that is parallel (i.e. tandem) to the data path being monitored. This definition of=
TC seems to be at variance, and would be if the ACH was actually in band.
> Doesn't "forwarding engine" sound like hardware to you?

Yes, but so what?

> IMHO it is worth noting that neither the MPLS-TP Requirements
> draft nor the MPLS-TP OAM requirements one
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen= ts-01.txt)
> contain any requirements dealing with tandem connections.
>
> But tandem connections are discussed in the MPLS-TP OAM Framework draf= t
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-= 00.txt).

Right.
Let's just get rid of an unnecessary term and bring all the I-Ds into line.=

> The bottom line, IMHO, is that some clarity regarding co-routed vs. > associated
> bidirectional paths is still required. One way to provide that could b= e by
> explicitly
> limiting Requirement 34 to specific functionality.

Agreed.

Adrian

________________________________________
From: Adrian Farrel [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 12:13 AM
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements=

Hi Sasha,

Not really sure whether you are misrepresenting anyone, but...

> 1. My reading of one of Ben's messages is that associated<= br> > bidirectional paths are the only types of paths that can be
> created in the existing networks; "true" co-routed bidirecti= onal
> paths will have to wait until (if ever) new equipment becomes
> available.

This is clearly nonsense!
>From the point of view of hardware, co-routed bidirectional LSPs are a
special case of associated bidirectional LSPs.

If you can set up two unidirectional LSPs (e.g. using the management plane)=
you can surely set up a co-routed bidirectional LSP.

There are shipping solutions that achieve co-routed bidirectional LSPs usin= g
the control plane. These either use the GMPLS (which is cleaner) or
non-standard proprietary solutions (which is messy but functional).

But (of course) the management plane or control plane solutions have nothin= g
to do with availability of equipment as they are software solutions.

> 2. My reading of one of Neil's messages is that the actual driver for<= br> > co-routed
> bidirectional paths may be experience with existing transport networks=
> rather
> than any specific benefit.

Isn't that the case with 75% of the MPLS-TP requirements?
Which is not to say it is a bad thing.

A large driver for MPLS-TP is to give the packet network the look, feel, an= d
behavioral characteristics of a "legacy" transport network.

> Based on these observations, I'd guess (FWIW) that:
> * associated bidirectional paths are, at least for the time
> being, the most important type of bidirectional paths in<= br> > MPLS-TP

I think that is wrong both given my statement above, and given that other upgrades to existing MPLS solutions will be needed to reach the full
function level of MPLS-TP.

> * they had a good chance to remain the only type of bidirectional
> paths in real deployments.

I don't see what that follows from.

Cheers,
Adrian_________________________________________= ______ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp

-------------------------------------------------------- ZTE Information Security Notice: The information&n= bsp;contained in this mail is solely property= of the sender's organization. This mail = ;communication is confidential. Recipients named a= bove are obligated to maintain secrecy and&nb= sp;are not permitted to disclose the contents= of this communication to others. This email and any files transmitted with&nbs= p;it are confidential and intended solely for= the use of the individual or entity&nbs= p;to whom they are addressed. If you hav= e received this email in error please no= tify the originator of the message. Any = views expressed in this message are those&nbs= p;of the individual sender. This message has been scanned for viruses&nbs= p;and Spam by ZTE Anti-Spam system.

--_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90A6ILPTMAIL02eci_-- From Italo.Busi@alcatel-lucent.it Fri Apr 17 01:02:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29B33A69C3 for ; Fri, 17 Apr 2009 01:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.969 X-Spam-Level: X-Spam-Status: No, score=-5.969 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwZAvq0+SoOE for ; Fri, 17 Apr 2009 01:02:13 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 842FA3A6821 for ; Fri, 17 Apr 2009 01:02:13 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H83FRN028550; Fri, 17 Apr 2009 10:03:15 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:03:15 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Apr 2009 10:03:12 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1821@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] Thread-Index: Acm+tJuOTknZdff0ik2hm8OGNyx6+gAfkNMg References: <8E1BB972CF3B4CAD83881CAD192D6BD8@your029b8cecfe> From: "BUSI ITALO" To: "Ben Niven-Jenkins" , "Adrian Farrel" , "Maarten Vissers" X-OriginalArrivalTime: 17 Apr 2009 08:03:15.0395 (UTC) FILETIME=[F60AE930:01C9BF32] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:02:14 -0000 Ben, For me the proposal from Adrian (i.e. removing the text within brackets) is fine. Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: Thursday, April 16, 2009 6:59 PM > To: Adrian Farrel; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated=20 > bidirectional transport path requirements] >=20 > Adrian, >=20 > On 16/04/2009 13:48, "Adrian Farrel" wrote: > > The original text reads... > >=20 > > The intermediate nodes (including MEPs, MIPs and=20 > other internal > > functions as appropriate) of a co-routed=20 > bidirectional transport > > path > >=20 > > Since MEPs, MIPs and other internal functions are just examples of > > intermediate nodes, the sentence loses nothing if it reads > >=20 > > The intermediate nodes of a co-routed bidirectional transport > > path > >=20 > > Furthermore, *any* text that reaches me as AD including "as=20 > appropriate" is > > highly likely to be turned around. If the authors do not=20 > know what they mean > > and have used the phrase to avoid working it out, then it=20 > needs to be fixed. > > If the authors do know what they mean, they should say it. >=20 > "as appropriate" is because I wrote the text of the=20 > requirement based on > asks for it to be a requirement from others and I didn't=20 > entirely know what > was being asked for so I took an educated guess. >=20 > What I was trying to do was highlight some of the functions=20 > in a node that > may make use of such information to try and add clarity as to=20 > how it may be > used. I have no problem removing the text if it doesn't add=20 > that clarity and > just leave as "The intermediate nodes of a co-routed..." >=20 > If other participants want the text kept then they need to propose > alternative text that is acceptable to our ADs as the current=20 > text is the > best I can come up with on my own. >=20 > Ben >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 01:21:10 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70F83A6D4E for ; Fri, 17 Apr 2009 01:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daCsQFbwtk8B for ; Fri, 17 Apr 2009 01:21:10 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 798233A6B39 for ; Fri, 17 Apr 2009 01:21:06 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H8KAto012695; Fri, 17 Apr 2009 10:20:11 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:20:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Apr 2009 10:20:09 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1830@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <51661468CBD1354294533DA79E85955A01A6BB14@XCH-SW-5V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAAAhgIIAA8nGw References: <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> <51661468CBD1354294533DA79E85955A01A6BB14@XCH-SW-5V2.sw.nos.boeing.com> From: "BUSI ITALO" To: "Drake, John E" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Ben Niven-Jenkins" , "Alexander Vainshtein" , "Adrian Farrel" X-OriginalArrivalTime: 17 Apr 2009 08:20:10.0854 (UTC) FILETIME=[534DA860:01C9BF35] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:21:10 -0000 John, There is a 1:1 relationship between a TCM instance and the LSP it is monitoring. I have never agreed to generalize it into a 1:N relationship. Italo > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Sent: Thursday, April 16, 2009 7:55 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ben=20 > Niven-Jenkins; Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Requirement for TCM or not. >=20 > Nurit, >=20 > As I recall, there is a 1:1 relationship between a TCM=20 > instance and the > LSP it is monitoring. I thought we had agreed (a long time ago) to > generalize this into a 1:N capability, and hence TCM became PST. >=20 > Thanks, >=20 > John=20 >=20 > > -----Original Message----- > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > > [mailto:nurit.sprecher@nsn.com]=20 > > Sent: Thursday, April 16, 2009 10:25 AM > > To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Requirement for TCM or not. > >=20 > > Hi, > > TC is a solution to the requirement to manage, monitor and=20 > > protect the network at different nested levels. > > The work on MPLS-TP started with this basic requirement that=20 > > came from the ITU-T.=20 > > I think we should continue and address this requirement as=20 > > our commitment to the ITU-T.=20 > > About the solution, there is room for discussion. Is it TC,=20 > > PST or something else? As promised I'll provide next week=20 > > some text about this. > >=20 > > Best regards, > > Nurit > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins > > Sent: Thursday, April 16, 2009 7:54 PM > > To: Alexander Vainshtein; Adrian Farrel > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: [mpls-tp] Requirement for TCM or not. > >=20 > > On 16/04/2009 12:39, "Alexander Vainshtein" > > > I fully support your proposal to get rid (in a consistent=20 > > manner) from > > the TC > > > stuff in MPLS-TP, especially since, to the best of my knowledge, > > operational > > > experience with SONET/SDH TCM (ITU-T definitions=20 > > notwithstanding) did > > not > > > prove its worth. If this is based on mis-perception, I=20 > would be glad > > to hear > > > that (especially from the operators on this list). > >=20 > > BT has no requirement for TCM. We do not have it deployed in=20 > > our TDM networks today and have no current plans to use it in=20 > > any of our networks in the future. > >=20 > > Ben > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 01:23:39 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3483A6EAE for ; Fri, 17 Apr 2009 01:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.984 X-Spam-Level: X-Spam-Status: No, score=-3.984 tagged_above=-999 required=5 tests=[AWL=-1.735, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7mBQrpGc5eD for ; Fri, 17 Apr 2009 01:23:38 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 3A0F43A6E96 for ; Fri, 17 Apr 2009 01:23:38 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H8MgFc017705; Fri, 17 Apr 2009 10:22:46 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:22:40 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Apr 2009 10:22:39 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1834@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326490D7B1@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgADOSIA= References: , <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A5326490D7B1@DEMUEXC014.nsn-intra.net> From: "BUSI ITALO" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Alexander Vainshtein" X-OriginalArrivalTime: 17 Apr 2009 08:22:40.0300 (UTC) FILETIME=[AC614EC0:01C9BF35] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:23:39 -0000 I am in full agreement with Nurit Italo=20 > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > [mailto:nurit.sprecher@nsn.com]=20 > Sent: Thursday, April 16, 2009 10:06 PM > To: ext Alexander Vainshtein > Cc: BUSI ITALO; mpls-tp@ietf.org; ext Ben Niven-Jenkins;=20 > Adrian Farrel; neil.2.harrison@bt.com > Subject: RE: [mpls-tp] Requirement for TCM or not. >=20 > Sasha, > I absolutely agree with your second point. > Regarding the first one, it was agreed that the MPLS-TP addresses the > transport requirements of the ITU-T and additional requirements from > SPs.=20 > This was one of the first set of requirements the ITU-T brought to the > work and we need to address it. > Best regards, > Nurit >=20 > -----Original Message----- > From: ext Alexander Vainshtein=20 > [mailto:Alexander.Vainshtein@ecitele.com] >=20 > Sent: Thursday, April 16, 2009 10:49 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: BUSI ITALO; mpls-tp@ietf.org; ext Ben Niven-Jenkins;=20 > Adrian Farrel; > neil.2.harrison@bt.com > Subject: RE: [mpls-tp] Requirement for TCM or not. >=20 > Nurit hi, > Two comments: >=20 > 1. As I see it, the actual operational need to monitor network at > different nested levels is, at the very least, > arguable (Neil explains this much better that I can ever=20 > can hope). >=20 > 2. We should understand and agree upon the requirement first and then > look for the suitable solution, not the > the other way round.=20 >=20 > Regards, > Sasha >=20 > ________________________________________ > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [nurit.sprecher@nsn.com] > Sent: Thursday, April 16, 2009 8:25 PM > To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Requirement for TCM or not. >=20 > Hi, > TC is a solution to the requirement to manage, monitor and protect the > network at different nested levels. > The work on MPLS-TP started with this basic requirement that came from > the ITU-T. > I think we should continue and address this requirement as our > commitment to the ITU-T. > About the solution, there is room for discussion. Is it TC, PST or > something else? As promised I'll provide next week some text=20 > about this. >=20 > Best regards, > Nurit >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of ext Ben Niven-Jenkins > Sent: Thursday, April 16, 2009 7:54 PM > To: Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: [mpls-tp] Requirement for TCM or not. >=20 > On 16/04/2009 12:39, "Alexander Vainshtein" > > I fully support your proposal to get rid (in a consistent=20 > manner) from > the TC > > stuff in MPLS-TP, especially since, to the best of my knowledge, > operational > > experience with SONET/SDH TCM (ITU-T definitions=20 > notwithstanding) did > not > > prove its worth. If this is based on mis-perception, I would be glad > to hear > > that (especially from the operators on this list). >=20 > BT has no requirement for TCM. We do not have it deployed in our TDM > networks today and have no current plans to use it in any of our > networks in > the future. >=20 > Ben >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 01:35:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71983A696B for ; Fri, 17 Apr 2009 01:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1fz+PfYqS4M for ; Fri, 17 Apr 2009 01:35:00 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id C32A83A692D for ; Fri, 17 Apr 2009 01:34:59 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H8Y5Ud016784; Fri, 17 Apr 2009 10:34:05 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:34:05 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Apr 2009 10:34:04 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1844@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tandem Connections in MPLS-TP (was RE: [mpls-tp] Associated bidirectional transport path requirements) Thread-Index: Acm+e9jj1HoQiXHcQhKAYvhbYuJx6wAKYxBAABXawM0ADoZp4A== References: <6FD21B53861BF44AA90A288402036AB4021B172F@FRVELSMBS21.ad2.ad.alcatel.com> From: "BUSI ITALO" To: "Ben Niven-Jenkins" , "Adrian Farrel" , "Alexander Vainshtein" X-OriginalArrivalTime: 17 Apr 2009 08:34:05.0664 (UTC) FILETIME=[44E38E00:01C9BF37] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:35:01 -0000 Ben, The JWT agreement is to bring the ITU-T transport requirements in IETF to extend the MPLS architecture to meet them in a way that is compatible, consistent and coherent with existing IETF architecture. We have never agreed to evaluate which requirement has to be meet and which has not. The expectation is that all the ITU-T requirements will be met. Italo > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Friday, April 17, 2009 3:36 AM > To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > Cc: mpls-tp@ietf.org; Lou Berger > Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp]=20 > Associated bidirectional transport path requirements) >=20 > Italo, >=20 > In turn I am a little worried by your statement. >=20 > On 16/04/2009 16:24, "BUSI ITALO"=20 > wrote: > > I am a little bit worried by our statement: > >=20 > >> Actually, I am quite fed up about this persistent insistence on the > >> inclusion of "Tandem Connection." The definition within the > >> ITU-T of this=20 > >> term is poorly specified and comes from the monitoring of a > >> path that is=20 > >> parallel (i.e. tandem) to the data path being monitored. This > >> definition of=20 > >> TC seems to be at variance, and would be if the ACH was > >> actually in band. > >=20 > > This is a strong requirement for transport networks and ITU-T has > > clearly communicated this to IETF during the JWT analysis. > >=20 > > We will be very persistent in maintaining what has been=20 > agreed by the > > JWT. >=20 > While our aim is to follow the JWT agreement I do not think we should > blindly follow it because it was agreed by the JWT. As our=20 > understanding of > MPLS-TP and its requirements evolves so it may be that some=20 > things agreed by > the JWT are no longer relevant. >=20 > Remember when the JWT made its agreement the requirements for=20 > T-MPLS/MPLS-TP > were in general poorly specified and therefore I have to assume some > assumptions had to be made. With all assumptions there is=20 > risk that although > they were the best available assumption at the time that=20 > subsequently they > are shown to be incorrect. >=20 > So, IMO, something is not a requirement because the JWT=20 > agreed it. It is a > requirement because operators require it. >=20 > If operators require it then fine, but I have yet to hear an=20 > operator state > publicly either in ITU or IETF that they require TCM in MPLS-TP. >=20 > Like I said earlier tonight I know not all operators participate in > standards but if just one operator were to step forward and=20 > say they require > TCM it would put an end to this debate. >=20 > Ben >=20 >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 01:43:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474553A6D4A for ; Fri, 17 Apr 2009 01:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[AWL=-1.698, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhKEiibd3v2q for ; Fri, 17 Apr 2009 01:42:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 097DB3A6ADF for ; Fri, 17 Apr 2009 01:42:58 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H8hoin025289; Fri, 17 Apr 2009 10:43:51 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:43:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 10:43:49 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B184D@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgAAEgtWAAM0zYA== References: <077E41CFFD002C4CAB7DFA4386A5326490D7B1@DEMUEXC014.nsn-intra.net> From: "BUSI ITALO" To: "Ben Niven-Jenkins" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Alexander Vainshtein" X-OriginalArrivalTime: 17 Apr 2009 08:43:50.0914 (UTC) FILETIME=[A1B99E20:01C9BF38] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:43:00 -0000 Hi all, I am sorry to repeat myself, but it seems that we are all repeating the debate we already had in the past. It is therefore important that I remind everybody that the requirement for TCM is not motivate by its existence in SONET/SDH. Actually, the TCM function was added to SONET/SDH quite late in its development on the basis of transport operators requirements. Because of its late introduction, the SONET/SDH TCM design has some limitations (e.g. the lack of nesting TCM) that has limited its applicability. This is the main reason why TCM was not widespread deployed with SONET/SDH, although some deployments actually exist. I think that we are continuing to ignore that SONET/SDH is not the only transport technology defined by ITU-T. After having realized the issues with SONET/SDH TCM design, all the subsequent OAM designs from ITU-T has taken seriously into account the TCM requirements, including the nesting: look for example at OTN and Ethernet OAM designs. Italo > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Thursday, April 16, 2009 10:20 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein > Cc: BUSI ITALO; mpls-tp@ietf.org; Adrian Farrel;=20 > neil.2.harrison@bt.com > Subject: Re: [mpls-tp] Requirement for TCM or not. >=20 > Colleagues, >=20 > On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > Regarding the first one, it was agreed that the MPLS-TP=20 > addresses the > > transport requirements of the ITU-T and additional requirements from > > SPs.=20 > > This was one of the first set of requirements the ITU-T=20 > brought to the > > work and we need to address it. >=20 > This does raise a question in my mind that goes back to=20 > something I have > said before. Is TCM a requirement because it is a real=20 > requirement that > operators are asking for or because we are recreating SDH/SONET > functionality blindly without considering its relevance in=20 > the world we now > live in? >=20 > I appreciate that there are many operators who do not participate in > standards, however it would be most useful if just one=20 > operator who requires > TCM were to step forward and say so. >=20 > I am not a TDM expert but what my TDM experts tell me is that=20 > TCM has been > deployed in the past by some operators (I have no idea of its=20 > current state > of deployment except in BT) but that its use in the past can=20 > be considered > (in their opinion) to be in the minority of deployments. >=20 > I do wonder if we are therefore expending a lot of energy=20 > (and later on time > both in standardisation and possibly development effort) for=20 > a function that > may be seldom, if ever, used. It won't be the first time we have > standardised something that is seldom, if ever, used but we do have an > opportunity now to take a step back and consider: is TCM=20 > really required and > if it is required, is it a priority in the development of MPLS-TP? >=20 > Ben >=20 >=20 >=20 From annamaria.fulignoli@ericsson.com Fri Apr 17 01:51:50 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64573A68AC for ; Fri, 17 Apr 2009 01:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.068 X-Spam-Level: X-Spam-Status: No, score=-5.068 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOVL97j3pkMu for ; Fri, 17 Apr 2009 01:51:48 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 07C693A6841 for ; Fri, 17 Apr 2009 01:51:47 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 12A6420964; Fri, 17 Apr 2009 10:53:00 +0200 (CEST) X-AuditID: c1b4fb3c-affd5bb00000238f-ee-49e8436b23f9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D2A6A20D89; Fri, 17 Apr 2009 10:52:59 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:52:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF39.C8728BC2" Date: Fri, 17 Apr 2009 10:51:59 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F9403953A74@esealmw118.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) Thread-Index: Acm/CXQUeye1hYvUSamfcDuyJtuRRQAKIQdQ References: From: "Annamaria Fulignoli" To: , "Alexander Vainshtein" , X-OriginalArrivalTime: 17 Apr 2009 08:52:05.0905 (UTC) FILETIME=[C8C34010:01C9BF39] X-Brightmail-Tracker: AAAAAA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:51:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF39.C8728BC2 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hi Sasha ,=20 I agree with Maarten and Liu. =20 Co-routed bidirectional path as well as TCM functionality are basic = requirement in transport network =20 If we think that these requirements are not clearly specified in mpls-tp = documents than we must better address them . =20 =20 Regards Annamaria=20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: venerd=A8=AC 17 aprile 2009 5.04 To: Alexander Vainshtein Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Co-routed bidirectional transport path = requirement (was: Associated bidirectional transport path requirements) sasha:=20 i don't agree your advice, i think it is necessary to consider TCM = functionality and protections in MPLS-TP survive framework.=20 it is complex and cost to apply end to end protection.=20 thank you.=20 liu=20 Alexander Vainshtein =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-16 22:32=20 =CA=D5=BC=FE=C8=CB Maarten Vissers =20 =B3=AD=CB=CD "mpls-tp@ietf.org" =20 =D6=F7=CC=E2 Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: = Associated bidirectional transport path requirements) =09 Maarten,=20 I've scanned the MPLS-TP Survivability Framework draft = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-00.tx= t = ) but did not find there any requirements for 1:1 SNC protection = (indeed, the term SNC is not mentioned in this document).=20 =20 And AFAIK 1:1 linear protection (which is mentioned in the draft) does = not require any TCM functionality.=20 =20 If the functionality you have in mind is called by any other name in the = MPLS-TP Survivability Framework , it would be nice if you could provide = an appropriate mapping. If not, let us not use it as a justification for = additional OAM functionality like TCM.=20 =20 Regards,=20 Sasha=20 =20 =20 =20 =20 =20 =20 ________________________________ From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Thursday, April 16, 2009 3:29 PM To: Alexander Vainshtein Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Co-routed bidirectional transport path = requirement (was: Associated bidirectional transport path requirements) Sasha,=20 =20 I do not agree with you nor Adrian in this matter as explained in my = response to Adrian's email a few minutes ago.=20 =20 One of the applications that would not longer be able to function would = be 1:1 PW SNC protection or 1:1 LSP SNC protection. For those protection = mechanisms we need TCM MEP functions to determine the status of each = SNC.=20 =20 Regards,=20 Maarten=20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Alexander Vainshtein Sent: donderdag 16 april 2009 13:40 To: Adrian Farrel Cc: BUSI@core3.amsl.com; ITALO; mpls-tp@ietf.org Subject: [mpls-tp] Co-routed bidirectional transport path requirement = (was: Associated bidirectional transport path requirements) Adrian,=20 Looks as we are much more in agreement than it could be guessed from the = first round of exchanges.=20 I've changed the subject since we are actually discussing specifics of = co-routed bidirectional paths.=20 =20 I fully support your proposal to get rid (in a consistent manner) from = the TC stuff in MPLS-TP, especially since, to the best of my knowledge, = operational experience with SONET/SDH TCM (ITU-T definitions = notwithstanding) did not prove its worth. If this is based on = mis-perception, I would be glad to hear that (especially from the = operators on this list).=20 =20 And if it is possible to re-write Requirement 34 as a = functional/behavior requirement, it would be great, too.=20 However, I am not sure this would be easy (Ben, my apologies again).=20 =20 Regards,=20 Sasha=20 =20 =20 =20 ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Thursday, April 16, 2009 12:59 PM To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com Cc: mpls-tp@ietf.org; Lou Berger; BUSI ITALO Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Hi Sasha, > Unfortunately I cannot fully agree with your statement: > > > From the point of view of hardware, co-routed bidirectional LSPs > are a special case of associated bidirectional LSPs. > > > This statement would be obviously correct, were it not for Requirement = 34 > in the latest > MPLS-TP requirements draft OK. Got it. But what is this doing in the data plane requirements section? In fact, what is this requirement actually saying? > > The intermediate nodes (including MEPs, MIPs and other internal > functions as appropriate) of a co-routed bidirectional transport > path at each (sub-)layer MUST be aware of the pairing > relationship of the forward and the backward directions of that > transport path. > There is no way this is a functional requirement. That is, there is *nothing* that can be observed from a black box point of view that = results from adhering to this requirement. Therefore it could be assumed that this requirement is met by = configuring some data plane database component through the management plane. The database component is not used for anything except to satisfy this requirement for "awareness". Ben! Can we please try to rewrite this requirement in terms of behavior? > Please note that Requirement 34 is the ONLY item in the list that is > specific > for co-routed bidirectional LSPs. (The pairing requirements at end = points > for co-routed and associated bidirectional paths are exactly the same = even > if they appear in two different items in the requirements' list). > In other words, without Requirement 34 the notion of co-routed > bidirectional > paths would be void of any data plane content. > > The somewhat vague scope of this requirement ("other internal = functions > as appropriate") creates a suspicion that HW support of the pairing > awareness > may be required in order to comply with it. The entirety of the bracketted text "(including MEPs, MIPs and other internal functions as appropriate)" should be deleted. It does not add = to "The intermediate nodes." > The following text in the draft increases this suspicion: > > > Tandem Connection: A tandem connection is an arbitrary part of a > transport path that can be monitored (via OAM) independently from = the > end-to-end monitoring (OAM). It may be a monitored segment or a > monitored concatenated segment of a transport path. The tandem > connection may also include the forwarding engine(s) of the node(s) > at the edge(s) of the segment or concatenated segment. > Actually, I am quite fed up about this persistent insistence on the inclusion of "Tandem Connection." The definition within the ITU-T of = this term is poorly specified and comes from the monitoring of a path that is parallel (i.e. tandem) to the data path being monitored. This definition = of TC seems to be at variance, and would be if the ACH was actually in = band. > Doesn't "forwarding engine" sound like hardware to you? Yes, but so what? > IMHO it is worth noting that neither the MPLS-TP Requirements > draft nor the MPLS-TP OAM requirements one > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-= 01.txt) > contain any requirements dealing with tandem connections. > > But tandem connections are discussed in the MPLS-TP OAM Framework = draft > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.= txt). Right. Let's just get rid of an unnecessary term and bring all the I-Ds into = line. > The bottom line, IMHO, is that some clarity regarding co-routed vs. > associated > bidirectional paths is still required. One way to provide that could = be by > explicitly > limiting Requirement 34 to specific functionality. Agreed. Adrian ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Thursday, April 16, 2009 12:13 AM To: Alexander Vainshtein; Lou Berger; BUSI ITALO Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Hi Sasha, Not really sure whether you are misrepresenting anyone, but... > 1. My reading of one of Ben's messages is that associated > bidirectional paths are the only types of paths that can be > created in the existing networks; "true" co-routed bidirectional > paths will have to wait until (if ever) new equipment becomes > available. This is clearly nonsense! >From the point of view of hardware, co-routed bidirectional LSPs are a special case of associated bidirectional LSPs. If you can set up two unidirectional LSPs (e.g. using the management = plane) you can surely set up a co-routed bidirectional LSP. There are shipping solutions that achieve co-routed bidirectional LSPs = using the control plane. These either use the GMPLS (which is cleaner) or non-standard proprietary solutions (which is messy but functional). But (of course) the management plane or control plane solutions have = nothing to do with availability of equipment as they are software solutions. > 2. My reading of one of Neil's messages is that the actual driver for > co-routed > bidirectional paths may be experience with existing transport networks > rather > than any specific benefit. Isn't that the case with 75% of the MPLS-TP requirements? Which is not to say it is a bad thing. A large driver for MPLS-TP is to give the packet network the look, feel, = and behavioral characteristics of a "legacy" transport network. > Based on these observations, I'd guess (FWIW) that: > * associated bidirectional paths are, at least for the time > being, the most important type of bidirectional paths in > MPLS-TP I think that is wrong both given my statement above, and given that = other upgrades to existing MPLS solutions will be needed to reach the full function level of MPLS-TP. > * they had a good chance to remain the only type of bidirectional > paths in real deployments. I don't see what that follows from. Cheers, Adrian_______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9BF39.C8728BC2 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Hi=20 Sasha ,

I agree = with Maarten and=20 Liu.

Co-routed bidirectional path  as well as TCM = functionality are basic = requirement in=20 transport network

If we think that these requirements = are not clearly=20 specified in mpls-tp documents than we must better address them=20 .

Regards

Annamaria

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn
Sent: venerd=A8=AC 17 aprile 2009=20 5.04
To: Alexander Vainshtein
Cc:=20 mpls-tp@ietf.org
Subject: Re: [mpls-tp] Co-routed = bidirectional=20 transport path requirement (was: Associated bidirectional transport path = requirements)

sasha:
i don't agree your advice, i think it = is necessary=20 to consider TCM functionality and protections in MPLS-TP survive=20 framework.
it is complex and = cost to=20 apply end to end protection.
thank=20 you.
liu

Alexander = Vainshtein=20 <Alexander.Vainshtein@ecitele.com>
=B7=A2=BC=FE=C8=CB: = mpls-tp-bounces@ietf.org=20
2009-04-16 22:32

=CA=D5=BC=FE=C8=CB
Maarten Vissers=20 <maarten.vissers@huawei.com>=20

=B3=AD=CB=CD
"mpls-tp@ietf.org"=20 <mpls-tp@ietf.org>=20

=D6=F7=CC=E2
Re: [mpls-tp] Co-routed=20 bidirectional transport path requirement (was: Associated=20 bidirectional transport path = requirements)

=

Maarten,
I've scanned the MPLS-TP Survivability Framework draft = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-surviv= e-fwk-00.txt) but did not find there any = requirements for=20 1:1 SNC protection (indeed, the term SNC is not mentioned in this=20 document).

And AFAIK 1:1 linear protection (which = is=20 mentioned in the draft) does not require any TCM functionality. =

If = the=20 functionality you have in mind is called by any other name in the = MPLS-TP=20 Survivability Framework , it would be nice if you could provide an = appropriate=20 mapping. If not, let us not use it as a justification for additional OAM = functionality like TCM.
=
Regards,
Sasha

From: Maarten Vissers=20 [maarten.vissers@huawei.com]
Sent: Thursday, April 16, 2009 = 3:29=20 PM
To: Alexander Vainshtein
Cc:=20 mpls-tp@ietf.org
Subject: RE: [mpls-tp] Co-routed = bidirectional=20 transport path requirement (was: Associated bidirectional transport path = requirements)

Sasha,

I do not agree with you nor Adrian in this matter = as explained=20 in my response to Adrian's email a few minutes ago.

One = of the=20 applications that would not longer be able to function would be 1:1 PW = SNC=20 protection or 1:1 LSP SNC protection. For those protection mechanisms we = need=20 TCM MEP functions to determine the status of each SNC.

Regards,=20
Maarten

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: donderdag 16 april 2009 13:40
To: = Adrian=20 Farrel
Cc: BUSI@core3.amsl.com; ITALO;=20 mpls-tp@ietf.org
Subject: [mpls-tp] Co-routed bidirectional = transport=20 path requirement (was: Associated bidirectional transport path=20 requirements)

Adrian,
Looks as we are = much more in=20 agreement than it could be guessed from the first round of = exchanges.=20
I've changed = the subject=20 since we are actually discussing specifics of co-routed bidirectional=20 paths.

I fully support your proposal to get rid (in a = consistent=20 manner) from the TC stuff in MPLS-TP, especially since, to the best of = my=20 knowledge, operational experience with SONET/SDH TCM (ITU-T definitions=20 notwithstanding) did not prove its worth. If this is based on = mis-perception, I=20 would be glad to hear that (especially from the operators on this = list).=20

And if it is possible to re-write Requirement 34 as a = functional/behavior=20 requirement, it would be great, too.
However, I am not sure this would be easy (Ben, my = apologies=20 again).

Regards,
Sasha

________________________________________
From: Adrian = Farrel=20 [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 12:59 PM
To:=20 Alexander Vainshtein; benjamin.niven-jenkins@bt.com
Cc: = mpls-tp@ietf.org; Lou=20 Berger; BUSI ITALO
Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements

Hi Sasha,

> Unfortunately I cannot = fully=20 agree with your statement:
>
> <quote>
> = =20 >From the point of view of hardware, co-routed bidirectional LSPs
> = =20 are a special case of associated bidirectional LSPs.
> = <end=20 quote>
>
> This statement would be obviously correct, = were it not=20 for Requirement 34
> in the latest
> MPLS-TP requirements=20 draft

OK. Got it.

But what is this doing in the data plane = requirements section?

In fact, what is this requirement actually=20 saying?

> <quote>
> The = intermediate=20 nodes (including MEPs, MIPs and other internal
> = =20 functions as appropriate) of a co-routed bidirectional transport
> = =20 path at each (sub-)layer MUST be aware of the = pairing
>=20 relationship of the forward and the backward = directions of=20 that
> transport path.
> <end=20 quote>

There is no way this is a functional requirement. That = is,=20 there is
*nothing* that can be observed from a black box point of = view that=20 results
from adhering to this requirement.

Therefore it could = be=20 assumed that this requirement is met by configuring
some data plane = database=20 component through the management plane. The
database component is not = used=20 for anything except to satisfy this
requirement for = "awareness".

Ben!=20 Can we please try to rewrite this requirement in terms of = behavior?

>=20 Please note that Requirement 34 is the ONLY item in the list that = is
>=20 specific
> for co-routed bidirectional LSPs. (The pairing = requirements at=20 end points
> for co-routed and associated bidirectional paths are = exactly=20 the same even
> if they appear in two different items in the = requirements'=20 list).
> In other words, without Requirement 34 the notion of=20 co-routed
> bidirectional
> paths would be void of any data = plane=20 content.
>
> The somewhat vague scope of this requirement = ("other=20 internal functions
> as appropriate") creates a suspicion that HW = support=20 of the pairing
> awareness
> may be required in order to = comply with=20 it.

The entirety of the bracketted text "(including MEPs, MIPs = and=20 other
internal functions as appropriate)" should be deleted. It does = not add=20 to
"The intermediate nodes."

> The following text in the = draft=20 increases this suspicion:
>
> <quote>
> = Tandem=20 Connection: A tandem connection is an arbitrary part of a
> = transport path that can be monitored (via OAM) independently from = the
>=20 end-to-end monitoring (OAM). It may be a monitored segment = or=20 a
> monitored concatenated segment of a transport path. = The=20 tandem
> connection may also include the forwarding = engine(s) of=20 the node(s)
> at the edge(s) of the segment or concatenated = segment.
> <end quote>

Actually, I am quite fed up = about this=20 persistent insistence on the
inclusion of "Tandem Connection." The = definition=20 within the ITU-T of this
term is poorly specified and comes from the=20 monitoring of a path that is
parallel (i.e. tandem) to the data path = being=20 monitored. This definition of
TC seems to be at variance, and would = be if the=20 ACH was actually in band.

> Doesn't "forwarding engine" sound = like=20 hardware to you?

Yes, but so what?

> IMHO it is worth = noting=20 that neither the MPLS-TP Requirements
> draft nor the MPLS-TP OAM=20 requirements one
>=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-= 01.txt)
>=20 contain any requirements dealing with tandem = connections.
>
> But=20 tandem connections are discussed in the MPLS-TP OAM Framework = draft
>=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.= txt).

Right.
Let's=20 just get rid of an unnecessary term and bring all the I-Ds into=20 line.

> The bottom line, IMHO, is that some clarity regarding=20 co-routed vs.
> associated
> bidirectional paths is still = required.=20 One way to provide that could be by
> explicitly
> limiting=20 Requirement 34 to specific=20 functionality.

Agreed.

Adrian

__________= ______________________________
From:=20 Adrian Farrel [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 = 12:13=20 AM
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc:=20 mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements

Hi Sasha,

Not really sure whether you = are=20 misrepresenting anyone, but...

> 1. My reading of one of = Ben's=20 messages is that associated
> bidirectional paths are the = only types=20 of paths that can be
> created in the existing networks; "true" = co-routed=20 bidirectional
> paths will have to wait until (if ever) new = equipment=20 becomes
> available.

This is clearly nonsense!
From the = point of=20 view of hardware, co-routed bidirectional LSPs are a
special case of=20 associated bidirectional LSPs.

If you can set up two = unidirectional LSPs=20 (e.g. using the management plane)
you can surely set up a co-routed=20 bidirectional LSP.

There are shipping solutions that achieve = co-routed=20 bidirectional LSPs using
the control plane. These either use the = GMPLS (which=20 is cleaner) or
non-standard proprietary solutions (which is messy but = functional).

But (of course) the management plane or control = plane=20 solutions have nothing
to do with availability of equipment as they = are=20 software solutions.

> 2. My reading of one of Neil's messages = is that=20 the actual driver for
> co-routed
> bidirectional paths may = be=20 experience with existing transport networks
> rather
> than = any=20 specific benefit.

Isn't that the case with 75% of the MPLS-TP=20 requirements?
Which is not to say it is a bad thing.

A large = driver=20 for MPLS-TP is to give the packet network the look, feel, = and
behavioral=20 characteristics of a "legacy" transport network.

> Based on = these=20 observations, I'd guess (FWIW) that:
> * associated bidirectional = paths=20 are, at least for the time
> being, the most = important type=20 of bidirectional paths in
> MPLS-TP

I think = that is=20 wrong both given my statement above, and given that other
upgrades to = existing MPLS solutions will be needed to reach the full
function = level of=20 MPLS-TP.

> * they had a good chance to remain the only type of = bidirectional
> paths in real deployments.

I = don't see=20 what that follows from.

Cheers,
Adrian_______________________________________________ mpls-tp = mailing=20 list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp=

--------------------------------------------= ------------ ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01C9BF39.C8728BC2-- From Italo.Busi@alcatel-lucent.it Fri Apr 17 01:58:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310D23A6996 for ; Fri, 17 Apr 2009 01:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVaPdQq8G1tO for ; Fri, 17 Apr 2009 01:58:43 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 29DEF3A6A47 for ; Fri, 17 Apr 2009 01:58:42 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H8wjjG028881; Fri, 17 Apr 2009 10:58:50 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:58:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 10:58:43 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1867@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <51661468CBD1354294533DA79E85955A01A6BB1D@XCH-SW-5V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWg References: <5403F90D2C87494EA46E4EB3370FC1C1@your029b8cecfe>, <007601c9be8e$497c82e0$6570ca0a@china.huawei.com> <51661468CBD1354294533DA79E85955A01A6BB1D@XCH-SW-5V2.sw.nos.boeing.com> From: "BUSI ITALO" To: "Drake, John E" , "Alexander Vainshtein" , "Maarten Vissers" X-OriginalArrivalTime: 17 Apr 2009 08:58:45.0032 (UTC) FILETIME=[B6A93280:01C9BF3A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:58:45 -0000 John, I might have missed the agreement of MPLS-TP being capable of sending replies to OAM requests sent on uni-directional LSPs. This requirement does not belong to the first set of requirements ITU-T is expecting to be met by October. However, I think this in a potential interesting additional requirement to be taken into account (at worst in a subsequent phase). I think that this requirement needs to be evaluated versus other more important requirements (e.g. the possibility to work w/o IP forwarding and the need for OAM to continue to monitor the data plane also in case of failures affecting the control or management plane). I am open to discuss it but not sure this is the right time because I wish to avoid delaying the first phase of the design solution. Thanks, Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: Thursday, April 16, 2009 8:00 PM > To: Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > At the meeting last fall at Juniper in Massachusetts, I think it was > agreed that an MPLS TP network needs to have a forwarding=20 > capability for > management, control, and OAM packets (e.g., sending replies to OAM > requests sent on uni-directional LSPs) even if it does not have an IP > forwarding data plane. =20 >=20 > > -----Original Message----- > > From: Alexander Vainshtein=20 > [mailto:Alexander.Vainshtein@ecitele.com]=20 > > Sent: Thursday, April 16, 2009 9:57 AM > > To: Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > > Maarten, > > It seems that you've just (implicitly and, probably,=20 > > inadvertently) stated the following: > >=20 > > MPLS-TP OAM will not ever support MIP loopback function=20 > > (and fault localization which requires this function ) for=20 > > unidirectional P2MP and P2P paths. > >=20 > > If this statement is correct, this (IMHO and FWIW) raises a=20 > > valid question:=20 > >=20 > > Is MPLS-TP an appropriate solution for these types of=20 > > transport paths? > >=20 > > For the reference, IP/MPLS provides this kind of=20 > > functionality today for (unidirectional - but it does not=20 > > know any other type) P2P LSPs as described in RFC 4379. And=20 > > its extension to P2MP LSPs seems easy... > >=20 > > =20 > >=20 > > Regards, > >=20 > > Sasha > >=20 > >=20 > >=20 > > ________________________________________ > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On=20 > > Behalf Of Maarten Vissers [maarten.vissers@huawei.com] > > Sent: Thursday, April 16, 2009 3:24 PM > > To: 'Adrian Farrel' > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > > Adrian, > >=20 > > >> > > >> The intermediate nodes (including MEPs, MIPs and=20 > > other internal > > >> functions as appropriate) of a co-routed=20 > > bidirectional transport > > >> path at each (sub-)layer MUST be aware of the pairing > > >> relationship of the forward and the backward=20 > > directions of that > > >> transport path. > > >> > > > > > > There is no way this is a functional requirement. That=20 > is, there is > > > *nothing* that can be observed from a black box point of=20 > view that=20 > > > results from adhering to this requirement. > >=20 > > Your understanding is not correct. It is very much observable=20 > > if this requirement is met from a black box point of view.=20 > > The MIP functions can only perform the Loopback when there is=20 > > a co-routed bidirectional transport path. The MPLS-TP LBM=20 > > packet received at a MIP needs to be returned (as LBR > > packet) to the originating MEP function via the other=20 > > direction of the co-routed bidirectional transport path. This=20 > > other direction would not be available in an associated=20 > > bidirectional transport path... and thus the loopback test=20 > would fail. > >=20 > > Similarly, when we have to apply TCM MEPs to monitor a=20 > > segment, then this is possible in a co-routed bidir transport=20 > > path but not in a associated bidir transport path. In the=20 > > first case the TCM MEP Source and Sink functions are=20 > > co-located and can exchange what is called "remote=20 > > information" which is necessary for performance monitoring.=20 > > In the latter case the TCM MEP Source and Sink functions are=20 > > in e.g. different nodes in the network and TCM would not be=20 > > able to provide performance monitoring. > >=20 > > > The entirety of the bracketted text "(including MEPs,=20 > MIPs and other > > internal > > > functions as appropriate)" should be deleted. It does not=20 > > add to "The=20 > > > intermediate nodes." > >=20 > > Your understanding is not correct. This text must not be=20 > > deleted at all. > >=20 > > > Actually, I am quite fed up about this persistent=20 > insistence on the > > inclusion > > > of "Tandem Connection." The definition within the ITU-T of=20 > > this term=20 > > > is > > poorly > > > specified and comes from the monitoring of a path that is=20 > > parallel (i.e. > > tandem) > > > to the data path being monitored. This definition of TC=20 > > seems to be at > > variance, > > > and would be if the ACH was actually in band. > >=20 > > I don't understand where your interpretation of tandem=20 > > connection is described in ITU-T recommendations. I.e. "from=20 > > the monitoring of a path that is parallel (i.e. tandem) to=20 > > the data path being monitored."? > >=20 > > There is a "network connection" and this network connection=20 > > is a set of interconnected "link connections" and "matrix=20 > > connections". A subset of those interconnected link=20 > > connections and matrix connections can be monitored and is=20 > > then referred to as a "tandem connection". There is no "path=20 > > that is parallel to the data path". There is only additional=20 > > OAM inserted inside the data path by the TCM MEP_So function=20 > > and this OAM is extracted from the data path by the TCM=20 > > MEP_Sk function. > >=20 > > Regards, > > Maarten > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: donderdag 16 april 2009 11:59 > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > > Hi Sasha, > >=20 > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > From the point of view of hardware, co-routed=20 > bidirectional LSPs > > > are a special case of associated bidirectional LSPs. > > > > > > > > > This statement would be obviously correct, were it not for=20 > > Requirement > > > 34 in the latest MPLS-TP requirements draft > >=20 > > OK. Got it. > >=20 > > But what is this doing in the data plane requirements section? > >=20 > > In fact, what is this requirement actually saying? > >=20 > > > > > > The intermediate nodes (including MEPs, MIPs and=20 > other internal > > > functions as appropriate) of a co-routed=20 > > bidirectional transport > > > path at each (sub-)layer MUST be aware of the pairing > > > relationship of the forward and the backward=20 > > directions of that > > > transport path. > > > > >=20 > > There is no way this is a functional requirement. That is, there is > > *nothing* that can be observed from a black box point of view=20 > > that results from adhering to this requirement. > >=20 > > Therefore it could be assumed that this requirement is met by=20 > > configuring some data plane database component through the=20 > > management plane. The database component is not used for=20 > > anything except to satisfy this requirement for "awareness". > >=20 > > Ben! Can we please try to rewrite this requirement in terms=20 > > of behavior? > >=20 > > > Please note that Requirement 34 is the ONLY item in the=20 > > list that is=20 > > > specific for co-routed bidirectional LSPs. (The pairing=20 > > requirements=20 > > > at end points for co-routed and associated bidirectional=20 > paths are=20 > > > exactly the same even if they appear in two different=20 > items in the=20 > > > requirements' list). > > > In other words, without Requirement 34 the notion of co-routed=20 > > > bidirectional paths would be void of any data plane content. > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > functions as appropriate") creates a suspicion that HW=20 > > support of the=20 > > > pairing awareness may be required in order to comply with it. > >=20 > > The entirety of the bracketted text "(including MEPs, MIPs=20 > > and other internal functions as appropriate)" should be=20 > > deleted. It does not add to "The intermediate nodes." > >=20 > > > The following text in the draft increases this suspicion: > > > > > > > > > Tandem Connection: A tandem connection is an arbitrary part of a > > > transport path that can be monitored (via OAM)=20 > > independently from the > > > end-to-end monitoring (OAM). It may be a monitored segment or a > > > monitored concatenated segment of a transport path. The tandem > > > connection may also include the forwarding engine(s) of=20 > > the node(s) > > > at the edge(s) of the segment or concatenated segment. > > > > >=20 > > Actually, I am quite fed up about this persistent insistence=20 > > on the inclusion of "Tandem Connection." The definition=20 > > within the ITU-T of this term is poorly specified and comes=20 > > from the monitoring of a path that is parallel (i.e. tandem)=20 > > to the data path being monitored. This definition of TC seems=20 > > to be at variance, and would be if the ACH was actually in band. > >=20 > > > Doesn't "forwarding engine" sound like hardware to you? > >=20 > > Yes, but so what? > >=20 > > > IMHO it is worth noting that neither the MPLS-TP=20 > Requirements draft=20 > > > nor the MPLS-TP OAM requirements one=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > ts-01.txt) contain any requirements dealing with tandem=20 > connections. > > > > > > But tandem connections are discussed in the MPLS-TP OAM Framework=20 > > > draft > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > amework-00.txt > > ). > >=20 > > Right. > > Let's just get rid of an unnecessary term and bring all the=20 > > I-Ds into line. > >=20 > > > The bottom line, IMHO, is that some clarity regarding=20 > co-routed vs. > > > associated > > > bidirectional paths is still required. One way to provide=20 > > that could=20 > > > be by explicitly limiting Requirement 34 to specific=20 > functionality. > >=20 > > Agreed. > >=20 > > Adrian > >=20 > >=20 > >=20 > >=20 > > ________________________________________ > > From: Adrian Farrel [adrian@olddog.co.uk] > > Sent: Thursday, April 16, 2009 12:13 AM > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > > Hi Sasha, > >=20 > > Not really sure whether you are misrepresenting anyone, but... > >=20 > > > 1. My reading of one of Ben's messages is that associated=20 > > > bidirectional paths are the only types of paths that can be=20 > > created in=20 > > > the existing networks; "true" co-routed bidirectional paths=20 > > will have=20 > > > to wait until (if ever) new equipment becomes available. > >=20 > > This is clearly nonsense! > > From the point of view of hardware, co-routed bidirectional=20 > > LSPs are a special case of associated bidirectional LSPs. > >=20 > > If you can set up two unidirectional LSPs (e.g. using the=20 > > management plane) you can surely set up a co-routed=20 > bidirectional LSP. > >=20 > > There are shipping solutions that achieve co-routed=20 > > bidirectional LSPs using the control plane. These either use=20 > > the GMPLS (which is cleaner) or non-standard proprietary=20 > > solutions (which is messy but functional). > >=20 > > But (of course) the management plane or control plane=20 > > solutions have nothing to do with availability of equipment=20 > > as they are software solutions. > >=20 > > > 2. My reading of one of Neil's messages is that the actual=20 > > driver for=20 > > > co-routed bidirectional paths may be experience with existing=20 > > > transport networks rather than any specific benefit. > >=20 > > Isn't that the case with 75% of the MPLS-TP requirements? > > Which is not to say it is a bad thing. > >=20 > > A large driver for MPLS-TP is to give the packet network the=20 > > look, feel, and behavioral characteristics of a "legacy"=20 > > transport network. > >=20 > > > Based on these observations, I'd guess (FWIW) that: > > > * associated bidirectional paths are, at least for the time > > > being, the most important type of bidirectional paths in > > > MPLS-TP > >=20 > > I think that is wrong both given my statement above, and=20 > > given that other upgrades to existing MPLS solutions will be=20 > > needed to reach the full function level of MPLS-TP. > >=20 > > > * they had a good chance to remain the only type of bidirectional > > > paths in real deployments. > >=20 > > I don't see what that follows from. > >=20 > > Cheers, > > Adrian > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From liu.guoman@zte.com.cn Fri Apr 17 02:02:07 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38C428C132 for ; Fri, 17 Apr 2009 02:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.335 X-Spam-Level: X-Spam-Status: No, score=-97.335 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGFTUWesUHsZ for ; Fri, 17 Apr 2009 02:02:05 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 611A228C13E for ; Fri, 17 Apr 2009 02:02:04 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Fri, 17 Apr 2009 16:56:13 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.801372902; Fri, 17 Apr 2009 17:00:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3H90WoK074285; Fri, 17 Apr 2009 17:00:33 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: Alexander Vainshtein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 17 Apr 2009 16:58:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-17 17:00:23, Serialize complete at 2009-04-17 17:00:23 Content-Type: multipart/alternative; boundary="=_alternative 003171E84825759B_=" X-MAIL: mse1.zte.com.cn n3H90WoK074285 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:02:08 -0000 This is a multipart message in MIME format. --=_alternative 003171E84825759B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c2FzaGE6DQogdGhhbmsgeW91IGZvciB5b3VyIGRldGFpbCBleHBsYWluLCB5b3UgbWF5IGJlIHRy dWUgZm9yIHlvdXIgDQp1bmRlcnN0YW5kaW5nLiBoZXJlIEkgY2FuJ3QgYWR2b2NhdGUgdGhlcmUg bXVzdCBiZSBUQ00gY29uY2VwdGlvbiBhbmQgDQpmdW5jYXRpb24gaW4gTVBMUy1UUCByZXF1aXJl bWVudCwgIGJ1dCBtcGxzLXRwIHNob3VsZCBoYXZlIHRoZSANCnJlcXVpcmVtZW50cyBvZiBzdWIt bGF5ZXIgb3Igc2VnZW1lbnQgcHJvdGVjdGlvbnMgbGlrZSBTTkNQIGluIFNESC9TT05FVCANCm5l dHdvcmsuIG1heWJlIHRoZSByZXF1aXJlbWVudHMgbm90IGJlIGFwcGx5ZWQgZm9yIHNvbWUgc2Vy dmljZSANCnByaXZpZGVycyxidXQgaXQgbWF5IHByaXZpZGUgdGhlbSB3aXRoICBtb3JlIGNob2lj ZXMgZm9yIHNlcnZpY2UgDQpwcml2aWRlcnMuDQoNCnJlZ2FyZHMNCmxpdQ0KIA0KDQoNCg0KQWxl eGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiANCjIw MDktMDQtMTcgMTU6NDkNCg0KytW8/sjLDQoibGl1Lmd1b21hbkB6dGUuY29tLmNuIiA8bGl1Lmd1 b21hbkB6dGUuY29tLmNuPg0Ks63LzQ0KIm1wbHMtdHBAaWV0Zi5vcmciIDxtcGxzLXRwQGlldGYu b3JnPg0K1vfM4g0KUkU6IFttcGxzLXRwXSBDby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCByZXF1aXJlbWVudCAod2FzOiANCkFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQoNCg0KDQoNCg0KDQpMaXUsDQpUaGFuayB5b3UgZm9y IGEgcHJvbXB0IHJlc3BvbnNlLg0KIA0KVG8gbWFrZSBpdCBjbGVhciwgSSBkaWQgbm90IGFkdm9j YXRlIDE6MSBsaW5lYXIgKGEuay5hLiBlbmQtdG8tZW5kKSANCnByb3RlY3Rpb24gZm9yIE1QTFMt VFAuIEkndmUgb25seSBtZW50aW9uZWQgaXQgYXMgdGhlIG9ubHkgMToxIHByb3RlY3Rpb24gDQpz Y2hlbWUgSSd2ZSBmb3VuZCBpbiB0aGUgTVBMUy1UUCBTdXJ2aXZhYmlsaXR5IEZyYW1ld29yayBk cmFmdC4NCiANClRvIHRha2Ugb25lIHN0ZXAgZnVydGhlciwgSU1ITyBhbmQgRldJVywgc3BlY2lm aWMgcHJvdGVjdGlvbiBzY2hlbWVzIGFuZCANCm1vbml0b3JpbmcgbWVjaGFuaXNtcyBhcmUgbm90 IHRpZ2h0bHkgY291cGxlZCwgYW5kIHByZWZlcmFibHkgc2hvdWxkIA0KcmVtYWluIHNvLiBIZW5j ZSBhbnkgYXR0ZW1wdCB0byBqdXN0aWZ5IGV4aXN0ZW5jZSBvZiBhIGNlcnRhaW4gbW9uaXRvcmlu ZyANCm1lY2hhbmlzbSAoYW5kIFRDTSBjbGVhcmx5IGZhbGxzIGluIHRoZSB0aGlzIGNhdGVnb3J5 IC0gaXQgc3RhbmRzIGZvciANClRhbmRlbSBDb25uZWN0aW9uIE1vbml0b3JpbmcpIGJ5IHJlZmVy ZW5jZSB0byBhIGNlcnRhaW4gcHJvdGVjdGlvbiBzY2hlbWUgDQp3b3VsZCBsb29rIGZhdWx0eSB0 byBtZS4gQW5kIGlmLCBvbiB0b3Agb2YgdGhpcywgdGhlIHByb3RlY3Rpb24gc2NoZW1lIGluIA0K cXVlc3Rpb24gaXMgbm90IGV2ZW4gbWVudGlvbmVkIG4gdGhlIFN1cnZpdmFiaWxpdHkgRnJhbWV3 b3JrIGRyYWZ0Li4uIG5vIA0KbmVlZCB0byBjb250aW51ZSwgSSB0aGluay4NCiANCihPZiBjb3Vy c2UgdGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQgYWRkaXRpb25hbCBwcm90ZWN0aW9uIHNjaGVtZXMg Y2Fubm90IA0KYXBwZWFyIGluIHRoZSBNUExTLVRQIFN1cnZpdmFiaWxpdHkgRnJhbWV3b3JrIGRy YWZ0LiBPbiB0aGUgb3RoZXIgaGFuZCwgDQpzb21lIG9mIHRoZSBzY2hlbWVzIG5vdyBpbiB0aGUg ZHJhZnQgbWF5IGJlIGV2ZW50dWFsbHkgZHJvcHBlZCBvciwgYXQgDQpsZWFzdCwgZG93bmdyYWRl ZCBmcm9tIE1VU1QgdG8gU0hPVUxEIG9yIE1BWS4gQnV0IHRoaXMgaXMgYSBkaWZmZXJlbnQgDQp0 b3BpYykuDQogDQpMYXN0IGJ1dCBub3QgbGVhc3QsIHdlIGFyZSBjdXJyZW50bHkgZGlzY3Vzc2lu ZyBNUExTLVRQIHJlcXVpcmVtZW50cywgYW5kIA0KdGhlc2UgcmVxdWlyZW1lbnRzIHByZXN1bWFi bHkgc2hvdWxkIGJlIGJhc2VkIG9uIGV4cGVyaWVuY2Ugb2YgdGhlIA0KdHJhbnNwb3J0IG9wZXJh dG9ycy4gQXMgc29tZSBwZW9wbGUgKGluY2x1ZGluZyBteXNlbGYpIGhhdmUgbm90ZWQsIGluIHRo ZSANCnR3byByb3VuZHMgb2YgZWFybGllciBkaXNjdXNzaW9ucyBubyB0cmFuc3BvcnQgb3BlcmF0 b3JzIGhhdmUgbm90IA0KZXhwbGljaXRseSByZXF1aXJlZCBUQ00uICBJbiB0aGlzICgzcmQhKSBy b3VuZCBhdCBsZWFzdCBvbmUgbWFqb3Igb3BlcmF0b3IgDQpoYXMgZXhwbGljaXRseSBzdGF0ZWQg dGhhdCBUQ00gaXMgbm90IG5lZWRlZC4gDQogDQpSZWdhcmRzLA0KICAgICBTYXNoYQ0KIA0KIA0K IA0KRnJvbTogbGl1Lmd1b21hbkB6dGUuY29tLmNuIFtsaXUuZ3VvbWFuQHp0ZS5jb20uY25dDQpT ZW50OiBGcmlkYXksIEFwcmlsIDE3LCAyMDA5IDY6MDMgQU0NClRvOiBBbGV4YW5kZXIgVmFpbnNo dGVpbg0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQ28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnQgDQood2FzOiBBc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQoNCnNh c2hhOiANCiBpIGRvbid0IGFncmVlIHlvdXIgYWR2aWNlLCBpIHRoaW5rIGl0IGlzIG5lY2Vzc2Fy eSB0byBjb25zaWRlciBUQ00gDQpmdW5jdGlvbmFsaXR5IGFuZCBwcm90ZWN0aW9ucyBpbiBNUExT LVRQIHN1cnZpdmUgZnJhbWV3b3JrLiANCml0IGlzIGNvbXBsZXggYW5kIGNvc3QgdG8gYXBwbHkg ZW5kIHRvIGVuZCBwcm90ZWN0aW9uLiANCnRoYW5rIHlvdS4gDQpsaXUgDQoNCg0KQWxleGFuZGVy IFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiANCreivP7Iyzog IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCjIwMDktMDQtMTYgMjI6MzIgDQoNCg0KytW8/sjL DQpNYWFydGVuIFZpc3NlcnMgPG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPiANCrOty80NCiJt cGxzLXRwQGlldGYub3JnIiA8bXBscy10cEBpZXRmLm9yZz4gDQrW98ziDQpSZTogW21wbHMtdHBd IENvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50ICh3YXM6 IA0KQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykN Cg0KDQoNCg0KDQoNCg0KDQpNYWFydGVuLCANCkkndmUgc2Nhbm5lZCB0aGUgTVBMUy1UUCBTdXJ2 aXZhYmlsaXR5IEZyYW1ld29yayBkcmFmdCAoDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtc3Vydml2ZS1md2stMDAudHh0KSANCmJ1dCBkaWQg bm90IGZpbmQgdGhlcmUgYW55IHJlcXVpcmVtZW50cyBmb3IgIDE6MSBTTkMgcHJvdGVjdGlvbiAo aW5kZWVkLCANCnRoZSB0ZXJtIFNOQyBpcyBub3QgbWVudGlvbmVkIGluIHRoaXMgZG9jdW1lbnQp LiANCiAgDQpBbmQgQUZBSUsgMToxIGxpbmVhciBwcm90ZWN0aW9uICh3aGljaCBpcyBtZW50aW9u ZWQgaW4gdGhlIGRyYWZ0KSBkb2VzIG5vdCANCnJlcXVpcmUgYW55IFRDTSBmdW5jdGlvbmFsaXR5 LiANCiAgDQpJZiB0aGUgZnVuY3Rpb25hbGl0eSB5b3UgaGF2ZSBpbiBtaW5kIGlzIGNhbGxlZCBi eSBhbnkgb3RoZXIgbmFtZSBpbiB0aGUgDQpNUExTLVRQIFN1cnZpdmFiaWxpdHkgRnJhbWV3b3Jr ICwgaXQgd291bGQgYmUgbmljZSBpZiB5b3UgY291bGQgcHJvdmlkZSBhbiANCmFwcHJvcHJpYXRl IG1hcHBpbmcuIElmIG5vdCwgbGV0IHVzIG5vdCB1c2UgaXQgYXMgYSBqdXN0aWZpY2F0aW9uIGZv ciANCmFkZGl0aW9uYWwgT0FNIGZ1bmN0aW9uYWxpdHkgbGlrZSBUQ00uIA0KICANClJlZ2FyZHMs IA0KICAgICBTYXNoYSANCiANCiANCiANCiANCiANCiANCkZyb206IE1hYXJ0ZW4gVmlzc2VycyBb bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIw MDkgMzoyOSBQTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQpDYzogbXBscy10cEBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IFttcGxzLXRwXSBDby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCByZXF1aXJlbWVudCANCih3YXM6IEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQoNClNhc2hhLCANCiAgDQpJIGRvIG5vdCBhZ3JlZSB3 aXRoIHlvdSBub3IgQWRyaWFuIGluIHRoaXMgbWF0dGVyIGFzIGV4cGxhaW5lZCBpbiBteSANCnJl c3BvbnNlIHRvIEFkcmlhbidzIGVtYWlsIGEgZmV3IG1pbnV0ZXMgYWdvLiANCiAgDQpPbmUgb2Yg dGhlIGFwcGxpY2F0aW9ucyB0aGF0IHdvdWxkIG5vdCBsb25nZXIgYmUgYWJsZSB0byBmdW5jdGlv biB3b3VsZCBiZSANCjE6MSBQVyBTTkMgcHJvdGVjdGlvbiBvciAxOjEgTFNQIFNOQyBwcm90ZWN0 aW9uLiBGb3IgdGhvc2UgcHJvdGVjdGlvbiANCm1lY2hhbmlzbXMgd2UgbmVlZCBUQ00gTUVQIGZ1 bmN0aW9ucyB0byBkZXRlcm1pbmUgdGhlIHN0YXR1cyBvZiBlYWNoIFNOQy4gDQogIA0KUmVnYXJk cywgDQpNYWFydGVuIA0KDQpGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCk9mIEFsZXhhbmRlciBWYWluc2h0 ZWluDQpTZW50OiBkb25kZXJkYWcgMTYgYXByaWwgMjAwOSAxMzo0MA0KVG86IEFkcmlhbiBGYXJy ZWwNCkNjOiBCVVNJQGNvcmUzLmFtc2wuY29tOyBJVEFMTzsgbXBscy10cEBpZXRmLm9yZw0KU3Vi amVjdDogW21wbHMtdHBdIENvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJl cXVpcmVtZW50IA0KKHdhczogQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo IHJlcXVpcmVtZW50cykNCg0KQWRyaWFuLCANCkxvb2tzIGFzIHdlIGFyZSBtdWNoIG1vcmUgaW4g YWdyZWVtZW50IHRoYW4gaXQgY291bGQgYmUgZ3Vlc3NlZCBmcm9tIHRoZSANCmZpcnN0IHJvdW5k IG9mIGV4Y2hhbmdlcy4gDQpJJ3ZlIGNoYW5nZWQgdGhlIHN1YmplY3Qgc2luY2Ugd2UgYXJlIGFj dHVhbGx5IGRpc2N1c3Npbmcgc3BlY2lmaWNzIG9mIA0KY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg cGF0aHMuIA0KICANCkkgZnVsbHkgc3VwcG9ydCB5b3VyIHByb3Bvc2FsIHRvIGdldCByaWQgKGlu IGEgY29uc2lzdGVudCBtYW5uZXIpIGZyb20gdGhlIA0KVEMgc3R1ZmYgaW4gTVBMUy1UUCwgZXNw ZWNpYWxseSBzaW5jZSwgdG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCANCm9wZXJhdGlvbmFs IGV4cGVyaWVuY2Ugd2l0aCBTT05FVC9TREggVENNIChJVFUtVCBkZWZpbml0aW9ucyANCm5vdHdp dGhzdGFuZGluZykgZGlkIG5vdCBwcm92ZSBpdHMgd29ydGguIElmIHRoaXMgaXMgYmFzZWQgb24g DQptaXMtcGVyY2VwdGlvbiwgSSB3b3VsZCBiZSBnbGFkIHRvIGhlYXIgdGhhdCAoZXNwZWNpYWxs eSBmcm9tIHRoZSANCm9wZXJhdG9ycyBvbiB0aGlzIGxpc3QpLiANCiAgDQpBbmQgaWYgaXQgaXMg cG9zc2libGUgdG8gcmUtd3JpdGUgUmVxdWlyZW1lbnQgMzQgYXMgYSBmdW5jdGlvbmFsL2JlaGF2 aW9yIA0KcmVxdWlyZW1lbnQsIGl0IHdvdWxkIGJlIGdyZWF0LCB0b28uIA0KSG93ZXZlciwgSSBh bSBub3Qgc3VyZSB0aGlzIHdvdWxkIGJlIGVhc3kgKEJlbiwgbXkgYXBvbG9naWVzIGFnYWluKS4g DQogIA0KUmVnYXJkcywgDQogICAgIFNhc2hhIA0KIA0KIA0KIA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBZHJpYW4gRmFycmVsIFthZHJpYW5Ab2xk ZG9nLmNvLnVrXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjU5IFBNDQpUbzog QWxleGFuZGVyIFZhaW5zaHRlaW47IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tDQpDYzog bXBscy10cEBpZXRmLm9yZzsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTw0KU3ViamVjdDogUmU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQpyZXF1aXJl bWVudHMNCg0KSGkgU2FzaGEsDQoNCj4gVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxseSBhZ3Jl ZSB3aXRoIHlvdXIgc3RhdGVtZW50Og0KPg0KPiA8cXVvdGU+DQo+ICAgICBGcm9tIHRoZSBwb2lu dCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzDQo+ICAg ICBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuDQo+ IDxlbmQgcXVvdGU+DQo+DQo+IFRoaXMgc3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3Jy ZWN0LCB3ZXJlIGl0IG5vdCBmb3IgUmVxdWlyZW1lbnQgDQozNA0KPiBpbiB0aGUgbGF0ZXN0DQo+ IE1QTFMtVFAgcmVxdWlyZW1lbnRzIGRyYWZ0DQoNCk9LLiBHb3QgaXQuDQoNCkJ1dCB3aGF0IGlz IHRoaXMgZG9pbmcgaW4gdGhlIGRhdGEgcGxhbmUgcmVxdWlyZW1lbnRzIHNlY3Rpb24/DQoNCklu IGZhY3QsIHdoYXQgaXMgdGhpcyByZXF1aXJlbWVudCBhY3R1YWxseSBzYXlpbmc/DQoNCj4gPHF1 b3RlPg0KPiAgICAgIFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZyBNRVBzLCBNSVBz IGFuZCBvdGhlciBpbnRlcm5hbA0KPiAgICAgICBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9m IGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ICAgICAgIHBhdGggYXQgZWFj aCAoc3ViLSlsYXllciBNVVNUIGJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nDQo+ICAgICAgIHJlbGF0 aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkIGRpcmVjdGlvbnMgb2YgdGhh dA0KPiAgICAgICB0cmFuc3BvcnQgcGF0aC4NCj4gPGVuZCBxdW90ZT4NCg0KVGhlcmUgaXMgbm8g d2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBUaGF0IGlzLCB0aGVyZSBpcw0K Km5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2Yg dmlldyB0aGF0IHJlc3VsdHMNCmZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC4NCg0K VGhlcmVmb3JlIGl0IGNvdWxkIGJlIGFzc3VtZWQgdGhhdCB0aGlzIHJlcXVpcmVtZW50IGlzIG1l dCBieSBjb25maWd1cmluZw0Kc29tZSBkYXRhIHBsYW5lIGRhdGFiYXNlIGNvbXBvbmVudCB0aHJv dWdoIHRoZSBtYW5hZ2VtZW50IHBsYW5lLiBUaGUNCmRhdGFiYXNlIGNvbXBvbmVudCBpcyBub3Qg dXNlZCBmb3IgYW55dGhpbmcgZXhjZXB0IHRvIHNhdGlzZnkgdGhpcw0KcmVxdWlyZW1lbnQgZm9y ICJhd2FyZW5lc3MiLg0KDQpCZW4hIENhbiB3ZSBwbGVhc2UgdHJ5IHRvIHJld3JpdGUgdGhpcyBy ZXF1aXJlbWVudCBpbiB0ZXJtcyBvZiBiZWhhdmlvcj8NCg0KPiBQbGVhc2Ugbm90ZSB0aGF0IFJl cXVpcmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4gdGhlIGxpc3QgdGhhdCBpcw0KPiBzcGVj aWZpYw0KPiBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBwYWlyaW5nIHJl cXVpcmVtZW50cyBhdCBlbmQgDQpwb2ludHMNCj4gZm9yIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSBleGFjdGx5IHRoZSBzYW1lIA0KZXZlbg0KPiBpZiB0 aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50IGl0ZW1zIGluIHRoZSByZXF1aXJlbWVudHMnIGxp c3QpLg0KPiBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9u IG9mIGNvLXJvdXRlZA0KPiBiaWRpcmVjdGlvbmFsDQo+IHBhdGhzIHdvdWxkIGJlIHZvaWQgb2Yg YW55IGRhdGEgcGxhbmUgY29udGVudC4NCj4NCj4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9m IHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbCBmdW5jdGlvbnMNCj4gYXMgYXBwcm9w cmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcgc3VwcG9ydCBvZiB0aGUgcGFpcmlu Zw0KPiBhd2FyZW5lc3MNCj4gbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRvIGNvbXBseSB3aXRo IGl0Lg0KDQpUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBN RVBzLCBNSVBzIGFuZCBvdGhlcg0KaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIg c2hvdWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90IGFkZCB0bw0KIlRoZSBpbnRlcm1lZGlhdGUg bm9kZXMuIg0KDQo+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2VzIHRo aXMgc3VzcGljaW9uOg0KPg0KPiA8cXVvdGU+DQo+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFu ZGVtIGNvbm5lY3Rpb24gaXMgYW4gYXJiaXRyYXJ5IHBhcnQgb2YgYQ0KPiAgIHRyYW5zcG9ydCBw YXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5kZXBlbmRlbnRseSBmcm9tIHRo ZQ0KPiAgIGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gIEl0IG1heSBiZSBhIG1vbml0b3Jl ZCBzZWdtZW50IG9yIGENCj4gICBtb25pdG9yZWQgY29uY2F0ZW5hdGVkIHNlZ21lbnQgb2YgYSB0 cmFuc3BvcnQgcGF0aC4gIFRoZSB0YW5kZW0NCj4gICBjb25uZWN0aW9uIG1heSBhbHNvIGluY2x1 ZGUgdGhlIGZvcndhcmRpbmcgZW5naW5lKHMpIG9mIHRoZSBub2RlKHMpDQo+ICAgYXQgdGhlIGVk Z2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21lbnQuDQo+IDxlbmQgcXVv dGU+DQoNCkFjdHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQg aW5zaXN0ZW5jZSBvbiB0aGUNCmluY2x1c2lvbiBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUg ZGVmaW5pdGlvbiB3aXRoaW4gdGhlIElUVS1UIG9mIHRoaXMNCnRlcm0gaXMgcG9vcmx5IHNwZWNp ZmllZCBhbmQgY29tZXMgZnJvbSB0aGUgbW9uaXRvcmluZyBvZiBhIHBhdGggdGhhdCBpcw0KcGFy YWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhp cyBkZWZpbml0aW9uIA0Kb2YNClRDIHNlZW1zIHRvIGJlIGF0IHZhcmlhbmNlLCBhbmQgd291bGQg YmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC4NCg0KPiBEb2Vzbid0ICJmb3J3YXJk aW5nIGVuZ2luZSIgc291bmQgbGlrZSBoYXJkd2FyZSB0byB5b3U/DQoNClllcywgYnV0IHNvIHdo YXQ/DQoNCj4gSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0aGVyIHRoZSBNUExTLVRQ IFJlcXVpcmVtZW50cw0KPiBkcmFmdCBub3IgdGhlIE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50cyBv bmUNCj4gKA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1t cGxzLXRwLW9hbS1yZXF1aXJlbWVudHMtMDEudHh0DQopDQo+IGNvbnRhaW4gYW55IHJlcXVpcmVt ZW50cyBkZWFsaW5nIHdpdGggdGFuZGVtIGNvbm5lY3Rpb25zLg0KPg0KPiBCdXQgdGFuZGVtIGNv bm5lY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNIEZyYW1ld29yayBkcmFm dA0KPiAoDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1w bHMtdHAtb2FtLWZyYW1ld29yay0wMC50eHQNCikuDQoNClJpZ2h0Lg0KTGV0J3MganVzdCBnZXQg cmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nIGFsbCB0aGUgSS1EcyBpbnRvIA0K bGluZS4NCg0KPiBUaGUgYm90dG9tIGxpbmUsIElNSE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5IHJl Z2FyZGluZyBjby1yb3V0ZWQgdnMuDQo+IGFzc29jaWF0ZWQNCj4gYmlkaXJlY3Rpb25hbCBwYXRo cyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdheSB0byBwcm92aWRlIHRoYXQgY291bGQgYmUgDQpi eQ0KPiBleHBsaWNpdGx5DQo+IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNwZWNpZmljIGZ1 bmN0aW9uYWxpdHkuDQoNCkFncmVlZC4NCg0KQWRyaWFuDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBv bGRkb2cuY28udWtdDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMTI6MTMgQU0NClRv OiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTw0KQ2M6IG1wbHMt dHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCBwYXRoIA0KcmVxdWlyZW1lbnRzDQoNCkhpIFNhc2hhLA0KDQpOb3QgcmVh bGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLg0K DQo+IDEuIE15IHJlYWRpbmcgb2YgIG9uZSBvZiBCZW4ncyAgbWVzc2FnZXMgaXMgdGhhdCBhc3Nv Y2lhdGVkDQo+IGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBvbmx5IHR5cGVzIG9mIHBhdGhz IHRoYXQgY2FuIGJlDQo+IGNyZWF0ZWQgaW4gdGhlIGV4aXN0aW5nIG5ldHdvcmtzOyAidHJ1ZSIg Y28tcm91dGVkIGJpZGlyZWN0aW9uYWwNCj4gcGF0aHMgd2lsbCBoYXZlIHRvIHdhaXQgdW50aWwg KGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lcw0KPiBhdmFpbGFibGUuDQoNClRoaXMgaXMg Y2xlYXJseSBub25zZW5zZSENCkZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMgYXJlIGENCnNwZWNpYWwgY2FzZSBvZiBhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCg0KSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVj dGlvbmFsIExTUHMgKGUuZy4gdXNpbmcgdGhlIG1hbmFnZW1lbnQgDQpwbGFuZSkNCnlvdSBjYW4g c3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC4NCg0KVGhlcmUgYXJl IHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg TFNQcyANCnVzaW5nDQp0aGUgY29udHJvbCBwbGFuZS4gVGhlc2UgZWl0aGVyIHVzZSB0aGUgR01Q TFMgKHdoaWNoIGlzIGNsZWFuZXIpIG9yDQpub24tc3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRp b25zICh3aGljaCBpcyBtZXNzeSBidXQgZnVuY3Rpb25hbCkuDQoNCkJ1dCAob2YgY291cnNlKSB0 aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lIHNvbHV0aW9ucyBoYXZlIA0Kbm90 aGluZw0KdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50IGFzIHRoZXkgYXJlIHNv ZnR3YXJlIHNvbHV0aW9ucy4NCg0KPiAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVz c2FnZXMgaXMgdGhhdCB0aGUgYWN0dWFsIGRyaXZlciBmb3INCj4gY28tcm91dGVkDQo+IGJpZGly ZWN0aW9uYWwgcGF0aHMgbWF5IGJlIGV4cGVyaWVuY2Ugd2l0aCBleGlzdGluZyB0cmFuc3BvcnQg bmV0d29ya3MNCj4gcmF0aGVyDQo+IHRoYW4gYW55IHNwZWNpZmljIGJlbmVmaXQuDQoNCklzbid0 IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPw0KV2hp Y2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0aGluZy4NCg0KQSBsYXJnZSBkcml2ZXIgZm9y IE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsgdGhlIGxvb2ssIGZlZWwsIA0K YW5kDQpiZWhhdmlvcmFsIGNoYXJhY3RlcmlzdGljcyBvZiBhICJsZWdhY3kiIHRyYW5zcG9ydCBu ZXR3b3JrLg0KDQo+IEJhc2VkIG9uIHRoZXNlIG9ic2VydmF0aW9ucywgSSdkIGd1ZXNzIChGV0lX KSB0aGF0Og0KPiAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0 IGZvciB0aGUgdGltZQ0KPiAgICBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2YgYmlk aXJlY3Rpb25hbCBwYXRocyBpbg0KPiAgICBNUExTLVRQDQoNCkkgdGhpbmsgdGhhdCBpcyB3cm9u ZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5kIGdpdmVuIHRoYXQgb3RoZXINCnVw Z3JhZGVzIHRvIGV4aXN0aW5nIE1QTFMgc29sdXRpb25zIHdpbGwgYmUgbmVlZGVkIHRvIHJlYWNo IHRoZSBmdWxsDQpmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLg0KDQo+ICogdGhleSBoYWQgYSBn b29kIGNoYW5jZSB0byByZW1haW4gdGhlIG9ubHkgdHlwZSBvZiBiaWRpcmVjdGlvbmFsDQo+ICAg cGF0aHMgaW4gIHJlYWwgZGVwbG95bWVudHMuDQoNCkkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBmb2xs b3dzIGZyb20uDQoNCkNoZWVycywNCkFkcmlhbl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptcGxzLXRwIG1haWxpbmcgbGlzdA0KbXBscy10cEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgDQph cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50 aS1TcGFtIA0Kc3lzdGVtLg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3Bl cnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9u IGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBj b250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 003171E84825759B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnNhc2hhOjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7dGhhbmsgeW91IGZvciB5b3VyIGRl dGFpbCBleHBsYWluLA0KeW91IG1heSBiZSB0cnVlIGZvciB5b3VyIHVuZGVyc3RhbmRpbmcuIGhl cmUgSSBjYW4ndCBhZHZvY2F0ZSB0aGVyZSBtdXN0DQpiZSBUQ00gY29uY2VwdGlvbiBhbmQgZnVu Y2F0aW9uIGluIE1QTFMtVFAgcmVxdWlyZW1lbnQsICZuYnNwO2J1dCBtcGxzLXRwDQpzaG91bGQg aGF2ZSB0aGUgcmVxdWlyZW1lbnRzIG9mIHN1Yi1sYXllciBvciBzZWdlbWVudCBwcm90ZWN0aW9u cyBsaWtlDQpTTkNQIGluIFNESC9TT05FVCBuZXR3b3JrLiBtYXliZSB0aGUgcmVxdWlyZW1lbnRz IG5vdCBiZSBhcHBseWVkIGZvciBzb21lDQpzZXJ2aWNlIHByaXZpZGVycyxidXQgaXQgbWF5IHBy aXZpZGUgdGhlbSB3aXRoICZuYnNwO21vcmUgY2hvaWNlcyBmb3Igc2VydmljZQ0KcHJpdmlkZXJz LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+cmVnYXJk czwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+bGl1PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+QWxleGFuZGVyIFZhaW5zaHRl aW4gJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tJmd0OzwvYj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTE3IDE1OjQ5PC9mb250 Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90 O2xpdS5ndW9tYW5AenRlLmNvbS5jbiZxdW90OyAmbHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0 OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBscy10cEBpZXRmLm9yZyZxdW90OyAmbHQ7bXBs cy10cEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbbXBscy10cF0gQ28tcm91 dGVkIGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50ICh3YXM6IEFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KcmVxdWlyZW1lbnRzKTwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPkxpdSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+VGhhbmsgeW91IGZvciBhIHByb21wdCByZXNwb25zZS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UbyBtYWtlIGl0IGNsZWFyLCBJIGRpZCBub3QgYWR2 b2NhdGUNCjE6MSBsaW5lYXIgKGEuay5hLiBlbmQtdG8tZW5kKSBwcm90ZWN0aW9uIGZvciBNUExT LVRQLiBJJ3ZlIG9ubHkgbWVudGlvbmVkDQppdCBhcyB0aGUgb25seSAxOjEgcHJvdGVjdGlvbiBz Y2hlbWUgSSd2ZSBmb3VuZCBpbiB0aGUgTVBMUy1UUCBTdXJ2aXZhYmlsaXR5DQpGcmFtZXdvcmsg ZHJhZnQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VG8gdGFrZSBv bmUgc3RlcCBmdXJ0aGVyLCBJTUhPDQphbmQgRldJVywgc3BlY2lmaWMgcHJvdGVjdGlvbiBzY2hl bWVzIGFuZCBtb25pdG9yaW5nIG1lY2hhbmlzbXMgYXJlIG5vdA0KdGlnaHRseSBjb3VwbGVkLCBh bmQgcHJlZmVyYWJseSBzaG91bGQgcmVtYWluIHNvLiBIZW5jZSBhbnkgYXR0ZW1wdCB0bw0KanVz dGlmeSBleGlzdGVuY2Ugb2YgYSBjZXJ0YWluIG1vbml0b3JpbmcgbWVjaGFuaXNtIChhbmQgVENN IGNsZWFybHkgZmFsbHMNCmluIHRoZSB0aGlzIGNhdGVnb3J5IC0gaXQgc3RhbmRzIGZvciA8aT5U YW5kZW0gQ29ubmVjdGlvbiBNb25pdG9yaW5nPC9pPikNCmJ5IHJlZmVyZW5jZSB0byBhIGNlcnRh aW4gcHJvdGVjdGlvbiBzY2hlbWUgd291bGQgbG9vayBmYXVsdHkgdG8gbWUuIEFuZA0KaWYsIG9u IHRvcCBvZiB0aGlzLCB0aGUgcHJvdGVjdGlvbiBzY2hlbWUgaW4gcXVlc3Rpb24gaXMgbm90IGV2 ZW4gbWVudGlvbmVkDQpuIHRoZSBTdXJ2aXZhYmlsaXR5IEZyYW1ld29yayBkcmFmdC4uLiBubyBu ZWVkIHRvIGNvbnRpbnVlLCBJIHRoaW5rLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPihPZiBjb3Vyc2UgdGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQNCmFkZGl0aW9uYWwg cHJvdGVjdGlvbiBzY2hlbWVzIGNhbm5vdCBhcHBlYXIgaW4gdGhlIE1QTFMtVFAgU3Vydml2YWJp bGl0eQ0KRnJhbWV3b3JrIGRyYWZ0LiBPbiB0aGUgb3RoZXIgaGFuZCwgc29tZSBvZiB0aGUgc2No ZW1lcyBub3cgaW4gdGhlIGRyYWZ0DQptYXkgYmUgZXZlbnR1YWxseSBkcm9wcGVkIG9yLCBhdCBs ZWFzdCwgZG93bmdyYWRlZCBmcm9tIE1VU1QgdG8gU0hPVUxEDQpvciBNQVkuIEJ1dCB0aGlzIGlz IGEgZGlmZmVyZW50IHRvcGljKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ TGFzdCBidXQgbm90IGxlYXN0LCB3ZSBhcmUgY3VycmVudGx5DQpkaXNjdXNzaW5nIE1QTFMtVFAg cmVxdWlyZW1lbnRzLCBhbmQgdGhlc2UgcmVxdWlyZW1lbnRzIHByZXN1bWFibHkgc2hvdWxkDQpi ZSBiYXNlZCBvbiBleHBlcmllbmNlIG9mIHRoZSB0cmFuc3BvcnQgb3BlcmF0b3JzLiBBcyBzb21l IHBlb3BsZSAoaW5jbHVkaW5nDQpteXNlbGYpIGhhdmUgbm90ZWQsIGluIHRoZSB0d28gcm91bmRz IG9mIGVhcmxpZXIgZGlzY3Vzc2lvbnMgbm8gdHJhbnNwb3J0DQpvcGVyYXRvcnMgaGF2ZSBub3Qg ZXhwbGljaXRseSByZXF1aXJlZCBUQ00uICZuYnNwO0luIHRoaXMgKDNyZCEpIHJvdW5kDQphdCBs ZWFzdCBvbmUgbWFqb3Igb3BlcmF0b3IgaGFzIGV4cGxpY2l0bHkgc3RhdGVkIHRoYXQgVENNIGlz IG5vdCBuZWVkZWQuDQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5S ZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4m bmJzcDsgJm5ic3A7ICZuYnNwO1Nhc2hhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7PC9mb250Pg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206 PC9iPiBsaXUuZ3VvbWFuQHp0ZS5jb20uY24gW2xpdS5ndW9tYW5AenRlLmNvbS5jbl08Yj48YnI+ DQpTZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxNywgMjAwOSA2OjAzIEFNPGI+PGJyPg0KVG86PC9i PiBBbGV4YW5kZXIgVmFpbnNodGVpbjxiPjxicj4NCkNjOjwvYj4gbXBscy10cEBpZXRmLm9yZzxi Pjxicj4NClN1YmplY3Q6PC9iPiBSZTogW21wbHMtdHBdIENvLXJvdXRlZCBiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50DQood2FzOiBBc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpzYXNoYTo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiBpIGRvbid0IGFncmVl IHlvdXIgYWR2aWNlLCBpIHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSB0byBjb25zaWRlciBUQ00gZnVu Y3Rpb25hbGl0eQ0KYW5kIHByb3RlY3Rpb25zIGluIE1QTFMtVFAgc3Vydml2ZSBmcmFtZXdvcmsu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KaXQgaXMgY29tcGxleCBhbmQgY29zdCB0byBhcHBs eSBlbmQgdG8gZW5kIHByb3RlY3Rpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KdGhhbmsg eW91LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KbGl1PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkFsZXhhbmRlciBWYWluc2h0ZWluICZsdDtBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbSZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDQtMTYgMjI6MzI8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NSU+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2Zv bnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5N YWFydGVuIFZpc3NlcnMgJmx0O21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tJmd0OzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOt y808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90 O21wbHMtdHBAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtt cGxzLXRwXSBDby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1l bnQgKHdhczogQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQpyZXF1aXJl bWVudHMpPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KTWFhcnRl biw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KSSd2ZSBzY2FubmVkIHRoZSBNUExTLVRQ IFN1cnZpdmFiaWxpdHkgRnJhbWV3b3JrIGRyYWZ0ICg8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXN1cnZpdmUtZndr LTAwLnR4dCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjx1Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtbXBscy10cC1zdXJ2aXZlLWZ3ay0wMC50eHQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4pDQpidXQgZGlkIG5vdCBmaW5kIHRoZXJlIGFueSBy ZXF1aXJlbWVudHMgZm9yICZuYnNwOzE6MSBTTkMgcHJvdGVjdGlvbiAoaW5kZWVkLA0KdGhlIHRl cm0gU05DIGlzIG5vdCBtZW50aW9uZWQgaW4gdGhpcyBkb2N1bWVudCkuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KQW5kIEFGQUlLIDE6MSBsaW5lYXIgcHJvdGVj dGlvbiAod2hpY2ggaXMgbWVudGlvbmVkIGluIHRoZSBkcmFmdCkgZG9lcw0Kbm90IHJlcXVpcmUg YW55IFRDTSBmdW5jdGlvbmFsaXR5LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxicj4NCklmIHRoZSBmdW5jdGlvbmFsaXR5IHlvdSBoYXZlIGluIG1pbmQgaXMgY2FsbGVk IGJ5IGFueSBvdGhlciBuYW1lIGluIHRoZQ0KTVBMUy1UUCBTdXJ2aXZhYmlsaXR5IEZyYW1ld29y ayAsIGl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIHByb3ZpZGUNCmFuIGFwcHJvcHJpYXRl IG1hcHBpbmcuIElmIG5vdCwgbGV0IHVzIG5vdCB1c2UgaXQgYXMgYSBqdXN0aWZpY2F0aW9uIGZv cg0KYWRkaXRpb25hbCBPQU0gZnVuY3Rpb25hbGl0eSBsaWtlIFRDTS48L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpSZWdhcmRzLDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48YnI+DQogJm5ic3A7ICZuYnNwOyBTYXNoYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDs8YnI+DQogJm5ic3A7PGJyPg0KICZuYnNwOzxicj4N CiAmbmJzcDs8YnI+DQogJm5ic3A7PGJyPg0KICZuYnNwOzxicj4NCjwvZm9udD4NCjxocj48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gTWFhcnRlbiBWaXNzZXJzIFttYWFy dGVuLnZpc3NlcnNAaHVhd2VpLmNvbV08Yj48YnI+DQpTZW50OjwvYj4gVGh1cnNkYXksIEFwcmls IDE2LCAyMDA5IDM6MjkgUE08Yj48YnI+DQpUbzo8L2I+IEFsZXhhbmRlciBWYWluc2h0ZWluPGI+ PGJyPg0KQ2M6PC9iPiBtcGxzLXRwQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJFOiBb bXBscy10cF0gQ28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1l bnQNCih3YXM6IEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJl bWVudHMpPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NClNhc2hhLDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCkkgZG8gbm90IGFncmVlIHdpdGgg eW91IG5vciBBZHJpYW4gaW4gdGhpcyBtYXR0ZXIgYXMgZXhwbGFpbmVkIGluIG15IHJlc3BvbnNl DQp0byBBZHJpYW4ncyBlbWFpbCBhIGZldyBtaW51dGVzIGFnby48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KT25lIG9mIHRoZSBhcHBsaWNhdGlvbnMgdGhhdCB3 b3VsZCBub3QgbG9uZ2VyIGJlIGFibGUgdG8gZnVuY3Rpb24gd291bGQNCmJlIDE6MSBQVyBTTkMg cHJvdGVjdGlvbiBvciAxOjEgTFNQIFNOQyBwcm90ZWN0aW9uLiBGb3IgdGhvc2UgcHJvdGVjdGlv bg0KbWVjaGFuaXNtcyB3ZSBuZWVkIFRDTSBNRVAgZnVuY3Rpb25zIHRvIGRldGVybWluZSB0aGUg c3RhdHVzIG9mIGVhY2ggU05DLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFs Ij48YnI+DQpSZWdhcmRzLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwv Zm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KTWFhcnRlbjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD4N Cjxocj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gbXBscy10cC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5BbGV4YW5kZXIgVmFpbnNodGVpbjxiPjxicj4NClNlbnQ6PC9iPiBkb25kZXJk YWcgMTYgYXByaWwgMjAwOSAxMzo0MDxiPjxicj4NClRvOjwvYj4gQWRyaWFuIEZhcnJlbDxiPjxi cj4NCkNjOjwvYj4gQlVTSUBjb3JlMy5hbXNsLmNvbTsgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmc8 Yj48YnI+DQpTdWJqZWN0OjwvYj4gW21wbHMtdHBdIENvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50DQood2FzOiBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg dHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCkFkcmlhbiw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K TG9va3MgYXMgd2UgYXJlIG11Y2ggbW9yZSBpbiBhZ3JlZW1lbnQgdGhhbiBpdCBjb3VsZCBiZSBn dWVzc2VkIGZyb20gdGhlDQpmaXJzdCByb3VuZCBvZiBleGNoYW5nZXMuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KSSd2ZSBjaGFuZ2VkIHRoZSBzdWJqZWN0IHNpbmNl IHdlIGFyZSBhY3R1YWxseSBkaXNjdXNzaW5nIHNwZWNpZmljcyBvZg0KY28tcm91dGVkIGJpZGly ZWN0aW9uYWwgcGF0aHMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJy Pg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxicj4NCkkgZnVsbHkgc3VwcG9ydCB5b3VyIHByb3Bvc2FsIHRvIGdldCByaWQgKGlu IGEgY29uc2lzdGVudCBtYW5uZXIpIGZyb20NCnRoZSBUQyBzdHVmZiBpbiBNUExTLVRQLCBlc3Bl Y2lhbGx5IHNpbmNlLCB0byB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsDQpvcGVyYXRpb25hbCBl eHBlcmllbmNlIHdpdGggU09ORVQvU0RIIFRDTSAoSVRVLVQgZGVmaW5pdGlvbnMgbm90d2l0aHN0 YW5kaW5nKQ0KZGlkIG5vdCBwcm92ZSBpdHMgd29ydGguIElmIHRoaXMgaXMgYmFzZWQgb24gbWlz LXBlcmNlcHRpb24sIEkgd291bGQgYmUNCmdsYWQgdG8gaGVhciB0aGF0IChlc3BlY2lhbGx5IGZy b20gdGhlIG9wZXJhdG9ycyBvbiB0aGlzIGxpc3QpLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KQW5kIGlmIGl0IGlzIHBvc3NpYmxlIHRvIHJl LXdyaXRlIFJlcXVpcmVtZW50IDM0IGFzIGEgZnVuY3Rpb25hbC9iZWhhdmlvcg0KcmVxdWlyZW1l bnQsIGl0IHdvdWxkIGJlIGdyZWF0LCB0b28uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxicj4NCkhvd2V2ZXIsIEkgYW0gbm90IHN1cmUgdGhpcyB3b3VsZCBiZSBlYXN5IChC ZW4sIG15IGFwb2xvZ2llcyBhZ2FpbikuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48YnI+DQpSZWdhcmRzLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxicj4NCiAmbmJzcDsgJm5ic3A7IFNhc2hhPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KICZuYnNwOzxicj4NCiAmbmJzcDs8YnI+DQogJm5ic3A7 PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CkZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdPGJyPg0KU2VudDogVGh1 cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjU5IFBNPGJyPg0KVG86IEFsZXhhbmRlciBWYWluc2h0 ZWluOyBiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbTxicj4NCkNjOiBtcGxzLXRwQGlldGYu b3JnOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPGJyPg0KU3ViamVjdDogUmU6IFttcGxzLXRwXSBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzPGJyPg0K PGJyPg0KSGkgU2FzaGEsPGJyPg0KPGJyPg0KJmd0OyBVbmZvcnR1bmF0ZWx5IEkgY2Fubm90IGZ1 bGx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmx0O3F1 b3RlJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9m IGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KTFNQczxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExT UHMuPGJyPg0KJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMg c3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0IG5vdCBmb3IgUmVx dWlyZW1lbnQNCjM0PGJyPg0KJmd0OyBpbiB0aGUgbGF0ZXN0PGJyPg0KJmd0OyBNUExTLVRQIHJl cXVpcmVtZW50cyBkcmFmdDxicj4NCjxicj4NCk9LLiBHb3QgaXQuPGJyPg0KPGJyPg0KQnV0IHdo YXQgaXMgdGhpcyBkb2luZyBpbiB0aGUgZGF0YSBwbGFuZSByZXF1aXJlbWVudHMgc2VjdGlvbj88 YnI+DQo8YnI+DQpJbiBmYWN0LCB3aGF0IGlzIHRoaXMgcmVxdWlyZW1lbnQgYWN0dWFsbHkgc2F5 aW5nPzxicj4NCjxicj4NCiZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQN Cm90aGVyIGludGVybmFsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMg YXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF0aCBhdCBlYWNoIChzdWItKWxheWVyIE1V U1QgYmUgYXdhcmUgb2YgdGhlDQpwYWlyaW5nPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KZGlyZWN0aW9u cyBvZiB0aGF0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFuc3BvcnQgcGF0aC48 YnI+DQomZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJyPg0KPGJyPg0KVGhlcmUgaXMgbm8gd2F5IHRo aXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBUaGF0IGlzLCB0aGVyZSBpczxicj4NCipu b3RoaW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZp ZXcgdGhhdCByZXN1bHRzPGJyPg0KZnJvbSBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVtZW50Ljxi cj4NCjxicj4NClRoZXJlZm9yZSBpdCBjb3VsZCBiZSBhc3N1bWVkIHRoYXQgdGhpcyByZXF1aXJl bWVudCBpcyBtZXQgYnkgY29uZmlndXJpbmc8YnI+DQpzb21lIGRhdGEgcGxhbmUgZGF0YWJhc2Ug Y29tcG9uZW50IHRocm91Z2ggdGhlIG1hbmFnZW1lbnQgcGxhbmUuIFRoZTxicj4NCmRhdGFiYXNl IGNvbXBvbmVudCBpcyBub3QgdXNlZCBmb3IgYW55dGhpbmcgZXhjZXB0IHRvIHNhdGlzZnkgdGhp czxicj4NCnJlcXVpcmVtZW50IGZvciAmcXVvdDthd2FyZW5lc3MmcXVvdDsuPGJyPg0KPGJyPg0K QmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdyaXRlIHRoaXMgcmVxdWlyZW1lbnQgaW4gdGVy bXMgb2YgYmVoYXZpb3I/PGJyPg0KPGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVt ZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4gdGhlIGxpc3QgdGhhdA0KaXM8YnI+DQomZ3Q7IHNw ZWNpZmljPGJyPg0KJmd0OyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBw YWlyaW5nIHJlcXVpcmVtZW50cyBhdCBlbmQNCnBvaW50czxicj4NCiZndDsgZm9yIGNvLXJvdXRl ZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSBleGFjdGx5IHRoZSBzYW1l DQpldmVuPGJyPg0KJmd0OyBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50IGl0ZW1zIGlu IHRoZSByZXF1aXJlbWVudHMnIGxpc3QpLjxicj4NCiZndDsgSW4gb3RoZXIgd29yZHMsIHdpdGhv dXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlvbiBvZiBjby1yb3V0ZWQ8YnI+DQomZ3Q7IGJpZGly ZWN0aW9uYWw8YnI+DQomZ3Q7IHBhdGhzIHdvdWxkIGJlIHZvaWQgb2YgYW55IGRhdGEgcGxhbmUg Y29udGVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgc29tZXdoYXQgdmFndWUgc2NvcGUgb2Yg dGhpcyByZXF1aXJlbWVudCAoJnF1b3Q7b3RoZXIgaW50ZXJuYWwNCmZ1bmN0aW9uczxicj4NCiZn dDsgYXMgYXBwcm9wcmlhdGUmcXVvdDspIGNyZWF0ZXMgYSBzdXNwaWNpb24gdGhhdCBIVyBzdXBw b3J0IG9mIHRoZSBwYWlyaW5nPGJyPg0KJmd0OyBhd2FyZW5lc3M8YnI+DQomZ3Q7IG1heSBiZSBy ZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC48YnI+DQo8YnI+DQpUaGUgZW50aXJl dHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAmcXVvdDsoaW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5k IG90aGVyPGJyPg0KaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSZxdW90OyBzaG91 bGQgYmUgZGVsZXRlZC4gSXQgZG9lcyBub3QNCmFkZCB0bzxicj4NCiZxdW90O1RoZSBpbnRlcm1l ZGlhdGUgbm9kZXMuJnF1b3Q7PGJyPg0KPGJyPg0KJmd0OyBUaGUgZm9sbG93aW5nIHRleHQgaW4g dGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzIHN1c3BpY2lvbjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm bHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVt IGNvbm5lY3Rpb24gaXMgYW4gYXJiaXRyYXJ5IHBhcnQNCm9mIGE8YnI+DQomZ3Q7ICZuYnNwOyB0 cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pIGluZGVwZW5kZW50 bHkNCmZyb20gdGhlPGJyPg0KJmd0OyAmbmJzcDsgZW5kLXRvLWVuZCBtb25pdG9yaW5nIChPQU0p LiAmbmJzcDtJdCBtYXkgYmUgYSBtb25pdG9yZWQgc2VnbWVudA0Kb3IgYTxicj4NCiZndDsgJm5i c3A7IG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIHRyYW5zcG9ydCBwYXRoLiAm bmJzcDtUaGUNCnRhbmRlbTxicj4NCiZndDsgJm5ic3A7IGNvbm5lY3Rpb24gbWF5IGFsc28gaW5j bHVkZSB0aGUgZm9yd2FyZGluZyBlbmdpbmUocykgb2YgdGhlDQpub2RlKHMpPGJyPg0KJmd0OyAm bmJzcDsgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21l bnQuPGJyPg0KJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCjxicj4NCkFjdHVhbGx5LCBJIGFt IHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQgaW5zaXN0ZW5jZSBvbiB0aGU8YnI+ DQppbmNsdXNpb24gb2YgJnF1b3Q7VGFuZGVtIENvbm5lY3Rpb24uJnF1b3Q7IFRoZSBkZWZpbml0 aW9uIHdpdGhpbiB0aGUgSVRVLVQNCm9mIHRoaXM8YnI+DQp0ZXJtIGlzIHBvb3JseSBzcGVjaWZp ZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1vbml0b3Jpbmcgb2YgYSBwYXRoIHRoYXQgaXM8YnI+DQpw YXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBU aGlzIGRlZmluaXRpb24NCm9mPGJyPg0KVEMgc2VlbXMgdG8gYmUgYXQgdmFyaWFuY2UsIGFuZCB3 b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLjxicj4NCjxicj4NCiZndDsg RG9lc24ndCAmcXVvdDtmb3J3YXJkaW5nIGVuZ2luZSZxdW90OyBzb3VuZCBsaWtlIGhhcmR3YXJl IHRvIHlvdT88YnI+DQo8YnI+DQpZZXMsIGJ1dCBzbyB3aGF0Pzxicj4NCjxicj4NCiZndDsgSU1I TyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0aGVyIHRoZSBNUExTLVRQIFJlcXVpcmVtZW50 czxicj4NCiZndDsgZHJhZnQgbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25lPGJy Pg0KJmd0OyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1t cGxzLXRwLW9hbS1yZXF1aXJlbWVudHMtMDEudHh0KTxicj4NCiZndDsgY29udGFpbiBhbnkgcmVx dWlyZW1lbnRzIGRlYWxpbmcgd2l0aCB0YW5kZW0gY29ubmVjdGlvbnMuPGJyPg0KJmd0Ozxicj4N CiZndDsgQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBNUExTLVRQ IE9BTSBGcmFtZXdvcmsNCmRyYWZ0PGJyPg0KJmd0OyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcmFtZXdvcmstMDAudHh0KS48YnI+ DQo8YnI+DQpSaWdodC48YnI+DQpMZXQncyBqdXN0IGdldCByaWQgb2YgYW4gdW5uZWNlc3Nhcnkg dGVybSBhbmQgYnJpbmcgYWxsIHRoZSBJLURzIGludG8gbGluZS48YnI+DQo8YnI+DQomZ3Q7IFRo ZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nIGNvLXJv dXRlZCB2cy48YnI+DQomZ3Q7IGFzc29jaWF0ZWQ8YnI+DQomZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0 aHMgaXMgc3RpbGwgcmVxdWlyZWQuIE9uZSB3YXkgdG8gcHJvdmlkZSB0aGF0IGNvdWxkDQpiZSBi eTxicj4NCiZndDsgZXhwbGljaXRseTxicj4NCiZndDsgbGltaXRpbmcgUmVxdWlyZW1lbnQgMzQg dG8gc3BlY2lmaWMgZnVuY3Rpb25hbGl0eS48YnI+DQo8YnI+DQpBZ3JlZWQuPGJyPg0KPGJyPg0K QWRyaWFuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCkZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRk b2cuY28udWtdPGJyPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjEzIEFNPGJy Pg0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPGJyPg0K Q2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHM8YnI+DQo8YnI+DQpI aSBTYXNoYSw8YnI+DQo8YnI+DQpOb3QgcmVhbGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3Jl cHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLjxicj4NCjxicj4NCiZndDsgMS4gTXkgcmVhZGluZyBv ZiAmbmJzcDtvbmUgb2YgQmVuJ3MgJm5ic3A7bWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkPGJy Pg0KJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBvZiBwYXRocyB0 aGF0IGNhbiBiZTxicj4NCiZndDsgY3JlYXRlZCBpbiB0aGUgZXhpc3RpbmcgbmV0d29ya3M7ICZx dW90O3RydWUmcXVvdDsgY28tcm91dGVkIGJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7IHBhdGhzIHdp bGwgaGF2ZSB0byB3YWl0IHVudGlsIChpZiBldmVyKSBuZXcgZXF1aXBtZW50IGJlY29tZXM8YnI+ DQomZ3Q7IGF2YWlsYWJsZS48YnI+DQo8YnI+DQpUaGlzIGlzIGNsZWFybHkgbm9uc2Vuc2UhPGJy Pg0KRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwgTFNQcyBhcmUgYTxicj4NCnNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgTFNQcy48YnI+DQo8YnI+DQpJZiB5b3UgY2FuIHNldCB1cCB0d28gdW5pZGlyZWN0aW9u YWwgTFNQcyAoZS5nLiB1c2luZyB0aGUgbWFuYWdlbWVudCBwbGFuZSk8YnI+DQp5b3UgY2FuIHN1 cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuPGJyPg0KPGJyPg0KVGhl cmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwgTFNQcw0KdXNpbmc8YnI+DQp0aGUgY29udHJvbCBwbGFuZS4gVGhlc2UgZWl0aGVyIHVz ZSB0aGUgR01QTFMgKHdoaWNoIGlzIGNsZWFuZXIpIG9yPGJyPg0Kbm9uLXN0YW5kYXJkIHByb3By aWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMgbWVzc3kgYnV0IGZ1bmN0aW9uYWwpLjxicj4NCjxi cj4NCkJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5l IHNvbHV0aW9ucyBoYXZlIG5vdGhpbmc8YnI+DQp0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBl cXVpcG1lbnQgYXMgdGhleSBhcmUgc29mdHdhcmUgc29sdXRpb25zLjxicj4NCjxicj4NCiZndDsg Mi4gTXkgcmVhZGluZyBvZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRoYXQgdGhlIGFjdHVh bCBkcml2ZXINCmZvcjxicj4NCiZndDsgY28tcm91dGVkPGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFs IHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtz PGJyPg0KJmd0OyByYXRoZXI8YnI+DQomZ3Q7IHRoYW4gYW55IHNwZWNpZmljIGJlbmVmaXQuPGJy Pg0KPGJyPg0KSXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUgTVBMUy1UUCByZXF1 aXJlbWVudHM/PGJyPg0KV2hpY2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0aGluZy48YnI+ DQo8YnI+DQpBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNrZXQg bmV0d29yayB0aGUgbG9vaywgZmVlbCwNCmFuZDxicj4NCmJlaGF2aW9yYWwgY2hhcmFjdGVyaXN0 aWNzIG9mIGEgJnF1b3Q7bGVnYWN5JnF1b3Q7IHRyYW5zcG9ydCBuZXR3b3JrLjxicj4NCjxicj4N CiZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRoYXQ6 PGJyPg0KJmd0OyAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0 IGZvciB0aGUgdGltZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2JlaW5nLCB0aGUgbW9zdCBpbXBv cnRhbnQgdHlwZSBvZiBiaWRpcmVjdGlvbmFsIHBhdGhzDQppbjxicj4NCiZndDsgJm5ic3A7ICZu YnNwO01QTFMtVFA8YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgaXMgd3JvbmcgYm90aCBnaXZlbiBt eSBzdGF0ZW1lbnQgYWJvdmUsIGFuZCBnaXZlbiB0aGF0IG90aGVyPGJyPg0KdXBncmFkZXMgdG8g ZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZSBuZWVkZWQgdG8gcmVhY2ggdGhlIGZ1bGw8 YnI+DQpmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLjxicj4NCjxicj4NCiZndDsgKiB0aGV5IGhh ZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBlIG9mIGJpZGlyZWN0aW9uYWw8 YnI+DQomZ3Q7ICZuYnNwOyBwYXRocyBpbiAmbmJzcDtyZWFsIGRlcGxveW1lbnRzLjxicj4NCjxi cj4NCkkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBmb2xsb3dzIGZyb20uPGJyPg0KPGJyPg0KQ2hlZXJz LDxicj4NCkFkcmlhbjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+ DQptcGxzLXRwQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzLXRwPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0Pi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwNCmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90 aGVycy48YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lz dGVtLjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3Jt YXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlv biZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNw O3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNw O29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJz cDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDth Ym92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtz ZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8m bmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5i c3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJz cDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5i c3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0 aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZu YnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNw O3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNw O3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZu YnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNw O2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3Rl bS4NCjwvcHJlPg== --=_alternative 003171E84825759B_=-- From Italo.Busi@alcatel-lucent.it Fri Apr 17 02:12:57 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D3A3A6AC7 for ; Fri, 17 Apr 2009 02:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2aFgwidykQd for ; Fri, 17 Apr 2009 02:12:56 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 4AB073A6814 for ; Fri, 17 Apr 2009 02:12:56 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H9E62n001579; Fri, 17 Apr 2009 11:14:07 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 11:14:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 11:14:05 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B187E@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <49E73762.5060207@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+miruivq4Vgc9TCaFn0uwzmLP2wAItLyw References: <001901c9bc0a$dc6fd060$6802a8c0@china.huawei.com><6FD21B53861BF44AA90A288402036AB402145621@FRVELSMBS21.ad2.ad.alcatel.com><49E5EEC8.6080101@labn.net><6FD21B53861BF44AA90A288402036AB4021B1686@FRVELSMBS21.ad2.ad.alcatel.com> <49E73762.5060207@labn.net> From: "BUSI ITALO" To: "Lou Berger" X-OriginalArrivalTime: 17 Apr 2009 09:14:06.0457 (UTC) FILETIME=[DBDF7E90:01C9BF3C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:12:57 -0000 Lou, Looking at the on-going discussion I would call it "not-yet resolved" comment ;-) Italo=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Thursday, April 16, 2009 3:49 PM > To: BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Ahh, I missed that you were re-raising a comment that was=20 > rejected. As=20 > Ben says, "all standards work it is about compromise"... >=20 > Thanks, > Lou >=20 > On 4/16/2009 9:10 AM, BUSI ITALO wrote: > > Lou, > > > > That's was one of my WG LC comments. > > > > Italo > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Wednesday, April 15, 2009 4:27 PM > >> To: BUSI ITALO > >> Cc: Maarten Vissers; Ben Niven-Jenkins; mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] Associated bidirectional transport > >> path requirements > >> > >> Italo, > >> > >> On 4/14/2009 6:12 AM, BUSI ITALO wrote: > >>> 2) we need to be clear that asssociated bidirectional=20 > paths are not > >>> required in transport networks (e.g. MPLS-TP) > >>> > >> This doesn't match draft-ietf-mpls-tp-requirements-06. Are you > >> proposing dropping associated bidirectional path from the TP > >> requirements document? > >> > >> Lou > >> > >> > >> > > > > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 02:13:55 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DBA3A6D52 for ; Fri, 17 Apr 2009 02:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.922 X-Spam-Level: X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHJ5egPuhaee for ; Fri, 17 Apr 2009 02:13:54 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id E24BA3A6AC7 for ; Fri, 17 Apr 2009 02:13:53 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H9ClNr011246; Fri, 17 Apr 2009 11:13:01 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 11:12:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 11:12:56 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B187A@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <49E735ED.3060402@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+mUwvZpucsMuSTLGY0Cv+5nv7pgAoilhQ References: <49E735ED.3060402@labn.net> From: "BUSI ITALO" To: "Lou Berger" , "Ben Niven-Jenkins" X-OriginalArrivalTime: 17 Apr 2009 09:12:58.0054 (UTC) FILETIME=[B31A0660:01C9BF3C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: BUSI@core3.amsl.com, mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:13:55 -0000 Lou, I am not 100% sure we have a common understanding of what "service level requirement" means. However, I agree with your proposal to move requirements 32-37 in section 2.1 (e.g. after Req.6) as well as to explicitly add the requirement for symmetric BW support. The only point that we still need to address is that we need to clarify that associated bidirectional paths are not required in transport networks but in traditional MPLS networks. Italo > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Thursday, April 16, 2009 3:43 PM > To: Ben Niven-Jenkins > Cc: Alexander Vainshtein; Adrian Farrel; BUSI ITALO;=20 > BUSI@core3.amsl.com; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Ben, > It seems to me that much of the discussion stems from=20 > the section in=20 > which these requirements are listed. >=20 > Requirement 32 is a service level requirement and primarily=20 > impact the=20 > management and control planes. As there is no section describing=20 > service requirements, I suggest moving this requirement to follow=20 > requirement 6, and adding the following in its place: > 33 MPLS-TP MUST support bidirectional transport paths with > symmetric bandwidth requirements, i.e. the amount of reserved > bandwidth is the same between the forward and backward > directions. >=20 > While this too is a service requirement and doesn't require=20 > any hardware=20 > modifications, it parallels current requirements 37, 40 and=20 > 41. It also=20 > makes a currently implicit requirement explicit. >=20 > Requirements 33-26 relate to "awareness" should have no=20 > implication on=20 > the data/forwarding plane and are IMO both management and=20 > control plane=20 > requirements. (And yes, they have implications on OAM and=20 > recovery.) I=20 > think Adrian raises a good point WRT these requirements,=20 > i.e., are these=20 > requirements listed as solutions to some unlisted=20 > requirements. If so,=20 > the unlisted requirements should be included and these should be=20 > dropped. If not, so be it, but they should be moved from section 2.3. >=20 > While I'm sure this won't end the discussion, I think these=20 > changes will=20 > help make "the requirements clear enough ..." >=20 > Lou >=20 > On 4/16/2009 5:58 AM, Ben Niven-Jenkins wrote: > > Colleagues, > > > > I can't help but feel we are overanalysing things here. How many > > technologies/protocols/mechanisms have we successfully=20 > defined in both IETF > > & ITU-T without this level of analysis of the initial=20 > requirements - a great > > many (a good chunk of which were extremely successful). > > > > The requirements document is not about specifying solutions. > > > > The key question is: are the requirements clear enough that=20 > it is understood > > what is required so someone could build a=20 > box/protocol/whatever to meet > > them? > > > > If we want to go into the nth level of detail on each=20 > requirement we will > > still be debating this by the time I retire (which isn't=20 > due until 2045). > > > > Ben > > > > > > On 16/04/2009 08:04, "Alexander Vainshtein" > > wrote: > > > >> Adrian, > >> Thank you for a prompt and detailed response. > >> > >> Unfortunately I cannot fully agree with your statement: > >> > >> > >> From the point of view of hardware, co-routed=20 > bidirectional LSPs > >> are a special case of associated bidirectional LSPs. > >> > >> > >> This statement would be obviously correct, were it not for=20 > Requirement 34 in > >> the latest > >> MPLS-TP requirements draft > >>=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requir > ements-06.txt): > >> > >> > >> The intermediate nodes (including MEPs, MIPs and=20 > other internal > >> functions as appropriate) of a co-routed=20 > bidirectional transport > >> path at each (sub-)layer MUST be aware of the pairing > >> relationship of the forward and the backward=20 > directions of that > >> transport path. > >> > >> > >> Please note that Requirement 34 is the ONLY item in the=20 > list that is specific > >> for co-routed bidirectional LSPs. (The pairing=20 > requirements at end points > >> for co-routed and associated bidirectional paths are=20 > exactly the same even > >> if they appear in two different items in the requirements' list). > >> In other words, without Requirement 34 the notion of=20 > co-routed bidirectional > >> paths would be void of any data plane content. > >> > >> The somewhat vague scope of this requirement ("other=20 > internal functions > >> as appropriate") creates a suspicion that HW support of=20 > the pairing awareness > >> may be required in order to comply with it. > >> > >> The following text in the draft increases this suspicion: > >> > >> > >> Tandem Connection: A tandem connection is an arbitrary=20 > part of a > >> transport path that can be monitored (via OAM)=20 > independently from the > >> end-to-end monitoring (OAM). It may be a monitored=20 > segment or a > >> monitored concatenated segment of a transport path. The tandem > >> connection may also include the forwarding engine(s)=20 > of the node(s) > >> at the edge(s) of the segment or concatenated segment. > >> > >> > >> Doesn't "forwarding engine" sound like hardware to you? > >> > >> IMHO it is worth noting that neither the MPLS-TP Requirements draft > >> nor the MPLS-TP OAM requirements one > >>=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-re > quirements-01.tx > >> t) > >> contain any requirements dealing with tandem connections. > >> > >> But tandem connections are discussed in the MPLS-TP OAM=20 > Framework draft > >>=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > amework-00.txt). > >> > >> The bottom line, IMHO, is that some clarity regarding=20 > co-routed vs. associated > >> bidirectional > >> paths is still required. One way to provide that could be=20 > by explicitly > >> limiting Requirement 34 > >> to specific functionality. > >> > >> My 2c, > >> Sasha > >> > >> > >> > >> > >> > >> ________________________________________ > >> From: Adrian Farrel [adrian@olddog.co.uk] > >> Sent: Thursday, April 16, 2009 12:13 AM > >> To: Alexander Vainshtein; Lou Berger; BUSI ITALO > >> Cc: mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements > >> > >> Hi Sasha, > >> > >> Not really sure whether you are misrepresenting anyone, but... > >> > >>> 1. My reading of one of Ben's messages is that associated > >>> bidirectional paths are the only types of paths that can be > >>> created in the existing networks; "true" co-routed bidirectional > >>> paths will have to wait until (if ever) new equipment becomes > >>> available. > >> This is clearly nonsense! > >> From the point of view of hardware, co-routed=20 > bidirectional LSPs are a > >> special case of associated bidirectional LSPs. > >> > >> If you can set up two unidirectional LSPs (e.g. using the=20 > management plane) > >> you can surely set up a co-routed bidirectional LSP. > >> > >> There are shipping solutions that achieve co-routed=20 > bidirectional LSPs using > >> the control plane. These either use the GMPLS (which is cleaner) or > >> non-standard proprietary solutions (which is messy but functional). > >> > >> But (of course) the management plane or control plane=20 > solutions have nothing > >> to do with availability of equipment as they are software=20 > solutions. > >> > >>> 2. My reading of one of Neil's messages is that the=20 > actual driver for > >>> co-routed > >>> bidirectional paths may be experience with existing=20 > transport networks > >>> rather > >>> than any specific benefit. > >> Isn't that the case with 75% of the MPLS-TP requirements? > >> Which is not to say it is a bad thing. > >> > >> A large driver for MPLS-TP is to give the packet network=20 > the look, feel, and > >> behavioral characteristics of a "legacy" transport network. > >> > >>> Based on these observations, I'd guess (FWIW) that: > >>> * associated bidirectional paths are, at least for the time > >>> being, the most important type of bidirectional paths in > >>> MPLS-TP > >> I think that is wrong both given my statement above, and=20 > given that other > >> upgrades to existing MPLS solutions will be needed to=20 > reach the full > >> function level of MPLS-TP. > >> > >>> * they had a good chance to remain the only type of bidirectional > >>> paths in real deployments. > >> I don't see what that follows from. > >> > >> Cheers, > >> Adrian > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 02:14:03 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB2E3A6C1B for ; Fri, 17 Apr 2009 02:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.929 X-Spam-Level: X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfKeebkfeP-H for ; Fri, 17 Apr 2009 02:14:01 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id D5E1B3A6814 for ; Fri, 17 Apr 2009 02:14:00 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H9E0oO004267; Fri, 17 Apr 2009 11:14:01 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 11:14:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF3C.D830AD26" Date: Fri, 17 Apr 2009 11:13:59 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B187D@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/poA2AgAAgP/qAADfpIA== References: , <007701c9be8f$04d97250$6570ca0a@china.huawei.com> From: "BUSI ITALO" To: "Alexander Vainshtein" , "Maarten Vissers" X-OriginalArrivalTime: 17 Apr 2009 09:14:00.0562 (UTC) FILETIME=[D85BFD20:01C9BF3C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:14:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF3C.D830AD26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, =20 the survivability framework should be a document that describes a framework for the solutions that meet MPLS-TP survivability requirements. =20 MPLS-TP Survivability Requirements are defined in section 2.8 of draft-ietf-mpls-tp-requirements-06. =20 In particular Req.56 requirese the capability of MPLS-TP to protect a segment or a concatenated segment of a transport path: =20 56 MPLS-TP recovery mechanisms MUST be applicable at various levels throughout the network including support for link, transport path, segment, concatenated segment and end to end recovery. My understanding is that SNCP means protecting a segment or concatenated segment of a transport path. =20 If my understanding is correct we can catch this translation in the next update of the Rosetta stone draft. =20 Italo ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Thursday, April 16, 2009 4:32 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) =09 =09 Maarten, I've scanned the MPLS-TP Survivability Framework draft (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-00.t xt) but did not find there any requirements for 1:1 SNC protection (indeed, the term SNC is not mentioned in this document). =20 And AFAIK 1:1 linear protection (which is mentioned in the draft) does not require any TCM functionality. =20 If the functionality you have in mind is called by any other name in the MPLS-TP Survivability Framework , it would be nice if you could provide an appropriate mapping. If not, let us not use it as a justification for additional OAM functionality like TCM. =20 Regards, Sasha =20 =20 =20 =20 =20 =20 ________________________________ From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Thursday, April 16, 2009 3:29 PM To: Alexander Vainshtein Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) =09 =09 Sasha, =20 I do not agree with you nor Adrian in this matter as explained in my response to Adrian's email a few minutes ago. =20 One of the applications that would not longer be able to function would be 1:1 PW SNC protection or 1:1 LSP SNC protection. For those protection mechanisms we need TCM MEP functions to determine the status of each SNC. =20 Regards, Maarten ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 16 april 2009 13:40 To: Adrian Farrel Cc: BUSI@core3.amsl.com; ITALO; mpls-tp@ietf.org Subject: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements) =09 =09 Adrian, Looks as we are much more in agreement than it could be guessed from the first round of exchanges. I've changed the subject since we are actually discussing specifics of co-routed bidirectional paths. =20 I fully support your proposal to get rid (in a consistent manner) from the TC stuff in MPLS-TP, especially since, to the best of my knowledge, operational experience with SONET/SDH TCM (ITU-T definitions notwithstanding) did not prove its worth. If this is based on mis-perception, I would be glad to hear that (especially from the operators on this list). =20 And if it is possible to re-write Requirement 34 as a functional/behavior requirement, it would be great, too. However, I am not sure this would be easy (Ben, my apologies again). =20 Regards, Sasha =20 =20 =20 =09 ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Thursday, April 16, 2009 12:59 PM To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com Cc: mpls-tp@ietf.org; Lou Berger; BUSI ITALO Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Hi Sasha, =09 > Unfortunately I cannot fully agree with your statement: > > > From the point of view of hardware, co-routed bidirectional LSPs > are a special case of associated bidirectional LSPs. > > > This statement would be obviously correct, were it not for Requirement 34 > in the latest > MPLS-TP requirements draft =09 OK. Got it. =09 But what is this doing in the data plane requirements section? =09 In fact, what is this requirement actually saying? =09 > > The intermediate nodes (including MEPs, MIPs and other internal > functions as appropriate) of a co-routed bidirectional transport > path at each (sub-)layer MUST be aware of the pairing > relationship of the forward and the backward directions of that > transport path. > =09 There is no way this is a functional requirement. That is, there is *nothing* that can be observed from a black box point of view that results from adhering to this requirement. =09 Therefore it could be assumed that this requirement is met by configuring some data plane database component through the management plane. The database component is not used for anything except to satisfy this requirement for "awareness". =09 Ben! Can we please try to rewrite this requirement in terms of behavior? =09 > Please note that Requirement 34 is the ONLY item in the list that is > specific > for co-routed bidirectional LSPs. (The pairing requirements at end points > for co-routed and associated bidirectional paths are exactly the same even > if they appear in two different items in the requirements' list). > In other words, without Requirement 34 the notion of co-routed > bidirectional > paths would be void of any data plane content. > > The somewhat vague scope of this requirement ("other internal functions > as appropriate") creates a suspicion that HW support of the pairing > awareness > may be required in order to comply with it. =09 The entirety of the bracketted text "(including MEPs, MIPs and other internal functions as appropriate)" should be deleted. It does not add to "The intermediate nodes." =09 > The following text in the draft increases this suspicion: > > > Tandem Connection: A tandem connection is an arbitrary part of a > transport path that can be monitored (via OAM) independently from the > end-to-end monitoring (OAM). It may be a monitored segment or a > monitored concatenated segment of a transport path. The tandem > connection may also include the forwarding engine(s) of the node(s) > at the edge(s) of the segment or concatenated segment. > =09 Actually, I am quite fed up about this persistent insistence on the inclusion of "Tandem Connection." The definition within the ITU-T of this term is poorly specified and comes from the monitoring of a path that is parallel (i.e. tandem) to the data path being monitored. This definition of TC seems to be at variance, and would be if the ACH was actually in band. =09 > Doesn't "forwarding engine" sound like hardware to you? =09 Yes, but so what? =09 > IMHO it is worth noting that neither the MPLS-TP Requirements > draft nor the MPLS-TP OAM requirements one > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements -01.txt) > contain any requirements dealing with tandem connections. > > But tandem connections are discussed in the MPLS-TP OAM Framework draft > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00 .txt). =09 Right. Let's just get rid of an unnecessary term and bring all the I-Ds into line. =09 > The bottom line, IMHO, is that some clarity regarding co-routed vs. > associated > bidirectional paths is still required. One way to provide that could be by > explicitly > limiting Requirement 34 to specific functionality. =09 Agreed. =09 Adrian =09 =09 =09 =09 ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Thursday, April 16, 2009 12:13 AM To: Alexander Vainshtein; Lou Berger; BUSI ITALO Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Hi Sasha, =09 Not really sure whether you are misrepresenting anyone, but... =09 > 1. My reading of one of Ben's messages is that associated > bidirectional paths are the only types of paths that can be > created in the existing networks; "true" co-routed bidirectional > paths will have to wait until (if ever) new equipment becomes > available. =09 This is clearly nonsense! From the point of view of hardware, co-routed bidirectional LSPs are a special case of associated bidirectional LSPs. =09 If you can set up two unidirectional LSPs (e.g. using the management plane) you can surely set up a co-routed bidirectional LSP. =09 There are shipping solutions that achieve co-routed bidirectional LSPs using the control plane. These either use the GMPLS (which is cleaner) or non-standard proprietary solutions (which is messy but functional). =09 But (of course) the management plane or control plane solutions have nothing to do with availability of equipment as they are software solutions. =09 > 2. My reading of one of Neil's messages is that the actual driver for > co-routed > bidirectional paths may be experience with existing transport networks > rather > than any specific benefit. =09 Isn't that the case with 75% of the MPLS-TP requirements? Which is not to say it is a bad thing. =09 A large driver for MPLS-TP is to give the packet network the look, feel, and behavioral characteristics of a "legacy" transport network. =09 > Based on these observations, I'd guess (FWIW) that: > * associated bidirectional paths are, at least for the time > being, the most important type of bidirectional paths in > MPLS-TP =09 I think that is wrong both given my statement above, and given that other upgrades to existing MPLS solutions will be needed to reach the full function level of MPLS-TP. =09 > * they had a good chance to remain the only type of bidirectional > paths in real deployments. =09 I don't see what that follows from. =09 Cheers, Adrian ------_=_NextPart_001_01C9BF3C.D830AD26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha,

the survivability framework should be a document that describes = a=20 framework for the solutions that meet MPLS-TP survivability=20 requirements.

MPLS-TP Survivability Requirements are defined in section 2.8 = of=20 draft-ietf-mpls-tp-requirements-06.

In particular Req.56 requirese the capability of MPLS-TP = to protect=20 a segment or a concatenated segment of a transport = path:

   56 MPLS-TP recovery mechanisms MUST be = applicable at=20 various levels
       throughout the = network=20 including support for link, = transport
      =20 path, segment, concatenated segment and end to end=20 recovery.

My=20 understanding is that SNCP means protecting a segment or concatenated = segment of=20 a transport path.

If my=20 understanding is correct we can catch this translation in the next = update of the=20 Rosetta stone draft.

Italo

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: Thursday, April 16, 2009 4:32 = PM
To:=20 Maarten Vissers
Cc: mpls-tp@ietf.org
Subject: Re:=20 [mpls-tp] Co-routed bidirectional transport path requirement (was: = Associated=20 bidirectional transport path requirements)

Maarten,

I've scanned the MPLS-TP = Survivability Framework draft (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-= fwk-00.txt)=20 but did not find there any requirements for 1:1 SNC protection = (indeed,=20 the term SNC is not mentioned in this document).

And=20 AFAIK 1:1 linear protection (which is mentioned in the draft) = does not=20 require any TCM functionality.

If the functionality you = have in=20 mind is called by any other name in the MPLS-TP Survivability = Framework , it=20 would be nice if you could provide an appropriate mapping. If not, let = us not=20 use it as a justification for additional OAM functionality like=20 TCM.

Regards,

     = Sasha

From: Maarten Vissers=20 [maarten.vissers@huawei.com]
Sent: Thursday, April 16, 2009 = 3:29=20 PM
To: Alexander Vainshtein
Cc:=20 mpls-tp@ietf.org
Subject: RE: [mpls-tp] Co-routed = bidirectional=20 transport path requirement (was: Associated bidirectional transport = path=20 requirements)

Sasha,

I do not agree with you nor Adrian in this = matter as=20 explained in my response to Adrian's email a few minutes=20 ago.

One of the applications that would not longer = be able to=20 function would be 1:1 PW SNC protection or 1:1 LSP SNC protection. For = those=20 protection mechanisms we need TCM MEP functions to determine the = status of=20 each SNC.

Regards,

Maarten

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: donderdag 16 april 2009 13:40
To: = Adrian=20 Farrel
Cc: BUSI@core3.amsl.com; ITALO;=20 mpls-tp@ietf.org
Subject: [mpls-tp] Co-routed bidirectional=20 transport path requirement (was: Associated bidirectional transport = path=20 requirements)

Adrian,

Looks as we are much more in agreement than = it could be=20 guessed from the first round of exchanges.

I've changed the = subject since=20 we are actually discussing specifics of co-routed bidirectional=20 paths.

I fully support your = proposal to=20 get rid (in a consistent manner) from the TC stuff in MPLS-TP, = especially=20 since, to the best of my knowledge, operational experience with SONET/SDH TCM (ITU-T = definitions=20 notwithstanding) did not prove its worth. If this is based on = mis-perception,=20 I would be glad to hear that (especially from the operators on this=20 list).

And if it is = possible to=20 re-write Requirement 34 as a functional/behavior requirement, it would = be=20 great, too.

However, I am not = sure this=20 would be easy (Ben, my apologies again).

Regards,

    =20 Sasha

________________________________________
Fr= om:=20 Adrian Farrel [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 = 12:59=20 PM
To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com
Cc:=20 mpls-tp@ietf.org; Lou Berger; BUSI ITALO
Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path requirements

Hi Sasha,

> = Unfortunately I cannot fully agree with your = statement:
>
>=20 <quote>
>     From the point of view = of=20 hardware, co-routed bidirectional LSPs
>     = are a=20 special case of associated bidirectional LSPs.
> <end=20 quote>
>
> This statement would be obviously correct, = were it=20 not for Requirement 34
> in the latest
> MPLS-TP = requirements=20 draft

OK. Got it.

But what is this doing in the data = plane=20 requirements section?

In fact, what is this requirement = actually=20 saying?

> = <quote>
>      The=20 intermediate nodes (including MEPs, MIPs and other=20 internal
>       functions as = appropriate)=20 of a co-routed bidirectional=20 transport
>       path at each = (sub-)layer=20 MUST be aware of the = pairing
>      =20 relationship of the forward and the backward directions of=20 that
>       transport = path.
>=20 <end quote>

There is no way this is a functional = requirement.=20 That is, there is
*nothing* that can be observed from a black box = point of=20 view that results
from adhering to this = requirement.

Therefore it=20 could be assumed that this requirement is met by configuring
some = data=20 plane database component through the management plane. The
database = component is not used for anything except to satisfy = this
requirement for=20 "awareness".

Ben! Can we please try to rewrite this requirement = in=20 terms of behavior?

> Please note that Requirement 34 is the = ONLY=20 item in the list that is
> specific
> for co-routed = bidirectional=20 LSPs. (The pairing requirements at end points
> for co-routed = and=20 associated bidirectional paths are exactly the same even
> if = they=20 appear in two different items in the requirements' list).
> In = other=20 words, without Requirement 34 the notion of co-routed
>=20 bidirectional
> paths would be void of any data plane=20 content.
>
> The somewhat vague scope of this requirement = ("other=20 internal functions
> as appropriate") creates a suspicion that = HW=20 support of the pairing
> awareness
> may be required in = order to=20 comply with it.

The entirety of the bracketted text "(including = MEPs,=20 MIPs and other
internal functions as appropriate)" should be = deleted. It=20 does not add to
"The intermediate nodes."

> The following = text in=20 the draft increases this suspicion:
>
>=20 <quote>
>   Tandem Connection: A tandem = connection is an=20 arbitrary part of a
>   transport path that can be = monitored=20 (via OAM) independently from the
>   end-to-end = monitoring=20 (OAM). It may be a monitored segment or a
>   = monitored=20 concatenated segment of a transport path. The = tandem
>  =20 connection may also include the forwarding engine(s) of the=20 node(s)
>   at the edge(s) of the segment or = concatenated=20 segment.
> <end quote>

Actually, I am quite fed up = about=20 this persistent insistence on the
inclusion of "Tandem Connection." = The=20 definition within the ITU-T of this
term is poorly specified and = comes from=20 the monitoring of a path that is
parallel (i.e. tandem) to the data = path=20 being monitored. This definition of
TC seems to be at variance, and = would=20 be if the ACH was actually in band.

> Doesn't "forwarding = engine"=20 sound like hardware to you?

Yes, but so what?

> IMHO = it is=20 worth noting that neither the MPLS-TP Requirements
> draft nor = the=20 MPLS-TP OAM requirements one
>=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-= 01.txt)
>=20 contain any requirements dealing with tandem = connections.
>
> But=20 tandem connections are discussed in the MPLS-TP OAM Framework = draft
>=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.= txt).

Right.
Let's=20 just get rid of an unnecessary term and bring all the I-Ds into=20 line.

> The bottom line, IMHO, is that some clarity = regarding=20 co-routed vs.
> associated
> bidirectional paths is still=20 required. One way to provide that could be by
> = explicitly
>=20 limiting Requirement 34 to specific=20 = functionality.

Agreed.

Adrian

__________= ______________________________
From:=20 Adrian Farrel [adrian@olddog.co.uk]
Sent: Thursday, April 16, 2009 = 12:13=20 AM
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc:=20 mpls-tp@ietf.org
Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements

Hi Sasha,

Not really sure whether you = are=20 misrepresenting anyone, but...

> 1. My reading of one = of=20 Ben's messages is that associated
> bidirectional paths = are the=20 only types of paths that can be
> created in the existing = networks;=20 "true" co-routed bidirectional
> paths will have to wait until = (if ever)=20 new equipment becomes
> available.

This is clearly=20 nonsense!
From the point of view of hardware, co-routed = bidirectional LSPs=20 are a
special case of associated bidirectional LSPs.

If you = can set=20 up two unidirectional LSPs (e.g. using the management plane)
you = can surely=20 set up a co-routed bidirectional LSP.

There are shipping = solutions that=20 achieve co-routed bidirectional LSPs using
the control plane. These = either=20 use the GMPLS (which is cleaner) or
non-standard proprietary = solutions=20 (which is messy but functional).

But (of course) the management = plane=20 or control plane solutions have nothing
to do with availability of=20 equipment as they are software solutions.

> 2. My reading of = one of=20 Neil's messages is that the actual driver for
> = co-routed
>=20 bidirectional paths may be experience with existing transport = networks
>=20 rather
> than any specific benefit.

Isn't that the case = with 75%=20 of the MPLS-TP requirements?
Which is not to say it is a bad=20 thing.

A large driver for MPLS-TP is to give the packet network = the=20 look, feel, and
behavioral characteristics of a "legacy" transport=20 network.

> Based on these observations, I'd guess (FWIW)=20 that:
> * associated bidirectional paths are, at least for the=20 time
>    being, the most important type of = bidirectional=20 paths in
>    MPLS-TP

I think that is = wrong both=20 given my statement above, and given that other
upgrades to existing = MPLS=20 solutions will be needed to reach the full
function level of=20 MPLS-TP.

> * they had a good chance to remain the only type = of=20 bidirectional
>   paths in real = deployments.

I=20 don't see what that follows=20 from.

Cheers,
Adrian
------_=_NextPart_001_01C9BF3C.D830AD26-- From neil.2.harrison@bt.com Fri Apr 17 02:14:52 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9BF3A6814 for ; Fri, 17 Apr 2009 02:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ2anK0CZCLh for ; Fri, 17 Apr 2009 02:14:51 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E77FB3A6AC7 for ; Fri, 17 Apr 2009 02:14:50 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:16:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 10:15:57 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FFB4D@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B184D@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. thread-index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgAAEgtWAAM0zYIAABA8g From: To: , , , X-OriginalArrivalTime: 17 Apr 2009 09:16:03.0432 (UTC) FILETIME=[21987680:01C9BF3D] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:14:52 -0000 Italo, =20 wrote 17 April 2009 09:44 >=20 > Hi all, >=20 > I am sorry to repeat myself, but it seems that we are all=20 > repeating the > debate we already had in the past. >=20 > It is therefore important that I remind everybody that the requirement > for TCM is not motivate by its existence in SONET/SDH. >=20 > Actually, the TCM function was added to SONET/SDH quite late in its > development on the basis of transport operators requirements. >=20 > Because of its late introduction, the SONET/SDH TCM design has some > limitations (e.g. the lack of nesting TCM) that has limited its > applicability. This is the main reason why TCM was not widespread > deployed with SONET/SDH, although some deployments actually exist. >=20 > I think that we are continuing to ignore that SONET/SDH is=20 > not the only > transport technology defined by ITU-T. >=20 > After having realized the issues with SONET/SDH TCM design, all the > subsequent OAM designs from ITU-T has taken seriously into account the > TCM requirements, including the nesting: look for example at OTN and > Ethernet OAM designs. NH=3D> Yes but how much of this is used in reality Italo? TCM as a concept has been around for a very long time and I don't know anyone here who laments us not using it....though I know a large number of folks who think it is not a great idea. Remember what I have said in previous mails, eg - the always-on defect detection/handling OAM needs to be as simple/sparse as possible with min config and it must be significantly more reliable then the network it is monitoring.... - ....and the intrinsic defect rate of the network must be very low else it is not fit-for-purpose anyway... - .....so an OAM phiolosophy of blanketing the network with lots of nested TCM level configuration is clearly the wrong way to be going. - And this is especially true when we are dealing with a non top-of-stack network that has no technical need to peer and have E-NNIs across several different parties.=20 Since you mention Ethernet (which is cl-ps in native form) perhaps we should have a clear understanding of how TCM will be applied to IPv4 and IPv6. I do not think it sensible that TCM should be considered in isolation wrt MPLS-TP within IETF and for it not to be applied to IP....if it's that important I would want to see clear work-plan intentions for it to apply to all co-cs, co-ps and cl-ps technologies that IETF have an interest in. And as a follow-on from that, I would want to understand how this factors into the work of CCAMPs wrt GMPLS.....the issue here of course is a desire to understand how nested TCM levels are configured wrt activation/deactivation across changes in routing when there is a failure/recovery event. regards, Neil >=20 > Italo >=20 > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > > Sent: Thursday, April 16, 2009 10:20 PM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander=20 > Vainshtein > > Cc: BUSI ITALO; mpls-tp@ietf.org; Adrian Farrel;=20 > > neil.2.harrison@bt.com > > Subject: Re: [mpls-tp] Requirement for TCM or not. > >=20 > > Colleagues, > >=20 > > On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > > Regarding the first one, it was agreed that the MPLS-TP=20 > > addresses the > > > transport requirements of the ITU-T and additional=20 > requirements from > > > SPs.=20 > > > This was one of the first set of requirements the ITU-T=20 > > brought to the > > > work and we need to address it. > >=20 > > This does raise a question in my mind that goes back to=20 > > something I have > > said before. Is TCM a requirement because it is a real=20 > > requirement that > > operators are asking for or because we are recreating SDH/SONET > > functionality blindly without considering its relevance in=20 > > the world we now > > live in? > >=20 > > I appreciate that there are many operators who do not participate in > > standards, however it would be most useful if just one=20 > > operator who requires > > TCM were to step forward and say so. > >=20 > > I am not a TDM expert but what my TDM experts tell me is that=20 > > TCM has been > > deployed in the past by some operators (I have no idea of its=20 > > current state > > of deployment except in BT) but that its use in the past can=20 > > be considered > > (in their opinion) to be in the minority of deployments. > >=20 > > I do wonder if we are therefore expending a lot of energy=20 > > (and later on time > > both in standardisation and possibly development effort) for=20 > > a function that > > may be seldom, if ever, used. It won't be the first time we have > > standardised something that is seldom, if ever, used but we=20 > do have an > > opportunity now to take a step back and consider: is TCM=20 > > really required and > > if it is required, is it a priority in the development of MPLS-TP? > >=20 > > Ben > >=20 > >=20 > >=20 >=20 From benjamin.niven-jenkins@bt.com Fri Apr 17 02:20:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249143A6C1B for ; Fri, 17 Apr 2009 02:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4Lz2HfwEp2U for ; Fri, 17 Apr 2009 02:20:30 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 23E073A6A42 for ; Fri, 17 Apr 2009 02:20:29 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:21:42 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Apr 2009 09:21:42 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 10:21:40 +0100 From: Ben Niven-Jenkins To: BUSI ITALO , Adrian Farrel , Alexander Vainshtein Message-ID: Thread-Topic: Tandem Connections in MPLS-TP (was RE: [mpls-tp] Associated bidirectional transport path requirements) Thread-Index: Acm+e9jj1HoQiXHcQhKAYvhbYuJx6wAKYxBAABXawM0ADoZp4AABwBsH In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1844@FRVELSMBS21.ad2.ad.alcatel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Apr 2009 09:21:42.0731 (UTC) FILETIME=[EBD561B0:01C9BF3D] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:20:31 -0000 Italo, On 17/04/2009 09:34, "BUSI ITALO" wrote: > The JWT agreement is to bring the ITU-T transport requirements in IETF > to extend the MPLS architecture to meet them in a way that is > compatible, consistent and coherent with existing IETF architecture. So I took a look at the JWT report. It says (slide 16) " Service Providers want LSPs/PWEs to be able to be managed at the different nested levels seamlessly (path, segment, multiple segments) aka Tandem Connection Monitoring (TCM), this is used for example when a LSP/PWE crosses multiple administrations" IMO the requirement is to be able to monitor parts of a path as well as the end to end path. There are many ways to solve that requirement, one of which is the creation of nested LSPs, one per level of monitoring required (my understanding of how TCM works). I think the real discussion is therefore is the requirement to monitor different components of an end to end path or is the requirement that such monitoring MUST be achieved using nested LSPs? As an example PW technology today allows end to end and per segment monitoring but it does not achieve it using nested PWs or PW levels. Ben From nurit.sprecher@nsn.com Fri Apr 17 02:24:42 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BB13A6A9B for ; Fri, 17 Apr 2009 02:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+Fse3Puk7Ex for ; Fri, 17 Apr 2009 02:24:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C20223A6A3F for ; Fri, 17 Apr 2009 02:24:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3H9PUkm006493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Apr 2009 11:25:30 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3H9PTff007416; Fri, 17 Apr 2009 11:25:29 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 11:25:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9BF3E.72CEA9EF" Date: Fri, 17 Apr 2009 11:25:17 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326490D9BC@DEMUEXC014.nsn-intra.net> In-Reply-To: <6535C9CED6F87446B41D20EF170F23623161F0@mamxm01.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgAAEgtWAAARmI4AA1aWQ References: <6535C9CED6F87446B41D20EF170F23623161F0@mamxm01.ciena.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Shah, Himanshu" , "Ben Niven-Jenkins" , "ext Alexander Vainshtein" X-OriginalArrivalTime: 17 Apr 2009 09:25:29.0690 (UTC) FILETIME=[731C93A0:01C9BF3E] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:24:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF3E.72CEA9EF Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9BF3E.72CEA9EF" ------_=_NextPart_002_01C9BF3E.72CEA9EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Honestly, I do not see the real reason for so long discussion aroun this. We all know that it was agreed by the JWT to use existing constructs to provide this functionaliy (LSP hierarchy).=20 So why should one care to include this requreiment that came from the first point from the ITU-T? ________________________________ From: ext Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Thursday, April 16, 2009 11:41 PM To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein Cc: BUSI ITALO; mpls-tp@ietf.org Subject: RE: [mpls-tp] Requirement for TCM or not. If I am not mistaken, this is the third iteration of the discussion cycle on this subject matter (each with different heading). As they say, third time is a charm. seriously though, I agree. Lets put this behind us if there is no 'real' requirement for it. /himanshu =20 -----Original Message----- From: mpls-tp-bounces@ietf.org on behalf of Ben Niven-Jenkins Sent: Thu 4/16/2009 4:20 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein Cc: BUSI ITALO; mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. Colleagues, On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > Regarding the first one, it was agreed that the MPLS-TP addresses the > transport requirements of the ITU-T and additional requirements from > SPs. > This was one of the first set of requirements the ITU-T brought to the > work and we need to address it. This does raise a question in my mind that goes back to something I have said before. Is TCM a requirement because it is a real requirement that operators are asking for or because we are recreating SDH/SONET functionality blindly without considering its relevance in the world we now live in? I appreciate that there are many operators who do not participate in standards, however it would be most useful if just one operator who requires TCM were to step forward and say so. I am not a TDM expert but what my TDM experts tell me is that TCM has been deployed in the past by some operators (I have no idea of its current state of deployment except in BT) but that its use in the past can be considered (in their opinion) to be in the minority of deployments. I do wonder if we are therefore expending a lot of energy (and later on time both in standardisation and possibly development effort) for a function that may be seldom, if ever, used. It won't be the first time we have standardised something that is seldom, if ever, used but we do have an opportunity now to take a step back and consider: is TCM really required and if it is required, is it a priority in the development of MPLS-TP? Ben _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ------_=_NextPart_002_01C9BF3E.72CEA9EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mpls-tp] Requirement for TCM or not.
Honestly, I do not see the real reason for so long discussion = aroun this.=20 We all know that it was agreed by the JWT to use existing = constructs to=20 provide this functionaliy (LSP hierarchy).

So why=20 should one care to include this requreiment that came from the first = point from=20 the ITU-T?

From: ext Shah, Himanshu=20 [mailto:hshah@ciena.com]
Sent: Thursday, April 16, 2009 11:41 = PM
To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod = HaSharon); ext=20 Alexander Vainshtein
Cc: BUSI ITALO;=20 mpls-tp@ietf.org
Subject: RE: [mpls-tp] Requirement for TCM or = not.

If I am not mistaken, this is the third iteration of=20 the
discussion cycle on this subject matter (each with
different = heading).=20 As they say, third time is a charm.

seriously though, I agree. = Lets put=20 this behind us if
there is no 'real' requirement for=20 it.

/himanshu

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

From: mpls-tp-bounces@ietf.org on behalf of Ben=20 Niven-Jenkins
Sent: Thu 4/16/2009 4:20 PM
To: Sprecher, Nurit (NSN = -=20 IL/Hod HaSharon); ext Alexander Vainshtein
Cc: BUSI ITALO;=20 mpls-tp@ietf.org
Subject: Re: [mpls-tp] Requirement for TCM or=20 not.

Colleagues,

On 16/04/2009 21:05, "Sprecher, Nurit = (NSN -=20 IL/Hod HaSharon)"
> Regarding the first one, it was agreed that = the=20 MPLS-TP addresses the
> transport requirements of the ITU-T and = additional=20 requirements from
> SPs.
> This was one of the first set of=20 requirements the ITU-T brought to the
> work and we need to = address=20 it.

This does raise a question in my mind that goes back to = something I=20 have
said before. Is TCM a requirement because it is a real = requirement=20 that
operators are asking for or because we are recreating=20 SDH/SONET
functionality blindly without considering its relevance in = the=20 world we now
live in?

I appreciate that there are many = operators who=20 do not participate in
standards, however it would be most useful if = just one=20 operator who requires
TCM were to step forward and say so.

I = am not a=20 TDM expert but what my TDM experts tell me is that TCM has = been
deployed in=20 the past by some operators (I have no idea of its current state
of = deployment=20 except in BT) but that its use in the past can be considered
(in = their=20 opinion) to be in the minority of deployments.

I do wonder if we = are=20 therefore expending a lot of energy (and later on time
both in=20 standardisation and possibly development effort) for a function = that
may be=20 seldom, if ever, used. It won't be the first time we = have
standardised=20 something that is seldom, if ever, used but we do have an
opportunity = now to=20 take a step back and consider: is TCM really required and
if it is = required,=20 is it a priority in the development of=20 MPLS-TP?

Ben

__________________________________________= _____
mpls-tp=20 mailing list
mpls-tp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mpls-tp

------_=_NextPart_002_01C9BF3E.72CEA9EF-- ------_=_NextPart_001_01C9BF3E.72CEA9EF Content-Type: image/gif; name="ATT96950.gif" Content-Transfer-Encoding: base64 Content-ID: <968412009@17042009-2FC9> Content-Description: ATT96950.gif Content-Location: ATT96950.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01C9BF3E.72CEA9EF-- From Italo.Busi@alcatel-lucent.it Fri Apr 17 02:24:48 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DAB3A6C1B for ; Fri, 17 Apr 2009 02:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[AWL=-1.643, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ymjp9F+6onC for ; Fri, 17 Apr 2009 02:24:47 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 179D33A6A3F for ; Fri, 17 Apr 2009 02:24:46 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H9Pxfa007702 for ; Fri, 17 Apr 2009 11:25:59 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 11:25:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 11:25:58 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B188D@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operator's support for TCM Thread-Index: Acm/PoQ2F9OQCQvrQEqchv5sRwAlAw== From: "BUSI ITALO" To: X-OriginalArrivalTime: 17 Apr 2009 09:25:59.0228 (UTC) FILETIME=[84B7B7C0:01C9BF3E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [mpls-tp] Operator's support for TCM X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:24:48 -0000 Despite the JWT, it is becoming clear that I have to look forward for some transport operator willing to voice his view regarding the requirements for TCM on the MPLS-TP mailing list. At the last ITU-T meeting some major transport operator expressed concerns on the fact that the validity of some transport requirements is questioned and their removal from MPLS-TP proposed. They have clearly expressed their need to have in MPLS-TP the same capabilities that ITU-T has defined in G.8131, G.8132 and G.8114. Although the need for TCM was not explicitly mentioned, this is a functionality that ITU-T has defined in G.8114 I will further investigate and check for the TCM requirements with my customers. Of course this additional (and IMO unneccessary, because of the JWT agreement) task will reduce the time I can spend in writing MPLS-TP drafts. Italo From liu.guoman@zte.com.cn Fri Apr 17 02:37:44 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3393A69F9 for ; Fri, 17 Apr 2009 02:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.535 X-Spam-Level: X-Spam-Status: No, score=-97.535 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yr2oQIReEpT for ; Fri, 17 Apr 2009 02:37:43 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E71983A6A47 for ; Fri, 17 Apr 2009 02:37:41 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Fri, 17 Apr 2009 17:31:51 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.1955151504; Fri, 17 Apr 2009 17:35:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3H9cwf8002483; Fri, 17 Apr 2009 17:38:58 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B188D@FRVELSMBS21.ad2.ad.alcatel.com> To: "BUSI ITALO" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 17 Apr 2009 17:36:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-17 17:38:48, Serialize complete at 2009-04-17 17:38:48 Content-Type: multipart/alternative; boundary="=_alternative 0034FC494825759B_=" X-MAIL: mse1.zte.com.cn n3H9cwf8002483 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Operator's support for TCM X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:37:44 -0000 This is a multipart message in MIME format. --=_alternative 0034FC494825759B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SVRBTE86DQogIEkgIHRoaW5rIGl0IGlzIHJlYXNvbmFibGUgYW5kIGJldHRlciBmb3IgeW91IHRv IGNsYXJpZnkgd2hpY2ggb3BlcmF0b3IgDQp3aWxsIHZvaWNlIGFuZCBzdXBwb3J0IHRoZSByZXF1 aXJlbWVudHMgZm9yIFRDTSBvbiB0aGUgbXBscy10cC4gb3IgZWxzZSANCm90aGVyIHBlb3BsZSBp cyBkaWZmY3VsdCB0byB0cnVzdCB3aGF0IHlvdSBzYWlkLg0KDQpyZWdhcmRzDQpsaXUNCg0KDQoN Cg0KIkJVU0kgSVRBTE8iIDxJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0PiANCreivP7Iyzog IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0wNC0xNyAxNzoyNQ0KDQrK1bz+yMsNCjxt cGxzLXRwQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbbXBscy10cF0gT3BlcmF0b3IncyBzdXBw b3J0IGZvciBUQ00NCg0KDQoNCg0KDQoNCkRlc3BpdGUgdGhlIEpXVCwgaXQgaXMgYmVjb21pbmcg Y2xlYXIgdGhhdCBJIGhhdmUgdG8gbG9vayBmb3J3YXJkIGZvcg0Kc29tZSB0cmFuc3BvcnQgb3Bl cmF0b3Igd2lsbGluZyB0byB2b2ljZSBoaXMgdmlldyByZWdhcmRpbmcgdGhlDQpyZXF1aXJlbWVu dHMgZm9yIFRDTSBvbiB0aGUgTVBMUy1UUCBtYWlsaW5nIGxpc3QuDQoNCkF0IHRoZSBsYXN0IElU VS1UIG1lZXRpbmcgc29tZSBtYWpvciB0cmFuc3BvcnQgb3BlcmF0b3IgZXhwcmVzc2VkDQpjb25j ZXJucyBvbiB0aGUgZmFjdCB0aGF0IHRoZSB2YWxpZGl0eSBvZiBzb21lIHRyYW5zcG9ydCByZXF1 aXJlbWVudHMgaXMNCnF1ZXN0aW9uZWQgYW5kIHRoZWlyIHJlbW92YWwgZnJvbSBNUExTLVRQIHBy b3Bvc2VkLg0KDQpUaGV5IGhhdmUgY2xlYXJseSBleHByZXNzZWQgdGhlaXIgbmVlZCB0byBoYXZl IGluIE1QTFMtVFAgdGhlIHNhbWUNCmNhcGFiaWxpdGllcyB0aGF0IElUVS1UIGhhcyBkZWZpbmVk IGluIEcuODEzMSwgRy44MTMyIGFuZCBHLjgxMTQuDQoNCkFsdGhvdWdoIHRoZSBuZWVkIGZvciBU Q00gd2FzIG5vdCBleHBsaWNpdGx5IG1lbnRpb25lZCwgdGhpcyBpcyBhDQpmdW5jdGlvbmFsaXR5 IHRoYXQgSVRVLVQgaGFzIGRlZmluZWQgaW4gRy44MTE0DQoNCkkgd2lsbCBmdXJ0aGVyIGludmVz dGlnYXRlIGFuZCBjaGVjayBmb3IgdGhlIFRDTSByZXF1aXJlbWVudHMgd2l0aCBteQ0KY3VzdG9t ZXJzLg0KDQpPZiBjb3Vyc2UgdGhpcyBhZGRpdGlvbmFsIChhbmQgSU1PIHVubmVjY2Vzc2FyeSwg YmVjYXVzZSBvZiB0aGUgSldUDQphZ3JlZW1lbnQpIHRhc2sgd2lsbCByZWR1Y2UgdGhlIHRpbWUg SSBjYW4gc3BlbmQgaW4gd3JpdGluZyBNUExTLVRQDQpkcmFmdHMuDQoNCkl0YWxvDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscy10cCBtYWlsaW5n IGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscy10cA0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0034FC494825759B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklUQUxPOjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEkgJm5ic3A7dGhpbmsgaXQgaXMg cmVhc29uYWJsZQ0KYW5kIGJldHRlciBmb3IgeW91IHRvIGNsYXJpZnkgd2hpY2ggb3BlcmF0b3Ig d2lsbCB2b2ljZSBhbmQgc3VwcG9ydCB0aGUNCnJlcXVpcmVtZW50cyBmb3IgVENNIG9uIHRoZSBt cGxzLXRwLiBvciBlbHNlIG90aGVyIHBlb3BsZSBpcyBkaWZmY3VsdCB0bw0KdHJ1c3Qgd2hhdCB5 b3Ugc2FpZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PnJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxpdTwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj4mcXVvdDtCVVNJIElUQUxPJnF1b3Q7DQombHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5p dCZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8 /sjLOiAmbmJzcDttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0xNyAxNzoyNTwvZm9udD4NCjx0ZCB3aWR0aD03 MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7bXBscy10cEBpZXRmLm9y ZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlttcGxzLXRwXSBPcGVyYXRvcidzIHN1cHBvcnQgZm9yIFRDTTwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+RGVzcGl0ZSB0aGUg SldULCBpdCBpcyBiZWNvbWluZyBjbGVhciB0aGF0IEkgaGF2ZQ0KdG8gbG9vayBmb3J3YXJkIGZv cjxicj4NCnNvbWUgdHJhbnNwb3J0IG9wZXJhdG9yIHdpbGxpbmcgdG8gdm9pY2UgaGlzIHZpZXcg cmVnYXJkaW5nIHRoZTxicj4NCnJlcXVpcmVtZW50cyBmb3IgVENNIG9uIHRoZSBNUExTLVRQIG1h aWxpbmcgbGlzdC48YnI+DQo8YnI+DQpBdCB0aGUgbGFzdCBJVFUtVCBtZWV0aW5nIHNvbWUgbWFq b3IgdHJhbnNwb3J0IG9wZXJhdG9yIGV4cHJlc3NlZDxicj4NCmNvbmNlcm5zIG9uIHRoZSBmYWN0 IHRoYXQgdGhlIHZhbGlkaXR5IG9mIHNvbWUgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBpczxicj4N CnF1ZXN0aW9uZWQgYW5kIHRoZWlyIHJlbW92YWwgZnJvbSBNUExTLVRQIHByb3Bvc2VkLjxicj4N Cjxicj4NClRoZXkgaGF2ZSBjbGVhcmx5IGV4cHJlc3NlZCB0aGVpciBuZWVkIHRvIGhhdmUgaW4g TVBMUy1UUCB0aGUgc2FtZTxicj4NCmNhcGFiaWxpdGllcyB0aGF0IElUVS1UIGhhcyBkZWZpbmVk IGluIEcuODEzMSwgRy44MTMyIGFuZCBHLjgxMTQuPGJyPg0KPGJyPg0KQWx0aG91Z2ggdGhlIG5l ZWQgZm9yIFRDTSB3YXMgbm90IGV4cGxpY2l0bHkgbWVudGlvbmVkLCB0aGlzIGlzIGE8YnI+DQpm dW5jdGlvbmFsaXR5IHRoYXQgSVRVLVQgaGFzIGRlZmluZWQgaW4gRy44MTE0PGJyPg0KPGJyPg0K SSB3aWxsIGZ1cnRoZXIgaW52ZXN0aWdhdGUgYW5kIGNoZWNrIGZvciB0aGUgVENNIHJlcXVpcmVt ZW50cyB3aXRoIG15PGJyPg0KY3VzdG9tZXJzLjxicj4NCjxicj4NCk9mIGNvdXJzZSB0aGlzIGFk ZGl0aW9uYWwgKGFuZCBJTU8gdW5uZWNjZXNzYXJ5LCBiZWNhdXNlIG9mIHRoZSBKV1Q8YnI+DQph Z3JlZW1lbnQpIHRhc2sgd2lsbCByZWR1Y2UgdGhlIHRpbWUgSSBjYW4gc3BlbmQgaW4gd3JpdGlu ZyBNUExTLVRQPGJyPg0KZHJhZnRzLjxicj4NCjxicj4NCkl0YWxvPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzLXRwIG1haWxpbmcg bGlzdDxicj4NCm1wbHMtdHBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt YWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZu YnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNw O21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Bl cm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNw O29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRo aXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0 ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQm bmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8m bmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2lu Jm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5h dG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5i c3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNw O3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZu YnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRp LVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0034FC494825759B_=-- From Italo.Busi@alcatel-lucent.it Fri Apr 17 02:49:26 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55263A68E7 for ; Fri, 17 Apr 2009 02:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcKSW-TNKp-4 for ; Fri, 17 Apr 2009 02:49:25 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 964A73A6AF2 for ; Fri, 17 Apr 2009 02:49:25 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H9nqXY013702; Fri, 17 Apr 2009 11:50:04 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 11:49:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 11:49:59 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B18B5@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tandem Connections in MPLS-TP (was RE: [mpls-tp] Associated bidirectional transport path requirements) Thread-Index: Acm+e9jj1HoQiXHcQhKAYvhbYuJx6wAKYxBAABXawM0ADoZp4AABwBsHAADOEkA= References: <6FD21B53861BF44AA90A288402036AB4021B1844@FRVELSMBS21.ad2.ad.alcatel.com> From: "BUSI ITALO" To: "Ben Niven-Jenkins" , "Adrian Farrel" , "Alexander Vainshtein" X-OriginalArrivalTime: 17 Apr 2009 09:49:59.0993 (UTC) FILETIME=[DF7B0290:01C9BF41] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:49:26 -0000 Ben, I think we are mixing solutions with requirements. The requirement for the TCM function is clearly defined and I do think it must be addressed by the MPLS-TP design. The solution evaluated by the JWT to meet this requirement was to use label stacking with a 1:1 relationship between the TCM LSP and the e2e LSP. I think this solution, although not the best technical option, is good enough and meets the requirements. However this is is a solution and has not impact on the requirement. Italo > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Friday, April 17, 2009 11:22 AM > To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > Cc: mpls-tp@ietf.org; Lou Berger > Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp]=20 > Associated bidirectional transport path requirements) >=20 > Italo, >=20 > On 17/04/2009 09:34, "BUSI ITALO"=20 > wrote: > > The JWT agreement is to bring the ITU-T transport=20 > requirements in IETF > > to extend the MPLS architecture to meet them in a way that is > > compatible, consistent and coherent with existing IETF architecture. >=20 > So I took a look at the JWT report. It says (slide 16) >=20 > " Service Providers want LSPs/PWEs to be able to be managed=20 > at the different > nested levels seamlessly (path, segment, multiple segments) > aka Tandem Connection Monitoring (TCM), this is used for=20 > example when a > LSP/PWE crosses multiple administrations" >=20 > IMO the requirement is to be able to monitor parts of a path=20 > as well as the > end to end path. There are many ways to solve that=20 > requirement, one of which > is the creation of nested LSPs, one per level of monitoring=20 > required (my > understanding of how TCM works). >=20 > I think the real discussion is therefore is the requirement to monitor > different components of an end to end path or is the=20 > requirement that such > monitoring MUST be achieved using nested LSPs? >=20 > As an example PW technology today allows end to end and per segment > monitoring but it does not achieve it using nested PWs or PW levels. >=20 > Ben >=20 >=20 From neil.2.harrison@bt.com Fri Apr 17 02:52:19 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC39B3A6B03 for ; Fri, 17 Apr 2009 02:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5VF-SwkwdQP for ; Fri, 17 Apr 2009 02:52:18 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 48D743A68E7 for ; Fri, 17 Apr 2009 02:52:18 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:53:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01C9BF42.5C868E49"; type="multipart/alternative" Date: Fri, 17 Apr 2009 10:52:45 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FFB96@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326490D9BC@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. thread-index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgAAEgtWAAARmI4AA1aWQgAAFd0A= From: To: , , , X-OriginalArrivalTime: 17 Apr 2009 09:53:30.0438 (UTC) FILETIME=[5CEA5E60:01C9BF42] Cc: Italo.Busi@alcatel-lucent.it, mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:52:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF42.5C868E49 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9BF42.5C868E49" ------_=_NextPart_002_01C9BF42.5C868E49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We care about it Nurit because it represents an operational cost and source of potentially worse reliability. I can tell you for a fact that OPs folks will turn-off as much unnecessary OAM as they can. I care about it as a thinking engineer because I can see better ways to do **rare** within-connection diagnostics. Which is also why I care about not creating unnecessary work/costs wrt trying to peer interwork non top-of-stack networks because I and my colleagues can figure out that it is a technical nonsence...and TCM must never be justified on that basis. =20 Further, we do not want to use suppliers whose equipment has such a high intrinsic defect rate that having shed-loads of OAM running is required....wrong approach. =20 But let me end with what I said in a different mail...if TCM is considered essential for MPLS-TP, then I want to see IETF agree to its adoptionfor IP. =20 regards, Neil ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: 17 April 2009 10:25 To: ext Shah, Himanshu; Niven-jenkins,B,Ben,DMF R; ext Alexander Vainshtein Cc: BUSI ITALO; mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. =09 =09 Honestly, I do not see the real reason for so long discussion aroun this. We all know that it was agreed by the JWT to use existing constructs to provide this functionaliy (LSP hierarchy).=20 So why should one care to include this requreiment that came from the first point from the ITU-T? ________________________________ From: ext Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Thursday, April 16, 2009 11:41 PM To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein Cc: BUSI ITALO; mpls-tp@ietf.org Subject: RE: [mpls-tp] Requirement for TCM or not. =09 =09 If I am not mistaken, this is the third iteration of the discussion cycle on this subject matter (each with different heading). As they say, third time is a charm. =09 seriously though, I agree. Lets put this behind us if there is no 'real' requirement for it. =09 /himanshu =09 =09 =09 =20 =09 -----Original Message----- =09 From: mpls-tp-bounces@ietf.org on behalf of Ben Niven-Jenkins Sent: Thu 4/16/2009 4:20 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein Cc: BUSI ITALO; mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. =09 Colleagues, =09 On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > Regarding the first one, it was agreed that the MPLS-TP addresses the > transport requirements of the ITU-T and additional requirements from > SPs. > This was one of the first set of requirements the ITU-T brought to the > work and we need to address it. =09 This does raise a question in my mind that goes back to something I have said before. Is TCM a requirement because it is a real requirement that operators are asking for or because we are recreating SDH/SONET functionality blindly without considering its relevance in the world we now live in? =09 I appreciate that there are many operators who do not participate in standards, however it would be most useful if just one operator who requires TCM were to step forward and say so. =09 I am not a TDM expert but what my TDM experts tell me is that TCM has been deployed in the past by some operators (I have no idea of its current state of deployment except in BT) but that its use in the past can be considered (in their opinion) to be in the minority of deployments. =09 I do wonder if we are therefore expending a lot of energy (and later on time both in standardisation and possibly development effort) for a function that may be seldom, if ever, used. It won't be the first time we have standardised something that is seldom, if ever, used but we do have an opportunity now to take a step back and consider: is TCM really required and if it is required, is it a priority in the development of MPLS-TP? =09 Ben =09 =09 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 ------_=_NextPart_002_01C9BF42.5C868E49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mpls-tp] Requirement for TCM or not.
We care about it Nurit = because it=20 represents an operational cost and source of potentially worse=20 reliability. I can tell you for a fact that OPs folks will = turn-off as=20 much unnecessary OAM as they can. I care about it as a thinking = engineer=20 because I can see better ways to do **rare** within-connection=20 diagnostics. Which is also why I care about not creating = unnecessary=20 work/costs wrt trying to peer interwork non top-of-stack networks = because I and=20 my colleagues can figure out that it is a technical nonsence...and TCM = must=20 never be justified on that basis.

Further, we do not want = to use=20 suppliers whose equipment has such a high intrinsic defect rate that = having=20 shed-loads of OAM running is required....wrong = approach.

But let me end with what = I said in a=20 different mail...if TCM is considered essential for MPLS-TP, then I want = to see=20 IETF agree to its adoptionfor IP.

regards, = Neil

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit = (NSN -=20 IL/Hod HaSharon)
Sent: 17 April 2009 10:25
To: ext = Shah,=20 Himanshu; Niven-jenkins,B,Ben,DMF R; ext Alexander = Vainshtein
Cc:=20 BUSI ITALO; mpls-tp@ietf.org
Subject: Re: [mpls-tp] = Requirement for=20 TCM or not.

Honestly, I do not see the real reason for so long discussion = aroun=20 this. We all know that it was agreed by the JWT to use existing=20 constructs to provide this functionaliy (LSP hierarchy). =

So=20 why should one care to include this requreiment that came from the = first point=20 from the ITU-T?

From: ext Shah, Himanshu=20 [mailto:hshah@ciena.com]
Sent: Thursday, April 16, 2009 = 11:41=20 PM
To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod = HaSharon);=20 ext Alexander Vainshtein
Cc: BUSI ITALO;=20 mpls-tp@ietf.org
Subject: RE: [mpls-tp] Requirement for TCM = or=20 not.

If I am not mistaken, this is the third iteration of = the
discussion cycle on this subject matter (each with
different = heading). As they say, third time is a charm.

seriously though, = I=20 agree. Lets put this behind us if
there is no 'real' requirement = for=20 it.

/himanshu

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

From: mpls-tp-bounces@ietf.org on behalf of Ben=20 Niven-Jenkins
Sent: Thu 4/16/2009 4:20 PM
To: Sprecher, Nurit = (NSN -=20 IL/Hod HaSharon); ext Alexander Vainshtein
Cc: BUSI ITALO;=20 mpls-tp@ietf.org
Subject: Re: [mpls-tp] Requirement for TCM or=20 not.

Colleagues,

On 16/04/2009 21:05, "Sprecher, Nurit = (NSN -=20 IL/Hod HaSharon)"
> Regarding the first one, it was agreed that = the=20 MPLS-TP addresses the
> transport requirements of the ITU-T and=20 additional requirements from
> SPs.
> This was one of the = first=20 set of requirements the ITU-T brought to the
> work and we need = to=20 address it.

This does raise a question in my mind that goes = back to=20 something I have
said before. Is TCM a requirement because it is a = real=20 requirement that
operators are asking for or because we are = recreating=20 SDH/SONET
functionality blindly without considering its relevance = in the=20 world we now
live in?

I appreciate that there are many = operators who=20 do not participate in
standards, however it would be most useful if = just=20 one operator who requires
TCM were to step forward and say = so.

I am=20 not a TDM expert but what my TDM experts tell me is that TCM has=20 been
deployed in the past by some operators (I have no idea of its = current=20 state
of deployment except in BT) but that its use in the past can = be=20 considered
(in their opinion) to be in the minority of=20 deployments.

I do wonder if we are therefore expending a lot of = energy=20 (and later on time
both in standardisation and possibly development = effort)=20 for a function that
may be seldom, if ever, used. It won't be the = first=20 time we have
standardised something that is seldom, if ever, used = but we do=20 have an
opportunity now to take a step back and consider: is TCM = really=20 required and
if it is required, is it a priority in the development = of=20 = MPLS-TP?

Ben

__________________________________________= _____
mpls-tp=20 mailing list
mpls-tp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mpls-tp

------_=_NextPart_002_01C9BF42.5C868E49-- ------_=_NextPart_001_01C9BF42.5C868E49 Content-Type: image/gif; name="ATT96950.gif" Content-Transfer-Encoding: base64 Content-ID: <902154009@17042009-1784> Content-Description: ATT96950.gif Content-Location: ATT96950.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01C9BF42.5C868E49-- From annamaria.fulignoli@ericsson.com Fri Apr 17 02:56:06 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233803A6A76 for ; Fri, 17 Apr 2009 02:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVCo+EWRZMVF for ; Fri, 17 Apr 2009 02:56:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CD1863A67F4 for ; Fri, 17 Apr 2009 02:55:41 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FCFD24734; Fri, 17 Apr 2009 11:56:53 +0200 (CEST) X-AuditID: c1b4fb3e-af025bb0000024d5-37-49e84457a828 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D67A523986; Fri, 17 Apr 2009 10:56:55 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:56:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 10:56:53 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F9403953A96@esealmw118.eemea.ericsson.se> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1834@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Requirement for TCM or not. Thread-Index: AQHJvogQ6p8FN+/AW0GgVMgTrO1G6o/p6rftgAAHu3CAACdwDYAABhBQgADOSICAAAmQgA== References: , <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net><077E41CFFD002C4CAB7DFA4386A5326490D7B1@DEMUEXC014.nsn-intra.net> <6FD21B53861BF44AA90A288402036AB4021B1834@FRVELSMBS21.ad2.ad.alcatel.com> From: "Annamaria Fulignoli" To: "BUSI ITALO" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Alexander Vainshtein" X-OriginalArrivalTime: 17 Apr 2009 08:56:55.0225 (UTC) FILETIME=[7535FA90:01C9BF3A] X-Brightmail-Tracker: AAAAAA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:56:06 -0000 +1 Annamaria=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of BUSI ITALO Sent: venerd=EC 17 aprile 2009 10.23 To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. I am in full agreement with Nurit Italo=20 > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > [mailto:nurit.sprecher@nsn.com] > Sent: Thursday, April 16, 2009 10:06 PM > To: ext Alexander Vainshtein > Cc: BUSI ITALO; mpls-tp@ietf.org; ext Ben Niven-Jenkins; Adrian=20 > Farrel; neil.2.harrison@bt.com > Subject: RE: [mpls-tp] Requirement for TCM or not. >=20 > Sasha, > I absolutely agree with your second point. > Regarding the first one, it was agreed that the MPLS-TP addresses the=20 > transport requirements of the ITU-T and additional requirements from=20 > SPs. > This was one of the first set of requirements the ITU-T brought to the = > work and we need to address it. > Best regards, > Nurit >=20 > -----Original Message----- > From: ext Alexander Vainshtein > [mailto:Alexander.Vainshtein@ecitele.com] >=20 > Sent: Thursday, April 16, 2009 10:49 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: BUSI ITALO; mpls-tp@ietf.org; ext Ben Niven-Jenkins; Adrian=20 > Farrel; neil.2.harrison@bt.com > Subject: RE: [mpls-tp] Requirement for TCM or not. >=20 > Nurit hi, > Two comments: >=20 > 1. As I see it, the actual operational need to monitor network at=20 > different nested levels is, at the very least, > arguable (Neil explains this much better that I can ever can=20 > hope). >=20 > 2. We should understand and agree upon the requirement first and then=20 > look for the suitable solution, not the > the other way round.=20 >=20 > Regards, > Sasha >=20 > ________________________________________ > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [nurit.sprecher@nsn.com] > Sent: Thursday, April 16, 2009 8:25 PM > To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Requirement for TCM or not. >=20 > Hi, > TC is a solution to the requirement to manage, monitor and protect the = > network at different nested levels. > The work on MPLS-TP started with this basic requirement that came from = > the ITU-T. > I think we should continue and address this requirement as our=20 > commitment to the ITU-T. > About the solution, there is room for discussion. Is it TC, PST or=20 > something else? As promised I'll provide next week some text about=20 > this. >=20 > Best regards, > Nurit >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > Behalf Of ext Ben Niven-Jenkins > Sent: Thursday, April 16, 2009 7:54 PM > To: Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: [mpls-tp] Requirement for TCM or not. >=20 > On 16/04/2009 12:39, "Alexander Vainshtein" > > I fully support your proposal to get rid (in a consistent > manner) from > the TC > > stuff in MPLS-TP, especially since, to the best of my knowledge, > operational > > experience with SONET/SDH TCM (ITU-T definitions > notwithstanding) did > not > > prove its worth. If this is based on mis-perception, I would be glad > to hear > > that (especially from the operators on this list). >=20 > BT has no requirement for TCM. We do not have it deployed in our TDM=20 > networks today and have no current plans to use it in any of our=20 > networks in the future. >=20 > Ben >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From neil.2.harrison@bt.com Fri Apr 17 02:58:29 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB45A3A69F9 for ; Fri, 17 Apr 2009 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOP9VxX4V-kf for ; Fri, 17 Apr 2009 02:58:29 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id DE3BF3A68E7 for ; Fri, 17 Apr 2009 02:58:28 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:59:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 10:58:41 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FFBA2@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B188D@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Operator's support for TCM thread-index: Acm/PoQ2F9OQCQvrQEqchv5sRwAlAwAA9wWw From: To: , X-OriginalArrivalTime: 17 Apr 2009 09:59:41.0602 (UTC) FILETIME=[3A258020:01C9BF43] Subject: Re: [mpls-tp] Operator's support for TCM X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:58:29 -0000 Italo, wrote 17 April 2009 10:26 > To: mpls-tp@ietf.org > Subject: [mpls-tp] Operator's support for TCM >=20 > Despite the JWT, it is becoming clear that I have to look forward for > some transport operator willing to voice his view regarding the > requirements for TCM on the MPLS-TP mailing list. >=20 > At the last ITU-T meeting some major transport operator expressed > concerns on the fact that the validity of some transport=20 > requirements is > questioned and their removal from MPLS-TP proposed. >=20 > They have clearly expressed their need to have in MPLS-TP the same > capabilities that ITU-T has defined in G.8131, G.8132 and G.8114. >=20 > Although the need for TCM was not explicitly mentioned, this is a > functionality that ITU-T has defined in G.8114 >=20 > I will further investigate and check for the TCM requirements with my > customers. >=20 > Of course this additional (and IMO unneccessary, because of the JWT > agreement) task will reduce the time I can spend in writing MPLS-TP > drafts. >=20 NH=3D> Can I also ask that operators voice their opinions of whether TCM needs to be applied to IP. IP is a real top-of-stack network and justifiably claim a need for UNIs/E-NNIs.....so, from simple logic, the case for TCM must be stronger here. It is not sensible IMO to ignore IP in this discussion on the need for TCM. regards, Neil =20 From benjamin.niven-jenkins@bt.com Fri Apr 17 03:03:09 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AD63A6A3F for ; Fri, 17 Apr 2009 03:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5888AiCdkOF for ; Fri, 17 Apr 2009 03:03:08 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CF4C43A69F9 for ; Fri, 17 Apr 2009 03:03:07 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 11:04:20 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Apr 2009 10:04:19 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 11:04:17 +0100 From: Ben Niven-Jenkins To: BUSI ITALO , Adrian Farrel , Alexander Vainshtein Message-ID: Thread-Topic: Tandem Connections in MPLS-TP (was RE: [mpls-tp] Associated bidirectional transport path requirements) Thread-Index: Acm+e9jj1HoQiXHcQhKAYvhbYuJx6wAKYxBAABXawM0ADoZp4AABwBsHAADOEkAAAK70XQ== In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B18B5@FRVELSMBS21.ad2.ad.alcatel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Apr 2009 10:04:20.0030 (UTC) FILETIME=[E01A3DE0:01C9BF43] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:03:09 -0000 Italo, I think we are converging. If I can be so bold as to speak on his behalf Adrian's objection seemed to be to the use of the term TCM. It is defined in the MPLS-TP requirements but not used. It is not used in the MPLS-TP OAM requirements document. Therefore I think the way forward is as follows: 1) Remove the term Tandem Connection from the MPLS-TP requirements as it is redundant (i.e. Not used in that document). 2) Ensure the MPLS-TP OAM requirements express the necessary functional requirements around monitoring of end to end paths as well as parts of end to end paths. This can be done without referring explicitly to Tandem Connections. When it comes to solution design we can decide what is the best mechanism to achieve/implement those requirements be it LSP hierarchy or something else. The JWT has proved that it is possible to meet those requirements using existing MPLS technology (maybe with some enhancements). I do not believe we have to necessarily use the solution they propose aslong as whatever solution we ultimately decide upon meets all the necessary requirements expressed. Can we agree on that as an approach and close this off for now? Ben On 17/04/2009 10:49, "BUSI ITALO" wrote: > Ben, > > I think we are mixing solutions with requirements. > > The requirement for the TCM function is clearly defined and I do think > it must be addressed by the MPLS-TP design. > > The solution evaluated by the JWT to meet this requirement was to use > label stacking with a 1:1 relationship between the TCM LSP and the e2e > LSP. > > I think this solution, although not the best technical option, is good > enough and meets the requirements. > > However this is is a solution and has not impact on the requirement. > > Italo > >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >> Sent: Friday, April 17, 2009 11:22 AM >> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >> Cc: mpls-tp@ietf.org; Lou Berger >> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >> Associated bidirectional transport path requirements) >> >> Italo, >> >> On 17/04/2009 09:34, "BUSI ITALO" >> wrote: >>> The JWT agreement is to bring the ITU-T transport >> requirements in IETF >>> to extend the MPLS architecture to meet them in a way that is >>> compatible, consistent and coherent with existing IETF architecture. >> >> So I took a look at the JWT report. It says (slide 16) >> >> " Service Providers want LSPs/PWEs to be able to be managed >> at the different >> nested levels seamlessly (path, segment, multiple segments) >> aka Tandem Connection Monitoring (TCM), this is used for >> example when a >> LSP/PWE crosses multiple administrations" >> >> IMO the requirement is to be able to monitor parts of a path >> as well as the >> end to end path. There are many ways to solve that >> requirement, one of which >> is the creation of nested LSPs, one per level of monitoring >> required (my >> understanding of how TCM works). >> >> I think the real discussion is therefore is the requirement to monitor >> different components of an end to end path or is the >> requirement that such >> monitoring MUST be achieved using nested LSPs? >> >> As an example PW technology today allows end to end and per segment >> monitoring but it does not achieve it using nested PWs or PW levels. >> >> Ben >> >> From maarten.vissers@huawei.com Fri Apr 17 03:17:15 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB2E3A6A3F for ; Fri, 17 Apr 2009 03:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mfnub71iqRl for ; Fri, 17 Apr 2009 03:17:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id DC79D3A68E7 for ; Fri, 17 Apr 2009 03:17:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI800MPAPW7FN@szxga04-in.huawei.com> for mpls-tp@ietf.org; Fri, 17 Apr 2009 18:16:55 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI800CXZPW7VV@szxga04-in.huawei.com> for mpls-tp@ietf.org; Fri, 17 Apr 2009 18:16:55 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI800I4KPW4OG@szxml06-in.huawei.com> for mpls-tp@ietf.org; Fri, 17 Apr 2009 18:16:55 +0800 (CST) Date: Fri, 17 Apr 2009 12:16:57 +0200 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C046FFBA2@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, Italo.Busi@alcatel-lucent.it, mpls-tp@ietf.org Message-id: <006601c9bf45$a4f24800$6570ca0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acm/PoQ2F9OQCQvrQEqchv5sRwAlAwAA9wWwAACwPuA= Subject: Re: [mpls-tp] Operator's support for TCM X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:17:15 -0000 Neil, I would expect that you get a requirement to support "TCM" (which is "monitoring of end to end paths as well as parts of end to end paths") for multi-operator IP VPNs (which are mp2mp IP transport entities). Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: vrijdag 17 april 2009 11:59 To: Italo.Busi@alcatel-lucent.it; mpls-tp@ietf.org Subject: Re: [mpls-tp] Operator's support for TCM Italo, wrote 17 April 2009 10:26 > To: mpls-tp@ietf.org > Subject: [mpls-tp] Operator's support for TCM > > Despite the JWT, it is becoming clear that I have to look forward for > some transport operator willing to voice his view regarding the > requirements for TCM on the MPLS-TP mailing list. > > At the last ITU-T meeting some major transport operator expressed > concerns on the fact that the validity of some transport requirements > is questioned and their removal from MPLS-TP proposed. > > They have clearly expressed their need to have in MPLS-TP the same > capabilities that ITU-T has defined in G.8131, G.8132 and G.8114. > > Although the need for TCM was not explicitly mentioned, this is a > functionality that ITU-T has defined in G.8114 > > I will further investigate and check for the TCM requirements with my > customers. > > Of course this additional (and IMO unneccessary, because of the JWT > agreement) task will reduce the time I can spend in writing MPLS-TP > drafts. > NH=> Can I also ask that operators voice their opinions of whether TCM needs to be applied to IP. IP is a real top-of-stack network and justifiably claim a need for UNIs/E-NNIs.....so, from simple logic, the case for TCM must be stronger here. It is not sensible IMO to ignore IP in this discussion on the need for TCM. regards, Neil _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From adrian@olddog.co.uk Fri Apr 17 03:19:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BC93A696B for ; Fri, 17 Apr 2009 03:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8+sxFiR9sGh for ; Fri, 17 Apr 2009 03:19:44 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 183D93A68E7 for ; Fri, 17 Apr 2009 03:19:43 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3HAJnja012589; Fri, 17 Apr 2009 11:19:49 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3HAJg3o012531; Fri, 17 Apr 2009 11:19:48 +0100 Message-ID: <4A5ED8915FEC4BF4845C6DB981DB5EE8@your029b8cecfe> From: "Adrian Farrel" To: "Ben Niven-Jenkins" , "BUSI ITALO" , "Alexander Vainshtein" References: Date: Fri, 17 Apr 2009 11:13:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:19:45 -0000 Ben, Well captured. That would work for me. A ----- Original Message ----- From: "Ben Niven-Jenkins" To: "BUSI ITALO" ; "Adrian Farrel" ; "Alexander Vainshtein" Cc: ; "Lou Berger" Sent: Friday, April 17, 2009 11:04 AM Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] Associated bidirectional transport path requirements) > Italo, > > I think we are converging. If I can be so bold as to speak on his behalf > Adrian's objection seemed to be to the use of the term TCM. > > It is defined in the MPLS-TP requirements but not used. > > It is not used in the MPLS-TP OAM requirements document. > > Therefore I think the way forward is as follows: > > 1) Remove the term Tandem Connection from the MPLS-TP requirements as it > is > redundant (i.e. Not used in that document). > > 2) Ensure the MPLS-TP OAM requirements express the necessary functional > requirements around monitoring of end to end paths as well as parts of end > to end paths. This can be done without referring explicitly to Tandem > Connections. > > When it comes to solution design we can decide what is the best mechanism > to > achieve/implement those requirements be it LSP hierarchy or something > else. > The JWT has proved that it is possible to meet those requirements using > existing MPLS technology (maybe with some enhancements). I do not believe > we > have to necessarily use the solution they propose aslong as whatever > solution we ultimately decide upon meets all the necessary requirements > expressed. > > Can we agree on that as an approach and close this off for now? > > Ben > > > On 17/04/2009 10:49, "BUSI ITALO" wrote: > >> Ben, >> >> I think we are mixing solutions with requirements. >> >> The requirement for the TCM function is clearly defined and I do think >> it must be addressed by the MPLS-TP design. >> >> The solution evaluated by the JWT to meet this requirement was to use >> label stacking with a 1:1 relationship between the TCM LSP and the e2e >> LSP. >> >> I think this solution, although not the best technical option, is good >> enough and meets the requirements. >> >> However this is is a solution and has not impact on the requirement. >> >> Italo >> >>> -----Original Message----- >>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>> Sent: Friday, April 17, 2009 11:22 AM >>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>> Cc: mpls-tp@ietf.org; Lou Berger >>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>> Associated bidirectional transport path requirements) >>> >>> Italo, >>> >>> On 17/04/2009 09:34, "BUSI ITALO" >>> wrote: >>>> The JWT agreement is to bring the ITU-T transport >>> requirements in IETF >>>> to extend the MPLS architecture to meet them in a way that is >>>> compatible, consistent and coherent with existing IETF architecture. >>> >>> So I took a look at the JWT report. It says (slide 16) >>> >>> " Service Providers want LSPs/PWEs to be able to be managed >>> at the different >>> nested levels seamlessly (path, segment, multiple segments) >>> aka Tandem Connection Monitoring (TCM), this is used for >>> example when a >>> LSP/PWE crosses multiple administrations" >>> >>> IMO the requirement is to be able to monitor parts of a path >>> as well as the >>> end to end path. There are many ways to solve that >>> requirement, one of which >>> is the creation of nested LSPs, one per level of monitoring >>> required (my >>> understanding of how TCM works). >>> >>> I think the real discussion is therefore is the requirement to monitor >>> different components of an end to end path or is the >>> requirement that such >>> monitoring MUST be achieved using nested LSPs? >>> >>> As an example PW technology today allows end to end and per segment >>> monitoring but it does not achieve it using nested PWs or PW levels. >>> >>> Ben >>> >>> > > From Italo.Busi@alcatel-lucent.it Fri Apr 17 03:26:06 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302113A6ABC for ; Fri, 17 Apr 2009 03:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.864 X-Spam-Level: X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIO-tTn-u4xt for ; Fri, 17 Apr 2009 03:26:05 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 261E13A68E7 for ; Fri, 17 Apr 2009 03:25:36 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HAQlIE023062; Fri, 17 Apr 2009 12:26:48 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 12:26:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 12:26:27 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B18E4@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C046FFBA2@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Operator's support for TCM Thread-Index: Acm/PoQ2F9OQCQvrQEqchv5sRwAlAwAA9wWwAAEQyfA= References: <6FD21B53861BF44AA90A288402036AB4021B188D@FRVELSMBS21.ad2.ad.alcatel.com> <2ECAA42C79676B42AEBAC11229CA7D0C046FFBA2@E03MVB2-UKBR.domain1.systemhost.net> From: "BUSI ITALO" To: , X-OriginalArrivalTime: 17 Apr 2009 10:26:28.0215 (UTC) FILETIME=[F7C33070:01C9BF46] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [mpls-tp] Operator's support for TCM X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:26:06 -0000 Neil, We are working on MPLS-TP and not on IP-TP I think it is up to IP operators and not to transport operators to voice their requirement, or lack of requirement, for TCM in IP. Italo=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, April 17, 2009 11:59 AM > To: BUSI ITALO; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Operator's support for TCM >=20 > Italo, >=20 > wrote 17 April 2009 10:26 > > To: mpls-tp@ietf.org > > Subject: [mpls-tp] Operator's support for TCM > >=20 > > Despite the JWT, it is becoming clear that I have to look=20 > forward for > > some transport operator willing to voice his view regarding the > > requirements for TCM on the MPLS-TP mailing list. > >=20 > > At the last ITU-T meeting some major transport operator expressed > > concerns on the fact that the validity of some transport=20 > > requirements is > > questioned and their removal from MPLS-TP proposed. > >=20 > > They have clearly expressed their need to have in MPLS-TP the same > > capabilities that ITU-T has defined in G.8131, G.8132 and G.8114. > >=20 > > Although the need for TCM was not explicitly mentioned, this is a > > functionality that ITU-T has defined in G.8114 > >=20 > > I will further investigate and check for the TCM=20 > requirements with my > > customers. > >=20 > > Of course this additional (and IMO unneccessary, because of the JWT > > agreement) task will reduce the time I can spend in writing MPLS-TP > > drafts. > >=20 > NH=3D> Can I also ask that operators voice their opinions of whether = TCM > needs to be applied to IP. IP is a real top-of-stack network and > justifiably claim a need for UNIs/E-NNIs.....so, from simple=20 > logic, the > case for TCM must be stronger here. It is not sensible IMO=20 > to ignore IP > in this discussion on the need for TCM. >=20 > regards, Neil =20 >=20 From adrian@olddog.co.uk Fri Apr 17 03:34:54 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B8B3A68E7 for ; Fri, 17 Apr 2009 03:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuIKcNWD8sif for ; Fri, 17 Apr 2009 03:34:53 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 53DF53A6AEC for ; Fri, 17 Apr 2009 03:34:53 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3HAYvlj025290; Fri, 17 Apr 2009 11:34:57 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3HAYtpF025270; Fri, 17 Apr 2009 11:34:56 +0100 Message-ID: <142D9DE20A7943A398EE1007B623434B@your029b8cecfe> From: "Adrian Farrel" To: "BUSI ITALO" , "Drake, John E" , "Sprecher, Nurit ¥(NSN - IL/Hod HaSharon¥)" , "ext Ben Niven-Jenkins" , "Alexander Vainshtein" References: <077E41CFFD002C4CAB7DFA4386A5326490D75F@DEMUEXC014.nsn-intra.net> <51661468CBD1354294533DA79E85955A01A6BB14@XCH-SW-5V2.sw.nos.boeing.com> <6FD21B53861BF44AA90A288402036AB4021B1830@FRVELSMBS21.ad2.ad.alcatel.com> Date: Fri, 17 Apr 2009 11:21:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement for TCM or not. X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:34:55 -0000 Italo, We sat in a small room in Geneva and discussed this extensively. The requirement you expressed there was to be able to diagnose individual paths. It was not a requirement to perform any specific solution. If we are going to make any progress at all we must learn to decouple requirements from solutions. We are engineers, so this is hard - as soon as we see a problem we think of a solution. But to get the solution right we must work out how to express our requirements clearly as functional behavior in terms of basic building blocks. Adrian ----- Original Message ----- From: "BUSI ITALO" To: "Drake, John E" ; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" ; "ext Ben Niven-Jenkins" ; "Alexander Vainshtein" ; "Adrian Farrel" Cc: Sent: Friday, April 17, 2009 9:20 AM Subject: RE: [mpls-tp] Requirement for TCM or not. John, There is a 1:1 relationship between a TCM instance and the LSP it is monitoring. I have never agreed to generalize it into a 1:N relationship. Italo > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Thursday, April 16, 2009 7:55 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ben > Niven-Jenkins; Alexander Vainshtein; Adrian Farrel > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Requirement for TCM or not. > > Nurit, > > As I recall, there is a 1:1 relationship between a TCM > instance and the > LSP it is monitoring. I thought we had agreed (a long time ago) to > generalize this into a 1:N capability, and hence TCM became PST. > > Thanks, > > John > > > -----Original Message----- > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > [mailto:nurit.sprecher@nsn.com] > > Sent: Thursday, April 16, 2009 10:25 AM > > To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Requirement for TCM or not. > > > > Hi, > > TC is a solution to the requirement to manage, monitor and > > protect the network at different nested levels. > > The work on MPLS-TP started with this basic requirement that > > came from the ITU-T. > > I think we should continue and address this requirement as > > our commitment to the ITU-T. > > About the solution, there is room for discussion. Is it TC, > > PST or something else? As promised I'll provide next week > > some text about this. > > > > Best regards, > > Nurit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins > > Sent: Thursday, April 16, 2009 7:54 PM > > To: Alexander Vainshtein; Adrian Farrel > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: [mpls-tp] Requirement for TCM or not. > > > > On 16/04/2009 12:39, "Alexander Vainshtein" > > > I fully support your proposal to get rid (in a consistent > > manner) from > > the TC > > > stuff in MPLS-TP, especially since, to the best of my knowledge, > > operational > > > experience with SONET/SDH TCM (ITU-T definitions > > notwithstanding) did > > not > > > prove its worth. If this is based on mis-perception, I > would be glad > > to hear > > > that (especially from the operators on this list). > > > > BT has no requirement for TCM. We do not have it deployed in > > our TDM networks today and have no current plans to use it in > > any of our networks in the future. > > > > Ben > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > From loa@pi.nu Fri Apr 17 04:13:26 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600B73A68AC for ; Fri, 17 Apr 2009 04:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMDzwyBLSvVU for ; Fri, 17 Apr 2009 04:13:25 -0700 (PDT) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 25C6B28C126 for ; Fri, 17 Apr 2009 04:13:24 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 5AAE12D852C; Fri, 17 Apr 2009 13:14:36 +0200 (CEST) Message-ID: <49E86497.6080702@pi.nu> Date: Fri, 17 Apr 2009 13:14:31 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ben Niven-Jenkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 11:13:26 -0000 Ben, this would work for me /Loa Ben Niven-Jenkins wrote: > Italo, > > I think we are converging. If I can be so bold as to speak on his behalf > Adrian's objection seemed to be to the use of the term TCM. > > It is defined in the MPLS-TP requirements but not used. > > It is not used in the MPLS-TP OAM requirements document. > > Therefore I think the way forward is as follows: > > 1) Remove the term Tandem Connection from the MPLS-TP requirements as it is > redundant (i.e. Not used in that document). > > 2) Ensure the MPLS-TP OAM requirements express the necessary functional > requirements around monitoring of end to end paths as well as parts of end > to end paths. This can be done without referring explicitly to Tandem > Connections. > > When it comes to solution design we can decide what is the best mechanism to > achieve/implement those requirements be it LSP hierarchy or something else. > The JWT has proved that it is possible to meet those requirements using > existing MPLS technology (maybe with some enhancements). I do not believe we > have to necessarily use the solution they propose aslong as whatever > solution we ultimately decide upon meets all the necessary requirements > expressed. > > Can we agree on that as an approach and close this off for now? > > Ben > > > On 17/04/2009 10:49, "BUSI ITALO" wrote: > >> Ben, >> >> I think we are mixing solutions with requirements. >> >> The requirement for the TCM function is clearly defined and I do think >> it must be addressed by the MPLS-TP design. >> >> The solution evaluated by the JWT to meet this requirement was to use >> label stacking with a 1:1 relationship between the TCM LSP and the e2e >> LSP. >> >> I think this solution, although not the best technical option, is good >> enough and meets the requirements. >> >> However this is is a solution and has not impact on the requirement. >> >> Italo >> >>> -----Original Message----- >>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>> Sent: Friday, April 17, 2009 11:22 AM >>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>> Cc: mpls-tp@ietf.org; Lou Berger >>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>> Associated bidirectional transport path requirements) >>> >>> Italo, >>> >>> On 17/04/2009 09:34, "BUSI ITALO" >>> wrote: >>>> The JWT agreement is to bring the ITU-T transport >>> requirements in IETF >>>> to extend the MPLS architecture to meet them in a way that is >>>> compatible, consistent and coherent with existing IETF architecture. >>> So I took a look at the JWT report. It says (slide 16) >>> >>> " Service Providers want LSPs/PWEs to be able to be managed >>> at the different >>> nested levels seamlessly (path, segment, multiple segments) >>> aka Tandem Connection Monitoring (TCM), this is used for >>> example when a >>> LSP/PWE crosses multiple administrations" >>> >>> IMO the requirement is to be able to monitor parts of a path >>> as well as the >>> end to end path. There are many ways to solve that >>> requirement, one of which >>> is the creation of nested LSPs, one per level of monitoring >>> required (my >>> understanding of how TCM works). >>> >>> I think the real discussion is therefore is the requirement to monitor >>> different components of an end to end path or is the >>> requirement that such >>> monitoring MUST be achieved using nested LSPs? >>> >>> As an example PW technology today allows end to end and per segment >>> monitoring but it does not achieve it using nested PWs or PW levels. >>> >>> Ben >>> >>> > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From prvs=3515cf1ca=eloaand@redback.com Fri Apr 17 04:11:32 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979913A6A03 for ; Fri, 17 Apr 2009 04:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QkZhysmWEml for ; Fri, 17 Apr 2009 04:11:31 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id A992F3A68AC for ; Fri, 17 Apr 2009 04:11:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,203,1239001200"; d="scan'208";a="1008671" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 17 Apr 2009 04:12:45 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7FCF145C163; Fri, 17 Apr 2009 04:12:45 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16760-09; Fri, 17 Apr 2009 04:12:45 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 04EAA45C162; Fri, 17 Apr 2009 04:12:44 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Fri, 17 Apr 2009 04:11:53 -0700 From: Loa Andersson To: Ben Niven-Jenkins , BUSI ITALO , Adrian Farrel , Alexander Vainshtein Date: Fri, 17 Apr 2009 04:11:42 -0700 Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm+e9jj1HoQiXHcQhKAYvhbYuJx6wAKYxBAABXawM0ADoZp4AABwBsHAADOEkAAAK70XQACWHnA Message-ID: References: <6FD21B53861BF44AA90A288402036AB4021B18B5@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: 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 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 11:16:06 -0000 This would work for me /Loa -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins Sent: Friday, April 17, 2009 12:04 PM To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bi= directional transport path requirements) Italo, I think we are converging. If I can be so bold as to speak on his behalf Adrian's objection seemed to be to the use of the term TCM. It is defined in the MPLS-TP requirements but not used. It is not used in the MPLS-TP OAM requirements document. Therefore I think the way forward is as follows: 1) Remove the term Tandem Connection from the MPLS-TP requirements as it is redundant (i.e. Not used in that document). 2) Ensure the MPLS-TP OAM requirements express the necessary functional requirements around monitoring of end to end paths as well as parts of end to end paths. This can be done without referring explicitly to Tandem Connections. When it comes to solution design we can decide what is the best mechanism t= o achieve/implement those requirements be it LSP hierarchy or something else. The JWT has proved that it is possible to meet those requirements using existing MPLS technology (maybe with some enhancements). I do not believe w= e have to necessarily use the solution they propose aslong as whatever solution we ultimately decide upon meets all the necessary requirements expressed. Can we agree on that as an approach and close this off for now? Ben On 17/04/2009 10:49, "BUSI ITALO" wrote: > Ben, >=20 > I think we are mixing solutions with requirements. >=20 > The requirement for the TCM function is clearly defined and I do think > it must be addressed by the MPLS-TP design. >=20 > The solution evaluated by the JWT to meet this requirement was to use > label stacking with a 1:1 relationship between the TCM LSP and the e2e > LSP. >=20 > I think this solution, although not the best technical option, is good > enough and meets the requirements. >=20 > However this is is a solution and has not impact on the requirement. >=20 > Italo >=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >> Sent: Friday, April 17, 2009 11:22 AM >> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >> Cc: mpls-tp@ietf.org; Lou Berger >> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >> Associated bidirectional transport path requirements) >>=20 >> Italo, >>=20 >> On 17/04/2009 09:34, "BUSI ITALO" >> wrote: >>> The JWT agreement is to bring the ITU-T transport >> requirements in IETF >>> to extend the MPLS architecture to meet them in a way that is >>> compatible, consistent and coherent with existing IETF architecture. >>=20 >> So I took a look at the JWT report. It says (slide 16) >>=20 >> " Service Providers want LSPs/PWEs to be able to be managed >> at the different >> nested levels seamlessly (path, segment, multiple segments) >> aka Tandem Connection Monitoring (TCM), this is used for >> example when a >> LSP/PWE crosses multiple administrations" >>=20 >> IMO the requirement is to be able to monitor parts of a path >> as well as the >> end to end path. There are many ways to solve that >> requirement, one of which >> is the creation of nested LSPs, one per level of monitoring >> required (my >> understanding of how TCM works). >>=20 >> I think the real discussion is therefore is the requirement to monitor >> different components of an end to end path or is the >> requirement that such >> monitoring MUST be achieved using nested LSPs? >>=20 >> As an example PW technology today allows end to end and per segment >> monitoring but it does not achieve it using nested PWs or PW levels. >>=20 >> Ben >>=20 >>=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From Martin.Vigoureux@alcatel-lucent.com Fri Apr 17 04:28:09 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1861F3A6C88 for ; Fri, 17 Apr 2009 04:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxNnyvZpyRCo for ; Fri, 17 Apr 2009 04:28:08 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E92BF3A69D8 for ; Fri, 17 Apr 2009 04:28:07 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HBSk1p012887; Fri, 17 Apr 2009 13:28:46 +0200 Received: from [135.244.33.0] ([135.244.33.0]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 13:28:45 +0200 Message-ID: <49E867E1.7050403@alcatel-lucent.com> Date: Fri, 17 Apr 2009 13:28:33 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ben Niven-Jenkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Apr 2009 11:28:45.0733 (UTC) FILETIME=[AB7F2D50:01C9BF4F] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 11:28:09 -0000 Ben, all in mpls-tp-oam-requirement, the text on this item is as follows: The service emulated by a single segment or a multi-segment PW may span multiple domains. A LSP may also span multiple domains. It MUST be possible to perform OAM functions on a per domain basis and across multiple domains. More generally it MUST be possible to perform OAM functions between any two switching elements (e.g., LSR or S-PE) of a LSP or of PW. This is referred to as (concatenated) segment monitoring. I believe the text describes a functional req. During mead team review, the removal of the last sentence was discussed. No strong opinion was expressed on whether it should effectively be removed or not. regards, martin Ben Niven-Jenkins a �crit : > Italo, > > I think we are converging. If I can be so bold as to speak on his behalf > Adrian's objection seemed to be to the use of the term TCM. > > It is defined in the MPLS-TP requirements but not used. > > It is not used in the MPLS-TP OAM requirements document. > > Therefore I think the way forward is as follows: > > 1) Remove the term Tandem Connection from the MPLS-TP requirements as it is > redundant (i.e. Not used in that document). > > 2) Ensure the MPLS-TP OAM requirements express the necessary functional > requirements around monitoring of end to end paths as well as parts of end > to end paths. This can be done without referring explicitly to Tandem > Connections. > > When it comes to solution design we can decide what is the best mechanism to > achieve/implement those requirements be it LSP hierarchy or something else. > The JWT has proved that it is possible to meet those requirements using > existing MPLS technology (maybe with some enhancements). I do not believe we > have to necessarily use the solution they propose aslong as whatever > solution we ultimately decide upon meets all the necessary requirements > expressed. > > Can we agree on that as an approach and close this off for now? > > Ben > > > On 17/04/2009 10:49, "BUSI ITALO" wrote: > >> Ben, >> >> I think we are mixing solutions with requirements. >> >> The requirement for the TCM function is clearly defined and I do think >> it must be addressed by the MPLS-TP design. >> >> The solution evaluated by the JWT to meet this requirement was to use >> label stacking with a 1:1 relationship between the TCM LSP and the e2e >> LSP. >> >> I think this solution, although not the best technical option, is good >> enough and meets the requirements. >> >> However this is is a solution and has not impact on the requirement. >> >> Italo >> >>> -----Original Message----- >>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>> Sent: Friday, April 17, 2009 11:22 AM >>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>> Cc: mpls-tp@ietf.org; Lou Berger >>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>> Associated bidirectional transport path requirements) >>> >>> Italo, >>> >>> On 17/04/2009 09:34, "BUSI ITALO" >>> wrote: >>>> The JWT agreement is to bring the ITU-T transport >>> requirements in IETF >>>> to extend the MPLS architecture to meet them in a way that is >>>> compatible, consistent and coherent with existing IETF architecture. >>> So I took a look at the JWT report. It says (slide 16) >>> >>> " Service Providers want LSPs/PWEs to be able to be managed >>> at the different >>> nested levels seamlessly (path, segment, multiple segments) >>> aka Tandem Connection Monitoring (TCM), this is used for >>> example when a >>> LSP/PWE crosses multiple administrations" >>> >>> IMO the requirement is to be able to monitor parts of a path >>> as well as the >>> end to end path. There are many ways to solve that >>> requirement, one of which >>> is the creation of nested LSPs, one per level of monitoring >>> required (my >>> understanding of how TCM works). >>> >>> I think the real discussion is therefore is the requirement to monitor >>> different components of an end to end path or is the >>> requirement that such >>> monitoring MUST be achieved using nested LSPs? >>> >>> As an example PW technology today allows end to end and per segment >>> monitoring but it does not achieve it using nested PWs or PW levels. >>> >>> Ben >>> >>> > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From adrian@olddog.co.uk Fri Apr 17 04:38:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3FF93A6DBF for ; Fri, 17 Apr 2009 04:38:41 -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=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGUZcp1rg+xA for ; Fri, 17 Apr 2009 04:38:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 6B2513A6DBD for ; Fri, 17 Apr 2009 04:38:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3HBcMWr032312; Fri, 17 Apr 2009 12:38:23 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3HBcII8032241; Fri, 17 Apr 2009 12:38:20 +0100 Message-ID: <86E15600C3DB47ABB8C09350185A9FFC@your029b8cecfe> From: "Adrian Farrel" To: "Martin Vigoureux" , "Ben Niven-Jenkins" References: <49E867E1.7050403@alcatel-lucent.com> Date: Fri, 17 Apr 2009 12:38:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 11:38:41 -0000 Martin, This is a good example of how to write a functional requirement. Thanks! Adrian ----- Original Message ----- From: "Martin Vigoureux" To: "Ben Niven-Jenkins" Cc: "BUSI ITALO" ; "Adrian Farrel" ; "Alexander Vainshtein" ; Sent: Friday, April 17, 2009 12:28 PM Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) > Ben, all > > in mpls-tp-oam-requirement, the text on this item is as follows: > > The service emulated by a single segment or a multi-segment PW may > span multiple domains. A LSP may also span multiple domains. It > MUST be possible to perform OAM functions on a per domain basis and > across multiple domains. More generally it MUST be possible to > perform OAM functions between any two switching elements (e.g., LSR > or S-PE) of a LSP or of PW. This is referred to as (concatenated) > segment monitoring. > > I believe the text describes a functional req. > > During mead team review, the removal of the last sentence was discussed. > No strong opinion was expressed on whether it should effectively be > removed or not. > > regards, > martin > > Ben Niven-Jenkins a �crit : >> Italo, >> >> I think we are converging. If I can be so bold as to speak on his behalf >> Adrian's objection seemed to be to the use of the term TCM. >> >> It is defined in the MPLS-TP requirements but not used. >> >> It is not used in the MPLS-TP OAM requirements document. >> >> Therefore I think the way forward is as follows: >> >> 1) Remove the term Tandem Connection from the MPLS-TP requirements as it >> is >> redundant (i.e. Not used in that document). >> >> 2) Ensure the MPLS-TP OAM requirements express the necessary functional >> requirements around monitoring of end to end paths as well as parts of >> end >> to end paths. This can be done without referring explicitly to Tandem >> Connections. >> >> When it comes to solution design we can decide what is the best mechanism >> to >> achieve/implement those requirements be it LSP hierarchy or something >> else. >> The JWT has proved that it is possible to meet those requirements using >> existing MPLS technology (maybe with some enhancements). I do not believe >> we >> have to necessarily use the solution they propose aslong as whatever >> solution we ultimately decide upon meets all the necessary requirements >> expressed. >> >> Can we agree on that as an approach and close this off for now? >> >> Ben >> >> >> On 17/04/2009 10:49, "BUSI ITALO" wrote: >> >>> Ben, >>> >>> I think we are mixing solutions with requirements. >>> >>> The requirement for the TCM function is clearly defined and I do think >>> it must be addressed by the MPLS-TP design. >>> >>> The solution evaluated by the JWT to meet this requirement was to use >>> label stacking with a 1:1 relationship between the TCM LSP and the e2e >>> LSP. >>> >>> I think this solution, although not the best technical option, is good >>> enough and meets the requirements. >>> >>> However this is is a solution and has not impact on the requirement. >>> >>> Italo >>> >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>>> Sent: Friday, April 17, 2009 11:22 AM >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>>> Cc: mpls-tp@ietf.org; Lou Berger >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>>> Associated bidirectional transport path requirements) >>>> >>>> Italo, >>>> >>>> On 17/04/2009 09:34, "BUSI ITALO" >>>> wrote: >>>>> The JWT agreement is to bring the ITU-T transport >>>> requirements in IETF >>>>> to extend the MPLS architecture to meet them in a way that is >>>>> compatible, consistent and coherent with existing IETF architecture. >>>> So I took a look at the JWT report. It says (slide 16) >>>> >>>> " Service Providers want LSPs/PWEs to be able to be managed >>>> at the different >>>> nested levels seamlessly (path, segment, multiple segments) >>>> aka Tandem Connection Monitoring (TCM), this is used for >>>> example when a >>>> LSP/PWE crosses multiple administrations" >>>> >>>> IMO the requirement is to be able to monitor parts of a path >>>> as well as the >>>> end to end path. There are many ways to solve that >>>> requirement, one of which >>>> is the creation of nested LSPs, one per level of monitoring >>>> required (my >>>> understanding of how TCM works). >>>> >>>> I think the real discussion is therefore is the requirement to monitor >>>> different components of an end to end path or is the >>>> requirement that such >>>> monitoring MUST be achieved using nested LSPs? >>>> >>>> As an example PW technology today allows end to end and per segment >>>> monitoring but it does not achieve it using nested PWs or PW levels. >>>> >>>> Ben >>>> >>>> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > From annamaria.fulignoli@ericsson.com Fri Apr 17 06:51:51 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17C93A68CB for ; Fri, 17 Apr 2009 06:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjtGzeNYC-ue for ; Fri, 17 Apr 2009 06:51:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 883D73A6ABD for ; Fri, 17 Apr 2009 06:51:50 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1350222E1; Fri, 17 Apr 2009 15:53:02 +0200 (CEST) X-AuditID: c1b4fb3e-af826bb0000024d5-69-49e86d63ec2e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9C64E220EB; Fri, 17 Apr 2009 13:52:03 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 13:51:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 13:51:53 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> In-Reply-To: <49E867E1.7050403@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQ References: <49E867E1.7050403@alcatel-lucent.com> From: "Annamaria Fulignoli" To: "Martin Vigoureux" , "Ben Niven-Jenkins" X-OriginalArrivalTime: 17 Apr 2009 11:51:55.0311 (UTC) FILETIME=[E7BFF3F0:01C9BF52] X-Brightmail-Tracker: AAAAAA== Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:51:51 -0000 Hi all, sorry but I do not understand why we cannot explicitly use the term = Tandem Connection in the requirements document! TCM is not a solution, it is part of functional architecture of a = transport networks as described in G.805. The solution is to realize it = with label stacking rather than MEL.=20 Regards Annamaria -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Martin Vigoureux Sent: venerd=EC 17 aprile 2009 13.29 To: Ben Niven-Jenkins Cc: BUSI ITALO; mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated = bidirectional transport path requirements) Ben, all in mpls-tp-oam-requirement, the text on this item is as follows: The service emulated by a single segment or a multi-segment PW may span multiple domains. A LSP may also span multiple domains. It MUST be possible to perform OAM functions on a per domain basis and across multiple domains. More generally it MUST be possible to perform OAM functions between any two switching elements (e.g., LSR or S-PE) of a LSP or of PW. This is referred to as (concatenated) segment monitoring. I believe the text describes a functional req. During mead team review, the removal of the last sentence was discussed. No strong opinion was expressed on whether it should effectively be = removed or not. regards, martin Ben Niven-Jenkins a =E9crit : > Italo, >=20 > I think we are converging. If I can be so bold as to speak on his=20 > behalf Adrian's objection seemed to be to the use of the term TCM. >=20 > It is defined in the MPLS-TP requirements but not used. >=20 > It is not used in the MPLS-TP OAM requirements document. >=20 > Therefore I think the way forward is as follows: >=20 > 1) Remove the term Tandem Connection from the MPLS-TP requirements as=20 > it is redundant (i.e. Not used in that document). >=20 > 2) Ensure the MPLS-TP OAM requirements express the necessary=20 > functional requirements around monitoring of end to end paths as well=20 > as parts of end to end paths. This can be done without referring=20 > explicitly to Tandem Connections. >=20 > When it comes to solution design we can decide what is the best=20 > mechanism to achieve/implement those requirements be it LSP hierarchy = or something else. > The JWT has proved that it is possible to meet those requirements=20 > using existing MPLS technology (maybe with some enhancements). I do=20 > not believe we have to necessarily use the solution they propose=20 > aslong as whatever solution we ultimately decide upon meets all the=20 > necessary requirements expressed. >=20 > Can we agree on that as an approach and close this off for now? >=20 > Ben >=20 >=20 > On 17/04/2009 10:49, "BUSI ITALO" = wrote: >=20 >> Ben, >> >> I think we are mixing solutions with requirements. >> >> The requirement for the TCM function is clearly defined and I do=20 >> think it must be addressed by the MPLS-TP design. >> >> The solution evaluated by the JWT to meet this requirement was to use = >> label stacking with a 1:1 relationship between the TCM LSP and the=20 >> e2e LSP. >> >> I think this solution, although not the best technical option, is=20 >> good enough and meets the requirements. >> >> However this is is a solution and has not impact on the requirement. >> >> Italo >> >>> -----Original Message----- >>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>> Sent: Friday, April 17, 2009 11:22 AM >>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>> Cc: mpls-tp@ietf.org; Lou Berger >>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp]=20 >>> Associated bidirectional transport path requirements) >>> >>> Italo, >>> >>> On 17/04/2009 09:34, "BUSI ITALO" >>> wrote: >>>> The JWT agreement is to bring the ITU-T transport >>> requirements in IETF >>>> to extend the MPLS architecture to meet them in a way that is=20 >>>> compatible, consistent and coherent with existing IETF = architecture. >>> So I took a look at the JWT report. It says (slide 16) >>> >>> " Service Providers want LSPs/PWEs to be able to be managed at the=20 >>> different nested levels seamlessly (path, segment, multiple=20 >>> segments) >>> aka Tandem Connection Monitoring (TCM), this is used for example = >>> when a LSP/PWE crosses multiple administrations" >>> >>> IMO the requirement is to be able to monitor parts of a path as well = >>> as the end to end path. There are many ways to solve that=20 >>> requirement, one of which is the creation of nested LSPs, one per=20 >>> level of monitoring required (my understanding of how TCM works). >>> >>> I think the real discussion is therefore is the requirement to=20 >>> monitor different components of an end to end path or is the=20 >>> requirement that such monitoring MUST be achieved using nested LSPs? >>> >>> As an example PW technology today allows end to end and per segment=20 >>> monitoring but it does not achieve it using nested PWs or PW levels. >>> >>> Ben >>> >>> >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From lberger@labn.net Fri Apr 17 06:53:30 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8434A3A6ABD for ; Fri, 17 Apr 2009 06:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsV88VIdwSYu for ; Fri, 17 Apr 2009 06:53:29 -0700 (PDT) Received: from outbound-mail-22.bluehost.com (outbound-mail-22.bluehost.com [69.89.21.17]) by core3.amsl.com (Postfix) with SMTP id 21F423A68CB for ; Fri, 17 Apr 2009 06:53:29 -0700 (PDT) Received: (qmail 9018 invoked by uid 0); 17 Apr 2009 12:54:17 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy2.bluehost.com with SMTP; 17 Apr 2009 12:54:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dBbiwznp4HvbOb+A4cCG2poohy6UuPB3b1dVV31n+pMszhe/1qM8VOk5KkDYwBCULho1JG4bWvHVxEVxzunG8VGZqHnRE4Z/CZvatV5WWhlvkRl8ul2zeS//a4CNSbW2; Received: from box474.bluehost.com ([74.220.219.74] helo=[127.0.0.1]) by box474.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LuoWg-0001Jx-IB; Fri, 17 Apr 2009 07:54:42 -0600 Message-ID: <49E88A21.9060309@labn.net> Date: Fri, 17 Apr 2009 09:54:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: liu.guoman@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {2629:box474.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.220.219.74 authed with lberger@labn.net} Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:53:30 -0000 Liu, Why isn't it necessary for associated bidirectional paths? Is it that asymmetric is the sole requirement? If not, I don't understand your comment. Lou On 4/16/2009 9:15 PM, liu.guoman@zte.com.cn wrote: > > Lou: > I agree your advice, but for symmetric bandwidth requirement, I think > the requirement can only be fit for co-routed bidirectional transport > paths, while it isn't necessary for associated bidirectional paths .so > adding a "co-routed" word in the requirement 33 is necessary. > thank you. > liu > > > *Lou Berger * > ��: mpls-tp-bounces@ietf.org > > 2009-04-16 21:43 > > > �� > Ben Niven-Jenkins > �� > BUSI@core3.amsl.com, "mpls-tp@ietf.org" , ITALO > > �� > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > > > Ben, > It seems to me that much of the discussion stems from the section in > which these requirements are listed. > > Requirement 32 is a service level requirement and primarily impact the > management and control planes. As there is no section describing > service requirements, I suggest moving this requirement to follow > requirement 6, and adding the following in its place: > 33 MPLS-TP MUST support bidirectional transport paths with > symmetric bandwidth requirements, i.e. the amount of reserved > bandwidth is the same between the forward and backward > directions. > > While this too is a service requirement and doesn't require any hardware > modifications, it parallels current requirements 37, 40 and 41. It also > makes a currently implicit requirement explicit. > > Requirements 33-26 relate to "awareness" should have no implication on > the data/forwarding plane and are IMO both management and control plane > requirements. (And yes, they have implications on OAM and recovery.) I > think Adrian raises a good point WRT these requirements, i.e., are these > requirements listed as solutions to some unlisted requirements. If so, > the unlisted requirements should be included and these should be > dropped. If not, so be it, but they should be moved from section 2.3. > > While I'm sure this won't end the discussion, I think these changes will > help make "the requirements clear enough ..." > > Lou > > On 4/16/2009 5:58 AM, Ben Niven-Jenkins wrote: > > Colleagues, > > > > I can't help but feel we are overanalysing things here. How many > > technologies/protocols/mechanisms have we successfully defined in > both IETF > > & ITU-T without this level of analysis of the initial requirements - > a great > > many (a good chunk of which were extremely successful). > > > > The requirements document is not about specifying solutions. > > > > The key question is: are the requirements clear enough that it is > understood > > what is required so someone could build a box/protocol/whatever to meet > > them? > > > > If we want to go into the nth level of detail on each requirement we will > > still be debating this by the time I retire (which isn't due until 2045). > > > > Ben > > > > > > On 16/04/2009 08:04, "Alexander Vainshtein" > > wrote: > > > >> Adrian, > >> Thank you for a prompt and detailed response. > >> > >> Unfortunately I cannot fully agree with your statement: > >> > >> > >> From the point of view of hardware, co-routed bidirectional LSPs > >> are a special case of associated bidirectional LSPs. > >> > >> > >> This statement would be obviously correct, were it not for > Requirement 34 in > >> the latest > >> MPLS-TP requirements draft > >> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.txt): > >> > >> > >> The intermediate nodes (including MEPs, MIPs and other internal > >> functions as appropriate) of a co-routed bidirectional transport > >> path at each (sub-)layer MUST be aware of the pairing > >> relationship of the forward and the backward directions of that > >> transport path. > >> > >> > >> Please note that Requirement 34 is the ONLY item in the list that is > specific > >> for co-routed bidirectional LSPs. (The pairing requirements at end > points > >> for co-routed and associated bidirectional paths are exactly the > same even > >> if they appear in two different items in the requirements' list). > >> In other words, without Requirement 34 the notion of co-routed > bidirectional > >> paths would be void of any data plane content. > >> > >> The somewhat vague scope of this requirement ("other internal functions > >> as appropriate") creates a suspicion that HW support of the pairing > awareness > >> may be required in order to comply with it. > >> > >> The following text in the draft increases this suspicion: > >> > >> > >> Tandem Connection: A tandem connection is an arbitrary part of a > >> transport path that can be monitored (via OAM) independently from the > >> end-to-end monitoring (OAM). It may be a monitored segment or a > >> monitored concatenated segment of a transport path. The tandem > >> connection may also include the forwarding engine(s) of the node(s) > >> at the edge(s) of the segment or concatenated segment. > >> > >> > >> Doesn't "forwarding engine" sound like hardware to you? > >> > >> IMHO it is worth noting that neither the MPLS-TP Requirements draft > >> nor the MPLS-TP OAM requirements one > >> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01.tx > >> t) > >> contain any requirements dealing with tandem connections. > >> > >> But tandem connections are discussed in the MPLS-TP OAM Framework draft > >> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt). > >> > >> The bottom line, IMHO, is that some clarity regarding co-routed vs. > associated > >> bidirectional > >> paths is still required. One way to provide that could be by explicitly > >> limiting Requirement 34 > >> to specific functionality. > >> > >> My 2c, > >> Sasha > >> > >> > >> > >> > >> > >> ________________________________________ > >> From: Adrian Farrel [adrian@olddog.co.uk] > >> Sent: Thursday, April 16, 2009 12:13 AM > >> To: Alexander Vainshtein; Lou Berger; BUSI ITALO > >> Cc: mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > >> > >> Hi Sasha, > >> > >> Not really sure whether you are misrepresenting anyone, but... > >> > >>> 1. My reading of one of Ben's messages is that associated > >>> bidirectional paths are the only types of paths that can be > >>> created in the existing networks; "true" co-routed bidirectional > >>> paths will have to wait until (if ever) new equipment becomes > >>> available. > >> This is clearly nonsense! > >> From the point of view of hardware, co-routed bidirectional LSPs are a > >> special case of associated bidirectional LSPs. > >> > >> If you can set up two unidirectional LSPs (e.g. using the management > plane) > >> you can surely set up a co-routed bidirectional LSP. > >> > >> There are shipping solutions that achieve co-routed bidirectional > LSPs using > >> the control plane. These either use the GMPLS (which is cleaner) or > >> non-standard proprietary solutions (which is messy but functional). > >> > >> But (of course) the management plane or control plane solutions have > nothing > >> to do with availability of equipment as they are software solutions. > >> > >>> 2. My reading of one of Neil's messages is that the actual driver for > >>> co-routed > >>> bidirectional paths may be experience with existing transport networks > >>> rather > >>> than any specific benefit. > >> Isn't that the case with 75% of the MPLS-TP requirements? > >> Which is not to say it is a bad thing. > >> > >> A large driver for MPLS-TP is to give the packet network the look, > feel, and > >> behavioral characteristics of a "legacy" transport network. > >> > >>> Based on these observations, I'd guess (FWIW) that: > >>> * associated bidirectional paths are, at least for the time > >>> being, the most important type of bidirectional paths in > >>> MPLS-TP > >> I think that is wrong both given my statement above, and given that > other > >> upgrades to existing MPLS solutions will be needed to reach the full > >> function level of MPLS-TP. > >> > >>> * they had a good chance to remain the only type of bidirectional > >>> paths in real deployments. > >> I don't see what that follows from. > >> > >> Cheers, > >> Adrian > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From Italo.Busi@alcatel-lucent.it Fri Apr 17 06:58:25 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4532C3A68BA for ; Fri, 17 Apr 2009 06:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRd1sArpHbQI for ; Fri, 17 Apr 2009 06:58:24 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id AFD143A6892 for ; Fri, 17 Apr 2009 06:58:23 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HDxXLr011742; Fri, 17 Apr 2009 15:59:34 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 15:59:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 15:59:32 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B19C4@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAATwzwA= References: <49E867E1.7050403@alcatel-lucent.com> <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> From: "BUSI ITALO" To: "Annamaria Fulignoli" , "VIGOUREUX MARTIN" , "Ben Niven-Jenkins" X-OriginalArrivalTime: 17 Apr 2009 13:59:33.0716 (UTC) FILETIME=[BC83D140:01C9BF64] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:58:25 -0000 +1=20 > -----Original Message----- > From: Annamaria Fulignoli [mailto:annamaria.fulignoli@ericsson.com]=20 > Sent: Friday, April 17, 2009 1:52 PM > To: VIGOUREUX MARTIN; Ben Niven-Jenkins > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > Associated bidirectional transport path requirements) >=20 > Hi all, > sorry but I do not understand why we cannot explicitly use=20 > the term Tandem Connection in the requirements document! > TCM is not a solution, it is part of functional architecture=20 > of a transport networks as described in G.805. The solution=20 > is to realize it with label stacking rather than MEL.=20 >=20 > Regards > Annamaria > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: venerd=EC 17 aprile 2009 13.29 > To: Ben Niven-Jenkins > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > Associated bidirectional transport path requirements) >=20 > Ben, all >=20 > in mpls-tp-oam-requirement, the text on this item is as follows: >=20 > The service emulated by a single segment or a multi-segment PW may > span multiple domains. A LSP may also span multiple domains. It > MUST be possible to perform OAM functions on a per domain=20 > basis and > across multiple domains. More generally it MUST be possible to > perform OAM functions between any two switching elements=20 > (e.g., LSR > or S-PE) of a LSP or of PW. This is referred to as (concatenated) > segment monitoring. >=20 > I believe the text describes a functional req. >=20 > During mead team review, the removal of the last sentence was=20 > discussed. > No strong opinion was expressed on whether it should=20 > effectively be removed or not. >=20 > regards, > martin >=20 > Ben Niven-Jenkins a =E9crit : > > Italo, > >=20 > > I think we are converging. If I can be so bold as to speak on his=20 > > behalf Adrian's objection seemed to be to the use of the term TCM. > >=20 > > It is defined in the MPLS-TP requirements but not used. > >=20 > > It is not used in the MPLS-TP OAM requirements document. > >=20 > > Therefore I think the way forward is as follows: > >=20 > > 1) Remove the term Tandem Connection from the MPLS-TP=20 > requirements as=20 > > it is redundant (i.e. Not used in that document). > >=20 > > 2) Ensure the MPLS-TP OAM requirements express the necessary=20 > > functional requirements around monitoring of end to end=20 > paths as well=20 > > as parts of end to end paths. This can be done without referring=20 > > explicitly to Tandem Connections. > >=20 > > When it comes to solution design we can decide what is the best=20 > > mechanism to achieve/implement those requirements be it LSP=20 > hierarchy or something else. > > The JWT has proved that it is possible to meet those requirements=20 > > using existing MPLS technology (maybe with some enhancements). I do=20 > > not believe we have to necessarily use the solution they propose=20 > > aslong as whatever solution we ultimately decide upon meets all the=20 > > necessary requirements expressed. > >=20 > > Can we agree on that as an approach and close this off for now? > >=20 > > Ben > >=20 > >=20 > > On 17/04/2009 10:49, "BUSI ITALO"=20 > wrote: > >=20 > >> Ben, > >> > >> I think we are mixing solutions with requirements. > >> > >> The requirement for the TCM function is clearly defined and I do=20 > >> think it must be addressed by the MPLS-TP design. > >> > >> The solution evaluated by the JWT to meet this requirement=20 > was to use=20 > >> label stacking with a 1:1 relationship between the TCM LSP and the=20 > >> e2e LSP. > >> > >> I think this solution, although not the best technical option, is=20 > >> good enough and meets the requirements. > >> > >> However this is is a solution and has not impact on the=20 > requirement. > >> > >> Italo > >> > >>> -----Original Message----- > >>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>> Sent: Friday, April 17, 2009 11:22 AM > >>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > >>> Cc: mpls-tp@ietf.org; Lou Berger > >>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp]=20 > >>> Associated bidirectional transport path requirements) > >>> > >>> Italo, > >>> > >>> On 17/04/2009 09:34, "BUSI ITALO" > >>> wrote: > >>>> The JWT agreement is to bring the ITU-T transport > >>> requirements in IETF > >>>> to extend the MPLS architecture to meet them in a way that is=20 > >>>> compatible, consistent and coherent with existing IETF=20 > architecture. > >>> So I took a look at the JWT report. It says (slide 16) > >>> > >>> " Service Providers want LSPs/PWEs to be able to be=20 > managed at the=20 > >>> different nested levels seamlessly (path, segment, multiple=20 > >>> segments) > >>> aka Tandem Connection Monitoring (TCM), this is used=20 > for example=20 > >>> when a LSP/PWE crosses multiple administrations" > >>> > >>> IMO the requirement is to be able to monitor parts of a=20 > path as well=20 > >>> as the end to end path. There are many ways to solve that=20 > >>> requirement, one of which is the creation of nested LSPs, one per=20 > >>> level of monitoring required (my understanding of how TCM works). > >>> > >>> I think the real discussion is therefore is the requirement to=20 > >>> monitor different components of an end to end path or is the=20 > >>> requirement that such monitoring MUST be achieved using=20 > nested LSPs? > >>> > >>> As an example PW technology today allows end to end and=20 > per segment=20 > >>> monitoring but it does not achieve it using nested PWs or=20 > PW levels. > >>> > >>> Ben > >>> > >>> > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From benjamin.niven-jenkins@bt.com Fri Apr 17 07:25:13 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FEA3A67E6 for ; Fri, 17 Apr 2009 07:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nshGSjYFGbvR for ; Fri, 17 Apr 2009 07:25:08 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 78F633A6AB8 for ; Fri, 17 Apr 2009 07:25:03 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 15:26:13 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Apr 2009 14:26:12 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 15:26:11 +0100 From: Ben Niven-Jenkins To: Annamaria Fulignoli , Martin Vigoureux Message-ID: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0= In-Reply-To: <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 17 Apr 2009 14:26:13.0276 (UTC) FILETIME=[75ED4DC0:01C9BF68] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 14:25:13 -0000 Because IMO use of the term TCM tends to make people think of a particular solution and what we want to do at this stage is express the functional requirements and not imply any particular solution. Certainly most of my mails in this thread (and I am probably not the only one) have been based on the fact that when discussing TCM I assume a particular solution is being discussed. Talking purely in terms of functional requirements removes that ambiguity. Ben On 17/04/2009 12:51, "Annamaria Fulignoli" wrote: > Hi all, > sorry but I do not understand why we cannot explicitly use the term Tande= m > Connection in the requirements document! > TCM is not a solution, it is part of functional architecture of a transpo= rt > networks as described in G.805. The solution is to realize it with label > stacking rather than MEL. >=20 > Regards > Annamaria > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > Martin Vigoureux > Sent: venerd=EC 17 aprile 2009 13.29 > To: Ben Niven-Jenkins > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated > bidirectional transport path requirements) >=20 > Ben, all >=20 > in mpls-tp-oam-requirement, the text on this item is as follows: >=20 > The service emulated by a single segment or a multi-segment PW may > span multiple domains. A LSP may also span multiple domains. It > MUST be possible to perform OAM functions on a per domain basis and > across multiple domains. More generally it MUST be possible to > perform OAM functions between any two switching elements (e.g., LSR > or S-PE) of a LSP or of PW. This is referred to as (concatenated) > segment monitoring. >=20 > I believe the text describes a functional req. >=20 > During mead team review, the removal of the last sentence was discussed. > No strong opinion was expressed on whether it should effectively be remov= ed or > not. >=20 > regards, > martin >=20 > Ben Niven-Jenkins a =E9crit : >> Italo, >>=20 >> I think we are converging. If I can be so bold as to speak on his >> behalf Adrian's objection seemed to be to the use of the term TCM. >>=20 >> It is defined in the MPLS-TP requirements but not used. >>=20 >> It is not used in the MPLS-TP OAM requirements document. >>=20 >> Therefore I think the way forward is as follows: >>=20 >> 1) Remove the term Tandem Connection from the MPLS-TP requirements as >> it is redundant (i.e. Not used in that document). >>=20 >> 2) Ensure the MPLS-TP OAM requirements express the necessary >> functional requirements around monitoring of end to end paths as well >> as parts of end to end paths. This can be done without referring >> explicitly to Tandem Connections. >>=20 >> When it comes to solution design we can decide what is the best >> mechanism to achieve/implement those requirements be it LSP hierarchy or >> something else. >> The JWT has proved that it is possible to meet those requirements >> using existing MPLS technology (maybe with some enhancements). I do >> not believe we have to necessarily use the solution they propose >> aslong as whatever solution we ultimately decide upon meets all the >> necessary requirements expressed. >>=20 >> Can we agree on that as an approach and close this off for now? >>=20 >> Ben >>=20 >>=20 >> On 17/04/2009 10:49, "BUSI ITALO" wrote: >>=20 >>> Ben, >>>=20 >>> I think we are mixing solutions with requirements. >>>=20 >>> The requirement for the TCM function is clearly defined and I do >>> think it must be addressed by the MPLS-TP design. >>>=20 >>> The solution evaluated by the JWT to meet this requirement was to use >>> label stacking with a 1:1 relationship between the TCM LSP and the >>> e2e LSP. >>>=20 >>> I think this solution, although not the best technical option, is >>> good enough and meets the requirements. >>>=20 >>> However this is is a solution and has not impact on the requirement. >>>=20 >>> Italo >>>=20 >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>>> Sent: Friday, April 17, 2009 11:22 AM >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>>> Cc: mpls-tp@ietf.org; Lou Berger >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>>> Associated bidirectional transport path requirements) >>>>=20 >>>> Italo, >>>>=20 >>>> On 17/04/2009 09:34, "BUSI ITALO" >>>> wrote: >>>>> The JWT agreement is to bring the ITU-T transport >>>> requirements in IETF >>>>> to extend the MPLS architecture to meet them in a way that is >>>>> compatible, consistent and coherent with existing IETF architecture. >>>> So I took a look at the JWT report. It says (slide 16) >>>>=20 >>>> " Service Providers want LSPs/PWEs to be able to be managed at the >>>> different nested levels seamlessly (path, segment, multiple >>>> segments) >>>> aka Tandem Connection Monitoring (TCM), this is used for example >>>> when a LSP/PWE crosses multiple administrations" >>>>=20 >>>> IMO the requirement is to be able to monitor parts of a path as well >>>> as the end to end path. There are many ways to solve that >>>> requirement, one of which is the creation of nested LSPs, one per >>>> level of monitoring required (my understanding of how TCM works). >>>>=20 >>>> I think the real discussion is therefore is the requirement to >>>> monitor different components of an end to end path or is the >>>> requirement that such monitoring MUST be achieved using nested LSPs? >>>>=20 >>>> As an example PW technology today allows end to end and per segment >>>> monitoring but it does not achieve it using nested PWs or PW levels. >>>>=20 >>>> Ben >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From dbrungard@att.com Fri Apr 17 07:58:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402DD3A6A9A for ; Fri, 17 Apr 2009 07:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+bJPEosuG+4 for ; Fri, 17 Apr 2009 07:58:07 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id BC9623A6A1C for ; Fri, 17 Apr 2009 07:58:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1239980358!30829555!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22680 invoked from network); 17 Apr 2009 14:59:19 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Apr 2009 14:59:19 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3HExIiC027229 for ; Fri, 17 Apr 2009 10:59:18 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3HExDKa027178 for ; Fri, 17 Apr 2009 10:59:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 10:59:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsA== References: <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ben Niven-Jenkins" , "Annamaria Fulignoli" , "Martin Vigoureux" Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 14:58:08 -0000 I agree with Ben. TCM, with the introduction of MEL as a solution, has = become architecturally confusing. When it was used in reference to SDH, = where trail overhead was overwritten, it created a tandem connection. = For cell/packet technologies where the OAM cells/packets are inserted, = it is not clear if this is a tandem connection or a new server layer, as = both architectural terms are used in the standards.=20 In G803, TCM is a sublayer monitoring technique for a SDH tandem = connection: "Sublayer monitoring Connections may be directly monitored at one end of a connection by = overwriting some portion of the original trail's overhead capacity at = the beginning of the connection. For SDH, overhead has been defined for = this purpose at the higher-order and lower-order path layers. When = applied to a SDH tandem connection, this monitoring method is referred = to as tandem connection monitoring." Whereas in Y.1711: "OAM techniques are applied on a per LSP basis. If a segment of a given = LSP at layer N is to be monitored for some reason (e.g., via a CV or P = flow say), one way to do this is by creating a new server layer LSP = (i.e., at layer N + 1) to cover the segment at layer N." So I think before using TCM in reference to MPLS-TP, Q12 needs to align = on the use. For now, the requirements documents should try to avoid it. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Ben Niven-Jenkins Sent: Friday, April 17, 2009 10:26 AM To: Annamaria Fulignoli; Martin Vigoureux Cc: BUSI ITALO; mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated = bidirectional transport path requirements) Because IMO use of the term TCM tends to make people think of a = particular solution and what we want to do at this stage is express the functional requirements and not imply any particular solution. Certainly most of my mails in this thread (and I am probably not the = only one) have been based on the fact that when discussing TCM I assume a particular solution is being discussed. Talking purely in terms of functional requirements removes that ambiguity. Ben On 17/04/2009 12:51, "Annamaria Fulignoli" wrote: > Hi all, > sorry but I do not understand why we cannot explicitly use the term = Tandem > Connection in the requirements document! > TCM is not a solution, it is part of functional architecture of a = transport > networks as described in G.805. The solution is to realize it with = label > stacking rather than MEL. >=20 > Regards > Annamaria > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of > Martin Vigoureux > Sent: venerd=EC 17 aprile 2009 13.29 > To: Ben Niven-Jenkins > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: = Associated > bidirectional transport path requirements) >=20 > Ben, all >=20 > in mpls-tp-oam-requirement, the text on this item is as follows: >=20 > The service emulated by a single segment or a multi-segment PW may > span multiple domains. A LSP may also span multiple domains. It > MUST be possible to perform OAM functions on a per domain basis = and > across multiple domains. More generally it MUST be possible to > perform OAM functions between any two switching elements (e.g., = LSR > or S-PE) of a LSP or of PW. This is referred to as (concatenated) > segment monitoring. >=20 > I believe the text describes a functional req. >=20 > During mead team review, the removal of the last sentence was = discussed. > No strong opinion was expressed on whether it should effectively be = removed or > not. >=20 > regards, > martin >=20 > Ben Niven-Jenkins a =E9crit : >> Italo, >>=20 >> I think we are converging. If I can be so bold as to speak on his >> behalf Adrian's objection seemed to be to the use of the term TCM. >>=20 >> It is defined in the MPLS-TP requirements but not used. >>=20 >> It is not used in the MPLS-TP OAM requirements document. >>=20 >> Therefore I think the way forward is as follows: >>=20 >> 1) Remove the term Tandem Connection from the MPLS-TP requirements as >> it is redundant (i.e. Not used in that document). >>=20 >> 2) Ensure the MPLS-TP OAM requirements express the necessary >> functional requirements around monitoring of end to end paths as well >> as parts of end to end paths. This can be done without referring >> explicitly to Tandem Connections. >>=20 >> When it comes to solution design we can decide what is the best >> mechanism to achieve/implement those requirements be it LSP hierarchy = or >> something else. >> The JWT has proved that it is possible to meet those requirements >> using existing MPLS technology (maybe with some enhancements). I do >> not believe we have to necessarily use the solution they propose >> aslong as whatever solution we ultimately decide upon meets all the >> necessary requirements expressed. >>=20 >> Can we agree on that as an approach and close this off for now? >>=20 >> Ben >>=20 >>=20 >> On 17/04/2009 10:49, "BUSI ITALO" = wrote: >>=20 >>> Ben, >>>=20 >>> I think we are mixing solutions with requirements. >>>=20 >>> The requirement for the TCM function is clearly defined and I do >>> think it must be addressed by the MPLS-TP design. >>>=20 >>> The solution evaluated by the JWT to meet this requirement was to = use >>> label stacking with a 1:1 relationship between the TCM LSP and the >>> e2e LSP. >>>=20 >>> I think this solution, although not the best technical option, is >>> good enough and meets the requirements. >>>=20 >>> However this is is a solution and has not impact on the requirement. >>>=20 >>> Italo >>>=20 >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>>> Sent: Friday, April 17, 2009 11:22 AM >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>>> Cc: mpls-tp@ietf.org; Lou Berger >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>>> Associated bidirectional transport path requirements) >>>>=20 >>>> Italo, >>>>=20 >>>> On 17/04/2009 09:34, "BUSI ITALO" >>>> wrote: >>>>> The JWT agreement is to bring the ITU-T transport >>>> requirements in IETF >>>>> to extend the MPLS architecture to meet them in a way that is >>>>> compatible, consistent and coherent with existing IETF = architecture. >>>> So I took a look at the JWT report. It says (slide 16) >>>>=20 >>>> " Service Providers want LSPs/PWEs to be able to be managed at the >>>> different nested levels seamlessly (path, segment, multiple >>>> segments) >>>> aka Tandem Connection Monitoring (TCM), this is used for = example >>>> when a LSP/PWE crosses multiple administrations" >>>>=20 >>>> IMO the requirement is to be able to monitor parts of a path as = well >>>> as the end to end path. There are many ways to solve that >>>> requirement, one of which is the creation of nested LSPs, one per >>>> level of monitoring required (my understanding of how TCM works). >>>>=20 >>>> I think the real discussion is therefore is the requirement to >>>> monitor different components of an end to end path or is the >>>> requirement that such monitoring MUST be achieved using nested = LSPs? >>>>=20 >>>> As an example PW technology today allows end to end and per segment >>>> monitoring but it does not achieve it using nested PWs or PW = levels. >>>>=20 >>>> Ben >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From neil.2.harrison@bt.com Fri Apr 17 08:20:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD8A3A6EAA for ; Fri, 17 Apr 2009 08:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEa1-qKiQ3Bd for ; Fri, 17 Apr 2009 08:20:11 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id ED2953A6E1C for ; Fri, 17 Apr 2009 08:20:10 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 16:21:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 16:21:38 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FFE01@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) thread-index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsAABEeww From: To: , , , X-OriginalArrivalTime: 17 Apr 2009 15:21:23.0427 (UTC) FILETIME=[2AEE4330:01C9BF70] Cc: Italo.Busi@alcatel-lucent.it, mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 15:20:12 -0000 I agree with both Ben and Deborah. One further point to add here..... G.805 is a fairly old Recommendation written largely to give us a = working func arch language for the development of management information = models when we were developing SONET/SDH. However, our understanding of = the physics of networking has improved significantly and G.800 (Unified = functional architecture of transport networks) is a more comprehensive = embodiment of that understanding that covers all 3 network modes (based = on sound Info and Systems theory underpinnings). So G.800 should be the = starting point for any references to the network func architecture for = MPLS-TP and not G.805 IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD,=20 > DEBORAH A, ATTLABS > Sent: 17 April 2009 15:59 > To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli; Martin Vigoureux > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > Associatedbidirectional transport path requirements) >=20 > I agree with Ben. TCM, with the introduction of MEL as a=20 > solution, has become architecturally confusing. When it was=20 > used in reference to SDH, where trail overhead was=20 > overwritten, it created a tandem connection. For cell/packet=20 > technologies where the OAM cells/packets are inserted, it is=20 > not clear if this is a tandem connection or a new server=20 > layer, as both architectural terms are used in the standards.=20 >=20 > In G803, TCM is a sublayer monitoring technique for a SDH=20 > tandem connection: > "Sublayer monitoring > Connections may be directly monitored at one end of a=20 > connection by overwriting some portion of the original=20 > trail's overhead capacity at the beginning of the connection.=20 > For SDH, overhead has been defined for this purpose at the=20 > higher-order and lower-order path layers. When applied to a=20 > SDH tandem connection, this monitoring method is referred to=20 > as tandem connection monitoring." >=20 > Whereas in Y.1711: > "OAM techniques are applied on a per LSP basis. If a segment=20 > of a given LSP at layer N is to be monitored for some reason=20 > (e.g., via a CV or P flow say), one way to do this is by=20 > creating a new server layer LSP (i.e., at layer N + 1) to=20 > cover the segment at layer N." >=20 > So I think before using TCM in reference to MPLS-TP, Q12=20 > needs to align on the use. For now, the requirements=20 > documents should try to avoid it. >=20 > Deborah >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: Friday, April 17, 2009 10:26 AM > To: Annamaria Fulignoli; Martin Vigoureux > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > Associated bidirectional transport path requirements) >=20 > Because IMO use of the term TCM tends to make people think of=20 > a particular > solution and what we want to do at this stage is express the=20 > functional > requirements and not imply any particular solution. >=20 > Certainly most of my mails in this thread (and I am probably=20 > not the only > one) have been based on the fact that when discussing TCM I assume a > particular solution is being discussed. Talking purely in terms of > functional requirements removes that ambiguity. >=20 > Ben >=20 >=20 > On 17/04/2009 12:51, "Annamaria Fulignoli" > wrote: >=20 > > Hi all, > > sorry but I do not understand why we cannot explicitly use=20 > the term Tandem > > Connection in the requirements document! > > TCM is not a solution, it is part of functional=20 > architecture of a transport > > networks as described in G.805. The solution is to realize=20 > it with label > > stacking rather than MEL. > >=20 > > Regards > > Annamaria > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > Martin Vigoureux > > Sent: venerd=EC 17 aprile 2009 13.29 > > To: Ben Niven-Jenkins > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE: Associated > > bidirectional transport path requirements) > >=20 > > Ben, all > >=20 > > in mpls-tp-oam-requirement, the text on this item is as follows: > >=20 > > The service emulated by a single segment or a=20 > multi-segment PW may > > span multiple domains. A LSP may also span multiple=20 > domains. It > > MUST be possible to perform OAM functions on a per=20 > domain basis and > > across multiple domains. More generally it MUST be possible to > > perform OAM functions between any two switching=20 > elements (e.g., LSR > > or S-PE) of a LSP or of PW. This is referred to as=20 > (concatenated) > > segment monitoring. > >=20 > > I believe the text describes a functional req. > >=20 > > During mead team review, the removal of the last sentence=20 > was discussed. > > No strong opinion was expressed on whether it should=20 > effectively be removed or > > not. > >=20 > > regards, > > martin > >=20 > > Ben Niven-Jenkins a =E9crit : > >> Italo, > >>=20 > >> I think we are converging. If I can be so bold as to speak on his > >> behalf Adrian's objection seemed to be to the use of the term TCM. > >>=20 > >> It is defined in the MPLS-TP requirements but not used. > >>=20 > >> It is not used in the MPLS-TP OAM requirements document. > >>=20 > >> Therefore I think the way forward is as follows: > >>=20 > >> 1) Remove the term Tandem Connection from the MPLS-TP=20 > requirements as > >> it is redundant (i.e. Not used in that document). > >>=20 > >> 2) Ensure the MPLS-TP OAM requirements express the necessary > >> functional requirements around monitoring of end to end=20 > paths as well > >> as parts of end to end paths. This can be done without referring > >> explicitly to Tandem Connections. > >>=20 > >> When it comes to solution design we can decide what is the best > >> mechanism to achieve/implement those requirements be it=20 > LSP hierarchy or > >> something else. > >> The JWT has proved that it is possible to meet those requirements > >> using existing MPLS technology (maybe with some enhancements). I do > >> not believe we have to necessarily use the solution they propose > >> aslong as whatever solution we ultimately decide upon meets all the > >> necessary requirements expressed. > >>=20 > >> Can we agree on that as an approach and close this off for now? > >>=20 > >> Ben > >>=20 > >>=20 > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > wrote: > >>=20 > >>> Ben, > >>>=20 > >>> I think we are mixing solutions with requirements. > >>>=20 > >>> The requirement for the TCM function is clearly defined and I do > >>> think it must be addressed by the MPLS-TP design. > >>>=20 > >>> The solution evaluated by the JWT to meet this=20 > requirement was to use > >>> label stacking with a 1:1 relationship between the TCM LSP and the > >>> e2e LSP. > >>>=20 > >>> I think this solution, although not the best technical option, is > >>> good enough and meets the requirements. > >>>=20 > >>> However this is is a solution and has not impact on the=20 > requirement. > >>>=20 > >>> Italo > >>>=20 > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>>> Sent: Friday, April 17, 2009 11:22 AM > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > >>>> Cc: mpls-tp@ietf.org; Lou Berger > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] > >>>> Associated bidirectional transport path requirements) > >>>>=20 > >>>> Italo, > >>>>=20 > >>>> On 17/04/2009 09:34, "BUSI ITALO" > >>>> wrote: > >>>>> The JWT agreement is to bring the ITU-T transport > >>>> requirements in IETF > >>>>> to extend the MPLS architecture to meet them in a way that is > >>>>> compatible, consistent and coherent with existing IETF=20 > architecture. > >>>> So I took a look at the JWT report. It says (slide 16) > >>>>=20 > >>>> " Service Providers want LSPs/PWEs to be able to be=20 > managed at the > >>>> different nested levels seamlessly (path, segment, multiple > >>>> segments) > >>>> aka Tandem Connection Monitoring (TCM), this is used=20 > for example > >>>> when a LSP/PWE crosses multiple administrations" > >>>>=20 > >>>> IMO the requirement is to be able to monitor parts of a=20 > path as well > >>>> as the end to end path. There are many ways to solve that > >>>> requirement, one of which is the creation of nested LSPs, one per > >>>> level of monitoring required (my understanding of how TCM works). > >>>>=20 > >>>> I think the real discussion is therefore is the requirement to > >>>> monitor different components of an end to end path or is the > >>>> requirement that such monitoring MUST be achieved using=20 > nested LSPs? > >>>>=20 > >>>> As an example PW technology today allows end to end and=20 > per segment > >>>> monitoring but it does not achieve it using nested PWs=20 > or PW levels. > >>>>=20 > >>>> Ben > >>>>=20 > >>>>=20 > >>=20 > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > >>=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From eric.gray@ericsson.com Fri Apr 17 11:15:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A059C3A6FD0 for ; Fri, 17 Apr 2009 11:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.312 X-Spam-Level: X-Spam-Status: No, score=-5.312 tagged_above=-999 required=5 tests=[AWL=1.287, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf1oEtGrVLbn for ; Fri, 17 Apr 2009 11:15:09 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id BB10428C197 for ; Fri, 17 Apr 2009 11:15:09 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n3HIGHfH016629; Fri, 17 Apr 2009 13:16:19 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 13:15:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 13:15:23 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <49E5EEC8.6080101@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm91k8eN17VNhFVQzmDnE7yj0tc5wBsbrrQ References: <001901c9bc0a$dc6fd060$6802a8c0@china.huawei.com><6FD21B53861BF44AA90A288402036AB402145621@FRVELSMBS21.ad2.ad.alcatel.com> <49E5EEC8.6080101@labn.net> From: "Eric Gray" To: "Lou Berger" , "BUSI ITALO" X-OriginalArrivalTime: 17 Apr 2009 18:15:24.0453 (UTC) FILETIME=[7A446550:01C9BF88] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:15:12 -0000 Lou/Italo, This gets into a fuzzy language area. I think it should be clear that use of associated (non-co-routed) bi-directional paths is not required. It also seems to me to be clear=20 that they might be used; hence support for them is needed in protocols and other specifications. We all need to be precise in what we mean by what is required, and where it is required. -- Eric -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, April 15, 2009 10:27 AM To: BUSI ITALO Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Italo, On 4/14/2009 6:12 AM, BUSI ITALO wrote: > 2) we need to be clear that asssociated bidirectional paths are not > required in transport networks (e.g. MPLS-TP) > This doesn't match draft-ietf-mpls-tp-requirements-06. Are you=20 proposing dropping associated bidirectional path from the TP=20 requirements document? Lou _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From Italo.Busi@alcatel-lucent.it Fri Apr 17 11:19:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C56428C1A1 for ; Fri, 17 Apr 2009 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yahE9xzBKNA for ; Fri, 17 Apr 2009 11:19:40 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id DFB4E28C19C for ; Fri, 17 Apr 2009 11:19:39 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HIKptg022978; Fri, 17 Apr 2009 20:20:51 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 20:20:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 20:20:45 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0ACB4nIA== References: <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> From: "BUSI ITALO" To: "Ben Niven-Jenkins" , "Annamaria Fulignoli" , "VIGOUREUX MARTIN" X-OriginalArrivalTime: 17 Apr 2009 18:20:50.0836 (UTC) FILETIME=[3CCE7D40:01C9BF89] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:19:41 -0000 Ben, TCM is an architectural construct well defined in G.805 in a = technology-independent manner. As such TCM does not imply any specific = solution. The solution we are working on to implement TCM within MPLS-TP is based = on the JWT agreement and described in the OAM Framework document. I do not think we should drop a requirement because of people's = misunderstandings. Italo > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Friday, April 17, 2009 4:26 PM > To: Annamaria Fulignoli; VIGOUREUX MARTIN > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > Associated bidirectional transport path requirements) >=20 > Because IMO use of the term TCM tends to make people think of=20 > a particular > solution and what we want to do at this stage is express the=20 > functional > requirements and not imply any particular solution. >=20 > Certainly most of my mails in this thread (and I am probably=20 > not the only > one) have been based on the fact that when discussing TCM I assume a > particular solution is being discussed. Talking purely in terms of > functional requirements removes that ambiguity. >=20 > Ben >=20 >=20 > On 17/04/2009 12:51, "Annamaria Fulignoli" > wrote: >=20 > > Hi all, > > sorry but I do not understand why we cannot explicitly use=20 > the term Tandem > > Connection in the requirements document! > > TCM is not a solution, it is part of functional=20 > architecture of a transport > > networks as described in G.805. The solution is to realize=20 > it with label > > stacking rather than MEL. > >=20 > > Regards > > Annamaria > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > Martin Vigoureux > > Sent: venerd=EC 17 aprile 2009 13.29 > > To: Ben Niven-Jenkins > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE: Associated > > bidirectional transport path requirements) > >=20 > > Ben, all > >=20 > > in mpls-tp-oam-requirement, the text on this item is as follows: > >=20 > > The service emulated by a single segment or a=20 > multi-segment PW may > > span multiple domains. A LSP may also span multiple=20 > domains. It > > MUST be possible to perform OAM functions on a per=20 > domain basis and > > across multiple domains. More generally it MUST be possible to > > perform OAM functions between any two switching=20 > elements (e.g., LSR > > or S-PE) of a LSP or of PW. This is referred to as=20 > (concatenated) > > segment monitoring. > >=20 > > I believe the text describes a functional req. > >=20 > > During mead team review, the removal of the last sentence=20 > was discussed. > > No strong opinion was expressed on whether it should=20 > effectively be removed or > > not. > >=20 > > regards, > > martin > >=20 > > Ben Niven-Jenkins a =E9crit : > >> Italo, > >>=20 > >> I think we are converging. If I can be so bold as to speak on his > >> behalf Adrian's objection seemed to be to the use of the term TCM. > >>=20 > >> It is defined in the MPLS-TP requirements but not used. > >>=20 > >> It is not used in the MPLS-TP OAM requirements document. > >>=20 > >> Therefore I think the way forward is as follows: > >>=20 > >> 1) Remove the term Tandem Connection from the MPLS-TP=20 > requirements as > >> it is redundant (i.e. Not used in that document). > >>=20 > >> 2) Ensure the MPLS-TP OAM requirements express the necessary > >> functional requirements around monitoring of end to end=20 > paths as well > >> as parts of end to end paths. This can be done without referring > >> explicitly to Tandem Connections. > >>=20 > >> When it comes to solution design we can decide what is the best > >> mechanism to achieve/implement those requirements be it=20 > LSP hierarchy or > >> something else. > >> The JWT has proved that it is possible to meet those requirements > >> using existing MPLS technology (maybe with some enhancements). I do > >> not believe we have to necessarily use the solution they propose > >> aslong as whatever solution we ultimately decide upon meets all the > >> necessary requirements expressed. > >>=20 > >> Can we agree on that as an approach and close this off for now? > >>=20 > >> Ben > >>=20 > >>=20 > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > wrote: > >>=20 > >>> Ben, > >>>=20 > >>> I think we are mixing solutions with requirements. > >>>=20 > >>> The requirement for the TCM function is clearly defined and I do > >>> think it must be addressed by the MPLS-TP design. > >>>=20 > >>> The solution evaluated by the JWT to meet this=20 > requirement was to use > >>> label stacking with a 1:1 relationship between the TCM LSP and the > >>> e2e LSP. > >>>=20 > >>> I think this solution, although not the best technical option, is > >>> good enough and meets the requirements. > >>>=20 > >>> However this is is a solution and has not impact on the=20 > requirement. > >>>=20 > >>> Italo > >>>=20 > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>>> Sent: Friday, April 17, 2009 11:22 AM > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > >>>> Cc: mpls-tp@ietf.org; Lou Berger > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] > >>>> Associated bidirectional transport path requirements) > >>>>=20 > >>>> Italo, > >>>>=20 > >>>> On 17/04/2009 09:34, "BUSI ITALO" > >>>> wrote: > >>>>> The JWT agreement is to bring the ITU-T transport > >>>> requirements in IETF > >>>>> to extend the MPLS architecture to meet them in a way that is > >>>>> compatible, consistent and coherent with existing IETF=20 > architecture. > >>>> So I took a look at the JWT report. It says (slide 16) > >>>>=20 > >>>> " Service Providers want LSPs/PWEs to be able to be=20 > managed at the > >>>> different nested levels seamlessly (path, segment, multiple > >>>> segments) > >>>> aka Tandem Connection Monitoring (TCM), this is used=20 > for example > >>>> when a LSP/PWE crosses multiple administrations" > >>>>=20 > >>>> IMO the requirement is to be able to monitor parts of a=20 > path as well > >>>> as the end to end path. There are many ways to solve that > >>>> requirement, one of which is the creation of nested LSPs, one per > >>>> level of monitoring required (my understanding of how TCM works). > >>>>=20 > >>>> I think the real discussion is therefore is the requirement to > >>>> monitor different components of an end to end path or is the > >>>> requirement that such monitoring MUST be achieved using=20 > nested LSPs? > >>>>=20 > >>>> As an example PW technology today allows end to end and=20 > per segment > >>>> monitoring but it does not achieve it using nested PWs=20 > or PW levels. > >>>>=20 > >>>> Ben > >>>>=20 > >>>>=20 > >>=20 > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > >>=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 11:28:16 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1F528C17E for ; Fri, 17 Apr 2009 11:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EQUOM3h3g7s for ; Fri, 17 Apr 2009 11:28:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 0F75B3A6844 for ; Fri, 17 Apr 2009 11:28:13 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HITM4P026326; Fri, 17 Apr 2009 20:29:23 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 20:29:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 20:29:18 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C046FFE01@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsAABEewwAAbNqSA= References: <2ECAA42C79676B42AEBAC11229CA7D0C046FFE01@E03MVB2-UKBR.domain1.systemhost.net> From: "BUSI ITALO" To: , , , , "VIGOUREUX MARTIN" X-OriginalArrivalTime: 17 Apr 2009 18:29:22.0505 (UTC) FILETIME=[6DC8FB90:01C9BF8A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:28:16 -0000 Neil, G.805 is an in-force Recommendation: G.800 was never intended to replace = G.805. People who worked on G.800 has always claimed that for = connection-oriented technologies G.800 defaults to G.805. When Q12/15 consented G.800, it was agreed that existing Recommendations = based on G.805 (e.g. G.8110.1) will continue to be based on G.805. Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com > Sent: Friday, April 17, 2009 5:22 PM > To: dbrungard@att.com; benjamin.niven-jenkins@bt.com;=20 > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE:Associatedbidirectional transport path requirements) >=20 > I agree with both Ben and Deborah. One further point to add here..... >=20 > G.805 is a fairly old Recommendation written largely to give=20 > us a working func arch language for the development of=20 > management information models when we were developing=20 > SONET/SDH. However, our understanding of the physics of=20 > networking has improved significantly and G.800 (Unified=20 > functional architecture of transport networks) is a more=20 > comprehensive embodiment of that understanding that covers=20 > all 3 network modes (based on sound Info and Systems theory=20 > underpinnings). So G.800 should be the starting point for=20 > any references to the network func architecture for MPLS-TP=20 > and not G.805 IMO. >=20 > regards, Neil >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD,=20 > > DEBORAH A, ATTLABS > > Sent: 17 April 2009 15:59 > > To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli; Martin Vigoureux > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > Associatedbidirectional transport path requirements) > >=20 > > I agree with Ben. TCM, with the introduction of MEL as a=20 > > solution, has become architecturally confusing. When it was=20 > > used in reference to SDH, where trail overhead was=20 > > overwritten, it created a tandem connection. For cell/packet=20 > > technologies where the OAM cells/packets are inserted, it is=20 > > not clear if this is a tandem connection or a new server=20 > > layer, as both architectural terms are used in the standards.=20 > >=20 > > In G803, TCM is a sublayer monitoring technique for a SDH=20 > > tandem connection: > > "Sublayer monitoring > > Connections may be directly monitored at one end of a=20 > > connection by overwriting some portion of the original=20 > > trail's overhead capacity at the beginning of the connection.=20 > > For SDH, overhead has been defined for this purpose at the=20 > > higher-order and lower-order path layers. When applied to a=20 > > SDH tandem connection, this monitoring method is referred to=20 > > as tandem connection monitoring." > >=20 > > Whereas in Y.1711: > > "OAM techniques are applied on a per LSP basis. If a segment=20 > > of a given LSP at layer N is to be monitored for some reason=20 > > (e.g., via a CV or P flow say), one way to do this is by=20 > > creating a new server layer LSP (i.e., at layer N + 1) to=20 > > cover the segment at layer N." > >=20 > > So I think before using TCM in reference to MPLS-TP, Q12=20 > > needs to align on the use. For now, the requirements=20 > > documents should try to avoid it. > >=20 > > Deborah > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > Sent: Friday, April 17, 2009 10:26 AM > > To: Annamaria Fulignoli; Martin Vigoureux > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > Associated bidirectional transport path requirements) > >=20 > > Because IMO use of the term TCM tends to make people think of=20 > > a particular > > solution and what we want to do at this stage is express the=20 > > functional > > requirements and not imply any particular solution. > >=20 > > Certainly most of my mails in this thread (and I am probably=20 > > not the only > > one) have been based on the fact that when discussing TCM I assume a > > particular solution is being discussed. Talking purely in terms of > > functional requirements removes that ambiguity. > >=20 > > Ben > >=20 > >=20 > > On 17/04/2009 12:51, "Annamaria Fulignoli" > > wrote: > >=20 > > > Hi all, > > > sorry but I do not understand why we cannot explicitly use=20 > > the term Tandem > > > Connection in the requirements document! > > > TCM is not a solution, it is part of functional=20 > > architecture of a transport > > > networks as described in G.805. The solution is to realize=20 > > it with label > > > stacking rather than MEL. > > >=20 > > > Regards > > > Annamaria > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > > Martin Vigoureux > > > Sent: venerd=EC 17 aprile 2009 13.29 > > > To: Ben Niven-Jenkins > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > > RE: Associated > > > bidirectional transport path requirements) > > >=20 > > > Ben, all > > >=20 > > > in mpls-tp-oam-requirement, the text on this item is as follows: > > >=20 > > > The service emulated by a single segment or a=20 > > multi-segment PW may > > > span multiple domains. A LSP may also span multiple=20 > > domains. It > > > MUST be possible to perform OAM functions on a per=20 > > domain basis and > > > across multiple domains. More generally it MUST be=20 > possible to > > > perform OAM functions between any two switching=20 > > elements (e.g., LSR > > > or S-PE) of a LSP or of PW. This is referred to as=20 > > (concatenated) > > > segment monitoring. > > >=20 > > > I believe the text describes a functional req. > > >=20 > > > During mead team review, the removal of the last sentence=20 > > was discussed. > > > No strong opinion was expressed on whether it should=20 > > effectively be removed or > > > not. > > >=20 > > > regards, > > > martin > > >=20 > > > Ben Niven-Jenkins a =E9crit : > > >> Italo, > > >>=20 > > >> I think we are converging. If I can be so bold as to speak on his > > >> behalf Adrian's objection seemed to be to the use of the=20 > term TCM. > > >>=20 > > >> It is defined in the MPLS-TP requirements but not used. > > >>=20 > > >> It is not used in the MPLS-TP OAM requirements document. > > >>=20 > > >> Therefore I think the way forward is as follows: > > >>=20 > > >> 1) Remove the term Tandem Connection from the MPLS-TP=20 > > requirements as > > >> it is redundant (i.e. Not used in that document). > > >>=20 > > >> 2) Ensure the MPLS-TP OAM requirements express the necessary > > >> functional requirements around monitoring of end to end=20 > > paths as well > > >> as parts of end to end paths. This can be done without referring > > >> explicitly to Tandem Connections. > > >>=20 > > >> When it comes to solution design we can decide what is the best > > >> mechanism to achieve/implement those requirements be it=20 > > LSP hierarchy or > > >> something else. > > >> The JWT has proved that it is possible to meet those requirements > > >> using existing MPLS technology (maybe with some=20 > enhancements). I do > > >> not believe we have to necessarily use the solution they propose > > >> aslong as whatever solution we ultimately decide upon=20 > meets all the > > >> necessary requirements expressed. > > >>=20 > > >> Can we agree on that as an approach and close this off for now? > > >>=20 > > >> Ben > > >>=20 > > >>=20 > > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > > wrote: > > >>=20 > > >>> Ben, > > >>>=20 > > >>> I think we are mixing solutions with requirements. > > >>>=20 > > >>> The requirement for the TCM function is clearly defined and I do > > >>> think it must be addressed by the MPLS-TP design. > > >>>=20 > > >>> The solution evaluated by the JWT to meet this=20 > > requirement was to use > > >>> label stacking with a 1:1 relationship between the TCM=20 > LSP and the > > >>> e2e LSP. > > >>>=20 > > >>> I think this solution, although not the best technical=20 > option, is > > >>> good enough and meets the requirements. > > >>>=20 > > >>> However this is is a solution and has not impact on the=20 > > requirement. > > >>>=20 > > >>> Italo > > >>>=20 > > >>>> -----Original Message----- > > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > >>>> Sent: Friday, April 17, 2009 11:22 AM > > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > > >>>> Cc: mpls-tp@ietf.org; Lou Berger > > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] > > >>>> Associated bidirectional transport path requirements) > > >>>>=20 > > >>>> Italo, > > >>>>=20 > > >>>> On 17/04/2009 09:34, "BUSI ITALO" > > >>>> wrote: > > >>>>> The JWT agreement is to bring the ITU-T transport > > >>>> requirements in IETF > > >>>>> to extend the MPLS architecture to meet them in a way that is > > >>>>> compatible, consistent and coherent with existing IETF=20 > > architecture. > > >>>> So I took a look at the JWT report. It says (slide 16) > > >>>>=20 > > >>>> " Service Providers want LSPs/PWEs to be able to be=20 > > managed at the > > >>>> different nested levels seamlessly (path, segment, multiple > > >>>> segments) > > >>>> aka Tandem Connection Monitoring (TCM), this is used=20 > > for example > > >>>> when a LSP/PWE crosses multiple administrations" > > >>>>=20 > > >>>> IMO the requirement is to be able to monitor parts of a=20 > > path as well > > >>>> as the end to end path. There are many ways to solve that > > >>>> requirement, one of which is the creation of nested=20 > LSPs, one per > > >>>> level of monitoring required (my understanding of how=20 > TCM works). > > >>>>=20 > > >>>> I think the real discussion is therefore is the requirement to > > >>>> monitor different components of an end to end path or is the > > >>>> requirement that such monitoring MUST be achieved using=20 > > nested LSPs? > > >>>>=20 > > >>>> As an example PW technology today allows end to end and=20 > > per segment > > >>>> monitoring but it does not achieve it using nested PWs=20 > > or PW levels. > > >>>>=20 > > >>>> Ben > > >>>>=20 > > >>>>=20 > > >>=20 > > >> _______________________________________________ > > >> mpls-tp mailing list > > >> mpls-tp@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > >>=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 11:39:43 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F6628C19A for ; Fri, 17 Apr 2009 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=-1.606, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykWLUgrco1WB for ; Fri, 17 Apr 2009 11:39:42 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 9864628C19D for ; Fri, 17 Apr 2009 11:39:42 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HIerRZ031562; Fri, 17 Apr 2009 20:40:53 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 20:40:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 20:40:51 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1A73@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm91k8eN17VNhFVQzmDnE7yj0tc5wBsbrrQAADkdbA= References: <001901c9bc0a$dc6fd060$6802a8c0@china.huawei.com><6FD21B53861BF44AA90A288402036AB402145621@FRVELSMBS21.ad2.ad.alcatel.com> <49E5EEC8.6080101@labn.net> <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> From: "BUSI ITALO" To: "Eric Gray" , "Lou Berger" X-OriginalArrivalTime: 17 Apr 2009 18:40:53.0469 (UTC) FILETIME=[09A1B8D0:01C9BF8C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:39:43 -0000 Eric, You got exactly the spirit of my comment. Italo > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com]=20 > Sent: Friday, April 17, 2009 8:15 PM > To: Lou Berger; BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Lou/Italo, >=20 > This gets into a fuzzy language area. >=20 > I think it should be clear that use of associated > (non-co-routed) > bi-directional paths is not required. It also seems to me to=20 > be clear=20 > that they might be used; hence support for them is needed in protocols > and other specifications. >=20 > We all need to be precise in what we mean by what is required, > and where it is required. >=20 > -- > Eric >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Lou Berger > Sent: Wednesday, April 15, 2009 10:27 AM > To: BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements >=20 > Italo, >=20 > On 4/14/2009 6:12 AM, BUSI ITALO wrote: > > 2) we need to be clear that asssociated bidirectional paths are not > > required in transport networks (e.g. MPLS-TP) > > >=20 > This doesn't match draft-ietf-mpls-tp-requirements-06. Are you=20 > proposing dropping associated bidirectional path from the TP=20 > requirements document? >=20 > Lou >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From John.E.Drake2@boeing.com Fri Apr 17 12:04:50 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06C43A6E1F for ; Fri, 17 Apr 2009 12:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC40hl-CI8rs for ; Fri, 17 Apr 2009 12:04:49 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 0F6C83A6E33 for ; Fri, 17 Apr 2009 12:04:49 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3HJ2DV0016277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Apr 2009 14:02:13 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3HJ2DfM024733; Fri, 17 Apr 2009 14:02:13 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3HJ2CcL024717; Fri, 17 Apr 2009 14:02:12 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 12:02:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 12:02:10 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BE71@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1867@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWgABQg5yA= References: <5403F90D2C87494EA46E4EB3370FC1C1@your029b8cecfe>, <007601c9be8e$497c82e0$6570ca0a@china.huawei.com> <51661468CBD1354294533DA79E85955A01A6BB1D@XCH-SW-5V2.sw.nos.boeing.com> <6FD21B53861BF44AA90A288402036AB4021B1867@FRVELSMBS21.ad2.ad.alcatel.com> From: "Drake, John E" To: "BUSI ITALO" , "Alexander Vainshtein" , "Maarten Vissers" X-OriginalArrivalTime: 17 Apr 2009 19:02:11.0959 (UTC) FILETIME=[03ABD070:01C9BF8F] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 19:04:50 -0000 Italo, As described in the MPLS TP OAM Requirements I-D, virtually all of the OAM functions require a return path, and in the absence of a return path they are disabled. As described in David Sinicrope's meeting minutes (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/meeting-no tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an MPLS TP network needs to be capable of getting IP packets from destination to source; neither the minutes nor I stipulate that a control plane needs to be used to instantiate this forwarding. As an aside, the issue of return path for unidirectional LSPs could be charaterized as the elephant in the room. In the MPLS TP OAM Framework I-D, unicast LSPs are only mentioned three times and return paths not at all. =20 Thanks, John > -----Original Message----- > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > Sent: Friday, April 17, 2009 1:59 AM > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > John, >=20 > I might have missed the agreement of MPLS-TP being capable of=20 > sending replies to OAM requests sent on uni-directional LSPs. >=20 > This requirement does not belong to the first set of=20 > requirements ITU-T is expecting to be met by October. >=20 > However, I think this in a potential interesting additional=20 > requirement to be taken into account (at worst in a subsequent phase). >=20 > I think that this requirement needs to be evaluated versus=20 > other more important requirements (e.g. the possibility to=20 > work w/o IP forwarding and the need for OAM to continue to=20 > monitor the data plane also in case of failures affecting the=20 > control or management plane). >=20 > I am open to discuss it but not sure this is the right time=20 > because I wish to avoid delaying the first phase of the=20 > design solution. >=20 > Thanks, Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > Sent: Thursday, April 16, 2009 8:00 PM > > To: Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > At the meeting last fall at Juniper in Massachusetts, I=20 > think it was=20 > > agreed that an MPLS TP network needs to have a forwarding=20 > capability=20 > > for management, control, and OAM packets (e.g., sending=20 > replies to OAM=20 > > requests sent on uni-directional LSPs) even if it does not=20 > have an IP=20 > > forwarding data plane. > >=20 > > > -----Original Message----- > > > From: Alexander Vainshtein > > [mailto:Alexander.Vainshtein@ecitele.com] > > > Sent: Thursday, April 16, 2009 9:57 AM > > > To: Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > Maarten, > > > It seems that you've just (implicitly and, probably, > > > inadvertently) stated the following: > > >=20 > > > MPLS-TP OAM will not ever support MIP loopback function=20 > (and fault=20 > > > localization which requires this function ) for=20 > unidirectional P2MP=20 > > > and P2P paths. > > >=20 > > > If this statement is correct, this (IMHO and FWIW) raises a valid=20 > > > question: > > >=20 > > > Is MPLS-TP an appropriate solution for these types of transport=20 > > > paths? > > >=20 > > > For the reference, IP/MPLS provides this kind of=20 > functionality today=20 > > > for (unidirectional - but it does not know any other=20 > type) P2P LSPs =20 > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > easy... > > >=20 > > > =20 > > >=20 > > > Regards, > > >=20 > > > Sasha > > >=20 > > >=20 > > >=20 > > > ________________________________________ > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org]=20 > On Behalf=20 > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > Sent: Thursday, April 16, 2009 3:24 PM > > > To: 'Adrian Farrel' > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > Adrian, > > >=20 > > > >> > > > >> The intermediate nodes (including MEPs, MIPs and > > > other internal > > > >> functions as appropriate) of a co-routed > > > bidirectional transport > > > >> path at each (sub-)layer MUST be aware of the pairing > > > >> relationship of the forward and the backward > > > directions of that > > > >> transport path. > > > >> > > > > > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > >=20 > > > Your understanding is not correct. It is very much observable if=20 > > > this requirement is met from a black box point of view. > > > The MIP functions can only perform the Loopback when there is a=20 > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > received at a MIP needs to be returned (as LBR > > > packet) to the originating MEP function via the other=20 > direction of=20 > > > the co-routed bidirectional transport path. This other direction=20 > > > would not be available in an associated bidirectional transport=20 > > > path... and thus the loopback test > > would fail. > > >=20 > > > Similarly, when we have to apply TCM MEPs to monitor a=20 > segment, then=20 > > > this is possible in a co-routed bidir transport path but not in a=20 > > > associated bidir transport path. In the first case the TCM MEP=20 > > > Source and Sink functions are co-located and can exchange what is=20 > > > called "remote information" which is necessary for performance=20 > > > monitoring. > > > In the latter case the TCM MEP Source and Sink functions=20 > are in e.g.=20 > > > different nodes in the network and TCM would not be able=20 > to provide=20 > > > performance monitoring. > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > internal > > > > functions as appropriate)" should be deleted. It does not > > > add to "The > > > > intermediate nodes." > > >=20 > > > Your understanding is not correct. This text must not be=20 > deleted at=20 > > > all. > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > inclusion > > > > of "Tandem Connection." The definition within the ITU-T of > > > this term > > > > is > > > poorly > > > > specified and comes from the monitoring of a path that is > > > parallel (i.e. > > > tandem) > > > > to the data path being monitored. This definition of TC > > > seems to be at > > > variance, > > > > and would be if the ACH was actually in band. > > >=20 > > > I don't understand where your interpretation of tandem=20 > connection is=20 > > > described in ITU-T recommendations. I.e. "from the=20 > monitoring of a=20 > > > path that is parallel (i.e. tandem) to the data path being=20 > > > monitored."? > > >=20 > > > There is a "network connection" and this network=20 > connection is a set=20 > > > of interconnected "link connections" and "matrix connections". A=20 > > > subset of those interconnected link connections and matrix=20 > > > connections can be monitored and is then referred to as a "tandem=20 > > > connection". There is no "path that is parallel to the=20 > data path".=20 > > > There is only additional OAM inserted inside the data path by the=20 > > > TCM MEP_So function and this OAM is extracted from the=20 > data path by=20 > > > the TCM MEP_Sk function. > > >=20 > > > Regards, > > > Maarten > > >=20 > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > Sent: donderdag 16 april 2009 11:59 > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > Hi Sasha, > > >=20 > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > From the point of view of hardware, co-routed > > bidirectional LSPs > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > Requirement > > > > 34 in the latest MPLS-TP requirements draft > > >=20 > > > OK. Got it. > > >=20 > > > But what is this doing in the data plane requirements section? > > >=20 > > > In fact, what is this requirement actually saying? > > >=20 > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > other internal > > > > functions as appropriate) of a co-routed > > > bidirectional transport > > > > path at each (sub-)layer MUST be aware of the pairing > > > > relationship of the forward and the backward > > > directions of that > > > > transport path. > > > > > > >=20 > > > There is no way this is a functional requirement. That=20 > is, there is > > > *nothing* that can be observed from a black box point of=20 > view that=20 > > > results from adhering to this requirement. > > >=20 > > > Therefore it could be assumed that this requirement is met by=20 > > > configuring some data plane database component through the=20 > > > management plane. The database component is not used for anything=20 > > > except to satisfy this requirement for "awareness". > > >=20 > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > behavior? > > >=20 > > > > Please note that Requirement 34 is the ONLY item in the > > > list that is > > > > specific for co-routed bidirectional LSPs. (The pairing > > > requirements > > > > at end points for co-routed and associated bidirectional > > paths are > > > > exactly the same even if they appear in two different > > items in the > > > > requirements' list). > > > > In other words, without Requirement 34 the notion of co-routed=20 > > > > bidirectional paths would be void of any data plane content. > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > functions as appropriate") creates a suspicion that HW > > > support of the > > > > pairing awareness may be required in order to comply with it. > > >=20 > > > The entirety of the bracketted text "(including MEPs,=20 > MIPs and other=20 > > > internal functions as appropriate)" should be deleted. It=20 > does not=20 > > > add to "The intermediate nodes." > > >=20 > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > Tandem Connection: A tandem connection is an=20 > arbitrary part of a > > > > transport path that can be monitored (via OAM) > > > independently from the > > > > end-to-end monitoring (OAM). It may be a monitored=20 > segment or a > > > > monitored concatenated segment of a transport path. =20 > The tandem > > > > connection may also include the forwarding engine(s) of > > > the node(s) > > > > at the edge(s) of the segment or concatenated segment. > > > > > > >=20 > > > Actually, I am quite fed up about this persistent=20 > insistence on the=20 > > > inclusion of "Tandem Connection." The definition within=20 > the ITU-T of=20 > > > this term is poorly specified and comes from the monitoring of a=20 > > > path that is parallel (i.e. tandem) to the data path being=20 > > > monitored. This definition of TC seems to be at variance,=20 > and would=20 > > > be if the ACH was actually in band. > > >=20 > > > > Doesn't "forwarding engine" sound like hardware to you? > > >=20 > > > Yes, but so what? > > >=20 > > > > IMHO it is worth noting that neither the MPLS-TP > > Requirements draft > > > > nor the MPLS-TP OAM requirements one > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > ts-01.txt) contain any requirements dealing with tandem > > connections. > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM=20 > Framework=20 > > > > draft > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > amework-00.txt > > > ). > > >=20 > > > Right. > > > Let's just get rid of an unnecessary term and bring all the I-Ds=20 > > > into line. > > >=20 > > > > The bottom line, IMHO, is that some clarity regarding > > co-routed vs. > > > > associated > > > > bidirectional paths is still required. One way to provide > > > that could > > > > be by explicitly limiting Requirement 34 to specific > > functionality. > > >=20 > > > Agreed. > > >=20 > > > Adrian > > >=20 > > >=20 > > >=20 > > >=20 > > > ________________________________________ > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > Sent: Thursday, April 16, 2009 12:13 AM > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > Hi Sasha, > > >=20 > > > Not really sure whether you are misrepresenting anyone, but... > > >=20 > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > bidirectional paths are the only types of paths that can be > > > created in > > > > the existing networks; "true" co-routed bidirectional paths > > > will have > > > > to wait until (if ever) new equipment becomes available. > > >=20 > > > This is clearly nonsense! > > > From the point of view of hardware, co-routed=20 > bidirectional LSPs are=20 > > > a special case of associated bidirectional LSPs. > > >=20 > > > If you can set up two unidirectional LSPs (e.g. using the=20 > management=20 > > > plane) you can surely set up a co-routed > > bidirectional LSP. > > >=20 > > > There are shipping solutions that achieve co-routed bidirectional=20 > > > LSPs using the control plane. These either use the GMPLS=20 > (which is=20 > > > cleaner) or non-standard proprietary solutions (which is=20 > messy but=20 > > > functional). > > >=20 > > > But (of course) the management plane or control plane=20 > solutions have=20 > > > nothing to do with availability of equipment as they are software=20 > > > solutions. > > >=20 > > > > 2. My reading of one of Neil's messages is that the actual > > > driver for > > > > co-routed bidirectional paths may be experience with existing=20 > > > > transport networks rather than any specific benefit. > > >=20 > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > Which is not to say it is a bad thing. > > >=20 > > > A large driver for MPLS-TP is to give the packet network=20 > the look,=20 > > > feel, and behavioral characteristics of a "legacy" > > > transport network. > > >=20 > > > > Based on these observations, I'd guess (FWIW) that: > > > > * associated bidirectional paths are, at least for the time > > > > being, the most important type of bidirectional paths in > > > > MPLS-TP > > >=20 > > > I think that is wrong both given my statement above, and=20 > given that=20 > > > other upgrades to existing MPLS solutions will be needed to reach=20 > > > the full function level of MPLS-TP. > > >=20 > > > > * they had a good chance to remain the only type of=20 > bidirectional > > > > paths in real deployments. > > >=20 > > > I don't see what that follows from. > > >=20 > > > Cheers, > > > Adrian > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 From John.E.Drake2@boeing.com Fri Apr 17 12:06:07 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790BD3A6E64 for ; Fri, 17 Apr 2009 12:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na517UkeBv1G for ; Fri, 17 Apr 2009 12:06:05 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A2F843A6E51 for ; Fri, 17 Apr 2009 12:05:40 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3HJ6dv4021148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Apr 2009 12:06:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3HJ6crX002098; Fri, 17 Apr 2009 14:06:39 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3HJ6cpa002078; Fri, 17 Apr 2009 14:06:38 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 12:06:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 12:06:36 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6BE74@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsAABEewwAAbNqSAAAX1XEA== References: <2ECAA42C79676B42AEBAC11229CA7D0C046FFE01@E03MVB2-UKBR.domain1.systemhost.net> <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> From: "Drake, John E" To: "BUSI ITALO" , , , , , "VIGOUREUX MARTIN" X-OriginalArrivalTime: 17 Apr 2009 19:06:37.0864 (UTC) FILETIME=[A229B280:01C9BF8F] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 19:06:07 -0000 =20 > -----Original Message----- > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > Sent: Friday, April 17, 2009 11:29 AM > To: neil.2.harrison@bt.com; dbrungard@att.com;=20 > benjamin.niven-jenkins@bt.com;=20 > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP=20 > (wasRE:Associatedbidirectional transport path requirements) >=20 > Neil, >=20 > G.805 is an in-force Recommendation: G.800 was never intended=20 > to replace G.805. >=20 > People who worked on G.800 has always claimed that for=20 > connection-oriented technologies G.800 defaults to G.805. JD: Connection-oriented circuit or connection-oriented packet = technologies? >=20 > When Q12/15 consented G.800, it was agreed that existing=20 > Recommendations based on G.805 (e.g. G.8110.1) will continue=20 > to be based on G.805. >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 > neil.2.harrison@bt.com > > Sent: Friday, April 17, 2009 5:22 PM > > To: dbrungard@att.com; benjamin.niven-jenkins@bt.com;=20 > > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > > RE:Associatedbidirectional transport path requirements) > >=20 > > I agree with both Ben and Deborah. One further point to=20 > add here..... > >=20 > > G.805 is a fairly old Recommendation written largely to give us a=20 > > working func arch language for the development of management=20 > > information models when we were developing SONET/SDH. However, our=20 > > understanding of the physics of networking has improved=20 > significantly=20 > > and G.800 (Unified functional architecture of transport=20 > networks) is a=20 > > more comprehensive embodiment of that understanding that=20 > covers all 3=20 > > network modes (based on sound Info and Systems theory=20 > underpinnings). =20 > > So G.800 should be the starting point for any references to the=20 > > network func architecture for MPLS-TP and not G.805 IMO. > >=20 > > regards, Neil > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD,=20 > DEBORAH A,=20 > > > ATTLABS > > > Sent: 17 April 2009 15:59 > > > To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli;=20 > Martin Vigoureux > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > Associatedbidirectional transport path requirements) > > >=20 > > > I agree with Ben. TCM, with the introduction of MEL as a=20 > solution,=20 > > > has become architecturally confusing. When it was used in=20 > reference=20 > > > to SDH, where trail overhead was overwritten, it created a tandem=20 > > > connection. For cell/packet technologies where the OAM=20 > cells/packets=20 > > > are inserted, it is not clear if this is a tandem connection or a=20 > > > new server layer, as both architectural terms are used in the=20 > > > standards. > > >=20 > > > In G803, TCM is a sublayer monitoring technique for a SDH tandem=20 > > > connection: > > > "Sublayer monitoring > > > Connections may be directly monitored at one end of a=20 > connection by=20 > > > overwriting some portion of the original trail's overhead=20 > capacity=20 > > > at the beginning of the connection. > > > For SDH, overhead has been defined for this purpose at the=20 > > > higher-order and lower-order path layers. When applied to a SDH=20 > > > tandem connection, this monitoring method is referred to=20 > as tandem=20 > > > connection monitoring." > > >=20 > > > Whereas in Y.1711: > > > "OAM techniques are applied on a per LSP basis. If a segment of a=20 > > > given LSP at layer N is to be monitored for some reason=20 > (e.g., via a=20 > > > CV or P flow say), one way to do this is by creating a new server=20 > > > layer LSP (i.e., at layer N + 1) to cover the segment at layer N." > > >=20 > > > So I think before using TCM in reference to MPLS-TP, Q12 needs to=20 > > > align on the use. For now, the requirements documents=20 > should try to=20 > > > avoid it. > > >=20 > > > Deborah > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > > Sent: Friday, April 17, 2009 10:26 AM > > > To: Annamaria Fulignoli; Martin Vigoureux > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > Associated bidirectional transport path requirements) > > >=20 > > > Because IMO use of the term TCM tends to make people think of a=20 > > > particular solution and what we want to do at this stage=20 > is express=20 > > > the functional requirements and not imply any particular solution. > > >=20 > > > Certainly most of my mails in this thread (and I am=20 > probably not the=20 > > > only > > > one) have been based on the fact that when discussing TCM=20 > I assume a=20 > > > particular solution is being discussed. Talking purely in=20 > terms of=20 > > > functional requirements removes that ambiguity. > > >=20 > > > Ben > > >=20 > > >=20 > > > On 17/04/2009 12:51, "Annamaria Fulignoli" > > > wrote: > > >=20 > > > > Hi all, > > > > sorry but I do not understand why we cannot explicitly use > > > the term Tandem > > > > Connection in the requirements document! > > > > TCM is not a solution, it is part of functional > > > architecture of a transport > > > > networks as described in G.805. The solution is to realize > > > it with label > > > > stacking rather than MEL. > > > >=20 > > > > Regards > > > > Annamaria > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > > > Martin Vigoureux > > > > Sent: venerd=EC 17 aprile 2009 13.29 > > > > To: Ben Niven-Jenkins > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was > > > RE: Associated > > > > bidirectional transport path requirements) > > > >=20 > > > > Ben, all > > > >=20 > > > > in mpls-tp-oam-requirement, the text on this item is as follows: > > > >=20 > > > > The service emulated by a single segment or a > > > multi-segment PW may > > > > span multiple domains. A LSP may also span multiple > > > domains. It > > > > MUST be possible to perform OAM functions on a per > > > domain basis and > > > > across multiple domains. More generally it MUST be > > possible to > > > > perform OAM functions between any two switching > > > elements (e.g., LSR > > > > or S-PE) of a LSP or of PW. This is referred to as > > > (concatenated) > > > > segment monitoring. > > > >=20 > > > > I believe the text describes a functional req. > > > >=20 > > > > During mead team review, the removal of the last sentence > > > was discussed. > > > > No strong opinion was expressed on whether it should > > > effectively be removed or > > > > not. > > > >=20 > > > > regards, > > > > martin > > > >=20 > > > > Ben Niven-Jenkins a =E9crit : > > > >> Italo, > > > >>=20 > > > >> I think we are converging. If I can be so bold as to=20 > speak on his=20 > > > >> behalf Adrian's objection seemed to be to the use of the > > term TCM. > > > >>=20 > > > >> It is defined in the MPLS-TP requirements but not used. > > > >>=20 > > > >> It is not used in the MPLS-TP OAM requirements document. > > > >>=20 > > > >> Therefore I think the way forward is as follows: > > > >>=20 > > > >> 1) Remove the term Tandem Connection from the MPLS-TP > > > requirements as > > > >> it is redundant (i.e. Not used in that document). > > > >>=20 > > > >> 2) Ensure the MPLS-TP OAM requirements express the necessary=20 > > > >> functional requirements around monitoring of end to end > > > paths as well > > > >> as parts of end to end paths. This can be done without=20 > referring=20 > > > >> explicitly to Tandem Connections. > > > >>=20 > > > >> When it comes to solution design we can decide what is=20 > the best=20 > > > >> mechanism to achieve/implement those requirements be it > > > LSP hierarchy or > > > >> something else. > > > >> The JWT has proved that it is possible to meet those=20 > requirements=20 > > > >> using existing MPLS technology (maybe with some > > enhancements). I do > > > >> not believe we have to necessarily use the solution=20 > they propose=20 > > > >> aslong as whatever solution we ultimately decide upon > > meets all the > > > >> necessary requirements expressed. > > > >>=20 > > > >> Can we agree on that as an approach and close this off for now? > > > >>=20 > > > >> Ben > > > >>=20 > > > >>=20 > > > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > > > wrote: > > > >>=20 > > > >>> Ben, > > > >>>=20 > > > >>> I think we are mixing solutions with requirements. > > > >>>=20 > > > >>> The requirement for the TCM function is clearly=20 > defined and I do=20 > > > >>> think it must be addressed by the MPLS-TP design. > > > >>>=20 > > > >>> The solution evaluated by the JWT to meet this > > > requirement was to use > > > >>> label stacking with a 1:1 relationship between the TCM > > LSP and the > > > >>> e2e LSP. > > > >>>=20 > > > >>> I think this solution, although not the best technical > > option, is > > > >>> good enough and meets the requirements. > > > >>>=20 > > > >>> However this is is a solution and has not impact on the > > > requirement. > > > >>>=20 > > > >>> Italo > > > >>>=20 > > > >>>> -----Original Message----- > > > >>>> From: Ben Niven-Jenkins=20 > [mailto:benjamin.niven-jenkins@bt.com] > > > >>>> Sent: Friday, April 17, 2009 11:22 AM > > > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > > > >>>> Cc: mpls-tp@ietf.org; Lou Berger > > > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE:=20 > [mpls-tp]=20 > > > >>>> Associated bidirectional transport path requirements) > > > >>>>=20 > > > >>>> Italo, > > > >>>>=20 > > > >>>> On 17/04/2009 09:34, "BUSI ITALO" > > > >>>> wrote: > > > >>>>> The JWT agreement is to bring the ITU-T transport > > > >>>> requirements in IETF > > > >>>>> to extend the MPLS architecture to meet them in a=20 > way that is=20 > > > >>>>> compatible, consistent and coherent with existing IETF > > > architecture. > > > >>>> So I took a look at the JWT report. It says (slide 16) > > > >>>>=20 > > > >>>> " Service Providers want LSPs/PWEs to be able to be > > > managed at the > > > >>>> different nested levels seamlessly (path, segment, multiple > > > >>>> segments) > > > >>>> aka Tandem Connection Monitoring (TCM), this is used > > > for example > > > >>>> when a LSP/PWE crosses multiple administrations" > > > >>>>=20 > > > >>>> IMO the requirement is to be able to monitor parts of a > > > path as well > > > >>>> as the end to end path. There are many ways to solve that=20 > > > >>>> requirement, one of which is the creation of nested > > LSPs, one per > > > >>>> level of monitoring required (my understanding of how > > TCM works). > > > >>>>=20 > > > >>>> I think the real discussion is therefore is the=20 > requirement to=20 > > > >>>> monitor different components of an end to end path or is the=20 > > > >>>> requirement that such monitoring MUST be achieved using > > > nested LSPs? > > > >>>>=20 > > > >>>> As an example PW technology today allows end to end and > > > per segment > > > >>>> monitoring but it does not achieve it using nested PWs > > > or PW levels. > > > >>>>=20 > > > >>>> Ben > > > >>>>=20 > > > >>>>=20 > > > >>=20 > > > >> _______________________________________________ > > > >> mpls-tp mailing list > > > >> mpls-tp@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > >>=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From Italo.Busi@alcatel-lucent.it Fri Apr 17 12:08:21 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D863A6E0D for ; Fri, 17 Apr 2009 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMCz7l3-zf83 for ; Fri, 17 Apr 2009 12:08:20 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 6C98B3A6E3B for ; Fri, 17 Apr 2009 12:08:19 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HJ9Nv0023241; Fri, 17 Apr 2009 21:09:23 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 21:09:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 21:09:14 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1A77@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <51661468CBD1354294533DA79E85955A01A6BE74@XCH-SW-5V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsAABEewwAAbNqSAAAX1XEAAAIUPQ References: <2ECAA42C79676B42AEBAC11229CA7D0C046FFE01@E03MVB2-UKBR.domain1.systemhost.net> <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> <51661468CBD1354294533DA79E85955A01A6BE74@XCH-SW-5V2.sw.nos.boeing.com> From: "BUSI ITALO" To: "Drake, John E" , , , , , "VIGOUREUX MARTIN" X-OriginalArrivalTime: 17 Apr 2009 19:09:22.0986 (UTC) FILETIME=[049550A0:01C9BF90] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 19:08:21 -0000 Both Italo=20 > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Sent: Friday, April 17, 2009 9:07 PM > To: BUSI ITALO; neil.2.harrison@bt.com; dbrungard@att.com;=20 > benjamin.niven-jenkins@bt.com;=20 > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP=20 > (wasRE:Associatedbidirectional transport path requirements) >=20 > =20 >=20 > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > > Sent: Friday, April 17, 2009 11:29 AM > > To: neil.2.harrison@bt.com; dbrungard@att.com;=20 > > benjamin.niven-jenkins@bt.com;=20 > > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP=20 > > (wasRE:Associatedbidirectional transport path requirements) > >=20 > > Neil, > >=20 > > G.805 is an in-force Recommendation: G.800 was never intended=20 > > to replace G.805. > >=20 > > People who worked on G.800 has always claimed that for=20 > > connection-oriented technologies G.800 defaults to G.805. >=20 > JD: Connection-oriented circuit or connection-oriented=20 > packet technologies? >=20 > >=20 > > When Q12/15 consented G.800, it was agreed that existing=20 > > Recommendations based on G.805 (e.g. G.8110.1) will continue=20 > > to be based on G.805. > >=20 > > Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 > > neil.2.harrison@bt.com > > > Sent: Friday, April 17, 2009 5:22 PM > > > To: dbrungard@att.com; benjamin.niven-jenkins@bt.com;=20 > > > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > > > RE:Associatedbidirectional transport path requirements) > > >=20 > > > I agree with both Ben and Deborah. One further point to=20 > > add here..... > > >=20 > > > G.805 is a fairly old Recommendation written largely to give us a=20 > > > working func arch language for the development of management=20 > > > information models when we were developing SONET/SDH. =20 > However, our=20 > > > understanding of the physics of networking has improved=20 > > significantly=20 > > > and G.800 (Unified functional architecture of transport=20 > > networks) is a=20 > > > more comprehensive embodiment of that understanding that=20 > > covers all 3=20 > > > network modes (based on sound Info and Systems theory=20 > > underpinnings). =20 > > > So G.800 should be the starting point for any references to the=20 > > > network func architecture for MPLS-TP and not G.805 IMO. > > >=20 > > > regards, Neil > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD,=20 > > DEBORAH A,=20 > > > > ATTLABS > > > > Sent: 17 April 2009 15:59 > > > > To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli;=20 > > Martin Vigoureux > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > > Associatedbidirectional transport path requirements) > > > >=20 > > > > I agree with Ben. TCM, with the introduction of MEL as a=20 > > solution,=20 > > > > has become architecturally confusing. When it was used in=20 > > reference=20 > > > > to SDH, where trail overhead was overwritten, it=20 > created a tandem=20 > > > > connection. For cell/packet technologies where the OAM=20 > > cells/packets=20 > > > > are inserted, it is not clear if this is a tandem=20 > connection or a=20 > > > > new server layer, as both architectural terms are used in the=20 > > > > standards. > > > >=20 > > > > In G803, TCM is a sublayer monitoring technique for a=20 > SDH tandem=20 > > > > connection: > > > > "Sublayer monitoring > > > > Connections may be directly monitored at one end of a=20 > > connection by=20 > > > > overwriting some portion of the original trail's overhead=20 > > capacity=20 > > > > at the beginning of the connection. > > > > For SDH, overhead has been defined for this purpose at the=20 > > > > higher-order and lower-order path layers. When applied to a SDH=20 > > > > tandem connection, this monitoring method is referred to=20 > > as tandem=20 > > > > connection monitoring." > > > >=20 > > > > Whereas in Y.1711: > > > > "OAM techniques are applied on a per LSP basis. If a=20 > segment of a=20 > > > > given LSP at layer N is to be monitored for some reason=20 > > (e.g., via a=20 > > > > CV or P flow say), one way to do this is by creating a=20 > new server=20 > > > > layer LSP (i.e., at layer N + 1) to cover the segment=20 > at layer N." > > > >=20 > > > > So I think before using TCM in reference to MPLS-TP,=20 > Q12 needs to=20 > > > > align on the use. For now, the requirements documents=20 > > should try to=20 > > > > avoid it. > > > >=20 > > > > Deborah > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > > > Sent: Friday, April 17, 2009 10:26 AM > > > > To: Annamaria Fulignoli; Martin Vigoureux > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > > Associated bidirectional transport path requirements) > > > >=20 > > > > Because IMO use of the term TCM tends to make people think of a=20 > > > > particular solution and what we want to do at this stage=20 > > is express=20 > > > > the functional requirements and not imply any=20 > particular solution. > > > >=20 > > > > Certainly most of my mails in this thread (and I am=20 > > probably not the=20 > > > > only > > > > one) have been based on the fact that when discussing TCM=20 > > I assume a=20 > > > > particular solution is being discussed. Talking purely in=20 > > terms of=20 > > > > functional requirements removes that ambiguity. > > > >=20 > > > > Ben > > > >=20 > > > >=20 > > > > On 17/04/2009 12:51, "Annamaria Fulignoli" > > > > wrote: > > > >=20 > > > > > Hi all, > > > > > sorry but I do not understand why we cannot explicitly use > > > > the term Tandem > > > > > Connection in the requirements document! > > > > > TCM is not a solution, it is part of functional > > > > architecture of a transport > > > > > networks as described in G.805. The solution is to realize > > > > it with label > > > > > stacking rather than MEL. > > > > >=20 > > > > > Regards > > > > > Annamaria > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > > > > Martin Vigoureux > > > > > Sent: venerd=EC 17 aprile 2009 13.29 > > > > > To: Ben Niven-Jenkins > > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was > > > > RE: Associated > > > > > bidirectional transport path requirements) > > > > >=20 > > > > > Ben, all > > > > >=20 > > > > > in mpls-tp-oam-requirement, the text on this item is=20 > as follows: > > > > >=20 > > > > > The service emulated by a single segment or a > > > > multi-segment PW may > > > > > span multiple domains. A LSP may also span multiple > > > > domains. It > > > > > MUST be possible to perform OAM functions on a per > > > > domain basis and > > > > > across multiple domains. More generally it MUST be > > > possible to > > > > > perform OAM functions between any two switching > > > > elements (e.g., LSR > > > > > or S-PE) of a LSP or of PW. This is referred to as > > > > (concatenated) > > > > > segment monitoring. > > > > >=20 > > > > > I believe the text describes a functional req. > > > > >=20 > > > > > During mead team review, the removal of the last sentence > > > > was discussed. > > > > > No strong opinion was expressed on whether it should > > > > effectively be removed or > > > > > not. > > > > >=20 > > > > > regards, > > > > > martin > > > > >=20 > > > > > Ben Niven-Jenkins a =E9crit : > > > > >> Italo, > > > > >>=20 > > > > >> I think we are converging. If I can be so bold as to=20 > > speak on his=20 > > > > >> behalf Adrian's objection seemed to be to the use of the > > > term TCM. > > > > >>=20 > > > > >> It is defined in the MPLS-TP requirements but not used. > > > > >>=20 > > > > >> It is not used in the MPLS-TP OAM requirements document. > > > > >>=20 > > > > >> Therefore I think the way forward is as follows: > > > > >>=20 > > > > >> 1) Remove the term Tandem Connection from the MPLS-TP > > > > requirements as > > > > >> it is redundant (i.e. Not used in that document). > > > > >>=20 > > > > >> 2) Ensure the MPLS-TP OAM requirements express the necessary=20 > > > > >> functional requirements around monitoring of end to end > > > > paths as well > > > > >> as parts of end to end paths. This can be done without=20 > > referring=20 > > > > >> explicitly to Tandem Connections. > > > > >>=20 > > > > >> When it comes to solution design we can decide what is=20 > > the best=20 > > > > >> mechanism to achieve/implement those requirements be it > > > > LSP hierarchy or > > > > >> something else. > > > > >> The JWT has proved that it is possible to meet those=20 > > requirements=20 > > > > >> using existing MPLS technology (maybe with some > > > enhancements). I do > > > > >> not believe we have to necessarily use the solution=20 > > they propose=20 > > > > >> aslong as whatever solution we ultimately decide upon > > > meets all the > > > > >> necessary requirements expressed. > > > > >>=20 > > > > >> Can we agree on that as an approach and close this=20 > off for now? > > > > >>=20 > > > > >> Ben > > > > >>=20 > > > > >>=20 > > > > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > > > > wrote: > > > > >>=20 > > > > >>> Ben, > > > > >>>=20 > > > > >>> I think we are mixing solutions with requirements. > > > > >>>=20 > > > > >>> The requirement for the TCM function is clearly=20 > > defined and I do=20 > > > > >>> think it must be addressed by the MPLS-TP design. > > > > >>>=20 > > > > >>> The solution evaluated by the JWT to meet this > > > > requirement was to use > > > > >>> label stacking with a 1:1 relationship between the TCM > > > LSP and the > > > > >>> e2e LSP. > > > > >>>=20 > > > > >>> I think this solution, although not the best technical > > > option, is > > > > >>> good enough and meets the requirements. > > > > >>>=20 > > > > >>> However this is is a solution and has not impact on the > > > > requirement. > > > > >>>=20 > > > > >>> Italo > > > > >>>=20 > > > > >>>> -----Original Message----- > > > > >>>> From: Ben Niven-Jenkins=20 > > [mailto:benjamin.niven-jenkins@bt.com] > > > > >>>> Sent: Friday, April 17, 2009 11:22 AM > > > > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > > > > >>>> Cc: mpls-tp@ietf.org; Lou Berger > > > > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE:=20 > > [mpls-tp]=20 > > > > >>>> Associated bidirectional transport path requirements) > > > > >>>>=20 > > > > >>>> Italo, > > > > >>>>=20 > > > > >>>> On 17/04/2009 09:34, "BUSI ITALO" > > > > >>>> wrote: > > > > >>>>> The JWT agreement is to bring the ITU-T transport > > > > >>>> requirements in IETF > > > > >>>>> to extend the MPLS architecture to meet them in a=20 > > way that is=20 > > > > >>>>> compatible, consistent and coherent with existing IETF > > > > architecture. > > > > >>>> So I took a look at the JWT report. It says (slide 16) > > > > >>>>=20 > > > > >>>> " Service Providers want LSPs/PWEs to be able to be > > > > managed at the > > > > >>>> different nested levels seamlessly (path, segment, multiple > > > > >>>> segments) > > > > >>>> aka Tandem Connection Monitoring (TCM), this is used > > > > for example > > > > >>>> when a LSP/PWE crosses multiple administrations" > > > > >>>>=20 > > > > >>>> IMO the requirement is to be able to monitor parts of a > > > > path as well > > > > >>>> as the end to end path. There are many ways to solve that=20 > > > > >>>> requirement, one of which is the creation of nested > > > LSPs, one per > > > > >>>> level of monitoring required (my understanding of how > > > TCM works). > > > > >>>>=20 > > > > >>>> I think the real discussion is therefore is the=20 > > requirement to=20 > > > > >>>> monitor different components of an end to end path=20 > or is the=20 > > > > >>>> requirement that such monitoring MUST be achieved using > > > > nested LSPs? > > > > >>>>=20 > > > > >>>> As an example PW technology today allows end to end and > > > > per segment > > > > >>>> monitoring but it does not achieve it using nested PWs > > > > or PW levels. > > > > >>>>=20 > > > > >>>> Ben > > > > >>>>=20 > > > > >>>>=20 > > > > >>=20 > > > > >> _______________________________________________ > > > > >> mpls-tp mailing list > > > > >> mpls-tp@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >>=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 From neil.2.harrison@bt.com Fri Apr 17 12:24:09 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6513A6DF5 for ; Fri, 17 Apr 2009 12:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaI4CwJSXZTM for ; Fri, 17 Apr 2009 12:24:07 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 16D5D3A6E18 for ; Fri, 17 Apr 2009 12:24:06 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 20:25:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 20:25:19 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FFEC6@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) thread-index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsAABEewwAAbNqSAAARuBAA== From: To: , , , , X-OriginalArrivalTime: 17 Apr 2009 19:25:19.0642 (UTC) FILETIME=[3ECB6FA0:01C9BF92] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 19:24:09 -0000 Thanks Italo....I understand why you say this. But I also work closely = with Andy Reid who is the major driving force behind G.800 (and one of = the folks who wrote the initial version of G.805) and it is very clear = to me that the concepts that underpin G.800 are vastly superior to what = we understood (as networking truths) at the time when G.805 was drafted. = But this (ie G.800) is a more general (and powerful) statement about = how networks work and why we see the networking world as we do, ie 3 = modes, etc. And IMO it shoots down some sacred networking cows which is = why some folks don't like it and appeal back to the good-old G.805 days. TCM is a specific issue related to OAM. And to repeat what I said = earlier, I know of no engineer here in BT (this includes folks like Andy = Reid, Alan McGuire, Ben Niven-Jenkins, me (obviously) etc) who think TCM = is a good idea....quite the opposite in fact. When we wrote a systems = engineering spec for PBB-TE a while back there was no mention of TCM, = and we would hold the same view for MPLS-TP.....there are far smarter = ways to deal with rare on-demand OAM diagnostics. So the mere fact that = the term TCM appears in G.805 does not vindicate it's value in any way = IMO. I know you sidestepped my observation on TCM and IP, but if one is = seriously suggesting TCM is such a great idea in IETF then it ought to = figure in IP even before it gets considered for MPLS-TP IMO.....but I = strongly suspect it never will and I think I also know why that would = be. regards, Neil > -----Original Message----- > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > Sent: 17 April 2009 19:29 > To: Harrison,N,Neil,CXM R; dbrungard@att.com;=20 > Niven-jenkins,B,Ben,DMF R; annamaria.fulignoli@ericsson.com;=20 > VIGOUREUX MARTIN > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE:Associatedbidirectional transport path requirements) >=20 > Neil, >=20 > G.805 is an in-force Recommendation: G.800 was never intended=20 > to replace G.805. >=20 > People who worked on G.800 has always claimed that for=20 > connection-oriented technologies G.800 defaults to G.805. >=20 > When Q12/15 consented G.800, it was agreed that existing=20 > Recommendations based on G.805 (e.g. G.8110.1) will continue=20 > to be based on G.805. >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 > neil.2.harrison@bt.com > > Sent: Friday, April 17, 2009 5:22 PM > > To: dbrungard@att.com; benjamin.niven-jenkins@bt.com;=20 > > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > > RE:Associatedbidirectional transport path requirements) > >=20 > > I agree with both Ben and Deborah. One further point to=20 > add here..... > >=20 > > G.805 is a fairly old Recommendation written largely to give=20 > > us a working func arch language for the development of=20 > > management information models when we were developing=20 > > SONET/SDH. However, our understanding of the physics of=20 > > networking has improved significantly and G.800 (Unified=20 > > functional architecture of transport networks) is a more=20 > > comprehensive embodiment of that understanding that covers=20 > > all 3 network modes (based on sound Info and Systems theory=20 > > underpinnings). So G.800 should be the starting point for=20 > > any references to the network func architecture for MPLS-TP=20 > > and not G.805 IMO. > >=20 > > regards, Neil > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD,=20 > > > DEBORAH A, ATTLABS > > > Sent: 17 April 2009 15:59 > > > To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli;=20 > Martin Vigoureux > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > Associatedbidirectional transport path requirements) > > >=20 > > > I agree with Ben. TCM, with the introduction of MEL as a=20 > > > solution, has become architecturally confusing. When it was=20 > > > used in reference to SDH, where trail overhead was=20 > > > overwritten, it created a tandem connection. For cell/packet=20 > > > technologies where the OAM cells/packets are inserted, it is=20 > > > not clear if this is a tandem connection or a new server=20 > > > layer, as both architectural terms are used in the standards.=20 > > >=20 > > > In G803, TCM is a sublayer monitoring technique for a SDH=20 > > > tandem connection: > > > "Sublayer monitoring > > > Connections may be directly monitored at one end of a=20 > > > connection by overwriting some portion of the original=20 > > > trail's overhead capacity at the beginning of the connection.=20 > > > For SDH, overhead has been defined for this purpose at the=20 > > > higher-order and lower-order path layers. When applied to a=20 > > > SDH tandem connection, this monitoring method is referred to=20 > > > as tandem connection monitoring." > > >=20 > > > Whereas in Y.1711: > > > "OAM techniques are applied on a per LSP basis. If a segment=20 > > > of a given LSP at layer N is to be monitored for some reason=20 > > > (e.g., via a CV or P flow say), one way to do this is by=20 > > > creating a new server layer LSP (i.e., at layer N + 1) to=20 > > > cover the segment at layer N." > > >=20 > > > So I think before using TCM in reference to MPLS-TP, Q12=20 > > > needs to align on the use. For now, the requirements=20 > > > documents should try to avoid it. > > >=20 > > > Deborah > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > > Sent: Friday, April 17, 2009 10:26 AM > > > To: Annamaria Fulignoli; Martin Vigoureux > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > Associated bidirectional transport path requirements) > > >=20 > > > Because IMO use of the term TCM tends to make people think of=20 > > > a particular > > > solution and what we want to do at this stage is express the=20 > > > functional > > > requirements and not imply any particular solution. > > >=20 > > > Certainly most of my mails in this thread (and I am probably=20 > > > not the only > > > one) have been based on the fact that when discussing TCM=20 > I assume a > > > particular solution is being discussed. Talking purely in terms of > > > functional requirements removes that ambiguity. > > >=20 > > > Ben > > >=20 > > >=20 > > > On 17/04/2009 12:51, "Annamaria Fulignoli" > > > wrote: > > >=20 > > > > Hi all, > > > > sorry but I do not understand why we cannot explicitly use=20 > > > the term Tandem > > > > Connection in the requirements document! > > > > TCM is not a solution, it is part of functional=20 > > > architecture of a transport > > > > networks as described in G.805. The solution is to realize=20 > > > it with label > > > > stacking rather than MEL. > > > >=20 > > > > Regards > > > > Annamaria > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org=20 > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > > > Martin Vigoureux > > > > Sent: venerd=EC 17 aprile 2009 13.29 > > > > To: Ben Niven-Jenkins > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > > > RE: Associated > > > > bidirectional transport path requirements) > > > >=20 > > > > Ben, all > > > >=20 > > > > in mpls-tp-oam-requirement, the text on this item is as follows: > > > >=20 > > > > The service emulated by a single segment or a=20 > > > multi-segment PW may > > > > span multiple domains. A LSP may also span multiple=20 > > > domains. It > > > > MUST be possible to perform OAM functions on a per=20 > > > domain basis and > > > > across multiple domains. More generally it MUST be=20 > > possible to > > > > perform OAM functions between any two switching=20 > > > elements (e.g., LSR > > > > or S-PE) of a LSP or of PW. This is referred to as=20 > > > (concatenated) > > > > segment monitoring. > > > >=20 > > > > I believe the text describes a functional req. > > > >=20 > > > > During mead team review, the removal of the last sentence=20 > > > was discussed. > > > > No strong opinion was expressed on whether it should=20 > > > effectively be removed or > > > > not. > > > >=20 > > > > regards, > > > > martin > > > >=20 > > > > Ben Niven-Jenkins a =E9crit : > > > >> Italo, > > > >>=20 > > > >> I think we are converging. If I can be so bold as to=20 > speak on his > > > >> behalf Adrian's objection seemed to be to the use of the=20 > > term TCM. > > > >>=20 > > > >> It is defined in the MPLS-TP requirements but not used. > > > >>=20 > > > >> It is not used in the MPLS-TP OAM requirements document. > > > >>=20 > > > >> Therefore I think the way forward is as follows: > > > >>=20 > > > >> 1) Remove the term Tandem Connection from the MPLS-TP=20 > > > requirements as > > > >> it is redundant (i.e. Not used in that document). > > > >>=20 > > > >> 2) Ensure the MPLS-TP OAM requirements express the necessary > > > >> functional requirements around monitoring of end to end=20 > > > paths as well > > > >> as parts of end to end paths. This can be done without=20 > referring > > > >> explicitly to Tandem Connections. > > > >>=20 > > > >> When it comes to solution design we can decide what is the best > > > >> mechanism to achieve/implement those requirements be it=20 > > > LSP hierarchy or > > > >> something else. > > > >> The JWT has proved that it is possible to meet those=20 > requirements > > > >> using existing MPLS technology (maybe with some=20 > > enhancements). I do > > > >> not believe we have to necessarily use the solution=20 > they propose > > > >> aslong as whatever solution we ultimately decide upon=20 > > meets all the > > > >> necessary requirements expressed. > > > >>=20 > > > >> Can we agree on that as an approach and close this off for now? > > > >>=20 > > > >> Ben > > > >>=20 > > > >>=20 > > > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > > > wrote: > > > >>=20 > > > >>> Ben, > > > >>>=20 > > > >>> I think we are mixing solutions with requirements. > > > >>>=20 > > > >>> The requirement for the TCM function is clearly=20 > defined and I do > > > >>> think it must be addressed by the MPLS-TP design. > > > >>>=20 > > > >>> The solution evaluated by the JWT to meet this=20 > > > requirement was to use > > > >>> label stacking with a 1:1 relationship between the TCM=20 > > LSP and the > > > >>> e2e LSP. > > > >>>=20 > > > >>> I think this solution, although not the best technical=20 > > option, is > > > >>> good enough and meets the requirements. > > > >>>=20 > > > >>> However this is is a solution and has not impact on the=20 > > > requirement. > > > >>>=20 > > > >>> Italo > > > >>>=20 > > > >>>> -----Original Message----- > > > >>>> From: Ben Niven-Jenkins=20 > [mailto:benjamin.niven-jenkins@bt.com] > > > >>>> Sent: Friday, April 17, 2009 11:22 AM > > > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > > > >>>> Cc: mpls-tp@ietf.org; Lou Berger > > > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] > > > >>>> Associated bidirectional transport path requirements) > > > >>>>=20 > > > >>>> Italo, > > > >>>>=20 > > > >>>> On 17/04/2009 09:34, "BUSI ITALO" > > > >>>> wrote: > > > >>>>> The JWT agreement is to bring the ITU-T transport > > > >>>> requirements in IETF > > > >>>>> to extend the MPLS architecture to meet them in a=20 > way that is > > > >>>>> compatible, consistent and coherent with existing IETF=20 > > > architecture. > > > >>>> So I took a look at the JWT report. It says (slide 16) > > > >>>>=20 > > > >>>> " Service Providers want LSPs/PWEs to be able to be=20 > > > managed at the > > > >>>> different nested levels seamlessly (path, segment, multiple > > > >>>> segments) > > > >>>> aka Tandem Connection Monitoring (TCM), this is used=20 > > > for example > > > >>>> when a LSP/PWE crosses multiple administrations" > > > >>>>=20 > > > >>>> IMO the requirement is to be able to monitor parts of a=20 > > > path as well > > > >>>> as the end to end path. There are many ways to solve that > > > >>>> requirement, one of which is the creation of nested=20 > > LSPs, one per > > > >>>> level of monitoring required (my understanding of how=20 > > TCM works). > > > >>>>=20 > > > >>>> I think the real discussion is therefore is the=20 > requirement to > > > >>>> monitor different components of an end to end path or is the > > > >>>> requirement that such monitoring MUST be achieved using=20 > > > nested LSPs? > > > >>>>=20 > > > >>>> As an example PW technology today allows end to end and=20 > > > per segment > > > >>>> monitoring but it does not achieve it using nested PWs=20 > > > or PW levels. > > > >>>>=20 > > > >>>> Ben > > > >>>>=20 > > > >>>>=20 > > > >>=20 > > > >> _______________________________________________ > > > >> mpls-tp mailing list > > > >> mpls-tp@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > >>=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 From neil.2.harrison@bt.com Fri Apr 17 12:59:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144963A6838 for ; Fri, 17 Apr 2009 12:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tZlZ4xJnmjQ for ; Fri, 17 Apr 2009 12:59:10 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 765933A6829 for ; Fri, 17 Apr 2009 12:59:09 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 21:00:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 21:00:17 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FFEDD@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <51661468CBD1354294533DA79E85955A01A6BE71@XCH-SW-5V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWgABQg5yAAAjIJkA== From: To: , , , X-OriginalArrivalTime: 17 Apr 2009 20:00:22.0089 (UTC) FILETIME=[23F36390:01C9BF97] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 19:59:12 -0000 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a=20 > return path > they are disabled. >=20 > As described in David Sinicrope's meeting minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an > MPLS TP network needs to be capable of getting IP packets from > destination to source; neither the minutes nor I stipulate that a > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework > I-D, unicast LSPs are only mentioned three times and return=20 > paths not at > all. =20 >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of=20 > > requirements ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a=20 > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus=20 > > other more important requirements (e.g. the possibility to=20 > > work w/o IP forwarding and the need for OAM to continue to=20 > > monitor the data plane also in case of failures affecting the=20 > > control or management plane). > >=20 > > I am open to discuss it but not sure this is the right time=20 > > because I wish to avoid delaying the first phase of the=20 > > design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I=20 > > think it was=20 > > > agreed that an MPLS TP network needs to have a forwarding=20 > > capability=20 > > > for management, control, and OAM packets (e.g., sending=20 > > replies to OAM=20 > > > requests sent on uni-directional LSPs) even if it does not=20 > > have an IP=20 > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function=20 > > (and fault=20 > > > > localization which requires this function ) for=20 > > unidirectional P2MP=20 > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW)=20 > raises a valid=20 > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these=20 > types of transport=20 > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of=20 > > functionality today=20 > > > > for (unidirectional - but it does not know any other=20 > > type) P2P LSPs =20 > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org]=20 > > On Behalf=20 > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much=20 > observable if=20 > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other=20 > > direction of=20 > > > > the co-routed bidirectional transport path. This other=20 > direction=20 > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a=20 > > segment, then=20 > > > > this is possible in a co-routed bidir transport path=20 > but not in a=20 > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can=20 > exchange what is=20 > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions=20 > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able=20 > > to provide=20 > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be=20 > > deleted at=20 > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem=20 > > connection is=20 > > > > described in ITU-T recommendations. I.e. "from the=20 > > monitoring of a=20 > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network=20 > > connection is a set=20 > > > > of interconnected "link connections" and "matrix=20 > connections". A=20 > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as=20 > a "tandem=20 > > > > connection". There is no "path that is parallel to the=20 > > data path".=20 > > > > There is only additional OAM inserted inside the data=20 > path by the=20 > > > > TCM MEP_So function and this OAM is extracted from the=20 > > data path by=20 > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That=20 > > is, there is > > > > *nothing* that can be observed from a black box point of=20 > > view that=20 > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used=20 > for anything=20 > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of=20 > co-routed=20 > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs,=20 > > MIPs and other=20 > > > > internal functions as appropriate)" should be deleted. It=20 > > does not=20 > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an=20 > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored=20 > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent=20 > > insistence on the=20 > > > > inclusion of "Tandem Connection." The definition within=20 > > the ITU-T of=20 > > > > this term is poorly specified and comes from the=20 > monitoring of a=20 > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance,=20 > > and would=20 > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM=20 > > Framework=20 > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all=20 > the I-Ds=20 > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed=20 > > bidirectional LSPs are=20 > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the=20 > > management=20 > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed=20 > bidirectional=20 > > > > LSPs using the control plane. These either use the GMPLS=20 > > (which is=20 > > > > cleaner) or non-standard proprietary solutions (which is=20 > > messy but=20 > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane=20 > > solutions have=20 > > > > nothing to do with availability of equipment as they=20 > are software=20 > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network=20 > > the look,=20 > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and=20 > > given that=20 > > > > other upgrades to existing MPLS solutions will be=20 > needed to reach=20 > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of=20 > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From adrian@olddog.co.uk Fri Apr 17 13:57:16 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173DC3A68D3 for ; Fri, 17 Apr 2009 13:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps1diwvKYlip for ; Fri, 17 Apr 2009 13:57:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 091213A6885 for ; Fri, 17 Apr 2009 13:57:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3HKwHNf004446; Fri, 17 Apr 2009 21:58:18 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3HKwFes004425; Fri, 17 Apr 2009 21:58:17 +0100 Message-ID: From: "Adrian Farrel" To: "Eric Gray" , "Lou Berger" , "BUSI ITALO" References: <001901c9bc0a$dc6fd060$6802a8c0@china.huawei.com><6FD21B53861BF44AA90A288402036AB402145621@FRVELSMBS21.ad2.ad.alcatel.com><49E5EEC8.6080101@labn.net> <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> Date: Fri, 17 Apr 2009 21:58:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 20:57:16 -0000 Thank you, Eric. Well captured. We should all note that the MPLS-TP requirements draft is not a set of requirements for things that must be implemented or deployed. It is a set of requirements for what protocol support must be specified. As you say, associated bidirectional transport paths might be used, so protocol support must be specified. But we should also observe that it is not necessary to provide the same level of function on an associated bidirectional LSP that we would provide on a corouted LSP. We can make that decision now. If there are somethings that are particularly hard to do with associated bidirectional LSPs, then perhaps we should observe that if you want that function you need to use a corouted LSP. Adrian ----- Original Message ----- From: "Eric Gray" To: "Lou Berger" ; "BUSI ITALO" Cc: Sent: Friday, April 17, 2009 7:15 PM Subject: Re: [mpls-tp] Associated bidirectional transport path requirements > Lou/Italo, > > This gets into a fuzzy language area. > > I think it should be clear that use of associated > (non-co-routed) > bi-directional paths is not required. It also seems to me to be clear > that they might be used; hence support for them is needed in protocols > and other specifications. > > We all need to be precise in what we mean by what is required, > and where it is required. > > -- > Eric > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Lou Berger > Sent: Wednesday, April 15, 2009 10:27 AM > To: BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Italo, > > On 4/14/2009 6:12 AM, BUSI ITALO wrote: >> 2) we need to be clear that asssociated bidirectional paths are not >> required in transport networks (e.g. MPLS-TP) >> > > This doesn't match draft-ietf-mpls-tp-requirements-06. Are you > proposing dropping associated bidirectional path from the TP > requirements document? > > Lou > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From xqwei@fiberhome.com.cn Fri Apr 17 23:09:15 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1753A6891 for ; Fri, 17 Apr 2009 23:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, MIME_BASE64_BLANKS=0.041, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWw0jMfRzMOw for ; Fri, 17 Apr 2009 23:09:14 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id AB8703A684A for ; Fri, 17 Apr 2009 23:09:11 -0700 (PDT) Received: from xqwei ([59.172.74.32]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Sat, 18 Apr 2009 14:05:57 +0800 Date: Sat, 18 Apr 2009 14:10:16 +0800 From: "=?utf-8?B?WHVlcWluIFdFSSAoU2h1ZXRzaW5nIFdFSSk=?=" To: "=?utf-8?B?U2hhaCwgSGltYW5zaHU=?=" References: , <6535C9CED6F87446B41D20EF170F23623161F0@mamxm01.ciena.com> Message-ID: <200904181410162814870@fiberhome.com.cn> Organization: =?utf-8?B?RmliZXJob21lIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ2llcyBDby4sTHRkLg==?= X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 18 Apr 2009 06:05:58.0019 (UTC) FILETIME=[BDDA4D30:01C9BFEB] Cc: =?utf-8?B?TVBMUy1UUA==?= Subject: Re: [mpls-tp] =?utf-8?q?Requirement_for_TCM_or_not=2E?= X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 06:09:15 -0000 KzEuDQpDb3VsZCB3ZSB1c2UgbmVzdGVkIExTUCB0byByZXBsYWNlIFRDTT8NCg0KU2luY2VyZWx5 IFlvdXJzDQpYdWVxaW4gV2VpIChTaHVldHNpbmcgV2VpKQ0KDQoyMDA5LTA0LTE4ICAxNDowODox NA0KDQo9PT09PT09PT09PT09PT09PT09PSBGb2xsb3dpbmcgaXMgeW91ciBlbWFpbD09PT09PT09 PT09PT09PT09PT09PQ0KU3ViamVjdDpSZTogW21wbHMtdHBdIFJlcXVpcmVtZW50IGZvciBUQ00g b3Igbm90Lg0KU2VudO+8mjIwMDktMDQtMTcgMDQ6MzY6NTcNCkZyb206U2hhaCwgSGltYW5zaHUN ClRvOkJlbiBOaXZlbi1KZW5raW5zOyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNo YXJvbik7IGV4dCBBbGV4YW5kZXIgVmFpbnNodGVpbg0KQ0MgdG86QlVTSSBJVEFMTzsgbXBscy10 cA0KDQo+SWYgSSBhbSBub3QgbWlzdGFrZW4sIHRoaXMgaXMgdGhlIHRoaXJkIGl0ZXJhdGlvbiBv ZiB0aGUNCj5kaXNjdXNzaW9uIGN5Y2xlIG9uIHRoaXMgc3ViamVjdCBtYXR0ZXIgKGVhY2ggd2l0 aA0KPmRpZmZlcmVudCBoZWFkaW5nKS4gQXMgdGhleSBzYXksIHRoaXJkIHRpbWUgaXMgYSBjaGFy bS4NCj4NCj5zZXJpb3VzbHkgdGhvdWdoLCBJIGFncmVlLiBMZXRzIHB1dCB0aGlzIGJlaGluZCB1 cyBpZiANCj50aGVyZSBpcyBubyAncmVhbCcgcmVxdWlyZW1lbnQgZm9yIGl0Lg0KPg0KPi9oaW1h bnNodQ0KPg0KPg0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbXBs cy10cC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBCZW4gTml2ZW4tSmVua2lucw0KPlNl bnQ6IFRodSA0LzE2LzIwMDkgNDoyMCBQTQ0KPlRvOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElM L0hvZCBIYVNoYXJvbik7IGV4dCBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPkNjOiBCVVNJIElUQUxP OyBtcGxzLXRwQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFttcGxzLXRwXSBSZXF1aXJlbWVudCBm b3IgVENNIG9yIG5vdC4NCj4gDQo+Q29sbGVhZ3VlcywNCj4NCj5PbiAxNi8wNC8yMDA5IDIxOjA1 LCAiU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pIg0KPj4gUmVnYXJkaW5n IHRoZSBmaXJzdCBvbmUsIGl0IHdhcyBhZ3JlZWQgdGhhdCB0aGUgTVBMUy1UUCBhZGRyZXNzZXMg dGhlDQo+PiB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIG9mIHRoZSBJVFUtVCBhbmQgYWRkaXRpb25h bCByZXF1aXJlbWVudHMgZnJvbQ0KPj4gU1BzLiANCj4+IFRoaXMgd2FzIG9uZSBvZiB0aGUgZmly c3Qgc2V0IG9mIHJlcXVpcmVtZW50cyB0aGUgSVRVLVQgYnJvdWdodCB0byB0aGUNCj4+IHdvcmsg YW5kIHdlIG5lZWQgdG8gYWRkcmVzcyBpdC4NCj4NCj5UaGlzIGRvZXMgcmFpc2UgYSBxdWVzdGlv biBpbiBteSBtaW5kIHRoYXQgZ29lcyBiYWNrIHRvIHNvbWV0aGluZyBJIGhhdmUNCj5zYWlkIGJl Zm9yZS4gSXMgVENNIGEgcmVxdWlyZW1lbnQgYmVjYXVzZSBpdCBpcyBhIHJlYWwgcmVxdWlyZW1l bnQgdGhhdA0KPm9wZXJhdG9ycyBhcmUgYXNraW5nIGZvciBvciBiZWNhdXNlIHdlIGFyZSByZWNy ZWF0aW5nIFNESC9TT05FVA0KPmZ1bmN0aW9uYWxpdHkgYmxpbmRseSB3aXRob3V0IGNvbnNpZGVy aW5nIGl0cyByZWxldmFuY2UgaW4gdGhlIHdvcmxkIHdlIG5vdw0KPmxpdmUgaW4/DQo+DQo+SSBh cHByZWNpYXRlIHRoYXQgdGhlcmUgYXJlIG1hbnkgb3BlcmF0b3JzIHdobyBkbyBub3QgcGFydGlj aXBhdGUgaW4NCj5zdGFuZGFyZHMsIGhvd2V2ZXIgaXQgd291bGQgYmUgbW9zdCB1c2VmdWwgaWYg anVzdCBvbmUgb3BlcmF0b3Igd2hvIHJlcXVpcmVzDQo+VENNIHdlcmUgdG8gc3RlcCBmb3J3YXJk IGFuZCBzYXkgc28uDQo+DQo+SSBhbSBub3QgYSBURE0gZXhwZXJ0IGJ1dCB3aGF0IG15IFRETSBl eHBlcnRzIHRlbGwgbWUgaXMgdGhhdCBUQ00gaGFzIGJlZW4NCj5kZXBsb3llZCBpbiB0aGUgcGFz dCBieSBzb21lIG9wZXJhdG9ycyAoSSBoYXZlIG5vIGlkZWEgb2YgaXRzIGN1cnJlbnQgc3RhdGUN Cj5vZiBkZXBsb3ltZW50IGV4Y2VwdCBpbiBCVCkgYnV0IHRoYXQgaXRzIHVzZSBpbiB0aGUgcGFz dCBjYW4gYmUgY29uc2lkZXJlZA0KPihpbiB0aGVpciBvcGluaW9uKSB0byBiZSBpbiB0aGUgbWlu b3JpdHkgb2YgZGVwbG95bWVudHMuDQo+DQo+SSBkbyB3b25kZXIgaWYgd2UgYXJlIHRoZXJlZm9y ZSBleHBlbmRpbmcgYSBsb3Qgb2YgZW5lcmd5IChhbmQgbGF0ZXIgb24gdGltZQ0KPmJvdGggaW4g c3RhbmRhcmRpc2F0aW9uIGFuZCBwb3NzaWJseSBkZXZlbG9wbWVudCBlZmZvcnQpIGZvciBhIGZ1 bmN0aW9uIHRoYXQNCj5tYXkgYmUgc2VsZG9tLCBpZiBldmVyLCB1c2VkLiBJdCB3b24ndCBiZSB0 aGUgZmlyc3QgdGltZSB3ZSBoYXZlDQo+c3RhbmRhcmRpc2VkIHNvbWV0aGluZyB0aGF0IGlzIHNl bGRvbSwgaWYgZXZlciwgdXNlZCBidXQgd2UgZG8gaGF2ZSBhbg0KPm9wcG9ydHVuaXR5IG5vdyB0 byB0YWtlIGEgc3RlcCBiYWNrIGFuZCBjb25zaWRlcjogaXMgVENNIHJlYWxseSByZXF1aXJlZCBh bmQNCj5pZiBpdCBpcyByZXF1aXJlZCwgaXMgaXQgYSBwcmlvcml0eSBpbiB0aGUgZGV2ZWxvcG1l bnQgb2YgTVBMUy1UUD8NCj4NCj5CZW4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPm1wbHMtdHAgbWFpbGluZyBsaXN0DQo+bXBscy10cEBp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0K Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+bXBscy10cCBtYWlsaW5nIGxpc3QNCj5tcGxzLXRwQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+DQoNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo= From xqwei@fiberhome.com.cn Fri Apr 17 23:51:27 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3633A69A4 for ; Fri, 17 Apr 2009 23:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.153 X-Spam-Level: * X-Spam-Status: No, score=1.153 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_05=-1.11, J_CHICKENPOX_24=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHUyPD2XiqE1 for ; Fri, 17 Apr 2009 23:51:27 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id 6364F3A690F for ; Fri, 17 Apr 2009 23:51:25 -0700 (PDT) Received: from xqwei ([59.172.74.32]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Sat, 18 Apr 2009 14:47:58 +0800 Date: Sat, 18 Apr 2009 14:52:17 +0800 From: "Xueqin WEI (Shuetsing WEI)" To: "Ben Niven-Jenkins" References: Message-ID: <200904181452174219225@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 18 Apr 2009 06:47:58.0582 (UTC) FILETIME=[9C39B160:01C9BFF1] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 06:51:27 -0000 U3VwcG9ydCwgSSB0aGluayB0aGUgbmVzdGVkIExTUCB3aWxsIGJlIGdyZWF0ISBVbnRpbCBub3cs IEkgZGlkbid0IHNlZSBhbnkgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBuZXN0ZWQgTFNQIGFuZCBU Q00gb24gcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4gQnV0IHRoZSBuZXN0ZWQgTFNQIHdpbGwgbWFr ZSB0aGUgdGhpbmdzIG1vcmUgZWFzeS4gSSB3b3VsZCBsaWtlIHNlbGVjdCBhIHNpbXBsZSB3YXkg dG8gcmVzb2x2ZSB0aGUgcHJvYmxlbS4NCg0KU2luY2VyZWx5IFlvdXJzDQpYdWVxaW4gV2VpIChT aHVldHNpbmcgV2VpKQ0KDQpGaWJlcmhvbWUgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9naWVz IENvLixMdGQuLA0KMjAwOS0wNC0xOCAgMTQ6NDg6NTENCg0KPT09PT09PT09PT09PT09PT09PT0g Rm9sbG93aW5nIGlzIHlvdXIgZW1haWw9PT09PT09PT09PT09PT09PT09PT0NClN1YmplY3Q6UmU6 IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOiBBc3NvY2lh dGVkYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQpTZW50o7oyMDA5 LTA0LTE3IDE3OjE3OjMxDQpGcm9tOkJlbiBOaXZlbi1KZW5raW5zDQpUbzpCVVNJIElUQUxPOyBB ZHJpYW4gRmFycmVsOyBBbGV4YW5kZXIgVmFpbnNodGVpbg0KQ0MgdG86bXBscy10cA0KDQo+SXRh bG8sDQo+DQo+T24gMTcvMDQvMjAwOSAwOTozNCwgIkJVU0kgSVRBTE8iIDxJdGFsby5CdXNpQGFs Y2F0ZWwtbHVjZW50Lml0PiB3cm90ZToNCj4+IFRoZSBKV1QgYWdyZWVtZW50IGlzIHRvIGJyaW5n IHRoZSBJVFUtVCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGluIElFVEYNCj4+IHRvIGV4dGVuZCB0 aGUgTVBMUyBhcmNoaXRlY3R1cmUgdG8gbWVldCB0aGVtIGluIGEgd2F5IHRoYXQgaXMNCj4+IGNv bXBhdGlibGUsIGNvbnNpc3RlbnQgYW5kIGNvaGVyZW50IHdpdGggZXhpc3RpbmcgSUVURiBhcmNo aXRlY3R1cmUuDQo+DQo+U28gSSB0b29rIGEgbG9vayBhdCB0aGUgSldUIHJlcG9ydC4gSXQgc2F5 cyAoc2xpZGUgMTYpDQo+DQo+IiBTZXJ2aWNlIFByb3ZpZGVycyB3YW50IExTUHMvUFdFcyB0byBi ZSBhYmxlIHRvIGJlIG1hbmFnZWQgYXQgdGhlIGRpZmZlcmVudA0KPm5lc3RlZCBsZXZlbHMgc2Vh bWxlc3NseSAocGF0aCwgc2VnbWVudCwgbXVsdGlwbGUgc2VnbWVudHMpDQo+ICAgIGFrYSBUYW5k ZW0gQ29ubmVjdGlvbiBNb25pdG9yaW5nIChUQ00pLCB0aGlzIGlzIHVzZWQgZm9yIGV4YW1wbGUg d2hlbiBhDQo+TFNQL1BXRSBjcm9zc2VzIG11bHRpcGxlIGFkbWluaXN0cmF0aW9ucyINCj4NCj5J TU8gdGhlIHJlcXVpcmVtZW50IGlzIHRvIGJlIGFibGUgdG8gbW9uaXRvciBwYXJ0cyBvZiBhIHBh dGggYXMgd2VsbCBhcyB0aGUNCj5lbmQgdG8gZW5kIHBhdGguIFRoZXJlIGFyZSBtYW55IHdheXMg dG8gc29sdmUgdGhhdCByZXF1aXJlbWVudCwgb25lIG9mIHdoaWNoDQo+aXMgdGhlIGNyZWF0aW9u IG9mIG5lc3RlZCBMU1BzLCBvbmUgcGVyIGxldmVsIG9mIG1vbml0b3JpbmcgcmVxdWlyZWQgKG15 DQo+dW5kZXJzdGFuZGluZyBvZiBob3cgVENNIHdvcmtzKS4NCj4NCj5JIHRoaW5rIHRoZSByZWFs IGRpc2N1c3Npb24gaXMgdGhlcmVmb3JlIGlzIHRoZSByZXF1aXJlbWVudCB0byBtb25pdG9yDQo+ ZGlmZmVyZW50IGNvbXBvbmVudHMgb2YgYW4gZW5kIHRvIGVuZCBwYXRoIG9yIGlzIHRoZSByZXF1 aXJlbWVudCB0aGF0IHN1Y2gNCj5tb25pdG9yaW5nIE1VU1QgYmUgYWNoaWV2ZWQgdXNpbmcgbmVz dGVkIExTUHM/DQo+DQo+QXMgYW4gZXhhbXBsZSBQVyB0ZWNobm9sb2d5IHRvZGF5IGFsbG93cyBl bmQgdG8gZW5kIGFuZCBwZXIgc2VnbWVudA0KPm1vbml0b3JpbmcgYnV0IGl0IGRvZXMgbm90IGFj aGlldmUgaXQgdXNpbmcgbmVzdGVkIFBXcyBvciBQVyBsZXZlbHMuDQo+DQo+QmVuDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tcGxzLXRwIG1h aWxpbmcgbGlzdA0KPm1wbHMtdHBAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHANCj4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg== From maarten.vissers@huawei.com Sat Apr 18 10:19:07 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7C13A6E3D for ; Sat, 18 Apr 2009 10:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5azGPw-K5pw for ; Sat, 18 Apr 2009 10:19:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AC4B03A6E48 for ; Sat, 18 Apr 2009 10:19:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIB00A8O45UQ1@szxga03-in.huawei.com> for mpls-tp@ietf.org; Sun, 19 Apr 2009 01:20:18 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIB002L045U38@szxga03-in.huawei.com> for mpls-tp@ietf.org; Sun, 19 Apr 2009 01:20:18 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIB00LGG45M77@szxml01-in.huawei.com>; Sun, 19 Apr 2009 01:20:18 +0800 (CST) Date: Sat, 18 Apr 2009 19:20:12 +0200 From: Maarten Vissers In-reply-to: <200904181452174219225@fiberhome.com.cn> To: xqwei@fiberhome.com.cn Message-id: <001001c9c049$f3509560$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Thread-index: Acm/8k9J3/iDMF7NTs6dhn0tyFGmUwAV1zBQ Cc: 'MPLS-TP' Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 17:19:07 -0000 Xueqin, The nested LSP is a more complex solution then TCM. TCM just requires the activation of some MEPs in the LSP. Nested LSP requires to set up the same MEP functions plus set up an additional LSP and change the existing LSP. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Xueqin WEI (Shuetsing WEI) Sent: zaterdag 18 april 2009 8:52 To: Ben Niven-Jenkins Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) Support, I think the nested LSP will be great! Until now, I didn't see any difference between the nested LSP and TCM on performance monitoring. But the nested LSP will make the things more easy. I would like select a simple way to resolve the problem. Sincerely Yours Xueqin Wei (Shuetsing Wei) Fiberhome Telecommunication Technologies Co.,Ltd., 2009-04-18 14:48:51 ==================== Following is your email===================== Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) Sent：2009-04-17 17:17:31 From:Ben Niven-Jenkins To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp >Italo, > >On 17/04/2009 09:34, "BUSI ITALO" wrote: >> The JWT agreement is to bring the ITU-T transport requirements in >> IETF to extend the MPLS architecture to meet them in a way that is >> compatible, consistent and coherent with existing IETF architecture. > >So I took a look at the JWT report. It says (slide 16) > >" Service Providers want LSPs/PWEs to be able to be managed at the >different nested levels seamlessly (path, segment, multiple segments) > aka Tandem Connection Monitoring (TCM), this is used for example >when a LSP/PWE crosses multiple administrations" > >IMO the requirement is to be able to monitor parts of a path as well as >the end to end path. There are many ways to solve that requirement, one >of which is the creation of nested LSPs, one per level of monitoring >required (my understanding of how TCM works). > >I think the real discussion is therefore is the requirement to monitor >different components of an end to end path or is the requirement that >such monitoring MUST be achieved using nested LSPs? > >As an example PW technology today allows end to end and per segment >monitoring but it does not achieve it using nested PWs or PW levels. > >Ben > >_______________________________________________ >mpls-tp mailing list >mpls-tp@ietf.org >https://www.ietf.org/mailman/listinfo/mpls-tp > ================================================================= _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From John.E.Drake2@boeing.com Sat Apr 18 14:00:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC72D28C15D for ; Sat, 18 Apr 2009 14:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ordqrxx+vk6 for ; Sat, 18 Apr 2009 14:00:11 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id E146A28C1C0 for ; Sat, 18 Apr 2009 14:00:10 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3IL16QT019328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 18 Apr 2009 14:01:06 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3IL15nU013525; Sat, 18 Apr 2009 16:01:05 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3IL159E013520; Sat, 18 Apr 2009 16:01:05 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 18 Apr 2009 14:01:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 18 Apr 2009 14:01:05 -0700 Message-ID: <51661468CBD1354294533DA79E85955A605BB0@XCH-SW-5V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Thread-Index: Acm/8k9J3/iDMF7NTs6dhn0tyFGmUwAV1zBQAAfHZTc= From: "Drake, John E" To: , X-OriginalArrivalTime: 18 Apr 2009 21:01:05.0078 (UTC) FILETIME=[C9C12560:01C9C068] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 21:00:12 -0000 TWFhcnRlbiwNCg0KSXRhbG8gY2xhaW1zIFRDTSBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQg b2YgRy44MDUuICBZb3UgY2xhaW0gaXQgaXMgYSBtb3JlIGVmZmljaWVudCBzb2x1dGlvbiB0byBz b21ldGhpbmcsIEknbSBub3Qgc3VyZSB3aGF0LCB0aGFuIExTUCBoaWVyYXJjaHkuICBJIGFtIGJl Z2lubmluZyB0byBzdXNwZWN0IHRoYXQgVENNIGlzIGEgZGVzZXJ0IHRvcHBpbmcgYW5kIGEgZmxv b3Igd2F4Lg0KDQpUaGFua3MsDQoNCkpvaG4NCkpvaG4gRHJha2UNCkJvZWluZyBTYXRlbGxpdGUg U3lzdGVtcw0KMjI2MCBFYXN0IEltcGVyaWFsIEhpZ2h3YXkgTUMgVy1TMDUtUDIwOA0KRWwgU2Vn dW5kbywgQ0EgOTAyNDUNCmpvaG4uZS5kcmFrZTJAYm9laW5nLmNvbQ0KKDQxMikgMzcwLTMxMDgN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogTWFhcnRlbiBWaXNzZXJzIDxt YWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbT4NClRvOiB4cXdlaUBmaWJlcmhvbWUuY29tLmNuIDx4 cXdlaUBmaWJlcmhvbWUuY29tLmNuPg0KQ2M6ICdNUExTLVRQJyA8bXBscy10cEBpZXRmLm9yZz4N ClNlbnQ6IFNhdCBBcHIgMTggMTA6MjA6MTIgMjAwOQ0KU3ViamVjdDogUmU6IFttcGxzLXRwXSBU YW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzUkU6QXNzb2NpYXRlZGJpZGlyZWN0aW9u YWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQpYdWVxaW4sDQoNClRoZSBuZXN0ZWQg TFNQIGlzIGEgbW9yZSBjb21wbGV4IHNvbHV0aW9uIHRoZW4gVENNLiBUQ00ganVzdCByZXF1aXJl cyB0aGUNCmFjdGl2YXRpb24gb2Ygc29tZSBNRVBzIGluIHRoZSBMU1AuIE5lc3RlZCBMU1AgcmVx dWlyZXMgdG8gc2V0IHVwIHRoZSBzYW1lDQpNRVAgZnVuY3Rpb25zIHBsdXMgc2V0IHVwIGFuIGFk ZGl0aW9uYWwgTFNQIGFuZCBjaGFuZ2UgdGhlIGV4aXN0aW5nIExTUC4NCg0KUmVnYXJkcywNCk1h YXJ0ZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQpP ZiBYdWVxaW4gV0VJIChTaHVldHNpbmcgV0VJKQ0KU2VudDogemF0ZXJkYWcgMTggYXByaWwgMjAw OSA4OjUyDQpUbzogQmVuIE5pdmVuLUplbmtpbnMNCkNjOiBNUExTLVRQDQpTdWJqZWN0OiBSZTog W21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMNClJFOkFzc29jaWF0 ZWRiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCg0KU3VwcG9ydCwg SSB0aGluayB0aGUgbmVzdGVkIExTUCB3aWxsIGJlIGdyZWF0ISBVbnRpbCBub3csIEkgZGlkbid0 IHNlZSBhbnkNCmRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmVzdGVkIExTUCBhbmQgVENNIG9uIHBl cmZvcm1hbmNlIG1vbml0b3JpbmcuIEJ1dCB0aGUNCm5lc3RlZCBMU1Agd2lsbCBtYWtlIHRoZSB0 aGluZ3MgbW9yZSBlYXN5LiBJIHdvdWxkIGxpa2Ugc2VsZWN0IGEgc2ltcGxlIHdheQ0KdG8gcmVz b2x2ZSB0aGUgcHJvYmxlbS4NCg0KU2luY2VyZWx5IFlvdXJzDQpYdWVxaW4gV2VpIChTaHVldHNp bmcgV2VpKQ0KDQpGaWJlcmhvbWUgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9naWVzIENvLixM dGQuLA0KMjAwOS0wNC0xOCAgMTQ6NDg6NTENCg0KPT09PT09PT09PT09PT09PT09PT0gRm9sbG93 aW5nIGlzIHlvdXIgZW1haWw9PT09PT09PT09PT09PT09PT09PT0NClN1YmplY3Q6UmU6IFttcGxz LXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOg0KQXNzb2NpYXRlZGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KU2VudO+8mjIwMDktMDQt MTcgMTc6MTc6MzENCkZyb206QmVuIE5pdmVuLUplbmtpbnMNClRvOkJVU0kgSVRBTE87IEFkcmlh biBGYXJyZWw7IEFsZXhhbmRlciBWYWluc2h0ZWluIENDIHRvOm1wbHMtdHANCg0KPkl0YWxvLA0K Pg0KPk9uIDE3LzA0LzIwMDkgMDk6MzQsICJCVVNJIElUQUxPIiA8SXRhbG8uQnVzaUBhbGNhdGVs LWx1Y2VudC5pdD4gd3JvdGU6DQo+PiBUaGUgSldUIGFncmVlbWVudCBpcyB0byBicmluZyB0aGUg SVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBpbiANCj4+IElFVEYgdG8gZXh0ZW5kIHRoZSBN UExTIGFyY2hpdGVjdHVyZSB0byBtZWV0IHRoZW0gaW4gYSB3YXkgdGhhdCBpcyANCj4+IGNvbXBh dGlibGUsIGNvbnNpc3RlbnQgYW5kIGNvaGVyZW50IHdpdGggZXhpc3RpbmcgSUVURiBhcmNoaXRl Y3R1cmUuDQo+DQo+U28gSSB0b29rIGEgbG9vayBhdCB0aGUgSldUIHJlcG9ydC4gSXQgc2F5cyAo c2xpZGUgMTYpDQo+DQo+IiBTZXJ2aWNlIFByb3ZpZGVycyB3YW50IExTUHMvUFdFcyB0byBiZSBh YmxlIHRvIGJlIG1hbmFnZWQgYXQgdGhlIA0KPmRpZmZlcmVudCBuZXN0ZWQgbGV2ZWxzIHNlYW1s ZXNzbHkgKHBhdGgsIHNlZ21lbnQsIG11bHRpcGxlIHNlZ21lbnRzKQ0KPiAgICBha2EgVGFuZGVt IENvbm5lY3Rpb24gTW9uaXRvcmluZyAoVENNKSwgdGhpcyBpcyB1c2VkIGZvciBleGFtcGxlIA0K PndoZW4gYSBMU1AvUFdFIGNyb3NzZXMgbXVsdGlwbGUgYWRtaW5pc3RyYXRpb25zIg0KPg0KPklN TyB0aGUgcmVxdWlyZW1lbnQgaXMgdG8gYmUgYWJsZSB0byBtb25pdG9yIHBhcnRzIG9mIGEgcGF0 aCBhcyB3ZWxsIGFzIA0KPnRoZSBlbmQgdG8gZW5kIHBhdGguIFRoZXJlIGFyZSBtYW55IHdheXMg dG8gc29sdmUgdGhhdCByZXF1aXJlbWVudCwgb25lIA0KPm9mIHdoaWNoIGlzIHRoZSBjcmVhdGlv biBvZiBuZXN0ZWQgTFNQcywgb25lIHBlciBsZXZlbCBvZiBtb25pdG9yaW5nIA0KPnJlcXVpcmVk IChteSB1bmRlcnN0YW5kaW5nIG9mIGhvdyBUQ00gd29ya3MpLg0KPg0KPkkgdGhpbmsgdGhlIHJl YWwgZGlzY3Vzc2lvbiBpcyB0aGVyZWZvcmUgaXMgdGhlIHJlcXVpcmVtZW50IHRvIG1vbml0b3Ig DQo+ZGlmZmVyZW50IGNvbXBvbmVudHMgb2YgYW4gZW5kIHRvIGVuZCBwYXRoIG9yIGlzIHRoZSBy ZXF1aXJlbWVudCB0aGF0IA0KPnN1Y2ggbW9uaXRvcmluZyBNVVNUIGJlIGFjaGlldmVkIHVzaW5n IG5lc3RlZCBMU1BzPw0KPg0KPkFzIGFuIGV4YW1wbGUgUFcgdGVjaG5vbG9neSB0b2RheSBhbGxv d3MgZW5kIHRvIGVuZCBhbmQgcGVyIHNlZ21lbnQgDQo+bW9uaXRvcmluZyBidXQgaXQgZG9lcyBu b3QgYWNoaWV2ZSBpdCB1c2luZyBuZXN0ZWQgUFdzIG9yIFBXIGxldmVscy4NCj4NCj5CZW4NCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm1wbHMt dHAgbWFpbGluZyBsaXN0DQo+bXBscy10cEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQpt cGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMtdHANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg== From hhelvoort@chello.nl Sat Apr 18 14:17:26 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D31A3A6C6B for ; Sat, 18 Apr 2009 14:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.211 X-Spam-Level: X-Spam-Status: No, score=-0.211 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_24=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHc4P7pE2oUo for ; Sat, 18 Apr 2009 14:17:25 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id D2C833A6B21 for ; Sat, 18 Apr 2009 14:17:24 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090418211837.SYPP10095.viefep16-int.chello.at@edge02.upc.biz>; Sat, 18 Apr 2009 23:18:37 +0200 Received: from McAsterix.local ([216.9.106.100]) by edge02.upc.biz with edge id h9JW1b04G29zQ8w029JYiv; Sat, 18 Apr 2009 23:18:37 +0200 X-SourceIP: 216.9.106.100 Message-ID: <49EA43A4.7050701@chello.nl> Date: Sat, 18 Apr 2009 23:18:28 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Drake, John E" References: <51661468CBD1354294533DA79E85955A605BB0@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <51661468CBD1354294533DA79E85955A605BB0@XCH-SW-5V2.sw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 21:17:26 -0000 Hi John, You wrote: > Italo claims TCM is a functional requirement of G.805. > You claim it is a more efficient solution to something, > I'm not sure what, than LSP hierarchy. I am beginning to > suspect that TCM is a desert topping and a floor wax. Do you mean it is a tool that serves two purposes. In that case it minimizes the toolset. Cheers, Huub. > ----- Original Message ----- > From: Maarten Vissers > To: xqwei@fiberhome.com.cn > Cc: 'MPLS-TP' > Sent: Sat Apr 18 10:20:12 2009 > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) > > Xueqin, > > The nested LSP is a more complex solution then TCM. TCM just requires the > activation of some MEPs in the LSP. Nested LSP requires to set up the same > MEP functions plus set up an additional LSP and change the existing LSP. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Xueqin WEI (Shuetsing WEI) > Sent: zaterdag 18 april 2009 8:52 > To: Ben Niven-Jenkins > Cc: MPLS-TP > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was > RE:Associatedbidirectional transport path requirements) > > Support, I think the nested LSP will be great! Until now, I didn't see any > difference between the nested LSP and TCM on performance monitoring. But the > nested LSP will make the things more easy. I would like select a simple way > to resolve the problem. > > Sincerely Yours > Xueqin Wei (Shuetsing Wei) > > Fiberhome Telecommunication Technologies Co.,Ltd., > 2009-04-18 14:48:51 > > ==================== Following is your email===================== > Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: > Associatedbidirectional transport path requirements) > Sent��2009-04-17 17:17:31 > From:Ben Niven-Jenkins > To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp > >> Italo, >> >> On 17/04/2009 09:34, "BUSI ITALO" wrote: >>> The JWT agreement is to bring the ITU-T transport requirements in >>> IETF to extend the MPLS architecture to meet them in a way that is >>> compatible, consistent and coherent with existing IETF architecture. >> So I took a look at the JWT report. It says (slide 16) >> >> " Service Providers want LSPs/PWEs to be able to be managed at the >> different nested levels seamlessly (path, segment, multiple segments) >> aka Tandem Connection Monitoring (TCM), this is used for example >> when a LSP/PWE crosses multiple administrations" >> >> IMO the requirement is to be able to monitor parts of a path as well as >> the end to end path. There are many ways to solve that requirement, one >> of which is the creation of nested LSPs, one per level of monitoring >> required (my understanding of how TCM works). >> >> I think the real discussion is therefore is the requirement to monitor >> different components of an end to end path or is the requirement that >> such monitoring MUST be achieved using nested LSPs? >> >> As an example PW technology today allows end to end and per segment >> monitoring but it does not achieve it using nested PWs or PW levels. >> >> Ben >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > > ================================================================= > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From benjamin.niven-jenkins@bt.com Sat Apr 18 15:41:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D843A6867 for ; Sat, 18 Apr 2009 15:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FALSY05jgRS for ; Sat, 18 Apr 2009 15:41:08 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id ED0C028C1F7 for ; Sat, 18 Apr 2009 15:40:36 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 18 Apr 2009 23:41:50 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Sat, 18 Apr 2009 22:41:50 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 18 Apr 2009 23:41:48 +0100 From: Ben Niven-Jenkins To: BUSI ITALO , Annamaria Fulignoli , VIGOUREUX MARTIN Message-ID: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0ACB4nIAA7e5w0 In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Apr 2009 22:41:50.0639 (UTC) FILETIME=[DD308BF0:01C9C076] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 22:41:09 -0000 Italo, On 17/04/2009 19:20, "BUSI ITALO" wrote: > Ben, > > TCM is an architectural construct well defined in G.805 in a > technology-independent manner. As such TCM does not imply any specific > solution. > > The solution we are working on to implement TCM within MPLS-TP is based on the > JWT agreement and described in the OAM Framework document. > > I do not think we should drop a requirement because of people's > misunderstandings. See my mail from Friday which I have copied below. I do not believe I am suggesting removal of requirements but that we describe the requirements without reference to what appears to be a somewhat controversial term. As Adrian has repeatedly stated what is important is we accurately capture the functional requirements. Given that neither the MPLS-TP requirements nor the MPLS-TP OAM requirements documents use the term TCM when describing the requirements I think this aim is thoroughly achievable without dropping any requirements. That way we can close this issue IMO. Ben > From: Benjamin Niven-Jenkins > Date: Fri, 17 Apr 2009 11:04:17 +0100 > To: BUSI ITALO , Adrian Farrel > , Alexander Vainshtein > Cc: > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated > bidirectional transport path requirements) > > Italo, > > I think we are converging. If I can be so bold as to speak on his behalf > Adrian's objection seemed to be to the use of the term TCM. > > It is defined in the MPLS-TP requirements but not used. > > It is not used in the MPLS-TP OAM requirements document. > > Therefore I think the way forward is as follows: > > 1) Remove the term Tandem Connection from the MPLS-TP requirements as it is > redundant (i.e. Not used in that document). > > 2) Ensure the MPLS-TP OAM requirements express the necessary functional > requirements around monitoring of end to end paths as well as parts of end > to end paths. This can be done without referring explicitly to Tandem > Connections. > > When it comes to solution design we can decide what is the best mechanism to > achieve/implement those requirements be it LSP hierarchy or something else. > The JWT has proved that it is possible to meet those requirements using > existing MPLS technology (maybe with some enhancements). I do not believe we > have to necessarily use the solution they propose aslong as whatever > solution we ultimately decide upon meets all the necessary requirements > expressed. > > Can we agree on that as an approach and close this off for now? > > Ben From neil.2.harrison@bt.com Sun Apr 19 00:22:06 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8D7328C175 for ; Sun, 19 Apr 2009 00:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk1f4+Mo4dGk for ; Sun, 19 Apr 2009 00:22:05 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 2EC643A6EAF for ; Sun, 19 Apr 2009 00:22:04 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Apr 2009 08:23:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 19 Apr 2009 08:23:14 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C046FFF51@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <49EA43A4.7050701@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) thread-index: AcnAa0CBMmRlnKFhRhe3hYfFYPghxwAT+4Qw From: To: , X-OriginalArrivalTime: 19 Apr 2009 07:23:18.0846 (UTC) FILETIME=[B66A0DE0:01C9C0BF] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 07:22:06 -0000 SSB0aGluayBpdOKAmXMgYSB0b29sIEh1dWIgdGhhdCBpcyB1bm5jZXNzYXJ5IGFuZCBjcmVhdGVz IGNvbXBsaWNhdGlvbnMvY29zdHMgZm9yIG5vIGdvb2QgcmVhc29uLi4uLmp1c3QgbGlrZSBwZWVy IGludGVyd29ya2luZyBvZiBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmtzIGRvZXMgdG9vLiAgSSBo YXZlIGFscmVhZHkgZXhwbGFpbmVkIHdoeSBCVCBkb2VzIG5vdCB3YW50IHRvIHdhc3RlIG91ciB0 aW1lL21vbmV5IG9uIHRoZXNlIHRvcGljcywgYnV0IEkgd2lsbCBoYXBwaWx5IGdvIG92ZXIgdGhl IGxvZ2ljIGFzIG1hbnkgdGltZXMgYXMgaXQgdGFrZXMgZm9yIG91ciBzdXBwbGllcnMgdG8gZ3Jh c3AgdGhpcy4NCg0KSW4gdGhlIG1lYW50aW1lIGhhdmUgYSB0aGluayBhYm91dCB0aGVzZSBxdWVz dGlvbnM6DQoNCkhvdyBjb21lIHRoZSBJbnRlcm5ldCBoYXMgZG9uZSBncmVhdCB3aXRob3V0IGl0 Li4uYW5kIEkgZG9uJ3Qgc2VlIElFVEYgYXNraW5nIGZvciBpdD8NCkhvdyBjb21lIHRoZSBQU1RO IGhhcyBkb25lIGdyZWF0IHdpdGhvdXQgaXQ/DQpIb3cgY29tZSBvdXIgT3BzIGd1eXMgYXJlIG5v dCBhc2tpbmcgZm9yIGl0IC4uLi5lc3AgZ2l2ZW4gdGhlIFRDTSBpZGVhIGhhcyBiZWVuIGFyb3Vu ZCBmb3IgYSB2ZXJ5IGxvbmcgdGltZT8gDQoNCkkgdGhpbmsgdGhpcyBpcyBtb3JlIG9mIGEgam9i L3dvcmsgY3JlYXRpb24gc2NoZW1lIGJhc2VkIG9uIGEgZmxhd2VkIHZpc2lvbiBvZiB3aGVyZSBu ZXR3b3JraW5nIG5lZWRzIHRvIGdvLiAgSWYgeW91IHJlYWxseSB3YW50IHRvIGNyZWF0ZSBhIGdv b2QgdmlzaW9uIGZvciBmdXR1cmUgbmV0d29ya2luZyBkaXJlY3Rpb24geW91IG11c3Qgc3RhcnQg d2l0aCB0aGUgcGh5c2ljcyB0aGF0IEcuODAwIGxheXMgZG93biAoYmVjYXVzZSB0aGVzZSBhcmUg dGhlIHJlYWwgdHJ1dGhzIGJhc2VkIG9uIGEgc29saWQgdW5kZXJwaW5uaW5nIG9mIEluZm8vU3lz dGVtcyBUaGVvcnkgb2YgbmV0d29ya2luZykgY291cGxlZCB3aXRoIHRoZSByZXF1aXJlbWVudHMg b2YgcmVhbCBleHRlcm5hbCBjdXN0b21lcnMvdXNlcnMgb2YgbmV0d29ya3MuDQoNCldoZW4geW91 IGRvIHRoYXQgeW91IGZpbmQgdGhhdCAzIG1ham9yIG5ldHdvcmtpbmcgcGxhbmtzIGVtZXJnZToN Ci0JdGhlcmUgYXJlIDMgbmV0d29yayBtb2Rlcy4uLi5hbmQgdGhleSBhcmUgKm5vdCogdGhlIHNh bWUuLi5lYWNoIHByb3ZpZGVzIHNvbWV0aGluZyBkaWZmZXJlbnQuLi4uc28gYSBuZXR3b3JraW5n IHBoaWxvc29waHkgdGhhdCBkb2VzIG5vdCByZWNvZ25pc2UvdW5kZXJzdGFuZCB0aGlzIGFuZCBp bnN0ZWFkIHNlZWtzIHRvIChpKSBibGluZGx5IGFwcGx5IHRoZSBzYW1lIGZ1bmMgY29tcG9uZW50 cyB0byBlYWNoIChEUCBPQU0gaXMgb25seSBvbmUgY29tcG9uZW50KSBhbmQgKGlpKSB0cmllcyB0 byBpbnRlcndvcmsgdGhlbSBhcyBwZWVycywgaXMganVzdCBwbGFpbiB3cm9uZy4NCi0JZXh0ZXJu YWwgYXBwbGljYXRpb25zIGdlbmVyYXRlIDMgZGlzdGluY3QgdHlwZXMgb2YgaW5mb3JtYXRpb24u Li5tZXNzYWdlcywgZmlsZXMgYW5kIHN0cmVhbXMuLi4uLi5hbmQgd2hpbHN0IHRoZWlyIFFvUyAo PT1kZWxheSkgcmVxdWlyZW1lbnRzIGFyZSBnZW5lcmFsbHkgZml4ZWQvaW52YXJpYW50IHBlciBp bmZvcm1hdGlvbiBzb3VyY2UgdHlwZSB0aGVpciBzdXJ2aXZhYmlsaXR5IGltcG9ydGFuY2UgY2Fu IGFzc3VtZSBhbnkgdmFsdWUgaW4gYW55IGluZm9ybWF0aW9uIHNvdXJjZSB0eXBlLg0KLQl0aGVy ZSBhcmUgMiBsYXllciBuZXR3b3JrIHJlbGF0aW9uc2hpcHMuLi4uY2xpZW50L3NlcnZlciBhbmQg cGVlci1wYXJ0aXRpb24uLi4udGhlIGZvcm1lciBpcyBieSBmYXIgdGhlIG1vc3QgY29tbW9uL2lt cG9ydGFudCAoZXNwIGZvciBwcml2YXRlICduZXR3b3JrIGJ1aWxkZXInIHNlcnZpY2VzKSB3aGls c3QgdGhlIGxhdHRlciBpcyBvbmx5IGltcG9ydGFudCBmb3IgdG9wLW9mLXN0YWNrIG5ldHdvcmtz IHRoYXQgc3VwcG9ydCB0aGUgZXh0ZXJuYWwgYXBwbGljYXRpb25zIChlc3AgaW4gYSBwdWJsaWMg c2VydmljZSBjb250ZXh0KS4NCg0KU28gaWYgeW91IGRvbid0IGhhdmUgYSBuZXR3b3JraW5nIHZp c2lvbiB0aGF0IGZhY3RvcnMtaW4gYWxsIHRoZXNlIHRoaW5ncyB0aGVuIHlvdSBkb24ndCBhY3R1 YWxseSBoYXZlIGEgdXNlZnVsIHZpc2lvbiBhdCBhbGwuLi4uLmluZGVlZCBzdWNoIGEgdmlzaW9u IGlzIGNvbnNwaWN1b3VzbHkgYWJzZW50IGluIHdoYXQgSSBzZWUgc29tZSBmb2xrcyBwdXNoaW5n IGZvci4NCg0KcmVnYXJkcywgTmVpbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCj4gW21haWx0bzptcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIdXViIHZhbiBIZWx2b29ydA0KPiBTZW50OiAxOCBB cHJpbCAyMDA5IDIyOjE4DQo+IFRvOiBEcmFrZSwgSm9obiBFDQo+IENjOiBtcGxzLXRwQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMt VFAgDQo+ICh3YXNSRTpBc3NvY2lhdGVkYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1 aXJlbWVudHMpDQo+IA0KPiBIaSBKb2huLA0KPiANCj4gWW91IHdyb3RlOg0KPiANCj4gPiBJdGFs byBjbGFpbXMgVENNIGlzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudCBvZiBHLjgwNS4NCj4gID4g WW91IGNsYWltIGl0IGlzIGEgbW9yZSBlZmZpY2llbnQgc29sdXRpb24gdG8gc29tZXRoaW5nLA0K PiAgPiBJJ20gbm90IHN1cmUgd2hhdCwgdGhhbiBMU1AgaGllcmFyY2h5LiAgSSBhbSBiZWdpbm5p bmcgdG8NCj4gID4gc3VzcGVjdCB0aGF0IFRDTSBpcyBhIGRlc2VydCB0b3BwaW5nIGFuZCBhIGZs b29yIHdheC4NCj4gDQo+IERvIHlvdSBtZWFuIGl0IGlzIGEgdG9vbCB0aGF0IHNlcnZlcyB0d28g cHVycG9zZXMuDQo+IEluIHRoYXQgY2FzZSBpdCBtaW5pbWl6ZXMgdGhlIHRvb2xzZXQuDQo+IA0K PiBDaGVlcnMsIEh1dWIuDQo+IA0KPiANCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t DQo+ID4gRnJvbTogTWFhcnRlbiBWaXNzZXJzIDxtYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbT4N Cj4gPiBUbzogeHF3ZWlAZmliZXJob21lLmNvbS5jbiA8eHF3ZWlAZmliZXJob21lLmNvbS5jbj4N Cj4gPiBDYzogJ01QTFMtVFAnIDxtcGxzLXRwQGlldGYub3JnPg0KPiA+IFNlbnQ6IFNhdCBBcHIg MTggMTA6MjA6MTIgMjAwOQ0KPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5l Y3Rpb25zIGluIE1QTFMtVFAgDQo+ICh3YXNSRTpBc3NvY2lhdGVkYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQo+ID4gDQo+ID4gWHVlcWluLA0KPiA+IA0KPiA+IFRo ZSBuZXN0ZWQgTFNQIGlzIGEgbW9yZSBjb21wbGV4IHNvbHV0aW9uIHRoZW4gVENNLiBUQ00gDQo+ IGp1c3QgcmVxdWlyZXMgdGhlDQo+ID4gYWN0aXZhdGlvbiBvZiBzb21lIE1FUHMgaW4gdGhlIExT UC4gTmVzdGVkIExTUCByZXF1aXJlcyB0byANCj4gc2V0IHVwIHRoZSBzYW1lDQo+ID4gTUVQIGZ1 bmN0aW9ucyBwbHVzIHNldCB1cCBhbiBhZGRpdGlvbmFsIExTUCBhbmQgY2hhbmdlIHRoZSANCj4g ZXhpc3RpbmcgTFNQLg0KPiA+IA0KPiA+IFJlZ2FyZHMsDQo+ID4gTWFhcnRlbg0KPiA+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGll dGYub3JnIA0KPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ ID4gT2YgWHVlcWluIFdFSSAoU2h1ZXRzaW5nIFdFSSkNCj4gPiBTZW50OiB6YXRlcmRhZyAxOCBh cHJpbCAyMDA5IDg6NTINCj4gPiBUbzogQmVuIE5pdmVuLUplbmtpbnMNCj4gPiBDYzogTVBMUy1U UA0KPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMt VFAgKHdhcw0KPiA+IFJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJl cXVpcmVtZW50cykNCj4gPiANCj4gPiBTdXBwb3J0LCBJIHRoaW5rIHRoZSBuZXN0ZWQgTFNQIHdp bGwgYmUgZ3JlYXQhIFVudGlsIG5vdywgSSANCj4gZGlkbid0IHNlZSBhbnkNCj4gPiBkaWZmZXJl bmNlIGJldHdlZW4gdGhlIG5lc3RlZCBMU1AgYW5kIFRDTSBvbiBwZXJmb3JtYW5jZSANCj4gbW9u aXRvcmluZy4gQnV0IHRoZQ0KPiA+IG5lc3RlZCBMU1Agd2lsbCBtYWtlIHRoZSB0aGluZ3MgbW9y ZSBlYXN5LiBJIHdvdWxkIGxpa2UgDQo+IHNlbGVjdCBhIHNpbXBsZSB3YXkNCj4gPiB0byByZXNv bHZlIHRoZSBwcm9ibGVtLg0KPiA+IA0KPiA+IFNpbmNlcmVseSBZb3Vycw0KPiA+IFh1ZXFpbiBX ZWkgKFNodWV0c2luZyBXZWkpDQo+ID4gDQo+ID4gRmliZXJob21lIFRlbGVjb21tdW5pY2F0aW9u IFRlY2hub2xvZ2llcyBDby4sTHRkLiwNCj4gPiAyMDA5LTA0LTE4ICAxNDo0ODo1MQ0KPiA+IA0K PiA+ID09PT09PT09PT09PT09PT09PT09IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09 PT09PT09PT09PT09DQo+ID4gU3ViamVjdDpSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9u cyBpbiBNUExTLVRQICh3YXMgUkU6DQo+ID4gQXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KPiA+IFNlbnTvvJoyMDA5LTA0LTE3IDE3OjE3OjMxDQo+ ID4gRnJvbTpCZW4gTml2ZW4tSmVua2lucw0KPiA+IFRvOkJVU0kgSVRBTE87IEFkcmlhbiBGYXJy ZWw7IEFsZXhhbmRlciBWYWluc2h0ZWluIENDIHRvOm1wbHMtdHANCj4gPiANCj4gPj4gSXRhbG8s DQo+ID4+DQo+ID4+IE9uIDE3LzA0LzIwMDkgMDk6MzQsICJCVVNJIElUQUxPIiANCj4gPEl0YWxv LkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+IHdyb3RlOg0KPiA+Pj4gVGhlIEpXVCBhZ3JlZW1lbnQg aXMgdG8gYnJpbmcgdGhlIElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMgaW4gDQo+ID4+PiBJ RVRGIHRvIGV4dGVuZCB0aGUgTVBMUyBhcmNoaXRlY3R1cmUgdG8gbWVldCB0aGVtIGluIGEgDQo+ IHdheSB0aGF0IGlzIA0KPiA+Pj4gY29tcGF0aWJsZSwgY29uc2lzdGVudCBhbmQgY29oZXJlbnQg d2l0aCBleGlzdGluZyBJRVRGIA0KPiBhcmNoaXRlY3R1cmUuDQo+ID4+IFNvIEkgdG9vayBhIGxv b2sgYXQgdGhlIEpXVCByZXBvcnQuIEl0IHNheXMgKHNsaWRlIDE2KQ0KPiA+Pg0KPiA+PiAiIFNl cnZpY2UgUHJvdmlkZXJzIHdhbnQgTFNQcy9QV0VzIHRvIGJlIGFibGUgdG8gYmUgbWFuYWdlZCBh dCB0aGUgDQo+ID4+IGRpZmZlcmVudCBuZXN0ZWQgbGV2ZWxzIHNlYW1sZXNzbHkgKHBhdGgsIHNl Z21lbnQsIA0KPiBtdWx0aXBsZSBzZWdtZW50cykNCj4gPj4gICAgYWthIFRhbmRlbSBDb25uZWN0 aW9uIE1vbml0b3JpbmcgKFRDTSksIHRoaXMgaXMgdXNlZCANCj4gZm9yIGV4YW1wbGUgDQo+ID4+ IHdoZW4gYSBMU1AvUFdFIGNyb3NzZXMgbXVsdGlwbGUgYWRtaW5pc3RyYXRpb25zIg0KPiA+Pg0K PiA+PiBJTU8gdGhlIHJlcXVpcmVtZW50IGlzIHRvIGJlIGFibGUgdG8gbW9uaXRvciBwYXJ0cyBv ZiBhIA0KPiBwYXRoIGFzIHdlbGwgYXMgDQo+ID4+IHRoZSBlbmQgdG8gZW5kIHBhdGguIFRoZXJl IGFyZSBtYW55IHdheXMgdG8gc29sdmUgdGhhdCANCj4gcmVxdWlyZW1lbnQsIG9uZSANCj4gPj4g b2Ygd2hpY2ggaXMgdGhlIGNyZWF0aW9uIG9mIG5lc3RlZCBMU1BzLCBvbmUgcGVyIGxldmVsIG9m IA0KPiBtb25pdG9yaW5nIA0KPiA+PiByZXF1aXJlZCAobXkgdW5kZXJzdGFuZGluZyBvZiBob3cg VENNIHdvcmtzKS4NCj4gPj4NCj4gPj4gSSB0aGluayB0aGUgcmVhbCBkaXNjdXNzaW9uIGlzIHRo ZXJlZm9yZSBpcyB0aGUgDQo+IHJlcXVpcmVtZW50IHRvIG1vbml0b3IgDQo+ID4+IGRpZmZlcmVu dCBjb21wb25lbnRzIG9mIGFuIGVuZCB0byBlbmQgcGF0aCBvciBpcyB0aGUgDQo+IHJlcXVpcmVt ZW50IHRoYXQgDQo+ID4+IHN1Y2ggbW9uaXRvcmluZyBNVVNUIGJlIGFjaGlldmVkIHVzaW5nIG5l c3RlZCBMU1BzPw0KPiA+Pg0KPiA+PiBBcyBhbiBleGFtcGxlIFBXIHRlY2hub2xvZ3kgdG9kYXkg YWxsb3dzIGVuZCB0byBlbmQgYW5kIA0KPiBwZXIgc2VnbWVudCANCj4gPj4gbW9uaXRvcmluZyBi dXQgaXQgZG9lcyBub3QgYWNoaWV2ZSBpdCB1c2luZyBuZXN0ZWQgUFdzIG9yIA0KPiBQVyBsZXZl bHMuDQo+ID4+DQo+ID4+IEJlbg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+PiBt cGxzLXRwQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscy10cA0KPiA+Pg0KPiA+IA0KPiA+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtcGxzLXRwIG1haWxpbmcgbGlz dA0KPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMtdHANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+ID4gbXBscy10 cEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzLXRwQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+IA0KPiAtLSANCj4g PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy52YW4taGVsdm9vcnQuZXUv DQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj4gQWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFyZSB1bmlxdWUuLi5qdXN0 IGxpa2UgZXZlcnlvbmUgZWxzZS4uLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiBtcGxzLXRwQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiAN Cg== From nurit.sprecher@nsn.com Sun Apr 19 02:13:02 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7337C3A67B4 for ; Sun, 19 Apr 2009 02:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZUUiPsTeShT for ; Sun, 19 Apr 2009 02:13:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E898E3A6F09 for ; Sun, 19 Apr 2009 02:13:00 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3J9ECMj020483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 19 Apr 2009 11:14:12 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3J9ECam001752; Sun, 19 Apr 2009 11:14:12 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Apr 2009 11:14:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 19 Apr 2009 11:14:11 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326490DDB2@DEMUEXC014.nsn-intra.net> In-Reply-To: <49E86497.6080702@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Thread-Index: Acm/TbcgXDo4VMLpTPWTLe4ZpOdxOwBBP62A References: <49E86497.6080702@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , "Ben Niven-Jenkins" X-OriginalArrivalTime: 19 Apr 2009 09:14:11.0654 (UTC) FILETIME=[33CBFE60:01C9C0CF] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 09:13:02 -0000 Hi, I think we already have a requirement to manage and monitor the network at different nested levels (end-to-end, segment, link, etc.) and this should be satisfactory.=20 TCM or whatever is used to solve it should appear in the architecture document.=20 Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Friday, April 17, 2009 2:15 PM To: Ben Niven-Jenkins Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) Ben, this would work for me /Loa Ben Niven-Jenkins wrote: > Italo, >=20 > I think we are converging. If I can be so bold as to speak on his behalf > Adrian's objection seemed to be to the use of the term TCM. >=20 > It is defined in the MPLS-TP requirements but not used. >=20 > It is not used in the MPLS-TP OAM requirements document. >=20 > Therefore I think the way forward is as follows: >=20 > 1) Remove the term Tandem Connection from the MPLS-TP requirements as it is > redundant (i.e. Not used in that document). >=20 > 2) Ensure the MPLS-TP OAM requirements express the necessary functional > requirements around monitoring of end to end paths as well as parts of end > to end paths. This can be done without referring explicitly to Tandem > Connections. >=20 > When it comes to solution design we can decide what is the best mechanism to > achieve/implement those requirements be it LSP hierarchy or something else. > The JWT has proved that it is possible to meet those requirements using > existing MPLS technology (maybe with some enhancements). I do not believe we > have to necessarily use the solution they propose aslong as whatever > solution we ultimately decide upon meets all the necessary requirements > expressed. >=20 > Can we agree on that as an approach and close this off for now? >=20 > Ben >=20 >=20 > On 17/04/2009 10:49, "BUSI ITALO" wrote: >=20 >> Ben, >> >> I think we are mixing solutions with requirements. >> >> The requirement for the TCM function is clearly defined and I do think >> it must be addressed by the MPLS-TP design. >> >> The solution evaluated by the JWT to meet this requirement was to use >> label stacking with a 1:1 relationship between the TCM LSP and the e2e >> LSP. >> >> I think this solution, although not the best technical option, is good >> enough and meets the requirements. >> >> However this is is a solution and has not impact on the requirement. >> >> Italo >> >>> -----Original Message----- >>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>> Sent: Friday, April 17, 2009 11:22 AM >>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>> Cc: mpls-tp@ietf.org; Lou Berger >>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>> Associated bidirectional transport path requirements) >>> >>> Italo, >>> >>> On 17/04/2009 09:34, "BUSI ITALO" >>> wrote: >>>> The JWT agreement is to bring the ITU-T transport >>> requirements in IETF >>>> to extend the MPLS architecture to meet them in a way that is >>>> compatible, consistent and coherent with existing IETF architecture. >>> So I took a look at the JWT report. It says (slide 16) >>> >>> " Service Providers want LSPs/PWEs to be able to be managed >>> at the different >>> nested levels seamlessly (path, segment, multiple segments) >>> aka Tandem Connection Monitoring (TCM), this is used for >>> example when a >>> LSP/PWE crosses multiple administrations" >>> >>> IMO the requirement is to be able to monitor parts of a path >>> as well as the >>> end to end path. There are many ways to solve that >>> requirement, one of which >>> is the creation of nested LSPs, one per level of monitoring >>> required (my >>> understanding of how TCM works). >>> >>> I think the real discussion is therefore is the requirement to monitor >>> different components of an end to end path or is the >>> requirement that such >>> monitoring MUST be achieved using nested LSPs? >>> >>> As an example PW technology today allows end to end and per segment >>> monitoring but it does not achieve it using nested PWs or PW levels. >>> >>> Ben >>> >>> >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp --=20 Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13=20 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From nurit.sprecher@nsn.com Sun Apr 19 02:13:07 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF8F3A6BF4 for ; Sun, 19 Apr 2009 02:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.481 X-Spam-Level: X-Spam-Status: No, score=-5.481 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsVVaqD8CjOS for ; Sun, 19 Apr 2009 02:13:06 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E20043A67B4 for ; Sun, 19 Apr 2009 02:13:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3J9EAh7020453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 19 Apr 2009 11:14:10 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3J9EAPn001738; Sun, 19 Apr 2009 11:14:10 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Apr 2009 11:14:09 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 19 Apr 2009 11:14:09 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326490DDB0@DEMUEXC014.nsn-intra.net> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) Thread-Index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0ACB4nIAAyEq0Q References: <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext BUSI ITALO" , "Ben Niven-Jenkins" , "Annamaria Fulignoli" , "VIGOUREUX MARTIN" X-OriginalArrivalTime: 19 Apr 2009 09:14:09.0994 (UTC) FILETIME=[32CEB2A0:01C9C0CF] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 09:13:07 -0000 Hi, As a functional element, it should be described in the architecture = document. In the requirement draft we have the requirement to manage the paths at = different nested levels. Best regards, Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of ext BUSI ITALO Sent: Friday, April 17, 2009 9:21 PM To: Ben Niven-Jenkins; Annamaria Fulignoli; VIGOUREUX MARTIN Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: = Associatedbidirectional transport path requirements) Ben, TCM is an architectural construct well defined in G.805 in a = technology-independent manner. As such TCM does not imply any specific = solution. The solution we are working on to implement TCM within MPLS-TP is based = on the JWT agreement and described in the OAM Framework document. I do not think we should drop a requirement because of people's = misunderstandings. Italo > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Friday, April 17, 2009 4:26 PM > To: Annamaria Fulignoli; VIGOUREUX MARTIN > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > Associated bidirectional transport path requirements) >=20 > Because IMO use of the term TCM tends to make people think of=20 > a particular > solution and what we want to do at this stage is express the=20 > functional > requirements and not imply any particular solution. >=20 > Certainly most of my mails in this thread (and I am probably=20 > not the only > one) have been based on the fact that when discussing TCM I assume a > particular solution is being discussed. Talking purely in terms of > functional requirements removes that ambiguity. >=20 > Ben >=20 >=20 > On 17/04/2009 12:51, "Annamaria Fulignoli" > wrote: >=20 > > Hi all, > > sorry but I do not understand why we cannot explicitly use=20 > the term Tandem > > Connection in the requirements document! > > TCM is not a solution, it is part of functional=20 > architecture of a transport > > networks as described in G.805. The solution is to realize=20 > it with label > > stacking rather than MEL. > >=20 > > Regards > > Annamaria > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > Martin Vigoureux > > Sent: venerd=EC 17 aprile 2009 13.29 > > To: Ben Niven-Jenkins > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE: Associated > > bidirectional transport path requirements) > >=20 > > Ben, all > >=20 > > in mpls-tp-oam-requirement, the text on this item is as follows: > >=20 > > The service emulated by a single segment or a=20 > multi-segment PW may > > span multiple domains. A LSP may also span multiple=20 > domains. It > > MUST be possible to perform OAM functions on a per=20 > domain basis and > > across multiple domains. More generally it MUST be possible to > > perform OAM functions between any two switching=20 > elements (e.g., LSR > > or S-PE) of a LSP or of PW. This is referred to as=20 > (concatenated) > > segment monitoring. > >=20 > > I believe the text describes a functional req. > >=20 > > During mead team review, the removal of the last sentence=20 > was discussed. > > No strong opinion was expressed on whether it should=20 > effectively be removed or > > not. > >=20 > > regards, > > martin > >=20 > > Ben Niven-Jenkins a =E9crit : > >> Italo, > >>=20 > >> I think we are converging. If I can be so bold as to speak on his > >> behalf Adrian's objection seemed to be to the use of the term TCM. > >>=20 > >> It is defined in the MPLS-TP requirements but not used. > >>=20 > >> It is not used in the MPLS-TP OAM requirements document. > >>=20 > >> Therefore I think the way forward is as follows: > >>=20 > >> 1) Remove the term Tandem Connection from the MPLS-TP=20 > requirements as > >> it is redundant (i.e. Not used in that document). > >>=20 > >> 2) Ensure the MPLS-TP OAM requirements express the necessary > >> functional requirements around monitoring of end to end=20 > paths as well > >> as parts of end to end paths. This can be done without referring > >> explicitly to Tandem Connections. > >>=20 > >> When it comes to solution design we can decide what is the best > >> mechanism to achieve/implement those requirements be it=20 > LSP hierarchy or > >> something else. > >> The JWT has proved that it is possible to meet those requirements > >> using existing MPLS technology (maybe with some enhancements). I do > >> not believe we have to necessarily use the solution they propose > >> aslong as whatever solution we ultimately decide upon meets all the > >> necessary requirements expressed. > >>=20 > >> Can we agree on that as an approach and close this off for now? > >>=20 > >> Ben > >>=20 > >>=20 > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > wrote: > >>=20 > >>> Ben, > >>>=20 > >>> I think we are mixing solutions with requirements. > >>>=20 > >>> The requirement for the TCM function is clearly defined and I do > >>> think it must be addressed by the MPLS-TP design. > >>>=20 > >>> The solution evaluated by the JWT to meet this=20 > requirement was to use > >>> label stacking with a 1:1 relationship between the TCM LSP and the > >>> e2e LSP. > >>>=20 > >>> I think this solution, although not the best technical option, is > >>> good enough and meets the requirements. > >>>=20 > >>> However this is is a solution and has not impact on the=20 > requirement. > >>>=20 > >>> Italo > >>>=20 > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>>> Sent: Friday, April 17, 2009 11:22 AM > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > >>>> Cc: mpls-tp@ietf.org; Lou Berger > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] > >>>> Associated bidirectional transport path requirements) > >>>>=20 > >>>> Italo, > >>>>=20 > >>>> On 17/04/2009 09:34, "BUSI ITALO" > >>>> wrote: > >>>>> The JWT agreement is to bring the ITU-T transport > >>>> requirements in IETF > >>>>> to extend the MPLS architecture to meet them in a way that is > >>>>> compatible, consistent and coherent with existing IETF=20 > architecture. > >>>> So I took a look at the JWT report. It says (slide 16) > >>>>=20 > >>>> " Service Providers want LSPs/PWEs to be able to be=20 > managed at the > >>>> different nested levels seamlessly (path, segment, multiple > >>>> segments) > >>>> aka Tandem Connection Monitoring (TCM), this is used=20 > for example > >>>> when a LSP/PWE crosses multiple administrations" > >>>>=20 > >>>> IMO the requirement is to be able to monitor parts of a=20 > path as well > >>>> as the end to end path. There are many ways to solve that > >>>> requirement, one of which is the creation of nested LSPs, one per > >>>> level of monitoring required (my understanding of how TCM works). > >>>>=20 > >>>> I think the real discussion is therefore is the requirement to > >>>> monitor different components of an end to end path or is the > >>>> requirement that such monitoring MUST be achieved using=20 > nested LSPs? > >>>>=20 > >>>> As an example PW technology today allows end to end and=20 > per segment > >>>> monitoring but it does not achieve it using nested PWs=20 > or PW levels. > >>>>=20 > >>>> Ben > >>>>=20 > >>>>=20 > >>=20 > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > >>=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From liu.guoman@zte.com.cn Sun Apr 19 18:03:01 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4299B3A6B7F for ; Sun, 19 Apr 2009 18:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.56 X-Spam-Level: X-Spam-Status: No, score=-97.56 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qck8Qq8UA-Zn for ; Sun, 19 Apr 2009 18:02:59 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BA1723A6AF4 for ; Sun, 19 Apr 2009 18:02:56 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Mon, 20 Apr 2009 08:56:56 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 90033.1275772506; Mon, 20 Apr 2009 09:00:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3K12cBo049516; Mon, 20 Apr 2009 09:02:38 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <49E88A21.9060309@labn.net> To: Lou Berger MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 20 Apr 2009 09:00:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-20 09:02:36, Serialize complete at 2009-04-20 09:02:36 Content-Type: multipart/alternative; boundary="=_alternative 0005BAA44825759E_=" X-MAIL: mse2.zte.com.cn n3K12cBo049516 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 01:03:01 -0000 This is a multipart message in MIME format. --=_alternative 0005BAA44825759E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 bG91Og0KICAgIGJlY2F1c2UgVGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkIGRpcmVjdGlvbnMgYXJl IHNldHVwLCBtb25pdG9yZWQgYW5kIA0KcHJvdGVjdGVkIGluZGVwZW5kZW50IGluIHRoZSBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMuIGl0IGNhbid0IA0KZW5zdXJlIGFuZCByZWFsaXpl IHRoZSBzeW1tZXRyaWMgYmFuZHdpZHRoIGluIHR3byBkaXJlY3Rpb25hbCBwYXRoLg0Kb3IgZWxz ZSAsIEkgTVVTVCByZXZpc2UgdGhlIGRlZmluaXRpb25zIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCBwYXRocyANCmluIG1wbHMtdHAgcmVxdWlyZW1lbnRzIGRyYWZ0Lg0KDQpyZWdhcmRzDQps aXUgDQoNCg0KDQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiANCjIwMDktMDQtMTcgMjE6 NTQNCg0KytW8/sjLDQpsaXUuZ3VvbWFuQHp0ZS5jb20uY24NCrOty80NCkJlbiBOaXZlbi1KZW5r aW5zIDxiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbT4sIG1wbHMtdHBAaWV0Zi5vcmcNCtb3 zOINClJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo IHJlcXVpcmVtZW50cw0KDQoNCg0KDQoNCg0KTGl1LA0KICAgICAgICAgICAgICAgICBXaHkgaXNu J3QgaXQgbmVjZXNzYXJ5IGZvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgDQpwYXRocz8gIElz IGl0IHRoYXQNCmFzeW1tZXRyaWMgaXMgdGhlIHNvbGUgcmVxdWlyZW1lbnQ/ICBJZiBub3QsIEkg ZG9uJ3QgdW5kZXJzdGFuZCB5b3VyDQpjb21tZW50Lg0KDQpMb3UNCg0KT24gNC8xNi8yMDA5IDk6 MTUgUE0sIGxpdS5ndW9tYW5AenRlLmNvbS5jbiB3cm90ZToNCj4gDQo+IExvdToNCj4gSSBhZ3Jl ZSB5b3VyIGFkdmljZSwgYnV0IGZvciBzeW1tZXRyaWMgYmFuZHdpZHRoIHJlcXVpcmVtZW50LCBJ IHRoaW5rIA0KPiB0aGUgcmVxdWlyZW1lbnQgY2FuIG9ubHkgYmUgZml0IGZvciBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgDQo+IHBhdGhzLCB3aGlsZSBpdCBpc24ndCBuZWNlc3Nh cnkgZm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyAuc28gDQo+IGFkZGluZyBhICJj by1yb3V0ZWQiIHdvcmQgaW4gdGhlIHJlcXVpcmVtZW50IDMzIGlzIG5lY2Vzc2FyeS4NCj4gdGhh bmsgeW91Lg0KPiBsaXUNCj4gDQo+IA0KPiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4q DQo+ILeivP7IyzogbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQo+IA0KPiAyMDA5LTA0LTE2IDIx OjQzDQo+IA0KPiANCj4gytW8/sjLDQo+ICAgICAgICAgICAgICAgIEJlbiBOaXZlbi1KZW5raW5z IDxiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbT4NCj4gs63LzQ0KPiAgICAgICAgICAgICAg ICBCVVNJQGNvcmUzLmFtc2wuY29tLCAibXBscy10cEBpZXRmLm9yZyIgDQo8bXBscy10cEBpZXRm Lm9yZz4sIElUQUxPIA0KPiA8SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdD4NCj4g1vfM4g0K PiAgICAgICAgICAgICAgICBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0 cmFuc3BvcnQgcGF0aCANCnJlcXVpcmVtZW50cw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IEJlbiwNCj4gSXQgc2VlbXMgdG8gbWUgdGhhdCBtdWNoIG9mIHRoZSBkaXNjdXNzaW9u IHN0ZW1zIGZyb20gdGhlIHNlY3Rpb24gaW4NCj4gd2hpY2ggdGhlc2UgcmVxdWlyZW1lbnRzIGFy ZSBsaXN0ZWQuDQo+IA0KPiBSZXF1aXJlbWVudCAzMiBpcyBhIHNlcnZpY2UgbGV2ZWwgcmVxdWly ZW1lbnQgYW5kIHByaW1hcmlseSBpbXBhY3QgdGhlDQo+IG1hbmFnZW1lbnQgYW5kIGNvbnRyb2wg cGxhbmVzLiBBcyB0aGVyZSBpcyBubyBzZWN0aW9uIGRlc2NyaWJpbmcNCj4gc2VydmljZSByZXF1 aXJlbWVudHMsIEkgc3VnZ2VzdCBtb3ZpbmcgdGhpcyByZXF1aXJlbWVudCB0byBmb2xsb3cNCj4g cmVxdWlyZW1lbnQgNiwgYW5kIGFkZGluZyB0aGUgZm9sbG93aW5nIGluIGl0cyBwbGFjZToNCj4g MzMgTVBMUy1UUCBNVVNUIHN1cHBvcnQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aHMgd2l0 aA0KPiBzeW1tZXRyaWMgYmFuZHdpZHRoIHJlcXVpcmVtZW50cywgaS5lLiB0aGUgYW1vdW50IG9m IHJlc2VydmVkDQo+IGJhbmR3aWR0aCBpcyB0aGUgc2FtZSBiZXR3ZWVuIHRoZSBmb3J3YXJkIGFu ZCBiYWNrd2FyZA0KPiBkaXJlY3Rpb25zLg0KPiANCj4gV2hpbGUgdGhpcyB0b28gaXMgYSBzZXJ2 aWNlIHJlcXVpcmVtZW50IGFuZCBkb2Vzbid0IHJlcXVpcmUgYW55IGhhcmR3YXJlDQo+IG1vZGlm aWNhdGlvbnMsIGl0IHBhcmFsbGVscyBjdXJyZW50IHJlcXVpcmVtZW50cyAzNywgNDAgYW5kIDQx LiBJdCBhbHNvDQo+IG1ha2VzIGEgY3VycmVudGx5IGltcGxpY2l0IHJlcXVpcmVtZW50IGV4cGxp Y2l0Lg0KPiANCj4gUmVxdWlyZW1lbnRzIDMzLTI2IHJlbGF0ZSB0byAiYXdhcmVuZXNzIiBzaG91 bGQgaGF2ZSBubyBpbXBsaWNhdGlvbiBvbg0KPiB0aGUgZGF0YS9mb3J3YXJkaW5nIHBsYW5lIGFu ZCBhcmUgSU1PIGJvdGggbWFuYWdlbWVudCBhbmQgY29udHJvbCBwbGFuZQ0KPiByZXF1aXJlbWVu dHMuIChBbmQgeWVzLCB0aGV5IGhhdmUgaW1wbGljYXRpb25zIG9uIE9BTSBhbmQgcmVjb3Zlcnku KSBJDQo+IHRoaW5rIEFkcmlhbiByYWlzZXMgYSBnb29kIHBvaW50IFdSVCB0aGVzZSByZXF1aXJl bWVudHMsIGkuZS4sIGFyZSB0aGVzZQ0KPiByZXF1aXJlbWVudHMgbGlzdGVkIGFzIHNvbHV0aW9u cyB0byBzb21lIHVubGlzdGVkIHJlcXVpcmVtZW50cy4gSWYgc28sDQo+IHRoZSB1bmxpc3RlZCBy ZXF1aXJlbWVudHMgc2hvdWxkIGJlIGluY2x1ZGVkIGFuZCB0aGVzZSBzaG91bGQgYmUNCj4gZHJv cHBlZC4gSWYgbm90LCBzbyBiZSBpdCwgYnV0IHRoZXkgc2hvdWxkIGJlIG1vdmVkIGZyb20gc2Vj dGlvbiAyLjMuDQo+IA0KPiBXaGlsZSBJJ20gc3VyZSB0aGlzIHdvbid0IGVuZCB0aGUgZGlzY3Vz c2lvbiwgSSB0aGluayB0aGVzZSBjaGFuZ2VzIHdpbGwNCj4gaGVscCBtYWtlICJ0aGUgcmVxdWly ZW1lbnRzIGNsZWFyIGVub3VnaCAuLi4iDQo+IA0KPiBMb3UNCj4gDQo+IE9uIDQvMTYvMjAwOSA1 OjU4IEFNLCBCZW4gTml2ZW4tSmVua2lucyB3cm90ZToNCj4gID4gQ29sbGVhZ3VlcywNCj4gID4N Cj4gID4gSSBjYW4ndCBoZWxwIGJ1dCBmZWVsIHdlIGFyZSBvdmVyYW5hbHlzaW5nIHRoaW5ncyBo ZXJlLiBIb3cgbWFueQ0KPiAgPiB0ZWNobm9sb2dpZXMvcHJvdG9jb2xzL21lY2hhbmlzbXMgaGF2 ZSB3ZSBzdWNjZXNzZnVsbHkgZGVmaW5lZCBpbiANCj4gYm90aCBJRVRGDQo+ICA+ICYgSVRVLVQg d2l0aG91dCB0aGlzIGxldmVsIG9mIGFuYWx5c2lzIG9mIHRoZSBpbml0aWFsIHJlcXVpcmVtZW50 cyAtIA0KPiBhIGdyZWF0DQo+ICA+IG1hbnkgKGEgZ29vZCBjaHVuayBvZiB3aGljaCB3ZXJlIGV4 dHJlbWVseSBzdWNjZXNzZnVsKS4NCj4gID4NCj4gID4gVGhlIHJlcXVpcmVtZW50cyBkb2N1bWVu dCBpcyBub3QgYWJvdXQgc3BlY2lmeWluZyBzb2x1dGlvbnMuDQo+ICA+DQo+ICA+IFRoZSBrZXkg cXVlc3Rpb24gaXM6IGFyZSB0aGUgcmVxdWlyZW1lbnRzIGNsZWFyIGVub3VnaCB0aGF0IGl0IGlz IA0KPiB1bmRlcnN0b29kDQo+ICA+IHdoYXQgaXMgcmVxdWlyZWQgc28gc29tZW9uZSBjb3VsZCBi dWlsZCBhIGJveC9wcm90b2NvbC93aGF0ZXZlciB0byANCm1lZXQNCj4gID4gdGhlbT8NCj4gID4N Cj4gID4gSWYgd2Ugd2FudCB0byBnbyBpbnRvIHRoZSBudGggbGV2ZWwgb2YgZGV0YWlsIG9uIGVh Y2ggcmVxdWlyZW1lbnQgd2UgDQp3aWxsDQo+ICA+IHN0aWxsIGJlIGRlYmF0aW5nIHRoaXMgYnkg dGhlIHRpbWUgSSByZXRpcmUgKHdoaWNoIGlzbid0IGR1ZSB1bnRpbCANCjIwNDUpLg0KPiAgPg0K PiAgPiBCZW4NCj4gID4NCj4gID4NCj4gID4gT24gMTYvMDQvMjAwOSAwODowNCwgIkFsZXhhbmRl ciBWYWluc2h0ZWluIg0KPiAgPiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+IHdy b3RlOg0KPiAgPg0KPiAgPj4gQWRyaWFuLA0KPiAgPj4gVGhhbmsgeW91IGZvciBhIHByb21wdCBh bmQgZGV0YWlsZWQgcmVzcG9uc2UuDQo+ICA+Pg0KPiAgPj4gVW5mb3J0dW5hdGVseSBJIGNhbm5v dCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50Og0KPiAgPj4NCj4gID4+IDxxdW90ZT4N Cj4gID4+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCBiaWRp cmVjdGlvbmFsIExTUHMNCj4gID4+IGFyZSBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgTFNQcy4NCj4gID4+IDxlbmQgcXVvdGU+DQo+ICA+Pg0KPiAgPj4gVGhpcyBz dGF0ZW1lbnQgd291bGQgYmUgb2J2aW91c2x5IGNvcnJlY3QsIHdlcmUgaXQgbm90IGZvciANCj4g UmVxdWlyZW1lbnQgMzQgaW4NCj4gID4+IHRoZSBsYXRlc3QNCj4gID4+IE1QTFMtVFAgcmVxdWly ZW1lbnRzIGRyYWZ0DQo+ICA+PiANCj4gKA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXJlcXVpcmVtZW50cy0wNi50eHQNCik6DQo+ICA+Pg0K PiAgPj4gPHF1b3RlPg0KPiAgPj4gVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1F UHMsIE1JUHMgYW5kIG90aGVyIGludGVybmFsDQo+ICA+PiBmdW5jdGlvbnMgYXMgYXBwcm9wcmlh dGUpIG9mIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ICA+PiBwYXRoIGF0 IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KPiAgPj4gcmVs YXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQgZGlyZWN0aW9ucyBvZiB0 aGF0DQo+ICA+PiB0cmFuc3BvcnQgcGF0aC4NCj4gID4+IDxlbmQgcXVvdGU+DQo+ICA+Pg0KPiAg Pj4gUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRo ZSBsaXN0IHRoYXQgaXMgDQoNCj4gc3BlY2lmaWMNCj4gID4+IGZvciBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1BzLiAoVGhlIHBhaXJpbmcgcmVxdWlyZW1lbnRzIGF0IGVuZCANCj4gcG9pbnRz DQo+ICA+PiBmb3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMg YXJlIGV4YWN0bHkgdGhlIA0KPiBzYW1lIGV2ZW4NCj4gID4+IGlmIHRoZXkgYXBwZWFyIGluIHR3 byBkaWZmZXJlbnQgaXRlbXMgaW4gdGhlIHJlcXVpcmVtZW50cycgbGlzdCkuDQo+ICA+PiBJbiBv dGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mIGNvLXJvdXRl ZCANCj4gYmlkaXJlY3Rpb25hbA0KPiAgPj4gcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0 YSBwbGFuZSBjb250ZW50Lg0KPiAgPj4NCj4gID4+IFRoZSBzb21ld2hhdCB2YWd1ZSBzY29wZSBv ZiB0aGlzIHJlcXVpcmVtZW50ICgib3RoZXIgaW50ZXJuYWwgDQpmdW5jdGlvbnMNCj4gID4+IGFz IGFwcHJvcHJpYXRlIikgY3JlYXRlcyBhIHN1c3BpY2lvbiB0aGF0IEhXIHN1cHBvcnQgb2YgdGhl IHBhaXJpbmcgDQo+IGF3YXJlbmVzcw0KPiAgPj4gbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRv IGNvbXBseSB3aXRoIGl0Lg0KPiAgPj4NCj4gID4+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUg ZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KPiAgPj4NCj4gID4+IDxxdW90ZT4NCj4g ID4+IFRhbmRlbSBDb25uZWN0aW9uOiBBIHRhbmRlbSBjb25uZWN0aW9uIGlzIGFuIGFyYml0cmFy eSBwYXJ0IG9mIGENCj4gID4+IHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAo dmlhIE9BTSkgaW5kZXBlbmRlbnRseSBmcm9tIA0KdGhlDQo+ICA+PiBlbmQtdG8tZW5kIG1vbml0 b3JpbmcgKE9BTSkuIEl0IG1heSBiZSBhIG1vbml0b3JlZCBzZWdtZW50IG9yIGENCj4gID4+IG1v bml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIHRyYW5zcG9ydCBwYXRoLiBUaGUgdGFu ZGVtDQo+ICA+PiBjb25uZWN0aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRpbmcgZW5n aW5lKHMpIG9mIHRoZSBub2RlKHMpDQo+ICA+PiBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVu dCBvciBjb25jYXRlbmF0ZWQgc2VnbWVudC4NCj4gID4+IDxlbmQgcXVvdGU+DQo+ICA+Pg0KPiAg Pj4gRG9lc24ndCAiZm9yd2FyZGluZyBlbmdpbmUiIHNvdW5kIGxpa2UgaGFyZHdhcmUgdG8geW91 Pw0KPiAgPj4NCj4gID4+IElNSE8gaXQgaXMgd29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUg TVBMUy1UUCBSZXF1aXJlbWVudHMgZHJhZnQNCj4gID4+IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVx dWlyZW1lbnRzIG9uZQ0KPiAgPj4gDQo+ICgNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVxdWlyZW1lbnRzLTAxLnR4DQoNCj4gID4+ IHQpDQo+ICA+PiBjb250YWluIGFueSByZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoIHRhbmRlbSBj b25uZWN0aW9ucy4NCj4gID4+DQo+ICA+PiBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNj dXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNIEZyYW1ld29yayANCmRyYWZ0DQo+ICA+PiANCj4gKA0K aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9h bS1mcmFtZXdvcmstMDAudHh0DQopLg0KPiAgPj4NCj4gID4+IFRoZSBib3R0b20gbGluZSwgSU1I TywgaXMgdGhhdCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nIGNvLXJvdXRlZCB2cy4gDQo+IGFzc29j aWF0ZWQNCj4gID4+IGJpZGlyZWN0aW9uYWwNCj4gID4+IHBhdGhzIGlzIHN0aWxsIHJlcXVpcmVk LiBPbmUgd2F5IHRvIHByb3ZpZGUgdGhhdCBjb3VsZCBiZSBieSANCmV4cGxpY2l0bHkNCj4gID4+ IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0DQo+ICA+PiB0byBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5 Lg0KPiAgPj4NCj4gID4+IE15IDJjLA0KPiAgPj4gU2FzaGENCj4gID4+DQo+ICA+Pg0KPiAgPj4N Cj4gID4+DQo+ICA+Pg0KPiAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAgPj4gRnJvbTogQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a10NCj4g ID4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTQ0KPiAgPj4gVG86IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPDQo+ICA+PiBDYzogbXBs cy10cEBpZXRmLm9yZw0KPiAgPj4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+IHJlcXVpcmVtZW50cw0KPiAgPj4NCj4gID4+ IEhpIFNhc2hhLA0KPiAgPj4NCj4gID4+IE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUg bWlzcmVwcmVzZW50aW5nIGFueW9uZSwgYnV0Li4uDQo+ICA+Pg0KPiAgPj4+IDEuIE15IHJlYWRp bmcgb2Ygb25lIG9mIEJlbidzIG1lc3NhZ2VzIGlzIHRoYXQgYXNzb2NpYXRlZA0KPiAgPj4+IGJp ZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBvbmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQgY2FuIGJl DQo+ICA+Pj4gY3JlYXRlZCBpbiB0aGUgZXhpc3RpbmcgbmV0d29ya3M7ICJ0cnVlIiBjby1yb3V0 ZWQgYmlkaXJlY3Rpb25hbA0KPiAgPj4+IHBhdGhzIHdpbGwgaGF2ZSB0byB3YWl0IHVudGlsIChp ZiBldmVyKSBuZXcgZXF1aXBtZW50IGJlY29tZXMNCj4gID4+PiBhdmFpbGFibGUuDQo+ICA+PiBU aGlzIGlzIGNsZWFybHkgbm9uc2Vuc2UhDQo+ICA+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9m IGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzIGFyZSANCmENCj4gID4+IHNw ZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4gID4+DQo+ICA+ PiBJZiB5b3UgY2FuIHNldCB1cCB0d28gdW5pZGlyZWN0aW9uYWwgTFNQcyAoZS5nLiB1c2luZyB0 aGUgbWFuYWdlbWVudCANCg0KPiBwbGFuZSkNCj4gID4+IHlvdSBjYW4gc3VyZWx5IHNldCB1cCBh IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC4NCj4gID4+DQo+ICA+PiBUaGVyZSBhcmUgc2hp cHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCANCj4g TFNQcyB1c2luZw0KPiAgPj4gdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVpdGhlciB1c2UgdGhl IEdNUExTICh3aGljaCBpcyBjbGVhbmVyKSBvcg0KPiAgPj4gbm9uLXN0YW5kYXJkIHByb3ByaWV0 YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMgbWVzc3kgYnV0IGZ1bmN0aW9uYWwpLg0KPiAgPj4NCj4g ID4+IEJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5l IHNvbHV0aW9ucyBoYXZlIA0KDQo+IG5vdGhpbmcNCj4gID4+IHRvIGRvIHdpdGggYXZhaWxhYmls aXR5IG9mIGVxdWlwbWVudCBhcyB0aGV5IGFyZSBzb2Z0d2FyZSBzb2x1dGlvbnMuDQo+ICA+Pg0K PiAgPj4+IDIuIE15IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRo ZSBhY3R1YWwgZHJpdmVyIA0KZm9yDQo+ICA+Pj4gY28tcm91dGVkDQo+ICA+Pj4gYmlkaXJlY3Rp b25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIHRyYW5zcG9ydCANCm5l dHdvcmtzDQo+ICA+Pj4gcmF0aGVyDQo+ICA+Pj4gdGhhbiBhbnkgc3BlY2lmaWMgYmVuZWZpdC4N Cj4gID4+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAgcmVxdWly ZW1lbnRzPw0KPiAgPj4gV2hpY2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0aGluZy4NCj4g ID4+DQo+ICA+PiBBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNr ZXQgbmV0d29yayB0aGUgbG9vaywgDQo+IGZlZWwsIGFuZA0KPiAgPj4gYmVoYXZpb3JhbCBjaGFy YWN0ZXJpc3RpY3Mgb2YgYSAibGVnYWN5IiB0cmFuc3BvcnQgbmV0d29yay4NCj4gID4+DQo+ICA+ Pj4gQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRoYXQ6DQo+ ICA+Pj4gKiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlLCBhdCBsZWFzdCBmb3Ig dGhlIHRpbWUNCj4gID4+PiBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2YgYmlkaXJl Y3Rpb25hbCBwYXRocyBpbg0KPiAgPj4+IE1QTFMtVFANCj4gID4+IEkgdGhpbmsgdGhhdCBpcyB3 cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5kIGdpdmVuIHRoYXQgDQo+IG90 aGVyDQo+ICA+PiB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9ucyB3aWxsIGJlIG5l ZWRlZCB0byByZWFjaCB0aGUgZnVsbA0KPiAgPj4gZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC4N Cj4gID4+DQo+ICA+Pj4gKiB0aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25s eSB0eXBlIG9mIGJpZGlyZWN0aW9uYWwNCj4gID4+PiBwYXRocyBpbiByZWFsIGRlcGxveW1lbnRz Lg0KPiAgPj4gSSBkb24ndCBzZWUgd2hhdCB0aGF0IGZvbGxvd3MgZnJvbS4NCj4gID4+DQo+ICA+ PiBDaGVlcnMsDQo+ICA+PiBBZHJpYW4NCj4gID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ICA+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiAgPj4g bXBscy10cEBpZXRmLm9yZw0KPiAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzLXRwDQo+ICA+DQo+ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ICA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+ICA+IG1wbHMtdHBA aWV0Zi5vcmcNCj4gID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz LXRwDQo+ICA+DQo+ICA+DQo+ICA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+IA0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gWlRFICBJbmZvcm1hdGlvbiAgU2VjdXJpdHkgIE5vdGljZTogIFRoZSAgaW5mb3Jt YXRpb24gIGNvbnRhaW5lZCAgaW4gDQp0aGlzICBtYWlsICBpcyAgc29sZWx5ICBwcm9wZXJ0eSAg b2YgIHRoZSAgc2VuZGVyJ3MgIG9yZ2FuaXphdGlvbi4gIFRoaXMgDQptYWlsICBjb21tdW5pY2F0 aW9uICBpcyAgY29uZmlkZW50aWFsLiAgUmVjaXBpZW50cyAgbmFtZWQgIGFib3ZlICBhcmUgDQpv YmxpZ2F0ZWQgIHRvICBtYWludGFpbiAgc2VjcmVjeSAgYW5kICBhcmUgIG5vdCAgcGVybWl0dGVk ICB0byAgZGlzY2xvc2UgDQp0aGUgIGNvbnRlbnRzICBvZiAgdGhpcyAgY29tbXVuaWNhdGlvbiAg dG8gIG90aGVycy4NCj4gVGhpcyAgZW1haWwgIGFuZCAgYW55ICBmaWxlcyAgdHJhbnNtaXR0ZWQg IHdpdGggIGl0ICBhcmUgIGNvbmZpZGVudGlhbCANCmFuZCAgaW50ZW5kZWQgIHNvbGVseSAgZm9y ICB0aGUgIHVzZSAgb2YgIHRoZSAgaW5kaXZpZHVhbCAgb3IgIGVudGl0eSAgdG8gDQp3aG9tICB0 aGV5ICBhcmUgIGFkZHJlc3NlZC4gIElmICB5b3UgIGhhdmUgIHJlY2VpdmVkICB0aGlzICBlbWFp bCAgaW4gDQplcnJvciAgcGxlYXNlICBub3RpZnkgIHRoZSAgb3JpZ2luYXRvciAgb2YgIHRoZSAg bWVzc2FnZS4gIEFueSAgdmlld3MgDQpleHByZXNzZWQgIGluICB0aGlzICBtZXNzYWdlICBhcmUg IHRob3NlICBvZiAgdGhlICBpbmRpdmlkdWFsICBzZW5kZXIuDQo+IFRoaXMgIG1lc3NhZ2UgIGhh cyAgYmVlbiAgc2Nhbm5lZCAgZm9yICB2aXJ1c2VzICBhbmQgIFNwYW0gIGJ5ICBaVEUgDQpBbnRp LVNwYW0gIHN5c3RlbS4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0005BAA44825759E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmxvdTo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgYmVjYXVzZSBUaGUgZm9y d2FyZCBhbmQNCmJhY2t3YXJkIGRpcmVjdGlvbnMgYXJlIHNldHVwLCBtb25pdG9yZWQgYW5kIHBy b3RlY3RlZCBpbmRlcGVuZGVudCBpbiB0aGUNCmFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRo cy4gaXQgY2FuJ3QgZW5zdXJlIGFuZCByZWFsaXplIHRoZSBzeW1tZXRyaWMNCmJhbmR3aWR0aCBp biB0d28gZGlyZWN0aW9uYWwgcGF0aC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPm9yIGVsc2UgLCBJIE1VU1QgcmV2aXNlIHRoZSBkZWZpbml0aW9ucw0Kb2YgYXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGluIG1wbHMtdHAgcmVxdWlyZW1lbnRzIGRyYWZ0 LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+cmVnYXJk czwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+bGl1IDwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb3UgQmVyZ2Vy ICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTE3IDIxOjU0PC9mb250Pg0KPHRkIHdpZHRoPTczJT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmxpdS5ndW9tYW5AenRlLmNvbS5jbjwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+QmVuIE5pdmVuLUplbmtpbnMgJmx0O2JlbmphbWluLm5pdmVuLWpl bmtpbnNAYnQuY29tJmd0OywNCm1wbHMtdHBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQp0cmFuc3BvcnQgcGF0aCByZXF1 aXJlbWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTI+PHR0PkxpdSw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KV2h5IGlzbid0IGl0IG5lY2Vzc2FyeSBmb3IgYXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHBhdGhzPyAmbmJzcDtJcyBpdA0KdGhhdDxicj4NCmFzeW1tZXRyaWMg aXMgdGhlIHNvbGUgcmVxdWlyZW1lbnQ/ICZuYnNwO0lmIG5vdCwgSSBkb24ndCB1bmRlcnN0YW5k IHlvdXI8YnI+DQpjb21tZW50Ljxicj4NCjxicj4NCkxvdTxicj4NCjxicj4NCk9uIDQvMTYvMjAw OSA5OjE1IFBNLCBsaXUuZ3VvbWFuQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IExvdTo8YnI+DQomZ3Q7IEkgYWdyZWUgeW91ciBhZHZpY2UsIGJ1dCBmb3Igc3ltbWV0cmlj IGJhbmR3aWR0aCByZXF1aXJlbWVudCwgSSB0aGluaw0KPGJyPg0KJmd0OyB0aGUgcmVxdWlyZW1l bnQgY2FuIG9ubHkgYmUgZml0IGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQN Cjxicj4NCiZndDsgcGF0aHMsIHdoaWxlIGl0IGlzbid0IG5lY2Vzc2FyeSBmb3IgYXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHBhdGhzDQouc28gPGJyPg0KJmd0OyBhZGRpbmcgYSAmcXVvdDtjby1y b3V0ZWQmcXVvdDsgd29yZCBpbiB0aGUgcmVxdWlyZW1lbnQgMzMgaXMgbmVjZXNzYXJ5Ljxicj4N CiZndDsgdGhhbmsgeW91Ljxicj4NCiZndDsgbGl1PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgKkxvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7Kjxicj4NCiZndDsgt6K8 /sjLOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxicj4NCiZndDsgMjAwOS0w NC0xNiAyMTo0Mzxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgytW8/sjLPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0Jlbg0KTml2ZW4tSmVua2lucyAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2lu c0BidC5jb20mZ3Q7PGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0JVU0lAY29yZTMuYW1z bC5jb20sDQomcXVvdDttcGxzLXRwQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzLXRwQGlldGYub3Jn Jmd0OywgSVRBTE8gPGJyPg0KJmd0OyAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdCZn dDs8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmU6DQpbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVuLDxicj4NCiZndDsgSXQgc2VlbXMg dG8gbWUgdGhhdCBtdWNoIG9mIHRoZSBkaXNjdXNzaW9uIHN0ZW1zIGZyb20gdGhlIHNlY3Rpb24N CmluPGJyPg0KJmd0OyB3aGljaCB0aGVzZSByZXF1aXJlbWVudHMgYXJlIGxpc3RlZC48YnI+DQom Z3Q7IDxicj4NCiZndDsgUmVxdWlyZW1lbnQgMzIgaXMgYSBzZXJ2aWNlIGxldmVsIHJlcXVpcmVt ZW50IGFuZCBwcmltYXJpbHkgaW1wYWN0DQp0aGU8YnI+DQomZ3Q7IG1hbmFnZW1lbnQgYW5kIGNv bnRyb2wgcGxhbmVzLiBBcyB0aGVyZSBpcyBubyBzZWN0aW9uIGRlc2NyaWJpbmc8YnI+DQomZ3Q7 IHNlcnZpY2UgcmVxdWlyZW1lbnRzLCBJIHN1Z2dlc3QgbW92aW5nIHRoaXMgcmVxdWlyZW1lbnQg dG8gZm9sbG93PGJyPg0KJmd0OyByZXF1aXJlbWVudCA2LCBhbmQgYWRkaW5nIHRoZSBmb2xsb3dp bmcgaW4gaXRzIHBsYWNlOjxicj4NCiZndDsgMzMgTVBMUy1UUCBNVVNUIHN1cHBvcnQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aHMgd2l0aDxicj4NCiZndDsgc3ltbWV0cmljIGJhbmR3aWR0 aCByZXF1aXJlbWVudHMsIGkuZS4gdGhlIGFtb3VudCBvZiByZXNlcnZlZDxicj4NCiZndDsgYmFu ZHdpZHRoIGlzIHRoZSBzYW1lIGJldHdlZW4gdGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkPGJyPg0K Jmd0OyBkaXJlY3Rpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGlsZSB0aGlzIHRvbyBpcyBh IHNlcnZpY2UgcmVxdWlyZW1lbnQgYW5kIGRvZXNuJ3QgcmVxdWlyZSBhbnkgaGFyZHdhcmU8YnI+ DQomZ3Q7IG1vZGlmaWNhdGlvbnMsIGl0IHBhcmFsbGVscyBjdXJyZW50IHJlcXVpcmVtZW50cyAz NywgNDAgYW5kIDQxLiBJdA0KYWxzbzxicj4NCiZndDsgbWFrZXMgYSBjdXJyZW50bHkgaW1wbGlj aXQgcmVxdWlyZW1lbnQgZXhwbGljaXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlcXVpcmVtZW50 cyAzMy0yNiByZWxhdGUgdG8gJnF1b3Q7YXdhcmVuZXNzJnF1b3Q7IHNob3VsZCBoYXZlIG5vDQpp bXBsaWNhdGlvbiBvbjxicj4NCiZndDsgdGhlIGRhdGEvZm9yd2FyZGluZyBwbGFuZSBhbmQgYXJl IElNTyBib3RoIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2wNCnBsYW5lPGJyPg0KJmd0OyByZXF1aXJl bWVudHMuIChBbmQgeWVzLCB0aGV5IGhhdmUgaW1wbGljYXRpb25zIG9uIE9BTSBhbmQgcmVjb3Zl cnkuKQ0KSTxicj4NCiZndDsgdGhpbmsgQWRyaWFuIHJhaXNlcyBhIGdvb2QgcG9pbnQgV1JUIHRo ZXNlIHJlcXVpcmVtZW50cywgaS5lLiwgYXJlDQp0aGVzZTxicj4NCiZndDsgcmVxdWlyZW1lbnRz IGxpc3RlZCBhcyBzb2x1dGlvbnMgdG8gc29tZSB1bmxpc3RlZCByZXF1aXJlbWVudHMuIElmDQpz byw8YnI+DQomZ3Q7IHRoZSB1bmxpc3RlZCByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGluY2x1ZGVk IGFuZCB0aGVzZSBzaG91bGQgYmU8YnI+DQomZ3Q7IGRyb3BwZWQuIElmIG5vdCwgc28gYmUgaXQs IGJ1dCB0aGV5IHNob3VsZCBiZSBtb3ZlZCBmcm9tIHNlY3Rpb24gMi4zLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBXaGlsZSBJJ20gc3VyZSB0aGlzIHdvbid0IGVuZCB0aGUgZGlzY3Vzc2lvbiwgSSB0 aGluayB0aGVzZSBjaGFuZ2VzDQp3aWxsPGJyPg0KJmd0OyBoZWxwIG1ha2UgJnF1b3Q7dGhlIHJl cXVpcmVtZW50cyBjbGVhciBlbm91Z2ggLi4uJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExv dTxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiA0LzE2LzIwMDkgNTo1OCBBTSwgQmVuIE5pdmVuLUpl bmtpbnMgd3JvdGU6PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IENvbGxlYWd1ZXMsPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IEkgY2FuJ3QgaGVscCBidXQgZmVlbCB3ZSBh cmUgb3ZlcmFuYWx5c2luZyB0aGluZ3MgaGVyZS4NCkhvdyBtYW55PGJyPg0KJmd0OyAmbmJzcDsm Z3Q7IHRlY2hub2xvZ2llcy9wcm90b2NvbHMvbWVjaGFuaXNtcyBoYXZlIHdlIHN1Y2Nlc3NmdWxs eQ0KZGVmaW5lZCBpbiA8YnI+DQomZ3Q7IGJvdGggSUVURjxicj4NCiZndDsgJm5ic3A7Jmd0OyAm YW1wOyBJVFUtVCB3aXRob3V0IHRoaXMgbGV2ZWwgb2YgYW5hbHlzaXMgb2YgdGhlIGluaXRpYWwN CnJlcXVpcmVtZW50cyAtIDxicj4NCiZndDsgYSBncmVhdDxicj4NCiZndDsgJm5ic3A7Jmd0OyBt YW55IChhIGdvb2QgY2h1bmsgb2Ygd2hpY2ggd2VyZSBleHRyZW1lbHkgc3VjY2Vzc2Z1bCkuPGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFRoZSByZXF1aXJlbWVudHMg ZG9jdW1lbnQgaXMgbm90IGFib3V0IHNwZWNpZnlpbmcgc29sdXRpb25zLjxicj4NCiZndDsgJm5i c3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBUaGUga2V5IHF1ZXN0aW9uIGlzOiBhcmUgdGhl IHJlcXVpcmVtZW50cyBjbGVhciBlbm91Z2gNCnRoYXQgaXQgaXMgPGJyPg0KJmd0OyB1bmRlcnN0 b29kPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHdoYXQgaXMgcmVxdWlyZWQgc28gc29tZW9uZSBjb3Vs ZCBidWlsZCBhIGJveC9wcm90b2NvbC93aGF0ZXZlcg0KdG8gbWVldDxicj4NCiZndDsgJm5ic3A7 Jmd0OyB0aGVtPzxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBJZiB3 ZSB3YW50IHRvIGdvIGludG8gdGhlIG50aCBsZXZlbCBvZiBkZXRhaWwgb24gZWFjaCByZXF1aXJl bWVudA0Kd2Ugd2lsbDxicj4NCiZndDsgJm5ic3A7Jmd0OyBzdGlsbCBiZSBkZWJhdGluZyB0aGlz IGJ5IHRoZSB0aW1lIEkgcmV0aXJlICh3aGljaCBpc24ndA0KZHVlIHVudGlsIDIwNDUpLjxicj4N CiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBCZW48YnI+DQomZ3Q7ICZuYnNw OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgT24gMTYvMDQv MjAwOSAwODowNCwgJnF1b3Q7QWxleGFuZGVyIFZhaW5zaHRlaW4mcXVvdDs8YnI+DQomZ3Q7ICZu YnNwOyZndDsgJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tJmd0OyB3cm90ZTo8 YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IEFkcmlhbiw8YnI+ DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFRoYW5rIHlvdSBmb3IgYSBwcm9tcHQgYW5kIGRldGFpbGVk IHJlc3BvbnNlLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsm Z3Q7IFVuZm9ydHVuYXRlbHkgSSBjYW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVu dDo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyAmbHQ7 cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3 IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KTFNQczxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsgYXJlIGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCBMU1BzLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgJmx0O2VuZCBxdW90ZSZndDs8YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBUaGlzIHN0YXRlbWVu dCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZSBpdA0Kbm90IGZvciA8YnI+DQomZ3Q7 IFJlcXVpcmVtZW50IDM0IGluPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyB0aGUgbGF0ZXN0PGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdDxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDsgPGJyPg0KJmd0OyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXJlcXVpcmVtZW50cy0wNi50eHQpOjxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7ICZsdDtxdW90ZSZndDs8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGlu ZyBNRVBzLCBNSVBzIGFuZCBvdGhlcg0KaW50ZXJuYWw8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7 IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0K dHJhbnNwb3J0PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5 ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZzxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsg cmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQgZGlyZWN0aW9ucw0K b2YgdGhhdDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgdHJhbnNwb3J0IHBhdGguPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7Jmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgUmVxdWlyZW1lbnQg MzQgaXMgdGhlIE9OTFkgaXRlbSBpbg0KdGhlIGxpc3QgdGhhdCBpcyA8YnI+DQomZ3Q7IHNwZWNp ZmljPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg TFNQcy4gKFRoZSBwYWlyaW5nIHJlcXVpcmVtZW50cw0KYXQgZW5kIDxicj4NCiZndDsgcG9pbnRz PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBmb3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgcGF0aHMgYXJlDQpleGFjdGx5IHRoZSA8YnI+DQomZ3Q7IHNhbWUgZXZlbjxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgaWYgdGhleSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudCBp dGVtcyBpbiB0aGUgcmVxdWlyZW1lbnRzJw0KbGlzdCkuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mDQpj by1yb3V0ZWQgPGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyBwYXRocyB3b3VsZCBiZSB2b2lkIG9mIGFueSBkYXRhIHBsYW5lIGNvbnRlbnQuPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgVGhlIHNvbWV3aGF0IHZh Z3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCZxdW90O290aGVyDQppbnRlcm5hbCBmdW5j dGlvbnM8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IGFzIGFwcHJvcHJpYXRlJnF1b3Q7KSBjcmVh dGVzIGEgc3VzcGljaW9uIHRoYXQgSFcgc3VwcG9ydA0Kb2YgdGhlIHBhaXJpbmcgPGJyPg0KJmd0 OyBhd2FyZW5lc3M8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IG1heSBiZSByZXF1aXJlZCBpbiBv cmRlciB0byBjb21wbHkgd2l0aCBpdC48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7Jmd0OyBUaGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIGRyYWZ0IGluY3JlYXNl cyB0aGlzIHN1c3BpY2lvbjo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJz cDsmZ3Q7Jmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBUYW5kZW0g Q29ubmVjdGlvbjogQSB0YW5kZW0gY29ubmVjdGlvbiBpcyBhbiBhcmJpdHJhcnkNCnBhcnQgb2Yg YTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgdHJhbnNwb3J0IHBhdGggdGhhdCBjYW4gYmUgbW9u aXRvcmVkICh2aWEgT0FNKSBpbmRlcGVuZGVudGx5DQpmcm9tIHRoZTxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDsgZW5kLXRvLWVuZCBtb25pdG9yaW5nIChPQU0pLiBJdCBtYXkgYmUgYSBtb25pdG9y ZWQNCnNlZ21lbnQgb3IgYTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgbW9uaXRvcmVkIGNvbmNh dGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguDQpUaGUgdGFuZGVtPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7Jmd0OyBjb25uZWN0aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRp bmcgZW5naW5lKHMpDQpvZiB0aGUgbm9kZShzKTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgYXQg dGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21lbnQuPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IERvZXNuJ3QgJnF1b3Q7Zm9yd2FyZGluZyBl bmdpbmUmcXVvdDsgc291bmQgbGlrZSBoYXJkd2FyZQ0KdG8geW91Pzxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IElNSE8gaXQgaXMgd29ydGggbm90aW5n IHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUCBSZXF1aXJlbWVudHMNCmRyYWZ0PGJyPg0KJmd0OyAm bmJzcDsmZ3Q7Jmd0OyBub3IgdGhlIE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50cyBvbmU8YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7IDxicj4NCiZndDsgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVxdWlyZW1lbnRzLTAxLnR4PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyB0KTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgY29udGFpbiBh bnkgcmVxdWlyZW1lbnRzIGRlYWxpbmcgd2l0aCB0YW5kZW0gY29ubmVjdGlvbnMuPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgQnV0IHRhbmRlbSBjb25u ZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBNUExTLVRQDQpPQU0gRnJhbWV3b3JrIGRyYWZ0 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7IChodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWZyYW1ld29yay0wMC50eHQp Ljxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFRoZSBi b3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nDQpjby1yb3V0 ZWQgdnMuIDxicj4NCiZndDsgYXNzb2NpYXRlZDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgYmlk aXJlY3Rpb25hbDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgcGF0aHMgaXMgc3RpbGwgcmVxdWly ZWQuIE9uZSB3YXkgdG8gcHJvdmlkZSB0aGF0IGNvdWxkDQpiZSBieSBleHBsaWNpdGx5PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyBsaW1pdGluZyBSZXF1aXJlbWVudCAzNDxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsgdG8gc3BlY2lmaWMgZnVuY3Rpb25hbGl0eS48YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBNeSAyYyw8YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7IFNhc2hhPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7 IEZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMTI6MTMgQU08YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsg QlVTSSBJVEFMTzxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KcGF0aCA8YnI+DQomZ3Q7IHJlcXVpcmVtZW50czxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IEhpIFNhc2hh LDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IE5vdCBy ZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwNCmJ1dC4u Ljxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyAx LiBNeSByZWFkaW5nIG9mIG9uZSBvZiBCZW4ncyBtZXNzYWdlcyBpcyB0aGF0DQphc3NvY2lhdGVk PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgdGhl IG9ubHkgdHlwZXMgb2YgcGF0aHMNCnRoYXQgY2FuIGJlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyZndDsgY3JlYXRlZCBpbiB0aGUgZXhpc3RpbmcgbmV0d29ya3M7ICZxdW90O3RydWUmcXVvdDsN CmNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgcGF0 aHMgd2lsbCBoYXZlIHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQNCmJlY29t ZXM8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyBhdmFpbGFibGUuPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7Jmd0OyBUaGlzIGlzIGNsZWFybHkgbm9uc2Vuc2UhPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 Jmd0OyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbA0KTFNQcyBhcmUgYTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgc3BlY2lhbCBjYXNl IG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IElmIHlvdSBjYW4gc2V0IHVwIHR3byB1bmlkaXJl Y3Rpb25hbCBMU1BzIChlLmcuIHVzaW5nDQp0aGUgbWFuYWdlbWVudCA8YnI+DQomZ3Q7IHBsYW5l KTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgeW91IGNhbiBzdXJlbHkgc2V0IHVwIGEgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7IFRoZXJlIGFyZSBzaGlwcGluZyBzb2x1dGlvbnMgdGhhdCBhY2hpZXZl IGNvLXJvdXRlZA0KYmlkaXJlY3Rpb25hbCA8YnI+DQomZ3Q7IExTUHMgdXNpbmc8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7IHRoZSBjb250cm9sIHBsYW5lLiBUaGVzZSBlaXRoZXIgdXNlIHRoZSBH TVBMUyAod2hpY2gNCmlzIGNsZWFuZXIpIG9yPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBub24t c3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpcyBtZXNzeQ0KYnV0IGZ1bmN0 aW9uYWwpLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7 IEJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lDQpz b2x1dGlvbnMgaGF2ZSA8YnI+DQomZ3Q7IG5vdGhpbmc8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7 IHRvIGRvIHdpdGggYXZhaWxhYmlsaXR5IG9mIGVxdWlwbWVudCBhcyB0aGV5IGFyZSBzb2Z0d2Fy ZQ0Kc29sdXRpb25zLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7Jmd0OyAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMgaXMgdGhh dA0KdGhlIGFjdHVhbCBkcml2ZXIgZm9yPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgY28t cm91dGVkPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgYmlkaXJlY3Rpb25hbCBwYXRocyBt YXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nDQp0cmFuc3BvcnQgbmV0d29ya3M8YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyByYXRoZXI8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0 OyB0aGFuIGFueSBzcGVjaWZpYyBiZW5lZml0Ljxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgSXNu J3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUgTVBMUy1UUCByZXF1aXJlbWVudHM/PGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFkIHRo aW5nLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IEEg bGFyZ2UgZHJpdmVyIGZvciBNUExTLVRQIGlzIHRvIGdpdmUgdGhlIHBhY2tldCBuZXR3b3JrDQp0 aGUgbG9vaywgPGJyPg0KJmd0OyBmZWVsLCBhbmQ8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IGJl aGF2aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgJnF1b3Q7bGVnYWN5JnF1b3Q7DQp0cmFuc3Bv cnQgbmV0d29yay48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 Jmd0OyZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRo YXQ6PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgKiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgcGF0aHMgYXJlLCBhdCBsZWFzdA0KZm9yIHRoZSB0aW1lPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 Jmd0OyZndDsgYmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mIGJpZGlyZWN0aW9uYWwN CnBhdGhzIGluPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgTVBMUy1UUDxicj4NCiZndDsg Jm5ic3A7Jmd0OyZndDsgSSB0aGluayB0aGF0IGlzIHdyb25nIGJvdGggZ2l2ZW4gbXkgc3RhdGVt ZW50IGFib3ZlLA0KYW5kIGdpdmVuIHRoYXQgPGJyPg0KJmd0OyBvdGhlcjxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsgdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZSBu ZWVkZWQNCnRvIHJlYWNoIHRoZSBmdWxsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBmdW5jdGlv biBsZXZlbCBvZiBNUExTLVRQLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZu YnNwOyZndDsmZ3Q7Jmd0OyAqIHRoZXkgaGFkIGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBv bmx5IHR5cGUNCm9mIGJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyBw YXRocyBpbiByZWFsIGRlcGxveW1lbnRzLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgSSBkb24n dCBzZWUgd2hhdCB0aGF0IGZvbGxvd3MgZnJvbS48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBB ZHJpYW48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBtcGxzLXRwIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgbXBscy10cEBpZXRmLm9yZzxicj4N CiZndDsgJm5ic3A7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzLXRwPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IG1wbHMtdHBA aWV0Zi5vcmc8YnI+DQomZ3Q7ICZuYnNwOyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsm Z3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0OyBaVEUgJm5ic3A7SW5mb3JtYXRpb24gJm5ic3A7U2VjdXJpdHkgJm5ic3A7Tm90 aWNlOiAmbmJzcDtUaGUgJm5ic3A7aW5mb3JtYXRpb24NCiZuYnNwO2NvbnRhaW5lZCAmbmJzcDtp biAmbmJzcDt0aGlzICZuYnNwO21haWwgJm5ic3A7aXMgJm5ic3A7c29sZWx5ICZuYnNwO3Byb3Bl cnR5DQombmJzcDtvZiAmbmJzcDt0aGUgJm5ic3A7c2VuZGVyJ3MgJm5ic3A7b3JnYW5pemF0aW9u LiAmbmJzcDtUaGlzICZuYnNwO21haWwNCiZuYnNwO2NvbW11bmljYXRpb24gJm5ic3A7aXMgJm5i c3A7Y29uZmlkZW50aWFsLiAmbmJzcDtSZWNpcGllbnRzICZuYnNwO25hbWVkDQombmJzcDthYm92 ZSAmbmJzcDthcmUgJm5ic3A7b2JsaWdhdGVkICZuYnNwO3RvICZuYnNwO21haW50YWluICZuYnNw O3NlY3JlY3kNCiZuYnNwO2FuZCAmbmJzcDthcmUgJm5ic3A7bm90ICZuYnNwO3Blcm1pdHRlZCAm bmJzcDt0byAmbmJzcDtkaXNjbG9zZSAmbmJzcDt0aGUNCiZuYnNwO2NvbnRlbnRzICZuYnNwO29m ICZuYnNwO3RoaXMgJm5ic3A7Y29tbXVuaWNhdGlvbiAmbmJzcDt0byAmbmJzcDtvdGhlcnMuPGJy Pg0KJmd0OyBUaGlzICZuYnNwO2VtYWlsICZuYnNwO2FuZCAmbmJzcDthbnkgJm5ic3A7ZmlsZXMg Jm5ic3A7dHJhbnNtaXR0ZWQNCiZuYnNwO3dpdGggJm5ic3A7aXQgJm5ic3A7YXJlICZuYnNwO2Nv bmZpZGVudGlhbCAmbmJzcDthbmQgJm5ic3A7aW50ZW5kZWQNCiZuYnNwO3NvbGVseSAmbmJzcDtm b3IgJm5ic3A7dGhlICZuYnNwO3VzZSAmbmJzcDtvZiAmbmJzcDt0aGUgJm5ic3A7aW5kaXZpZHVh bA0KJm5ic3A7b3IgJm5ic3A7ZW50aXR5ICZuYnNwO3RvICZuYnNwO3dob20gJm5ic3A7dGhleSAm bmJzcDthcmUgJm5ic3A7YWRkcmVzc2VkLg0KJm5ic3A7SWYgJm5ic3A7eW91ICZuYnNwO2hhdmUg Jm5ic3A7cmVjZWl2ZWQgJm5ic3A7dGhpcyAmbmJzcDtlbWFpbCAmbmJzcDtpbg0KJm5ic3A7ZXJy b3IgJm5ic3A7cGxlYXNlICZuYnNwO25vdGlmeSAmbmJzcDt0aGUgJm5ic3A7b3JpZ2luYXRvciAm bmJzcDtvZg0KJm5ic3A7dGhlICZuYnNwO21lc3NhZ2UuICZuYnNwO0FueSAmbmJzcDt2aWV3cyAm bmJzcDtleHByZXNzZWQgJm5ic3A7aW4NCiZuYnNwO3RoaXMgJm5ic3A7bWVzc2FnZSAmbmJzcDth cmUgJm5ic3A7dGhvc2UgJm5ic3A7b2YgJm5ic3A7dGhlICZuYnNwO2luZGl2aWR1YWwNCiZuYnNw O3NlbmRlci48YnI+DQomZ3Q7IFRoaXMgJm5ic3A7bWVzc2FnZSAmbmJzcDtoYXMgJm5ic3A7YmVl biAmbmJzcDtzY2FubmVkICZuYnNwO2ZvciAmbmJzcDt2aXJ1c2VzDQombmJzcDthbmQgJm5ic3A7 U3BhbSAmbmJzcDtieSAmbmJzcDtaVEUgJm5ic3A7QW50aS1TcGFtICZuYnNwO3N5c3RlbS48YnI+ DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 0005BAA44825759E_=-- From liu.guoman@zte.com.cn Sun Apr 19 18:05:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27A33A6B44 for ; Sun, 19 Apr 2009 18:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.985 X-Spam-Level: X-Spam-Status: No, score=-96.985 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+VxA-EnhLhU for ; Sun, 19 Apr 2009 18:05:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 73BFC3A6AF4 for ; Sun, 19 Apr 2009 18:05:12 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 11164764009499; Mon, 20 Apr 2009 08:56:19 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.2512172824; Mon, 20 Apr 2009 09:02:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3K15DE7032156; Mon, 20 Apr 2009 09:05:14 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B19C4@FRVELSMBS21.ad2.ad.alcatel.com> To: "BUSI ITALO" , "Annamaria Fulignoli" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 20 Apr 2009 09:03:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-20 09:05:13, Serialize complete at 2009-04-20 09:05:13 Content-Type: multipart/alternative; boundary="=_alternative 0005F72D4825759E_=" X-MAIL: mse1.zte.com.cn n3K15DE7032156 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 01:05:14 -0000 This is a multipart message in MIME format. --=_alternative 0005F72D4825759E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KysxDQoNCg0KDQoiQlVTSSBJVEFMTyIgPEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+IA0K t6K8/sjLOiAgbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoyMDA5LTA0LTE3IDIxOjU5DQoNCsrV vP7Iyw0KLCAiVklHT1VSRVVYIE1BUlRJTiIgPE1hcnRpbi5WaWdvdXJldXhAYWxjYXRlbC1sdWNl bnQuY29tPiwgIkJlbiANCk5pdmVuLUplbmtpbnMiIDxiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0 LmNvbT4NCrOty80NCm1wbHMtdHBAaWV0Zi5vcmcNCtb3zOINClJlOiBbbXBscy10cF0gVGFuZGVt IENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyBSRTogQXNzb2NpYXRlZCANCmJpZGlyZWN0aW9u YWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQoNCg0KDQoNCg0KKzEgDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5uYW1hcmlhIEZ1bGlnbm9saSBbbWFp bHRvOmFubmFtYXJpYS5mdWxpZ25vbGlAZXJpY3Nzb24uY29tXSANCj4gU2VudDogRnJpZGF5LCBB cHJpbCAxNywgMjAwOSAxOjUyIFBNDQo+IFRvOiBWSUdPVVJFVVggTUFSVElOOyBCZW4gTml2ZW4t SmVua2lucw0KPiBDYzogQlVTSSBJVEFMTzsgbXBscy10cEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS RTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgUkU6IA0KPiBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KPiAN Cj4gSGkgYWxsLA0KPiBzb3JyeSBidXQgSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgd2UgY2Fubm90 IGV4cGxpY2l0bHkgdXNlIA0KPiB0aGUgdGVybSBUYW5kZW0gQ29ubmVjdGlvbiBpbiB0aGUgcmVx dWlyZW1lbnRzIGRvY3VtZW50IQ0KPiBUQ00gaXMgbm90IGEgc29sdXRpb24sIGl0IGlzIHBhcnQg b2YgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUgDQo+IG9mIGEgdHJhbnNwb3J0IG5ldHdvcmtzIGFz IGRlc2NyaWJlZCBpbiBHLjgwNS4gVGhlIHNvbHV0aW9uIA0KPiBpcyB0byByZWFsaXplIGl0IHdp dGggbGFiZWwgc3RhY2tpbmcgcmF0aGVyIHRoYW4gTUVMLiANCj4gDQo+IFJlZ2FyZHMNCj4gQW5u YW1hcmlhDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZyANCj4gW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNYXJ0aW4gVmlnb3VyZXV4DQo+IFNlbnQ6IHZlbmVyZKisIDE3IGFwcmlsZSAyMDA5 IDEzLjI5DQo+IFRvOiBCZW4gTml2ZW4tSmVua2lucw0KPiBDYzogQlVTSSBJVEFMTzsgbXBscy10 cEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBp biBNUExTLVRQICh3YXMgUkU6IA0KPiBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0 IHBhdGggcmVxdWlyZW1lbnRzKQ0KPiANCj4gQmVuLCBhbGwNCj4gDQo+IGluIG1wbHMtdHAtb2Ft LXJlcXVpcmVtZW50LCB0aGUgdGV4dCBvbiB0aGlzIGl0ZW0gaXMgYXMgZm9sbG93czoNCj4gDQo+ ICAgICBUaGUgc2VydmljZSBlbXVsYXRlZCBieSBhIHNpbmdsZSBzZWdtZW50IG9yIGEgbXVsdGkt c2VnbWVudCBQVyBtYXkNCj4gICAgIHNwYW4gbXVsdGlwbGUgZG9tYWlucy4gIEEgTFNQIG1heSBh bHNvIHNwYW4gbXVsdGlwbGUgZG9tYWlucy4gIEl0DQo+ICAgICBNVVNUIGJlIHBvc3NpYmxlIHRv IHBlcmZvcm0gT0FNIGZ1bmN0aW9ucyBvbiBhIHBlciBkb21haW4gDQo+IGJhc2lzIGFuZA0KPiAg ICAgYWNyb3NzIG11bHRpcGxlIGRvbWFpbnMuICBNb3JlIGdlbmVyYWxseSBpdCBNVVNUIGJlIHBv c3NpYmxlIHRvDQo+ICAgICBwZXJmb3JtIE9BTSBmdW5jdGlvbnMgYmV0d2VlbiBhbnkgdHdvIHN3 aXRjaGluZyBlbGVtZW50cyANCj4gKGUuZy4sIExTUg0KPiAgICAgb3IgUy1QRSkgb2YgYSBMU1Ag b3Igb2YgUFcuICBUaGlzIGlzIHJlZmVycmVkIHRvIGFzIChjb25jYXRlbmF0ZWQpDQo+ICAgICBz ZWdtZW50IG1vbml0b3JpbmcuDQo+IA0KPiBJIGJlbGlldmUgdGhlIHRleHQgZGVzY3JpYmVzIGEg ZnVuY3Rpb25hbCByZXEuDQo+IA0KPiBEdXJpbmcgbWVhZCB0ZWFtIHJldmlldywgdGhlIHJlbW92 YWwgb2YgdGhlIGxhc3Qgc2VudGVuY2Ugd2FzIA0KPiBkaXNjdXNzZWQuDQo+IE5vIHN0cm9uZyBv cGluaW9uIHdhcyBleHByZXNzZWQgb24gd2hldGhlciBpdCBzaG91bGQgDQo+IGVmZmVjdGl2ZWx5 IGJlIHJlbW92ZWQgb3Igbm90Lg0KPiANCj4gcmVnYXJkcywNCj4gbWFydGluDQo+IA0KPiBCZW4g Tml2ZW4tSmVua2lucyBhIKimY3JpdCA6DQo+ID4gSXRhbG8sDQo+ID4gDQo+ID4gSSB0aGluayB3 ZSBhcmUgY29udmVyZ2luZy4gSWYgSSBjYW4gYmUgc28gYm9sZCBhcyB0byBzcGVhayBvbiBoaXMg DQo+ID4gYmVoYWxmIEFkcmlhbidzIG9iamVjdGlvbiBzZWVtZWQgdG8gYmUgdG8gdGhlIHVzZSBv ZiB0aGUgdGVybSBUQ00uDQo+ID4gDQo+ID4gSXQgaXMgZGVmaW5lZCBpbiB0aGUgTVBMUy1UUCBy ZXF1aXJlbWVudHMgYnV0IG5vdCB1c2VkLg0KPiA+IA0KPiA+IEl0IGlzIG5vdCB1c2VkIGluIHRo ZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgZG9jdW1lbnQuDQo+ID4gDQo+ID4gVGhlcmVmb3Jl IEkgdGhpbmsgdGhlIHdheSBmb3J3YXJkIGlzIGFzIGZvbGxvd3M6DQo+ID4gDQo+ID4gMSkgUmVt b3ZlIHRoZSB0ZXJtIFRhbmRlbSBDb25uZWN0aW9uIGZyb20gdGhlIE1QTFMtVFAgDQo+IHJlcXVp cmVtZW50cyBhcyANCj4gPiBpdCBpcyByZWR1bmRhbnQgKGkuZS4gTm90IHVzZWQgaW4gdGhhdCBk b2N1bWVudCkuDQo+ID4gDQo+ID4gMikgRW5zdXJlIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVu dHMgZXhwcmVzcyB0aGUgbmVjZXNzYXJ5IA0KPiA+IGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGFy b3VuZCBtb25pdG9yaW5nIG9mIGVuZCB0byBlbmQgDQo+IHBhdGhzIGFzIHdlbGwgDQo+ID4gYXMg cGFydHMgb2YgZW5kIHRvIGVuZCBwYXRocy4gVGhpcyBjYW4gYmUgZG9uZSB3aXRob3V0IHJlZmVy cmluZyANCj4gPiBleHBsaWNpdGx5IHRvIFRhbmRlbSBDb25uZWN0aW9ucy4NCj4gPiANCj4gPiBX aGVuIGl0IGNvbWVzIHRvIHNvbHV0aW9uIGRlc2lnbiB3ZSBjYW4gZGVjaWRlIHdoYXQgaXMgdGhl IGJlc3QgDQo+ID4gbWVjaGFuaXNtIHRvIGFjaGlldmUvaW1wbGVtZW50IHRob3NlIHJlcXVpcmVt ZW50cyBiZSBpdCBMU1AgDQo+IGhpZXJhcmNoeSBvciBzb21ldGhpbmcgZWxzZS4NCj4gPiBUaGUg SldUIGhhcyBwcm92ZWQgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBtZWV0IHRob3NlIHJlcXVpcmVt ZW50cyANCj4gPiB1c2luZyBleGlzdGluZyBNUExTIHRlY2hub2xvZ3kgKG1heWJlIHdpdGggc29t ZSBlbmhhbmNlbWVudHMpLiBJIGRvIA0KPiA+IG5vdCBiZWxpZXZlIHdlIGhhdmUgdG8gbmVjZXNz YXJpbHkgdXNlIHRoZSBzb2x1dGlvbiB0aGV5IHByb3Bvc2UgDQo+ID4gYXNsb25nIGFzIHdoYXRl dmVyIHNvbHV0aW9uIHdlIHVsdGltYXRlbHkgZGVjaWRlIHVwb24gbWVldHMgYWxsIHRoZSANCj4g PiBuZWNlc3NhcnkgcmVxdWlyZW1lbnRzIGV4cHJlc3NlZC4NCj4gPiANCj4gPiBDYW4gd2UgYWdy ZWUgb24gdGhhdCBhcyBhbiBhcHByb2FjaCBhbmQgY2xvc2UgdGhpcyBvZmYgZm9yIG5vdz8NCj4g PiANCj4gPiBCZW4NCj4gPiANCj4gPiANCj4gPiBPbiAxNy8wNC8yMDA5IDEwOjQ5LCAiQlVTSSBJ VEFMTyIgDQo+IDxJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0PiB3cm90ZToNCj4gPiANCj4g Pj4gQmVuLA0KPiA+Pg0KPiA+PiBJIHRoaW5rIHdlIGFyZSBtaXhpbmcgc29sdXRpb25zIHdpdGgg cmVxdWlyZW1lbnRzLg0KPiA+Pg0KPiA+PiBUaGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBUQ00gZnVu Y3Rpb24gaXMgY2xlYXJseSBkZWZpbmVkIGFuZCBJIGRvIA0KPiA+PiB0aGluayBpdCBtdXN0IGJl IGFkZHJlc3NlZCBieSB0aGUgTVBMUy1UUCBkZXNpZ24uDQo+ID4+DQo+ID4+IFRoZSBzb2x1dGlv biBldmFsdWF0ZWQgYnkgdGhlIEpXVCB0byBtZWV0IHRoaXMgcmVxdWlyZW1lbnQgDQo+IHdhcyB0 byB1c2UgDQo+ID4+IGxhYmVsIHN0YWNraW5nIHdpdGggYSAxOjEgcmVsYXRpb25zaGlwIGJldHdl ZW4gdGhlIFRDTSBMU1AgYW5kIHRoZSANCj4gPj4gZTJlIExTUC4NCj4gPj4NCj4gPj4gSSB0aGlu ayB0aGlzIHNvbHV0aW9uLCBhbHRob3VnaCBub3QgdGhlIGJlc3QgdGVjaG5pY2FsIG9wdGlvbiwg aXMgDQo+ID4+IGdvb2QgZW5vdWdoIGFuZCBtZWV0cyB0aGUgcmVxdWlyZW1lbnRzLg0KPiA+Pg0K PiA+PiBIb3dldmVyIHRoaXMgaXMgaXMgYSBzb2x1dGlvbiBhbmQgaGFzIG5vdCBpbXBhY3Qgb24g dGhlIA0KPiByZXF1aXJlbWVudC4NCj4gPj4NCj4gPj4gSXRhbG8NCj4gPj4NCj4gPj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBCZW4gTml2ZW4tSmVua2lucyBbbWFp bHRvOmJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tXQ0KPiA+Pj4gU2VudDogRnJpZGF5LCBB cHJpbCAxNywgMjAwOSAxMToyMiBBTQ0KPiA+Pj4gVG86IEJVU0kgSVRBTE87IEFkcmlhbiBGYXJy ZWw7IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+ID4+PiBDYzogbXBscy10cEBpZXRmLm9yZzsgTG91 IEJlcmdlcg0KPiA+Pj4gU3ViamVjdDogUmU6IFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQ ICh3YXMgUkU6IFttcGxzLXRwXSANCj4gPj4+IEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQo+ID4+Pg0KPiA+Pj4gSXRhbG8sDQo+ID4+Pg0KPiA+ Pj4gT24gMTcvMDQvMjAwOSAwOTozNCwgIkJVU0kgSVRBTE8iDQo+ID4+PiA8SXRhbG8uQnVzaUBh bGNhdGVsLWx1Y2VudC5pdD4gd3JvdGU6DQo+ID4+Pj4gVGhlIEpXVCBhZ3JlZW1lbnQgaXMgdG8g YnJpbmcgdGhlIElUVS1UIHRyYW5zcG9ydA0KPiA+Pj4gcmVxdWlyZW1lbnRzIGluIElFVEYNCj4g Pj4+PiB0byBleHRlbmQgdGhlIE1QTFMgYXJjaGl0ZWN0dXJlIHRvIG1lZXQgdGhlbSBpbiBhIHdh eSB0aGF0IGlzIA0KPiA+Pj4+IGNvbXBhdGlibGUsIGNvbnNpc3RlbnQgYW5kIGNvaGVyZW50IHdp dGggZXhpc3RpbmcgSUVURiANCj4gYXJjaGl0ZWN0dXJlLg0KPiA+Pj4gU28gSSB0b29rIGEgbG9v ayBhdCB0aGUgSldUIHJlcG9ydC4gSXQgc2F5cyAoc2xpZGUgMTYpDQo+ID4+Pg0KPiA+Pj4gIiBT ZXJ2aWNlIFByb3ZpZGVycyB3YW50IExTUHMvUFdFcyB0byBiZSBhYmxlIHRvIGJlIA0KPiBtYW5h Z2VkIGF0IHRoZSANCj4gPj4+IGRpZmZlcmVudCBuZXN0ZWQgbGV2ZWxzIHNlYW1sZXNzbHkgKHBh dGgsIHNlZ21lbnQsIG11bHRpcGxlIA0KPiA+Pj4gc2VnbWVudHMpDQo+ID4+PiAgICAgYWthIFRh bmRlbSBDb25uZWN0aW9uIE1vbml0b3JpbmcgKFRDTSksIHRoaXMgaXMgdXNlZCANCj4gZm9yIGV4 YW1wbGUgDQo+ID4+PiB3aGVuIGEgTFNQL1BXRSBjcm9zc2VzIG11bHRpcGxlIGFkbWluaXN0cmF0 aW9ucyINCj4gPj4+DQo+ID4+PiBJTU8gdGhlIHJlcXVpcmVtZW50IGlzIHRvIGJlIGFibGUgdG8g bW9uaXRvciBwYXJ0cyBvZiBhIA0KPiBwYXRoIGFzIHdlbGwgDQo+ID4+PiBhcyB0aGUgZW5kIHRv IGVuZCBwYXRoLiBUaGVyZSBhcmUgbWFueSB3YXlzIHRvIHNvbHZlIHRoYXQgDQo+ID4+PiByZXF1 aXJlbWVudCwgb25lIG9mIHdoaWNoIGlzIHRoZSBjcmVhdGlvbiBvZiBuZXN0ZWQgTFNQcywgb25l IHBlciANCj4gPj4+IGxldmVsIG9mIG1vbml0b3JpbmcgcmVxdWlyZWQgKG15IHVuZGVyc3RhbmRp bmcgb2YgaG93IFRDTSB3b3JrcykuDQo+ID4+Pg0KPiA+Pj4gSSB0aGluayB0aGUgcmVhbCBkaXNj dXNzaW9uIGlzIHRoZXJlZm9yZSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gDQo+ID4+PiBtb25pdG9y IGRpZmZlcmVudCBjb21wb25lbnRzIG9mIGFuIGVuZCB0byBlbmQgcGF0aCBvciBpcyB0aGUgDQo+ ID4+PiByZXF1aXJlbWVudCB0aGF0IHN1Y2ggbW9uaXRvcmluZyBNVVNUIGJlIGFjaGlldmVkIHVz aW5nIA0KPiBuZXN0ZWQgTFNQcz8NCj4gPj4+DQo+ID4+PiBBcyBhbiBleGFtcGxlIFBXIHRlY2hu b2xvZ3kgdG9kYXkgYWxsb3dzIGVuZCB0byBlbmQgYW5kIA0KPiBwZXIgc2VnbWVudCANCj4gPj4+ IG1vbml0b3JpbmcgYnV0IGl0IGRvZXMgbm90IGFjaGlldmUgaXQgdXNpbmcgbmVzdGVkIFBXcyBv ciANCj4gUFcgbGV2ZWxzLg0KPiA+Pj4NCj4gPj4+IEJlbg0KPiA+Pj4NCj4gPj4+DQo+ID4gDQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBt cGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscy10cCBtYWlsaW5nIGxp c3QNCj4gbXBscy10cEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMtdHANCj4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g b3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNj YW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0005F72D4825759E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisrMTwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtCVVNJIElUQUxPJnF1 b3Q7DQombHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdCZndDs8L2I+IDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLXRwLWJv dW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAwOS0wNC0xNyAyMTo1OTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4sICZxdW90O1ZJR09VUkVVWCBNQVJUSU4mcXVvdDsgJmx0O01hcnRp bi5WaWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tJmd0OywNCiZxdW90O0JlbiBOaXZlbi1KZW5r aW5zJnF1b3Q7ICZsdDtiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbSZndDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPm1wbHMtdHBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbbXBscy10 cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluDQpNUExTLVRQICh3YXMgUkU6IEFzc29jaWF0ZWQgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmlkaXJlY3Rpb25hbA0KdHJhbnNwb3J0IHBhdGggcmVx dWlyZW1lbnRzKTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+KzEgPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsgRnJvbTogQW5uYW1hcmlhIEZ1bGlnbm9saSBbbWFpbHRvOmFubmFtYXJpYS5m dWxpZ25vbGlAZXJpY3Nzb24uY29tXQ0KPGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDE3 LCAyMDA5IDE6NTIgUE08YnI+DQomZ3Q7IFRvOiBWSUdPVVJFVVggTUFSVElOOyBCZW4gTml2ZW4t SmVua2luczxicj4NCiZndDsgQ2M6IEJVU0kgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQom Z3Q7IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAg KHdhcyBSRTogPGJyPg0KJmd0OyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzKTxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBhbGwsPGJyPg0KJmd0OyBz b3JyeSBidXQgSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgd2UgY2Fubm90IGV4cGxpY2l0bHkgdXNl IDxicj4NCiZndDsgdGhlIHRlcm0gVGFuZGVtIENvbm5lY3Rpb24gaW4gdGhlIHJlcXVpcmVtZW50 cyBkb2N1bWVudCE8YnI+DQomZ3Q7IFRDTSBpcyBub3QgYSBzb2x1dGlvbiwgaXQgaXMgcGFydCBv ZiBmdW5jdGlvbmFsIGFyY2hpdGVjdHVyZSA8YnI+DQomZ3Q7IG9mIGEgdHJhbnNwb3J0IG5ldHdv cmtzIGFzIGRlc2NyaWJlZCBpbiBHLjgwNS4gVGhlIHNvbHV0aW9uIDxicj4NCiZndDsgaXMgdG8g cmVhbGl6ZSBpdCB3aXRoIGxhYmVsIHN0YWNraW5nIHJhdGhlciB0aGFuIE1FTC4gPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFJlZ2FyZHM8YnI+DQomZ3Q7IEFubmFtYXJpYTxicj4NCiZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZyA8YnI+DQomZ3Q7IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTWFydGluIFZpZ291cmV1eDxicj4NCiZndDsgU2VudDogdmVuZXJkqKwgMTcgYXByaWxl IDIwMDkgMTMuMjk8YnI+DQomZ3Q7IFRvOiBCZW4gTml2ZW4tSmVua2luczxicj4NCiZndDsgQ2M6 IEJVU0kgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbbXBs cy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyBSRTogPGJyPg0KJmd0OyBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTxicj4N CiZndDsgPGJyPg0KJmd0OyBCZW4sIGFsbDxicj4NCiZndDsgPGJyPg0KJmd0OyBpbiBtcGxzLXRw LW9hbS1yZXF1aXJlbWVudCwgdGhlIHRleHQgb24gdGhpcyBpdGVtIGlzIGFzIGZvbGxvd3M6PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhlIHNlcnZpY2UgZW11bGF0ZWQgYnkg YSBzaW5nbGUgc2VnbWVudCBvciBhIG11bHRpLXNlZ21lbnQNClBXIG1heTxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyBzcGFuIG11bHRpcGxlIGRvbWFpbnMuICZuYnNwO0EgTFNQIG1heSBhbHNvIHNw YW4gbXVsdGlwbGUNCmRvbWFpbnMuICZuYnNwO0l0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IE1V U1QgYmUgcG9zc2libGUgdG8gcGVyZm9ybSBPQU0gZnVuY3Rpb25zIG9uIGEgcGVyIGRvbWFpbg0K PGJyPg0KJmd0OyBiYXNpcyBhbmQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgYWNyb3NzIG11bHRp cGxlIGRvbWFpbnMuICZuYnNwO01vcmUgZ2VuZXJhbGx5IGl0IE1VU1QNCmJlIHBvc3NpYmxlIHRv PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHBlcmZvcm0gT0FNIGZ1bmN0aW9ucyBiZXR3ZWVuIGFu eSB0d28gc3dpdGNoaW5nIGVsZW1lbnRzDQo8YnI+DQomZ3Q7IChlLmcuLCBMU1I8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgb3IgUy1QRSkgb2YgYSBMU1Agb3Igb2YgUFcuICZuYnNwO1RoaXMgaXMg cmVmZXJyZWQgdG8NCmFzIChjb25jYXRlbmF0ZWQpPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHNl Z21lbnQgbW9uaXRvcmluZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBiZWxpZXZlIHRoZSB0ZXh0 IGRlc2NyaWJlcyBhIGZ1bmN0aW9uYWwgcmVxLjxicj4NCiZndDsgPGJyPg0KJmd0OyBEdXJpbmcg bWVhZCB0ZWFtIHJldmlldywgdGhlIHJlbW92YWwgb2YgdGhlIGxhc3Qgc2VudGVuY2Ugd2FzIDxi cj4NCiZndDsgZGlzY3Vzc2VkLjxicj4NCiZndDsgTm8gc3Ryb25nIG9waW5pb24gd2FzIGV4cHJl c3NlZCBvbiB3aGV0aGVyIGl0IHNob3VsZCA8YnI+DQomZ3Q7IGVmZmVjdGl2ZWx5IGJlIHJlbW92 ZWQgb3Igbm90Ljxicj4NCiZndDsgPGJyPg0KJmd0OyByZWdhcmRzLDxicj4NCiZndDsgbWFydGlu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlbiBOaXZlbi1KZW5raW5zIGEgqKZjcml0IDo8YnI+DQom Z3Q7ICZndDsgSXRhbG8sPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHRoaW5rIHdl IGFyZSBjb252ZXJnaW5nLiBJZiBJIGNhbiBiZSBzbyBib2xkIGFzIHRvIHNwZWFrIG9uDQpoaXMg PGJyPg0KJmd0OyAmZ3Q7IGJlaGFsZiBBZHJpYW4ncyBvYmplY3Rpb24gc2VlbWVkIHRvIGJlIHRv IHRoZSB1c2Ugb2YgdGhlIHRlcm0NClRDTS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IEl0IGlzIGRlZmluZWQgaW4gdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzIGJ1dCBub3QgdXNlZC48 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEl0IGlzIG5vdCB1c2VkIGluIHRoZSBNUExT LVRQIE9BTSByZXF1aXJlbWVudHMgZG9jdW1lbnQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBUaGVyZWZvcmUgSSB0aGluayB0aGUgd2F5IGZvcndhcmQgaXMgYXMgZm9sbG93czo8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDEpIFJlbW92ZSB0aGUgdGVybSBUYW5kZW0gQ29u bmVjdGlvbiBmcm9tIHRoZSBNUExTLVRQIDxicj4NCiZndDsgcmVxdWlyZW1lbnRzIGFzIDxicj4N CiZndDsgJmd0OyBpdCBpcyByZWR1bmRhbnQgKGkuZS4gTm90IHVzZWQgaW4gdGhhdCBkb2N1bWVu dCkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAyKSBFbnN1cmUgdGhlIE1QTFMtVFAg T0FNIHJlcXVpcmVtZW50cyBleHByZXNzIHRoZSBuZWNlc3NhcnkNCjxicj4NCiZndDsgJmd0OyBm dW5jdGlvbmFsIHJlcXVpcmVtZW50cyBhcm91bmQgbW9uaXRvcmluZyBvZiBlbmQgdG8gZW5kIDxi cj4NCiZndDsgcGF0aHMgYXMgd2VsbCA8YnI+DQomZ3Q7ICZndDsgYXMgcGFydHMgb2YgZW5kIHRv IGVuZCBwYXRocy4gVGhpcyBjYW4gYmUgZG9uZSB3aXRob3V0IHJlZmVycmluZw0KPGJyPg0KJmd0 OyAmZ3Q7IGV4cGxpY2l0bHkgdG8gVGFuZGVtIENvbm5lY3Rpb25zLjxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgV2hlbiBpdCBjb21lcyB0byBzb2x1dGlvbiBkZXNpZ24gd2UgY2FuIGRl Y2lkZSB3aGF0IGlzIHRoZSBiZXN0DQo8YnI+DQomZ3Q7ICZndDsgbWVjaGFuaXNtIHRvIGFjaGll dmUvaW1wbGVtZW50IHRob3NlIHJlcXVpcmVtZW50cyBiZSBpdCBMU1AgPGJyPg0KJmd0OyBoaWVy YXJjaHkgb3Igc29tZXRoaW5nIGVsc2UuPGJyPg0KJmd0OyAmZ3Q7IFRoZSBKV1QgaGFzIHByb3Zl ZCB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIG1lZXQgdGhvc2UgcmVxdWlyZW1lbnRzDQo8YnI+DQom Z3Q7ICZndDsgdXNpbmcgZXhpc3RpbmcgTVBMUyB0ZWNobm9sb2d5IChtYXliZSB3aXRoIHNvbWUg ZW5oYW5jZW1lbnRzKS4NCkkgZG8gPGJyPg0KJmd0OyAmZ3Q7IG5vdCBiZWxpZXZlIHdlIGhhdmUg dG8gbmVjZXNzYXJpbHkgdXNlIHRoZSBzb2x1dGlvbiB0aGV5IHByb3Bvc2UNCjxicj4NCiZndDsg Jmd0OyBhc2xvbmcgYXMgd2hhdGV2ZXIgc29sdXRpb24gd2UgdWx0aW1hdGVseSBkZWNpZGUgdXBv biBtZWV0cyBhbGwNCnRoZSA8YnI+DQomZ3Q7ICZndDsgbmVjZXNzYXJ5IHJlcXVpcmVtZW50cyBl eHByZXNzZWQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBDYW4gd2UgYWdyZWUgb24g dGhhdCBhcyBhbiBhcHByb2FjaCBhbmQgY2xvc2UgdGhpcyBvZmYgZm9yIG5vdz88YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJlbjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IE9uIDE3LzA0LzIwMDkgMTA6NDksICZxdW90O0JVU0kgSVRBTE8mcXVv dDsgPGJyPg0KJmd0OyAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdCZndDsgd3JvdGU6 PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQmVuLDxicj4NCiZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgd2UgYXJlIG1peGluZyBzb2x1dGlvbnMgd2l0 aCByZXF1aXJlbWVudHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhl IHJlcXVpcmVtZW50IGZvciB0aGUgVENNIGZ1bmN0aW9uIGlzIGNsZWFybHkgZGVmaW5lZCBhbmQN CkkgZG8gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGluayBpdCBtdXN0IGJlIGFkZHJlc3NlZCBieSB0 aGUgTVBMUy1UUCBkZXNpZ24uPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsg VGhlIHNvbHV0aW9uIGV2YWx1YXRlZCBieSB0aGUgSldUIHRvIG1lZXQgdGhpcyByZXF1aXJlbWVu dA0KPGJyPg0KJmd0OyB3YXMgdG8gdXNlIDxicj4NCiZndDsgJmd0OyZndDsgbGFiZWwgc3RhY2tp bmcgd2l0aCBhIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgVENNIExTUA0KYW5kIHRoZSA8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGUyZSBMU1AuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsgSSB0aGluayB0aGlzIHNvbHV0aW9uLCBhbHRob3VnaCBub3QgdGhlIGJlc3QgdGVj aG5pY2FsIG9wdGlvbiwNCmlzIDxicj4NCiZndDsgJmd0OyZndDsgZ29vZCBlbm91Z2ggYW5kIG1l ZXRzIHRoZSByZXF1aXJlbWVudHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgSG93ZXZlciB0aGlzIGlzIGlzIGEgc29sdXRpb24gYW5kIGhhcyBub3QgaW1wYWN0IG9uIHRo ZSA8YnI+DQomZ3Q7IHJlcXVpcmVtZW50Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IEl0YWxvPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTogQmVu IE5pdmVuLUplbmtpbnMgW21haWx0bzpiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbV08YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDE3LCAyMDA5IDExOjIyIEFN PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgVG86IEJVU0kgSVRBTE87IEFkcmlhbiBGYXJyZWw7IEFs ZXhhbmRlciBWYWluc2h0ZWluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQ2M6IG1wbHMtdHBAaWV0 Zi5vcmc7IExvdSBCZXJnZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogVGFu ZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyBSRTogW21wbHMtdHBdDQo8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVx dWlyZW1lbnRzKTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg SXRhbG8sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBPbiAx Ny8wNC8yMDA5IDA5OjM0LCAmcXVvdDtCVVNJIElUQUxPJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgJmx0O0l0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQmZ3Q7IHdyb3RlOjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgSldUIGFncmVlbWVudCBpcyB0byBicmluZyB0aGUgSVRV LVQgdHJhbnNwb3J0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgcmVxdWlyZW1lbnRzIGluIElFVEY8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdG8gZXh0ZW5kIHRoZSBNUExTIGFyY2hpdGVjdHVy ZSB0byBtZWV0IHRoZW0gaW4gYQ0Kd2F5IHRoYXQgaXMgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IGNvbXBhdGlibGUsIGNvbnNpc3RlbnQgYW5kIGNvaGVyZW50IHdpdGggZXhpc3RpbmcNCklF VEYgPGJyPg0KJmd0OyBhcmNoaXRlY3R1cmUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgU28gSSB0 b29rIGEgbG9vayBhdCB0aGUgSldUIHJlcG9ydC4gSXQgc2F5cyAoc2xpZGUgMTYpPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAmcXVvdDsgU2VydmljZSBQcm92 aWRlcnMgd2FudCBMU1BzL1BXRXMgdG8gYmUgYWJsZSB0bw0KYmUgPGJyPg0KJmd0OyBtYW5hZ2Vk IGF0IHRoZSA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBkaWZmZXJlbnQgbmVzdGVkIGxldmVscyBz ZWFtbGVzc2x5IChwYXRoLCBzZWdtZW50LCBtdWx0aXBsZQ0KPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgc2VnbWVudHMpPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBha2EgVGFu ZGVtIENvbm5lY3Rpb24gTW9uaXRvcmluZyAoVENNKSwNCnRoaXMgaXMgdXNlZCA8YnI+DQomZ3Q7 IGZvciBleGFtcGxlIDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHdoZW4gYSBMU1AvUFdFIGNyb3Nz ZXMgbXVsdGlwbGUgYWRtaW5pc3RyYXRpb25zJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBJTU8gdGhlIHJlcXVpcmVtZW50IGlzIHRvIGJlIGFibGUg dG8gbW9uaXRvciBwYXJ0cyBvZg0KYSA8YnI+DQomZ3Q7IHBhdGggYXMgd2VsbCA8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBhcyB0aGUgZW5kIHRvIGVuZCBwYXRoLiBUaGVyZSBhcmUgbWFueSB3YXlz IHRvIHNvbHZlDQp0aGF0IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50LCBvbmUg b2Ygd2hpY2ggaXMgdGhlIGNyZWF0aW9uIG9mIG5lc3RlZCBMU1BzLA0Kb25lIHBlciA8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyBsZXZlbCBvZiBtb25pdG9yaW5nIHJlcXVpcmVkIChteSB1bmRlcnN0 YW5kaW5nIG9mIGhvdw0KVENNIHdvcmtzKS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7IEkgdGhpbmsgdGhlIHJlYWwgZGlzY3Vzc2lvbiBpcyB0aGVyZWZvcmUg aXMgdGhlIHJlcXVpcmVtZW50DQp0byA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBtb25pdG9yIGRp ZmZlcmVudCBjb21wb25lbnRzIG9mIGFuIGVuZCB0byBlbmQgcGF0aCBvcg0KaXMgdGhlIDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50IHRoYXQgc3VjaCBtb25pdG9yaW5nIE1VU1Qg YmUgYWNoaWV2ZWQgdXNpbmcNCjxicj4NCiZndDsgbmVzdGVkIExTUHM/PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBBcyBhbiBleGFtcGxlIFBXIHRlY2hub2xv Z3kgdG9kYXkgYWxsb3dzIGVuZCB0byBlbmQgYW5kDQo8YnI+DQomZ3Q7IHBlciBzZWdtZW50IDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7IG1vbml0b3JpbmcgYnV0IGl0IGRvZXMgbm90IGFjaGlldmUg aXQgdXNpbmcgbmVzdGVkIFBXcw0Kb3IgPGJyPg0KJmd0OyBQVyBsZXZlbHMuPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBCZW48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgJmd0OyBtcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBtcGxzLXRwQGlldGYu b3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscy10cDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBtcGxzLXRwIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyA8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMtdHAgbWFpbGluZyBsaXN0 PGJyPg0KbXBscy10cEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscy10cDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0005F72D4825759E_=-- From liu.guoman@zte.com.cn Sun Apr 19 19:06:10 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3473A6949 for ; Sun, 19 Apr 2009 19:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.575 X-Spam-Level: X-Spam-Status: No, score=-97.575 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7v4sZf6YEXc for ; Sun, 19 Apr 2009 19:06:07 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BE6933A68D8 for ; Sun, 19 Apr 2009 19:05:52 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Mon, 20 Apr 2009 09:59:51 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 90033.1367178663; Mon, 20 Apr 2009 10:03:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3K24sjP086903; Mon, 20 Apr 2009 10:04:54 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <51661468CBD1354294533DA79E85955A01A6BE71@XCH-SW-5V2.sw.nos.boeing.com> To: "Drake, John E" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 20 Apr 2009 10:01:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-20 10:04:52, Serialize complete at 2009-04-20 10:04:52 Content-Type: multipart/alternative; boundary="=_alternative 000B50EC4825759E_=" X-MAIL: mse1.zte.com.cn n3K24sjP086903 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 02:06:10 -0000 This is a multipart message in MIME format. --=_alternative 000B50EC4825759E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Sm9obqO6DQogSSBkb24ndCBjb21wbGV0ZWx5IGFncmVlIHlvdXIgb3BpbmlvbnMuIGZvciB1bmlk aXJlY3Rpb25hbCBQMlAgYW5kIFAyTVAgDQpwYXRoLCBpZiB0aGVyZSBpcyBubyByZXR1cm4gcGF0 aCwgaG93IGNhbiBzaW5rIHBvaW50cyByZXBseSB0byBzb3VyY2UgDQpwb2ludCdzIHJlcXVlc3Qg cGFja2V0PyBpZiB0aGVyZSBhcmUgc29tZSBmYXVsdHMgaW4gdGhlIGJhY2t3YXJkIHNlY3Rpb25z IA0Kb2YgdGhpcyB1bmlkaXJlY3Rpb25hbCBwYXRoLCB0aGUgc2luayBwb2ludHMgd2lsbCBkZXRl Y3RzIHRoZSBkZWZlY3RzLCBpZiANCm5vIHJldHVybiBwYXRoLCBob3cgY2FuIHRoZSBzaW5rIHBv aW50cyBub3RpZnkgdGhlIGZhdWx0IG1lc3NhZ2UgdG8gc291cmNlIA0KcG9pbnRzLg0KYW5kIHNv LCBJIHRoaW5rIGlmIHRoZXJlIGlzIG5vIHJldHVybiBwYXRoLCB3aGF0IGhhcHBlbmVkIHRvIA0K dW5pZGlyZWN0aW9uYWwgUDJQIGFuZCBQMk1QID8NCkkgdGhpbmsgd2UgY29uc2lkZXIgdGhlIHJl dHVybiBwYXRoLg0KDQpyZWdhcmRzDQpsaXUNCg0KDQoNCiJEcmFrZSwgSm9obiBFIiA8Sm9obi5F LkRyYWtlMkBib2VpbmcuY29tPiANCreivP7IyzogIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0K MjAwOS0wNC0xOCAwMzowMg0KDQrK1bz+yMsNCiJCVVNJIElUQUxPIiA8SXRhbG8uQnVzaUBhbGNh dGVsLWx1Y2VudC5pdD4sICJBbGV4YW5kZXIgVmFpbnNodGVpbiIgDQo8QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20+LCAiTWFhcnRlbiBWaXNzZXJzIiANCjxtYWFydGVuLnZpc3NlcnNA aHVhd2VpLmNvbT4NCrOty80NCm1wbHMtdHBAaWV0Zi5vcmcNCtb3zOINClJlOiBbbXBscy10cF0g QXNzb2NpYXRlZCBiaWRpcm9lY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0K DQoNCg0KDQoNCkl0YWxvLA0KDQpBcyBkZXNjcmliZWQgaW4gdGhlIE1QTFMgVFAgT0FNIFJlcXVp cmVtZW50cyBJLUQsIHZpcnR1YWxseSBhbGwgb2YgdGhlDQpPQU0gZnVuY3Rpb25zIHJlcXVpcmUg YSByZXR1cm4gcGF0aCwgYW5kIGluIHRoZSBhYnNlbmNlIG9mIGEgcmV0dXJuIHBhdGgNCnRoZXkg YXJlIGRpc2FibGVkLg0KDQpBcyBkZXNjcmliZWQgaW4gRGF2aWQgU2luaWNyb3BlJ3MgbWVldGlu ZyBtaW51dGVzDQooaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvbWlzYy9tcGxzLWludGVyb3Av YXR0YWNobWVudC93aWtpL21lZXRpbmctbm8NCnRlcy8yMDA4MTAxNS5tcGxzLWludGVyb3AtZHQt bm90ZXMuemlwKSwgaWYgSVAgYWRkcmVzc2luZyBpcyB1c2VkLCBhbg0KTVBMUyBUUCBuZXR3b3Jr IG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgZ2V0dGluZyBJUCBwYWNrZXRzIGZyb20NCmRlc3RpbmF0 aW9uIHRvIHNvdXJjZTsgbmVpdGhlciB0aGUgbWludXRlcyBub3IgSSBzdGlwdWxhdGUgdGhhdCBh DQpjb250cm9sIHBsYW5lIG5lZWRzIHRvIGJlIHVzZWQgdG8gaW5zdGFudGlhdGUgdGhpcyBmb3J3 YXJkaW5nLg0KDQpBcyBhbiBhc2lkZSwgdGhlIGlzc3VlIG9mIHJldHVybiBwYXRoIGZvciB1bmlk aXJlY3Rpb25hbCBMU1BzIGNvdWxkIGJlDQpjaGFyYXRlcml6ZWQgYXMgdGhlIGVsZXBoYW50IGlu IHRoZSByb29tLiAgSW4gdGhlIE1QTFMgVFAgT0FNIEZyYW1ld29yaw0KSS1ELCB1bmljYXN0IExT UHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRpbWVzIGFuZCByZXR1cm4gcGF0aHMgbm90IGF0 DQphbGwuIA0KDQpUaGFua3MsDQoNCkpvaG4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQlVTSSBJVEFMTyBbbWFpbHRvOkl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXRd IA0KPiBTZW50OiBGcmlkYXksIEFwcmlsIDE3LCAyMDA5IDE6NTkgQU0NCj4gVG86IERyYWtlLCBK b2huIEU7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gQ2M6IG1wbHMt dHBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IA0KPiBwYXRoIHJlcXVpcmVtZW50cw0KPiANCj4gSm9obiwNCj4gDQo+ IEkgbWlnaHQgaGF2ZSBtaXNzZWQgdGhlIGFncmVlbWVudCBvZiBNUExTLVRQIGJlaW5nIGNhcGFi bGUgb2YgDQo+IHNlbmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2VudCBvbiB1bmktZGly ZWN0aW9uYWwgTFNQcy4NCj4gDQo+IFRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3QgYmVsb25nIHRv IHRoZSBmaXJzdCBzZXQgb2YgDQo+IHJlcXVpcmVtZW50cyBJVFUtVCBpcyBleHBlY3RpbmcgdG8g YmUgbWV0IGJ5IE9jdG9iZXIuDQo+IA0KPiBIb3dldmVyLCBJIHRoaW5rIHRoaXMgaW4gYSBwb3Rl bnRpYWwgaW50ZXJlc3RpbmcgYWRkaXRpb25hbCANCj4gcmVxdWlyZW1lbnQgdG8gYmUgdGFrZW4g aW50byBhY2NvdW50IChhdCB3b3JzdCBpbiBhIHN1YnNlcXVlbnQgcGhhc2UpLg0KPiANCj4gSSB0 aGluayB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgbmVlZHMgdG8gYmUgZXZhbHVhdGVkIHZlcnN1cyAN Cj4gb3RoZXIgbW9yZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJpbGl0 eSB0byANCj4gd29yayB3L28gSVAgZm9yd2FyZGluZyBhbmQgdGhlIG5lZWQgZm9yIE9BTSB0byBj b250aW51ZSB0byANCj4gbW9uaXRvciB0aGUgZGF0YSBwbGFuZSBhbHNvIGluIGNhc2Ugb2YgZmFp bHVyZXMgYWZmZWN0aW5nIHRoZSANCj4gY29udHJvbCBvciBtYW5hZ2VtZW50IHBsYW5lKS4NCj4g DQo+IEkgYW0gb3BlbiB0byBkaXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdo dCB0aW1lIA0KPiBiZWNhdXNlIEkgd2lzaCB0byBhdm9pZCBkZWxheWluZyB0aGUgZmlyc3QgcGhh c2Ugb2YgdGhlIA0KPiBkZXNpZ24gc29sdXRpb24uDQo+IA0KPiBUaGFua3MsIEl0YWxvDQo+IA0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbXBscy10cC1ib3VuY2Vz QGlldGYub3JnDQo+ID4gW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBEcmFrZSwgSm9obiBFDQo+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDg6 MDAgUE0NCj4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KPiA+ IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gcmVxdWlyZW1lbnRzDQo+ID4g DQo+ID4gQXQgdGhlIG1lZXRpbmcgbGFzdCBmYWxsIGF0IEp1bmlwZXIgaW4gTWFzc2FjaHVzZXR0 cywgSSANCj4gdGhpbmsgaXQgd2FzIA0KPiA+IGFncmVlZCB0aGF0IGFuIE1QTFMgVFAgbmV0d29y ayBuZWVkcyB0byBoYXZlIGEgZm9yd2FyZGluZyANCj4gY2FwYWJpbGl0eSANCj4gPiBmb3IgbWFu YWdlbWVudCwgY29udHJvbCwgYW5kIE9BTSBwYWNrZXRzIChlLmcuLCBzZW5kaW5nIA0KPiByZXBs aWVzIHRvIE9BTSANCj4gPiByZXF1ZXN0cyBzZW50IG9uIHVuaS1kaXJlY3Rpb25hbCBMU1BzKSBl dmVuIGlmIGl0IGRvZXMgbm90IA0KPiBoYXZlIGFuIElQIA0KPiA+IGZvcndhcmRpbmcgZGF0YSBw bGFuZS4NCj4gPiANCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9t OiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiA+IFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb21dDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgOTo1NyBB TQ0KPiA+ID4gVG86IE1hYXJ0ZW4gVmlzc2Vycw0KPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcN Cj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIA0KPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiANCj4gPiA+IE1hYXJ0ZW4s DQo+ID4gPiBJdCBzZWVtcyB0aGF0IHlvdSd2ZSBqdXN0IChpbXBsaWNpdGx5IGFuZCwgcHJvYmFi bHksDQo+ID4gPiBpbmFkdmVydGVudGx5KSBzdGF0ZWQgdGhlIGZvbGxvd2luZzoNCj4gPiA+IA0K PiA+ID4gICAgICAgICAgICBNUExTLVRQIE9BTSB3aWxsIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxv b3BiYWNrIGZ1bmN0aW9uIA0KPiAoYW5kIGZhdWx0IA0KPiA+ID4gbG9jYWxpemF0aW9uIHdoaWNo IHJlcXVpcmVzIHRoaXMgZnVuY3Rpb24gKSBmb3IgDQo+IHVuaWRpcmVjdGlvbmFsIFAyTVAgDQo+ ID4gPiBhbmQgUDJQIHBhdGhzLg0KPiA+ID4gDQo+ID4gPiBJZiB0aGlzIHN0YXRlbWVudCBpcyBj b3JyZWN0LCB0aGlzIChJTUhPIGFuZCBGV0lXKSByYWlzZXMgYSB2YWxpZCANCj4gPiA+IHF1ZXN0 aW9uOg0KPiA+ID4gDQo+ID4gPiAgICAgICAgICAgIElzIE1QTFMtVFAgYW4gYXBwcm9wcmlhdGUg c29sdXRpb24gZm9yIHRoZXNlIHR5cGVzIG9mIA0KdHJhbnNwb3J0IA0KPiA+ID4gcGF0aHM/DQo+ ID4gPiANCj4gPiA+IEZvciB0aGUgcmVmZXJlbmNlLCBJUC9NUExTIHByb3ZpZGVzIHRoaXMga2lu ZCBvZiANCj4gZnVuY3Rpb25hbGl0eSB0b2RheSANCj4gPiA+IGZvciAodW5pZGlyZWN0aW9uYWwg LSBidXQgaXQgZG9lcyBub3Qga25vdyBhbnkgb3RoZXIgDQo+IHR5cGUpIFAyUCBMU1BzIA0KPiA+ ID4gYXMgZGVzY3JpYmVkIGluIFJGQyA0Mzc5LiBBbmQgaXRzIGV4dGVuc2lvbiB0byBQMk1QIExT UHMgc2VlbXMgDQo+ID4gPiBlYXN5Li4uDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBS ZWdhcmRzLA0KPiA+ID4gDQo+ID4gPiAgICAgIFNhc2hhDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4g DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBG cm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10g DQo+IE9uIEJlaGFsZiANCj4gPiA+IE9mIE1hYXJ0ZW4gVmlzc2VycyBbbWFhcnRlbi52aXNzZXJz QGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzoyNCBQ TQ0KPiA+ID4gVG86ICdBZHJpYW4gRmFycmVsJw0KPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcN Cj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIA0KPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiANCj4gPiA+IEFkcmlhbiwN Cj4gPiA+IA0KPiA+ID4gPj4gPHF1b3RlPg0KPiA+ID4gPj4gICAgICBUaGUgaW50ZXJtZWRpYXRl IG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQNCj4gPiA+IG90aGVyIGludGVybmFsDQo+ ID4gPiA+PiAgICAgICBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkDQo+ ID4gPiBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPiA+ID4gPj4gICAgICAgcGF0aCBhdCBlYWNo IChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmcNCj4gPiA+ID4+ICAgICAg IHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkDQo+ID4gPiBkaXJl Y3Rpb25zIG9mIHRoYXQNCj4gPiA+ID4+ICAgICAgIHRyYW5zcG9ydCBwYXRoLg0KPiA+ID4gPj4g PGVuZCBxdW90ZT4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlcmUgaXMgbm8gd2F5IHRoaXMgaXMgYSBm dW5jdGlvbmFsIHJlcXVpcmVtZW50LiBUaGF0DQo+ID4gaXMsIHRoZXJlIGlzDQo+ID4gPiA+ICpu b3RoaW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mDQo+ ID4gdmlldyB0aGF0DQo+ID4gPiA+IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlzIHJlcXVp cmVtZW50Lg0KPiA+ID4gDQo+ID4gPiBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3Qu IEl0IGlzIHZlcnkgbXVjaCBvYnNlcnZhYmxlIGlmIA0KPiA+ID4gdGhpcyByZXF1aXJlbWVudCBp cyBtZXQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZiB2aWV3Lg0KPiA+ID4gVGhlIE1JUCBmdW5j dGlvbnMgY2FuIG9ubHkgcGVyZm9ybSB0aGUgTG9vcGJhY2sgd2hlbiB0aGVyZSBpcyBhIA0KPiA+ ID4gY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoZSBNUExTLVRQIExC TSBwYWNrZXQgDQo+ID4gPiByZWNlaXZlZCBhdCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5lZCAo YXMgTEJSDQo+ID4gPiBwYWNrZXQpIHRvIHRoZSBvcmlnaW5hdGluZyBNRVAgZnVuY3Rpb24gdmlh IHRoZSBvdGhlciANCj4gZGlyZWN0aW9uIG9mIA0KPiA+ID4gdGhlIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoLiBUaGlzIG90aGVyIGRpcmVjdGlvbiANCj4gPiA+IHdvdWxk IG5vdCBiZSBhdmFpbGFibGUgaW4gYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCANCj4gPiA+IHBhdGguLi4gYW5kIHRodXMgdGhlIGxvb3BiYWNrIHRlc3QNCj4gPiB3b3VsZCBm YWlsLg0KPiA+ID4gDQo+ID4gPiBTaW1pbGFybHksIHdoZW4gd2UgaGF2ZSB0byBhcHBseSBUQ00g TUVQcyB0byBtb25pdG9yIGEgDQo+IHNlZ21lbnQsIHRoZW4gDQo+ID4gPiB0aGlzIGlzIHBvc3Np YmxlIGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoIGJ1dCBub3QgaW4gYSANCj4g PiA+IGFzc29jaWF0ZWQgYmlkaXIgdHJhbnNwb3J0IHBhdGguIEluIHRoZSBmaXJzdCBjYXNlIHRo ZSBUQ00gTUVQIA0KPiA+ID4gU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucyBhcmUgY28tbG9jYXRl ZCBhbmQgY2FuIGV4Y2hhbmdlIHdoYXQgaXMgDQo+ID4gPiBjYWxsZWQgInJlbW90ZSBpbmZvcm1h dGlvbiIgd2hpY2ggaXMgbmVjZXNzYXJ5IGZvciBwZXJmb3JtYW5jZSANCj4gPiA+IG1vbml0b3Jp bmcuDQo+ID4gPiBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBNRVAgU291cmNlIGFuZCBTaW5r IGZ1bmN0aW9ucyANCj4gYXJlIGluIGUuZy4gDQo+ID4gPiBkaWZmZXJlbnQgbm9kZXMgaW4gdGhl IG5ldHdvcmsgYW5kIFRDTSB3b3VsZCBub3QgYmUgYWJsZSANCj4gdG8gcHJvdmlkZSANCj4gPiA+ IHBlcmZvcm1hbmNlIG1vbml0b3JpbmcuDQo+ID4gPiANCj4gPiA+ID4gVGhlIGVudGlyZXR5IG9m IHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRpbmcgTUVQcywNCj4gPiBNSVBzIGFuZCBvdGhl cg0KPiA+ID4gaW50ZXJuYWwNCj4gPiA+ID4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgc2hv dWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90DQo+ID4gPiBhZGQgdG8gIlRoZQ0KPiA+ID4gPiBp bnRlcm1lZGlhdGUgbm9kZXMuIg0KPiA+ID4gDQo+ID4gPiBZb3VyIHVuZGVyc3RhbmRpbmcgaXMg bm90IGNvcnJlY3QuIFRoaXMgdGV4dCBtdXN0IG5vdCBiZSANCj4gZGVsZXRlZCBhdCANCj4gPiA+ IGFsbC4NCj4gPiA+IA0KPiA+ID4gPiBBY3R1YWxseSwgSSBhbSBxdWl0ZSBmZWQgdXAgYWJvdXQg dGhpcyBwZXJzaXN0ZW50DQo+ID4gaW5zaXN0ZW5jZSBvbiB0aGUNCj4gPiA+IGluY2x1c2lvbg0K PiA+ID4gPiBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3aXRoaW4gdGhl IElUVS1UIG9mDQo+ID4gPiB0aGlzIHRlcm0NCj4gPiA+ID4gaXMNCj4gPiA+IHBvb3JseQ0KPiA+ ID4gPiBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1vbml0b3Jpbmcgb2YgYSBwYXRoIHRo YXQgaXMNCj4gPiA+IHBhcmFsbGVsIChpLmUuDQo+ID4gPiB0YW5kZW0pDQo+ID4gPiA+IHRvIHRo ZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24gb2YgVEMNCj4gPiA+ IHNlZW1zIHRvIGJlIGF0DQo+ID4gPiB2YXJpYW5jZSwNCj4gPiA+ID4gYW5kIHdvdWxkIGJlIGlm IHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQo+ID4gPiANCj4gPiA+IEkgZG9uJ3QgdW5k ZXJzdGFuZCB3aGVyZSB5b3VyIGludGVycHJldGF0aW9uIG9mIHRhbmRlbSANCj4gY29ubmVjdGlv biBpcyANCj4gPiA+IGRlc2NyaWJlZCBpbiBJVFUtVCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gImZy b20gdGhlIA0KPiBtb25pdG9yaW5nIG9mIGEgDQo+ID4gPiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwg KGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIA0KPiA+ID4gbW9uaXRvcmVkLiI/ DQo+ID4gPiANCj4gPiA+IFRoZXJlIGlzIGEgIm5ldHdvcmsgY29ubmVjdGlvbiIgYW5kIHRoaXMg bmV0d29yayANCj4gY29ubmVjdGlvbiBpcyBhIHNldCANCj4gPiA+IG9mIGludGVyY29ubmVjdGVk ICJsaW5rIGNvbm5lY3Rpb25zIiBhbmQgIm1hdHJpeCBjb25uZWN0aW9ucyIuIEEgDQo+ID4gPiBz dWJzZXQgb2YgdGhvc2UgaW50ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQgbWF0cml4 IA0KPiA+ID4gY29ubmVjdGlvbnMgY2FuIGJlIG1vbml0b3JlZCBhbmQgaXMgdGhlbiByZWZlcnJl ZCB0byBhcyBhICJ0YW5kZW0gDQo+ID4gPiBjb25uZWN0aW9uIi4gVGhlcmUgaXMgbm8gInBhdGgg dGhhdCBpcyBwYXJhbGxlbCB0byB0aGUgDQo+IGRhdGEgcGF0aCIuIA0KPiA+ID4gVGhlcmUgaXMg b25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBpbnNpZGUgdGhlIGRhdGEgcGF0aCBieSB0aGUg DQo+ID4gPiBUQ00gTUVQX1NvIGZ1bmN0aW9uIGFuZCB0aGlzIE9BTSBpcyBleHRyYWN0ZWQgZnJv bSB0aGUgDQo+IGRhdGEgcGF0aCBieSANCj4gPiA+IHRoZSBUQ00gTUVQX1NrIGZ1bmN0aW9uLg0K PiA+ID4gDQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4gTWFhcnRlbg0KPiA+ID4gDQo+ID4gPiANCj4g PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBtcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmcNCj4gPiA+IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiA+ID4gU2VudDogZG9uZGVyZGFnIDE2IGFwcmlsIDIw MDkgMTE6NTkNCj4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgYmVuamFtaW4ubml2ZW4t amVua2luc0BidC5jb20NCj4gPiA+IENjOiBCVVNJIElUQUxPOyBtcGxzLXRwQGlldGYub3JnDQo+ ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCANCj4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gDQo+ID4gPiBIaSBTYXNoYSwN Cj4gPiA+IA0KPiA+ID4gPiBVbmZvcnR1bmF0ZWx5IEkgY2Fubm90IGZ1bGx5IGFncmVlIHdpdGgg eW91ciBzdGF0ZW1lbnQ6DQo+ID4gPiA+DQo+ID4gPiA+IDxxdW90ZT4NCj4gPiA+ID4gICAgIEZy b20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZA0KPiA+IGJpZGlyZWN0 aW9uYWwgTFNQcw0KPiA+ID4gPiAgICAgYXJlIGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbCBMU1BzLg0KPiA+ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPg0KPiA+ID4g PiBUaGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZSBpdCBub3Qg Zm9yDQo+ID4gPiBSZXF1aXJlbWVudA0KPiA+ID4gPiAzNCBpbiB0aGUgbGF0ZXN0IE1QTFMtVFAg cmVxdWlyZW1lbnRzIGRyYWZ0DQo+ID4gPiANCj4gPiA+IE9LLiBHb3QgaXQuDQo+ID4gPiANCj4g PiA+IEJ1dCB3aGF0IGlzIHRoaXMgZG9pbmcgaW4gdGhlIGRhdGEgcGxhbmUgcmVxdWlyZW1lbnRz IHNlY3Rpb24/DQo+ID4gPiANCj4gPiA+IEluIGZhY3QsIHdoYXQgaXMgdGhpcyByZXF1aXJlbWVu dCBhY3R1YWxseSBzYXlpbmc/DQo+ID4gPiANCj4gPiA+ID4gPHF1b3RlPg0KPiA+ID4gPiAgICAg IFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZyBNRVBzLCBNSVBzIGFuZA0KPiA+IG90 aGVyIGludGVybmFsDQo+ID4gPiA+ICAgICAgIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2Yg YSBjby1yb3V0ZWQNCj4gPiA+IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ID4gPiA+ICAgICAg IHBhdGggYXQgZWFjaCAoc3ViLSlsYXllciBNVVNUIGJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nDQo+ ID4gPiA+ICAgICAgIHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJk DQo+ID4gPiBkaXJlY3Rpb25zIG9mIHRoYXQNCj4gPiA+ID4gICAgICAgdHJhbnNwb3J0IHBhdGgu DQo+ID4gPiA+IDxlbmQgcXVvdGU+DQo+ID4gPiANCj4gPiA+IFRoZXJlIGlzIG5vIHdheSB0aGlz IGlzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdCANCj4gaXMsIHRoZXJlIGlzDQo+ID4g PiAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBv ZiANCj4gdmlldyB0aGF0IA0KPiA+ID4gcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVx dWlyZW1lbnQuDQo+ID4gPiANCj4gPiA+IFRoZXJlZm9yZSBpdCBjb3VsZCBiZSBhc3N1bWVkIHRo YXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgYnkgDQo+ID4gPiBjb25maWd1cmluZyBzb21lIGRh dGEgcGxhbmUgZGF0YWJhc2UgY29tcG9uZW50IHRocm91Z2ggdGhlIA0KPiA+ID4gbWFuYWdlbWVu dCBwbGFuZS4gVGhlIGRhdGFiYXNlIGNvbXBvbmVudCBpcyBub3QgdXNlZCBmb3IgYW55dGhpbmcg DQo+ID4gPiBleGNlcHQgdG8gc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAiYXdhcmVuZXNz Ii4NCj4gPiA+IA0KPiA+ID4gQmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdyaXRlIHRoaXMg cmVxdWlyZW1lbnQgaW4gdGVybXMgb2YgDQo+ID4gPiBiZWhhdmlvcj8NCj4gPiA+IA0KPiA+ID4g PiBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4gdGhl DQo+ID4gPiBsaXN0IHRoYXQgaXMNCj4gPiA+ID4gc3BlY2lmaWMgZm9yIGNvLXJvdXRlZCBiaWRp cmVjdGlvbmFsIExTUHMuIChUaGUgcGFpcmluZw0KPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+ IGF0IGVuZCBwb2ludHMgZm9yIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs DQo+ID4gcGF0aHMgYXJlDQo+ID4gPiA+IGV4YWN0bHkgdGhlIHNhbWUgZXZlbiBpZiB0aGV5IGFw cGVhciBpbiB0d28gZGlmZmVyZW50DQo+ID4gaXRlbXMgaW4gdGhlDQo+ID4gPiA+IHJlcXVpcmVt ZW50cycgbGlzdCkuDQo+ID4gPiA+IEluIG90aGVyIHdvcmRzLCB3aXRob3V0IFJlcXVpcmVtZW50 IDM0IHRoZSBub3Rpb24gb2YgY28tcm91dGVkIA0KPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBhdGhz IHdvdWxkIGJlIHZvaWQgb2YgYW55IGRhdGEgcGxhbmUgY29udGVudC4NCj4gPiA+ID4NCj4gPiA+ ID4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBp bnRlcm5hbCANCj4gPiA+ID4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlIikgY3JlYXRlcyBhIHN1 c3BpY2lvbiB0aGF0IEhXDQo+ID4gPiBzdXBwb3J0IG9mIHRoZQ0KPiA+ID4gPiBwYWlyaW5nIGF3 YXJlbmVzcyBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIgdG8gY29tcGx5IHdpdGggaXQuDQo+ID4g PiANCj4gPiA+IFRoZSBlbnRpcmV0eSBvZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICIoaW5jbHVkaW5n IE1FUHMsIA0KPiBNSVBzIGFuZCBvdGhlciANCj4gPiA+IGludGVybmFsIGZ1bmN0aW9ucyBhcyBh cHByb3ByaWF0ZSkiIHNob3VsZCBiZSBkZWxldGVkLiBJdCANCj4gZG9lcyBub3QgDQo+ID4gPiBh ZGQgdG8gIlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KPiA+ID4gDQo+ID4gPiA+IFRoZSBmb2xs b3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KPiA+ID4g Pg0KPiA+ID4gPiA8cXVvdGU+DQo+ID4gPiA+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVt IGNvbm5lY3Rpb24gaXMgYW4gDQo+IGFyYml0cmFyeSBwYXJ0IG9mIGENCj4gPiA+ID4gICB0cmFu c3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pDQo+ID4gPiBpbmRlcGVu ZGVudGx5IGZyb20gdGhlDQo+ID4gPiA+ICAgZW5kLXRvLWVuZCBtb25pdG9yaW5nIChPQU0pLiAg SXQgbWF5IGJlIGEgbW9uaXRvcmVkIA0KPiBzZWdtZW50IG9yIGENCj4gPiA+ID4gICBtb25pdG9y ZWQgY29uY2F0ZW5hdGVkIHNlZ21lbnQgb2YgYSB0cmFuc3BvcnQgcGF0aC4gDQo+IFRoZSB0YW5k ZW0NCj4gPiA+ID4gICBjb25uZWN0aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRpbmcg ZW5naW5lKHMpIG9mDQo+ID4gPiB0aGUgbm9kZShzKQ0KPiA+ID4gPiAgIGF0IHRoZSBlZGdlKHMp IG9mIHRoZSBzZWdtZW50IG9yIGNvbmNhdGVuYXRlZCBzZWdtZW50Lg0KPiA+ID4gPiA8ZW5kIHF1 b3RlPg0KPiA+ID4gDQo+ID4gPiBBY3R1YWxseSwgSSBhbSBxdWl0ZSBmZWQgdXAgYWJvdXQgdGhp cyBwZXJzaXN0ZW50IA0KPiBpbnNpc3RlbmNlIG9uIHRoZSANCj4gPiA+IGluY2x1c2lvbiBvZiAi VGFuZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3aXRoaW4gDQo+IHRoZSBJVFUtVCBv ZiANCj4gPiA+IHRoaXMgdGVybSBpcyBwb29ybHkgc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRo ZSBtb25pdG9yaW5nIG9mIGEgDQo+ID4gPiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFu ZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIA0KPiA+ID4gbW9uaXRvcmVkLiBUaGlzIGRlZmlu aXRpb24gb2YgVEMgc2VlbXMgdG8gYmUgYXQgdmFyaWFuY2UsIA0KPiBhbmQgd291bGQgDQo+ID4g PiBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KPiA+ID4gDQo+ID4gPiA+IERv ZXNuJ3QgImZvcndhcmRpbmcgZW5naW5lIiBzb3VuZCBsaWtlIGhhcmR3YXJlIHRvIHlvdT8NCj4g PiA+IA0KPiA+ID4gWWVzLCBidXQgc28gd2hhdD8NCj4gPiA+IA0KPiA+ID4gPiBJTUhPIGl0IGlz IHdvcnRoIG5vdGluZyB0aGF0IG5laXRoZXIgdGhlIE1QTFMtVFANCj4gPiBSZXF1aXJlbWVudHMg ZHJhZnQNCj4gPiA+ID4gbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25lDQo+ID4g PiA+IA0KPiA+ID4gDQo+ID4gDQo+IChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVtZW4NCj4gPiA+ID4gdHMtMDEudHh0KSBj b250YWluIGFueSByZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoIHRhbmRlbQ0KPiA+IGNvbm5lY3Rp b25zLg0KPiA+ID4gPg0KPiA+ID4gPiBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNjdXNz ZWQgaW4gdGhlIE1QTFMtVFAgT0FNIA0KPiBGcmFtZXdvcmsgDQo+ID4gPiA+IGRyYWZ0DQo+ID4g PiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRw LW9hbS1mcg0KPiA+ID4gYW1ld29yay0wMC50eHQNCj4gPiA+ICkuDQo+ID4gPiANCj4gPiA+IFJp Z2h0Lg0KPiA+ID4gTGV0J3MganVzdCBnZXQgcmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5k IGJyaW5nIGFsbCB0aGUgSS1EcyANCj4gPiA+IGludG8gbGluZS4NCj4gPiA+IA0KPiA+ID4gPiBU aGUgYm90dG9tIGxpbmUsIElNSE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZw0KPiA+ IGNvLXJvdXRlZCB2cy4NCj4gPiA+ID4gYXNzb2NpYXRlZA0KPiA+ID4gPiBiaWRpcmVjdGlvbmFs IHBhdGhzIGlzIHN0aWxsIHJlcXVpcmVkLiBPbmUgd2F5IHRvIHByb3ZpZGUNCj4gPiA+IHRoYXQg Y291bGQNCj4gPiA+ID4gYmUgYnkgZXhwbGljaXRseSBsaW1pdGluZyBSZXF1aXJlbWVudCAzNCB0 byBzcGVjaWZpYw0KPiA+IGZ1bmN0aW9uYWxpdHkuDQo+ID4gPiANCj4gPiA+IEFncmVlZC4NCj4g PiA+IA0KPiA+ID4gQWRyaWFuDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEZyb206IEFk cmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdDQo+ID4gPiBTZW50OiBUaHVyc2RheSwg QXByaWwgMTYsIDIwMDkgMTI6MTMgQU0NCj4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsg TG91IEJlcmdlcjsgQlVTSSBJVEFMTw0KPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCBwYXRoIA0KPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiANCj4gPiA+IEhpIFNhc2hhLA0KPiA+ ID4gDQo+ID4gPiBOb3QgcmVhbGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3JlcHJlc2VudGlu ZyBhbnlvbmUsIGJ1dC4uLg0KPiA+ID4gDQo+ID4gPiA+IDEuIE15IHJlYWRpbmcgb2YgIG9uZSBv ZiBCZW4ncyAgbWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkIA0KPiA+ID4gPiBiaWRpcmVjdGlv bmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBvZiBwYXRocyB0aGF0IGNhbiBiZQ0KPiA+ID4g Y3JlYXRlZCBpbg0KPiA+ID4gPiB0aGUgZXhpc3RpbmcgbmV0d29ya3M7ICJ0cnVlIiBjby1yb3V0 ZWQgYmlkaXJlY3Rpb25hbCBwYXRocw0KPiA+ID4gd2lsbCBoYXZlDQo+ID4gPiA+IHRvIHdhaXQg dW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lcyBhdmFpbGFibGUuDQo+ID4gPiAN Cj4gPiA+IFRoaXMgaXMgY2xlYXJseSBub25zZW5zZSENCj4gPiA+IEZyb20gdGhlIHBvaW50IG9m IHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCANCj4gYmlkaXJlY3Rpb25hbCBMU1BzIGFyZSAN Cj4gPiA+IGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0K PiA+ID4gDQo+ID4gPiBJZiB5b3UgY2FuIHNldCB1cCB0d28gdW5pZGlyZWN0aW9uYWwgTFNQcyAo ZS5nLiB1c2luZyB0aGUgDQo+IG1hbmFnZW1lbnQgDQo+ID4gPiBwbGFuZSkgeW91IGNhbiBzdXJl bHkgc2V0IHVwIGEgY28tcm91dGVkDQo+ID4gYmlkaXJlY3Rpb25hbCBMU1AuDQo+ID4gPiANCj4g PiA+IFRoZXJlIGFyZSBzaGlwcGluZyBzb2x1dGlvbnMgdGhhdCBhY2hpZXZlIGNvLXJvdXRlZCBi aWRpcmVjdGlvbmFsIA0KPiA+ID4gTFNQcyB1c2luZyB0aGUgY29udHJvbCBwbGFuZS4gVGhlc2Ug ZWl0aGVyIHVzZSB0aGUgR01QTFMgDQo+ICh3aGljaCBpcyANCj4gPiA+IGNsZWFuZXIpIG9yIG5v bi1zdGFuZGFyZCBwcm9wcmlldGFyeSBzb2x1dGlvbnMgKHdoaWNoIGlzIA0KPiBtZXNzeSBidXQg DQo+ID4gPiBmdW5jdGlvbmFsKS4NCj4gPiA+IA0KPiA+ID4gQnV0IChvZiBjb3Vyc2UpIHRoZSBt YW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wgcGxhbmUgDQo+IHNvbHV0aW9ucyBoYXZlIA0KPiA+ ID4gbm90aGluZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMgdGhleSBh cmUgc29mdHdhcmUgDQo+ID4gPiBzb2x1dGlvbnMuDQo+ID4gPiANCj4gPiA+ID4gMi4gTXkgcmVh ZGluZyBvZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRoYXQgdGhlIGFjdHVhbA0KPiA+ID4g ZHJpdmVyIGZvcg0KPiA+ID4gPiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUg ZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIA0KPiA+ID4gPiB0cmFuc3BvcnQgbmV0d29ya3MgcmF0 aGVyIHRoYW4gYW55IHNwZWNpZmljIGJlbmVmaXQuDQo+ID4gPiANCj4gPiA+IElzbid0IHRoYXQg dGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPw0KPiA+ID4gV2hp Y2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0aGluZy4NCj4gPiA+IA0KPiA+ID4gQSBsYXJn ZSBkcml2ZXIgZm9yIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsgDQo+IHRo ZSBsb29rLCANCj4gPiA+IGZlZWwsIGFuZCBiZWhhdmlvcmFsIGNoYXJhY3RlcmlzdGljcyBvZiBh ICJsZWdhY3kiDQo+ID4gPiB0cmFuc3BvcnQgbmV0d29yay4NCj4gPiA+IA0KPiA+ID4gPiBCYXNl ZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVzcyAoRldJVykgdGhhdDoNCj4gPiA+ID4g KiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlLCBhdCBsZWFzdCBmb3IgdGhlIHRp bWUNCj4gPiA+ID4gICAgYmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mIGJpZGlyZWN0 aW9uYWwgcGF0aHMgaW4NCj4gPiA+ID4gICAgTVBMUy1UUA0KPiA+ID4gDQo+ID4gPiBJIHRoaW5r IHRoYXQgaXMgd3JvbmcgYm90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZCANCj4gZ2l2 ZW4gdGhhdCANCj4gPiA+IG90aGVyIHVwZ3JhZGVzIHRvIGV4aXN0aW5nIE1QTFMgc29sdXRpb25z IHdpbGwgYmUgbmVlZGVkIHRvIHJlYWNoIA0KPiA+ID4gdGhlIGZ1bGwgZnVuY3Rpb24gbGV2ZWwg b2YgTVBMUy1UUC4NCj4gPiA+IA0KPiA+ID4gPiAqIHRoZXkgaGFkIGEgZ29vZCBjaGFuY2UgdG8g cmVtYWluIHRoZSBvbmx5IHR5cGUgb2YgDQo+IGJpZGlyZWN0aW9uYWwNCj4gPiA+ID4gICBwYXRo cyBpbiAgcmVhbCBkZXBsb3ltZW50cy4NCj4gPiA+IA0KPiA+ID4gSSBkb24ndCBzZWUgd2hhdCB0 aGF0IGZvbGxvd3MgZnJvbS4NCj4gPiA+IA0KPiA+ID4gQ2hlZXJzLA0KPiA+ID4gQWRyaWFuDQo+ ID4gPiANCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+ID4gbXBscy10cEBpZXRmLm9yZw0K PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ID4g PiANCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KPiA+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ID4gPiAN Cj4gPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzLXRwQGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ID4gDQo+IA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAg bWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000B50EC4825759E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkpvaG6jujwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SSBkb24ndCBjb21wbGV0ZWx5IGFn cmVlIHlvdXINCm9waW5pb25zLiBmb3IgdW5pZGlyZWN0aW9uYWwgUDJQIGFuZCBQMk1QIHBhdGgs IGlmIHRoZXJlIGlzIG5vIHJldHVybiBwYXRoLA0KaG93IGNhbiBzaW5rIHBvaW50cyByZXBseSB0 byBzb3VyY2UgcG9pbnQncyByZXF1ZXN0IHBhY2tldD8gaWYgdGhlcmUgYXJlDQpzb21lIGZhdWx0 cyBpbiB0aGUgYmFja3dhcmQgc2VjdGlvbnMgb2YgdGhpcyB1bmlkaXJlY3Rpb25hbCBwYXRoLCB0 aGUgc2luaw0KcG9pbnRzIHdpbGwgZGV0ZWN0cyB0aGUgZGVmZWN0cywgaWYgbm8gcmV0dXJuIHBh dGgsIGhvdyBjYW4gdGhlIHNpbmsgcG9pbnRzDQpub3RpZnkgdGhlIGZhdWx0IG1lc3NhZ2UgdG8g c291cmNlIHBvaW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PmFuZCBzbywgSSB0aGluayBpZiB0aGVyZSBpcyBubyByZXR1cm4NCnBhdGgsIHdoYXQgaGFwcGVu ZWQgdG8gdW5pZGlyZWN0aW9uYWwgUDJQIGFuZCBQMk1QID88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgd2UgY29uc2lkZXIgdGhlIHJldHVybiBwYXRo LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+cmVnYXJk czwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+bGl1PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0RyYWtl LCBKb2huIEUmcXVvdDsNCiZsdDtKb2huLkUuRHJha2UyQGJvZWluZy5jb20mZ3Q7PC9iPiA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBs cy10cC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjIwMDktMDQtMTggMDM6MDI8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7QlVTSSBJVEFMTyZxdW90OyAmbHQ7SXRhbG8u QnVzaUBhbGNhdGVsLWx1Y2VudC5pdCZndDssDQomcXVvdDtBbGV4YW5kZXIgVmFpbnNodGVpbiZx dW90OyAmbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7LA0KJnF1b3Q7TWFh cnRlbiBWaXNzZXJzJnF1b3Q7ICZsdDttYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbSZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPm1wbHMtdHBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBb bXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcm9lY3Rpb25hbA0KdHJhbnNwb3J0IHBhdGggcmVxdWly ZW1lbnRzPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD5JdGFsbyw8YnI+DQo8YnI+DQpBcyBkZXNjcmliZWQgaW4gdGhlIE1QTFMgVFAgT0FN IFJlcXVpcmVtZW50cyBJLUQsIHZpcnR1YWxseSBhbGwgb2YgdGhlPGJyPg0KT0FNIGZ1bmN0aW9u cyByZXF1aXJlIGEgcmV0dXJuIHBhdGgsIGFuZCBpbiB0aGUgYWJzZW5jZSBvZiBhIHJldHVybiBw YXRoPGJyPg0KdGhleSBhcmUgZGlzYWJsZWQuPGJyPg0KPGJyPg0KQXMgZGVzY3JpYmVkIGluIERh dmlkIFNpbmljcm9wZSdzIG1lZXRpbmcgbWludXRlczxicj4NCihodHRwOi8vd2lraS50b29scy5p ZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9hdHRhY2htZW50L3dpa2kvbWVldGluZy1ubzxicj4N CnRlcy8yMDA4MTAxNS5tcGxzLWludGVyb3AtZHQtbm90ZXMuemlwKSwgaWYgSVAgYWRkcmVzc2lu ZyBpcyB1c2VkLCBhbjxicj4NCk1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBiZSBjYXBhYmxlIG9m IGdldHRpbmcgSVAgcGFja2V0cyBmcm9tPGJyPg0KZGVzdGluYXRpb24gdG8gc291cmNlOyBuZWl0 aGVyIHRoZSBtaW51dGVzIG5vciBJIHN0aXB1bGF0ZSB0aGF0IGE8YnI+DQpjb250cm9sIHBsYW5l IG5lZWRzIHRvIGJlIHVzZWQgdG8gaW5zdGFudGlhdGUgdGhpcyBmb3J3YXJkaW5nLjxicj4NCjxi cj4NCkFzIGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgcmV0dXJuIHBhdGggZm9yIHVuaWRpcmVjdGlv bmFsIExTUHMgY291bGQgYmU8YnI+DQpjaGFyYXRlcml6ZWQgYXMgdGhlIGVsZXBoYW50IGluIHRo ZSByb29tLiAmbmJzcDtJbiB0aGUgTVBMUyBUUCBPQU0gRnJhbWV3b3JrPGJyPg0KSS1ELCB1bmlj YXN0IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRpbWVzIGFuZCByZXR1cm4gcGF0aHMg bm90IGF0PGJyPg0KYWxsLiAmbmJzcDs8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KSm9o bjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IEJV U0kgSVRBTE8gW21haWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0XSA8YnI+DQomZ3Q7 IFNlbnQ6IEZyaWRheSwgQXByaWwgMTcsIDIwMDkgMTo1OSBBTTxicj4NCiZndDsgVG86IERyYWtl LCBKb2huIEU7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnM8YnI+DQomZ3Q7 IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogW21wbHMtdHBdIEFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgPGJyPg0KJmd0OyBwYXRoIHJlcXVpcmVt ZW50czxicj4NCiZndDsgPGJyPg0KJmd0OyBKb2huLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIG1p Z2h0IGhhdmUgbWlzc2VkIHRoZSBhZ3JlZW1lbnQgb2YgTVBMUy1UUCBiZWluZyBjYXBhYmxlIG9m IDxicj4NCiZndDsgc2VuZGluZyByZXBsaWVzIHRvIE9BTSByZXF1ZXN0cyBzZW50IG9uIHVuaS1k aXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIHJlcXVpcmVtZW50IGRv ZXMgbm90IGJlbG9uZyB0byB0aGUgZmlyc3Qgc2V0IG9mIDxicj4NCiZndDsgcmVxdWlyZW1lbnRz IElUVS1UIGlzIGV4cGVjdGluZyB0byBiZSBtZXQgYnkgT2N0b2Jlci48YnI+DQomZ3Q7IDxicj4N CiZndDsgSG93ZXZlciwgSSB0aGluayB0aGlzIGluIGEgcG90ZW50aWFsIGludGVyZXN0aW5nIGFk ZGl0aW9uYWwgPGJyPg0KJmd0OyByZXF1aXJlbWVudCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQg KGF0IHdvcnN0IGluIGEgc3Vic2VxdWVudCBwaGFzZSkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkg dGhpbmsgdGhhdCB0aGlzIHJlcXVpcmVtZW50IG5lZWRzIHRvIGJlIGV2YWx1YXRlZCB2ZXJzdXMg PGJyPg0KJmd0OyBvdGhlciBtb3JlIGltcG9ydGFudCByZXF1aXJlbWVudHMgKGUuZy4gdGhlIHBv c3NpYmlsaXR5IHRvIDxicj4NCiZndDsgd29yayB3L28gSVAgZm9yd2FyZGluZyBhbmQgdGhlIG5l ZWQgZm9yIE9BTSB0byBjb250aW51ZSB0byA8YnI+DQomZ3Q7IG1vbml0b3IgdGhlIGRhdGEgcGxh bmUgYWxzbyBpbiBjYXNlIG9mIGZhaWx1cmVzIGFmZmVjdGluZyB0aGUgPGJyPg0KJmd0OyBjb250 cm9sIG9yIG1hbmFnZW1lbnQgcGxhbmUpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIG9wZW4g dG8gZGlzY3VzcyBpdCBidXQgbm90IHN1cmUgdGhpcyBpcyB0aGUgcmlnaHQgdGltZSA8YnI+DQom Z3Q7IGJlY2F1c2UgSSB3aXNoIHRvIGF2b2lkIGRlbGF5aW5nIHRoZSBmaXJzdCBwaGFzZSBvZiB0 aGUgPGJyPg0KJmd0OyBkZXNpZ24gc29sdXRpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5r cywgSXRhbG88YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQom Z3Q7ICZndDsgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBE cmFrZSwgSm9obiBFPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAw OSA4OjAwIFBNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRl biBWaXNzZXJzPGJyPg0KJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoDQo8YnI+DQomZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBBdCB0aGUgbWVldGluZyBsYXN0IGZhbGwgYXQgSnVuaXBlciBpbiBNYXNz YWNodXNldHRzLCBJIDxicj4NCiZndDsgdGhpbmsgaXQgd2FzIDxicj4NCiZndDsgJmd0OyBhZ3Jl ZWQgdGhhdCBhbiBNUExTIFRQIG5ldHdvcmsgbmVlZHMgdG8gaGF2ZSBhIGZvcndhcmRpbmcgPGJy Pg0KJmd0OyBjYXBhYmlsaXR5IDxicj4NCiZndDsgJmd0OyBmb3IgbWFuYWdlbWVudCwgY29udHJv bCwgYW5kIE9BTSBwYWNrZXRzIChlLmcuLCBzZW5kaW5nIDxicj4NCiZndDsgcmVwbGllcyB0byBP QU0gPGJyPg0KJmd0OyAmZ3Q7IHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMp IGV2ZW4gaWYgaXQgZG9lcyBub3QgPGJyPg0KJmd0OyBoYXZlIGFuIElQIDxicj4NCiZndDsgJmd0 OyBmb3J3YXJkaW5nIGRhdGEgcGxhbmUuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTog QWxleGFuZGVyIFZhaW5zaHRlaW48YnI+DQomZ3Q7ICZndDsgW21haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbV08YnI+DQomZ3Q7ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwg QXByaWwgMTYsIDIwMDkgOTo1NyBBTTxicj4NCiZndDsgJmd0OyAmZ3Q7IFRvOiBNYWFydGVuIFZp c3NlcnM8YnI+DQomZ3Q7ICZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsg Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydA0KcGF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBNYWFydGVuLDxicj4NCiZndDsgJmd0 OyAmZ3Q7IEl0IHNlZW1zIHRoYXQgeW91J3ZlIGp1c3QgKGltcGxpY2l0bHkgYW5kLCBwcm9iYWJs eSw8YnI+DQomZ3Q7ICZndDsgJmd0OyBpbmFkdmVydGVudGx5KSBzdGF0ZWQgdGhlIGZvbGxvd2lu Zzo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtNUExTLVRQ IE9BTSB3aWxsIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0aW9uDQo8YnI+DQom Z3Q7IChhbmQgZmF1bHQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbG9jYWxpemF0aW9uIHdoaWNoIHJl cXVpcmVzIHRoaXMgZnVuY3Rpb24gKSBmb3IgPGJyPg0KJmd0OyB1bmlkaXJlY3Rpb25hbCBQMk1Q IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFuZCBQMlAgcGF0aHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSWYgdGhpcyBzdGF0ZW1lbnQgaXMgY29ycmVjdCwgdGhpcyAo SU1ITyBhbmQgRldJVykgcmFpc2VzDQphIHZhbGlkIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHF1ZXN0 aW9uOjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO0lzIE1Q TFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIHRoZXNlIHR5cGVzDQpvZiB0cmFuc3Bv cnQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcGF0aHM/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgRm9yIHRoZSByZWZlcmVuY2UsIElQL01QTFMgcHJvdmlkZXMgdGhpcyBr aW5kIG9mIDxicj4NCiZndDsgZnVuY3Rpb25hbGl0eSB0b2RheSA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBmb3IgKHVuaWRpcmVjdGlvbmFsIC0gYnV0IGl0IGRvZXMgbm90IGtub3cgYW55IG90aGVyIDxi cj4NCiZndDsgdHlwZSkgUDJQIExTUHMgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYXMgZGVz Y3JpYmVkIGluIFJGQyA0Mzc5LiBBbmQgaXRzIGV4dGVuc2lvbiB0byBQMk1QIExTUHMNCnNlZW1z IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGVhc3kuLi48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7U2FzaGE8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJv bTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddDQo8 YnI+DQomZ3Q7IE9uIEJlaGFsZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBPZiBNYWFydGVuIFZpc3Nl cnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXTxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAzOjI0IFBNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVG86 ICdBZHJpYW4gRmFycmVsJzxicj4NCiZndDsgJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVt ZW50czxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFkcmlhbiw8YnI+ DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbHQ7cXVvdGUm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUg aW50ZXJtZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcNCk1FUHMsIE1JUHMgYW5kPGJyPg0KJmd0OyAm Z3Q7ICZndDsgb3RoZXIgaW50ZXJuYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpDQpvZiBhIGNvLXJvdXRl ZDxicj4NCiZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF0aCBhdCBlYWNoIChzdWIt KWxheWVyIE1VU1QNCmJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJk DQphbmQgdGhlIGJhY2t3YXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGlyZWN0aW9ucyBvZiB0aGF0 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNw b3J0IHBhdGguPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmx0O2VuZCBxdW90ZSZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBp cyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQ8YnI+DQomZ3Q7 ICZndDsgaXMsIHRoZXJlIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAqbm90aGluZyogdGhh dCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludA0Kb2Y8YnI+DQomZ3Q7ICZn dDsgdmlldyB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXN1bHRzIGZyb20gYWRoZXJp bmcgdG8gdGhpcyByZXF1aXJlbWVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIEl0IGlzIHZlcnkgbXVj aCBvYnNlcnZhYmxlDQppZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGlzIHJlcXVpcmVtZW50IGlz IG1ldCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZpZXcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg VGhlIE1JUCBmdW5jdGlvbnMgY2FuIG9ubHkgcGVyZm9ybSB0aGUgTG9vcGJhY2sgd2hlbiB0aGVy ZQ0KaXMgYSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aC4gVGhlIE1QTFMtVFAgTEJNDQpwYWNrZXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg cmVjZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUgcmV0dXJuZWQgKGFzIExCUjxicj4NCiZndDsg Jmd0OyAmZ3Q7IHBhY2tldCkgdG8gdGhlIG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhl IG90aGVyIDxicj4NCiZndDsgZGlyZWN0aW9uIG9mIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBj by1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4gVGhpcyBvdGhlciBkaXJlY3Rp b24NCjxicj4NCiZndDsgJmd0OyAmZ3Q7IHdvdWxkIG5vdCBiZSBhdmFpbGFibGUgaW4gYW4gYXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcGF0 aC4uLiBhbmQgdGh1cyB0aGUgbG9vcGJhY2sgdGVzdDxicj4NCiZndDsgJmd0OyB3b3VsZCBmYWls Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFNpbWlsYXJseSwgd2hl biB3ZSBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1vbml0b3IgYSA8YnI+DQomZ3Q7IHNlZ21l bnQsIHRoZW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhpcyBpcyBwb3NzaWJsZSBpbiBhIGNvLXJv dXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aCBidXQNCm5vdCBpbiBhIDxicj4NCiZndDsgJmd0OyAm Z3Q7IGFzc29jaWF0ZWQgYmlkaXIgdHJhbnNwb3J0IHBhdGguIEluIHRoZSBmaXJzdCBjYXNlIHRo ZSBUQ00NCk1FUCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25z IGFyZSBjby1sb2NhdGVkIGFuZCBjYW4gZXhjaGFuZ2UNCndoYXQgaXMgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgY2FsbGVkICZxdW90O3JlbW90ZSBpbmZvcm1hdGlvbiZxdW90OyB3aGljaCBpcyBuZWNl c3NhcnkNCmZvciBwZXJmb3JtYW5jZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBtb25pdG9yaW5nLjxi cj4NCiZndDsgJmd0OyAmZ3Q7IEluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgVENNIE1FUCBTb3VyY2Ug YW5kIFNpbmsgZnVuY3Rpb25zDQo8YnI+DQomZ3Q7IGFyZSBpbiBlLmcuIDxicj4NCiZndDsgJmd0 OyAmZ3Q7IGRpZmZlcmVudCBub2RlcyBpbiB0aGUgbmV0d29yayBhbmQgVENNIHdvdWxkIG5vdCBi ZSBhYmxlDQo8YnI+DQomZ3Q7IHRvIHByb3ZpZGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcGVyZm9y bWFuY2UgbW9uaXRvcmluZy48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFRoZSBlbnRpcmV0eSBvZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICZxdW90OyhpbmNsdWRp bmcNCk1FUHMsPGJyPg0KJmd0OyAmZ3Q7IE1JUHMgYW5kIG90aGVyPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgaW50ZXJuYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9ucyBhcyBhcHByb3By aWF0ZSkmcXVvdDsgc2hvdWxkIGJlIGRlbGV0ZWQuDQpJdCBkb2VzIG5vdDxicj4NCiZndDsgJmd0 OyAmZ3Q7IGFkZCB0byAmcXVvdDtUaGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGludGVybWVk aWF0ZSBub2Rlcy4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIFRoaXMgdGV4dCBtdXN0IG5vdCBi ZQ0KPGJyPg0KJmd0OyBkZWxldGVkIGF0IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFsbC48YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFjdHVhbGx5LCBJIGFtIHF1 aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQ8YnI+DQomZ3Q7ICZndDsgaW5zaXN0ZW5j ZSBvbiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBpbmNsdXNpb248YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IG9mICZxdW90O1RhbmRlbSBDb25uZWN0aW9uLiZxdW90OyBUaGUgZGVmaW5pdGlvbiB3 aXRoaW4NCnRoZSBJVFUtVCBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoaXMgdGVybTxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBwb29ybHk8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUgbW9uaXRvcmluZyBv ZiBhIHBhdGggdGhhdA0KaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBwYXJhbGxlbCAoaS5lLjxicj4N CiZndDsgJmd0OyAmZ3Q7IHRhbmRlbSk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRvIHRoZSBk YXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24gb2YNClRDPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgc2VlbXMgdG8gYmUgYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB2YXJpYW5jZSw8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1 YWxseSBpbiBiYW5kLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEkg ZG9uJ3QgdW5kZXJzdGFuZCB3aGVyZSB5b3VyIGludGVycHJldGF0aW9uIG9mIHRhbmRlbSA8YnI+ DQomZ3Q7IGNvbm5lY3Rpb24gaXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGVzY3JpYmVkIGluIElU VS1UIHJlY29tbWVuZGF0aW9ucy4gSS5lLiAmcXVvdDtmcm9tIHRoZQ0KPGJyPg0KJmd0OyBtb25p dG9yaW5nIG9mIGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcGF0aCB0aGF0IGlzIHBhcmFsbGVsIChp LmUuIHRhbmRlbSkgdG8gdGhlIGRhdGEgcGF0aCBiZWluZw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsg bW9uaXRvcmVkLiZxdW90Oz88YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBUaGVyZSBpcyBhICZxdW90O25ldHdvcmsgY29ubmVjdGlvbiZxdW90OyBhbmQgdGhpcyBuZXR3 b3JrDQo8YnI+DQomZ3Q7IGNvbm5lY3Rpb24gaXMgYSBzZXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg b2YgaW50ZXJjb25uZWN0ZWQgJnF1b3Q7bGluayBjb25uZWN0aW9ucyZxdW90OyBhbmQgJnF1b3Q7 bWF0cml4DQpjb25uZWN0aW9ucyZxdW90Oy4gQSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBzdWJzZXQg b2YgdGhvc2UgaW50ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQgbWF0cml4DQo8YnI+ DQomZ3Q7ICZndDsgJmd0OyBjb25uZWN0aW9ucyBjYW4gYmUgbW9uaXRvcmVkIGFuZCBpcyB0aGVu IHJlZmVycmVkIHRvIGFzDQphICZxdW90O3RhbmRlbSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjb25u ZWN0aW9uJnF1b3Q7LiBUaGVyZSBpcyBubyAmcXVvdDtwYXRoIHRoYXQgaXMgcGFyYWxsZWwNCnRv IHRoZSA8YnI+DQomZ3Q7IGRhdGEgcGF0aCZxdW90Oy4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhl cmUgaXMgb25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBpbnNpZGUgdGhlIGRhdGEgcGF0aA0K YnkgdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRDTSBNRVBfU28gZnVuY3Rpb24gYW5kIHRoaXMg T0FNIGlzIGV4dHJhY3RlZCBmcm9tIHRoZSA8YnI+DQomZ3Q7IGRhdGEgcGF0aCBieSA8YnI+DQom Z3Q7ICZndDsgJmd0OyB0aGUgVENNIE1FUF9TayBmdW5jdGlvbi48YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7IE1hYXJ0 ZW48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IEZy b206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IFttYWlsdG86 bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbDxicj4N CiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IGRvbmRlcmRhZyAxNiBhcHJpbCAyMDA5IDExOjU5PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBiZW5qYW1pbi5uaXZlbi1q ZW5raW5zQGJ0LmNvbTxicj4NCiZndDsgJmd0OyAmZ3Q7IENjOiBCVVNJIElUQUxPOyBtcGxzLXRw QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IHJlcXVpcmVtZW50czxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEhp IFNhc2hhLDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVW5m b3J0dW5hdGVseSBJIGNhbm5vdCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50Ojxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgRnJvbSB0aGUgcG9pbnQg b2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkPGJyPg0KJmd0OyAmZ3Q7IGJpZGlyZWN0aW9u YWwgTFNQczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBhcmUgYSBzcGVj aWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpMU1BzLjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmx0O2VuZCBxdW90ZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkg Y29ycmVjdCwgd2VyZSBpdA0Kbm90IGZvcjxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlcXVpcmVtZW50 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAzNCBpbiB0aGUgbGF0ZXN0IE1QTFMtVFAgcmVxdWly ZW1lbnRzIGRyYWZ0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0su IEdvdCBpdC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBCdXQgd2hh dCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cyBzZWN0aW9uPzxi cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEluIGZhY3QsIHdoYXQgaXMg dGhpcyByZXF1aXJlbWVudCBhY3R1YWxseSBzYXlpbmc/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGlu Zw0KTUVQcywgTUlQcyBhbmQ8YnI+DQomZ3Q7ICZndDsgb3RoZXIgaW50ZXJuYWw8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZ1bmN0aW9ucyBhcyBhcHByb3By aWF0ZSkgb2YgYQ0KY28tcm91dGVkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCB0 cmFuc3BvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBh dGggYXQgZWFjaCAoc3ViLSlsYXllciBNVVNUDQpiZSBhd2FyZSBvZiB0aGUgcGFpcmluZzxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRpb25zaGlwIG9m IHRoZSBmb3J3YXJkIGFuZA0KdGhlIGJhY2t3YXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGlyZWN0 aW9ucyBvZiB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB0cmFuc3BvcnQgcGF0aC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgcXVvdGUm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8g d2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBUaGF0IDxicj4NCiZndDsgaXMs IHRoZXJlIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2Vy dmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCjxicj4NCiZndDsgdmlldyB0aGF0IDxicj4N CiZndDsgJmd0OyAmZ3Q7IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVtZW50 Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZXJlZm9yZSBpdCBj b3VsZCBiZSBhc3N1bWVkIHRoYXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQNCmJ5IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IGNvbmZpZ3VyaW5nIHNvbWUgZGF0YSBwbGFuZSBkYXRhYmFzZSBjb21wb25l bnQgdGhyb3VnaCB0aGUNCjxicj4NCiZndDsgJmd0OyAmZ3Q7IG1hbmFnZW1lbnQgcGxhbmUuIFRo ZSBkYXRhYmFzZSBjb21wb25lbnQgaXMgbm90IHVzZWQgZm9yDQphbnl0aGluZyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBleGNlcHQgdG8gc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAmcXVvdDth d2FyZW5lc3MmcXVvdDsuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg QmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdyaXRlIHRoaXMgcmVxdWlyZW1lbnQgaW4gdGVy bXMNCm9mIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGJlaGF2aW9yPzxicj4NCiZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJlbWVudCAz NCBpcyB0aGUgT05MWSBpdGVtIGluDQp0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBsaXN0IHRoYXQg aXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNwZWNpZmljIGZvciBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1BzLiAoVGhlIHBhaXJpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVu dHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0IGVuZCBwb2ludHMgZm9yIGNvLXJvdXRlZCBh bmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyAmZ3Q7IHBhdGhzIGFyZTxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgZXhhY3RseSB0aGUgc2FtZSBldmVuIGlmIHRoZXkgYXBwZWFy IGluIHR3byBkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZndDsgaXRlbXMgaW4gdGhlPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHMnIGxpc3QpLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgSW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlvbiBvZg0K Y28tcm91dGVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBwYXRocyB3 b3VsZCBiZSB2b2lkIG9mIGFueSBkYXRhIHBsYW5lDQpjb250ZW50Ljxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBzb21ld2hhdCB2YWd1ZSBzY29w ZSBvZiB0aGlzIHJlcXVpcmVtZW50ICgmcXVvdDtvdGhlcg0KaW50ZXJuYWwgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUmcXVvdDspIGNyZWF0ZXMgYSBz dXNwaWNpb24NCnRoYXQgSFc8YnI+DQomZ3Q7ICZndDsgJmd0OyBzdXBwb3J0IG9mIHRoZTxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgcGFpcmluZyBhd2FyZW5lc3MgbWF5IGJlIHJlcXVpcmVkIGlu IG9yZGVyIHRvIGNvbXBseQ0Kd2l0aCBpdC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAmcXVvdDsoaW5j bHVkaW5nIE1FUHMsDQo8YnI+DQomZ3Q7IE1JUHMgYW5kIG90aGVyIDxicj4NCiZndDsgJmd0OyAm Z3Q7IGludGVybmFsIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkmcXVvdDsgc2hvdWxkIGJlIGRl bGV0ZWQuDQpJdCA8YnI+DQomZ3Q7IGRvZXMgbm90IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFkZCB0 byAmcXVvdDtUaGUgaW50ZXJtZWRpYXRlIG5vZGVzLiZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFm dCBpbmNyZWFzZXMgdGhpcyBzdXNwaWNpb246PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7IFRhbmRlbSBDb25uZWN0aW9uOiBBIHRhbmRlbSBjb25uZWN0aW9uIGlzIGFuDQo8 YnI+DQomZ3Q7IGFyYml0cmFyeSBwYXJ0IG9mIGE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu YnNwOyB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgaW5kZXBlbmRlbnRseSBmcm9tIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7IGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gJm5ic3A7SXQgbWF5IGJl DQphIG1vbml0b3JlZCA8YnI+DQomZ3Q7IHNlZ21lbnQgb3IgYTxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7IG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIHRyYW5zcG9y dA0KcGF0aC4gJm5ic3A7PGJyPg0KJmd0OyBUaGUgdGFuZGVtPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVu Z2luZShzKQ0Kb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgbm9kZShzKTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7IGF0IHRoZSBlZGdlKHMpIG9mIHRoZSBzZWdtZW50IG9yIGNvbmNh dGVuYXRlZA0Kc2VnbWVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgcXVvdGUm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQWN0dWFsbHksIEkg YW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudCA8YnI+DQomZ3Q7IGluc2lzdGVu Y2Ugb24gdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGluY2x1c2lvbiBvZiAmcXVvdDtUYW5kZW0g Q29ubmVjdGlvbi4mcXVvdDsgVGhlIGRlZmluaXRpb24NCndpdGhpbiA8YnI+DQomZ3Q7IHRoZSBJ VFUtVCBvZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGlzIHRlcm0gaXMgcG9vcmx5IHNwZWNpZmll ZCBhbmQgY29tZXMgZnJvbSB0aGUgbW9uaXRvcmluZw0Kb2YgYSA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJl aW5nDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBtb25pdG9yZWQuIFRoaXMgZGVmaW5pdGlvbiBvZiBU QyBzZWVtcyB0byBiZSBhdCB2YXJpYW5jZSwNCjxicj4NCiZndDsgYW5kIHdvdWxkIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBEb2Vzbid0ICZxdW90O2Zvcndh cmRpbmcgZW5naW5lJnF1b3Q7IHNvdW5kIGxpa2UgaGFyZHdhcmUNCnRvIHlvdT88YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBZZXMsIGJ1dCBzbyB3aGF0Pzxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSU1ITyBpdCBpcyB3b3J0aCBu b3RpbmcgdGhhdCBuZWl0aGVyIHRoZSBNUExTLVRQPGJyPg0KJmd0OyAmZ3Q7IFJlcXVpcmVtZW50 cyBkcmFmdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1 aXJlbWVudHMgb25lPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1yZXF1aXJlbWVuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyB0cy0wMS50eHQpIGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdp dGggdGFuZGVtPGJyPg0KJmd0OyAmZ3Q7IGNvbm5lY3Rpb25zLjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJ1dCB0YW5kZW0gY29ubmVjdGlvbnMgYXJl IGRpc2N1c3NlZCBpbiB0aGUgTVBMUy1UUA0KT0FNIDxicj4NCiZndDsgRnJhbWV3b3JrIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgZHJhZnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAoaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcjxicj4N CiZndDsgJmd0OyAmZ3Q7IGFtZXdvcmstMDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgKS48YnI+ DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBSaWdodC48YnI+DQomZ3Q7ICZn dDsgJmd0OyBMZXQncyBqdXN0IGdldCByaWQgb2YgYW4gdW5uZWNlc3NhcnkgdGVybSBhbmQgYnJp bmcgYWxsDQp0aGUgSS1EcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBpbnRvIGxpbmUuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgYm90dG9tIGxpbmUsIElN SE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZzxicj4NCiZndDsgJmd0OyBjby1yb3V0 ZWQgdnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhc3NvY2lhdGVkPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGlzIHN0aWxsIHJlcXVpcmVkLiBPbmUgd2F5 IHRvIHByb3ZpZGU8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGF0IGNvdWxkPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBiZSBieSBleHBsaWNpdGx5IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNw ZWNpZmljPGJyPg0KJmd0OyAmZ3Q7IGZ1bmN0aW9uYWxpdHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQWdyZWVkLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IEFkcmlhbjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7ICZndDsgJmd0OyBGcm9tOiBBZHJpYW4gRmFycmVsIFthZHJpYW5Ab2xkZG9nLmNvLnVrXTxi cj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBB TTxicj4NCiZndDsgJmd0OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdl cjsgQlVTSSBJVEFMTzxicj4NCiZndDsgJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50 czxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEhpIFNhc2hhLDxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE5vdCByZWFsbHkgc3VyZSB3aGV0 aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwNCmJ1dC4uLjxicj4NCiZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgMS4gTXkgcmVhZGluZyBvZiAmbmJzcDtv bmUgb2YgQmVuJ3MgJm5ic3A7bWVzc2FnZXMNCmlzIHRoYXQgYXNzb2NpYXRlZCA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBvbmx5IHR5cGVzIG9m IHBhdGhzIHRoYXQNCmNhbiBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGNyZWF0ZWQgaW48YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBleGlzdGluZyBuZXR3b3JrczsgJnF1b3Q7dHJ1ZSZxdW90 OyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KcGF0aHM8YnI+DQomZ3Q7ICZndDsgJmd0OyB3aWxs IGhhdmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5l dyBlcXVpcG1lbnQgYmVjb21lcyBhdmFpbGFibGUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlITxicj4NCiZndDsgJmd0OyAm Z3Q7IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCA8YnI+DQom Z3Q7IGJpZGlyZWN0aW9uYWwgTFNQcyBhcmUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYSBzcGVjaWFs IGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlv bmFsIExTUHMgKGUuZy4gdXNpbmcgdGhlDQo8YnI+DQomZ3Q7IG1hbmFnZW1lbnQgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgcGxhbmUpIHlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZDxicj4N CiZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIExTUC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgc2hpcHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBj by1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTFNQcyB1c2luZyB0 aGUgY29udHJvbCBwbGFuZS4gVGhlc2UgZWl0aGVyIHVzZSB0aGUgR01QTFMNCjxicj4NCiZndDsg KHdoaWNoIGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGNsZWFuZXIpIG9yIG5vbi1zdGFuZGFyZCBw cm9wcmlldGFyeSBzb2x1dGlvbnMgKHdoaWNoIGlzDQo8YnI+DQomZ3Q7IG1lc3N5IGJ1dCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBmdW5jdGlvbmFsKS48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyBCdXQgKG9mIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29u dHJvbCBwbGFuZSA8YnI+DQomZ3Q7IHNvbHV0aW9ucyBoYXZlIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IG5vdGhpbmcgdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50IGFzIHRoZXkgYXJl DQpzb2Z0d2FyZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBzb2x1dGlvbnMuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBO ZWlsJ3MgbWVzc2FnZXMgaXMgdGhhdCB0aGUNCmFjdHVhbDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRy aXZlciBmb3I8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFs IHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGgNCmV4aXN0aW5nIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgdHJhbnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFuIGFueSBzcGVjaWZpYyBiZW5l Zml0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IElzbid0IHRoYXQg dGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPzxicj4NCiZndDsg Jmd0OyAmZ3Q7IFdoaWNoIGlzIG5vdCB0byBzYXkgaXQgaXMgYSBiYWQgdGhpbmcuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMt VFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsNCjxicj4NCiZndDsgdGhlIGxvb2ssIDxi cj4NCiZndDsgJmd0OyAmZ3Q7IGZlZWwsIGFuZCBiZWhhdmlvcmFsIGNoYXJhY3RlcmlzdGljcyBv ZiBhICZxdW90O2xlZ2FjeSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IHRyYW5zcG9ydCBuZXR3 b3JrLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQmFzZWQg b24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRoYXQ6PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxl YXN0IGZvcg0KdGhlIHRpbWU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDti ZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2YgYmlkaXJlY3Rpb25hbA0KcGF0aHMgaW48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtNUExTLVRQPGJyPg0KJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSB0aGluayB0aGF0IGlzIHdyb25nIGJvdGgg Z2l2ZW4gbXkgc3RhdGVtZW50IGFib3ZlLCBhbmQNCjxicj4NCiZndDsgZ2l2ZW4gdGhhdCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBvdGhlciB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9u cyB3aWxsIGJlIG5lZWRlZA0KdG8gcmVhY2ggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIGZ1bGwg ZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICogdGhleSBoYWQgYSBnb29kIGNoYW5jZSB0byByZW1haW4gdGhlIG9u bHkgdHlwZSBvZg0KPGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgcGF0aHMgaW4gJm5ic3A7cmVhbCBkZXBsb3ltZW50cy48YnI+DQomZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93 cyBmcm9tLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IENoZWVycyw8 YnI+DQomZ3Q7ICZndDsgJmd0OyBBZHJpYW48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgJmd0OyAmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 ICZndDsgJmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IG1wbHMtdHAgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQptcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCm1wbHMtdHBAaWV0Zi5vcmc8 YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQo8 L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7 U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250 YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJz cDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRp b24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtj b25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDth cmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNw O2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xv c2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNw O2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDth cmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZu YnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2Fy ZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZl ZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJz cDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtt ZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJz cDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtT cGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 000B50EC4825759E_=-- From benjamin.niven-jenkins@bt.com Sun Apr 19 23:01:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385003A6FC5 for ; Sun, 19 Apr 2009 23:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUdepz2LJRqe for ; Sun, 19 Apr 2009 23:01:06 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6DE093A6FCC for ; Sun, 19 Apr 2009 23:00:55 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 07:02:10 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Apr 2009 06:02:08 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 20 Apr 2009 07:02:05 +0100 From: Ben Niven-Jenkins To: , Lou Berger Message-ID: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnBfYfJM5cQ0InSskGAbXJM06KN4A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Apr 2009 06:02:10.0068 (UTC) FILETIME=[8ACF3D40:01C9C17D] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 06:01:08 -0000 Liu, On 20/04/2009 02:00, "liu.guoman@zte.com.cn" wrote: > lou: > because The forward and backward directions are setup, monitored and > protected independent in the associated bidirectional paths. it can't > ensure and realize the symmetric bandwidth in two directional path. > or else , I MUST revise the definitions of associated bidirectional paths > in mpls-tp requirements draft. You are claiming that it is not possible for the end points of an associate= d bidirectional path to ensure that both directions have the same bandwidth attributes. This is clearly IMO incorrect. Let's take a real world example to illustrate why it is incorrect. If it were true then it would not be possible for example to support E1 PWs in MPLS networks today. Such E1 PWs are successfully being used in MPLS networks today to support customer services. Ben >=20 > regards > liu=20 >=20 >=20 >=20 > Lou Berger > 2009-04-17 21:54 >=20 > =CA=D5=BC=FE=C8=CB > liu.guoman@zte.com.cn > =B3=AD=CB=CD > Ben Niven-Jenkins , mpls-tp@ietf.org > =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidirectional transport path requirements >=20 >=20 >=20 >=20 >=20 >=20 > Liu, > Why isn't it necessary for associated bidirectional > paths? Is it that > asymmetric is the sole requirement? If not, I don't understand your > comment. >=20 > Lou >=20 > On 4/16/2009 9:15 PM, liu.guoman@zte.com.cn wrote: >>=20 >> Lou: >> I agree your advice, but for symmetric bandwidth requirement, I think >> the requirement can only be fit for co-routed bidirectional transport >> paths, while it isn't necessary for associated bidirectional paths .so >> adding a "co-routed" word in the requirement 33 is necessary. >> thank you. >> liu >>=20 >>=20 >> *Lou Berger * >> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org >>=20 >> 2009-04-16 21:43 >>=20 >>=20 >> =CA=D5=BC=FE=C8=CB >> Ben Niven-Jenkins >> =B3=AD=CB=CD >> BUSI@core3.amsl.com, "mpls-tp@ietf.org" > , ITALO >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path > requirements >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Ben, >> It seems to me that much of the discussion stems from the section in >> which these requirements are listed. >>=20 >> Requirement 32 is a service level requirement and primarily impact the >> management and control planes. As there is no section describing >> service requirements, I suggest moving this requirement to follow >> requirement 6, and adding the following in its place: >> 33 MPLS-TP MUST support bidirectional transport paths with >> symmetric bandwidth requirements, i.e. the amount of reserved >> bandwidth is the same between the forward and backward >> directions. >>=20 >> While this too is a service requirement and doesn't require any hardware >> modifications, it parallels current requirements 37, 40 and 41. It also >> makes a currently implicit requirement explicit. >>=20 >> Requirements 33-26 relate to "awareness" should have no implication on >> the data/forwarding plane and are IMO both management and control plane >> requirements. (And yes, they have implications on OAM and recovery.) I >> think Adrian raises a good point WRT these requirements, i.e., are these >> requirements listed as solutions to some unlisted requirements. If so, >> the unlisted requirements should be included and these should be >> dropped. If not, so be it, but they should be moved from section 2.3. >>=20 >> While I'm sure this won't end the discussion, I think these changes will >> help make "the requirements clear enough ..." >>=20 >> Lou >>=20 >> On 4/16/2009 5:58 AM, Ben Niven-Jenkins wrote: >>> Colleagues, >>>=20 >>> I can't help but feel we are overanalysing things here. How many >>> technologies/protocols/mechanisms have we successfully defined in >> both IETF >>> & ITU-T without this level of analysis of the initial requirements - >> a great >>> many (a good chunk of which were extremely successful). >>>=20 >>> The requirements document is not about specifying solutions. >>>=20 >>> The key question is: are the requirements clear enough that it is >> understood >>> what is required so someone could build a box/protocol/whatever to > meet >>> them? >>>=20 >>> If we want to go into the nth level of detail on each requirement we > will >>> still be debating this by the time I retire (which isn't due until > 2045). >>>=20 >>> Ben >>>=20 >>>=20 >>> On 16/04/2009 08:04, "Alexander Vainshtein" >>> wrote: >>>=20 >>>> Adrian, >>>> Thank you for a prompt and detailed response. >>>>=20 >>>> Unfortunately I cannot fully agree with your statement: >>>>=20 >>>> >>>> From the point of view of hardware, co-routed bidirectional LSPs >>>> are a special case of associated bidirectional LSPs. >>>> >>>>=20 >>>> This statement would be obviously correct, were it not for >> Requirement 34 in >>>> the latest >>>> MPLS-TP requirements draft >>>>=20 >> ( > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.tx= t > ): >>>>=20 >>>> >>>> The intermediate nodes (including MEPs, MIPs and other internal >>>> functions as appropriate) of a co-routed bidirectional transport >>>> path at each (sub-)layer MUST be aware of the pairing >>>> relationship of the forward and the backward directions of that >>>> transport path. >>>> >>>>=20 >>>> Please note that Requirement 34 is the ONLY item in the list that is >=20 >> specific >>>> for co-routed bidirectional LSPs. (The pairing requirements at end >> points >>>> for co-routed and associated bidirectional paths are exactly the >> same even >>>> if they appear in two different items in the requirements' list). >>>> In other words, without Requirement 34 the notion of co-routed >> bidirectional >>>> paths would be void of any data plane content. >>>>=20 >>>> The somewhat vague scope of this requirement ("other internal > functions >>>> as appropriate") creates a suspicion that HW support of the pairing >> awareness >>>> may be required in order to comply with it. >>>>=20 >>>> The following text in the draft increases this suspicion: >>>>=20 >>>> >>>> Tandem Connection: A tandem connection is an arbitrary part of a >>>> transport path that can be monitored (via OAM) independently from > the >>>> end-to-end monitoring (OAM). It may be a monitored segment or a >>>> monitored concatenated segment of a transport path. The tandem >>>> connection may also include the forwarding engine(s) of the node(s) >>>> at the edge(s) of the segment or concatenated segment. >>>> >>>>=20 >>>> Doesn't "forwarding engine" sound like hardware to you? >>>>=20 >>>> IMHO it is worth noting that neither the MPLS-TP Requirements draft >>>> nor the MPLS-TP OAM requirements one >>>>=20 >> ( > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-0= 1.tx >=20 >>>> t) >>>> contain any requirements dealing with tandem connections. >>>>=20 >>>> But tandem connections are discussed in the MPLS-TP OAM Framework > draft >>>>=20 >> ( > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.t= xt > ). >>>>=20 >>>> The bottom line, IMHO, is that some clarity regarding co-routed vs. >> associated >>>> bidirectional >>>> paths is still required. One way to provide that could be by > explicitly >>>> limiting Requirement 34 >>>> to specific functionality. >>>>=20 >>>> My 2c, >>>> Sasha >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ________________________________________ >>>> From: Adrian Farrel [adrian@olddog.co.uk] >>>> Sent: Thursday, April 16, 2009 12:13 AM >>>> To: Alexander Vainshtein; Lou Berger; BUSI ITALO >>>> Cc: mpls-tp@ietf.org >>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >>>>=20 >>>> Hi Sasha, >>>>=20 >>>> Not really sure whether you are misrepresenting anyone, but... >>>>=20 >>>>> 1. My reading of one of Ben's messages is that associated >>>>> bidirectional paths are the only types of paths that can be >>>>> created in the existing networks; "true" co-routed bidirectional >>>>> paths will have to wait until (if ever) new equipment becomes >>>>> available. >>>> This is clearly nonsense! >>>> From the point of view of hardware, co-routed bidirectional LSPs are > a >>>> special case of associated bidirectional LSPs. >>>>=20 >>>> If you can set up two unidirectional LSPs (e.g. using the management >=20 >> plane) >>>> you can surely set up a co-routed bidirectional LSP. >>>>=20 >>>> There are shipping solutions that achieve co-routed bidirectional >> LSPs using >>>> the control plane. These either use the GMPLS (which is cleaner) or >>>> non-standard proprietary solutions (which is messy but functional). >>>>=20 >>>> But (of course) the management plane or control plane solutions have >=20 >> nothing >>>> to do with availability of equipment as they are software solutions. >>>>=20 >>>>> 2. My reading of one of Neil's messages is that the actual driver > for >>>>> co-routed >>>>> bidirectional paths may be experience with existing transport > networks >>>>> rather >>>>> than any specific benefit. >>>> Isn't that the case with 75% of the MPLS-TP requirements? >>>> Which is not to say it is a bad thing. >>>>=20 >>>> A large driver for MPLS-TP is to give the packet network the look, >> feel, and >>>> behavioral characteristics of a "legacy" transport network. >>>>=20 >>>>> Based on these observations, I'd guess (FWIW) that: >>>>> * associated bidirectional paths are, at least for the time >>>>> being, the most important type of bidirectional paths in >>>>> MPLS-TP >>>> I think that is wrong both given my statement above, and given that >> other >>>> upgrades to existing MPLS solutions will be needed to reach the full >>>> function level of MPLS-TP. >>>>=20 >>>>> * they had a good chance to remain the only type of bidirectional >>>>> paths in real deployments. >>>> I don't see what that follows from. >>>>=20 >>>> Cheers, >>>> Adrian >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>=20 >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 >>=20 >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in > this mail is solely property of the sender's organization. This > mail communication is confidential. Recipients named above are > obligated to maintain secrecy and are not permitted to disclose > the contents of this communication to others. >> This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in > error please notify the originator of the message. Any views > expressed in this message are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE > Anti-Spam system. >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d are > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From Alexander.Vainshtein@ecitele.com Mon Apr 20 00:11:46 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB37D3A6928 for ; Mon, 20 Apr 2009 00:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-1.889, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKI840rR2iH7 for ; Mon, 20 Apr 2009 00:11:45 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 8E7D13A68E3 for ; Mon, 20 Apr 2009 00:11:44 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 20 Apr 2009 10:19:15 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 10:12:54 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 20 Apr 2009 10:12:54 +0300 From: Alexander Vainshtein To: Ben Niven-Jenkins , "liu.guoman@zte.com.cn" , Lou Berger Date: Mon, 20 Apr 2009 10:12:51 +0300 Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnBfYfJM5cQ0InSskGAbXJM06KN4AACZVBA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2009 07:12:54.0577 (UTC) FILETIME=[6CBBEA10:01C9C187] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:11:47 -0000 KzENClRoZSBmYWN0IHRoYXQgdHdvIGRpcmVjdGlvbnMgb2YgdGhlIHBhdGggYXJlIHNlIHVwIGlu ZGVwZW5kZW50bHkgc2hvdWxkIG5vdCAtIGFuZCwgQUZBSUssIA0KZG9lcyBub3QgcHJldmVudCB0 aGUgb3BlcmF0b3IgZnJvbSBleHBsaWNpdGx5IHJlcXVlc3Rpbmcgc2FtZSBCVyBmb3IgdHdvIHVu aWRpcmVjdGlvbmFsIHBhdGhzLiANCg0KTXkgMmMsDQoJU2FzaGENCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQo+IFttYWls dG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVuIE5pdmVuLUplbmtp bnMNCj4gU2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSA5OjAyIEFNDQo+IFRvOiBsaXUuZ3Vv bWFuQHp0ZS5jb20uY247IExvdSBCZXJnZXINCj4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IA0K PiBwYXRoIHJlcXVpcmVtZW50cw0KPiANCj4gTGl1LA0KPiANCj4gDQo+IE9uIDIwLzA0LzIwMDkg MDI6MDAsICJsaXUuZ3VvbWFuQHp0ZS5jb20uY24iIA0KPiA8bGl1Lmd1b21hbkB6dGUuY29tLmNu PiB3cm90ZToNCj4gDQo+ID4gbG91Og0KPiA+ICAgICBiZWNhdXNlIFRoZSBmb3J3YXJkIGFuZCBi YWNrd2FyZCBkaXJlY3Rpb25zIGFyZSBzZXR1cCwgDQo+IG1vbml0b3JlZCBhbmQNCj4gPiBwcm90 ZWN0ZWQgaW5kZXBlbmRlbnQgaW4gdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCANCj4gcGF0 aHMuIGl0IGNhbid0DQo+ID4gZW5zdXJlIGFuZCByZWFsaXplIHRoZSBzeW1tZXRyaWMgYmFuZHdp ZHRoIGluIHR3byBkaXJlY3Rpb25hbCBwYXRoLg0KPiA+IG9yIGVsc2UgLCBJIE1VU1QgcmV2aXNl IHRoZSBkZWZpbml0aW9ucyBvZiBhc3NvY2lhdGVkIA0KPiBiaWRpcmVjdGlvbmFsIHBhdGhzDQo+ ID4gaW4gbXBscy10cCByZXF1aXJlbWVudHMgZHJhZnQuDQo+IA0KPiBZb3UgYXJlIGNsYWltaW5n IHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIGZvciB0aGUgZW5kIHBvaW50cyANCj4gb2YgYW4gYXNz b2NpYXRlZA0KPiBiaWRpcmVjdGlvbmFsIHBhdGggdG8gZW5zdXJlIHRoYXQgYm90aCBkaXJlY3Rp b25zIGhhdmUgdGhlIA0KPiBzYW1lIGJhbmR3aWR0aA0KPiBhdHRyaWJ1dGVzLiBUaGlzIGlzIGNs ZWFybHkgSU1PIGluY29ycmVjdC4NCj4gDQo+IExldCdzIHRha2UgYSByZWFsIHdvcmxkIGV4YW1w bGUgdG8gaWxsdXN0cmF0ZSB3aHkgaXQgaXMgDQo+IGluY29ycmVjdC4gSWYgaXQNCj4gd2VyZSB0 cnVlIHRoZW4gaXQgd291bGQgbm90IGJlIHBvc3NpYmxlIGZvciBleGFtcGxlIHRvIA0KPiBzdXBw b3J0IEUxIFBXcyBpbg0KPiBNUExTIG5ldHdvcmtzIHRvZGF5LiBTdWNoIEUxIFBXcyBhcmUgc3Vj Y2Vzc2Z1bGx5IGJlaW5nIHVzZWQgaW4gTVBMUw0KPiBuZXR3b3JrcyB0b2RheSB0byBzdXBwb3J0 IGN1c3RvbWVyIHNlcnZpY2VzLg0KPiANCj4gQmVuDQo+IA0KPiANCj4gDQo+ID4gDQo+ID4gcmVn YXJkcw0KPiA+IGxpdSANCj4gPiANCj4gPiANCj4gPiANCj4gPiBMb3UgQmVyZ2VyIDxsYmVyZ2Vy QGxhYm4ubmV0Pg0KPiA+IDIwMDktMDQtMTcgMjE6NTQNCj4gPiANCj4gPiDK1bz+yMsNCj4gPiBs aXUuZ3VvbWFuQHp0ZS5jb20uY24NCj4gPiCzrcvNDQo+ID4gQmVuIE5pdmVuLUplbmtpbnMgPGJl bmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPiwgbXBscy10cEBpZXRmLm9yZw0KPiA+INb3zOIN Cj4gPiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0 aCByZXF1aXJlbWVudHMNCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBM aXUsDQo+ID4gICAgICAgICAgICAgICAgICBXaHkgaXNuJ3QgaXQgbmVjZXNzYXJ5IGZvciBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwNCj4gPiBwYXRocz8gIElzIGl0IHRoYXQNCj4gPiBhc3ltbWV0 cmljIGlzIHRoZSBzb2xlIHJlcXVpcmVtZW50PyAgSWYgbm90LCBJIGRvbid0IHVuZGVyc3RhbmQg eW91cg0KPiA+IGNvbW1lbnQuDQo+ID4gDQo+ID4gTG91DQo+ID4gDQo+ID4gT24gNC8xNi8yMDA5 IDk6MTUgUE0sIGxpdS5ndW9tYW5AenRlLmNvbS5jbiB3cm90ZToNCj4gPj4gDQo+ID4+IExvdToN Cj4gPj4gSSBhZ3JlZSB5b3VyIGFkdmljZSwgYnV0IGZvciBzeW1tZXRyaWMgYmFuZHdpZHRoIA0K PiByZXF1aXJlbWVudCwgSSB0aGluaw0KPiA+PiB0aGUgcmVxdWlyZW1lbnQgY2FuIG9ubHkgYmUg Zml0IGZvciBjby1yb3V0ZWQgDQo+IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ID4+IHBhdGhz LCB3aGlsZSBpdCBpc24ndCBuZWNlc3NhcnkgZm9yIGFzc29jaWF0ZWQgDQo+IGJpZGlyZWN0aW9u YWwgcGF0aHMgLnNvDQo+ID4+IGFkZGluZyBhICJjby1yb3V0ZWQiIHdvcmQgaW4gdGhlIHJlcXVp cmVtZW50IDMzIGlzIG5lY2Vzc2FyeS4NCj4gPj4gdGhhbmsgeW91Lg0KPiA+PiBsaXUNCj4gPj4g DQo+ID4+IA0KPiA+PiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+ID4+ILeivP7I yzogbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQo+ID4+IA0KPiA+PiAyMDA5LTA0LTE2IDIxOjQz DQo+ID4+IA0KPiA+PiANCj4gPj4gytW8/sjLDQo+ID4+ICAgICAgICAgICAgICAgIEJlbiBOaXZl bi1KZW5raW5zIDxiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbT4NCj4gPj4gs63LzQ0KPiA+ PiAgICAgICAgICAgICAgICBCVVNJQGNvcmUzLmFtc2wuY29tLCAibXBscy10cEBpZXRmLm9yZyIN Cj4gPiA8bXBscy10cEBpZXRmLm9yZz4sIElUQUxPDQo+ID4+IDxJdGFsby5CdXNpQGFsY2F0ZWwt bHVjZW50Lml0Pg0KPiA+PiDW98ziDQo+ID4+ICAgICAgICAgICAgICAgIFJlOiBbbXBscy10cF0g QXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIA0KPiB0cmFuc3BvcnQgcGF0aA0KPiA+IHJlcXVpcmVt ZW50cw0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiANCj4g Pj4gDQo+ID4+IEJlbiwNCj4gPj4gSXQgc2VlbXMgdG8gbWUgdGhhdCBtdWNoIG9mIHRoZSBkaXNj dXNzaW9uIHN0ZW1zIGZyb20gdGhlIA0KPiBzZWN0aW9uIGluDQo+ID4+IHdoaWNoIHRoZXNlIHJl cXVpcmVtZW50cyBhcmUgbGlzdGVkLg0KPiA+PiANCj4gPj4gUmVxdWlyZW1lbnQgMzIgaXMgYSBz ZXJ2aWNlIGxldmVsIHJlcXVpcmVtZW50IGFuZCANCj4gcHJpbWFyaWx5IGltcGFjdCB0aGUNCj4g Pj4gbWFuYWdlbWVudCBhbmQgY29udHJvbCBwbGFuZXMuIEFzIHRoZXJlIGlzIG5vIHNlY3Rpb24g ZGVzY3JpYmluZw0KPiA+PiBzZXJ2aWNlIHJlcXVpcmVtZW50cywgSSBzdWdnZXN0IG1vdmluZyB0 aGlzIHJlcXVpcmVtZW50IHRvIGZvbGxvdw0KPiA+PiByZXF1aXJlbWVudCA2LCBhbmQgYWRkaW5n IHRoZSBmb2xsb3dpbmcgaW4gaXRzIHBsYWNlOg0KPiA+PiAzMyBNUExTLVRQIE1VU1Qgc3VwcG9y dCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRocyB3aXRoDQo+ID4+IHN5bW1ldHJpYyBiYW5k d2lkdGggcmVxdWlyZW1lbnRzLCBpLmUuIHRoZSBhbW91bnQgb2YgcmVzZXJ2ZWQNCj4gPj4gYmFu ZHdpZHRoIGlzIHRoZSBzYW1lIGJldHdlZW4gdGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkDQo+ID4+ IGRpcmVjdGlvbnMuDQo+ID4+IA0KPiA+PiBXaGlsZSB0aGlzIHRvbyBpcyBhIHNlcnZpY2UgcmVx dWlyZW1lbnQgYW5kIGRvZXNuJ3QgDQo+IHJlcXVpcmUgYW55IGhhcmR3YXJlDQo+ID4+IG1vZGlm aWNhdGlvbnMsIGl0IHBhcmFsbGVscyBjdXJyZW50IHJlcXVpcmVtZW50cyAzNywgNDAgDQo+IGFu ZCA0MS4gSXQgYWxzbw0KPiA+PiBtYWtlcyBhIGN1cnJlbnRseSBpbXBsaWNpdCByZXF1aXJlbWVu dCBleHBsaWNpdC4NCj4gPj4gDQo+ID4+IFJlcXVpcmVtZW50cyAzMy0yNiByZWxhdGUgdG8gImF3 YXJlbmVzcyIgc2hvdWxkIGhhdmUgbm8gDQo+IGltcGxpY2F0aW9uIG9uDQo+ID4+IHRoZSBkYXRh L2ZvcndhcmRpbmcgcGxhbmUgYW5kIGFyZSBJTU8gYm90aCBtYW5hZ2VtZW50IGFuZCANCj4gY29u dHJvbCBwbGFuZQ0KPiA+PiByZXF1aXJlbWVudHMuIChBbmQgeWVzLCB0aGV5IGhhdmUgaW1wbGlj YXRpb25zIG9uIE9BTSBhbmQgDQo+IHJlY292ZXJ5LikgSQ0KPiA+PiB0aGluayBBZHJpYW4gcmFp c2VzIGEgZ29vZCBwb2ludCBXUlQgdGhlc2UgcmVxdWlyZW1lbnRzLCANCj4gaS5lLiwgYXJlIHRo ZXNlDQo+ID4+IHJlcXVpcmVtZW50cyBsaXN0ZWQgYXMgc29sdXRpb25zIHRvIHNvbWUgdW5saXN0 ZWQgDQo+IHJlcXVpcmVtZW50cy4gSWYgc28sDQo+ID4+IHRoZSB1bmxpc3RlZCByZXF1aXJlbWVu dHMgc2hvdWxkIGJlIGluY2x1ZGVkIGFuZCB0aGVzZSBzaG91bGQgYmUNCj4gPj4gZHJvcHBlZC4g SWYgbm90LCBzbyBiZSBpdCwgYnV0IHRoZXkgc2hvdWxkIGJlIG1vdmVkIGZyb20gDQo+IHNlY3Rp b24gMi4zLg0KPiA+PiANCj4gPj4gV2hpbGUgSSdtIHN1cmUgdGhpcyB3b24ndCBlbmQgdGhlIGRp c2N1c3Npb24sIEkgdGhpbmsgDQo+IHRoZXNlIGNoYW5nZXMgd2lsbA0KPiA+PiBoZWxwIG1ha2Ug InRoZSByZXF1aXJlbWVudHMgY2xlYXIgZW5vdWdoIC4uLiINCj4gPj4gDQo+ID4+IExvdQ0KPiA+ PiANCj4gPj4gT24gNC8xNi8yMDA5IDU6NTggQU0sIEJlbiBOaXZlbi1KZW5raW5zIHdyb3RlOg0K PiA+Pj4gQ29sbGVhZ3VlcywNCj4gPj4+IA0KPiA+Pj4gSSBjYW4ndCBoZWxwIGJ1dCBmZWVsIHdl IGFyZSBvdmVyYW5hbHlzaW5nIHRoaW5ncyBoZXJlLiBIb3cgbWFueQ0KPiA+Pj4gdGVjaG5vbG9n aWVzL3Byb3RvY29scy9tZWNoYW5pc21zIGhhdmUgd2Ugc3VjY2Vzc2Z1bGx5IGRlZmluZWQgaW4N Cj4gPj4gYm90aCBJRVRGDQo+ID4+PiAmIElUVS1UIHdpdGhvdXQgdGhpcyBsZXZlbCBvZiBhbmFs eXNpcyBvZiB0aGUgaW5pdGlhbCANCj4gcmVxdWlyZW1lbnRzIC0NCj4gPj4gYSBncmVhdA0KPiA+ Pj4gbWFueSAoYSBnb29kIGNodW5rIG9mIHdoaWNoIHdlcmUgZXh0cmVtZWx5IHN1Y2Nlc3NmdWwp Lg0KPiA+Pj4gDQo+ID4+PiBUaGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGlzIG5vdCBhYm91dCBz cGVjaWZ5aW5nIHNvbHV0aW9ucy4NCj4gPj4+IA0KPiA+Pj4gVGhlIGtleSBxdWVzdGlvbiBpczog YXJlIHRoZSByZXF1aXJlbWVudHMgY2xlYXIgZW5vdWdoIHRoYXQgaXQgaXMNCj4gPj4gdW5kZXJz dG9vZA0KPiA+Pj4gd2hhdCBpcyByZXF1aXJlZCBzbyBzb21lb25lIGNvdWxkIGJ1aWxkIGEgYm94 L3Byb3RvY29sL3doYXRldmVyIHRvDQo+ID4gbWVldA0KPiA+Pj4gdGhlbT8NCj4gPj4+IA0KPiA+ Pj4gSWYgd2Ugd2FudCB0byBnbyBpbnRvIHRoZSBudGggbGV2ZWwgb2YgZGV0YWlsIG9uIGVhY2gg DQo+IHJlcXVpcmVtZW50IHdlDQo+ID4gd2lsbA0KPiA+Pj4gc3RpbGwgYmUgZGViYXRpbmcgdGhp cyBieSB0aGUgdGltZSBJIHJldGlyZSAod2hpY2ggaXNuJ3QgZHVlIHVudGlsDQo+ID4gMjA0NSku DQo+ID4+PiANCj4gPj4+IEJlbg0KPiA+Pj4gDQo+ID4+PiANCj4gPj4+IE9uIDE2LzA0LzIwMDkg MDg6MDQsICJBbGV4YW5kZXIgVmFpbnNodGVpbiINCj4gPj4+IDxBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT4gd3JvdGU6DQo+ID4+PiANCj4gPj4+PiBBZHJpYW4sDQo+ID4+Pj4gVGhh bmsgeW91IGZvciBhIHByb21wdCBhbmQgZGV0YWlsZWQgcmVzcG9uc2UuDQo+ID4+Pj4gDQo+ID4+ Pj4gVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50 Og0KPiA+Pj4+IA0KPiA+Pj4+IDxxdW90ZT4NCj4gPj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3 IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzDQo+ID4+Pj4gYXJlIGEg c3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KPiA+Pj4+IDxl bmQgcXVvdGU+DQo+ID4+Pj4gDQo+ID4+Pj4gVGhpcyBzdGF0ZW1lbnQgd291bGQgYmUgb2J2aW91 c2x5IGNvcnJlY3QsIHdlcmUgaXQgbm90IGZvcg0KPiA+PiBSZXF1aXJlbWVudCAzNCBpbg0KPiA+ Pj4+IHRoZSBsYXRlc3QNCj4gPj4+PiBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdA0KPiA+Pj4+ IA0KPiA+PiAoDQo+ID4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtbXBscy10cC1yZXF1aXJlDQptZW50cy0wNi50eHQNCj4gKToNCj4+Pj4gDQo+Pj4+ IDxxdW90ZT4NCj4+Pj4gVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1J UHMgYW5kIG90aGVyIGludGVybmFsDQo+Pj4+IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2Yg YSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCj4+Pj4gcGF0aCBhdCBlYWNoIChz dWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmcNCj4+Pj4gcmVsYXRpb25zaGlw IG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQgZGlyZWN0aW9ucyBvZiB0aGF0DQo+Pj4+ IHRyYW5zcG9ydCBwYXRoLg0KPj4+PiA8ZW5kIHF1b3RlPg0KPj4+PiANCj4+Pj4gUGxlYXNlIG5v dGUgdGhhdCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZSBsaXN0IHRoYXQg aXMNCj4gDQo+PiBzcGVjaWZpYw0KPj4+PiBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQ cy4gKFRoZSBwYWlyaW5nIHJlcXVpcmVtZW50cyBhdCBlbmQNCj4+IHBvaW50cw0KPj4+PiBmb3Ig Y28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIGV4YWN0bHkg dGhlDQo+PiBzYW1lIGV2ZW4NCj4+Pj4gaWYgdGhleSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudCBp dGVtcyBpbiB0aGUgcmVxdWlyZW1lbnRzJyBsaXN0KS4NCj4+Pj4gSW4gb3RoZXIgd29yZHMsIHdp dGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlvbiBvZiBjby1yb3V0ZWQNCj4+IGJpZGlyZWN0 aW9uYWwNCj4+Pj4gcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50 Lg0KPj4+PiANCj4+Pj4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1l bnQgKCJvdGhlciBpbnRlcm5hbA0KPiBmdW5jdGlvbnMNCj4+Pj4gYXMgYXBwcm9wcmlhdGUiKSBj cmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcgc3VwcG9ydCBvZiB0aGUgcGFpcmluZw0KPj4gYXdh cmVuZXNzDQo+Pj4+IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC4N Cj4+Pj4gDQo+Pj4+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2VzIHRo aXMgc3VzcGljaW9uOg0KPj4+PiANCj4+Pj4gPHF1b3RlPg0KPj4+PiBUYW5kZW0gQ29ubmVjdGlv bjogQSB0YW5kZW0gY29ubmVjdGlvbiBpcyBhbiBhcmJpdHJhcnkgcGFydCBvZiBhDQo+Pj4+IHRy YW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5kZXBlbmRlbnRs eSBmcm9tDQo+IHRoZQ0KPj4+PiBlbmQtdG8tZW5kIG1vbml0b3JpbmcgKE9BTSkuIEl0IG1heSBi ZSBhIG1vbml0b3JlZCBzZWdtZW50IG9yIGENCj4+Pj4gbW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBz ZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguIFRoZSB0YW5kZW0NCj4+Pj4gY29ubmVjdGlvbiBt YXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVuZ2luZShzKSBvZiB0aGUgbm9kZShzKQ0K Pj4+PiBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBvciBjb25jYXRlbmF0ZWQgc2VnbWVu dC4NCj4+Pj4gPGVuZCBxdW90ZT4NCj4+Pj4gDQo+Pj4+IERvZXNuJ3QgImZvcndhcmRpbmcgZW5n aW5lIiBzb3VuZCBsaWtlIGhhcmR3YXJlIHRvIHlvdT8NCj4+Pj4gDQo+Pj4+IElNSE8gaXQgaXMg d29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUCBSZXF1aXJlbWVudHMgZHJhZnQN Cj4+Pj4gbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25lDQo+Pj4+IA0KPj4gKA0K PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAt b2FtLXJlcXVpcmVtZW50cy0wMS50eA0KPiANCj4+Pj4gdCkNCj4+Pj4gY29udGFpbiBhbnkgcmVx dWlyZW1lbnRzIGRlYWxpbmcgd2l0aCB0YW5kZW0gY29ubmVjdGlvbnMuDQo+Pj4+IA0KPj4+PiBC dXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNIEZy YW1ld29yaw0KPiBkcmFmdA0KPj4+PiANCj4+ICgNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcmFtZXdvcmstMDAudHh0DQo+ICku DQo+Pj4+IA0KPj4+PiBUaGUgYm90dG9tIGxpbmUsIElNSE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5 IHJlZ2FyZGluZyBjby1yb3V0ZWQgdnMuDQo+PiBhc3NvY2lhdGVkDQo+Pj4+IGJpZGlyZWN0aW9u YWwNCj4+Pj4gcGF0aHMgaXMgc3RpbGwgcmVxdWlyZWQuIE9uZSB3YXkgdG8gcHJvdmlkZSB0aGF0 IGNvdWxkIGJlIGJ5DQo+IGV4cGxpY2l0bHkNCj4+Pj4gbGltaXRpbmcgUmVxdWlyZW1lbnQgMzQN Cj4+Pj4gdG8gc3BlY2lmaWMgZnVuY3Rpb25hbGl0eS4NCj4+Pj4gDQo+Pj4+IE15IDJjLA0KPj4+ PiBTYXNoYQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gRnJvbTogQWRyaWFuIEZhcnJl bCBbYWRyaWFuQG9sZGRvZy5jby51a10NCj4+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAy MDA5IDEyOjEzIEFNDQo+Pj4+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsg QlVTSSBJVEFMTw0KPj4+PiBDYzogbXBscy10cEBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTog W21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KPj4gcmVx dWlyZW1lbnRzDQo+Pj4+IA0KPj4+PiBIaSBTYXNoYSwNCj4+Pj4gDQo+Pj4+IE5vdCByZWFsbHkg c3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwgYnV0Li4uDQo+Pj4+ IA0KPj4+Pj4gMS4gTXkgcmVhZGluZyBvZiBvbmUgb2YgQmVuJ3MgbWVzc2FnZXMgaXMgdGhhdCBh c3NvY2lhdGVkDQo+Pj4+PiBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBv ZiBwYXRocyB0aGF0IGNhbiBiZQ0KPj4+Pj4gY3JlYXRlZCBpbiB0aGUgZXhpc3RpbmcgbmV0d29y a3M7ICJ0cnVlIiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KPj4+Pj4gcGF0aHMgd2lsbCBoYXZl IHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lcw0KPj4+Pj4gYXZh aWxhYmxlLg0KPj4+PiBUaGlzIGlzIGNsZWFybHkgbm9uc2Vuc2UhDQo+Pj4+IEZyb20gdGhlIHBv aW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMgYXJl DQo+IGENCj4+Pj4gc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1Bz Lg0KPj4+PiANCj4+Pj4gSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMg KGUuZy4gdXNpbmcgdGhlIG1hbmFnZW1lbnQNCj4gDQo+PiBwbGFuZSkNCj4+Pj4geW91IGNhbiBz dXJlbHkgc2V0IHVwIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPj4+PiANCj4+Pj4g VGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkIGJpZGly ZWN0aW9uYWwNCj4+IExTUHMgdXNpbmcNCj4+Pj4gdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVp dGhlciB1c2UgdGhlIEdNUExTICh3aGljaCBpcyBjbGVhbmVyKSBvcg0KPj4+PiBub24tc3RhbmRh cmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpcyBtZXNzeSBidXQgZnVuY3Rpb25hbCku DQo+Pj4+IA0KPj4+PiBCdXQgKG9mIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29u dHJvbCBwbGFuZSBzb2x1dGlvbnMgaGF2ZQ0KPiANCj4+IG5vdGhpbmcNCj4+Pj4gdG8gZG8gd2l0 aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50IGFzIHRoZXkgYXJlIHNvZnR3YXJlIHNvbHV0aW9u cy4NCj4+Pj4gDQo+Pj4+PiAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMg aXMgdGhhdCB0aGUgYWN0dWFsIGRyaXZlcg0KPiBmb3INCj4+Pj4+IGNvLXJvdXRlZA0KPj4+Pj4g YmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIHRyYW5z cG9ydA0KPiBuZXR3b3Jrcw0KPj4+Pj4gcmF0aGVyDQo+Pj4+PiB0aGFuIGFueSBzcGVjaWZpYyBi ZW5lZml0Lg0KPj4+PiBJc24ndCB0aGF0IHRoZSBjYXNlIHdpdGggNzUlIG9mIHRoZSBNUExTLVRQ IHJlcXVpcmVtZW50cz8NCj4+Pj4gV2hpY2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0aGlu Zy4NCj4+Pj4gDQo+Pj4+IEEgbGFyZ2UgZHJpdmVyIGZvciBNUExTLVRQIGlzIHRvIGdpdmUgdGhl IHBhY2tldCBuZXR3b3JrIHRoZSBsb29rLA0KPj4gZmVlbCwgYW5kDQo+Pj4+IGJlaGF2aW9yYWwg Y2hhcmFjdGVyaXN0aWNzIG9mIGEgImxlZ2FjeSIgdHJhbnNwb3J0IG5ldHdvcmsuDQo+Pj4+IA0K Pj4+Pj4gQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRoYXQ6 DQo+Pj4+PiAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0IGZv ciB0aGUgdGltZQ0KPj4+Pj4gYmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mIGJpZGly ZWN0aW9uYWwgcGF0aHMgaW4NCj4+Pj4+IE1QTFMtVFANCj4+Pj4gSSB0aGluayB0aGF0IGlzIHdy b25nIGJvdGggZ2l2ZW4gbXkgc3RhdGVtZW50IGFib3ZlLCBhbmQgZ2l2ZW4gdGhhdA0KPj4gb3Ro ZXINCj4+Pj4gdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZSBuZWVk ZWQgdG8gcmVhY2ggdGhlIGZ1bGwNCj4+Pj4gZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC4NCj4+ Pj4gDQo+Pj4+PiAqIHRoZXkgaGFkIGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5 cGUgb2YgYmlkaXJlY3Rpb25hbA0KPj4+Pj4gcGF0aHMgaW4gcmVhbCBkZXBsb3ltZW50cy4NCj4+ Pj4gSSBkb24ndCBzZWUgd2hhdCB0aGF0IGZvbGxvd3MgZnJvbS4NCj4+Pj4gDQo+Pj4+IENoZWVy cywNCj4+Pj4gQWRyaWFuDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+Pj4+IG1wbHMtdHBAaWV0 Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRw DQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPj4+IG1wbHMtdHBAaWV0Zi5vcmcNCj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4+PiANCj4+PiAN Cj4+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPj4gbXBscy10cEBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+PiANCj4+IA0KPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ IFpURSAgSW5mb3JtYXRpb24gIFNlY3VyaXR5ICBOb3RpY2U6ICBUaGUgIGluZm9ybWF0aW9uICBj b250YWluZWQgIGluDQo+IHRoaXMgIG1haWwgIGlzICBzb2xlbHkgIHByb3BlcnR5ICBvZiAgdGhl ICBzZW5kZXIncyAgb3JnYW5pemF0aW9uLiAgVGhpcw0KPiBtYWlsICBjb21tdW5pY2F0aW9uICBp cyAgY29uZmlkZW50aWFsLiAgUmVjaXBpZW50cyAgbmFtZWQgIGFib3ZlICBhcmUNCj4gb2JsaWdh dGVkICB0byAgbWFpbnRhaW4gIHNlY3JlY3kgIGFuZCAgYXJlICBub3QgIHBlcm1pdHRlZCAgdG8g IGRpc2Nsb3NlDQo+IHRoZSAgY29udGVudHMgIG9mICB0aGlzICBjb21tdW5pY2F0aW9uICB0byAg b3RoZXJzLg0KPj4gVGhpcyAgZW1haWwgIGFuZCAgYW55ICBmaWxlcyAgdHJhbnNtaXR0ZWQgIHdp dGggIGl0ICBhcmUgIGNvbmZpZGVudGlhbA0KPiBhbmQgIGludGVuZGVkICBzb2xlbHkgIGZvciAg dGhlICB1c2UgIG9mICB0aGUgIGluZGl2aWR1YWwgIG9yICBlbnRpdHkgIHRvDQo+IHdob20gIHRo ZXkgIGFyZSAgYWRkcmVzc2VkLiAgSWYgIHlvdSAgaGF2ZSAgcmVjZWl2ZWQgIHRoaXMgIGVtYWls ICBpbg0KPiBlcnJvciAgcGxlYXNlICBub3RpZnkgIHRoZSAgb3JpZ2luYXRvciAgb2YgIHRoZSAg bWVzc2FnZS4gIEFueSAgdmlld3MNCj4gZXhwcmVzc2VkICBpbiAgdGhpcyAgbWVzc2FnZSAgYXJl ICB0aG9zZSAgb2YgIHRoZSAgaW5kaXZpZHVhbCAgc2VuZGVyLg0KPj4gVGhpcyAgbWVzc2FnZSAg aGFzICBiZWVuICBzY2FubmVkICBmb3IgIHZpcnVzZXMgIGFuZCAgU3BhbSAgYnkgIFpURQ0KPiBB bnRpLVNwYW0gIHN5c3RlbS4NCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlz DQo+IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcw0KPiBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUNCj4gbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NCj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQNCj4gc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYNCj4geW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZQ0KPiBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVz c2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwNCj4gc2VuZGVyLg0KPiBUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gbXBscy10cEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQpt cGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMtdHANCg== From liu.guoman@zte.com.cn Mon Apr 20 00:28:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6530B3A67D1 for ; Mon, 20 Apr 2009 00:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.202 X-Spam-Level: X-Spam-Status: No, score=-97.202 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bteB1iS45jg2 for ; Mon, 20 Apr 2009 00:28:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 394833A6978 for ; Mon, 20 Apr 2009 00:28:25 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 11164764009499; Mon, 20 Apr 2009 15:19:40 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 90033.1746388837; Mon, 20 Apr 2009 15:25:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3K7TPUT066233; Mon, 20 Apr 2009 15:29:25 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: Ben Niven-Jenkins MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 20 Apr 2009 15:27:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-20 15:29:17, Serialize complete at 2009-04-20 15:29:17 Content-Type: multipart/alternative; boundary="=_alternative 00291F3B4825759E_=" X-MAIL: mse2.zte.com.cn n3K7TPUT066233 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:28:28 -0000 This is a multipart message in MIME format. --=_alternative 00291F3B4825759E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QmVuOg0KIHlvdSBjYW4gd3JvbmdseSB1bmRlcnN0YW5kIG15IG1lYW5pbmcgLCBoZXJlIEkgd2Fu dCB0byBjbGFyaWZ5IGl0IGlzIA0KdW5uZWNlc3NhcnkgZm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCBwYXRoIHRvIGtlZXAgc3ltbWV0cmljIGJhbmR3aWR0aCANCmluIGJvdGggZm9yd2FyZCBh bmQgYmFja3dhcmQgcGF0aC4NCm1heWJlIG15IGV4cHJlc3NpbmcgaXNuJ3QgIGNsYXJpZnkgdG8g bWFrZSB5b3UgdG8gZGlmZnVsdGx5IHVuZGVyc3RhbmQgaXQuDQpoZXJlIEkgc2F5IHNvcnJ5IHRv IGFsbA0KDQpyZWdhcmRzDQpsaXUgDQoNCg0KDQpCZW4gTml2ZW4tSmVua2lucyA8YmVuamFtaW4u bml2ZW4tamVua2luc0BidC5jb20+IA0KMjAwOS0wNC0yMCAxNDowMg0KDQrK1bz+yMsNCjxsaXUu Z3VvbWFuQHp0ZS5jb20uY24+LCBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0Ks63LzQ0K PG1wbHMtdHBAaWV0Zi5vcmc+DQrW98ziDQpSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0KDQoNCg0KDQoNCkxpdSwNCg0K DQpPbiAyMC8wNC8yMDA5IDAyOjAwLCAibGl1Lmd1b21hbkB6dGUuY29tLmNuIiA8bGl1Lmd1b21h bkB6dGUuY29tLmNuPiANCndyb3RlOg0KDQo+IGxvdToNCj4gICAgIGJlY2F1c2UgVGhlIGZvcndh cmQgYW5kIGJhY2t3YXJkIGRpcmVjdGlvbnMgYXJlIHNldHVwLCBtb25pdG9yZWQgYW5kDQo+IHBy b3RlY3RlZCBpbmRlcGVuZGVudCBpbiB0aGUgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhz LiBpdCBjYW4ndA0KPiBlbnN1cmUgYW5kIHJlYWxpemUgdGhlIHN5bW1ldHJpYyBiYW5kd2lkdGgg aW4gdHdvIGRpcmVjdGlvbmFsIHBhdGguDQo+IG9yIGVsc2UgLCBJIE1VU1QgcmV2aXNlIHRoZSBk ZWZpbml0aW9ucyBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgDQpwYXRocw0KPiBpbiBtcGxz LXRwIHJlcXVpcmVtZW50cyBkcmFmdC4NCg0KWW91IGFyZSBjbGFpbWluZyB0aGF0IGl0IGlzIG5v dCBwb3NzaWJsZSBmb3IgdGhlIGVuZCBwb2ludHMgb2YgYW4gDQphc3NvY2lhdGVkDQpiaWRpcmVj dGlvbmFsIHBhdGggdG8gZW5zdXJlIHRoYXQgYm90aCBkaXJlY3Rpb25zIGhhdmUgdGhlIHNhbWUg YmFuZHdpZHRoDQphdHRyaWJ1dGVzLiBUaGlzIGlzIGNsZWFybHkgSU1PIGluY29ycmVjdC4NCg0K TGV0J3MgdGFrZSBhIHJlYWwgd29ybGQgZXhhbXBsZSB0byBpbGx1c3RyYXRlIHdoeSBpdCBpcyBp bmNvcnJlY3QuIElmIGl0DQp3ZXJlIHRydWUgdGhlbiBpdCB3b3VsZCBub3QgYmUgcG9zc2libGUg Zm9yIGV4YW1wbGUgdG8gc3VwcG9ydCBFMSBQV3MgaW4NCk1QTFMgbmV0d29ya3MgdG9kYXkuIFN1 Y2ggRTEgUFdzIGFyZSBzdWNjZXNzZnVsbHkgYmVpbmcgdXNlZCBpbiBNUExTDQpuZXR3b3JrcyB0 b2RheSB0byBzdXBwb3J0IGN1c3RvbWVyIHNlcnZpY2VzLg0KDQpCZW4NCg0KDQoNCj4gDQo+IHJl Z2FyZHMNCj4gbGl1IA0KPiANCj4gDQo+IA0KPiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0 Pg0KPiAyMDA5LTA0LTE3IDIxOjU0DQo+IA0KPiDK1bz+yMsNCj4gbGl1Lmd1b21hbkB6dGUuY29t LmNuDQo+ILOty80NCj4gQmVuIE5pdmVuLUplbmtpbnMgPGJlbmphbWluLm5pdmVuLWplbmtpbnNA YnQuY29tPiwgbXBscy10cEBpZXRmLm9yZw0KPiDW98ziDQo+IFJlOiBbbXBscy10cF0gQXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiBMaXUsDQo+ICAgICAgICAgICAgICAgICAgV2h5IGlzbid0IGl0IG5l Y2Vzc2FyeSBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQo+IHBhdGhzPyAgSXMgaXQgdGhh dA0KPiBhc3ltbWV0cmljIGlzIHRoZSBzb2xlIHJlcXVpcmVtZW50PyAgSWYgbm90LCBJIGRvbid0 IHVuZGVyc3RhbmQgeW91cg0KPiBjb21tZW50Lg0KPiANCj4gTG91DQo+IA0KPiBPbiA0LzE2LzIw MDkgOToxNSBQTSwgbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOg0KPj4gDQo+PiBMb3U6DQo+ PiBJIGFncmVlIHlvdXIgYWR2aWNlLCBidXQgZm9yIHN5bW1ldHJpYyBiYW5kd2lkdGggcmVxdWly ZW1lbnQsIEkgdGhpbmsNCj4+IHRoZSByZXF1aXJlbWVudCBjYW4gb25seSBiZSBmaXQgZm9yIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPj4gcGF0aHMsIHdoaWxlIGl0IGlzbid0 IG5lY2Vzc2FyeSBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIC5zbw0KPj4gYWRk aW5nIGEgImNvLXJvdXRlZCIgd29yZCBpbiB0aGUgcmVxdWlyZW1lbnQgMzMgaXMgbmVjZXNzYXJ5 Lg0KPj4gdGhhbmsgeW91Lg0KPj4gbGl1DQo+PiANCj4+IA0KPj4gKkxvdSBCZXJnZXIgPGxiZXJn ZXJAbGFibi5uZXQ+Kg0KPj4gt6K8/sjLOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCj4+IA0K Pj4gMjAwOS0wNC0xNiAyMTo0Mw0KPj4gDQo+PiANCj4+IMrVvP7Iyw0KPj4gICAgICAgICAgICAg ICAgQmVuIE5pdmVuLUplbmtpbnMgPGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPg0KPj4g s63LzQ0KPj4gICAgICAgICAgICAgICAgQlVTSUBjb3JlMy5hbXNsLmNvbSwgIm1wbHMtdHBAaWV0 Zi5vcmciDQo+IDxtcGxzLXRwQGlldGYub3JnPiwgSVRBTE8NCj4+IDxJdGFsby5CdXNpQGFsY2F0 ZWwtbHVjZW50Lml0Pg0KPj4g1vfM4g0KPj4gICAgICAgICAgICAgICAgUmU6IFttcGxzLXRwXSBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCj4gcmVxdWlyZW1lbnRzDQo+ PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gQmVuLA0KPj4gSXQgc2Vl bXMgdG8gbWUgdGhhdCBtdWNoIG9mIHRoZSBkaXNjdXNzaW9uIHN0ZW1zIGZyb20gdGhlIHNlY3Rp b24gaW4NCj4+IHdoaWNoIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgbGlzdGVkLg0KPj4gDQo+PiBS ZXF1aXJlbWVudCAzMiBpcyBhIHNlcnZpY2UgbGV2ZWwgcmVxdWlyZW1lbnQgYW5kIHByaW1hcmls eSBpbXBhY3QgdGhlDQo+PiBtYW5hZ2VtZW50IGFuZCBjb250cm9sIHBsYW5lcy4gQXMgdGhlcmUg aXMgbm8gc2VjdGlvbiBkZXNjcmliaW5nDQo+PiBzZXJ2aWNlIHJlcXVpcmVtZW50cywgSSBzdWdn ZXN0IG1vdmluZyB0aGlzIHJlcXVpcmVtZW50IHRvIGZvbGxvdw0KPj4gcmVxdWlyZW1lbnQgNiwg YW5kIGFkZGluZyB0aGUgZm9sbG93aW5nIGluIGl0cyBwbGFjZToNCj4+IDMzIE1QTFMtVFAgTVVT VCBzdXBwb3J0IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGhzIHdpdGgNCj4+IHN5bW1ldHJp YyBiYW5kd2lkdGggcmVxdWlyZW1lbnRzLCBpLmUuIHRoZSBhbW91bnQgb2YgcmVzZXJ2ZWQNCj4+ IGJhbmR3aWR0aCBpcyB0aGUgc2FtZSBiZXR3ZWVuIHRoZSBmb3J3YXJkIGFuZCBiYWNrd2FyZA0K Pj4gZGlyZWN0aW9ucy4NCj4+IA0KPj4gV2hpbGUgdGhpcyB0b28gaXMgYSBzZXJ2aWNlIHJlcXVp cmVtZW50IGFuZCBkb2Vzbid0IHJlcXVpcmUgYW55IA0KaGFyZHdhcmUNCj4+IG1vZGlmaWNhdGlv bnMsIGl0IHBhcmFsbGVscyBjdXJyZW50IHJlcXVpcmVtZW50cyAzNywgNDAgYW5kIDQxLiBJdCBh bHNvDQo+PiBtYWtlcyBhIGN1cnJlbnRseSBpbXBsaWNpdCByZXF1aXJlbWVudCBleHBsaWNpdC4N Cj4+IA0KPj4gUmVxdWlyZW1lbnRzIDMzLTI2IHJlbGF0ZSB0byAiYXdhcmVuZXNzIiBzaG91bGQg aGF2ZSBubyBpbXBsaWNhdGlvbiBvbg0KPj4gdGhlIGRhdGEvZm9yd2FyZGluZyBwbGFuZSBhbmQg YXJlIElNTyBib3RoIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2wgcGxhbmUNCj4+IHJlcXVpcmVtZW50 cy4gKEFuZCB5ZXMsIHRoZXkgaGF2ZSBpbXBsaWNhdGlvbnMgb24gT0FNIGFuZCByZWNvdmVyeS4p IEkNCj4+IHRoaW5rIEFkcmlhbiByYWlzZXMgYSBnb29kIHBvaW50IFdSVCB0aGVzZSByZXF1aXJl bWVudHMsIGkuZS4sIGFyZSANCnRoZXNlDQo+PiByZXF1aXJlbWVudHMgbGlzdGVkIGFzIHNvbHV0 aW9ucyB0byBzb21lIHVubGlzdGVkIHJlcXVpcmVtZW50cy4gSWYgc28sDQo+PiB0aGUgdW5saXN0 ZWQgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSBpbmNsdWRlZCBhbmQgdGhlc2Ugc2hvdWxkIGJlDQo+ PiBkcm9wcGVkLiBJZiBub3QsIHNvIGJlIGl0LCBidXQgdGhleSBzaG91bGQgYmUgbW92ZWQgZnJv bSBzZWN0aW9uIDIuMy4NCj4+IA0KPj4gV2hpbGUgSSdtIHN1cmUgdGhpcyB3b24ndCBlbmQgdGhl IGRpc2N1c3Npb24sIEkgdGhpbmsgdGhlc2UgY2hhbmdlcyANCndpbGwNCj4+IGhlbHAgbWFrZSAi dGhlIHJlcXVpcmVtZW50cyBjbGVhciBlbm91Z2ggLi4uIg0KPj4gDQo+PiBMb3UNCj4+IA0KPj4g T24gNC8xNi8yMDA5IDU6NTggQU0sIEJlbiBOaXZlbi1KZW5raW5zIHdyb3RlOg0KPj4+IENvbGxl YWd1ZXMsDQo+Pj4gDQo+Pj4gSSBjYW4ndCBoZWxwIGJ1dCBmZWVsIHdlIGFyZSBvdmVyYW5hbHlz aW5nIHRoaW5ncyBoZXJlLiBIb3cgbWFueQ0KPj4+IHRlY2hub2xvZ2llcy9wcm90b2NvbHMvbWVj aGFuaXNtcyBoYXZlIHdlIHN1Y2Nlc3NmdWxseSBkZWZpbmVkIGluDQo+PiBib3RoIElFVEYNCj4+ PiAmIElUVS1UIHdpdGhvdXQgdGhpcyBsZXZlbCBvZiBhbmFseXNpcyBvZiB0aGUgaW5pdGlhbCBy ZXF1aXJlbWVudHMgLQ0KPj4gYSBncmVhdA0KPj4+IG1hbnkgKGEgZ29vZCBjaHVuayBvZiB3aGlj aCB3ZXJlIGV4dHJlbWVseSBzdWNjZXNzZnVsKS4NCj4+PiANCj4+PiBUaGUgcmVxdWlyZW1lbnRz IGRvY3VtZW50IGlzIG5vdCBhYm91dCBzcGVjaWZ5aW5nIHNvbHV0aW9ucy4NCj4+PiANCj4+PiBU aGUga2V5IHF1ZXN0aW9uIGlzOiBhcmUgdGhlIHJlcXVpcmVtZW50cyBjbGVhciBlbm91Z2ggdGhh dCBpdCBpcw0KPj4gdW5kZXJzdG9vZA0KPj4+IHdoYXQgaXMgcmVxdWlyZWQgc28gc29tZW9uZSBj b3VsZCBidWlsZCBhIGJveC9wcm90b2NvbC93aGF0ZXZlciB0bw0KPiBtZWV0DQo+Pj4gdGhlbT8N Cj4+PiANCj4+PiBJZiB3ZSB3YW50IHRvIGdvIGludG8gdGhlIG50aCBsZXZlbCBvZiBkZXRhaWwg b24gZWFjaCByZXF1aXJlbWVudCB3ZQ0KPiB3aWxsDQo+Pj4gc3RpbGwgYmUgZGViYXRpbmcgdGhp cyBieSB0aGUgdGltZSBJIHJldGlyZSAod2hpY2ggaXNuJ3QgZHVlIHVudGlsDQo+IDIwNDUpLg0K Pj4+IA0KPj4+IEJlbg0KPj4+IA0KPj4+IA0KPj4+IE9uIDE2LzA0LzIwMDkgMDg6MDQsICJBbGV4 YW5kZXIgVmFpbnNodGVpbiINCj4+PiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ IHdyb3RlOg0KPj4+IA0KPj4+PiBBZHJpYW4sDQo+Pj4+IFRoYW5rIHlvdSBmb3IgYSBwcm9tcHQg YW5kIGRldGFpbGVkIHJlc3BvbnNlLg0KPj4+PiANCj4+Pj4gVW5mb3J0dW5hdGVseSBJIGNhbm5v dCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50Og0KPj4+PiANCj4+Pj4gPHF1b3RlPg0K Pj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1BzDQo+Pj4+IGFyZSBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgTFNQcy4NCj4+Pj4gPGVuZCBxdW90ZT4NCj4+Pj4gDQo+Pj4+IFRoaXMgc3RhdGVt ZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0IG5vdCBmb3INCj4+IFJlcXVp cmVtZW50IDM0IGluDQo+Pj4+IHRoZSBsYXRlc3QNCj4+Pj4gTVBMUy1UUCByZXF1aXJlbWVudHMg ZHJhZnQNCj4+Pj4gDQo+PiAoDQo+IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXJlcXVpcmVtZW50cy0wNi50eHQNCj4gKToNCj4+Pj4gDQo+ Pj4+IDxxdW90ZT4NCj4+Pj4gVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMs IE1JUHMgYW5kIG90aGVyIGludGVybmFsDQo+Pj4+IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkg b2YgYSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCj4+Pj4gcGF0aCBhdCBlYWNo IChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmcNCj4+Pj4gcmVsYXRpb25z aGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQgZGlyZWN0aW9ucyBvZiB0aGF0DQo+ Pj4+IHRyYW5zcG9ydCBwYXRoLg0KPj4+PiA8ZW5kIHF1b3RlPg0KPj4+PiANCj4+Pj4gUGxlYXNl IG5vdGUgdGhhdCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZSBsaXN0IHRo YXQgaXMNCj4gDQo+PiBzcGVjaWZpYw0KPj4+PiBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg TFNQcy4gKFRoZSBwYWlyaW5nIHJlcXVpcmVtZW50cyBhdCBlbmQNCj4+IHBvaW50cw0KPj4+PiBm b3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIGV4YWN0 bHkgdGhlDQo+PiBzYW1lIGV2ZW4NCj4+Pj4gaWYgdGhleSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVu dCBpdGVtcyBpbiB0aGUgcmVxdWlyZW1lbnRzJyBsaXN0KS4NCj4+Pj4gSW4gb3RoZXIgd29yZHMs IHdpdGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlvbiBvZiBjby1yb3V0ZWQNCj4+IGJpZGly ZWN0aW9uYWwNCj4+Pj4gcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250 ZW50Lg0KPj4+PiANCj4+Pj4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWly ZW1lbnQgKCJvdGhlciBpbnRlcm5hbA0KPiBmdW5jdGlvbnMNCj4+Pj4gYXMgYXBwcm9wcmlhdGUi KSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcgc3VwcG9ydCBvZiB0aGUgcGFpcmluZw0KPj4g YXdhcmVuZXNzDQo+Pj4+IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBp dC4NCj4+Pj4gDQo+Pj4+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2Vz IHRoaXMgc3VzcGljaW9uOg0KPj4+PiANCj4+Pj4gPHF1b3RlPg0KPj4+PiBUYW5kZW0gQ29ubmVj dGlvbjogQSB0YW5kZW0gY29ubmVjdGlvbiBpcyBhbiBhcmJpdHJhcnkgcGFydCBvZiBhDQo+Pj4+ IHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5kZXBlbmRl bnRseSBmcm9tDQo+IHRoZQ0KPj4+PiBlbmQtdG8tZW5kIG1vbml0b3JpbmcgKE9BTSkuIEl0IG1h eSBiZSBhIG1vbml0b3JlZCBzZWdtZW50IG9yIGENCj4+Pj4gbW9uaXRvcmVkIGNvbmNhdGVuYXRl ZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguIFRoZSB0YW5kZW0NCj4+Pj4gY29ubmVjdGlv biBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVuZ2luZShzKSBvZiB0aGUgbm9kZShz KQ0KPj4+PiBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBvciBjb25jYXRlbmF0ZWQgc2Vn bWVudC4NCj4+Pj4gPGVuZCBxdW90ZT4NCj4+Pj4gDQo+Pj4+IERvZXNuJ3QgImZvcndhcmRpbmcg ZW5naW5lIiBzb3VuZCBsaWtlIGhhcmR3YXJlIHRvIHlvdT8NCj4+Pj4gDQo+Pj4+IElNSE8gaXQg aXMgd29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUCBSZXF1aXJlbWVudHMgZHJh ZnQNCj4+Pj4gbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25lDQo+Pj4+IA0KPj4g KA0KPiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBs cy10cC1vYW0tcmVxdWlyZW1lbnRzLTAxLnR4DQoNCj4gDQo+Pj4+IHQpDQo+Pj4+IGNvbnRhaW4g YW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGggdGFuZGVtIGNvbm5lY3Rpb25zLg0KPj4+PiAN Cj4+Pj4gQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBNUExTLVRQ IE9BTSBGcmFtZXdvcmsNCj4gZHJhZnQNCj4+Pj4gDQo+PiAoDQo+IA0KaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcmFtZXdvcmstMDAu dHh0DQoNCj4gKS4NCj4+Pj4gDQo+Pj4+IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBz b21lIGNsYXJpdHkgcmVnYXJkaW5nIGNvLXJvdXRlZCB2cy4NCj4+IGFzc29jaWF0ZWQNCj4+Pj4g YmlkaXJlY3Rpb25hbA0KPj4+PiBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdheSB0byBw cm92aWRlIHRoYXQgY291bGQgYmUgYnkNCj4gZXhwbGljaXRseQ0KPj4+PiBsaW1pdGluZyBSZXF1 aXJlbWVudCAzNA0KPj4+PiB0byBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5Lg0KPj4+PiANCj4+Pj4g TXkgMmMsDQo+Pj4+IFNhc2hhDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBGcm9tOiBB ZHJpYW4gRmFycmVsIFthZHJpYW5Ab2xkZG9nLmNvLnVrXQ0KPj4+PiBTZW50OiBUaHVyc2RheSwg QXByaWwgMTYsIDIwMDkgMTI6MTMgQU0NCj4+Pj4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBM b3UgQmVyZ2VyOyBCVVNJIElUQUxPDQo+Pj4+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+Pj4+IFN1 YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBw YXRoDQo+PiByZXF1aXJlbWVudHMNCj4+Pj4gDQo+Pj4+IEhpIFNhc2hhLA0KPj4+PiANCj4+Pj4g Tm90IHJlYWxseSBzdXJlIHdoZXRoZXIgeW91IGFyZSBtaXNyZXByZXNlbnRpbmcgYW55b25lLCBi dXQuLi4NCj4+Pj4gDQo+Pj4+PiAxLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBCZW4ncyBtZXNzYWdl cyBpcyB0aGF0IGFzc29jaWF0ZWQNCj4+Pj4+IGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBv bmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQgY2FuIGJlDQo+Pj4+PiBjcmVhdGVkIGluIHRoZSBleGlz dGluZyBuZXR3b3JrczsgInRydWUiIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsDQo+Pj4+PiBwYXRo cyB3aWxsIGhhdmUgdG8gd2FpdCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVudCBiZWNvbWVz DQo+Pj4+PiBhdmFpbGFibGUuDQo+Pj4+IFRoaXMgaXMgY2xlYXJseSBub25zZW5zZSENCj4+Pj4g RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkIGJpZGlyZWN0aW9u YWwgTFNQcyBhcmUNCj4gYQ0KPj4+PiBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIExTUHMuDQo+Pj4+IA0KPj4+PiBJZiB5b3UgY2FuIHNldCB1cCB0d28gdW5pZGlyZWN0 aW9uYWwgTFNQcyAoZS5nLiB1c2luZyB0aGUgbWFuYWdlbWVudA0KPiANCj4+IHBsYW5lKQ0KPj4+ PiB5b3UgY2FuIHN1cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuDQo+ Pj4+IA0KPj4+PiBUaGVyZSBhcmUgc2hpcHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1y b3V0ZWQgYmlkaXJlY3Rpb25hbA0KPj4gTFNQcyB1c2luZw0KPj4+PiB0aGUgY29udHJvbCBwbGFu ZS4gVGhlc2UgZWl0aGVyIHVzZSB0aGUgR01QTFMgKHdoaWNoIGlzIGNsZWFuZXIpIG9yDQo+Pj4+ IG5vbi1zdGFuZGFyZCBwcm9wcmlldGFyeSBzb2x1dGlvbnMgKHdoaWNoIGlzIG1lc3N5IGJ1dCBm dW5jdGlvbmFsKS4NCj4+Pj4gDQo+Pj4+IEJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBw bGFuZSBvciBjb250cm9sIHBsYW5lIHNvbHV0aW9ucyBoYXZlDQo+IA0KPj4gbm90aGluZw0KPj4+ PiB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMgdGhleSBhcmUgc29mdHdh cmUgc29sdXRpb25zLg0KPj4+PiANCj4+Pj4+IDIuIE15IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwn cyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWwgZHJpdmVyDQo+IGZvcg0KPj4+Pj4gY28tcm91 dGVkDQo+Pj4+PiBiaWRpcmVjdGlvbmFsIHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhp c3RpbmcgdHJhbnNwb3J0DQo+IG5ldHdvcmtzDQo+Pj4+PiByYXRoZXINCj4+Pj4+IHRoYW4gYW55 IHNwZWNpZmljIGJlbmVmaXQuDQo+Pj4+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2Yg dGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPw0KPj4+PiBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlz IGEgYmFkIHRoaW5nLg0KPj4+PiANCj4+Pj4gQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMtVFAgaXMg dG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsgdGhlIGxvb2ssDQo+PiBmZWVsLCBhbmQNCj4+Pj4g YmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSAibGVnYWN5IiB0cmFuc3BvcnQgbmV0d29y ay4NCj4+Pj4gDQo+Pj4+PiBCYXNlZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVzcyAo RldJVykgdGhhdDoNCj4+Pj4+ICogYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSwg YXQgbGVhc3QgZm9yIHRoZSB0aW1lDQo+Pj4+PiBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5 cGUgb2YgYmlkaXJlY3Rpb25hbCBwYXRocyBpbg0KPj4+Pj4gTVBMUy1UUA0KPj4+PiBJIHRoaW5r IHRoYXQgaXMgd3JvbmcgYm90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZCBnaXZlbiB0 aGF0DQo+PiBvdGhlcg0KPj4+PiB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9ucyB3 aWxsIGJlIG5lZWRlZCB0byByZWFjaCB0aGUgZnVsbA0KPj4+PiBmdW5jdGlvbiBsZXZlbCBvZiBN UExTLVRQLg0KPj4+PiANCj4+Pj4+ICogdGhleSBoYWQgYSBnb29kIGNoYW5jZSB0byByZW1haW4g dGhlIG9ubHkgdHlwZSBvZiBiaWRpcmVjdGlvbmFsDQo+Pj4+PiBwYXRocyBpbiByZWFsIGRlcGxv eW1lbnRzLg0KPj4+PiBJIGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93cyBmcm9tLg0KPj4+PiAN Cj4+Pj4gQ2hlZXJzLA0KPj4+PiBBZHJpYW4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4+Pj4g bXBscy10cEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMtdHANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+Pj4gbXBscy10cEBpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0K Pj4+IA0KPj4+IA0KPj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+PiBtcGxzLXRwQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4+IA0K Pj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4gWlRFICBJbmZvcm1hdGlvbiAgU2VjdXJpdHkgIE5vdGljZTogIFRoZSAgaW5m b3JtYXRpb24gIGNvbnRhaW5lZCAgaW4NCj4gdGhpcyAgbWFpbCAgaXMgIHNvbGVseSAgcHJvcGVy dHkgIG9mICB0aGUgIHNlbmRlcidzICBvcmdhbml6YXRpb24uICBUaGlzDQo+IG1haWwgIGNvbW11 bmljYXRpb24gIGlzICBjb25maWRlbnRpYWwuICBSZWNpcGllbnRzICBuYW1lZCAgYWJvdmUgIGFy ZQ0KPiBvYmxpZ2F0ZWQgIHRvICBtYWludGFpbiAgc2VjcmVjeSAgYW5kICBhcmUgIG5vdCAgcGVy bWl0dGVkICB0byAgZGlzY2xvc2UNCj4gdGhlICBjb250ZW50cyAgb2YgIHRoaXMgIGNvbW11bmlj YXRpb24gIHRvICBvdGhlcnMuDQo+PiBUaGlzICBlbWFpbCAgYW5kICBhbnkgIGZpbGVzICB0cmFu c21pdHRlZCAgd2l0aCAgaXQgIGFyZSAgY29uZmlkZW50aWFsDQo+IGFuZCAgaW50ZW5kZWQgIHNv bGVseSAgZm9yICB0aGUgIHVzZSAgb2YgIHRoZSAgaW5kaXZpZHVhbCAgb3IgIGVudGl0eSB0bw0K PiB3aG9tICB0aGV5ICBhcmUgIGFkZHJlc3NlZC4gIElmICB5b3UgIGhhdmUgIHJlY2VpdmVkICB0 aGlzICBlbWFpbCAgaW4NCj4gZXJyb3IgIHBsZWFzZSAgbm90aWZ5ICB0aGUgIG9yaWdpbmF0b3Ig IG9mICB0aGUgIG1lc3NhZ2UuICBBbnkgIHZpZXdzDQo+IGV4cHJlc3NlZCAgaW4gIHRoaXMgIG1l c3NhZ2UgIGFyZSAgdGhvc2UgIG9mICB0aGUgIGluZGl2aWR1YWwgIHNlbmRlci4NCj4+IFRoaXMg IG1lc3NhZ2UgIGhhcyAgYmVlbiAgc2Nhbm5lZCAgZm9yICB2aXJ1c2VzICBhbmQgIFNwYW0gIGJ5 ICBaVEUNCj4gQW50aS1TcGFtICBzeXN0ZW0uDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCANCmlzDQo+IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcw0KPiBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFy ZQ0KPiBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8gb3RoZXJzLg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVuZGVkDQo+IHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCmFk ZHJlc3NlZC4gSWYNCj4geW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVh c2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIA0KdGhlDQo+IG1lc3NhZ2UuIEFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0KPiBz ZW5kZXIuDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBT cGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+IG1wbHMt dHBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz LXRwDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUg c2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBh ZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRo aXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBB bnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00291F3B4825759E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlbjo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO3lvdSBjYW4gd3JvbmdseSB1bmRlcnN0 YW5kIG15DQptZWFuaW5nICwgaGVyZSBJIHdhbnQgdG8gY2xhcmlmeSBpdCBpcyB1bm5lY2Vzc2Fy eSBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpwYXRoIHRvIGtlZXAgc3ltbWV0cmljIGJh bmR3aWR0aCBpbiBib3RoIGZvcndhcmQgYW5kIGJhY2t3YXJkIHBhdGguPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5tYXliZSBteSBleHByZXNzaW5nIGlzbid0ICZu YnNwO2NsYXJpZnkNCnRvIG1ha2UgeW91IHRvIGRpZmZ1bHRseSB1bmRlcnN0YW5kIGl0LjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aGVyZSBJIHNheSBzb3JyeSB0 byBhbGw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnJl Z2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxpdSA8L2Zv bnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+QmVuIE5p dmVuLUplbmtpbnMgJmx0O2JlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tJmd0OzwvYj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTIwIDE0OjAy PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZsdDtsaXUuZ3VvbWFuQHp0ZS5jb20uY24mZ3Q7LCBMb3UgQmVyZ2VyDQombHQ7bGJlcmdlckBs YWJuLm5ldCZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDttcGxzLXRwQGlldGYub3JnJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwN CnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+TGl1LDxicj4NCjxicj4NCjxicj4NCk9uIDIw LzA0LzIwMDkgMDI6MDAsICZxdW90O2xpdS5ndW9tYW5AenRlLmNvbS5jbiZxdW90OyAmbHQ7bGl1 Lmd1b21hbkB6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBsb3U6PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IGJlY2F1c2UgVGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkIGRpcmVj dGlvbnMgYXJlIHNldHVwLA0KbW9uaXRvcmVkIGFuZDxicj4NCiZndDsgcHJvdGVjdGVkIGluZGVw ZW5kZW50IGluIHRoZSBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMuIGl0IGNhbid0PGJy Pg0KJmd0OyBlbnN1cmUgYW5kIHJlYWxpemUgdGhlIHN5bW1ldHJpYyBiYW5kd2lkdGggaW4gdHdv IGRpcmVjdGlvbmFsIHBhdGguPGJyPg0KJmd0OyBvciBlbHNlICwgSSBNVVNUIHJldmlzZSB0aGUg ZGVmaW5pdGlvbnMgb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpwYXRoczxicj4NCiZndDsg aW4gbXBscy10cCByZXF1aXJlbWVudHMgZHJhZnQuPGJyPg0KPGJyPg0KWW91IGFyZSBjbGFpbWlu ZyB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZSBmb3IgdGhlIGVuZCBwb2ludHMgb2YgYW4gYXNzb2Np YXRlZDxicj4NCmJpZGlyZWN0aW9uYWwgcGF0aCB0byBlbnN1cmUgdGhhdCBib3RoIGRpcmVjdGlv bnMgaGF2ZSB0aGUgc2FtZSBiYW5kd2lkdGg8YnI+DQphdHRyaWJ1dGVzLiBUaGlzIGlzIGNsZWFy bHkgSU1PIGluY29ycmVjdC48YnI+DQo8YnI+DQpMZXQncyB0YWtlIGEgcmVhbCB3b3JsZCBleGFt cGxlIHRvIGlsbHVzdHJhdGUgd2h5IGl0IGlzIGluY29ycmVjdC4gSWYgaXQ8YnI+DQp3ZXJlIHRy dWUgdGhlbiBpdCB3b3VsZCBub3QgYmUgcG9zc2libGUgZm9yIGV4YW1wbGUgdG8gc3VwcG9ydCBF MSBQV3MgaW48YnI+DQpNUExTIG5ldHdvcmtzIHRvZGF5LiBTdWNoIEUxIFBXcyBhcmUgc3VjY2Vz c2Z1bGx5IGJlaW5nIHVzZWQgaW4gTVBMUzxicj4NCm5ldHdvcmtzIHRvZGF5IHRvIHN1cHBvcnQg Y3VzdG9tZXIgc2VydmljZXMuPGJyPg0KPGJyPg0KQmVuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IHJlZ2FyZHM8YnI+DQomZ3Q7IGxpdSA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQm Z3Q7PGJyPg0KJmd0OyAyMDA5LTA0LTE3IDIxOjU0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IMrVvP7I yzxicj4NCiZndDsgbGl1Lmd1b21hbkB6dGUuY29tLmNuPGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0 OyBCZW4gTml2ZW4tSmVua2lucyAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7 LCBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0OyBSZTogW21wbHMtdHBd IEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHM8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IExpdSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V2h5DQppc24ndCBpdCBuZWNlc3Nh cnkgZm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbDxicj4NCiZndDsgcGF0aHM/ICZuYnNwO0lz IGl0IHRoYXQ8YnI+DQomZ3Q7IGFzeW1tZXRyaWMgaXMgdGhlIHNvbGUgcmVxdWlyZW1lbnQ/ICZu YnNwO0lmIG5vdCwgSSBkb24ndCB1bmRlcnN0YW5kDQp5b3VyPGJyPg0KJmd0OyBjb21tZW50Ljxi cj4NCiZndDsgPGJyPg0KJmd0OyBMb3U8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gNC8xNi8yMDA5 IDk6MTUgUE0sIGxpdS5ndW9tYW5AenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBMb3U6PGJyPg0KJmd0OyZndDsgSSBhZ3JlZSB5b3VyIGFkdmljZSwgYnV0IGZv ciBzeW1tZXRyaWMgYmFuZHdpZHRoIHJlcXVpcmVtZW50LA0KSSB0aGluazxicj4NCiZndDsmZ3Q7 IHRoZSByZXF1aXJlbWVudCBjYW4gb25seSBiZSBmaXQgZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydDxicj4NCiZndDsmZ3Q7IHBhdGhzLCB3aGlsZSBpdCBpc24ndCBuZWNlc3Nh cnkgZm9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocw0KLnNvPGJyPg0KJmd0OyZndDsg YWRkaW5nIGEgJnF1b3Q7Y28tcm91dGVkJnF1b3Q7IHdvcmQgaW4gdGhlIHJlcXVpcmVtZW50IDMz IGlzIG5lY2Vzc2FyeS48YnI+DQomZ3Q7Jmd0OyB0aGFuayB5b3UuPGJyPg0KJmd0OyZndDsgbGl1 PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgKkxvdSBCZXJnZXIg Jmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7Kjxicj4NCiZndDsmZ3Q7ILeivP7IyzogbXBscy10cC1i b3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgMjAwOS0wNC0xNiAy MTo0Mzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IMrVvP7Iyzxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtCZW4gTml2ZW4tSmVua2lucw0KJmx0O2JlbmphbWluLm5pdmVuLWplbmtpbnNA YnQuY29tJmd0Ozxicj4NCiZndDsmZ3Q7ILOty808YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QlVTSUBjb3JlMy5hbXNs LmNvbSwNCiZxdW90O21wbHMtdHBAaWV0Zi5vcmcmcXVvdDs8YnI+DQomZ3Q7ICZsdDttcGxzLXRw QGlldGYub3JnJmd0OywgSVRBTE88YnI+DQomZ3Q7Jmd0OyAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVs LWx1Y2VudC5pdCZndDs8YnI+DQomZ3Q7Jmd0OyDW98ziPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JlOiBbbXBscy10 cF0NCkFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aDxicj4NCiZndDsgcmVx dWlyZW1lbnRzPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQmVuLDxicj4NCiZndDsmZ3Q7IEl0IHNlZW1z IHRvIG1lIHRoYXQgbXVjaCBvZiB0aGUgZGlzY3Vzc2lvbiBzdGVtcyBmcm9tIHRoZSBzZWN0aW9u DQppbjxicj4NCiZndDsmZ3Q7IHdoaWNoIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgbGlzdGVkLjxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFJlcXVpcmVtZW50IDMyIGlzIGEgc2VydmljZSBs ZXZlbCByZXF1aXJlbWVudCBhbmQgcHJpbWFyaWx5IGltcGFjdA0KdGhlPGJyPg0KJmd0OyZndDsg bWFuYWdlbWVudCBhbmQgY29udHJvbCBwbGFuZXMuIEFzIHRoZXJlIGlzIG5vIHNlY3Rpb24gZGVz Y3JpYmluZzxicj4NCiZndDsmZ3Q7IHNlcnZpY2UgcmVxdWlyZW1lbnRzLCBJIHN1Z2dlc3QgbW92 aW5nIHRoaXMgcmVxdWlyZW1lbnQgdG8gZm9sbG93PGJyPg0KJmd0OyZndDsgcmVxdWlyZW1lbnQg NiwgYW5kIGFkZGluZyB0aGUgZm9sbG93aW5nIGluIGl0cyBwbGFjZTo8YnI+DQomZ3Q7Jmd0OyAz MyBNUExTLVRQIE1VU1Qgc3VwcG9ydCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRocyB3aXRo PGJyPg0KJmd0OyZndDsgc3ltbWV0cmljIGJhbmR3aWR0aCByZXF1aXJlbWVudHMsIGkuZS4gdGhl IGFtb3VudCBvZiByZXNlcnZlZDxicj4NCiZndDsmZ3Q7IGJhbmR3aWR0aCBpcyB0aGUgc2FtZSBi ZXR3ZWVuIHRoZSBmb3J3YXJkIGFuZCBiYWNrd2FyZDxicj4NCiZndDsmZ3Q7IGRpcmVjdGlvbnMu PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgV2hpbGUgdGhpcyB0b28gaXMgYSBzZXJ2aWNl IHJlcXVpcmVtZW50IGFuZCBkb2Vzbid0IHJlcXVpcmUgYW55DQpoYXJkd2FyZTxicj4NCiZndDsm Z3Q7IG1vZGlmaWNhdGlvbnMsIGl0IHBhcmFsbGVscyBjdXJyZW50IHJlcXVpcmVtZW50cyAzNywg NDAgYW5kIDQxLg0KSXQgYWxzbzxicj4NCiZndDsmZ3Q7IG1ha2VzIGEgY3VycmVudGx5IGltcGxp Y2l0IHJlcXVpcmVtZW50IGV4cGxpY2l0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFJl cXVpcmVtZW50cyAzMy0yNiByZWxhdGUgdG8gJnF1b3Q7YXdhcmVuZXNzJnF1b3Q7IHNob3VsZCBo YXZlDQpubyBpbXBsaWNhdGlvbiBvbjxicj4NCiZndDsmZ3Q7IHRoZSBkYXRhL2ZvcndhcmRpbmcg cGxhbmUgYW5kIGFyZSBJTU8gYm90aCBtYW5hZ2VtZW50IGFuZCBjb250cm9sDQpwbGFuZTxicj4N CiZndDsmZ3Q7IHJlcXVpcmVtZW50cy4gKEFuZCB5ZXMsIHRoZXkgaGF2ZSBpbXBsaWNhdGlvbnMg b24gT0FNIGFuZCByZWNvdmVyeS4pDQpJPGJyPg0KJmd0OyZndDsgdGhpbmsgQWRyaWFuIHJhaXNl cyBhIGdvb2QgcG9pbnQgV1JUIHRoZXNlIHJlcXVpcmVtZW50cywgaS5lLiwNCmFyZSB0aGVzZTxi cj4NCiZndDsmZ3Q7IHJlcXVpcmVtZW50cyBsaXN0ZWQgYXMgc29sdXRpb25zIHRvIHNvbWUgdW5s aXN0ZWQgcmVxdWlyZW1lbnRzLg0KSWYgc28sPGJyPg0KJmd0OyZndDsgdGhlIHVubGlzdGVkIHJl cXVpcmVtZW50cyBzaG91bGQgYmUgaW5jbHVkZWQgYW5kIHRoZXNlIHNob3VsZA0KYmU8YnI+DQom Z3Q7Jmd0OyBkcm9wcGVkLiBJZiBub3QsIHNvIGJlIGl0LCBidXQgdGhleSBzaG91bGQgYmUgbW92 ZWQgZnJvbSBzZWN0aW9uDQoyLjMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgV2hpbGUg SSdtIHN1cmUgdGhpcyB3b24ndCBlbmQgdGhlIGRpc2N1c3Npb24sIEkgdGhpbmsgdGhlc2UgY2hh bmdlcw0Kd2lsbDxicj4NCiZndDsmZ3Q7IGhlbHAgbWFrZSAmcXVvdDt0aGUgcmVxdWlyZW1lbnRz IGNsZWFyIGVub3VnaCAuLi4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBMb3U8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiA0LzE2LzIwMDkgNTo1OCBBTSwgQmVuIE5p dmVuLUplbmtpbnMgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7IENvbGxlYWd1ZXMsPGJyPg0KJmd0 OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBJIGNhbid0IGhlbHAgYnV0IGZlZWwgd2UgYXJl IG92ZXJhbmFseXNpbmcgdGhpbmdzIGhlcmUuIEhvdw0KbWFueTxicj4NCiZndDsmZ3Q7Jmd0OyB0 ZWNobm9sb2dpZXMvcHJvdG9jb2xzL21lY2hhbmlzbXMgaGF2ZSB3ZSBzdWNjZXNzZnVsbHkgZGVm aW5lZA0KaW48YnI+DQomZ3Q7Jmd0OyBib3RoIElFVEY8YnI+DQomZ3Q7Jmd0OyZndDsgJmFtcDsg SVRVLVQgd2l0aG91dCB0aGlzIGxldmVsIG9mIGFuYWx5c2lzIG9mIHRoZSBpbml0aWFsDQpyZXF1 aXJlbWVudHMgLTxicj4NCiZndDsmZ3Q7IGEgZ3JlYXQ8YnI+DQomZ3Q7Jmd0OyZndDsgbWFueSAo YSBnb29kIGNodW5rIG9mIHdoaWNoIHdlcmUgZXh0cmVtZWx5IHN1Y2Nlc3NmdWwpLjxicj4NCiZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBp cyBub3QgYWJvdXQgc3BlY2lmeWluZyBzb2x1dGlvbnMuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyBUaGUga2V5IHF1ZXN0aW9uIGlzOiBhcmUgdGhlIHJlcXVpcmVtZW50cyBj bGVhciBlbm91Z2ggdGhhdA0KaXQgaXM8YnI+DQomZ3Q7Jmd0OyB1bmRlcnN0b29kPGJyPg0KJmd0 OyZndDsmZ3Q7IHdoYXQgaXMgcmVxdWlyZWQgc28gc29tZW9uZSBjb3VsZCBidWlsZCBhIGJveC9w cm90b2NvbC93aGF0ZXZlcg0KdG88YnI+DQomZ3Q7IG1lZXQ8YnI+DQomZ3Q7Jmd0OyZndDsgdGhl bT88YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IElmIHdlIHdhbnQgdG8gZ28g aW50byB0aGUgbnRoIGxldmVsIG9mIGRldGFpbCBvbiBlYWNoIHJlcXVpcmVtZW50DQp3ZTxicj4N CiZndDsgd2lsbDxicj4NCiZndDsmZ3Q7Jmd0OyBzdGlsbCBiZSBkZWJhdGluZyB0aGlzIGJ5IHRo ZSB0aW1lIEkgcmV0aXJlICh3aGljaCBpc24ndCBkdWUNCnVudGlsPGJyPg0KJmd0OyAyMDQ1KS48 YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEJlbjxicj4NCiZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDE2LzA0LzIwMDkgMDg6 MDQsICZxdW90O0FsZXhhbmRlciBWYWluc2h0ZWluJnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZs dDtBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQWRyaWFuLDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgVGhhbmsgeW91IGZvciBhIHByb21wdCBhbmQgZGV0YWlsZWQgcmVzcG9uc2UuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFVuZm9ydHVuYXRlbHkgSSBjYW5u b3QgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudDo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwNCkxTUHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGFyZSBhIHNwZWNpYWwgY2FzZSBvZiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtl bmQgcXVvdGUmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IFRoaXMgc3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0IG5vdA0K Zm9yPGJyPg0KJmd0OyZndDsgUmVxdWlyZW1lbnQgMzQgaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IHRoZSBsYXRlc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE1QTFMtVFAgcmVxdWlyZW1lbnRzIGRy YWZ0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAoPGJyPg0KJmd0OyBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtcmVxdWly ZW1lbnRzLTA2LnR4dDxicj4NCiZndDsgKTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhlIGlu dGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5kIG90aGVyDQppbnRlcm5h bDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsDQp0cmFuc3BvcnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHBh dGggYXQgZWFjaCAoc3ViLSlsYXllciBNVVNUIGJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNr d2FyZCBkaXJlY3Rpb25zDQpvZiB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc3BvcnQg cGF0aC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgUmVxdWly ZW1lbnQgMzQgaXMgdGhlIE9OTFkgaXRlbSBpbiB0aGUNCmxpc3QgdGhhdCBpczxicj4NCiZndDsg PGJyPg0KJmd0OyZndDsgc3BlY2lmaWM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGZvciBjby1yb3V0 ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhlIHBhaXJpbmcgcmVxdWlyZW1lbnRzDQphdCBlbmQ8 YnI+DQomZ3Q7Jmd0OyBwb2ludHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGZvciBjby1yb3V0ZWQg YW5kIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgZXhhY3RseQ0KdGhlPGJyPg0K Jmd0OyZndDsgc2FtZSBldmVuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBpZiB0aGV5IGFwcGVhciBp biB0d28gZGlmZmVyZW50IGl0ZW1zIGluIHRoZSByZXF1aXJlbWVudHMnDQpsaXN0KS48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IEluIG90aGVyIHdvcmRzLCB3aXRob3V0IFJlcXVpcmVtZW50IDM0IHRo ZSBub3Rpb24gb2YgY28tcm91dGVkPGJyPg0KJmd0OyZndDsgYmlkaXJlY3Rpb25hbDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250 ZW50Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgc29t ZXdoYXQgdmFndWUgc2NvcGUgb2YgdGhpcyByZXF1aXJlbWVudCAoJnF1b3Q7b3RoZXINCmludGVy bmFsPGJyPg0KJmd0OyBmdW5jdGlvbnM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGFzIGFwcHJvcHJp YXRlJnF1b3Q7KSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcgc3VwcG9ydA0Kb2YgdGhlIHBh aXJpbmc8YnI+DQomZ3Q7Jmd0OyBhd2FyZW5lc3M8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG1heSBi ZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFm dCBpbmNyZWFzZXMgdGhpcyBzdXNwaWNpb246PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7ICZsdDtxdW90ZSZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRhbmRl bSBDb25uZWN0aW9uOiBBIHRhbmRlbSBjb25uZWN0aW9uIGlzIGFuIGFyYml0cmFyeQ0KcGFydCBv ZiBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25p dG9yZWQgKHZpYSBPQU0pIGluZGVwZW5kZW50bHkNCmZyb208YnI+DQomZ3Q7IHRoZTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgZW5kLXRvLWVuZCBtb25pdG9yaW5nIChPQU0pLiBJdCBtYXkgYmUgYSBt b25pdG9yZWQgc2VnbWVudA0Kb3IgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgbW9uaXRvcmVkIGNv bmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguIFRoZQ0KdGFuZGVtPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyBjb25uZWN0aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRp bmcgZW5naW5lKHMpIG9mDQp0aGUgbm9kZShzKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYXQgdGhl IGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21lbnQuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBEb2Vzbid0ICZxdW90O2ZvcndhcmRpbmcgZW5naW5lJnF1b3Q7 IHNvdW5kIGxpa2UgaGFyZHdhcmUNCnRvIHlvdT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0aGVyIHRo ZSBNUExTLVRQIFJlcXVpcmVtZW50cw0KZHJhZnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG5vciB0 aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgKDxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1yZXF1aXJlbWVudHMtMDEudHg8YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgdCk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnRhaW4gYW55 IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGggdGFuZGVtIGNvbm5lY3Rpb25zLjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBCdXQgdGFuZGVtIGNvbm5lY3Rpb25z IGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNDQpGcmFtZXdvcms8YnI+DQomZ3Q7IGRy YWZ0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAoPGJyPg0KJmd0OyBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWZy YW1ld29yay0wMC50eHQ8YnI+DQomZ3Q7ICkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21lIGNsYXJp dHkgcmVnYXJkaW5nDQpjby1yb3V0ZWQgdnMuPGJyPg0KJmd0OyZndDsgYXNzb2NpYXRlZDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgYmlkaXJlY3Rpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcGF0 aHMgaXMgc3RpbGwgcmVxdWlyZWQuIE9uZSB3YXkgdG8gcHJvdmlkZSB0aGF0IGNvdWxkDQpiZSBi eTxicj4NCiZndDsgZXhwbGljaXRseTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgbGltaXRpbmcgUmVx dWlyZW1lbnQgMzQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRvIHNwZWNpZmljIGZ1bmN0aW9uYWxp dHkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE15IDJjLDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgU2FzaGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBG cm9tOiBBZHJpYW4gRmFycmVsIFthZHJpYW5Ab2xkZG9nLmNvLnVrXTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjEzIEFNPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IExvdSBCZXJnZXI7IEJVU0kgSVRB TE88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQNCnBhdGg8YnI+DQomZ3Q7Jmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSGkgU2FzaGEsPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlv dSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwNCmJ1dC4uLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMS4gTXkgcmVhZGluZyBvZiBvbmUgb2YgQmVu J3MgbWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgdGhlIG9ubHkgdHlwZXMgb2YgcGF0aHMgdGhhdA0KY2Fu IGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY3JlYXRlZCBpbiB0aGUgZXhpc3RpbmcgbmV0 d29ya3M7ICZxdW90O3RydWUmcXVvdDsNCmNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aHMgd2lsbCBoYXZlIHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIp IG5ldyBlcXVpcG1lbnQNCmJlY29tZXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdmFpbGFi bGUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGNsZWFybHkgbm9uc2Vuc2UhPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1y b3V0ZWQgYmlkaXJlY3Rpb25hbA0KTFNQcyBhcmU8YnI+DQomZ3Q7IGE8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSWYgeW91IGNhbiBzZXQg dXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgKGUuZy4gdXNpbmcNCnRoZSBtYW5hZ2VtZW50PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBwbGFuZSk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHlvdSBj YW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC48YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgYXJlIHNoaXBwaW5nIHNv bHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7Jmd0 OyBMU1BzIHVzaW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0aGUgY29udHJvbCBwbGFuZS4gVGhl c2UgZWl0aGVyIHVzZSB0aGUgR01QTFMgKHdoaWNoIGlzDQpjbGVhbmVyKSBvcjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgbm9uLXN0YW5kYXJkIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMg bWVzc3kgYnV0DQpmdW5jdGlvbmFsKS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgQnV0IChvZiBjb3Vyc2UpIHRoZSBtYW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRy b2wgcGxhbmUNCnNvbHV0aW9ucyBoYXZlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBub3RoaW5n PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1l bnQgYXMgdGhleSBhcmUgc29mdHdhcmUNCnNvbHV0aW9ucy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIuIE15IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwn cyBtZXNzYWdlcyBpcyB0aGF0IHRoZQ0KYWN0dWFsIGRyaXZlcjxicj4NCiZndDsgZm9yPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY28tcm91dGVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nDQp0cmFu c3BvcnQ8YnI+DQomZ3Q7IG5ldHdvcmtzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmF0aGVy PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhbiBhbnkgc3BlY2lmaWMgYmVuZWZpdC48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1Q TFMtVFAgcmVxdWlyZW1lbnRzPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgV2hpY2ggaXMgbm90IHRv IHNheSBpdCBpcyBhIGJhZCB0aGluZy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFj a2V0IG5ldHdvcmsNCnRoZSBsb29rLDxicj4NCiZndDsmZ3Q7IGZlZWwsIGFuZDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSAmcXVvdDtsZWdhY3km cXVvdDsgdHJhbnNwb3J0DQpuZXR3b3JrLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3Mg KEZXSVcpIHRoYXQ6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKiBhc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgcGF0aHMgYXJlLCBhdCBsZWFzdCBmb3INCnRoZSB0aW1lPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgYmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mIGJpZGlyZWN0aW9u YWwgcGF0aHMNCmluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTVBMUy1UUDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgSSB0aGluayB0aGF0IGlzIHdyb25nIGJvdGggZ2l2ZW4gbXkgc3RhdGVtZW50 IGFib3ZlLCBhbmQNCmdpdmVuIHRoYXQ8YnI+DQomZ3Q7Jmd0OyBvdGhlcjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZSBuZWVk ZWQgdG8NCnJlYWNoIHRoZSBmdWxsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiBsZXZl bCBvZiBNUExTLVRQLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgKiB0aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBlIG9m DQpiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aHMgaW4gcmVhbCBk ZXBsb3ltZW50cy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBm b2xsb3dzIGZyb20uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEFkcmlhbjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyZndDsmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7 IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBtcGxzLXRwIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7IFpURSAmbmJzcDtJbmZv cm1hdGlvbiAmbmJzcDtTZWN1cml0eSAmbmJzcDtOb3RpY2U6ICZuYnNwO1RoZSAmbmJzcDtpbmZv cm1hdGlvbg0KJm5ic3A7Y29udGFpbmVkICZuYnNwO2luPGJyPg0KJmd0OyB0aGlzICZuYnNwO21h aWwgJm5ic3A7aXMgJm5ic3A7c29sZWx5ICZuYnNwO3Byb3BlcnR5ICZuYnNwO29mICZuYnNwO3Ro ZQ0KJm5ic3A7c2VuZGVyJ3MgJm5ic3A7b3JnYW5pemF0aW9uLiAmbmJzcDtUaGlzPGJyPg0KJmd0 OyBtYWlsICZuYnNwO2NvbW11bmljYXRpb24gJm5ic3A7aXMgJm5ic3A7Y29uZmlkZW50aWFsLiAm bmJzcDtSZWNpcGllbnRzDQombmJzcDtuYW1lZCAmbmJzcDthYm92ZSAmbmJzcDthcmU8YnI+DQom Z3Q7IG9ibGlnYXRlZCAmbmJzcDt0byAmbmJzcDttYWludGFpbiAmbmJzcDtzZWNyZWN5ICZuYnNw O2FuZCAmbmJzcDthcmUNCiZuYnNwO25vdCAmbmJzcDtwZXJtaXR0ZWQgJm5ic3A7dG8gJm5ic3A7 ZGlzY2xvc2U8YnI+DQomZ3Q7IHRoZSAmbmJzcDtjb250ZW50cyAmbmJzcDtvZiAmbmJzcDt0aGlz ICZuYnNwO2NvbW11bmljYXRpb24gJm5ic3A7dG8NCiZuYnNwO290aGVycy48YnI+DQomZ3Q7Jmd0 OyBUaGlzICZuYnNwO2VtYWlsICZuYnNwO2FuZCAmbmJzcDthbnkgJm5ic3A7ZmlsZXMgJm5ic3A7 dHJhbnNtaXR0ZWQNCiZuYnNwO3dpdGggJm5ic3A7aXQgJm5ic3A7YXJlICZuYnNwO2NvbmZpZGVu dGlhbDxicj4NCiZndDsgYW5kICZuYnNwO2ludGVuZGVkICZuYnNwO3NvbGVseSAmbmJzcDtmb3Ig Jm5ic3A7dGhlICZuYnNwO3VzZSAmbmJzcDtvZg0KJm5ic3A7dGhlICZuYnNwO2luZGl2aWR1YWwg Jm5ic3A7b3IgJm5ic3A7ZW50aXR5ICZuYnNwO3RvPGJyPg0KJmd0OyB3aG9tICZuYnNwO3RoZXkg Jm5ic3A7YXJlICZuYnNwO2FkZHJlc3NlZC4gJm5ic3A7SWYgJm5ic3A7eW91ICZuYnNwO2hhdmUN CiZuYnNwO3JlY2VpdmVkICZuYnNwO3RoaXMgJm5ic3A7ZW1haWwgJm5ic3A7aW48YnI+DQomZ3Q7 IGVycm9yICZuYnNwO3BsZWFzZSAmbmJzcDtub3RpZnkgJm5ic3A7dGhlICZuYnNwO29yaWdpbmF0 b3IgJm5ic3A7b2YNCiZuYnNwO3RoZSAmbmJzcDttZXNzYWdlLiAmbmJzcDtBbnkgJm5ic3A7dmll d3M8YnI+DQomZ3Q7IGV4cHJlc3NlZCAmbmJzcDtpbiAmbmJzcDt0aGlzICZuYnNwO21lc3NhZ2Ug Jm5ic3A7YXJlICZuYnNwO3Rob3NlDQombmJzcDtvZiAmbmJzcDt0aGUgJm5ic3A7aW5kaXZpZHVh bCAmbmJzcDtzZW5kZXIuPGJyPg0KJmd0OyZndDsgVGhpcyAmbmJzcDttZXNzYWdlICZuYnNwO2hh cyAmbmJzcDtiZWVuICZuYnNwO3NjYW5uZWQgJm5ic3A7Zm9yDQombmJzcDt2aXJ1c2VzICZuYnNw O2FuZCAmbmJzcDtTcGFtICZuYnNwO2J5ICZuYnNwO1pURTxicj4NCiZndDsgQW50aS1TcGFtICZu YnNwO3N5c3RlbS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KbWFpbCBpczxicj4NCiZndDsgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0 aW9uDQppczxicj4NCiZndDsgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZTxicj4NCiZndDsgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv IG90aGVycy48YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kDQppbnRlbmRlZDxicj4NCiZndDsgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC4NCklmPGJyPg0KJmd0OyB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3INCm9mIHRoZTxicj4NCiZndDsgbWVzc2Fn ZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBp bmRpdmlkdWFsPGJyPg0KJmd0OyBzZW5kZXIuPGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtDQpzeXN0ZW0u PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG1wbHMtdHBAaWV0Zi5v cmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10 cDxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5m b3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1h dGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZu YnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZu YnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24m bmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJz cDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJz cDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7 dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlz Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWls Jm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgm bmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVk Jm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJz cDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2 ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZu YnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZu YnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZu YnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5 c3RlbS4NCjwvcHJlPg== --=_alternative 00291F3B4825759E_=-- From annamaria.fulignoli@ericsson.com Mon Apr 20 00:36:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331DE3A67F3 for ; Mon, 20 Apr 2009 00:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeEuC8ZbESb0 for ; Mon, 20 Apr 2009 00:36:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0A3363A67F0 for ; Mon, 20 Apr 2009 00:36:09 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4B4D820661; Mon, 20 Apr 2009 09:37:24 +0200 (CEST) X-AuditID: c1b4fb3c-aefd3bb00000238f-2e-49ec26343bee Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 20C8020245; Mon, 20 Apr 2009 09:37:24 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 09:37:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 09:37:22 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F94039755DF@esealmw118.eemea.ericsson.se> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm91k8eN17VNhFVQzmDnE7yj0tc5wBsbrrQAICREFA= References: <001901c9bc0a$dc6fd060$6802a8c0@china.huawei.com><6FD21B53861BF44AA90A288402036AB402145621@FRVELSMBS21.ad2.ad.alcatel.com><49E5EEC8.6080101@labn.net> <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> From: "Annamaria Fulignoli" To: "Eric Gray" , "Lou Berger" , "BUSI ITALO" X-OriginalArrivalTime: 20 Apr 2009 07:37:24.0028 (UTC) FILETIME=[D89857C0:01C9C18A] X-Brightmail-Tracker: AAAAAA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:36:11 -0000 Eric, I couldn't agree more! Annamaria=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Eric Gray Sent: venerd=EC 17 aprile 2009 20.15 To: Lou Berger; BUSI ITALO Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Lou/Italo, This gets into a fuzzy language area. I think it should be clear that use of associated (non-co-routed) bi-directional paths is not required. It also seems to me to be clear = that they might be used; hence support for them is needed in protocols = and other specifications. We all need to be precise in what we mean by what is required, and = where it is required. -- Eric -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Lou Berger Sent: Wednesday, April 15, 2009 10:27 AM To: BUSI ITALO Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Italo, On 4/14/2009 6:12 AM, BUSI ITALO wrote: > 2) we need to be clear that asssociated bidirectional paths are not=20 > required in transport networks (e.g. MPLS-TP) > This doesn't match draft-ietf-mpls-tp-requirements-06. Are you = proposing dropping associated bidirectional path from the TP = requirements document? Lou _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From liu.guoman@zte.com.cn Mon Apr 20 01:20:22 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38463A6A97 for ; Mon, 20 Apr 2009 01:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.585 X-Spam-Level: X-Spam-Status: No, score=-97.585 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5CupaNMXqZQ for ; Mon, 20 Apr 2009 01:20:18 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 35AC53A6809 for ; Mon, 20 Apr 2009 01:20:17 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Mon, 20 Apr 2009 16:14:16 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.1321030819; Mon, 20 Apr 2009 16:18:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3K8LZM8039932; Mon, 20 Apr 2009 16:21:36 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <93DFCD4B101EB440B5B72997456C5F94039755DF@esealmw118.eemea.ericsson.se> To: "Annamaria Fulignoli" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 20 Apr 2009 16:19:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-20 16:21:29, Serialize complete at 2009-04-20 16:21:29 Content-Type: multipart/alternative; boundary="=_alternative 002DE8BB4825759E_=" X-MAIL: mse1.zte.com.cn n3K8LZM8039932 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:20:22 -0000 This is a multipart message in MIME format. --=_alternative 002DE8BB4825759E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IGkgc3VwcG9ydCBBbm5hbWFyaWEsIEkgc2hvdWxkIGhhdmUgdGhlIHJlcXVpcmVtZW50cyBvZiBz dXBwb3J0aW5nIA0KYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGggaW4gbXBscy10cC4gYnV0 IGl0IGlzIHVubmVjZXNzYXJ5IHRvIGtlZXAgQlcgDQppbiBib3RoIGRpcmVjdGlvbmFsIHBhdGgu DQoNCnJlZ2FyZHMNCmxpdQ0KDQoNCg0KIkFubmFtYXJpYSBGdWxpZ25vbGkiIDxhbm5hbWFyaWEu ZnVsaWdub2xpQGVyaWNzc29uLmNvbT4gDQq3orz+yMs6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmcNCjIwMDktMDQtMjAgMTU6MzcNCg0KytW8/sjLDQoiRXJpYyBHcmF5IiA8ZXJpYy5ncmF5QGVy aWNzc29uLmNvbT4sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4sIA0KIkJVU0kgSVRB TE8iIDxJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0Pg0Ks63LzQ0KbXBscy10cEBpZXRmLm9y Zw0K1vfM4g0KUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0 IHBhdGggcmVxdWlyZW1lbnRzDQoNCg0KDQoNCg0KDQpFcmljLA0KSSBjb3VsZG4ndCBhZ3JlZSBt b3JlIQ0KDQpBbm5hbWFyaWEgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiANCk9mIEVyaWMgR3JheQ0KU2VudDogdmVuZXJkqKwgMTcgYXByaWxlIDIwMDkg MjAuMTUNClRvOiBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPDQpDYzogbXBscy10cEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0 IHBhdGggDQpyZXF1aXJlbWVudHMNCg0KTG91L0l0YWxvLA0KDQogICAgICAgICAgICAgICAgIFRo aXMgZ2V0cyBpbnRvIGEgZnV6enkgbGFuZ3VhZ2UgYXJlYS4NCg0KICAgICAgICAgICAgICAgICBJ IHRoaW5rIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0IHVzZSBvZiBhc3NvY2lhdGVkDQoobm9uLWNv LXJvdXRlZCkNCmJpLWRpcmVjdGlvbmFsIHBhdGhzIGlzIG5vdCByZXF1aXJlZC4gIEl0IGFsc28g c2VlbXMgdG8gbWUgdG8gYmUgY2xlYXIgDQp0aGF0IHRoZXkgbWlnaHQgYmUgdXNlZDsgaGVuY2Ug c3VwcG9ydCBmb3IgdGhlbSBpcyBuZWVkZWQgaW4gcHJvdG9jb2xzIGFuZCANCm90aGVyIHNwZWNp ZmljYXRpb25zLg0KDQogICAgICAgICAgICAgICAgIFdlIGFsbCBuZWVkIHRvIGJlIHByZWNpc2Ug aW4gd2hhdCB3ZSBtZWFuIGJ5IHdoYXQgaXMgDQpyZXF1aXJlZCwgYW5kIHdoZXJlIGl0IGlzIHJl cXVpcmVkLg0KDQotLQ0KRXJpYw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog bXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgDQpPZiBMb3UgQmVyZ2VyDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE1LCAy MDA5IDEwOjI3IEFNDQpUbzogQlVTSSBJVEFMTw0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo IA0KcmVxdWlyZW1lbnRzDQoNCkl0YWxvLA0KDQpPbiA0LzE0LzIwMDkgNjoxMiBBTSwgQlVTSSBJ VEFMTyB3cm90ZToNCj4gMikgd2UgbmVlZCB0byBiZSBjbGVhciB0aGF0IGFzc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgcGF0aHMgYXJlIG5vdCANCj4gcmVxdWlyZWQgaW4gdHJhbnNwb3J0IG5ldHdv cmtzIChlLmcuIE1QTFMtVFApDQo+DQoNClRoaXMgZG9lc24ndCBtYXRjaCBkcmFmdC1pZXRmLW1w bHMtdHAtcmVxdWlyZW1lbnRzLTA2LiAgQXJlIHlvdSBwcm9wb3NpbmcgDQpkcm9wcGluZyBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aCBmcm9tIHRoZSBUUCByZXF1aXJlbWVudHMgZG9jdW1l bnQ/DQoNCkxvdQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptcGxzLXRwIG1haWxpbmcgbGlzdA0KbXBscy10cEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMt dHBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10 cA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMt dHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVs eSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVu aWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGln YXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9z ZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1h aWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5k IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRp dmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz IGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 002DE8BB4825759E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+aQ0Kc3VwcG9ydCBBbm5hbWFyaWEsIEkgc2hvdWxkIGhh dmUgdGhlIHJlcXVpcmVtZW50cyBvZiBzdXBwb3J0aW5nIGFzc29jaWF0ZWQNCmJpZGlyZWN0aW9u YWwgcGF0aCBpbiBtcGxzLXRwLiBidXQgaXQgaXMgdW5uZWNlc3NhcnkgdG8ga2VlcCBCVyBpbiBi b3RoDQpkaXJlY3Rpb25hbCBwYXRoLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+cmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+bGl1PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPiZxdW90O0FubmFtYXJpYSBGdWxpZ25vbGkmcXVvdDsNCiZsdDthbm5hbWFyaWEu ZnVsaWdub2xpQGVyaWNzc29uLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0yMCAxNToz NzwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mcXVvdDtFcmljIEdyYXkmcXVvdDsgJmx0O2VyaWMuZ3JheUBlcmljc3Nvbi5jb20mZ3Q7LA0K JnF1b3Q7TG91IEJlcmdlciZxdW90OyAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDssICZxdW90O0JV U0kgSVRBTE8mcXVvdDsNCiZsdDtJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0Jmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+bXBscy10cEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVt ZW50czwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+RXJpYyw8YnI+DQpJIGNvdWxkbid0IGFncmVlIG1vcmUhPGJyPg0KPGJyPg0KQW5uYW1h cmlhIDxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbXBs cy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCk9mIEVyaWMgR3JheTxicj4NClNlbnQ6IHZlbmVyZKisIDE3IGFwcmlsZSAyMDA5 IDIwLjE1PGJyPg0KVG86IExvdSBCZXJnZXI7IEJVU0kgSVRBTE88YnI+DQpDYzogbXBscy10cEBp ZXRmLm9yZzxicj4NClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxicj4NCjxicj4NCkxvdS9JdGFsbyw8YnI+ DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KVGhpcyBnZXRzIGludG8gYSBmdXp6eSBsYW5ndWFnZSBhcmVhLjxicj4NCjxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQpJIHRoaW5rIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0IHVzZSBvZiBhc3NvY2lhdGVkPGJyPg0K KG5vbi1jby1yb3V0ZWQpPGJyPg0KYmktZGlyZWN0aW9uYWwgcGF0aHMgaXMgbm90IHJlcXVpcmVk LiAmbmJzcDtJdCBhbHNvIHNlZW1zIHRvIG1lIHRvIGJlIGNsZWFyDQp0aGF0IHRoZXkgbWlnaHQg YmUgdXNlZDsgaGVuY2Ugc3VwcG9ydCBmb3IgdGhlbSBpcyBuZWVkZWQgaW4gcHJvdG9jb2xzDQph bmQgb3RoZXIgc3BlY2lmaWNhdGlvbnMuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCldlIGFsbCBuZWVkIHRvIGJlIHBy ZWNpc2UgaW4gd2hhdCB3ZSBtZWFuIGJ5IHdoYXQgaXMgcmVxdWlyZWQsIGFuZCB3aGVyZQ0KaXQg aXMgcmVxdWlyZWQuPGJyPg0KPGJyPg0KLS08YnI+DQpFcmljPGJyPg0KPGJyPg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KT2YgTG91IEJlcmdlcjxi cj4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTUsIDIwMDkgMTA6MjcgQU08YnI+DQpUbzogQlVT SSBJVEFMTzxicj4NCkNjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KU3ViamVjdDogUmU6IFttcGxz LXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRz PGJyPg0KPGJyPg0KSXRhbG8sPGJyPg0KPGJyPg0KT24gNC8xNC8yMDA5IDY6MTIgQU0sIEJVU0kg SVRBTE8gd3JvdGU6PGJyPg0KJmd0OyAyKSB3ZSBuZWVkIHRvIGJlIGNsZWFyIHRoYXQgYXNzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgbm90DQo8YnI+DQomZ3Q7IHJlcXVpcmVkIGlu IHRyYW5zcG9ydCBuZXR3b3JrcyAoZS5nLiBNUExTLVRQKTxicj4NCiZndDs8YnI+DQo8YnI+DQpU aGlzIGRvZXNuJ3QgbWF0Y2ggZHJhZnQtaWV0Zi1tcGxzLXRwLXJlcXVpcmVtZW50cy0wNi4gJm5i c3A7QXJlIHlvdSBwcm9wb3NpbmcNCmRyb3BwaW5nIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBw YXRoIGZyb20gdGhlIFRQIHJlcXVpcmVtZW50cyBkb2N1bWVudD88YnI+DQo8YnI+DQpMb3U8YnI+ DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCm1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KbXBscy10cEBpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscy10cCBt YWlsaW5nIGxpc3Q8YnI+DQptcGxzLXRwQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCm1w bHMtdHBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtdHA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0lu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3Jt YXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMm bmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3Mm bmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5i c3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNw O3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhp cyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFp bCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRo Jm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRl ZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5i c3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hh dmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3Im bmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2Vk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMm bmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtz eXN0ZW0uDQo8L3ByZT4= --=_alternative 002DE8BB4825759E_=-- From benjamin.niven-jenkins@bt.com Mon Apr 20 01:34:56 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A8D3A6925 for ; Mon, 20 Apr 2009 01:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqkeJIYJx0p5 for ; Mon, 20 Apr 2009 01:34:55 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 6FEA93A67B0 for ; Mon, 20 Apr 2009 01:34:54 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 09:36:08 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Apr 2009 08:36:08 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 20 Apr 2009 09:36:04 +0100 From: Ben Niven-Jenkins To: Message-ID: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnBkwqpUwV9WqaNjEeSij89OguQGg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Apr 2009 08:36:08.0770 (UTC) FILETIME=[0D814A20:01C9C193] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:34:56 -0000 Liu, If I understand correctly you are saying associated bi-directional paths ca= n support both symmetric and asymmetric bandwidth transport paths. That is correct. Ben On 20/04/2009 08:27, "liu.guoman@zte.com.cn" wrote: > Ben: > you can wrongly understand my meaning , here I want to clarify it is > unnecessary for associated bidirectional path to keep symmetric bandwidth > in both forward and backward path. > maybe my expressing isn't clarify to make you to diffultly understand it= . > here I say sorry to all >=20 > regards > liu=20 >=20 >=20 >=20 > Ben Niven-Jenkins > 2009-04-20 14:02 >=20 > =CA=D5=BC=FE=C8=CB > , Lou Berger > =B3=AD=CB=CD > > =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidirectional transport path requirements >=20 >=20 >=20 >=20 >=20 >=20 > Liu, >=20 >=20 > On 20/04/2009 02:00, "liu.guoman@zte.com.cn" > wrote: >=20 >> lou: >> because The forward and backward directions are setup, monitored and >> protected independent in the associated bidirectional paths. it can't >> ensure and realize the symmetric bandwidth in two directional path. >> or else , I MUST revise the definitions of associated bidirectional > paths >> in mpls-tp requirements draft. >=20 > You are claiming that it is not possible for the end points of an > associated > bidirectional path to ensure that both directions have the same bandwidth > attributes. This is clearly IMO incorrect. >=20 > Let's take a real world example to illustrate why it is incorrect. If it > were true then it would not be possible for example to support E1 PWs in > MPLS networks today. Such E1 PWs are successfully being used in MPLS > networks today to support customer services. >=20 > Ben >=20 >=20 >=20 >>=20 >> regards >> liu=20 >>=20 >>=20 >>=20 >> Lou Berger >> 2009-04-17 21:54 >>=20 >> =CA=D5=BC=FE=C8=CB >> liu.guoman@zte.com.cn >> =B3=AD=CB=CD >> Ben Niven-Jenkins , mpls-tp@ietf.org >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Liu, >> Why isn't it necessary for associated bidirectional >> paths? Is it that >> asymmetric is the sole requirement? If not, I don't understand your >> comment. >>=20 >> Lou >>=20 >> On 4/16/2009 9:15 PM, liu.guoman@zte.com.cn wrote: >>>=20 >>> Lou: >>> I agree your advice, but for symmetric bandwidth requirement, I think >>> the requirement can only be fit for co-routed bidirectional transport >>> paths, while it isn't necessary for associated bidirectional paths .so >>> adding a "co-routed" word in the requirement 33 is necessary. >>> thank you. >>> liu >>>=20 >>>=20 >>> *Lou Berger * >>> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org >>>=20 >>> 2009-04-16 21:43 >>>=20 >>>=20 >>> =CA=D5=BC=FE=C8=CB >>> Ben Niven-Jenkins >>> =B3=AD=CB=CD >>> BUSI@core3.amsl.com, "mpls-tp@ietf.org" >> , ITALO >>> >>> =D6=F7=CC=E2 >>> Re: [mpls-tp] Associated bidirectional transport path >> requirements >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Ben, >>> It seems to me that much of the discussion stems from the section in >>> which these requirements are listed. >>>=20 >>> Requirement 32 is a service level requirement and primarily impact the >>> management and control planes. As there is no section describing >>> service requirements, I suggest moving this requirement to follow >>> requirement 6, and adding the following in its place: >>> 33 MPLS-TP MUST support bidirectional transport paths with >>> symmetric bandwidth requirements, i.e. the amount of reserved >>> bandwidth is the same between the forward and backward >>> directions. >>>=20 >>> While this too is a service requirement and doesn't require any > hardware >>> modifications, it parallels current requirements 37, 40 and 41. It also >>> makes a currently implicit requirement explicit. >>>=20 >>> Requirements 33-26 relate to "awareness" should have no implication on >>> the data/forwarding plane and are IMO both management and control plane >>> requirements. (And yes, they have implications on OAM and recovery.) I >>> think Adrian raises a good point WRT these requirements, i.e., are > these >>> requirements listed as solutions to some unlisted requirements. If so, >>> the unlisted requirements should be included and these should be >>> dropped. If not, so be it, but they should be moved from section 2.3. >>>=20 >>> While I'm sure this won't end the discussion, I think these changes > will >>> help make "the requirements clear enough ..." >>>=20 >>> Lou >>>=20 >>> On 4/16/2009 5:58 AM, Ben Niven-Jenkins wrote: >>>> Colleagues, >>>>=20 >>>> I can't help but feel we are overanalysing things here. How many >>>> technologies/protocols/mechanisms have we successfully defined in >>> both IETF >>>> & ITU-T without this level of analysis of the initial requirements - >>> a great >>>> many (a good chunk of which were extremely successful). >>>>=20 >>>> The requirements document is not about specifying solutions. >>>>=20 >>>> The key question is: are the requirements clear enough that it is >>> understood >>>> what is required so someone could build a box/protocol/whatever to >> meet >>>> them? >>>>=20 >>>> If we want to go into the nth level of detail on each requirement we >> will >>>> still be debating this by the time I retire (which isn't due until >> 2045). >>>>=20 >>>> Ben >>>>=20 >>>>=20 >>>> On 16/04/2009 08:04, "Alexander Vainshtein" >>>> wrote: >>>>=20 >>>>> Adrian, >>>>> Thank you for a prompt and detailed response. >>>>>=20 >>>>> Unfortunately I cannot fully agree with your statement: >>>>>=20 >>>>> >>>>> From the point of view of hardware, co-routed bidirectional LSPs >>>>> are a special case of associated bidirectional LSPs. >>>>> >>>>>=20 >>>>> This statement would be obviously correct, were it not for >>> Requirement 34 in >>>>> the latest >>>>> MPLS-TP requirements draft >>>>>=20 >>> ( >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.tx= t >> ): >>>>>=20 >>>>> >>>>> The intermediate nodes (including MEPs, MIPs and other internal >>>>> functions as appropriate) of a co-routed bidirectional transport >>>>> path at each (sub-)layer MUST be aware of the pairing >>>>> relationship of the forward and the backward directions of that >>>>> transport path. >>>>> >>>>>=20 >>>>> Please note that Requirement 34 is the ONLY item in the list that is >>=20 >>> specific >>>>> for co-routed bidirectional LSPs. (The pairing requirements at end >>> points >>>>> for co-routed and associated bidirectional paths are exactly the >>> same even >>>>> if they appear in two different items in the requirements' list). >>>>> In other words, without Requirement 34 the notion of co-routed >>> bidirectional >>>>> paths would be void of any data plane content. >>>>>=20 >>>>> The somewhat vague scope of this requirement ("other internal >> functions >>>>> as appropriate") creates a suspicion that HW support of the pairing >>> awareness >>>>> may be required in order to comply with it. >>>>>=20 >>>>> The following text in the draft increases this suspicion: >>>>>=20 >>>>> >>>>> Tandem Connection: A tandem connection is an arbitrary part of a >>>>> transport path that can be monitored (via OAM) independently from >> the >>>>> end-to-end monitoring (OAM). It may be a monitored segment or a >>>>> monitored concatenated segment of a transport path. The tandem >>>>> connection may also include the forwarding engine(s) of the node(s) >>>>> at the edge(s) of the segment or concatenated segment. >>>>> >>>>>=20 >>>>> Doesn't "forwarding engine" sound like hardware to you? >>>>>=20 >>>>> IMHO it is worth noting that neither the MPLS-TP Requirements draft >>>>> nor the MPLS-TP OAM requirements one >>>>>=20 >>> ( >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-0= 1.tx >=20 >>=20 >>>>> t) >>>>> contain any requirements dealing with tandem connections. >>>>>=20 >>>>> But tandem connections are discussed in the MPLS-TP OAM Framework >> draft >>>>>=20 >>> ( >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.t= xt >=20 >> ). >>>>>=20 >>>>> The bottom line, IMHO, is that some clarity regarding co-routed vs. >>> associated >>>>> bidirectional >>>>> paths is still required. One way to provide that could be by >> explicitly >>>>> limiting Requirement 34 >>>>> to specific functionality. >>>>>=20 >>>>> My 2c, >>>>> Sasha >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> From: Adrian Farrel [adrian@olddog.co.uk] >>>>> Sent: Thursday, April 16, 2009 12:13 AM >>>>> To: Alexander Vainshtein; Lou Berger; BUSI ITALO >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>> requirements >>>>>=20 >>>>> Hi Sasha, >>>>>=20 >>>>> Not really sure whether you are misrepresenting anyone, but... >>>>>=20 >>>>>> 1. My reading of one of Ben's messages is that associated >>>>>> bidirectional paths are the only types of paths that can be >>>>>> created in the existing networks; "true" co-routed bidirectional >>>>>> paths will have to wait until (if ever) new equipment becomes >>>>>> available. >>>>> This is clearly nonsense! >>>>> From the point of view of hardware, co-routed bidirectional LSPs are >> a >>>>> special case of associated bidirectional LSPs. >>>>>=20 >>>>> If you can set up two unidirectional LSPs (e.g. using the management >>=20 >>> plane) >>>>> you can surely set up a co-routed bidirectional LSP. >>>>>=20 >>>>> There are shipping solutions that achieve co-routed bidirectional >>> LSPs using >>>>> the control plane. These either use the GMPLS (which is cleaner) or >>>>> non-standard proprietary solutions (which is messy but functional). >>>>>=20 >>>>> But (of course) the management plane or control plane solutions have >>=20 >>> nothing >>>>> to do with availability of equipment as they are software solutions. >>>>>=20 >>>>>> 2. My reading of one of Neil's messages is that the actual driver >> for >>>>>> co-routed >>>>>> bidirectional paths may be experience with existing transport >> networks >>>>>> rather >>>>>> than any specific benefit. >>>>> Isn't that the case with 75% of the MPLS-TP requirements? >>>>> Which is not to say it is a bad thing. >>>>>=20 >>>>> A large driver for MPLS-TP is to give the packet network the look, >>> feel, and >>>>> behavioral characteristics of a "legacy" transport network. >>>>>=20 >>>>>> Based on these observations, I'd guess (FWIW) that: >>>>>> * associated bidirectional paths are, at least for the time >>>>>> being, the most important type of bidirectional paths in >>>>>> MPLS-TP >>>>> I think that is wrong both given my statement above, and given that >>> other >>>>> upgrades to existing MPLS solutions will be needed to reach the full >>>>> function level of MPLS-TP. >>>>>=20 >>>>>> * they had a good chance to remain the only type of bidirectional >>>>>> paths in real deployments. >>>>> I don't see what that follows from. >>>>>=20 >>>>> Cheers, >>>>> Adrian >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>=20 >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>=20 >>>=20 >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained in >> this mail is solely property of the sender's organization. This >> mail communication is confidential. Recipients named above are >> obligated to maintain secrecy and are not permitted to disclose >> the contents of this communication to others. >>> This email and any files transmitted with it are confidential >> and intended solely for the use of the individual or entity to >> whom they are addressed. If you have received this email in >> error please notify the originator of the message. Any views >> expressed in this message are those of the individual sender. >>> This message has been scanned for viruses and Spam by ZTE >> Anti-Spam system. >>=20 >>=20 >>=20 >>=20 >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail > is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy > and are >> not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and > intended >> solely for the use of the individual or entity to whom they are > addressed. If >> you have received this email in error please notify the originator of > the >> message. Any views expressed in this message are those of the individual >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d are > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. From benjamin.niven-jenkins@bt.com Mon Apr 20 01:37:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E973A6A4C for ; Mon, 20 Apr 2009 01:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYhIVSZrFHvy for ; Mon, 20 Apr 2009 01:37:44 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 61DB13A6925 for ; Mon, 20 Apr 2009 01:37:44 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 09:38:59 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Apr 2009 08:38:57 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 20 Apr 2009 09:38:55 +0100 From: Ben Niven-Jenkins To: Annamaria Fulignoli , Eric Gray , Lou Berger , BUSI ITALO Message-ID: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm91k8eN17VNhFVQzmDnE7yj0tc5wBsbrrQAICREFAAAkiTPA== In-Reply-To: <93DFCD4B101EB440B5B72997456C5F94039755DF@esealmw118.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Apr 2009 08:38:59.0397 (UTC) FILETIME=[7334E750:01C9C193] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:37:45 -0000 I refer my learned colleagues to the following paragraph in the MPLS-TP requirements The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS transport profile is constructed. The requirements are not implementation requirements. BTW we seem to go around this same loop every few weeks. Ben On 20/04/2009 08:37, "Annamaria Fulignoli" wrote: > Eric, > I couldn't agree more! >=20 > Annamaria=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > Eric Gray > Sent: venerd=EC 17 aprile 2009 20.15 > To: Lou Berger; BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 > Lou/Italo, >=20 > This gets into a fuzzy language area. >=20 > I think it should be clear that use of associated > (non-co-routed) > bi-directional paths is not required. It also seems to me to be clear th= at > they might be used; hence support for them is needed in protocols and oth= er > specifications. >=20 > We all need to be precise in what we mean by what is required, and where = it is > required. >=20 > -- > Eric >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > Lou Berger > Sent: Wednesday, April 15, 2009 10:27 AM > To: BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 > Italo, >=20 > On 4/14/2009 6:12 AM, BUSI ITALO wrote: >> 2) we need to be clear that asssociated bidirectional paths are not >> required in transport networks (e.g. MPLS-TP) >>=20 >=20 > This doesn't match draft-ietf-mpls-tp-requirements-06. Are you proposing > dropping associated bidirectional path from the TP requirements document? >=20 > Lou >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From liu.guoman@zte.com.cn Mon Apr 20 01:41:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC453A6925 for ; Mon, 20 Apr 2009 01:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.592 X-Spam-Level: X-Spam-Status: No, score=-97.592 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ409qmRjU4C for ; Mon, 20 Apr 2009 01:41:26 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 85BD23A68AE for ; Mon, 20 Apr 2009 01:41:25 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Mon, 20 Apr 2009 16:35:24 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 90033.1746388837; Mon, 20 Apr 2009 16:39:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3K8gjDw013678; Mon, 20 Apr 2009 16:42:45 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: Ben Niven-Jenkins MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 20 Apr 2009 16:40:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-20 16:42:36, Serialize complete at 2009-04-20 16:42:36 Content-Type: multipart/alternative; boundary="=_alternative 002FD7364825759E_=" X-MAIL: mse2.zte.com.cn n3K8gjDw013678 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:41:29 -0000 This is a multipart message in MIME format. --=_alternative 002FD7364825759E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QmVuOg0KIGlmIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBjYW4gc3VwcG9ydCBib3Ro IHN5bW1ldHJpYyBhbmQgDQphc3ltbWV0cmljIGJhbmR0aHdpZHRoIHRyYW5zcG9ydCBwYXRocywg SSB0aGluayBpdCBpcyB1bm5lY2Vzc2FyeSB0byBjbGFpbSANCnRoZSByZXF1aXJlbWVudCBpbiBt cGxzLXRwLiBiZWNhdXNlIHRoZXJlIGFyZSBvbmx5IHRoaXMgdHdvIGNvbmRpdGlvbnMgOiANCnN5 bW1ldHJpYyBhbmQgYXN5bW1ldHJpYy4gY2FuIHNvbWVvbmUgcHJpdmlkZSBhbm90aGVyIGNvbmRp dGlvbnMuDQoNCnJlZ2FyZHMNCmxpdQ0KDQoNCg0KQmVuIE5pdmVuLUplbmtpbnMgPGJlbmphbWlu Lm5pdmVuLWplbmtpbnNAYnQuY29tPiANCjIwMDktMDQtMjAgMTY6MzYNCg0KytW8/sjLDQo8bGl1 Lmd1b21hbkB6dGUuY29tLmNuPg0Ks63LzQ0KPG1wbHMtdHBAaWV0Zi5vcmc+DQrW98ziDQpSZTog W21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJl bWVudHMNCg0KDQoNCg0KDQoNCkxpdSwNCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSB5b3Ug YXJlIHNheWluZyBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIHBhdGhzIA0KY2FuDQpzdXBwb3J0 IGJvdGggc3ltbWV0cmljIGFuZCBhc3ltbWV0cmljIGJhbmR3aWR0aCB0cmFuc3BvcnQgcGF0aHMu DQoNClRoYXQgaXMgY29ycmVjdC4NCg0KQmVuDQoNCg0KDQpPbiAyMC8wNC8yMDA5IDA4OjI3LCAi bGl1Lmd1b21hbkB6dGUuY29tLmNuIiA8bGl1Lmd1b21hbkB6dGUuY29tLmNuPiANCndyb3RlOg0K DQo+IEJlbjoNCj4gIHlvdSBjYW4gd3JvbmdseSB1bmRlcnN0YW5kIG15IG1lYW5pbmcgLCBoZXJl IEkgd2FudCB0byBjbGFyaWZ5IGl0IGlzDQo+IHVubmVjZXNzYXJ5IGZvciBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgcGF0aCB0byBrZWVwIHN5bW1ldHJpYyANCmJhbmR3aWR0aA0KPiBpbiBib3Ro IGZvcndhcmQgYW5kIGJhY2t3YXJkIHBhdGguDQo+IG1heWJlIG15IGV4cHJlc3NpbmcgaXNuJ3Qg IGNsYXJpZnkgdG8gbWFrZSB5b3UgdG8gZGlmZnVsdGx5IHVuZGVyc3RhbmQgDQppdC4NCj4gaGVy ZSBJIHNheSBzb3JyeSB0byBhbGwNCj4gDQo+IHJlZ2FyZHMNCj4gbGl1IA0KPiANCj4gDQo+IA0K PiBCZW4gTml2ZW4tSmVua2lucyA8YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20+DQo+IDIw MDktMDQtMjAgMTQ6MDINCj4gDQo+IMrVvP7Iyw0KPiA8bGl1Lmd1b21hbkB6dGUuY29tLmNuPiwg TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCj4gs63LzQ0KPiA8bXBscy10cEBpZXRmLm9y Zz4NCj4g1vfM4g0KPiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gTGl1LA0K PiANCj4gDQo+IE9uIDIwLzA0LzIwMDkgMDI6MDAsICJsaXUuZ3VvbWFuQHp0ZS5jb20uY24iIDxs aXUuZ3VvbWFuQHp0ZS5jb20uY24+DQo+IHdyb3RlOg0KPiANCj4+IGxvdToNCj4+ICAgICBiZWNh dXNlIFRoZSBmb3J3YXJkIGFuZCBiYWNrd2FyZCBkaXJlY3Rpb25zIGFyZSBzZXR1cCwgbW9uaXRv cmVkIA0KYW5kDQo+PiBwcm90ZWN0ZWQgaW5kZXBlbmRlbnQgaW4gdGhlIGFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCBwYXRocy4gaXQgY2FuJ3QNCj4+IGVuc3VyZSBhbmQgcmVhbGl6ZSB0aGUgc3lt bWV0cmljIGJhbmR3aWR0aCBpbiB0d28gZGlyZWN0aW9uYWwgcGF0aC4NCj4+IG9yIGVsc2UgLCBJ IE1VU1QgcmV2aXNlIHRoZSBkZWZpbml0aW9ucyBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwN Cj4gcGF0aHMNCj4+IGluIG1wbHMtdHAgcmVxdWlyZW1lbnRzIGRyYWZ0Lg0KPiANCj4gWW91IGFy ZSBjbGFpbWluZyB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZSBmb3IgdGhlIGVuZCBwb2ludHMgb2Yg YW4NCj4gYXNzb2NpYXRlZA0KPiBiaWRpcmVjdGlvbmFsIHBhdGggdG8gZW5zdXJlIHRoYXQgYm90 aCBkaXJlY3Rpb25zIGhhdmUgdGhlIHNhbWUgDQpiYW5kd2lkdGgNCj4gYXR0cmlidXRlcy4gVGhp cyBpcyBjbGVhcmx5IElNTyBpbmNvcnJlY3QuDQo+IA0KPiBMZXQncyB0YWtlIGEgcmVhbCB3b3Js ZCBleGFtcGxlIHRvIGlsbHVzdHJhdGUgd2h5IGl0IGlzIGluY29ycmVjdC4gSWYgaXQNCj4gd2Vy ZSB0cnVlIHRoZW4gaXQgd291bGQgbm90IGJlIHBvc3NpYmxlIGZvciBleGFtcGxlIHRvIHN1cHBv cnQgRTEgUFdzIGluDQo+IE1QTFMgbmV0d29ya3MgdG9kYXkuIFN1Y2ggRTEgUFdzIGFyZSBzdWNj ZXNzZnVsbHkgYmVpbmcgdXNlZCBpbiBNUExTDQo+IG5ldHdvcmtzIHRvZGF5IHRvIHN1cHBvcnQg Y3VzdG9tZXIgc2VydmljZXMuDQo+IA0KPiBCZW4NCj4gDQo+IA0KPiANCj4+IA0KPj4gcmVnYXJk cw0KPj4gbGl1IA0KPj4gDQo+PiANCj4+IA0KPj4gTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5l dD4NCj4+IDIwMDktMDQtMTcgMjE6NTQNCj4+IA0KPj4gytW8/sjLDQo+PiBsaXUuZ3VvbWFuQHp0 ZS5jb20uY24NCj4+ILOty80NCj4+IEJlbiBOaXZlbi1KZW5raW5zIDxiZW5qYW1pbi5uaXZlbi1q ZW5raW5zQGJ0LmNvbT4sIG1wbHMtdHBAaWV0Zi5vcmcNCj4+INb3zOINCj4+IFJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0K Pj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gTGl1LA0KPj4gICAgICAgICAgICAgICAg ICBXaHkgaXNuJ3QgaXQgbmVjZXNzYXJ5IGZvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCj4+ IHBhdGhzPyAgSXMgaXQgdGhhdA0KPj4gYXN5bW1ldHJpYyBpcyB0aGUgc29sZSByZXF1aXJlbWVu dD8gIElmIG5vdCwgSSBkb24ndCB1bmRlcnN0YW5kIHlvdXINCj4+IGNvbW1lbnQuDQo+PiANCj4+ IExvdQ0KPj4gDQo+PiBPbiA0LzE2LzIwMDkgOToxNSBQTSwgbGl1Lmd1b21hbkB6dGUuY29tLmNu IHdyb3RlOg0KPj4+IA0KPj4+IExvdToNCj4+PiBJIGFncmVlIHlvdXIgYWR2aWNlLCBidXQgZm9y IHN5bW1ldHJpYyBiYW5kd2lkdGggcmVxdWlyZW1lbnQsIEkgdGhpbmsNCj4+PiB0aGUgcmVxdWly ZW1lbnQgY2FuIG9ubHkgYmUgZml0IGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQNCj4+PiBwYXRocywgd2hpbGUgaXQgaXNuJ3QgbmVjZXNzYXJ5IGZvciBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgcGF0aHMgLnNvDQo+Pj4gYWRkaW5nIGEgImNvLXJvdXRlZCIgd29yZCBpbiB0 aGUgcmVxdWlyZW1lbnQgMzMgaXMgbmVjZXNzYXJ5Lg0KPj4+IHRoYW5rIHlvdS4NCj4+PiBsaXUN Cj4+PiANCj4+PiANCj4+PiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+Pj4gt6K8 /sjLOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCj4+PiANCj4+PiAyMDA5LTA0LTE2IDIxOjQz DQo+Pj4gDQo+Pj4gDQo+Pj4gytW8/sjLDQo+Pj4gICAgICAgICAgICAgICAgQmVuIE5pdmVuLUpl bmtpbnMgPGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPg0KPj4+ILOty80NCj4+PiAgICAg ICAgICAgICAgICBCVVNJQGNvcmUzLmFtc2wuY29tLCAibXBscy10cEBpZXRmLm9yZyINCj4+IDxt cGxzLXRwQGlldGYub3JnPiwgSVRBTE8NCj4+PiA8SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5p dD4NCj4+PiDW98ziDQo+Pj4gICAgICAgICAgICAgICAgUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCj4+IHJlcXVpcmVtZW50cw0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IEJlbiwNCj4+PiBJdCBz ZWVtcyB0byBtZSB0aGF0IG11Y2ggb2YgdGhlIGRpc2N1c3Npb24gc3RlbXMgZnJvbSB0aGUgc2Vj dGlvbiBpbg0KPj4+IHdoaWNoIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgbGlzdGVkLg0KPj4+IA0K Pj4+IFJlcXVpcmVtZW50IDMyIGlzIGEgc2VydmljZSBsZXZlbCByZXF1aXJlbWVudCBhbmQgcHJp bWFyaWx5IGltcGFjdCB0aGUNCj4+PiBtYW5hZ2VtZW50IGFuZCBjb250cm9sIHBsYW5lcy4gQXMg dGhlcmUgaXMgbm8gc2VjdGlvbiBkZXNjcmliaW5nDQo+Pj4gc2VydmljZSByZXF1aXJlbWVudHMs IEkgc3VnZ2VzdCBtb3ZpbmcgdGhpcyByZXF1aXJlbWVudCB0byBmb2xsb3cNCj4+PiByZXF1aXJl bWVudCA2LCBhbmQgYWRkaW5nIHRoZSBmb2xsb3dpbmcgaW4gaXRzIHBsYWNlOg0KPj4+IDMzIE1Q TFMtVFAgTVVTVCBzdXBwb3J0IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGhzIHdpdGgNCj4+ PiBzeW1tZXRyaWMgYmFuZHdpZHRoIHJlcXVpcmVtZW50cywgaS5lLiB0aGUgYW1vdW50IG9mIHJl c2VydmVkDQo+Pj4gYmFuZHdpZHRoIGlzIHRoZSBzYW1lIGJldHdlZW4gdGhlIGZvcndhcmQgYW5k IGJhY2t3YXJkDQo+Pj4gZGlyZWN0aW9ucy4NCj4+PiANCj4+PiBXaGlsZSB0aGlzIHRvbyBpcyBh IHNlcnZpY2UgcmVxdWlyZW1lbnQgYW5kIGRvZXNuJ3QgcmVxdWlyZSBhbnkNCj4gaGFyZHdhcmUN Cj4+PiBtb2RpZmljYXRpb25zLCBpdCBwYXJhbGxlbHMgY3VycmVudCByZXF1aXJlbWVudHMgMzcs IDQwIGFuZCA0MS4gSXQgDQphbHNvDQo+Pj4gbWFrZXMgYSBjdXJyZW50bHkgaW1wbGljaXQgcmVx dWlyZW1lbnQgZXhwbGljaXQuDQo+Pj4gDQo+Pj4gUmVxdWlyZW1lbnRzIDMzLTI2IHJlbGF0ZSB0 byAiYXdhcmVuZXNzIiBzaG91bGQgaGF2ZSBubyBpbXBsaWNhdGlvbiBvbg0KPj4+IHRoZSBkYXRh L2ZvcndhcmRpbmcgcGxhbmUgYW5kIGFyZSBJTU8gYm90aCBtYW5hZ2VtZW50IGFuZCBjb250cm9s IA0KcGxhbmUNCj4+PiByZXF1aXJlbWVudHMuIChBbmQgeWVzLCB0aGV5IGhhdmUgaW1wbGljYXRp b25zIG9uIE9BTSBhbmQgcmVjb3ZlcnkuKSBJDQo+Pj4gdGhpbmsgQWRyaWFuIHJhaXNlcyBhIGdv b2QgcG9pbnQgV1JUIHRoZXNlIHJlcXVpcmVtZW50cywgaS5lLiwgYXJlDQo+IHRoZXNlDQo+Pj4g cmVxdWlyZW1lbnRzIGxpc3RlZCBhcyBzb2x1dGlvbnMgdG8gc29tZSB1bmxpc3RlZCByZXF1aXJl bWVudHMuIElmIHNvLA0KPj4+IHRoZSB1bmxpc3RlZCByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGlu Y2x1ZGVkIGFuZCB0aGVzZSBzaG91bGQgYmUNCj4+PiBkcm9wcGVkLiBJZiBub3QsIHNvIGJlIGl0 LCBidXQgdGhleSBzaG91bGQgYmUgbW92ZWQgZnJvbSBzZWN0aW9uIDIuMy4NCj4+PiANCj4+PiBX aGlsZSBJJ20gc3VyZSB0aGlzIHdvbid0IGVuZCB0aGUgZGlzY3Vzc2lvbiwgSSB0aGluayB0aGVz ZSBjaGFuZ2VzDQo+IHdpbGwNCj4+PiBoZWxwIG1ha2UgInRoZSByZXF1aXJlbWVudHMgY2xlYXIg ZW5vdWdoIC4uLiINCj4+PiANCj4+PiBMb3UNCj4+PiANCj4+PiBPbiA0LzE2LzIwMDkgNTo1OCBB TSwgQmVuIE5pdmVuLUplbmtpbnMgd3JvdGU6DQo+Pj4+IENvbGxlYWd1ZXMsDQo+Pj4+IA0KPj4+ PiBJIGNhbid0IGhlbHAgYnV0IGZlZWwgd2UgYXJlIG92ZXJhbmFseXNpbmcgdGhpbmdzIGhlcmUu IEhvdyBtYW55DQo+Pj4+IHRlY2hub2xvZ2llcy9wcm90b2NvbHMvbWVjaGFuaXNtcyBoYXZlIHdl IHN1Y2Nlc3NmdWxseSBkZWZpbmVkIGluDQo+Pj4gYm90aCBJRVRGDQo+Pj4+ICYgSVRVLVQgd2l0 aG91dCB0aGlzIGxldmVsIG9mIGFuYWx5c2lzIG9mIHRoZSBpbml0aWFsIHJlcXVpcmVtZW50cyAt DQo+Pj4gYSBncmVhdA0KPj4+PiBtYW55IChhIGdvb2QgY2h1bmsgb2Ygd2hpY2ggd2VyZSBleHRy ZW1lbHkgc3VjY2Vzc2Z1bCkuDQo+Pj4+IA0KPj4+PiBUaGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50 IGlzIG5vdCBhYm91dCBzcGVjaWZ5aW5nIHNvbHV0aW9ucy4NCj4+Pj4gDQo+Pj4+IFRoZSBrZXkg cXVlc3Rpb24gaXM6IGFyZSB0aGUgcmVxdWlyZW1lbnRzIGNsZWFyIGVub3VnaCB0aGF0IGl0IGlz DQo+Pj4gdW5kZXJzdG9vZA0KPj4+PiB3aGF0IGlzIHJlcXVpcmVkIHNvIHNvbWVvbmUgY291bGQg YnVpbGQgYSBib3gvcHJvdG9jb2wvd2hhdGV2ZXIgdG8NCj4+IG1lZXQNCj4+Pj4gdGhlbT8NCj4+ Pj4gDQo+Pj4+IElmIHdlIHdhbnQgdG8gZ28gaW50byB0aGUgbnRoIGxldmVsIG9mIGRldGFpbCBv biBlYWNoIHJlcXVpcmVtZW50IHdlDQo+PiB3aWxsDQo+Pj4+IHN0aWxsIGJlIGRlYmF0aW5nIHRo aXMgYnkgdGhlIHRpbWUgSSByZXRpcmUgKHdoaWNoIGlzbid0IGR1ZSB1bnRpbA0KPj4gMjA0NSku DQo+Pj4+IA0KPj4+PiBCZW4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPbiAxNi8wNC8yMDA5IDA4OjA0 LCAiQWxleGFuZGVyIFZhaW5zaHRlaW4iDQo+Pj4+IDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gQWRyaWFuLA0KPj4+Pj4gVGhhbmsgeW91IGZv ciBhIHByb21wdCBhbmQgZGV0YWlsZWQgcmVzcG9uc2UuDQo+Pj4+PiANCj4+Pj4+IFVuZm9ydHVu YXRlbHkgSSBjYW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudDoNCj4+Pj4+IA0K Pj4+Pj4gPHF1b3RlPg0KPj4+Pj4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwg Y28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcw0KPj4+Pj4gYXJlIGEgc3BlY2lhbCBjYXNlIG9m IGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KPj4+Pj4gPGVuZCBxdW90ZT4NCj4+Pj4+ IA0KPj4+Pj4gVGhpcyBzdGF0ZW1lbnQgd291bGQgYmUgb2J2aW91c2x5IGNvcnJlY3QsIHdlcmUg aXQgbm90IGZvcg0KPj4+IFJlcXVpcmVtZW50IDM0IGluDQo+Pj4+PiB0aGUgbGF0ZXN0DQo+Pj4+ PiBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdA0KPj4+Pj4gDQo+Pj4gKA0KPj4gDQo+IA0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXJlcXVp cmVtZW50cy0wNi50eHQNCj4+ICk6DQo+Pj4+PiANCj4+Pj4+IDxxdW90ZT4NCj4+Pj4+IFRoZSBp bnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZyBNRVBzLCBNSVBzIGFuZCBvdGhlciBpbnRlcm5h bA0KPj4+Pj4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydA0KPj4+Pj4gcGF0aCBhdCBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUg YXdhcmUgb2YgdGhlIHBhaXJpbmcNCj4+Pj4+IHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBh bmQgdGhlIGJhY2t3YXJkIGRpcmVjdGlvbnMgb2YgdGhhdA0KPj4+Pj4gdHJhbnNwb3J0IHBhdGgu DQo+Pj4+PiA8ZW5kIHF1b3RlPg0KPj4+Pj4gDQo+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVp cmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4gdGhlIGxpc3QgdGhhdCBpcw0KPj4gDQo+Pj4g c3BlY2lmaWMNCj4+Pj4+IGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhlIHBh aXJpbmcgcmVxdWlyZW1lbnRzIGF0IGVuZA0KPj4+IHBvaW50cw0KPj4+Pj4gZm9yIGNvLXJvdXRl ZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSBleGFjdGx5IHRoZQ0KPj4+ IHNhbWUgZXZlbg0KPj4+Pj4gaWYgdGhleSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudCBpdGVtcyBp biB0aGUgcmVxdWlyZW1lbnRzJyBsaXN0KS4NCj4+Pj4+IEluIG90aGVyIHdvcmRzLCB3aXRob3V0 IFJlcXVpcmVtZW50IDM0IHRoZSBub3Rpb24gb2YgY28tcm91dGVkDQo+Pj4gYmlkaXJlY3Rpb25h bA0KPj4+Pj4gcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50Lg0K Pj4+Pj4gDQo+Pj4+PiBUaGUgc29tZXdoYXQgdmFndWUgc2NvcGUgb2YgdGhpcyByZXF1aXJlbWVu dCAoIm90aGVyIGludGVybmFsDQo+PiBmdW5jdGlvbnMNCj4+Pj4+IGFzIGFwcHJvcHJpYXRlIikg Y3JlYXRlcyBhIHN1c3BpY2lvbiB0aGF0IEhXIHN1cHBvcnQgb2YgdGhlIHBhaXJpbmcNCj4+PiBh d2FyZW5lc3MNCj4+Pj4+IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBp dC4NCj4+Pj4+IA0KPj4+Pj4gVGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFmdCBpbmNyZWFz ZXMgdGhpcyBzdXNwaWNpb246DQo+Pj4+PiANCj4+Pj4+IDxxdW90ZT4NCj4+Pj4+IFRhbmRlbSBD b25uZWN0aW9uOiBBIHRhbmRlbSBjb25uZWN0aW9uIGlzIGFuIGFyYml0cmFyeSBwYXJ0IG9mIGEN Cj4+Pj4+IHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkgaW5k ZXBlbmRlbnRseSBmcm9tDQo+PiB0aGUNCj4+Pj4+IGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FN KS4gSXQgbWF5IGJlIGEgbW9uaXRvcmVkIHNlZ21lbnQgb3IgYQ0KPj4+Pj4gbW9uaXRvcmVkIGNv bmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguIFRoZSB0YW5kZW0NCj4+Pj4+ IGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0aGUgZm9yd2FyZGluZyBlbmdpbmUocykgb2Yg dGhlIG5vZGUocykNCj4+Pj4+IGF0IHRoZSBlZGdlKHMpIG9mIHRoZSBzZWdtZW50IG9yIGNvbmNh dGVuYXRlZCBzZWdtZW50Lg0KPj4+Pj4gPGVuZCBxdW90ZT4NCj4+Pj4+IA0KPj4+Pj4gRG9lc24n dCAiZm9yd2FyZGluZyBlbmdpbmUiIHNvdW5kIGxpa2UgaGFyZHdhcmUgdG8geW91Pw0KPj4+Pj4g DQo+Pj4+PiBJTUhPIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IG5laXRoZXIgdGhlIE1QTFMtVFAg UmVxdWlyZW1lbnRzIGRyYWZ0DQo+Pj4+PiBub3IgdGhlIE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50 cyBvbmUNCj4+Pj4+IA0KPj4+ICgNCj4+IA0KPiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVxdWlyZW1lbnRzLTAxLnR4DQoNCj4g DQo+PiANCj4+Pj4+IHQpDQo+Pj4+PiBjb250YWluIGFueSByZXF1aXJlbWVudHMgZGVhbGluZyB3 aXRoIHRhbmRlbSBjb25uZWN0aW9ucy4NCj4+Pj4+IA0KPj4+Pj4gQnV0IHRhbmRlbSBjb25uZWN0 aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBNUExTLVRQIE9BTSBGcmFtZXdvcmsNCj4+IGRyYWZ0 DQo+Pj4+PiANCj4+PiAoDQo+PiANCj4gDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWZyYW1ld29yay0wMC50eHQNCg0KPiANCj4+ICku DQo+Pj4+PiANCj4+Pj4+IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21lIGNsYXJp dHkgcmVnYXJkaW5nIGNvLXJvdXRlZCB2cy4NCj4+PiBhc3NvY2lhdGVkDQo+Pj4+PiBiaWRpcmVj dGlvbmFsDQo+Pj4+PiBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdheSB0byBwcm92aWRl IHRoYXQgY291bGQgYmUgYnkNCj4+IGV4cGxpY2l0bHkNCj4+Pj4+IGxpbWl0aW5nIFJlcXVpcmVt ZW50IDM0DQo+Pj4+PiB0byBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5Lg0KPj4+Pj4gDQo+Pj4+PiBN eSAyYywNCj4+Pj4+IFNhc2hhDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4g RnJvbTogQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a10NCj4+Pj4+IFNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTQ0KPj4+Pj4gVG86IEFsZXhhbmRlciBWYWlu c2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPDQo+Pj4+PiBDYzogbXBscy10cEBpZXRmLm9y Zw0KPj4+Pj4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg dHJhbnNwb3J0IHBhdGgNCj4+PiByZXF1aXJlbWVudHMNCj4+Pj4+IA0KPj4+Pj4gSGkgU2FzaGEs DQo+Pj4+PiANCj4+Pj4+IE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVz ZW50aW5nIGFueW9uZSwgYnV0Li4uDQo+Pj4+PiANCj4+Pj4+PiAxLiBNeSByZWFkaW5nIG9mIG9u ZSBvZiBCZW4ncyBtZXNzYWdlcyBpcyB0aGF0IGFzc29jaWF0ZWQNCj4+Pj4+PiBiaWRpcmVjdGlv bmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBvZiBwYXRocyB0aGF0IGNhbiBiZQ0KPj4+Pj4+ IGNyZWF0ZWQgaW4gdGhlIGV4aXN0aW5nIG5ldHdvcmtzOyAidHJ1ZSIgY28tcm91dGVkIGJpZGly ZWN0aW9uYWwNCj4+Pj4+PiBwYXRocyB3aWxsIGhhdmUgdG8gd2FpdCB1bnRpbCAoaWYgZXZlcikg bmV3IGVxdWlwbWVudCBiZWNvbWVzDQo+Pj4+Pj4gYXZhaWxhYmxlLg0KPj4+Pj4gVGhpcyBpcyBj bGVhcmx5IG5vbnNlbnNlIQ0KPj4+Pj4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2Fy ZSwgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcyBhcmUNCj4+IGENCj4+Pj4+IHNwZWNpYWwg Y2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4+Pj4+IA0KPj4+Pj4gSWYg eW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgKGUuZy4gdXNpbmcgdGhlIG1h bmFnZW1lbnQNCj4+IA0KPj4+IHBsYW5lKQ0KPj4+Pj4geW91IGNhbiBzdXJlbHkgc2V0IHVwIGEg Y28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPj4+Pj4gDQo+Pj4+PiBUaGVyZSBhcmUgc2hp cHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KPj4+ IExTUHMgdXNpbmcNCj4+Pj4+IHRoZSBjb250cm9sIHBsYW5lLiBUaGVzZSBlaXRoZXIgdXNlIHRo ZSBHTVBMUyAod2hpY2ggaXMgY2xlYW5lcikgb3INCj4+Pj4+IG5vbi1zdGFuZGFyZCBwcm9wcmll dGFyeSBzb2x1dGlvbnMgKHdoaWNoIGlzIG1lc3N5IGJ1dCBmdW5jdGlvbmFsKS4NCj4+Pj4+IA0K Pj4+Pj4gQnV0IChvZiBjb3Vyc2UpIHRoZSBtYW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wgcGxh bmUgc29sdXRpb25zIGhhdmUNCj4+IA0KPj4+IG5vdGhpbmcNCj4+Pj4+IHRvIGRvIHdpdGggYXZh aWxhYmlsaXR5IG9mIGVxdWlwbWVudCBhcyB0aGV5IGFyZSBzb2Z0d2FyZSBzb2x1dGlvbnMuDQo+ Pj4+PiANCj4+Pj4+PiAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMgaXMg dGhhdCB0aGUgYWN0dWFsIGRyaXZlcg0KPj4gZm9yDQo+Pj4+Pj4gY28tcm91dGVkDQo+Pj4+Pj4g YmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIHRyYW5z cG9ydA0KPj4gbmV0d29ya3MNCj4+Pj4+PiByYXRoZXINCj4+Pj4+PiB0aGFuIGFueSBzcGVjaWZp YyBiZW5lZml0Lg0KPj4+Pj4gSXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUgTVBM Uy1UUCByZXF1aXJlbWVudHM/DQo+Pj4+PiBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFk IHRoaW5nLg0KPj4+Pj4gDQo+Pj4+PiBBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBn aXZlIHRoZSBwYWNrZXQgbmV0d29yayB0aGUgbG9vaywNCj4+PiBmZWVsLCBhbmQNCj4+Pj4+IGJl aGF2aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgImxlZ2FjeSIgdHJhbnNwb3J0IG5ldHdvcmsu DQo+Pj4+PiANCj4+Pj4+PiBCYXNlZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVzcyAo RldJVykgdGhhdDoNCj4+Pj4+PiAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUs IGF0IGxlYXN0IGZvciB0aGUgdGltZQ0KPj4+Pj4+IGJlaW5nLCB0aGUgbW9zdCBpbXBvcnRhbnQg dHlwZSBvZiBiaWRpcmVjdGlvbmFsIHBhdGhzIGluDQo+Pj4+Pj4gTVBMUy1UUA0KPj4+Pj4gSSB0 aGluayB0aGF0IGlzIHdyb25nIGJvdGggZ2l2ZW4gbXkgc3RhdGVtZW50IGFib3ZlLCBhbmQgZ2l2 ZW4gdGhhdA0KPj4+IG90aGVyDQo+Pj4+PiB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0 aW9ucyB3aWxsIGJlIG5lZWRlZCB0byByZWFjaCB0aGUgZnVsbA0KPj4+Pj4gZnVuY3Rpb24gbGV2 ZWwgb2YgTVBMUy1UUC4NCj4+Pj4+IA0KPj4+Pj4+ICogdGhleSBoYWQgYSBnb29kIGNoYW5jZSB0 byByZW1haW4gdGhlIG9ubHkgdHlwZSBvZiBiaWRpcmVjdGlvbmFsDQo+Pj4+Pj4gcGF0aHMgaW4g cmVhbCBkZXBsb3ltZW50cy4NCj4+Pj4+IEkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBmb2xsb3dzIGZy b20uDQo+Pj4+PiANCj4+Pj4+IENoZWVycywNCj4+Pj4+IEFkcmlhbg0KPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG1wbHMtdHAgbWFp bGluZyBsaXN0DQo+Pj4+PiBtcGxzLXRwQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG1wbHMtdHAgbWFpbGluZyBs aXN0DQo+Pj4+IG1wbHMtdHBAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBtcGxzLXRwIG1haWxp bmcgbGlzdA0KPj4+IG1wbHMtdHBAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4+PiANCj4+PiANCj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IFpURSAgSW5mb3Jt YXRpb24gIFNlY3VyaXR5ICBOb3RpY2U6ICBUaGUgIGluZm9ybWF0aW9uICBjb250YWluZWQgIGlu DQo+PiB0aGlzICBtYWlsICBpcyAgc29sZWx5ICBwcm9wZXJ0eSAgb2YgIHRoZSAgc2VuZGVyJ3Mg IG9yZ2FuaXphdGlvbi4gVGhpcw0KPj4gbWFpbCAgY29tbXVuaWNhdGlvbiAgaXMgIGNvbmZpZGVu dGlhbC4gIFJlY2lwaWVudHMgIG5hbWVkICBhYm92ZSAgYXJlDQo+PiBvYmxpZ2F0ZWQgIHRvICBt YWludGFpbiAgc2VjcmVjeSAgYW5kICBhcmUgIG5vdCAgcGVybWl0dGVkICB0byBkaXNjbG9zZQ0K Pj4gdGhlICBjb250ZW50cyAgb2YgIHRoaXMgIGNvbW11bmljYXRpb24gIHRvICBvdGhlcnMuDQo+ Pj4gVGhpcyAgZW1haWwgIGFuZCAgYW55ICBmaWxlcyAgdHJhbnNtaXR0ZWQgIHdpdGggIGl0ICBh cmUgIGNvbmZpZGVudGlhbA0KPj4gYW5kICBpbnRlbmRlZCAgc29sZWx5ICBmb3IgIHRoZSAgdXNl ICBvZiAgdGhlICBpbmRpdmlkdWFsICBvciAgZW50aXR5IA0KdG8NCj4+IHdob20gIHRoZXkgIGFy ZSAgYWRkcmVzc2VkLiAgSWYgIHlvdSAgaGF2ZSAgcmVjZWl2ZWQgIHRoaXMgIGVtYWlsICBpbg0K Pj4gZXJyb3IgIHBsZWFzZSAgbm90aWZ5ICB0aGUgIG9yaWdpbmF0b3IgIG9mICB0aGUgIG1lc3Nh Z2UuICBBbnkgIHZpZXdzDQo+PiBleHByZXNzZWQgIGluICB0aGlzICBtZXNzYWdlICBhcmUgIHRo b3NlICBvZiAgdGhlICBpbmRpdmlkdWFsICBzZW5kZXIuDQo+Pj4gVGhpcyAgbWVzc2FnZSAgaGFz ICBiZWVuICBzY2FubmVkICBmb3IgIHZpcnVzZXMgIGFuZCAgU3BhbSAgYnkgIFpURQ0KPj4gQW50 aS1TcGFtICBzeXN0ZW0uDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bA0KPiBpcw0KPj4gc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIA0KaXMNCj4+IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCj4gYW5kIGFy ZQ0KPj4gbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NCj4+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kDQo+IGludGVuZGVkDQo+PiBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUN Cj4gYWRkcmVzc2VkLiBJZg0KPj4geW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQo+IHRoZQ0KPj4gbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2 aWR1YWwNCj4+IHNlbmRlci4NCj4+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2 aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCj4gc3lzdGVtLg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1wbHMtdHAgbWFpbGlu ZyBsaXN0DQo+PiBtcGxzLXRwQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCANCmlzDQo+IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcw0KPiBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZQ0K PiBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmlj YXRpb24gdG8gb3RoZXJzLg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVuZGVkDQo+IHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCmFkZHJl c3NlZC4gSWYNCj4geW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ug bm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIA0KdGhlDQo+IG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0KPiBzZW5k ZXIuDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2 aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 002FD7364825759E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlbjo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO2lmIGFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCBwYXRocw0KY2FuIHN1cHBvcnQgYm90aCBzeW1tZXRyaWMgYW5kIGFzeW1tZXRyaWMgYmFu ZHRod2lkdGggdHJhbnNwb3J0IHBhdGhzLA0KSSB0aGluayBpdCBpcyB1bm5lY2Vzc2FyeSB0byBj bGFpbSB0aGUgcmVxdWlyZW1lbnQgaW4gbXBscy10cC4gYmVjYXVzZQ0KdGhlcmUgYXJlIG9ubHkg dGhpcyB0d28gY29uZGl0aW9ucyA6IHN5bW1ldHJpYyBhbmQgYXN5bW1ldHJpYy4gY2FuIHNvbWVv bmUNCnByaXZpZGUgYW5vdGhlciBjb25kaXRpb25zLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+bGl1PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxiPkJlbiBOaXZlbi1KZW5raW5zICZsdDtiZW5qYW1pbi5uaXZlbi1q ZW5raW5zQGJ0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+MjAwOS0wNC0yMCAxNjozNjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbA0KdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD5MaXUsPGJyPg0KPGJyPg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3Rs eSB5b3UgYXJlIHNheWluZyBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIHBhdGhzDQpjYW48YnI+ DQpzdXBwb3J0IGJvdGggc3ltbWV0cmljIGFuZCBhc3ltbWV0cmljIGJhbmR3aWR0aCB0cmFuc3Bv cnQgcGF0aHMuPGJyPg0KPGJyPg0KVGhhdCBpcyBjb3JyZWN0Ljxicj4NCjxicj4NCkJlbjxicj4N Cjxicj4NCjxicj4NCjxicj4NCk9uIDIwLzA0LzIwMDkgMDg6MjcsICZxdW90O2xpdS5ndW9tYW5A enRlLmNvbS5jbiZxdW90OyAmbHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6PGJy Pg0KPGJyPg0KJmd0OyBCZW46PGJyPg0KJmd0OyAmbmJzcDt5b3UgY2FuIHdyb25nbHkgdW5kZXJz dGFuZCBteSBtZWFuaW5nICwgaGVyZSBJIHdhbnQgdG8gY2xhcmlmeQ0KaXQgaXM8YnI+DQomZ3Q7 IHVubmVjZXNzYXJ5IGZvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aCB0byBrZWVwIHN5 bW1ldHJpYyBiYW5kd2lkdGg8YnI+DQomZ3Q7IGluIGJvdGggZm9yd2FyZCBhbmQgYmFja3dhcmQg cGF0aC48YnI+DQomZ3Q7IG1heWJlIG15IGV4cHJlc3NpbmcgaXNuJ3QgJm5ic3A7Y2xhcmlmeSB0 byBtYWtlIHlvdSB0byBkaWZmdWx0bHkgdW5kZXJzdGFuZA0KaXQuPGJyPg0KJmd0OyBoZXJlIEkg c2F5IHNvcnJ5IHRvIGFsbDxicj4NCiZndDsgPGJyPg0KJmd0OyByZWdhcmRzPGJyPg0KJmd0OyBs aXUgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBCZW4gTml2ZW4t SmVua2lucyAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7PGJyPg0KJmd0OyAy MDA5LTA0LTIwIDE0OjAyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IMrVvP7Iyzxicj4NCiZndDsgJmx0 O2xpdS5ndW9tYW5AenRlLmNvbS5jbiZndDssIExvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5u ZXQmZ3Q7PGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyAmbHQ7bXBscy10cEBpZXRmLm9yZyZndDs8 YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTGl1 LDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDIwLzA0LzIwMDkgMDI6MDAsICZx dW90O2xpdS5ndW9tYW5AenRlLmNvbS5jbiZxdW90OyAmbHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNu Jmd0Ozxicj4NCiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBsb3U6PGJyPg0K Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBiZWNhdXNlIFRoZSBmb3J3YXJkIGFuZCBiYWNrd2FyZCBk aXJlY3Rpb25zIGFyZQ0Kc2V0dXAsIG1vbml0b3JlZCBhbmQ8YnI+DQomZ3Q7Jmd0OyBwcm90ZWN0 ZWQgaW5kZXBlbmRlbnQgaW4gdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocy4gaXQN CmNhbid0PGJyPg0KJmd0OyZndDsgZW5zdXJlIGFuZCByZWFsaXplIHRoZSBzeW1tZXRyaWMgYmFu ZHdpZHRoIGluIHR3byBkaXJlY3Rpb25hbA0KcGF0aC48YnI+DQomZ3Q7Jmd0OyBvciBlbHNlICwg SSBNVVNUIHJldmlzZSB0aGUgZGVmaW5pdGlvbnMgb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs PGJyPg0KJmd0OyBwYXRoczxicj4NCiZndDsmZ3Q7IGluIG1wbHMtdHAgcmVxdWlyZW1lbnRzIGRy YWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3UgYXJlIGNsYWltaW5nIHRoYXQgaXQgaXMgbm90 IHBvc3NpYmxlIGZvciB0aGUgZW5kIHBvaW50cyBvZiBhbjxicj4NCiZndDsgYXNzb2NpYXRlZDxi cj4NCiZndDsgYmlkaXJlY3Rpb25hbCBwYXRoIHRvIGVuc3VyZSB0aGF0IGJvdGggZGlyZWN0aW9u cyBoYXZlIHRoZSBzYW1lIGJhbmR3aWR0aDxicj4NCiZndDsgYXR0cmlidXRlcy4gVGhpcyBpcyBj bGVhcmx5IElNTyBpbmNvcnJlY3QuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExldCdzIHRha2UgYSBy ZWFsIHdvcmxkIGV4YW1wbGUgdG8gaWxsdXN0cmF0ZSB3aHkgaXQgaXMgaW5jb3JyZWN0Lg0KSWYg aXQ8YnI+DQomZ3Q7IHdlcmUgdHJ1ZSB0aGVuIGl0IHdvdWxkIG5vdCBiZSBwb3NzaWJsZSBmb3Ig ZXhhbXBsZSB0byBzdXBwb3J0IEUxDQpQV3MgaW48YnI+DQomZ3Q7IE1QTFMgbmV0d29ya3MgdG9k YXkuIFN1Y2ggRTEgUFdzIGFyZSBzdWNjZXNzZnVsbHkgYmVpbmcgdXNlZCBpbiBNUExTPGJyPg0K Jmd0OyBuZXR3b3JrcyB0b2RheSB0byBzdXBwb3J0IGN1c3RvbWVyIHNlcnZpY2VzLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBCZW48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyByZWdhcmRzPGJyPg0KJmd0OyZndDsgbGl1IDxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IExvdSBC ZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PGJyPg0KJmd0OyZndDsgMjAwOS0wNC0xNyAy MTo1NDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IMrVvP7Iyzxicj4NCiZndDsmZ3Q7IGxp dS5ndW9tYW5AenRlLmNvbS5jbjxicj4NCiZndDsmZ3Q7ILOty808YnI+DQomZ3Q7Jmd0OyBCZW4g Tml2ZW4tSmVua2lucyAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7LCBtcGxz LXRwQGlldGYub3JnPGJyPg0KJmd0OyZndDsg1vfM4jxicj4NCiZndDsmZ3Q7IFJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IExpdSw8YnI+DQom Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1doeQ0KaXNuJ3QgaXQgbmVjZXNzYXJ5IGZvciBhc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWw8YnI+DQomZ3Q7Jmd0OyBwYXRocz8gJm5ic3A7SXMgaXQgdGhhdDxicj4NCiZndDsm Z3Q7IGFzeW1tZXRyaWMgaXMgdGhlIHNvbGUgcmVxdWlyZW1lbnQ/ICZuYnNwO0lmIG5vdCwgSSBk b24ndCB1bmRlcnN0YW5kDQp5b3VyPGJyPg0KJmd0OyZndDsgY29tbWVudC48YnI+DQomZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyBMb3U8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiA0LzE2 LzIwMDkgOToxNSBQTSwgbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOjxicj4NCiZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgTG91Ojxicj4NCiZndDsmZ3Q7Jmd0OyBJIGFncmVlIHlv dXIgYWR2aWNlLCBidXQgZm9yIHN5bW1ldHJpYyBiYW5kd2lkdGggcmVxdWlyZW1lbnQsDQpJIHRo aW5rPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSByZXF1aXJlbWVudCBjYW4gb25seSBiZSBmaXQgZm9y IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsDQp0cmFuc3BvcnQ8YnI+DQomZ3Q7Jmd0OyZndDsgcGF0 aHMsIHdoaWxlIGl0IGlzbid0IG5lY2Vzc2FyeSBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs DQpwYXRocyAuc288YnI+DQomZ3Q7Jmd0OyZndDsgYWRkaW5nIGEgJnF1b3Q7Y28tcm91dGVkJnF1 b3Q7IHdvcmQgaW4gdGhlIHJlcXVpcmVtZW50IDMzDQppcyBuZWNlc3NhcnkuPGJyPg0KJmd0OyZn dDsmZ3Q7IHRoYW5rIHlvdS48YnI+DQomZ3Q7Jmd0OyZndDsgbGl1PGJyPg0KJmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgKkxvdSBCZXJnZXIgJmx0O2xi ZXJnZXJAbGFibi5uZXQmZ3Q7Kjxicj4NCiZndDsmZ3Q7Jmd0OyC3orz+yMs6IG1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZzxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgMjAwOS0w NC0xNiAyMTo0Mzxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7IMrVvP7Iyzxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QmVuDQpOaXZlbi1KZW5raW5zICZsdDti ZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbSZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgs63LzTxi cj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7QlVTSUBjb3JlMy5hbXNsLmNvbSwNCiZxdW90O21wbHMtdHBAaWV0Zi5v cmcmcXVvdDs8YnI+DQomZ3Q7Jmd0OyAmbHQ7bXBscy10cEBpZXRmLm9yZyZndDssIElUQUxPPGJy Pg0KJmd0OyZndDsmZ3Q7ICZsdDtJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyDW98ziPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZToNClttcGxzLXRwXSBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGg8YnI+DQomZ3Q7Jmd0OyByZXF1aXJlbWVu dHM8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyBCZW4sPGJyPg0KJmd0OyZndDsmZ3Q7IEl0IHNlZW1zIHRvIG1lIHRoYXQgbXVjaCBvZiB0aGUg ZGlzY3Vzc2lvbiBzdGVtcyBmcm9tIHRoZQ0Kc2VjdGlvbiBpbjxicj4NCiZndDsmZ3Q7Jmd0OyB3 aGljaCB0aGVzZSByZXF1aXJlbWVudHMgYXJlIGxpc3RlZC48YnI+DQomZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7IFJlcXVpcmVtZW50IDMyIGlzIGEgc2VydmljZSBsZXZlbCByZXF1aXJl bWVudCBhbmQgcHJpbWFyaWx5DQppbXBhY3QgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7IG1hbmFnZW1l bnQgYW5kIGNvbnRyb2wgcGxhbmVzLiBBcyB0aGVyZSBpcyBubyBzZWN0aW9uIGRlc2NyaWJpbmc8 YnI+DQomZ3Q7Jmd0OyZndDsgc2VydmljZSByZXF1aXJlbWVudHMsIEkgc3VnZ2VzdCBtb3Zpbmcg dGhpcyByZXF1aXJlbWVudCB0bw0KZm9sbG93PGJyPg0KJmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50 IDYsIGFuZCBhZGRpbmcgdGhlIGZvbGxvd2luZyBpbiBpdHMgcGxhY2U6PGJyPg0KJmd0OyZndDsm Z3Q7IDMzIE1QTFMtVFAgTVVTVCBzdXBwb3J0IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGhz IHdpdGg8YnI+DQomZ3Q7Jmd0OyZndDsgc3ltbWV0cmljIGJhbmR3aWR0aCByZXF1aXJlbWVudHMs IGkuZS4gdGhlIGFtb3VudCBvZiByZXNlcnZlZDxicj4NCiZndDsmZ3Q7Jmd0OyBiYW5kd2lkdGgg aXMgdGhlIHNhbWUgYmV0d2VlbiB0aGUgZm9yd2FyZCBhbmQgYmFja3dhcmQ8YnI+DQomZ3Q7Jmd0 OyZndDsgZGlyZWN0aW9ucy48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFdo aWxlIHRoaXMgdG9vIGlzIGEgc2VydmljZSByZXF1aXJlbWVudCBhbmQgZG9lc24ndCByZXF1aXJl DQphbnk8YnI+DQomZ3Q7IGhhcmR3YXJlPGJyPg0KJmd0OyZndDsmZ3Q7IG1vZGlmaWNhdGlvbnMs IGl0IHBhcmFsbGVscyBjdXJyZW50IHJlcXVpcmVtZW50cyAzNywgNDAgYW5kDQo0MS4gSXQgYWxz bzxicj4NCiZndDsmZ3Q7Jmd0OyBtYWtlcyBhIGN1cnJlbnRseSBpbXBsaWNpdCByZXF1aXJlbWVu dCBleHBsaWNpdC48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFJlcXVpcmVt ZW50cyAzMy0yNiByZWxhdGUgdG8gJnF1b3Q7YXdhcmVuZXNzJnF1b3Q7IHNob3VsZA0KaGF2ZSBu byBpbXBsaWNhdGlvbiBvbjxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgZGF0YS9mb3J3YXJkaW5nIHBs YW5lIGFuZCBhcmUgSU1PIGJvdGggbWFuYWdlbWVudCBhbmQNCmNvbnRyb2wgcGxhbmU8YnI+DQom Z3Q7Jmd0OyZndDsgcmVxdWlyZW1lbnRzLiAoQW5kIHllcywgdGhleSBoYXZlIGltcGxpY2F0aW9u cyBvbiBPQU0gYW5kDQpyZWNvdmVyeS4pIEk8YnI+DQomZ3Q7Jmd0OyZndDsgdGhpbmsgQWRyaWFu IHJhaXNlcyBhIGdvb2QgcG9pbnQgV1JUIHRoZXNlIHJlcXVpcmVtZW50cywgaS5lLiwNCmFyZTxi cj4NCiZndDsgdGhlc2U8YnI+DQomZ3Q7Jmd0OyZndDsgcmVxdWlyZW1lbnRzIGxpc3RlZCBhcyBz b2x1dGlvbnMgdG8gc29tZSB1bmxpc3RlZCByZXF1aXJlbWVudHMuDQpJZiBzbyw8YnI+DQomZ3Q7 Jmd0OyZndDsgdGhlIHVubGlzdGVkIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgaW5jbHVkZWQgYW5k IHRoZXNlIHNob3VsZA0KYmU8YnI+DQomZ3Q7Jmd0OyZndDsgZHJvcHBlZC4gSWYgbm90LCBzbyBi ZSBpdCwgYnV0IHRoZXkgc2hvdWxkIGJlIG1vdmVkIGZyb20gc2VjdGlvbg0KMi4zLjxicj4NCiZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgV2hpbGUgSSdtIHN1cmUgdGhpcyB3b24ndCBl bmQgdGhlIGRpc2N1c3Npb24sIEkgdGhpbmsgdGhlc2UNCmNoYW5nZXM8YnI+DQomZ3Q7IHdpbGw8 YnI+DQomZ3Q7Jmd0OyZndDsgaGVscCBtYWtlICZxdW90O3RoZSByZXF1aXJlbWVudHMgY2xlYXIg ZW5vdWdoIC4uLiZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgTG91 PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBPbiA0LzE2LzIwMDkgNTo1OCBB TSwgQmVuIE5pdmVuLUplbmtpbnMgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDb2xsZWFn dWVzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGNhbid0 IGhlbHAgYnV0IGZlZWwgd2UgYXJlIG92ZXJhbmFseXNpbmcgdGhpbmdzIGhlcmUuDQpIb3cgbWFu eTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGVjaG5vbG9naWVzL3Byb3RvY29scy9tZWNoYW5pc21z IGhhdmUgd2Ugc3VjY2Vzc2Z1bGx5DQpkZWZpbmVkIGluPGJyPg0KJmd0OyZndDsmZ3Q7IGJvdGgg SUVURjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmFtcDsgSVRVLVQgd2l0aG91dCB0aGlzIGxldmVs IG9mIGFuYWx5c2lzIG9mIHRoZSBpbml0aWFsDQpyZXF1aXJlbWVudHMgLTxicj4NCiZndDsmZ3Q7 Jmd0OyBhIGdyZWF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBtYW55IChhIGdvb2QgY2h1bmsgb2Yg d2hpY2ggd2VyZSBleHRyZW1lbHkgc3VjY2Vzc2Z1bCkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgaXMgbm90IGFi b3V0IHNwZWNpZnlpbmcgc29sdXRpb25zLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBUaGUga2V5IHF1ZXN0aW9uIGlzOiBhcmUgdGhlIHJlcXVpcmVtZW50cyBj bGVhciBlbm91Z2gNCnRoYXQgaXQgaXM8YnI+DQomZ3Q7Jmd0OyZndDsgdW5kZXJzdG9vZDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgd2hhdCBpcyByZXF1aXJlZCBzbyBzb21lb25lIGNvdWxkIGJ1aWxk IGEgYm94L3Byb3RvY29sL3doYXRldmVyDQp0bzxicj4NCiZndDsmZ3Q7IG1lZXQ8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZW0/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IElmIHdlIHdhbnQgdG8gZ28gaW50byB0aGUgbnRoIGxldmVsIG9mIGRldGFpbCBvbiBl YWNoDQpyZXF1aXJlbWVudCB3ZTxicj4NCiZndDsmZ3Q7IHdpbGw8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IHN0aWxsIGJlIGRlYmF0aW5nIHRoaXMgYnkgdGhlIHRpbWUgSSByZXRpcmUgKHdoaWNoIGlz bid0DQpkdWUgdW50aWw8YnI+DQomZ3Q7Jmd0OyAyMDQ1KS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQmVuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT24gMTYvMDQvMjAwOSAwODow NCwgJnF1b3Q7QWxleGFuZGVyIFZhaW5zaHRlaW4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 ICZsdDtBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBZHJpYW4sPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmsgeW91IGZvciBhIHByb21wdCBhbmQgZGV0YWlsZWQgcmVz cG9uc2UuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50 Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZs dDtxdW90ZSZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIHRoZSBwb2ludCBvZiB2 aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KTFNQczxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGFyZSBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgTFNQcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMg c3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0DQpub3QgZm9yPGJy Pg0KJmd0OyZndDsmZ3Q7IFJlcXVpcmVtZW50IDM0IGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhlIGxhdGVzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1QTFMtVFAgcmVxdWlyZW1l bnRzIGRyYWZ0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7ICg8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtbXBscy10cC1yZXF1aXJlbWVudHMtMDYudHh0PGJyPg0KJmd0OyZndDsg KTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm bHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGludGVybWVkaWF0ZSBu b2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5kIG90aGVyDQppbnRlcm5hbDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbA0KdHJhbnNwb3J0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aCBh dCBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmc8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNr d2FyZCBkaXJlY3Rpb25zDQpvZiB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNw b3J0IHBhdGguPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O2VuZCBxdW90ZSZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2Ug bm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4NCnRoZSBsaXN0IHRo YXQgaXM8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgc3BlY2lmaWM8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBw YWlyaW5nIHJlcXVpcmVtZW50cw0KYXQgZW5kPGJyPg0KJmd0OyZndDsmZ3Q7IHBvaW50czxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvciBjby1yb3V0ZWQgYW5kIGFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCBwYXRocyBhcmUNCmV4YWN0bHkgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7IHNhbWUgZXZl bjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlmIHRoZXkgYXBwZWFyIGluIHR3byBkaWZmZXJl bnQgaXRlbXMgaW4gdGhlIHJlcXVpcmVtZW50cycNCmxpc3QpLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEluIG90aGVyIHdvcmRzLCB3aXRob3V0IFJlcXVpcmVtZW50IDM0IHRoZSBub3Rpb24N Cm9mIGNvLXJvdXRlZDxicj4NCiZndDsmZ3Q7Jmd0OyBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250 ZW50Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoZSBzb21ld2hhdCB2YWd1ZSBzY29wZSBvZiB0aGlzIHJlcXVpcmVtZW50ICgmcXVvdDtvdGhl cg0KaW50ZXJuYWw8YnI+DQomZ3Q7Jmd0OyBmdW5jdGlvbnM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhcyBhcHByb3ByaWF0ZSZxdW90OykgY3JlYXRlcyBhIHN1c3BpY2lvbiB0aGF0IEhXDQpz dXBwb3J0IG9mIHRoZSBwYWlyaW5nPGJyPg0KJmd0OyZndDsmZ3Q7IGF3YXJlbmVzczxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0 aCBpdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBUaGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzIHN1c3BpY2lv bjo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm bHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGFuZGVtIENvbm5lY3Rpb246 IEEgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW4gYXJiaXRyYXJ5DQpwYXJ0IG9mIGE8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZp YSBPQU0pIGluZGVwZW5kZW50bHkNCmZyb208YnI+DQomZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBlbmQtdG8tZW5kIG1vbml0b3JpbmcgKE9BTSkuIEl0IG1heSBiZSBhIG1v bml0b3JlZA0Kc2VnbWVudCBvciBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbW9uaXRvcmVk IGNvbmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguDQpUaGUgdGFuZGVtPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBm b3J3YXJkaW5nIGVuZ2luZShzKQ0Kb2YgdGhlIG5vZGUocyk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBvciBjb25jYXRlbmF0ZWQgc2VnbWVu dC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERvZXNuJ3QgJnF1b3Q7 Zm9yd2FyZGluZyBlbmdpbmUmcXVvdDsgc291bmQgbGlrZSBoYXJkd2FyZQ0KdG8geW91Pzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElNSE8gaXQg aXMgd29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUCBSZXF1aXJlbWVudHMNCmRy YWZ0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJl bWVudHMgb25lPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7ICg8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVxdWlyZW1lbnRzLTAxLnR4PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0KTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGggdGFuZGVt IGNvbm5lY3Rpb25zLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEJ1dCB0YW5kZW0gY29ubmVjdGlvbnMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgTVBM Uy1UUA0KT0FNIEZyYW1ld29yazxicj4NCiZndDsmZ3Q7IGRyYWZ0PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7ICg8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0t ZnJhbWV3b3JrLTAwLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgKS48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgYm90dG9tIGxpbmUs IElNSE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZw0KY28tcm91dGVkIHZzLjxicj4N CiZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmlkaXJl Y3Rpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhdGhzIGlzIHN0aWxsIHJlcXVpcmVk LiBPbmUgd2F5IHRvIHByb3ZpZGUgdGhhdCBjb3VsZA0KYmUgYnk8YnI+DQomZ3Q7Jmd0OyBleHBs aWNpdGx5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGltaXRpbmcgUmVxdWlyZW1lbnQgMzQ8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5Ljxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE15IDJjLDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNhc2hhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IEFkcmlhbiBGYXJyZWwgW2Fkcmlh bkBvbGRkb2cuY28udWtdPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXks IEFwcmlsIDE2LCAyMDA5IDEyOjEzIEFNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQNCnBhdGg8YnI+DQomZ3Q7Jmd0OyZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgU2FzaGEsPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm90IHJlYWxseSBzdXJl IHdoZXRoZXIgeW91IGFyZSBtaXNyZXByZXNlbnRpbmcgYW55b25lLA0KYnV0Li4uPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEuIE15IHJl YWRpbmcgb2Ygb25lIG9mIEJlbidzIG1lc3NhZ2VzIGlzIHRoYXQNCmFzc29jaWF0ZWQ8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgdGhlIG9ubHkg dHlwZXMgb2YgcGF0aHMNCnRoYXQgY2FuIGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGNyZWF0ZWQgaW4gdGhlIGV4aXN0aW5nIG5ldHdvcmtzOyAmcXVvdDt0cnVlJnF1b3Q7DQpjby1y b3V0ZWQgYmlkaXJlY3Rpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRocyB3 aWxsIGhhdmUgdG8gd2FpdCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVudA0KYmVjb21lczxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdmFpbGFibGUuPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlITxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsDQpMU1BzIGFyZTxicj4NCiZndDsmZ3Q7IGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgeW91IGNhbiBz ZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgKGUuZy4gdXNpbmcNCnRoZSBtYW5hZ2VtZW50 PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IHBsYW5lKTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFs IExTUC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBUaGVyZSBhcmUgc2hpcHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0ZWQNCmJp ZGlyZWN0aW9uYWw8YnI+DQomZ3Q7Jmd0OyZndDsgTFNQcyB1c2luZzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRoZSBjb250cm9sIHBsYW5lLiBUaGVzZSBlaXRoZXIgdXNlIHRoZSBHTVBMUyAo d2hpY2gNCmlzIGNsZWFuZXIpIG9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9uLXN0YW5k YXJkIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMgbWVzc3kNCmJ1dCBmdW5jdGlvbmFs KS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBC dXQgKG9mIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29udHJvbCBwbGFuZQ0Kc29s dXRpb25zIGhhdmU8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgbm90aGluZzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGRvIHdpdGggYXZhaWxhYmlsaXR5IG9mIGVxdWlwbWVu dCBhcyB0aGV5IGFyZSBzb2Z0d2FyZQ0Kc29sdXRpb25zLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyLiBNeSByZWFkaW5nIG9mIG9uZSBv ZiBOZWlsJ3MgbWVzc2FnZXMgaXMgdGhhdA0KdGhlIGFjdHVhbCBkcml2ZXI8YnI+DQomZ3Q7Jmd0 OyBmb3I8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY28tcm91dGVkPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgbWF5IGJlIGV4cGVyaWVuY2Ug d2l0aCBleGlzdGluZw0KdHJhbnNwb3J0PGJyPg0KJmd0OyZndDsgbmV0d29ya3M8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmF0aGVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRoYW4gYW55IHNwZWNpZmljIGJlbmVmaXQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXNu J3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUgTVBMUy1UUCByZXF1aXJlbWVudHM/PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2hpY2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCB0 aGluZy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNrZXQgbmV0d29y aw0KdGhlIGxvb2ssPGJyPg0KJmd0OyZndDsmZ3Q7IGZlZWwsIGFuZDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGJlaGF2aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgJnF1b3Q7bGVnYWN5JnF1 b3Q7DQp0cmFuc3BvcnQgbmV0d29yay48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2Qg Z3Vlc3MgKEZXSVcpDQp0aGF0Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqIGFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0DQpmb3IgdGhlIHRpbWU8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBl IG9mIGJpZGlyZWN0aW9uYWwNCnBhdGhzIGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE1QTFMtVFA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgaXMgd3Jvbmcg Ym90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsDQphbmQgZ2l2ZW4gdGhhdDxicj4NCiZndDsm Z3Q7Jmd0OyBvdGhlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVwZ3JhZGVzIHRvIGV4aXN0 aW5nIE1QTFMgc29sdXRpb25zIHdpbGwgYmUgbmVlZGVkDQp0byByZWFjaCB0aGUgZnVsbDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9uIGxldmVsIG9mIE1QTFMtVFAuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICogdGhleSBo YWQgYSBnb29kIGNoYW5jZSB0byByZW1haW4gdGhlIG9ubHkgdHlwZQ0Kb2YgYmlkaXJlY3Rpb25h bDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRocyBpbiByZWFsIGRlcGxveW1lbnRz Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBmb2xsb3dz IGZyb20uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFkcmlhbjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBtcGxz LXRwIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgbXBscy10cEBpZXRmLm9yZzxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzLXRwPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IG1wbHMtdHAg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7 Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJy Pg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQomZ3Q7Jmd0OyZndDsgWlRFICZuYnNwO0luZm9ybWF0aW9uICZuYnNwO1NlY3VyaXR5ICZuYnNw O05vdGljZTogJm5ic3A7VGhlDQombmJzcDtpbmZvcm1hdGlvbiAmbmJzcDtjb250YWluZWQgJm5i c3A7aW48YnI+DQomZ3Q7Jmd0OyB0aGlzICZuYnNwO21haWwgJm5ic3A7aXMgJm5ic3A7c29sZWx5 ICZuYnNwO3Byb3BlcnR5ICZuYnNwO29mDQombmJzcDt0aGUgJm5ic3A7c2VuZGVyJ3MgJm5ic3A7 b3JnYW5pemF0aW9uLiAmbmJzcDtUaGlzPGJyPg0KJmd0OyZndDsgbWFpbCAmbmJzcDtjb21tdW5p Y2F0aW9uICZuYnNwO2lzICZuYnNwO2NvbmZpZGVudGlhbC4gJm5ic3A7UmVjaXBpZW50cw0KJm5i c3A7bmFtZWQgJm5ic3A7YWJvdmUgJm5ic3A7YXJlPGJyPg0KJmd0OyZndDsgb2JsaWdhdGVkICZu YnNwO3RvICZuYnNwO21haW50YWluICZuYnNwO3NlY3JlY3kgJm5ic3A7YW5kICZuYnNwO2FyZQ0K Jm5ic3A7bm90ICZuYnNwO3Blcm1pdHRlZCAmbmJzcDt0byAmbmJzcDtkaXNjbG9zZTxicj4NCiZn dDsmZ3Q7IHRoZSAmbmJzcDtjb250ZW50cyAmbmJzcDtvZiAmbmJzcDt0aGlzICZuYnNwO2NvbW11 bmljYXRpb24gJm5ic3A7dG8NCiZuYnNwO290aGVycy48YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyAm bmJzcDtlbWFpbCAmbmJzcDthbmQgJm5ic3A7YW55ICZuYnNwO2ZpbGVzICZuYnNwO3RyYW5zbWl0 dGVkDQombmJzcDt3aXRoICZuYnNwO2l0ICZuYnNwO2FyZSAmbmJzcDtjb25maWRlbnRpYWw8YnI+ DQomZ3Q7Jmd0OyBhbmQgJm5ic3A7aW50ZW5kZWQgJm5ic3A7c29sZWx5ICZuYnNwO2ZvciAmbmJz cDt0aGUgJm5ic3A7dXNlDQombmJzcDtvZiAmbmJzcDt0aGUgJm5ic3A7aW5kaXZpZHVhbCAmbmJz cDtvciAmbmJzcDtlbnRpdHkgdG88YnI+DQomZ3Q7Jmd0OyB3aG9tICZuYnNwO3RoZXkgJm5ic3A7 YXJlICZuYnNwO2FkZHJlc3NlZC4gJm5ic3A7SWYgJm5ic3A7eW91DQombmJzcDtoYXZlICZuYnNw O3JlY2VpdmVkICZuYnNwO3RoaXMgJm5ic3A7ZW1haWwgJm5ic3A7aW48YnI+DQomZ3Q7Jmd0OyBl cnJvciAmbmJzcDtwbGVhc2UgJm5ic3A7bm90aWZ5ICZuYnNwO3RoZSAmbmJzcDtvcmlnaW5hdG9y ICZuYnNwO29mDQombmJzcDt0aGUgJm5ic3A7bWVzc2FnZS4gJm5ic3A7QW55ICZuYnNwO3ZpZXdz PGJyPg0KJmd0OyZndDsgZXhwcmVzc2VkICZuYnNwO2luICZuYnNwO3RoaXMgJm5ic3A7bWVzc2Fn ZSAmbmJzcDthcmUgJm5ic3A7dGhvc2UNCiZuYnNwO29mICZuYnNwO3RoZSAmbmJzcDtpbmRpdmlk dWFsICZuYnNwO3NlbmRlci48YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyAmbmJzcDttZXNzYWdlICZu YnNwO2hhcyAmbmJzcDtiZWVuICZuYnNwO3NjYW5uZWQgJm5ic3A7Zm9yDQombmJzcDt2aXJ1c2Vz ICZuYnNwO2FuZCAmbmJzcDtTcGFtICZuYnNwO2J5ICZuYnNwO1pURTxicj4NCiZndDsmZ3Q7IEFu dGktU3BhbSAmbmJzcDtzeXN0ZW0uPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyBaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu DQp0aGlzIG1haWw8YnI+DQomZ3Q7IGlzPGJyPg0KJmd0OyZndDsgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppczxi cj4NCiZndDsmZ3Q7IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js aWdhdGVkIHRvIG1haW50YWluDQpzZWNyZWN5PGJyPg0KJmd0OyBhbmQgYXJlPGJyPg0KJmd0OyZn dDsgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KJmd0OyZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVz IHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbA0KYW5kPGJyPg0KJmd0OyBpbnRl bmRlZDxicj4NCiZndDsmZ3Q7IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZTxicj4NCiZndDsgYWRkcmVzc2VkLiBJZjxicj4NCiZn dDsmZ3Q7IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvcg0Kb2Y8YnI+DQomZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7IG1lc3NhZ2Uu IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUNCmlu ZGl2aWR1YWw8YnI+DQomZ3Q7Jmd0OyBzZW5kZXIuPGJyPg0KJmd0OyZndDsgVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbTxi cj4NCiZndDsgc3lzdGVtLjxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyZndDsgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcw0KbWFpbCBpczxicj4NCiZndDsgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppczxicj4NCiZndDsgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4g c2VjcmVjeQ0KYW5kIGFyZTxicj4NCiZndDsgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy48YnI+DQomZ3Q7IFRoaXMg ZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kDQppbnRlbmRlZDxicj4NCiZndDsgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmPGJyPg0KJmd0OyB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3INCm9mIHRoZTxicj4NCiZndDsgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsPGJyPg0KJmd0OyBzZW5k ZXIuPGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtDQpzeXN0ZW0uPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 002FD7364825759E_=-- From Rolf.Winter@nw.neclab.eu Mon Apr 20 01:50:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CD33A692D for ; Mon, 20 Apr 2009 01:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiUxe66Gb9RW for ; Mon, 20 Apr 2009 01:50:18 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C4AB93A6D12 for ; Mon, 20 Apr 2009 01:50:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C4B022C01C8ED; Mon, 20 Apr 2009 10:51:32 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV9nf05BrcFz; Mon, 20 Apr 2009 10:51:32 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 935132C01C95B; Mon, 20 Apr 2009 10:51:17 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 10:51:08 +0200 Message-ID: <547F018265F92642B577B986577D671C7FE9C0@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnBlBAFC9wdCqwyToeqzvzspTLUzQAAJVVQ References: From: "Rolf Winter" To: , "Ben Niven-Jenkins" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:50:20 -0000 Liu, That would still make it a requirement. There is no harm in spelling it = out. Vice versa, expressing something clearly makes a good requirement. = Since this has been debated for quite a bit we will not have this = discussion again in a few weeks time if we simply express this = explicitly in the requirements. Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of liu.guoman@zte.com.cn > Sent: Montag, 20. April 2009 10:40 > To: Ben Niven-Jenkins > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements >=20 >=20 > Ben: > if associated bidirectional paths can support both symmetric and > asymmetric bandthwidth transport paths, I think it is unnecessary to > claim the requirement in mpls-tp. because there are only this two > conditions : symmetric and asymmetric. can someone privide another > conditions. >=20 > regards > liu >=20 >=20 >=20 > Ben Niven-Jenkins >=20 > 2009-04-20 16:36 =CA=D5=BC=FE=C8=CB > > =B3=AD=CB=CD > > =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidirectional transport path requirements >=20 >=20 >=20 >=20 >=20 >=20 > Liu, >=20 > If I understand correctly you are saying associated bi-directional > paths can > support both symmetric and asymmetric bandwidth transport paths. >=20 > That is correct. >=20 > Ben >=20 >=20 >=20 > On 20/04/2009 08:27, "liu.guoman@zte.com.cn" > wrote: >=20 > > Ben: > > you can wrongly understand my meaning , here I want to clarify it = is > > unnecessary for associated bidirectional path to keep symmetric > bandwidth > > in both forward and backward path. > > maybe my expressing isn't clarify to make you to diffultly > understand it. > > here I say sorry to all > > > > regards > > liu > > > > > > > > Ben Niven-Jenkins > > 2009-04-20 14:02 > > > > =CA=D5=BC=FE=C8=CB > > , Lou Berger > > =B3=AD=CB=CD > > > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > > > > > > > > Liu, > > > > > > On 20/04/2009 02:00, "liu.guoman@zte.com.cn" > > wrote: > > > >> lou: > >> because The forward and backward directions are setup, = monitored > and > >> protected independent in the associated bidirectional paths. it > can't > >> ensure and realize the symmetric bandwidth in two directional path. > >> or else , I MUST revise the definitions of associated bidirectional > > paths > >> in mpls-tp requirements draft. > > > > You are claiming that it is not possible for the end points of an > > associated > > bidirectional path to ensure that both directions have the same > bandwidth > > attributes. This is clearly IMO incorrect. > > > > Let's take a real world example to illustrate why it is incorrect. = If > it > > were true then it would not be possible for example to support E1 = PWs > in > > MPLS networks today. Such E1 PWs are successfully being used in MPLS > > networks today to support customer services. > > > > Ben > > > > > > > >> > >> regards > >> liu > >> > >> > >> > >> Lou Berger > >> 2009-04-17 21:54 > >> > >> =CA=D5=BC=FE=C8=CB > >> liu.guoman@zte.com.cn > >> =B3=AD=CB=CD > >> Ben Niven-Jenkins , mpls-tp@ietf.org > >> =D6=F7=CC=E2 > >> Re: [mpls-tp] Associated bidirectional transport path requirements > >> > >> > >> > >> > >> > >> > >> Liu, > >> Why isn't it necessary for associated = bidirectional > >> paths? Is it that > >> asymmetric is the sole requirement? If not, I don't understand = your > >> comment. > >> > >> Lou > >> > >> On 4/16/2009 9:15 PM, liu.guoman@zte.com.cn wrote: > >>> > >>> Lou: > >>> I agree your advice, but for symmetric bandwidth requirement, I > think > >>> the requirement can only be fit for co-routed bidirectional > transport > >>> paths, while it isn't necessary for associated bidirectional paths > .so > >>> adding a "co-routed" word in the requirement 33 is necessary. > >>> thank you. > >>> liu > >>> > >>> > >>> *Lou Berger * > >>> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org > >>> > >>> 2009-04-16 21:43 > >>> > >>> > >>> =CA=D5=BC=FE=C8=CB > >>> Ben Niven-Jenkins > >>> =B3=AD=CB=CD > >>> BUSI@core3.amsl.com, "mpls-tp@ietf.org" > >> , ITALO > >>> > >>> =D6=F7=CC=E2 > >>> Re: [mpls-tp] Associated bidirectional transport > path > >> requirements > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Ben, > >>> It seems to me that much of the discussion stems from the section > in > >>> which these requirements are listed. > >>> > >>> Requirement 32 is a service level requirement and primarily impact > the > >>> management and control planes. As there is no section describing > >>> service requirements, I suggest moving this requirement to follow > >>> requirement 6, and adding the following in its place: > >>> 33 MPLS-TP MUST support bidirectional transport paths with > >>> symmetric bandwidth requirements, i.e. the amount of reserved > >>> bandwidth is the same between the forward and backward > >>> directions. > >>> > >>> While this too is a service requirement and doesn't require any > > hardware > >>> modifications, it parallels current requirements 37, 40 and 41. It > also > >>> makes a currently implicit requirement explicit. > >>> > >>> Requirements 33-26 relate to "awareness" should have no = implication > on > >>> the data/forwarding plane and are IMO both management and control > plane > >>> requirements. (And yes, they have implications on OAM and > recovery.) I > >>> think Adrian raises a good point WRT these requirements, i.e., are > > these > >>> requirements listed as solutions to some unlisted requirements. If > so, > >>> the unlisted requirements should be included and these should be > >>> dropped. If not, so be it, but they should be moved from section > 2.3. > >>> > >>> While I'm sure this won't end the discussion, I think these = changes > > will > >>> help make "the requirements clear enough ..." > >>> > >>> Lou > >>> > >>> On 4/16/2009 5:58 AM, Ben Niven-Jenkins wrote: > >>>> Colleagues, > >>>> > >>>> I can't help but feel we are overanalysing things here. How many > >>>> technologies/protocols/mechanisms have we successfully defined in > >>> both IETF > >>>> & ITU-T without this level of analysis of the initial = requirements > - > >>> a great > >>>> many (a good chunk of which were extremely successful). > >>>> > >>>> The requirements document is not about specifying solutions. > >>>> > >>>> The key question is: are the requirements clear enough that it is > >>> understood > >>>> what is required so someone could build a box/protocol/whatever = to > >> meet > >>>> them? > >>>> > >>>> If we want to go into the nth level of detail on each requirement > we > >> will > >>>> still be debating this by the time I retire (which isn't due = until > >> 2045). > >>>> > >>>> Ben > >>>> > >>>> > >>>> On 16/04/2009 08:04, "Alexander Vainshtein" > >>>> wrote: > >>>> > >>>>> Adrian, > >>>>> Thank you for a prompt and detailed response. > >>>>> > >>>>> Unfortunately I cannot fully agree with your statement: > >>>>> > >>>>> > >>>>> From the point of view of hardware, co-routed bidirectional LSPs > >>>>> are a special case of associated bidirectional LSPs. > >>>>> > >>>>> > >>>>> This statement would be obviously correct, were it not for > >>> Requirement 34 in > >>>>> the latest > >>>>> MPLS-TP requirements draft > >>>>> > >>> ( > >> > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements- > 06.txt > >> ): > >>>>> > >>>>> > >>>>> The intermediate nodes (including MEPs, MIPs and other internal > >>>>> functions as appropriate) of a co-routed bidirectional transport > >>>>> path at each (sub-)layer MUST be aware of the pairing > >>>>> relationship of the forward and the backward directions of that > >>>>> transport path. > >>>>> > >>>>> > >>>>> Please note that Requirement 34 is the ONLY item in the list = that > is > >> > >>> specific > >>>>> for co-routed bidirectional LSPs. (The pairing requirements at > end > >>> points > >>>>> for co-routed and associated bidirectional paths are exactly the > >>> same even > >>>>> if they appear in two different items in the requirements' = list). > >>>>> In other words, without Requirement 34 the notion of co-routed > >>> bidirectional > >>>>> paths would be void of any data plane content. > >>>>> > >>>>> The somewhat vague scope of this requirement ("other internal > >> functions > >>>>> as appropriate") creates a suspicion that HW support of the > pairing > >>> awareness > >>>>> may be required in order to comply with it. > >>>>> > >>>>> The following text in the draft increases this suspicion: > >>>>> > >>>>> > >>>>> Tandem Connection: A tandem connection is an arbitrary part of a > >>>>> transport path that can be monitored (via OAM) independently = from > >> the > >>>>> end-to-end monitoring (OAM). It may be a monitored segment or a > >>>>> monitored concatenated segment of a transport path. The tandem > >>>>> connection may also include the forwarding engine(s) of the > node(s) > >>>>> at the edge(s) of the segment or concatenated segment. > >>>>> > >>>>> > >>>>> Doesn't "forwarding engine" sound like hardware to you? > >>>>> > >>>>> IMHO it is worth noting that neither the MPLS-TP Requirements > draft > >>>>> nor the MPLS-TP OAM requirements one > >>>>> > >>> ( > >> > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam- > requirements-01.tx > > > >> > >>>>> t) > >>>>> contain any requirements dealing with tandem connections. > >>>>> > >>>>> But tandem connections are discussed in the MPLS-TP OAM = Framework > >> draft > >>>>> > >>> ( > >> > > = http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework- > 00.txt > > > >> ). > >>>>> > >>>>> The bottom line, IMHO, is that some clarity regarding co-routed > vs. > >>> associated > >>>>> bidirectional > >>>>> paths is still required. One way to provide that could be by > >> explicitly > >>>>> limiting Requirement 34 > >>>>> to specific functionality. > >>>>> > >>>>> My 2c, > >>>>> Sasha > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> From: Adrian Farrel [adrian@olddog.co.uk] > >>>>> Sent: Thursday, April 16, 2009 12:13 AM > >>>>> To: Alexander Vainshtein; Lou Berger; BUSI ITALO > >>>>> Cc: mpls-tp@ietf.org > >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path > >>> requirements > >>>>> > >>>>> Hi Sasha, > >>>>> > >>>>> Not really sure whether you are misrepresenting anyone, but... > >>>>> > >>>>>> 1. My reading of one of Ben's messages is that associated > >>>>>> bidirectional paths are the only types of paths that can be > >>>>>> created in the existing networks; "true" co-routed = bidirectional > >>>>>> paths will have to wait until (if ever) new equipment becomes > >>>>>> available. > >>>>> This is clearly nonsense! > >>>>> From the point of view of hardware, co-routed bidirectional LSPs > are > >> a > >>>>> special case of associated bidirectional LSPs. > >>>>> > >>>>> If you can set up two unidirectional LSPs (e.g. using the > management > >> > >>> plane) > >>>>> you can surely set up a co-routed bidirectional LSP. > >>>>> > >>>>> There are shipping solutions that achieve co-routed = bidirectional > >>> LSPs using > >>>>> the control plane. These either use the GMPLS (which is cleaner) > or > >>>>> non-standard proprietary solutions (which is messy but > functional). > >>>>> > >>>>> But (of course) the management plane or control plane solutions > have > >> > >>> nothing > >>>>> to do with availability of equipment as they are software > solutions. > >>>>> > >>>>>> 2. My reading of one of Neil's messages is that the actual > driver > >> for > >>>>>> co-routed > >>>>>> bidirectional paths may be experience with existing transport > >> networks > >>>>>> rather > >>>>>> than any specific benefit. > >>>>> Isn't that the case with 75% of the MPLS-TP requirements? > >>>>> Which is not to say it is a bad thing. > >>>>> > >>>>> A large driver for MPLS-TP is to give the packet network the > look, > >>> feel, and > >>>>> behavioral characteristics of a "legacy" transport network. > >>>>> > >>>>>> Based on these observations, I'd guess (FWIW) that: > >>>>>> * associated bidirectional paths are, at least for the time > >>>>>> being, the most important type of bidirectional paths in > >>>>>> MPLS-TP > >>>>> I think that is wrong both given my statement above, and given > that > >>> other > >>>>> upgrades to existing MPLS solutions will be needed to reach the > full > >>>>> function level of MPLS-TP. > >>>>> > >>>>>> * they had a good chance to remain the only type of > bidirectional > >>>>>> paths in real deployments. > >>>>> I don't see what that follows from. > >>>>> > >>>>> Cheers, > >>>>> Adrian > >>>>> _______________________________________________ > >>>>> mpls-tp mailing list > >>>>> mpls-tp@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>>> > >>>> _______________________________________________ > >>>> mpls-tp mailing list > >>>> mpls-tp@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> mpls-tp mailing list > >>> mpls-tp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>> > >>> > >>> -------------------------------------------------------- > >>> ZTE Information Security Notice: The information contained > in > >> this mail is solely property of the sender's organization. > This > >> mail communication is confidential. Recipients named above > are > >> obligated to maintain secrecy and are not permitted to > disclose > >> the contents of this communication to others. > >>> This email and any files transmitted with it are > confidential > >> and intended solely for the use of the individual or > entity to > >> whom they are addressed. If you have received this email > in > >> error please notify the originator of the message. Any > views > >> expressed in this message are those of the individual > sender. > >>> This message has been scanned for viruses and Spam by = ZTE > >> Anti-Spam system. > >> > >> > >> > >> > >> -------------------------------------------------------- > >> ZTE Information Security Notice: The information contained in this > mail > > is > >> solely property of the sender's organization. This mail > communication is > >> confidential. Recipients named above are obligated to maintain > secrecy > > and are > >> not permitted to disclose the contents of this communication to > others. > >> This email and any files transmitted with it are confidential and > > intended > >> solely for the use of the individual or entity to whom they are > > addressed. If > >> you have received this email in error please notify the originator > of > > the > >> message. Any views expressed in this message are those of the > individual > >> sender. > >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > mail is > > solely property of the sender's organization. This mail = communication > is > > confidential. Recipients named above are obligated to maintain > secrecy and are > > not permitted to disclose the contents of this communication to > others. > > This email and any files transmitted with it are confidential and > intended > > solely for the use of the individual or entity to whom they are > addressed. If > > you have received this email in error please notify the originator = of > the > > message. Any views expressed in this message are those of the > individual > > sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail > is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of = this > communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the originator of the message. Any views expressed in this message are > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. From loa@pi.nu Mon Apr 20 04:21:21 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4116B28C2A6 for ; Mon, 20 Apr 2009 04:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_50=0.001, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY7dfZy7lfS4 for ; Mon, 20 Apr 2009 04:21:20 -0700 (PDT) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 72BD828C285 for ; Mon, 20 Apr 2009 04:21:20 -0700 (PDT) Received: from webmail.elverljung.se (localhost [127.0.0.1]) by ns.elverljung.se (Postfix) with ESMTP id 97CF22D883C for ; Mon, 20 Apr 2009 13:22:33 +0200 (CEST) Received: from 194.237.142.6 (SquirrelMail authenticated user loa) by webmail.elverljung.se with HTTP; Mon, 20 Apr 2009 13:22:33 +0200 (CEST) Message-ID: <60ac7f5a82d1903674568d2f0daf4bd0.squirrel@webmail.elverljung.se> Date: Mon, 20 Apr 2009 13:22:33 +0200 (CEST) From: "Loa Andersson" To: mpls-tp@ietf.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [mpls-tp] updated process draft X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa@pi.nu List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 11:21:21 -0000 All, I've updated the MPLS-TP draft http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt This draft is still woek in progress, and I'm not sure I intend to progress it to wg draft or RFC, nevertheless this document is the document that guides how the MPLS-TP drafts are managed- The document is in need of a grammar and spelling review, anyone that wants to undertaken that task is welcome. /Loa From lberger@labn.net Mon Apr 20 04:25:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67AF3A67A1 for ; Mon, 20 Apr 2009 04:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkcTh9vKIRHD for ; Mon, 20 Apr 2009 04:25:30 -0700 (PDT) Received: from outbound-mail-19.bluehost.com (outbound-mail-19.bluehost.com [69.89.20.234]) by core3.amsl.com (Postfix) with SMTP id 2776C3A6AE3 for ; Mon, 20 Apr 2009 04:25:26 -0700 (PDT) Received: (qmail 25091 invoked by uid 0); 20 Apr 2009 10:25:16 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy1.bluehost.com with SMTP; 20 Apr 2009 10:25:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Gk/yzo6aVzhDsAqjL7pCRojRJlq/tnfMSOpGVO0xqsrHonLDiJT/npTP4WbpSAdZsWAqfY0AMXRrZHMdLJqz939iHiV6nZbx0ERmz90z02WreO68utFOsvOWh6XyS3mq; Received: from box474.bluehost.com ([74.220.219.74] helo=[127.0.0.1]) by box474.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lvre4-0002Xr-Bu; Mon, 20 Apr 2009 05:26:40 -0600 Message-ID: <49EC5BF2.6030908@labn.net> Date: Mon, 20 Apr 2009 07:26:42 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Ben Niven-Jenkins References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {2629:box474.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.220.219.74 authed with lberger@labn.net} Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 11:25:31 -0000 Ben, I agree completely. Lou On 4/20/2009 2:02 AM, Ben Niven-Jenkins wrote: > Liu, > > > On 20/04/2009 02:00, "liu.guoman@zte.com.cn" wrote: > >> lou: >> because The forward and backward directions are setup, monitored and >> protected independent in the associated bidirectional paths. it can't >> ensure and realize the symmetric bandwidth in two directional path. >> or else , I MUST revise the definitions of associated bidirectional paths >> in mpls-tp requirements draft. > > You are claiming that it is not possible for the end points of an associated > bidirectional path to ensure that both directions have the same bandwidth > attributes. This is clearly IMO incorrect. > > Let's take a real world example to illustrate why it is incorrect. If it > were true then it would not be possible for example to support E1 PWs in > MPLS networks today. Such E1 PWs are successfully being used in MPLS > networks today to support customer services. > > Ben > > > >> regards >> liu >> >> >> >> Lou Berger >> 2009-04-17 21:54 >> >> �� >> liu.guoman@zte.com.cn >> �� >> Ben Niven-Jenkins, mpls-tp@ietf.org >> �� >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> Liu, >> Why isn't it necessary for associated bidirectional >> paths? Is it that >> asymmetric is the sole requirement? If not, I don't understand your >> comment. >> >> Lou >> >> On 4/16/2009 9:15 PM, liu.guoman@zte.com.cn wrote: >>> Lou: >>> I agree your advice, but for symmetric bandwidth requirement, I think >>> the requirement can only be fit for co-routed bidirectional transport >>> paths, while it isn't necessary for associated bidirectional paths .so >>> adding a "co-routed" word in the requirement 33 is necessary. >>> thank you. >>> liu >>> >>> >>> *Lou Berger* >>> ��: mpls-tp-bounces@ietf.org >>> >>> 2009-04-16 21:43 >>> >>> >>> �� >>> Ben Niven-Jenkins >>> �� >>> BUSI@core3.amsl.com, "mpls-tp@ietf.org" >> , ITALO >>> >>> �� >>> Re: [mpls-tp] Associated bidirectional transport path >> requirements >>> >>> >>> >>> >>> >>> >>> >>> Ben, >>> It seems to me that much of the discussion stems from the section in >>> which these requirements are listed. >>> >>> Requirement 32 is a service level requirement and primarily impact the >>> management and control planes. As there is no section describing >>> service requirements, I suggest moving this requirement to follow >>> requirement 6, and adding the following in its place: >>> 33 MPLS-TP MUST support bidirectional transport paths with >>> symmetric bandwidth requirements, i.e. the amount of reserved >>> bandwidth is the same between the forward and backward >>> directions. >>> >>> While this too is a service requirement and doesn't require any hardware >>> modifications, it parallels current requirements 37, 40 and 41. It also >>> makes a currently implicit requirement explicit. >>> >>> Requirements 33-26 relate to "awareness" should have no implication on >>> the data/forwarding plane and are IMO both management and control plane >>> requirements. (And yes, they have implications on OAM and recovery.) I >>> think Adrian raises a good point WRT these requirements, i.e., are these >>> requirements listed as solutions to some unlisted requirements. If so, >>> the unlisted requirements should be included and these should be >>> dropped. If not, so be it, but they should be moved from section 2.3. >>> >>> While I'm sure this won't end the discussion, I think these changes will >>> help make "the requirements clear enough ..." >>> >>> Lou >>> >>> On 4/16/2009 5:58 AM, Ben Niven-Jenkins wrote: >>>> Colleagues, >>>> >>>> I can't help but feel we are overanalysing things here. How many >>>> technologies/protocols/mechanisms have we successfully defined in >>> both IETF >>>> & ITU-T without this level of analysis of the initial requirements - >>> a great >>>> many (a good chunk of which were extremely successful). >>>> >>>> The requirements document is not about specifying solutions. >>>> >>>> The key question is: are the requirements clear enough that it is >>> understood >>>> what is required so someone could build a box/protocol/whatever to >> meet >>>> them? >>>> >>>> If we want to go into the nth level of detail on each requirement we >> will >>>> still be debating this by the time I retire (which isn't due until >> 2045). >>>> Ben >>>> >>>> >>>> On 16/04/2009 08:04, "Alexander Vainshtein" >>>> wrote: >>>> >>>>> Adrian, >>>>> Thank you for a prompt and detailed response. >>>>> >>>>> Unfortunately I cannot fully agree with your statement: >>>>> >>>>> >>>>> From the point of view of hardware, co-routed bidirectional LSPs >>>>> are a special case of associated bidirectional LSPs. >>>>> >>>>> >>>>> This statement would be obviously correct, were it not for >>> Requirement 34 in >>>>> the latest >>>>> MPLS-TP requirements draft >>>>> >>> ( >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.txt >> ): >>>>> >>>>> The intermediate nodes (including MEPs, MIPs and other internal >>>>> functions as appropriate) of a co-routed bidirectional transport >>>>> path at each (sub-)layer MUST be aware of the pairing >>>>> relationship of the forward and the backward directions of that >>>>> transport path. >>>>> >>>>> >>>>> Please note that Requirement 34 is the ONLY item in the list that is >>> specific >>>>> for co-routed bidirectional LSPs. (The pairing requirements at end >>> points >>>>> for co-routed and associated bidirectional paths are exactly the >>> same even >>>>> if they appear in two different items in the requirements' list). >>>>> In other words, without Requirement 34 the notion of co-routed >>> bidirectional >>>>> paths would be void of any data plane content. >>>>> >>>>> The somewhat vague scope of this requirement ("other internal >> functions >>>>> as appropriate") creates a suspicion that HW support of the pairing >>> awareness >>>>> may be required in order to comply with it. >>>>> >>>>> The following text in the draft increases this suspicion: >>>>> >>>>> >>>>> Tandem Connection: A tandem connection is an arbitrary part of a >>>>> transport path that can be monitored (via OAM) independently from >> the >>>>> end-to-end monitoring (OAM). It may be a monitored segment or a >>>>> monitored concatenated segment of a transport path. The tandem >>>>> connection may also include the forwarding engine(s) of the node(s) >>>>> at the edge(s) of the segment or concatenated segment. >>>>> >>>>> >>>>> Doesn't "forwarding engine" sound like hardware to you? >>>>> >>>>> IMHO it is worth noting that neither the MPLS-TP Requirements draft >>>>> nor the MPLS-TP OAM requirements one >>>>> >>> ( >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01.tx >> >>>>> t) >>>>> contain any requirements dealing with tandem connections. >>>>> >>>>> But tandem connections are discussed in the MPLS-TP OAM Framework >> draft >>> ( >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt >> ). >>>>> The bottom line, IMHO, is that some clarity regarding co-routed vs. >>> associated >>>>> bidirectional >>>>> paths is still required. One way to provide that could be by >> explicitly >>>>> limiting Requirement 34 >>>>> to specific functionality. >>>>> >>>>> My 2c, >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: Adrian Farrel [adrian@olddog.co.uk] >>>>> Sent: Thursday, April 16, 2009 12:13 AM >>>>> To: Alexander Vainshtein; Lou Berger; BUSI ITALO >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>> requirements >>>>> Hi Sasha, >>>>> >>>>> Not really sure whether you are misrepresenting anyone, but... >>>>> >>>>>> 1. My reading of one of Ben's messages is that associated >>>>>> bidirectional paths are the only types of paths that can be >>>>>> created in the existing networks; "true" co-routed bidirectional >>>>>> paths will have to wait until (if ever) new equipment becomes >>>>>> available. >>>>> This is clearly nonsense! >>>>> From the point of view of hardware, co-routed bidirectional LSPs are >> a >>>>> special case of associated bidirectional LSPs. >>>>> >>>>> If you can set up two unidirectional LSPs (e.g. using the management >>> plane) >>>>> you can surely set up a co-routed bidirectional LSP. >>>>> >>>>> There are shipping solutions that achieve co-routed bidirectional >>> LSPs using >>>>> the control plane. These either use the GMPLS (which is cleaner) or >>>>> non-standard proprietary solutions (which is messy but functional). >>>>> >>>>> But (of course) the management plane or control plane solutions have >>> nothing >>>>> to do with availability of equipment as they are software solutions. >>>>> >>>>>> 2. My reading of one of Neil's messages is that the actual driver >> for >>>>>> co-routed >>>>>> bidirectional paths may be experience with existing transport >> networks >>>>>> rather >>>>>> than any specific benefit. >>>>> Isn't that the case with 75% of the MPLS-TP requirements? >>>>> Which is not to say it is a bad thing. >>>>> >>>>> A large driver for MPLS-TP is to give the packet network the look, >>> feel, and >>>>> behavioral characteristics of a "legacy" transport network. >>>>> >>>>>> Based on these observations, I'd guess (FWIW) that: >>>>>> * associated bidirectional paths are, at least for the time >>>>>> being, the most important type of bidirectional paths in >>>>>> MPLS-TP >>>>> I think that is wrong both given my statement above, and given that >>> other >>>>> upgrades to existing MPLS solutions will be needed to reach the full >>>>> function level of MPLS-TP. >>>>> >>>>>> * they had a good chance to remain the only type of bidirectional >>>>>> paths in real deployments. >>>>> I don't see what that follows from. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>>> >>>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >>> >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained in >> this mail is solely property of the sender's organization. This >> mail communication is confidential. Recipients named above are >> obligated to maintain secrecy and are not permitted to disclose >> the contents of this communication to others. >>> This email and any files transmitted with it are confidential >> and intended solely for the use of the individual or entity to >> whom they are addressed. If you have received this email in >> error please notify the originator of the message. Any views >> expressed in this message are those of the individual sender. >>> This message has been scanned for viruses and Spam by ZTE >> Anti-Spam system. >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy and are >> not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and intended >> solely for the use of the individual or entity to whom they are addressed. If >> you have received this email in error please notify the originator of the >> message. Any views expressed in this message are those of the individual >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam system. >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > > From loa@pi.nu Mon Apr 20 04:50:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661923A69F8 for ; Mon, 20 Apr 2009 04:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ0Cm3hhIgRd for ; Mon, 20 Apr 2009 04:49:59 -0700 (PDT) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 9A75F3A68E7 for ; Mon, 20 Apr 2009 04:49:59 -0700 (PDT) Received: from webmail.elverljung.se (localhost [127.0.0.1]) by ns.elverljung.se (Postfix) with ESMTP id 0E05E2D88B1 for ; Mon, 20 Apr 2009 13:51:14 +0200 (CEST) Received: from 194.237.142.6 (SquirrelMail authenticated user loa) by webmail.elverljung.se with HTTP; Mon, 20 Apr 2009 13:51:14 +0200 (CEST) Message-ID: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> Date: Mon, 20 Apr 2009 13:51:14 +0200 (CEST) From: "Loa Andersson" To: mpls-tp@ietf.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa@pi.nu List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 11:50:00 -0000 All, I'd like to comment on the current discussion on http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-06 . We do our best follow the the mpls-tp process as described in: http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt The outstanding question we have for the ITU-T ad hoc team on MPLS-TP is step 13 in the figure on page 7 of that draft. We are asking the ad hoc Team if the draft is good enough to send to the IESG with a request for publication. Please note that we are only expecting a "yes" or "no" answer to our question. If the response is "yes" then publication will be requested, if the answer is "no", the document will be taken back into the working group process and a new version produced. That said, there is never wrong to discuss technical improvements, editorial issues or genereal clarifications on any draft. /Loa From John.E.Drake2@boeing.com Mon Apr 20 05:47:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179B928C28B for ; Mon, 20 Apr 2009 05:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.717 X-Spam-Level: X-Spam-Status: No, score=-4.717 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKvELaMmpn7X for ; Mon, 20 Apr 2009 05:47:43 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 579A328C2B7 for ; Mon, 20 Apr 2009 05:47:33 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3KCmgGP023421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 07:48:47 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3KCmgM2016179; Mon, 20 Apr 2009 07:48:42 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3KCmgMe016171; Mon, 20 Apr 2009 07:48:42 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 05:48:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 05:48:38 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6C023@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnBXPUqYqwG+kDAQEmJZ6Quz8Fi3wAWTtAQ References: <51661468CBD1354294533DA79E85955A01A6BE71@XCH-SW-5V2.sw.nos.boeing.com> From: "Drake, John E" To: X-OriginalArrivalTime: 20 Apr 2009 12:48:41.0424 (UTC) FILETIME=[5530CD00:01C9C1B6] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 12:47:45 -0000 liu, Please re-read my e-mail. You are agreeing with me. Thanks, John > -----Original Message----- > From: liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn]=20 > Sent: Sunday, April 19, 2009 7:01 PM > To: Drake, John E > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 >=20 > John=A3=BA > I don't completely agree your opinions. for unidirectional=20 > P2P and P2MP path, if there is no return path, how can sink=20 > points reply to source point's request packet? if there are=20 > some faults in the backward sections of this unidirectional=20 > path, the sink points will detects the defects, if no return=20 > path, how can the sink points notify the fault message to=20 > source points.=20 > and so, I think if there is no return path, what happened to=20 > unidirectional P2P and P2MP ?=20 > I think we consider the return path.=20 >=20 > regards > liu=20 >=20 >=20 >=20 > "Drake, John E" =20 > =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 >=20 > 2009-04-18 03:02 =CA=D5=BC=FE=C8=CB > "BUSI ITALO" , "Alexander=20 > Vainshtein" , "Maarten=20 > Vissers" =20 > =B3=AD=CB=CD > mpls-tp@ietf.org=20 > =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidiroectional transport path requirements >=20 > =09 >=20 >=20 >=20 >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a=20 > return path > they are disabled. >=20 > As described in David Sinicrope's meeting minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an > MPLS TP network needs to be capable of getting IP packets from > destination to source; neither the minutes nor I stipulate that a > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework > I-D, unicast LSPs are only mentioned three times and return=20 > paths not at > all. =20 >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of=20 > > requirements ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a=20 > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus=20 > > other more important requirements (e.g. the possibility to=20 > > work w/o IP forwarding and the need for OAM to continue to=20 > > monitor the data plane also in case of failures affecting the=20 > > control or management plane). > >=20 > > I am open to discuss it but not sure this is the right time=20 > > because I wish to avoid delaying the first phase of the=20 > > design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I=20 > > think it was=20 > > > agreed that an MPLS TP network needs to have a forwarding=20 > > capability=20 > > > for management, control, and OAM packets (e.g., sending=20 > > replies to OAM=20 > > > requests sent on uni-directional LSPs) even if it does not=20 > > have an IP=20 > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP=20 > loopback function=20 > > (and fault=20 > > > > localization which requires this function ) for=20 > > unidirectional P2MP=20 > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW)=20 > raises a valid=20 > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for=20 > these types of transport=20 > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of=20 > > functionality today=20 > > > > for (unidirectional - but it does not know any other=20 > > type) P2P LSPs =20 > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org]=20 > > On Behalf=20 > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much=20 > observable if=20 > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other=20 > > direction of=20 > > > > the co-routed bidirectional transport path. This other=20 > direction=20 > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a=20 > > segment, then=20 > > > > this is possible in a co-routed bidir transport path=20 > but not in a=20 > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can=20 > exchange what is=20 > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions=20 > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able=20 > > to provide=20 > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be=20 > > deleted at=20 > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem=20 > > connection is=20 > > > > described in ITU-T recommendations. I.e. "from the=20 > > monitoring of a=20 > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network=20 > > connection is a set=20 > > > > of interconnected "link connections" and "matrix=20 > connections". A=20 > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as=20 > a "tandem=20 > > > > connection". There is no "path that is parallel to the=20 > > data path".=20 > > > > There is only additional OAM inserted inside the data=20 > path by the=20 > > > > TCM MEP_So function and this OAM is extracted from the=20 > > data path by=20 > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That=20 > > is, there is > > > > *nothing* that can be observed from a black box point of=20 > > view that=20 > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used=20 > for anything=20 > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of=20 > co-routed=20 > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs,=20 > > MIPs and other=20 > > > > internal functions as appropriate)" should be deleted. It=20 > > does not=20 > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an=20 > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored=20 > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent=20 > > insistence on the=20 > > > > inclusion of "Tandem Connection." The definition within=20 > > the ITU-T of=20 > > > > this term is poorly specified and comes from the=20 > monitoring of a=20 > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance,=20 > > and would=20 > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM=20 > > Framework=20 > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all=20 > the I-Ds=20 > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed=20 > > bidirectional LSPs are=20 > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the=20 > > management=20 > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed=20 > bidirectional=20 > > > > LSPs using the control plane. These either use the GMPLS=20 > > (which is=20 > > > > cleaner) or non-standard proprietary solutions (which is=20 > > messy but=20 > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane=20 > > solutions have=20 > > > > nothing to do with availability of equipment as they=20 > are software=20 > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network=20 > > the look,=20 > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and=20 > > given that=20 > > > > other upgrades to existing MPLS solutions will be=20 > needed to reach=20 > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of=20 > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in=20 > this mail is solely property of the sender's organization.=20 > This mail communication is confidential. Recipients named=20 > above are obligated to maintain secrecy and are not permitted=20 > to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential=20 > and intended solely for the use of the individual or entity=20 > to whom they are addressed. If you have received this email=20 > in error please notify the originator of the message. Any=20 > views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE=20 > Anti-Spam system. >=20 From maarten.vissers@huawei.com Mon Apr 20 06:22:53 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2263A696C for ; Mon, 20 Apr 2009 06:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpKPbXJKbKF6 for ; Mon, 20 Apr 2009 06:22:52 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id 1AC5D3A67D1 for ; Mon, 20 Apr 2009 06:22:52 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042006240709521 ; Mon, 20 Apr 2009 06:24:07 -0700 Received: from M00900002 ([10.84.1.19]) by s-utl02-sjpop.stsn.net; Mon, 20 Apr 2009 06:24:04 -0700 From: "Maarten Vissers" To: Date: Mon, 20 Apr 2009 15:23:56 +0200 Message-ID: <006501c9c1bb$48839d80$1301540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C046FFEC6@E03MVB2-UKBR.domain1.systemhost.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsAABEewwAAbNqSAAARuBAACKJXcg Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 13:22:53 -0000 Neil, > When we wrote a systems engineering spec for PBB-TE a while back there = was no mention of TCM, If I understand PBB-TE, then the TESI in PBB-TE provides a tunnel which starts/ends at e.g. metro domain edges (802.1Qay PAR states that PBB-TE = is defined for single domain usage only).=20 Furthermore, TESI protection is provided using TESI trail OAM; = essentially the client signals carried by the TESI are protected as group using = inherent monitoring. In G.808.1 this is referred to as CL-SNCG/I protection.=20 Because of the above there is indeed no need for TCM in PBB-TE TESI connections. For MPLS-TP LSPs the same may hold; i.e. if MPLS-TP LSPs 1) are single carrier 2) start/end at metro domain edges or start/end at core domain edges 3) are protected using client CL-SNCG/I protection then there is no need for LSP TCM. If we decide that the MPLS-TP is a metro or core domain in a PTN and = that the PTN deploys the EVC as its UNI-to-UNI service/channel layer, then = the MPLS-TP PW provide an EVC link connection and is always a SS-PW. For = this case there is no MPLS-TP PW layer network and there is no need for = MPLS-TP TCM. The EVC (ETH) layer network with its UNI-to-UNI EVCs there is a EVC TCM requirement as those EVCs may be multi-carrier EVCs. EVCs may start/end = at UNI-N ports (EVC Type I), or may start/end in the user domain (EVC Type = II). For the case of EVC Type I, the PTN owns all MEG levels (0 to 7). For = the case of EVC Type II, the PTN owns only a subset of MEG levels (e.g. 0 to = 4); the user can deploy all MEG levels (o to 7) inside its own domain, and = can use the top MEG levels (e.g. 5 to 7) in the EVC passing through the PTN. Regards, Maarten =20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: vrijdag 17 april 2009 21:25 To: Italo.Busi@alcatel-lucent.it; dbrungard@att.com; benjamin.niven-jenkins@bt.com; annamaria.fulignoli@ericsson.com; Martin.Vigoureux@alcatel-lucent.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Thanks Italo....I understand why you say this. But I also work closely = with Andy Reid who is the major driving force behind G.800 (and one of the = folks who wrote the initial version of G.805) and it is very clear to me that = the concepts that underpin G.800 are vastly superior to what we understood = (as networking truths) at the time when G.805 was drafted. But this (ie = G.800) is a more general (and powerful) statement about how networks work and = why we see the networking world as we do, ie 3 modes, etc. And IMO it = shoots down some sacred networking cows which is why some folks don't like it = and appeal back to the good-old G.805 days. TCM is a specific issue related to OAM. And to repeat what I said = earlier, I know of no engineer here in BT (this includes folks like Andy Reid, = Alan McGuire, Ben Niven-Jenkins, me (obviously) etc) who think TCM is a good idea....quite the opposite in fact. When we wrote a systems engineering spec for PBB-TE a while back there was no mention of TCM, and we would = hold the same view for MPLS-TP.....there are far smarter ways to deal with = rare on-demand OAM diagnostics. So the mere fact that the term TCM appears = in G.805 does not vindicate it's value in any way IMO. I know you sidestepped my observation on TCM and IP, but if one is = seriously suggesting TCM is such a great idea in IETF then it ought to figure in = IP even before it gets considered for MPLS-TP IMO.....but I strongly = suspect it never will and I think I also know why that would be. regards, Neil > -----Original Message----- > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: 17 April 2009 19:29 > To: Harrison,N,Neil,CXM R; dbrungard@att.com; Niven-jenkins,B,Ben,DMF=20 > R; annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE:Associatedbidirectional transport path requirements) >=20 > Neil, >=20 > G.805 is an in-force Recommendation: G.800 was never intended to=20 > replace G.805. >=20 > People who worked on G.800 has always claimed that for=20 > connection-oriented technologies G.800 defaults to G.805. >=20 > When Q12/15 consented G.800, it was agreed that existing=20 > Recommendations based on G.805 (e.g. G.8110.1) will continue to be=20 > based on G.805. >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > neil.2.harrison@bt.com > > Sent: Friday, April 17, 2009 5:22 PM > > To: dbrungard@att.com; benjamin.niven-jenkins@bt.com;=20 > > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > > RE:Associatedbidirectional transport path requirements) > >=20 > > I agree with both Ben and Deborah. One further point to > add here..... > >=20 > > G.805 is a fairly old Recommendation written largely to give us a=20 > > working func arch language for the development of management=20 > > information models when we were developing SONET/SDH. However, our=20 > > understanding of the physics of networking has improved=20 > > significantly and G.800 (Unified functional architecture of=20 > > transport networks) is a more comprehensive embodiment of that=20 > > understanding that covers all 3 network modes (based on sound Info=20 > > and Systems theory underpinnings). So G.800 should be the starting=20 > > point for any references to the network func architecture for=20 > > MPLS-TP and not G.805 IMO. > >=20 > > regards, Neil > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH=20 > > > A, ATTLABS > > > Sent: 17 April 2009 15:59 > > > To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli; > Martin Vigoureux > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > Associatedbidirectional transport path requirements) > > >=20 > > > I agree with Ben. TCM, with the introduction of MEL as a solution, = > > > has become architecturally confusing. When it was used in=20 > > > reference to SDH, where trail overhead was overwritten, it created = > > > a tandem connection. For cell/packet technologies where the OAM=20 > > > cells/packets are inserted, it is not clear if this is a tandem=20 > > > connection or a new server layer, as both architectural terms are=20 > > > used in the standards. > > >=20 > > > In G803, TCM is a sublayer monitoring technique for a SDH tandem=20 > > > connection: > > > "Sublayer monitoring > > > Connections may be directly monitored at one end of a connection=20 > > > by overwriting some portion of the original trail's overhead=20 > > > capacity at the beginning of the connection. > > > For SDH, overhead has been defined for this purpose at the=20 > > > higher-order and lower-order path layers. When applied to a SDH=20 > > > tandem connection, this monitoring method is referred to as tandem = > > > connection monitoring." > > >=20 > > > Whereas in Y.1711: > > > "OAM techniques are applied on a per LSP basis. If a segment of a=20 > > > given LSP at layer N is to be monitored for some reason (e.g., via = > > > a CV or P flow say), one way to do this is by creating a new=20 > > > server layer LSP (i.e., at layer N + 1) to cover the segment at=20 > > > layer N." > > >=20 > > > So I think before using TCM in reference to MPLS-TP, Q12 needs to=20 > > > align on the use. For now, the requirements documents should try=20 > > > to avoid it. > > >=20 > > > Deborah > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > > Sent: Friday, April 17, 2009 10:26 AM > > > To: Annamaria Fulignoli; Martin Vigoureux > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > > Associated bidirectional transport path requirements) > > >=20 > > > Because IMO use of the term TCM tends to make people think of a=20 > > > particular solution and what we want to do at this stage is=20 > > > express the functional requirements and not imply any particular=20 > > > solution. > > >=20 > > > Certainly most of my mails in this thread (and I am probably not=20 > > > the only > > > one) have been based on the fact that when discussing TCM > I assume a > > > particular solution is being discussed. Talking purely in terms of = > > > functional requirements removes that ambiguity. > > >=20 > > > Ben > > >=20 > > >=20 > > > On 17/04/2009 12:51, "Annamaria Fulignoli" > > > wrote: > > >=20 > > > > Hi all, > > > > sorry but I do not understand why we cannot explicitly use > > > the term Tandem > > > > Connection in the requirements document! > > > > TCM is not a solution, it is part of functional > > > architecture of a transport > > > > networks as described in G.805. The solution is to realize > > > it with label > > > > stacking rather than MEL. > > > >=20 > > > > Regards > > > > Annamaria > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > > > Martin Vigoureux > > > > Sent: venerd=EC 17 aprile 2009 13.29 > > > > To: Ben Niven-Jenkins > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was > > > RE: Associated > > > > bidirectional transport path requirements) > > > >=20 > > > > Ben, all > > > >=20 > > > > in mpls-tp-oam-requirement, the text on this item is as follows: > > > >=20 > > > > The service emulated by a single segment or a > > > multi-segment PW may > > > > span multiple domains. A LSP may also span multiple > > > domains. It > > > > MUST be possible to perform OAM functions on a per > > > domain basis and > > > > across multiple domains. More generally it MUST be > > possible to > > > > perform OAM functions between any two switching > > > elements (e.g., LSR > > > > or S-PE) of a LSP or of PW. This is referred to as > > > (concatenated) > > > > segment monitoring. > > > >=20 > > > > I believe the text describes a functional req. > > > >=20 > > > > During mead team review, the removal of the last sentence > > > was discussed. > > > > No strong opinion was expressed on whether it should > > > effectively be removed or > > > > not. > > > >=20 > > > > regards, > > > > martin > > > >=20 > > > > Ben Niven-Jenkins a =E9crit : > > > >> Italo, > > > >>=20 > > > >> I think we are converging. If I can be so bold as to > speak on his > > > >> behalf Adrian's objection seemed to be to the use of the > > term TCM. > > > >>=20 > > > >> It is defined in the MPLS-TP requirements but not used. > > > >>=20 > > > >> It is not used in the MPLS-TP OAM requirements document. > > > >>=20 > > > >> Therefore I think the way forward is as follows: > > > >>=20 > > > >> 1) Remove the term Tandem Connection from the MPLS-TP > > > requirements as > > > >> it is redundant (i.e. Not used in that document). > > > >>=20 > > > >> 2) Ensure the MPLS-TP OAM requirements express the necessary=20 > > > >> functional requirements around monitoring of end to end > > > paths as well > > > >> as parts of end to end paths. This can be done without > referring > > > >> explicitly to Tandem Connections. > > > >>=20 > > > >> When it comes to solution design we can decide what is the best = > > > >> mechanism to achieve/implement those requirements be it > > > LSP hierarchy or > > > >> something else. > > > >> The JWT has proved that it is possible to meet those > requirements > > > >> using existing MPLS technology (maybe with some > > enhancements). I do > > > >> not believe we have to necessarily use the solution > they propose > > > >> aslong as whatever solution we ultimately decide upon > > meets all the > > > >> necessary requirements expressed. > > > >>=20 > > > >> Can we agree on that as an approach and close this off for now? > > > >>=20 > > > >> Ben > > > >>=20 > > > >>=20 > > > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > > > wrote: > > > >>=20 > > > >>> Ben, > > > >>>=20 > > > >>> I think we are mixing solutions with requirements. > > > >>>=20 > > > >>> The requirement for the TCM function is clearly > defined and I do > > > >>> think it must be addressed by the MPLS-TP design. > > > >>>=20 > > > >>> The solution evaluated by the JWT to meet this > > > requirement was to use > > > >>> label stacking with a 1:1 relationship between the TCM > > LSP and the > > > >>> e2e LSP. > > > >>>=20 > > > >>> I think this solution, although not the best technical > > option, is > > > >>> good enough and meets the requirements. > > > >>>=20 > > > >>> However this is is a solution and has not impact on the > > > requirement. > > > >>>=20 > > > >>> Italo > > > >>>=20 > > > >>>> -----Original Message----- > > > >>>> From: Ben Niven-Jenkins > [mailto:benjamin.niven-jenkins@bt.com] > > > >>>> Sent: Friday, April 17, 2009 11:22 AM > > > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > > > >>>> Cc: mpls-tp@ietf.org; Lou Berger > > > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] = > > > >>>> Associated bidirectional transport path requirements) > > > >>>>=20 > > > >>>> Italo, > > > >>>>=20 > > > >>>> On 17/04/2009 09:34, "BUSI ITALO" > > > >>>> wrote: > > > >>>>> The JWT agreement is to bring the ITU-T transport > > > >>>> requirements in IETF > > > >>>>> to extend the MPLS architecture to meet them in a > way that is > > > >>>>> compatible, consistent and coherent with existing IETF > > > architecture. > > > >>>> So I took a look at the JWT report. It says (slide 16) > > > >>>>=20 > > > >>>> " Service Providers want LSPs/PWEs to be able to be > > > managed at the > > > >>>> different nested levels seamlessly (path, segment, multiple > > > >>>> segments) > > > >>>> aka Tandem Connection Monitoring (TCM), this is used > > > for example > > > >>>> when a LSP/PWE crosses multiple administrations" > > > >>>>=20 > > > >>>> IMO the requirement is to be able to monitor parts of a > > > path as well > > > >>>> as the end to end path. There are many ways to solve that=20 > > > >>>> requirement, one of which is the creation of nested > > LSPs, one per > > > >>>> level of monitoring required (my understanding of how > > TCM works). > > > >>>>=20 > > > >>>> I think the real discussion is therefore is the > requirement to > > > >>>> monitor different components of an end to end path or is the=20 > > > >>>> requirement that such monitoring MUST be achieved using > > > nested LSPs? > > > >>>>=20 > > > >>>> As an example PW technology today allows end to end and > > > per segment > > > >>>> monitoring but it does not achieve it using nested PWs > > > or PW levels. > > > >>>>=20 > > > >>>> Ben > > > >>>>=20 > > > >>>>=20 > > > >>=20 > > > >> _______________________________________________ > > > >> mpls-tp mailing list > > > >> mpls-tp@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > > >>=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Mon Apr 20 06:25:32 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A0D3A6A03 for ; Mon, 20 Apr 2009 06:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93leKJJJJoUt for ; Mon, 20 Apr 2009 06:25:30 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id 6C4BF3A696C for ; Mon, 20 Apr 2009 06:25:29 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042006263909548 ; Mon, 20 Apr 2009 06:26:39 -0700 Received: from M00900002 ([10.84.1.19]) by s-utl02-sjpop.stsn.net; Mon, 20 Apr 2009 06:26:38 -0700 From: "Maarten Vissers" To: "'BUSI ITALO'" Date: Mon, 20 Apr 2009 15:26:31 +0200 Message-ID: <006601c9c1bb$a4319dd0$1301540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0AAGPpsAABEewwAAbNqSAAijGbIA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 13:25:32 -0000 Italo, You are right. If you look at the set of network architecture (G.803, G.872, G.8010, G.8110.1, I.326), equipment (G.806, G.705, G.783, G.798, G.8021, G.8121, I.732), interface/OAM (G.707, G.709, G.8012, G.8112, I.610, Y.1731), equipment management (G.7710, G.784, G.874, G.8051, G.8151), protection (G.841, G.842, G.873.1, G.8031, G.8032, G.8131, I.630) and info model (G.774, G.874.1, G.8052, G.8152) recommendations then all of those are = based on G.805.=20 So far there are no recommendations that have G.800 as basis, as the = most important concept in a transport network (i.e. the "transport entity") = was not present in the first version. G.800 amendment 1 has just introduced = this "transport entity" and also introduced "differentiated connection" as concepts/definitions into G.800. There is now a misalignment between definitions and text. Next step is to go through G.800 text and update = the text, including the replacement of e.g. "forwarding relationship" by "transport entity", replacement of "channel forwarding" by connection, replacement of "destination forwarding" by "differentiated connection", addition of some transport network versions of the axioms, e.g. "Axiom = 1B Transport networks are concerned with the **secure and managed** = conveyance of information between senders and receivers **which belong to one user community** when the senders and receivers are separated = geographically." and more. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of BUSI ITALO Sent: vrijdag 17 april 2009 20:29 To: neil.2.harrison@bt.com; dbrungard@att.com; benjamin.niven-jenkins@bt.com; annamaria.fulignoli@ericsson.com; = VIGOUREUX MARTIN Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Neil, G.805 is an in-force Recommendation: G.800 was never intended to replace G.805. People who worked on G.800 has always claimed that for = connection-oriented technologies G.800 defaults to G.805. When Q12/15 consented G.800, it was agreed that existing Recommendations based on G.805 (e.g. G.8110.1) will continue to be based on G.805. Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com > Sent: Friday, April 17, 2009 5:22 PM > To: dbrungard@att.com; benjamin.niven-jenkins@bt.com;=20 > annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE:Associatedbidirectional transport path requirements) >=20 > I agree with both Ben and Deborah. One further point to add here..... >=20 > G.805 is a fairly old Recommendation written largely to give us a=20 > working func arch language for the development of management=20 > information models when we were developing SONET/SDH. However, our=20 > understanding of the physics of networking has improved significantly=20 > and G.800 (Unified functional architecture of transport networks) is a = > more comprehensive embodiment of that understanding that covers all 3=20 > network modes (based on sound Info and Systems theory underpinnings). = > So G.800 should be the starting point for any references to the=20 > network func architecture for MPLS-TP and not G.805 IMO. >=20 > regards, Neil >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A,=20 > > ATTLABS > > Sent: 17 April 2009 15:59 > > To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli; Martin Vigoureux > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > Associatedbidirectional transport path requirements) > >=20 > > I agree with Ben. TCM, with the introduction of MEL as a solution,=20 > > has become architecturally confusing. When it was used in reference=20 > > to SDH, where trail overhead was overwritten, it created a tandem=20 > > connection. For cell/packet technologies where the OAM cells/packets = > > are inserted, it is not clear if this is a tandem connection or a=20 > > new server layer, as both architectural terms are used in the=20 > > standards. > >=20 > > In G803, TCM is a sublayer monitoring technique for a SDH tandem=20 > > connection: > > "Sublayer monitoring > > Connections may be directly monitored at one end of a connection by=20 > > overwriting some portion of the original trail's overhead capacity=20 > > at the beginning of the connection. > > For SDH, overhead has been defined for this purpose at the=20 > > higher-order and lower-order path layers. When applied to a SDH=20 > > tandem connection, this monitoring method is referred to as tandem=20 > > connection monitoring." > >=20 > > Whereas in Y.1711: > > "OAM techniques are applied on a per LSP basis. If a segment of a=20 > > given LSP at layer N is to be monitored for some reason (e.g., via a = > > CV or P flow say), one way to do this is by creating a new server=20 > > layer LSP (i.e., at layer N + 1) to cover the segment at layer N." > >=20 > > So I think before using TCM in reference to MPLS-TP, Q12 needs to=20 > > align on the use. For now, the requirements documents should try to=20 > > avoid it. > >=20 > > Deborah > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > Sent: Friday, April 17, 2009 10:26 AM > > To: Annamaria Fulignoli; Martin Vigoureux > > Cc: BUSI ITALO; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > > Associated bidirectional transport path requirements) > >=20 > > Because IMO use of the term TCM tends to make people think of a=20 > > particular solution and what we want to do at this stage is express=20 > > the functional requirements and not imply any particular solution. > >=20 > > Certainly most of my mails in this thread (and I am probably not the = > > only > > one) have been based on the fact that when discussing TCM I assume a = > > particular solution is being discussed. Talking purely in terms of=20 > > functional requirements removes that ambiguity. > >=20 > > Ben > >=20 > >=20 > > On 17/04/2009 12:51, "Annamaria Fulignoli" > > wrote: > >=20 > > > Hi all, > > > sorry but I do not understand why we cannot explicitly use > > the term Tandem > > > Connection in the requirements document! > > > TCM is not a solution, it is part of functional > > architecture of a transport > > > networks as described in G.805. The solution is to realize > > it with label > > > stacking rather than MEL. > > >=20 > > > Regards > > > Annamaria > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > > Martin Vigoureux > > > Sent: venerd=EC 17 aprile 2009 13.29 > > > To: Ben Niven-Jenkins > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was > > RE: Associated > > > bidirectional transport path requirements) > > >=20 > > > Ben, all > > >=20 > > > in mpls-tp-oam-requirement, the text on this item is as follows: > > >=20 > > > The service emulated by a single segment or a > > multi-segment PW may > > > span multiple domains. A LSP may also span multiple > > domains. It > > > MUST be possible to perform OAM functions on a per > > domain basis and > > > across multiple domains. More generally it MUST be > possible to > > > perform OAM functions between any two switching > > elements (e.g., LSR > > > or S-PE) of a LSP or of PW. This is referred to as > > (concatenated) > > > segment monitoring. > > >=20 > > > I believe the text describes a functional req. > > >=20 > > > During mead team review, the removal of the last sentence > > was discussed. > > > No strong opinion was expressed on whether it should > > effectively be removed or > > > not. > > >=20 > > > regards, > > > martin > > >=20 > > > Ben Niven-Jenkins a =E9crit : > > >> Italo, > > >>=20 > > >> I think we are converging. If I can be so bold as to speak on his = > > >> behalf Adrian's objection seemed to be to the use of the > term TCM. > > >>=20 > > >> It is defined in the MPLS-TP requirements but not used. > > >>=20 > > >> It is not used in the MPLS-TP OAM requirements document. > > >>=20 > > >> Therefore I think the way forward is as follows: > > >>=20 > > >> 1) Remove the term Tandem Connection from the MPLS-TP > > requirements as > > >> it is redundant (i.e. Not used in that document). > > >>=20 > > >> 2) Ensure the MPLS-TP OAM requirements express the necessary=20 > > >> functional requirements around monitoring of end to end > > paths as well > > >> as parts of end to end paths. This can be done without referring=20 > > >> explicitly to Tandem Connections. > > >>=20 > > >> When it comes to solution design we can decide what is the best=20 > > >> mechanism to achieve/implement those requirements be it > > LSP hierarchy or > > >> something else. > > >> The JWT has proved that it is possible to meet those requirements = > > >> using existing MPLS technology (maybe with some > enhancements). I do > > >> not believe we have to necessarily use the solution they propose=20 > > >> aslong as whatever solution we ultimately decide upon > meets all the > > >> necessary requirements expressed. > > >>=20 > > >> Can we agree on that as an approach and close this off for now? > > >>=20 > > >> Ben > > >>=20 > > >>=20 > > >> On 17/04/2009 10:49, "BUSI ITALO"=20 > > wrote: > > >>=20 > > >>> Ben, > > >>>=20 > > >>> I think we are mixing solutions with requirements. > > >>>=20 > > >>> The requirement for the TCM function is clearly defined and I do = > > >>> think it must be addressed by the MPLS-TP design. > > >>>=20 > > >>> The solution evaluated by the JWT to meet this > > requirement was to use > > >>> label stacking with a 1:1 relationship between the TCM > LSP and the > > >>> e2e LSP. > > >>>=20 > > >>> I think this solution, although not the best technical > option, is > > >>> good enough and meets the requirements. > > >>>=20 > > >>> However this is is a solution and has not impact on the > > requirement. > > >>>=20 > > >>> Italo > > >>>=20 > > >>>> -----Original Message----- > > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > >>>> Sent: Friday, April 17, 2009 11:22 AM > > >>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein > > >>>> Cc: mpls-tp@ietf.org; Lou Berger > > >>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp]=20 > > >>>> Associated bidirectional transport path requirements) > > >>>>=20 > > >>>> Italo, > > >>>>=20 > > >>>> On 17/04/2009 09:34, "BUSI ITALO" > > >>>> wrote: > > >>>>> The JWT agreement is to bring the ITU-T transport > > >>>> requirements in IETF > > >>>>> to extend the MPLS architecture to meet them in a way that is=20 > > >>>>> compatible, consistent and coherent with existing IETF > > architecture. > > >>>> So I took a look at the JWT report. It says (slide 16) > > >>>>=20 > > >>>> " Service Providers want LSPs/PWEs to be able to be > > managed at the > > >>>> different nested levels seamlessly (path, segment, multiple > > >>>> segments) > > >>>> aka Tandem Connection Monitoring (TCM), this is used > > for example > > >>>> when a LSP/PWE crosses multiple administrations" > > >>>>=20 > > >>>> IMO the requirement is to be able to monitor parts of a > > path as well > > >>>> as the end to end path. There are many ways to solve that=20 > > >>>> requirement, one of which is the creation of nested > LSPs, one per > > >>>> level of monitoring required (my understanding of how > TCM works). > > >>>>=20 > > >>>> I think the real discussion is therefore is the requirement to=20 > > >>>> monitor different components of an end to end path or is the=20 > > >>>> requirement that such monitoring MUST be achieved using > > nested LSPs? > > >>>>=20 > > >>>> As an example PW technology today allows end to end and > > per segment > > >>>> monitoring but it does not achieve it using nested PWs > > or PW levels. > > >>>>=20 > > >>>> Ben > > >>>>=20 > > >>>>=20 > > >>=20 > > >> _______________________________________________ > > >> mpls-tp mailing list > > >> mpls-tp@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > >>=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Mon Apr 20 07:04:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4040928C115 for ; Mon, 20 Apr 2009 07:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpwrVaMbI2Uw for ; Mon, 20 Apr 2009 07:04:15 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id D8CBF28C10B for ; Mon, 20 Apr 2009 07:04:14 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042007053009715 ; Mon, 20 Apr 2009 07:05:30 -0700 Received: from M00900002 ([10.84.1.19]) by s-utl02-sjpop.stsn.net; Mon, 20 Apr 2009 07:05:23 -0700 From: "Maarten Vissers" To: Date: Mon, 20 Apr 2009 16:05:16 +0200 Message-ID: <006701c9c1c1$0e6bbb40$1301540a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0068_01C9C1D1.D1F48B40" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C046FFEDD@E03MVB2-UKBR.domain1.systemhost.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWgABQg5yAAAjIJkACKNDyw Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 14:04:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C9C1D1.D1F48B40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity. What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get! In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Italo, > > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return > path they are disabled. > > As described in David Sinicrope's meeting minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an > MPLS TP network needs to be capable of getting IP packets from > destination to source; neither the minutes nor I stipulate that a > control plane needs to be used to instantiate this forwarding. > > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM > Framework I-D, unicast LSPs are only mentioned three times and return > paths not at all. > > Thanks, > > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path > > requirements > > > > John, > > > > I might have missed the agreement of MPLS-TP being capable of > > sending replies to OAM requests sent on uni-directional LSPs. > > > > This requirement does not belong to the first set of requirements > > ITU-T is expecting to be met by October. > > > > However, I think this in a potential interesting additional > > requirement to be taken into account (at worst in a > subsequent phase). > > > > I think that this requirement needs to be evaluated versus other > > more important requirements (e.g. the possibility to work w/o IP > > forwarding and the need for OAM to continue to monitor the data > > plane also in case of failures affecting the control or management > > plane). > > > > I am open to discuss it but not sure this is the right time because > > I wish to avoid delaying the first phase of the design solution. > > > > Thanks, Italo > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > requirements > > > > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > > > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > > > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > > > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > > > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > > > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems > > > > easy... > > > > > > > > > > > > > > > > Regards, > > > > > > > > Sasha > > > > > > > > > > > > > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Adrian, > > > > > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > > > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport > > > > path... and thus the loopback test > > > would fail. > > > > > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g. > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > > > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > > > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > > > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > > > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being > > > > monitored."? > > > > > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path". > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > > > > > > Regards, > > > > Maarten > > > > > > > > > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Hi Sasha, > > > > > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > > > > > > OK. Got it. > > > > > > > > But what is this doing in the data plane requirements section? > > > > > > > > In fact, what is this requirement actually saying? > > > > > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > > > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > > > > > > Therefore it could be assumed that this requirement is met by > > > > configuring some data plane database component through the > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > > > > > > Ben! Can we please try to rewrite this requirement in terms of > > > > behavior? > > > > > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > > > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > > > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > > > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > > > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > > > > > > Yes, but so what? > > > > > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > > > > > > > > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > > > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > > > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > > > > > > Agreed. > > > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Hi Sasha, > > > > > > > > Not really sure whether you are misrepresenting anyone, but... > > > > > > > > > 1. My reading of one of Ben's messages is that associated > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > > > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > > > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > > > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > > > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > > > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing > > > > > transport networks rather than any specific benefit. > > > > > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > > > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > > > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > > > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > > > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > > > > > > I don't see what that follows from. > > > > > > > > Cheers, > > > > Adrian > > > > > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > ------=_NextPart_000_0068_01C9C1D1.D1F48B40 Content-Type: application/vnd.ms-powerpoint; name="ethernet-ais-01.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ethernet-ais-01.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA5AAAAAAAAAAA EAAAtQAAAAEAAAD+////AAAAAOYAAADlAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////4wAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA ZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABz AAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAACAAAAA/f///1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAGCk04u+wckB tgAAAEADAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAvWMBAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALcAAAAkVQAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOgCAAAAAAAADwDo Aw8mAAABAOkDKAAAAEIaAACwEwAA4BAAAIAWAAAFAAAACgAAAAUAAAAsAAAAAQAGAAAAAAEPAPID 3gIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVBxQCAAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3 ACAAUgBvAG0AYQBuAAAAVKkTAFSpEwAooYQF3JYTAHg6CzDclhMAAAAAAA8A1QcAAAYiEAC3D0QA AABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAFSpEwBUqRMAKKGEBdyWEwB4Ogsw3JYT AAAAAAAPANUHgAAGIiAAtw9EAAAAi1tTTwAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABUqRMA VKkTACihhAXclhMAeDoLMNyWEwAAAAAADwDVB4YABgIwALcPRAAAAFcAaQBuAGcAZABpAG4AZwBz AAAAAABvAG0AYQBuAAAAVKkTAFSpEwAooYQF3JYTAHg6CzDclhMAAAAAAA8A1QcCAAYCQAC3D0QA AABUAHIAZQBiAHUAYwBoAGUAdAAgAE0AUwAAAGEAbgAAAFSpEwBUqRMAKKGEBdyWEwB4Ogsw3JYT AAAAAAAPANUHAAAGIlAAtw9EAAAARgB1AHQAdQByAGEAQQAgAEIAawAgAEIAVAAAAG4AAABUqRMA VKkTACihhAXclhMAeDoLMNyWEwAAAAAADwDVBwAEBiJgALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAAVKkTAFSpEwAooYQF3JYTAHg6CzDclhMAAAAAAA8A1QcAAAYSAACkDwoA AACBAEIAAQAAABkAAAClDwwAAAAAAAAILgAAAAIAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//xgA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BEAWAAAPAADwOBYAAAAABvC4FQAAgdQKALYCAAA/AQAABAAAAAAAAAAPAAAAAAAAABYAAAALAAAA CAAAAAAAAAAEAAAAAAAAABAAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAE AAAAAAAAAA0AAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAgA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABQAA AAAAAAAFAAAAAAAAAAQAAAAAAAAAHgAAAAAAAAAMAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAA AAAAAAUAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAoAAAAA AAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABgAAAAAAAAARAAAALgAAAAYAAAAvAAAACAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAkAAAAAAAAABAAAAAAAAABjAAAAAAAAAAQAAAAAAAAAlQAAAAAAAAAIAAAAAAAAAAcAAAAAAAAA CAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAIAAAAAAAAADsAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAIAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAA AAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABAAAAF4AAAAMAAAAAAAAAAcAAAAA AAAABwAAAAAAAAAjAAAAAAAAAAcAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABwAAAAAA AAAHAAAAAAAAAAcAAAAAAAAACwAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAIAAAAAAAA AAQAAAAAAAAABwAAAAAAAAAIAAAAAAAAAAoAAAAAAAAACAAAAAAAAAAIAAAAAAAAAD8AAAAAAAAA PQAAAAAAAABvAAAAAAAAAAQAAAAAAAAABgAAAAAAAACZAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAE AAAAAAAAAEAAAAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAPwAAAAAAAAAGAAAAAAAAAAgA AAAAAAAABQAAAAAAAACIAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAB4AAAAAAAAABAAAAAAAAAA2AAAAAAAAAAQAAAAAAAAANwAAAAAAAAAEAAAA AAAAADcAAAAAAAAABAAAAAAAAAA8AAAAAAAAAEYAAAAAAAAAMwAAAAAAAABIAAAAAAAAADgAAAAA AAAASAAAAAAAAABZAQAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAA AAAHAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABgAAAAAAAAAGAAAAAAAA ACQAAAAAAAAABgAAAAAAAAAIAAAAAAAAABIAAAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAABoAAAAAAAAAHQAAAAAAAAAR AAAAAAAAAAQAAAAAAAAARgAAAAAAAAAcAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAyAAAAAAAAADAA AAAAAAAAKgAAAAAAAAA3AAAAAAAAADMAAAAAAAAAUwAAAAAAAABIAAAAAAAAAO0AAAAAAAAAPgEA AAAAAAAFAAAAAAAAAEcAAAAAAAAABAAAAAAAAACDAAAAAAAAAAQAAAAAAAAA2AEAAAAAAAAEAAAA AAAAAAQAAAAAAAAACAAAAAAAAACcAAAAAAAAAKwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAGAAAAAAAAAAQAAAAAAAAALgAAAAAA AAAEAAAAAAAAAJMAAAAAAAAAfwAAAAAAAABWAAAAAAAAADYAAAAAAAAAkwAAAAAAAABkAAAAAAAA AB4AAAAAAAAAUAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAJAAAAAAAAAAQAAAAAAAAA BgAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABAAAAAAAAACMAAAAAAAAADkAAAAAAAAAKAAAAAAAAAAj AAAAAAAAAAgAAAAAAAAABAAAAAAAAAAMAQAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAACkAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAGsAAAAAAAAASwAA AAAAAABVAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAaAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAFAAAAAA AAAAhAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABQAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAABwAAAAAAAAASwAAAAAAAABVAAAAAAAAAEwAAAAAAAAA xAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAKMAAAAAAAAABAAAAAAAAAA5 AAAAAAAAAAUAAAAAAAAACAAAAAAAAAAHAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAQA AAAAAAAAPAAAAAAAAAAvAAAAAAAAACwAAAAAAAAADgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABgAA AAAAAADPAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAIAAAA AAAAANEAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAA4AAAAAAAAAAQAAAAAAAAABAAAAAAAAABxAAAAAAAAAAQAAAAAAAAACAAAAAAA AAAIAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAIAAAAAAAAAPYAAAAAAAAABgAAAAAAAAAEAAAAAAAA AD0AAAAAAAAABAAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAC8AAAAAAAAAAQAAAAAAAAABgAAAAAAAAAdAQAAAAAAAAgAAAAAAAAABAAAAAAAAAA5 AQAAAAAAAE0AAAAAAAAADQEAAAAAAACmAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYA AAAAAAAAUwEAAAAAAAAEAAAAAAAAAAUAAAAAAAAACAAAAAAAAADOAAAAAAAAAKsAAAAAAAAA6QAA AAAAAABaAAAAAAAAAFoAAAAAAAAAcgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAxQAAAAAAAAAGAAAA AAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAA AAAA4AEAAAAAAAAEAAAAAAAAAAYAAAAAAAAAbAAAAAAAAAC2AQAAAAAAAGoAAAAAAAAABgAAAAAA AAAGAAAAAAAAAAYAAAAAAAAAlQAAAAAAAAAEAAAAAAAAAKMAAAAAAAAAnwAAAAAAAACeAAAAAAAA AKEAAAAAAAAAvwAAAAAAAAAGAAAAAAAAAAUAAAAAAAAABAAAAAAAAAClAAAAAAAAAAQAAAAAAAAA VwAAAAAAAACdAAAAAAAAAAQAAAAAAAAAlQAAAAAAAAAEAAAAAAAAAHsAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAARwAAAAAAAADKAAAAAAAAAIIAAAAAAAAAYwAAAAAAAACPAAAAAAAAAE8A AAAAAAAAcAAAAAAAAABNAAAAAAAAADgAAAAAAAAAbwAAAAAAAACnAAAAAAAAAAQAAAAAAAAAaQAA AAAAAADHAAAAAAAAAGsAAAAAAAAAlQAAAAAAAACxAAAAAAAAADUAAAAAAAAAewAAAAAAAACQAAAA AAAAAEkAAAAAAAAAKgAAAAAAAAAEAAAAAAAAADMAAAAAAAAALgAAAAAAAAA6AAAAAAAAAGUAAAAA AAAATwAAAAAAAADhAAAAAAAAAAcAAAAAAAAAOwAAAAAAAABHAAAAAAAAALQAAAAAAAAASwAAAAAA AABOAAAAAAAAAAYAAAAAAAAABgAAAAAAAABLAAAAAAAAABIAAAAAAAAABAAAAAAAAAAGAAAAAAAA AAQAAAAAAAAABQAAAAAAAAARAAAAAAAAABYAAAAAAAAABQAAAAAAAAAIAAAAAAAAACwAAAAAAAAA BAAAAAAAAAA5AAAAAAAAAAQAAAAAAAAAXQAAAAAAAABWAAAAAAAAAAQAAAAAAAAAFgAAAAAAAAAE AAAAAAAAANQAAAAAAAAALAEAAAAAAAAcAAAAAAAAAFwAAAAAAAAABAAAAAAAAABcAAAAAAAAAAYA AAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAAbQAAAAAAAAA4AAAAAAAAAAQAAAAAAAAAFgAA AAAAAAAEAAAAAAAAAAQAAAAAAAAAgQAAAAAAAABaAAAAAAAAAF0AAAAAAAAAgAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAFwAAAAAAAAAWAAAAAAAAAA4AAAAA AAAAFwAAAAAAAAA8AAAAAAAAACwAAAAAAAAAHAAAAAAAAABEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAABoAAAAAAAAAJgAAAAAAAAAaAAAAAAAAACsAAAAAAAAAZAAAAAAAAAAEAAAAAAAA ABoAAAAAAAAAJwAAAAAAAABAAAAAAAAAAAQAAAAAAAAAbwAAAAAAAABaAAAAAAAAAAQAAAAAAAAA bAAAAAAAAABAAAAAAAAAAIwAAAAAAAAAWgAAAAAAAABFAAAAAAAAAIMAAAAAAAAASwAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAABbAAAAAAAAAHcAAAAAAAAABgAAAAAAAAAIAAAAAAAAAGMA AAAAAAAAVwAAAAAAAAAEAAAAAAAAAH0AAAAAAAAAMQAAAAAAAAAyAAAAAAAAAAQAAAAAAAAAQwAA AAAAAAAEAAAAAAAAADQAAAAAAAAABAAAAAAAAAAlAAAAAAAAACsAAAAAAAAARQAAAAAAAAAEAAAA AAAAADYAAAAAAAAAQQAAAAAAAAAkAAAAAAAAACQAAAAAAAAABgAAAAAAAAAIAAAAAAAAAAYAAAAA AAAAWAAAAAAAAABYAAAAAAAAAH4AAAAAAAAAgAAAAAAAAABAAAAAAAAAAFgAAAAAAAAAQAAAAAAA AABOAAAAAAAAAGgAAAAAAAAALwAAAAAAAABkAAAAAAAAAAQAAAAAAAAACwAAAAAAAAALAAAAAAAA AEYAAAAAAAAANgAAAAAAAAA+AAAAAAAAAD4AAAAAAAAA1gAAAAAAAAAEAAAAAAAAAFoAAAAAAAAA hwAAAAAAAACZAAAAAAAAALIAAAAAAAAAFAEAAAAAAABWAAAAAAAAAAQAAAAAAAAABAAAAAAAAABB AAAAAAAAAFcAAAAAAAAABAAAAAAAAABRAAAAAAAAAFwAAAAAAAAAYgAAAAAAAABWAAAAAAAAAHcA AAAAAAAAMQAAAAAAAABIAAAAAAAAADkAAAAAAAAAoQAAAAAAAAC6AAAAAAAAAK4AAAAAAAAAQwAA AAAAAAA+AAAAAAAAAEAAAAAAAAAABAAAAAAAAAA4AAAAAAAAADgAAAAAAAAALwAAAAAAAAA7AAAA AAAAAHEAAAAAAAAABAAAAAAAAABeAAAAAAAAAHgAAAAAAAAAlwAAAAAAAACKAAAAAAAAAHoAAAAA AAAAnQAAAAAAAAArAQAAOAIAAEIBAAAAAAAAPgAAAAAAAAAmAAAAAAAAACYAAAAAAAAAGAAAAAAA AABLAAAAAAAAAEAAAAAAAAAAOgAAAAAAAAA7AAAAAAAAAFcAAAAAAAAAQwAAAAAAAAAcAAAAAAAA AC0AAAAAAAAAIQAAAAAAAABGAAAAAAAAABsAAAAAAAAAGAAAAAAAAAAYAAAAAAAAAB8AAAAAAAAA OAAAAAAAAAA4AAAAAAAAABYAAAAAAAAAKgAAAAAAAAAnAAAAAAAAACIAAAAAAAAAIwAAAAAAAAAj AAAAAAAAAAQAAAAAAAAAUAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAABQAAAAAAAAAAUA AAAAAAAAXwAAAAAAAAAvAAAAAAAAACgAAAAAAAAALgAAAAAAAAAEAAAAAAAAAFEAAAAAAAAAaQAA AAAAAABYAAAAAAAAAFoAAAAAAAAAGwAAAAAAAABdAAAAAAAAAPYAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAQAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAF4AAAAA AAAABAAAAAAAAADMAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAA AAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAMAAAAAAAAABAAAAAAAAABCAAAAAAAA AAQAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAB8AAAAAAAAA BAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAyAAAAAAAAAA4AAAAAAAAAAcAAAAAAAAAgQAAAIMAC/Aw AAAAgQEEAAAIgwEAAAAIhkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIgAAa8SAA AAAAM8wA/wAAAMz/mQD/zAAAlpaWAE1NTQBm/zMAAIAAAEAAHvEQAAAAlpaWAP8AAAD///////// /x8A8A8cAAAAAADzAxQAAABAAAAAAAAAAAAAAAADAACAAAAAAA8A0AdwCwAAHwAUBBwAAAAAABUE FAAAACT6SgkAypo7BcDfIwDKmjsAAgAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQwAAAGQA AABDAAAAZAAAAAAAAAC80oQF9JYTAHg6CzAAAAAAAAAAAEL6//+O////AQATAHAA+wMIAAAAAAAA ANgJAABwAPsDCAAAAAEAAAAhDQAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8A+gNHAAAA AAD+AwMAAAAAAQAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAABAAAAlP2EBfSWEwB4OgswAAAAAAAA AAAAAAAAAAAAAAEAEwAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAACCXEwAS9AowVKkT AAShhAUAAAAAAAAAAAAAAAAAAAAAAAETAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAA IJcTABL0CjBUqRMABKGEBQAAAAAAAAAAAAAAAAAAAAAAABMADwCIE+IJAAAPAIoTaAAAAAAAug8U AAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8AiBc8AAAAAACJFzQAAAAAAAAAAAAAAAAA AABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAACI2QAAAAAAAAAAAACAAgHgDwCKE/gIAAAAALoPFgAA AF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT0ggAAEAAGhBmBQAABQAAAAAIDAEAAAAAAAIAAAEM AAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAA AAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5h bWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAA AAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAA AAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAA AAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAA AQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAA AAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkA cABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAA AQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAED AAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAA AAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5 AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEA AAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAI AAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAA AAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBp AGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIA YQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAABwQ FAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgA AAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAA AQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkA YQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBh AHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBA AgAAEACvDwgAAAAAAQAABQAAAAAAGRAoAgAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAA AAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAAB AgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAE AAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8A dAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAA AAAABAAAAA4ACQARAAAAGgABAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAA AAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAA AAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMA AAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAg AFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4A CQARAAAAGgABDwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAADQQIAAAA cLUAAHC1AAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAC8AyA8MAAAAMADS DwQAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAAJQBPANkPDAAAAAAA2g8EAAAADQA9AA8A8A/dAAAA AADzAxQAAAC4AQAABAAAAAEAAAB8AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA9FAAAARVZDIGRpZmZl cmVudGlhdGVkIGNvbm5lY3Rpb25zLCBFVkMtQUlTIGFuZCBFVkMtTE9DIGFsYXJtIHN1cHByZXNz aW9uAAChD0QAAABGAAAAAAAAAAAAJAAAAAAAAgAgAAMAAAAAAAYAIAD/AAD+CQAAAAAAAgAgAAMA AAAAAAYAIAAAM8z+EwAAAAAAAgAgAAAAqg8UAAAARQAAAAYAAAAJCAAAAQAAAAAAAAAAAOoDAAAA AA8A+ANBCAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAACzBgAPAHIAAAAP///wAAAAAA gICAAAAAAAC74OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDM MwAAmWYAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN72 8QAAAAAAlpaWAAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3 ADPMzAD/UFAA/5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAH IAAAAIAAAAD///8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM //8AM2bMAACwAABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDl AABgAPAHIAAAAGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA//// AD4+XAD///8AYFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8A zLQAAIyeoAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD/ /+8AAQAAAAIAAAD//yMAmQAA/gAAEACjD5YAAAAFAP/9PwAAACIgAABkAAAAAP8AAGQARgAAAAAA AABAAgAAAAAHAAAA///vAAEAAAACAAAA//8ZAAAAAAEAALM1AAADAHEAAwAAAAABVQAjACcCIAEB AAIAAAAWAIA1AADYAGQAFABdA5ECAAACABQAsgUAAAEAEyAAAAAAAP+0BM4DAABAAP//gAUAALsA CwYlBQAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAcAAAD/ /+8AAAAAAAIAAAD//wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAA AAUAAIAEgAQAAAAAUACjD04AAAAFAAAAAAgAAAEAAAAAAAEAAQkAAAIAAQAgAQAAAAACAAEJAAAC AAEAkQIAAAAAAwABCQAAAAABAM4DAAAAAAQAAQkAAAAAAQAlBQAAAABgAKMPDAAAAAEAAAAAAAAA AAAAAHAAow8+AAAABQAAAAAAAAAAAAIAFgABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAA AAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABMAAQAAAAAAAAACABIAAgAAAAAA AAACABAAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBPACAAAPAALw6AIAAOAFCPAIAAAAAwAA AAt4AQAPAAPwgAIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAeAEA BQAAAA8ABPD+AAAAEgAK8AgAAAACeAEAAAoAAOMAC/BUAAAAfwABAAUAgAC4GoQFgQDyZAEAggB7 sgAAgwDyZAEAhAB7sgAAhwABAAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIEwAi8QYAAAC/AwAAAAQAABDwCAAAABkAUAHyGJQCDwAR8BAAAAAAAMMLCAAAAAAAAAAB AIQFDwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxl IHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwQgEAABIACvAIAAAAA3gB AAAKAADTAAvwTgAAAH8AAQAFAIAAaHOEBYEA8mQBAIIAe7IAAIMA8mQBAIQAe7IAAL8AEAAfAIEB BAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACBMAIvEGAAAAvwMAAAAEAAAQ8AgAAACY BFAB8hiWEQ8AEfAQAAAAAADDCwgAAAABAAAAAgCEBQ8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IA AABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2 ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAA AwAMAAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATwSAAAABIACvAIAAAAAXgBAAAMAACDAAvwMAAA AIEBAAAACIMBBQAACJMBFe2iAJQBti56AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA ////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTnQAAAA8AihOVAAAAAAC6DxAAAABf AF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOouBAAAAAEAAAAAAOsuCAAAAEvNyAHwmxKwAAAAKwQA AAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB/FP////8SAAAADwA9 8Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAgALoPJAAAAGgAdQBhAHcAZQBpAC0AdABlAG0AcABs AGEAdABlAC0AbQB2AA8A8AMoBgAAAQDxAwgAAAADAACAAAALMA8ADASoBQAADwAC8KAFAACwAAjw CAAAAAcAAAAHDAAADwAD8DgFAAAPAATwKAAAAAEACfAQAAAAAQAAAAIAAAAAAAAAAAAAAAIACvAI AAAAAAwAAAUAAAAPAATw1AAAABIACvAIAAAAAgwAAAAKAABzAAvwKgAAAH8AAQABAIAAXBBeD4EB BAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAAAEPAIAAAAAAAAAFAHIAEPABHwEAAAAAAAwwsI AAAAAAAAAAoCXg8PAA3wYgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAA AAACAAAAAAACAAwAAAD5DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJ BAQIDwAE8NYAAAASAArwCAAAAAMMAAAACgAAcwAL8CoAAAB/AAEAAQCAAABYXg+BAQQAAAiDAQAA AAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAAAAkAngECABDwAR8BAAAAAAAMMLCAAAAAEAAAAH AF4PDwAN8GQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAA AAACAAwAAAD4DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQIDwAE 8GQAAAASAArwCAAAAAQMAAAACgAAYwAL8CQAAAB/AAQABACHAAEAAAB/AQAAAQC/AREAEQD/AQgA CQA/AgEAAQAAABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAF4PDwAE8BQBAAAS AArwCAAAAAUMAAAACgAAcwAL8CoAAAB/AAEAAQCAANxbXg+BAQQAAAiDAQAAAAi/AQEAEQDAAQEA AAj/AQEACQAAABDwCAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAMAAAAGAl4PDwAN8KIAAAAA AJ8PBAAAAAIAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29u ZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAA AA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8OAAAAUwAAAAcAAAAAAAkEBAgPAATw2gAAABIA CvAIAAAABgwAAAAKAACDAAvwMAAAAH8AAQABAIAAfF9eD4cAAgAAAIEBBAAACIMBAAAACL8BAQAR AMABAQAACP8BAQAJAAAAEPAIAAAAYBUAAFAHgBYPABHwEAAAAAAAwwsIAAAABAAAAAkCXg8PAA3w YgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD6 DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQIDwAE8NwAAAASAArw CAAAAAcMAAAACgAAgwAL8DAAAAB/AAEAAQCAAHyHXg+HAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQAAABDwCAAAAGAVkAngEIAWDwAR8BAAAAAAAMMLCAAAAAUAAAAIAl4PDwAN8GQA AAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADY DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQIDwAE8EgAAAASAArw CAAAAAEMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgA AAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACwpnIAgCSq cw8AyQ+gBAAADwAMBDAEAAAPAALwKAQAAOACCPAIAAAABQAAAAWwAAAPAAPwwAMAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAsAAABQAAAA8ABPDYAAAAEgAK8AgAAAAC sAAAAAoAAIMAC/AwAAAAfwABAAUAgAAIC14PgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIAAAQ8AgAAAAAAAAAUAcgAQ8AEfAQAAAAAADDCwgAAAAAAAAACgJeDw8ADfBgAAAAAACf DwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPkPBAAAAAAA AAAAAKoPGgAAAAEAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIDwAE8NoAAAASAArwCAAAAAOwAAAA CgAAgwAL8DAAAAB/AAEABQCAACwKXg+BAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAAAAjwnfECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAl4PDwAN8GIAAAAAAJ8PBAAA AAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAAAAAA AACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECA8ABPDeAAAAEgAK8AgAAAAEsAAAAAoA AJMAC/A2AAAAfwABAAUAgACIfF4PhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIAAAQ8AgAAABfFQAAUAd/Fg8AEfAQAAAAAADDCwgAAAACAAAACQJeDw8ADfBgAAAAAACf DwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPoPBAAAAAAA AAAAAKoPGgAAAAEAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIDwAE8OAAAAASAArwCAAAAAWwAAAA CgAAkwAL8DYAAAB/AAEABQCAANjyWQ+HAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA CQABAgIAAAgAABDwCAAAAF8VjwnfEH8WDwAR8BAAAAAAAMMLCAAAAAMAAAAIAl4PDwAN8GIAAAAA AJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADYDwQA AAAAAAAAAACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECA8ABPBIAAAAEgAK8AgAAAAB sAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCK EzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAXGvGAXDPjTQPAO4D KSoBAAIA7wMYAAAABwAAAA0AAAAAAAAAAwAAgAAAAAAHAAswAAD5AxAAAAAAAAAAAAAAAAIAAQAC 3EwwDwAMBJMeAQAPAALwix4BAIAjCPAIAAAAKQEAAEGNCQDQABjxNAAAAAEAAAACAAAAAwACAAQA AAAFAAQABgAAAAcABgAIAAAACQAAAAoACQALAAkADAAJAA0AAAAPAAPwvx0BAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAjAkABQAAAA8AA/CMBgAADwAE8EwAAAABAAnw EAAAALABAACsAwAAcBQAAAAPAAACAArwCAAAAAKMCQABAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAA ABDwCAAAAFoE9wHZF5IRDwAE8KIAAAAiAArwCAAAAAOMCQACCgAAMwEL8HIAAACFAAIAAACHAAEA AAC/AAAADwAMAfMDMxCBAd3d3QC/ARwAHgDAAQIAAAjLAZ9vAADOAQoAAAD/AQ4ADgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAKAI AAB1BgAAQA4AAOULAAAPAATwogAAACIACvAIAAAABIwJAAIKAAAzAQvwcgAAAIUAAgAAAIcAAQAA AL8AAAAPAAwB8wMzEIEB3d3dAL8BHAAeAMABAgAACMsBn28AAM4BCgAAAP8BDgAOAAACBQAAAAEC 8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAQAgA ACAHAADgDQAAkAwAAA8ABPCiAAAAIgAK8AgAAAAFjAkAAgoAADMBC/ByAAAAhQACAAAAhwABAAAA vwAAAA8ADAHzAzMQgQHd3d0AvwEcAB4AwAGysrIAywGfbwAAzgEJAAAA/wEGAA4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAACwAQAA kAkAAFAHAAAADwAADwAE8KIAAAAiAArwCAAAAAaMCQACCgAAMwEL8HIAAACFAAIAAACHAAEAAAC/ AAAADwAMAfMDMxCBAd3d3QC/ARwAHgDAAbKysgDLAZ9vAADOAQkAAAD/AQYADgAAAgUAAAABAvEB mRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAALABAADA AwAAUAcAADAJAAAPAATwogAAACIACvAIAAAAB4wJAMIKAAAzAQvwcgAAAIUAAgAAAIcAAQAAAL8A AAAPAAwB8wMzEIEB3d3dAL8BHAAeAMABsrKyAMsBn28AAM4BCQAAAP8BBgAOAAACBQAAAAEC8QGZ EAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAA0A4AAJAJ AABwFAAAAA8AAA8ABPCiAAAAIgAK8AgAAAAIjAkAwgoAADMBC/ByAAAAhQACAAAAhwABAAAAvwAA AA8ADAHzAzMQgQHd3d0AvwEcAB4AwAGysrIAywGfbwAAzgEJAAAA/wEGAA4AAAIFAAAAAQLxAZkQ AgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAADQDgAArAMA AHAUAAAcCQAADwAE8BYBAACiDArwCAAAAAmMCQACCgAAEwEL8GYAAACAANzFhAWBALKgAQCCAFnQ AACDALKgAQCEAFnQAACFAAIAAACHAAYAAAC/ABIAHwCBAd3d3QC/AQwAHgDAAQEAAAj/AQYADgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAPAJAABgBgAA+Q0AADYHAAAPAA3w eAAAAAAAnw8EAAAABAAAAAAAqA8OAAAAQ29yZSBCIChQLU9UTikAAKEPHAAAAA8AAAAAABAAAAAF AA8AAAABAEMAAQAEAAQAEwAAAKoPDAAAAA8AAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaAC oALwA/ADQAVABQ8ABPAWAQAAogwK8AgAAAAKjAkAAgoAABMBC/BmAAAAgADYjIQFgQCyoAEAggBZ 0AAAgwCyoAEAhABZ0AAAhQACAAAAhwAGAAAAvwASAB8AgQHd3d0AvwEMAB4AwAEBAAAI/wEGAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAACQAAgAcAAA4NAABXCAAADwAN 8HgAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAENvcmUgQSAoUC1PVE4pAAChDxwAAAAPAAAAAAAQAAAA BQAPAAAAAQBDAAEABAAEABMAAACqDwwAAAAPAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGg AqAC8APwA0AFQAUPAAPwqBoAAA8ABPCAAAAAAQAJ8BAAAACQAwAA4AQAAMASAADgDQAAAgAK8AgA AAALjAkAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAACwBSgE4hUwEA8AEfAsAAAADwAU ECQAAAABAPEPHAAAAAAAAAcERAAAAAAAAAAAAAACAAEAAQAAAgAACzAPAAPwWAIAAA8ABPBUAAAA AQAJ8BAAAACwCgAA0AIAAAAMAABQBAAAAgAK8AgAAAAMjAkAAwIAACMAC/AMAAAABAAAAAAAiAMA AAAAAAAP8BAAAACQCQAAQAgAAOAKAADACQAADwAE8FABAAASAArwCAAAAA2MCQACCgAAcwEL8IoA AAB/AAAABACAAMjXRQWBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABAAHwAMAfMDMxCB AZlmAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAD/AQAAAAsAoAANACAAAA DAAAUAQAAA8ADfCAAAAAAACfDwQAAAAEAAAAAACoDwIAAABWUAAAoQ8oAAAAAwAAAAAAFlgAAAYA BgABAFoAkP8DAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkIAAAA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwnAAAADIACvAIAAAADowJAAIKAAAjAQvw bAAAAAQAAACm/4UAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEIEBzP+ZAL8BHAAeAMABAQAACP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAA D/AQAAAAKAsAAEkDAACICwAAOQQAAA8AA/BYAgAADwAE8FQAAAABAAnwEAAAALAKAADQAgAAAAwA AFAEAAACAArwCAAAAA+MCQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAFAKAACACgAA oAsAAAAMAAAPAATwUAEAABIACvAIAAAAEIwJAAIKAABzAQvwigAAAH8AAAAEAIAAhPj1BIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBmWYAAL8BHAAeAMABAQAACMsB akoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAAAACwCgAA0AIAAAAMAABQBAAADwAN8IAAAAAAAJ8P BAAAAAQAAAAAAKgPAgAAAFZQAAChDygAAAADAAAAAAAWWAAABgAGAAEAWgCQ/wMAAAABAEcAAQAE AAQAEAAAAAAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaAC oALwA/ADQAVABQ8ABPCcAAAAMgAK8AgAAAARjAkAAgoAACMBC/BsAAAABAAAAKb/hQACAAAAhwAB AAAAvwAAAA8ADAHzAzMQgQHM/5kAvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQ BQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAoCwAASQMAAIgLAAA5 BAAADwAD8FgCAAAPAATwVAAAAAEACfAQAAAAsAoAANACAAAADAAAUAQAAAIACvAIAAAAEowJAAMC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAAoAsAAKAIAADwDAAAIAoAAA8ABPBQAQAAEgAK 8AgAAAATjAkAAgoAAHMBC/CKAAAAfwAAAAQAgADA/AAFgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hQACAAAAvwAQAB8ADAHzAzMQgQGZZgAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCC AIIAAA/wEAAAALAKAADQAgAAAAwAAFAEAAAPAA3wgAAAAAAAnw8EAAAABAAAAAAAqA8CAAAAVlAA AKEPKAAAAAMAAAAAABZYAAAGAAYAAQBaAJD/AwAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAIA AAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8JwAAAAy AArwCAAAABSMCQACCgAAIwEL8GwAAAAEAAAApv+FAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAcz/ mQC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAACgLAABJAwAAiAsAADkEAAAPAAPwWAIAAA8ABPBUAAAA AQAJ8BAAAACwCgAA0AIAAAAMAABQBAAAAgAK8AgAAAAVjAkAAwIAACMAC/AMAAAABAAAAAAAiAMA AAAAAAAP8BAAAACQAwAA4AQAAOAEAABgBgAADwAE8FABAAASAArwCAAAABaMCQACCgAAcwEL8IoA AAB/AAAABACAAHAPAAWBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABAAHwAMAfMDMxCB AZlmAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAD/AQAAAAsAoAANACAAAA DAAAUAQAAA8ADfCAAAAAAACfDwQAAAAEAAAAAACoDwIAAABWUAAAoQ8oAAAAAwAAAAAAFlgAAAYA BgABAFoAkP8DAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkIAAAA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwnAAAADIACvAIAAAAF4wJAAIKAAAjAQvw bAAAAAQAAACm/4UAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEIEBzP+ZAL8BHAAeAMABAQAACP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAA D/AQAAAAKAsAAEkDAACICwAAOQQAAA8AA/BYAgAADwAE8FQAAAABAAnwEAAAALAKAADQAgAAAAwA AFAEAAACAArwCAAAABiMCQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAACAEAADABgAA cAUAAEAIAAAPAATwUAEAABIACvAIAAAAGYwJAAIKAABzAQvwigAAAH8AAAAEAIAAgPfbBIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBmWYAAL8BHAAeAMABAQAACMsB akoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAAAACwCgAA0AIAAAAMAABQBAAADwAN8IAAAAAAAJ8P BAAAAAQAAAAAAKgPAgAAAFZQAAChDygAAAADAAAAAAAWWAAABgAGAAEAWgCQ/wMAAAABAEcAAQAE AAQAEAAAAAAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaAC oALwA/ADQAVABQ8ABPCcAAAAMgAK8AgAAAAajAkAAgoAACMBC/BsAAAABAAAAKb/hQACAAAAhwAB AAAAvwAAAA8ADAHzAzMQgQHM/5kAvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQ BQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAoCwAASQMAAIgLAAA5 BAAADwAD8FgCAAAPAATwVAAAAAEACfAQAAAAsAoAANACAAAADAAAUAQAAAIACvAIAAAAG4wJAAMC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAAkAMAAFAKAADgBAAA0AsAAA8ABPBQAQAAEgAK 8AgAAAAcjAkAAgoAAHMBC/CKAAAAfwAAAAQAgADs39sEgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hQACAAAAvwAQAB8ADAHzAzMQgQGZZgAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCC AIIAAA/wEAAAALAKAADQAgAAAAwAAFAEAAAPAA3wgAAAAAAAnw8EAAAABAAAAAAAqA8CAAAAVlAA AKEPKAAAAAMAAAAAABZYAAAGAAYAAQBaAJD/AwAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAIA AAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8JwAAAAy AArwCAAAAB2MCQACCgAAIwEL8GwAAAAEAAAApv+FAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAcz/ mQC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAACgLAABJAwAAiAsAADkEAAAPAAPwWAIAAA8ABPBUAAAA AQAJ8BAAAACwCgAA0AIAAAAMAABQBAAAAgAK8AgAAAAejAkAAwIAACMAC/AMAAAABAAAAAAAiAMA AAAAAAAP8BAAAAAgBAAAMAwAAHAFAACwDQAADwAE8FABAAASAArwCAAAAB+MCQACCgAAcwEL8IoA AAB/AAAABACAAHjm2wSBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABAAHwAMAfMDMxCB AZlmAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAD/AQAAAAsAoAANACAAAA DAAAUAQAAA8ADfCAAAAAAACfDwQAAAAEAAAAAACoDwIAAABWUAAAoQ8oAAAAAwAAAAAAFlgAAAYA BgABAFoAkP8DAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkIAAAA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwnAAAADIACvAIAAAAIIwJAAIKAAAjAQvw bAAAAAQAAACm/4UAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEIEBzP+ZAL8BHAAeAMABAQAACP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAA D/AQAAAAKAsAAEkDAACICwAAOQQAAA8AA/BYAgAADwAE8FQAAAABAAnwEAAAALAKAADQAgAAAAwA AFAEAAACAArwCAAAACGMCQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAOAQAAAQBQAA MBIAAJAGAAAPAATwUAEAABIACvAIAAAAIowJAAIKAABzAQvwigAAAH8AAAAEAIAALMrbBIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBmWYAAL8BHAAeAMABAQAACMsB akoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAAAACwCgAA0AIAAAAMAABQBAAADwAN8IAAAAAAAJ8P BAAAAAQAAAAAAKgPAgAAAFZQAAChDygAAAADAAAAAAAWWAAABgAGAAEAWgCQ/wMAAAABAEcAAQAE AAQAEAAAAAAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaAC oALwA/ADQAVABQ8ABPCcAAAAMgAK8AgAAAAjjAkAAgoAACMBC/BsAAAABAAAAKb/hQACAAAAhwAB AAAAvwAAAA8ADAHzAzMQgQHM/5kAvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQ BQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAoCwAASQMAAIgLAAA5 BAAADwAD8FgCAAAPAATwVAAAAAEACfAQAAAAsAoAANACAAAADAAAUAQAAAIACvAIAAAAJIwJAAMC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAAcBEAAPAGAADAEgAAcAgAAA8ABPBQAQAAEgAK 8AgAAAAljAkAAgoAAHMBC/CKAAAAfwAAAAQAgADQ1NsEgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hQACAAAAvwAQAB8ADAHzAzMQgQGZZgAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCC AIIAAA/wEAAAALAKAADQAgAAAAwAAFAEAAAPAA3wgAAAAAAAnw8EAAAABAAAAAAAqA8CAAAAVlAA AKEPKAAAAAMAAAAAABZYAAAGAAYAAQBaAJD/AwAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAIA AAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8JwAAAAy AArwCAAAACaMCQACCgAAIwEL8GwAAAAEAAAApv+FAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAcz/ mQC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAACgLAABJAwAAiAsAADkEAAAPAAPwWAIAAA8ABPBUAAAA AQAJ8BAAAACwCgAA0AIAAAAMAABQBAAAAgAK8AgAAAAnjAkAAwIAACMAC/AMAAAABAAAAAAAiAMA AAAAAAAP8BAAAACwEAAAgAoAAAASAAAADAAADwAE8FABAAASAArwCAAAACiMCQACCgAAcwEL8IoA AAB/AAAABACAAGSg2wSBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABAAHwAMAfMDMxCB AZlmAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAD/AQAAAAsAoAANACAAAA DAAAUAQAAA8ADfCAAAAAAACfDwQAAAAEAAAAAACoDwIAAABWUAAAoQ8oAAAAAwAAAAAAFlgAAAYA BgABAFoAkP8DAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkIAAAA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwnAAAADIACvAIAAAAKYwJAAIKAAAjAQvw bAAAAAQAAACm/4UAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEIEBzP+ZAL8BHAAeAMABAQAACP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAA D/AQAAAAKAsAAEkDAACICwAAOQQAAA8AA/BYAgAADwAE8FQAAAABAAnwEAAAALAKAADQAgAAAAwA AFAEAAACAArwCAAAACqMCQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAEARAABgDAAA kBIAAOANAAAPAATwUAEAABIACvAIAAAAK4wJAAIKAABzAQvwigAAAH8AAAAEAIAACKvbBIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBmWYAAL8BHAAeAMABAQAACMsB akoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAAAACwCgAA0AIAAAAMAABQBAAADwAN8IAAAAAAAJ8P BAAAAAQAAAAAAKgPAgAAAFZQAAChDygAAAADAAAAAAAWWAAABgAGAAEAWgCQ/wMAAAABAEcAAQAE AAQAEAAAAAAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaAC oALwA/ADQAVABQ8ABPCcAAAAMgAK8AgAAAAsjAkAAgoAACMBC/BsAAAABAAAAKb/hQACAAAAhwAB AAAAvwAAAA8ADAHzAzMQgQHM/5kAvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQ BQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAoCwAASQMAAIgLAAA5 BAAADwAE8E8BAAASAArwCAAAAC2MCQAACgAAgwEL8JAAAAB/AAAABACAAJS12wSBAAAAAACCAAAA AACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEAAAjL AWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYA HwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAASAq6GNIZYAsPAA3wgQAAAAAAnw8EAAAABAAA AAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQAEAAA AAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALwA/AD QAVABQ8ABPBJAQAAEgAK8AgAAAAujAkAAAoAAHMBC/CKAAAAfwAAAAQAgAAEt9sEgQAAAAAAggAA AAAAgwAAAAAAhAAAAAAAhQACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA /wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMA AA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAEgD6hNyFUAFDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgP AwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAA qg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUP AATwVQEAABIACvAIAAAAL4wJAIAKAACTAQvwlgAAAAQAAAA+/n8AAAAEAIAAFFvbBIEAAAAAAIIA AAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAA CMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8C FgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAACgEOoTGhYMEg8ADfCBAAAAAACfDwQAAAAE AAAAAACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQ AAAAAAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD 8ANABUAFDwAE8FUBAAASAArwCAAAADCMCQCACgAAkwEL8JYAAAAEAAAA8v5/AAAABACAAKBl2wSB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwA HgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAoBC4A+gF1BEPAA3wgQAAAAAA nw8EAAAABAAAAAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcA AQAEAAQAEAAAAAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPBJAQAAEgAK8AgAAAAxjAkAAAoAAHMBC/CKAAAAfwAAAAQAgAAscNsE gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEB AAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A /wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAADACWAY5B7gDDwAN8IEAAAAAAJ8PBAAA AAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAE ABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC 8APwA0AFQAUPAATwSQEAABIACvAIAAAAMowJAAAKAABzAQvwigAAAH8AAAAEAIAAuHrbBIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsB akoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAABIA2AE6AVABQ8ADfCBAAAAAACfDwQAAAAEAAAA AACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAA AAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANA BUAFDwAE8E8BAAASAArwCAAAADOMCQAACgAAgwEL8JAAAAB/AAAABACAAESF2wSBAAAAAACCAAAA AACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEAAAjL AWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYA HwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAsAU4ABgBOAcPAA3wgQAAAAAAnw8EAAAABAAA AAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQAEAAA AAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALwA/AD QAVABQ8ABPBJAQAAEgAK8AgAAAA0jAkAAAoAAHMBC/CKAAAAfwAAAAQAgADQj9sEgQAAAAAAggAA AAAAgwAAAAAAhAAAAAAAhQACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA /wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMA AA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAAAOOAAYAYgPDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgP AwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAA qg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUP AATwTwEAABIACvAIAAAANYwJAAAKAACDAQvwkAAAAH8AAAAEAIAAEJrbBIEAAAAAAIIAAAAAAIMA AAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsBakoA AP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8D AAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAAC4CjgAGAFADA8ADfCBAAAAAACfDwQAAAAEAAAAAACo DwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAAAAAA AKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAF DwAE8EkBAAASAArwCAAAADaMCQAACgAAcwEL8IoAAAB/AAAABACAALwE2wSBAAAAAACCAAAAAACD AAAAAACEAAAAAACFAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYA DgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAEPAIAAAA4Ac4ABgBEAoPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8DAAAA RVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQAEAAAAAAAAACqDxQA AAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBJ AQAAEgAK8AgAAAA3jAkAAAoAAHMBC/CKAAAAfwAAAAQAgAAcUNsEgQAAAAAAggAAAAAAgwAAAAAA hAAAAAAAhQACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIF AAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYA AAC/AwCCAIIAABDwCAAAALgDOAAYAUAFDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVWQwAA oQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAwAA AAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwTwEAABIA CvAIAAAAOIwJAAAKAACDAQvwkAAAAH8AAAAEAIAA7EXbBIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA AIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAAC BQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEG AAAAvwMAggCCAAAQ8AgAAADYEDgAGAEoEg8ADfCBAAAAAACfDwQAAAAEAAAAAACoDwMAAABFVkMA AKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAMA AAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8E8BAAAS AArwCAAAADmMCQAACgAAgwEL8JAAAAB/AAAABACAAJw62wSBAAAAAACCAAAAAACDAAAAAACEAAAA AACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAA AgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLx BgAAAL8DAIIAggAAEPAIAAAAYBJ4BZEGeBMPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARVZD AAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQAEAAAAAAAAACqDxQAAAAD AAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBPAQAA EgAK8AgAAAA6jAkAAAoAAIMBC/CQAAAAfwAAAAQAgACMJdsEgQAAAAAAggAAAAAAgwAAAAAAhAAA AAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4A AAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi 8QYAAAC/AwCCAIIAABDwCAAAAGASEAMoBHgTDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVW QwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAA AwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwTwEA ABIACvAIAAAAO4wJAAAKAACDAQvwkAAAAH8AAAAEAIAAEBvbBIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsBakoAAP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMA IvEGAAAAvwMAggCCAAAQ8AgAAABgEnIVihZ4Ew8ADfCBAAAAAACfDwQAAAAEAAAAAACoDwMAAABF VkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAA AAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8E8B AAASAArwCAAAADyMCQAACgAAgwEL8JAAAAB/AAAABACAADAw2wSBAAAAAACCAAAAAACDAAAAAACE AAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYA DgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAEPAIAAAAYBIJEyIUeBMPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8DAAAA RVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQAEAAAAAAAAACqDxQA AAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBP AQAAEgAK8AgAAAA9jAkAAAoAAIMBC/CQAAAAfwAAAAQAgADwFl8PgQAAAAAAggAAAAAAgwAAAAAA hAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA/wEG AA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8A EwAi8QYAAAC/AwCCAIIAABDwCAAAAKAQ8hgKGvARDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPAwAA AEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAAqg8U AAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATw SQEAABIACvAIAAAAPowJAAAKAABzAQvwigAAAH8AAAAEAIAAqBOFBYEAAAAAAIIAAAAAAIMAAAAA AIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAAC BQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEG AAAAvwMAggCCAAAQ8AgAAACoDvIYChr4Dw8ADfCBAAAAAACfDwQAAAAEAAAAAACoDwMAAABFVkMA AKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAMA AAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8EkBAAAS AArwCAAAAD+MCQAACgAAcwEL8IoAAAB/AAAABACAAAQUhQWBAAAAAACCAAAAAACDAAAAAACEAAAA AACFAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8D AIIAggAAEPAIAAAAmAvyGAoa6AwPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARVZDAAChDygA AAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQAEAAAAAAAAACqDxQAAAADAAAAAAAA AAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBJAQAAEgAK8AgA AABAjAkAAAoAAHMBC/CKAAAAfwAAAAQAgACIfYUFgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAC AAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQ AgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIA ABDwCAAAAOgF8hgKGgAHDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAA AAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAA BgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwTwEAABIACvAIAAAAQYwJ AAAKAACDAQvwkAAAAH8AAAAEAIAAUAaFBYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcA AgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZ EAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCC AAAQ8AgAAAD4CPIYChoQCg8ADfCBAAAAAACfDwQAAAAEAAAAAACoDwMAAABFVkMAAKEPKAAAAAQA AAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAMAAAAAAAAAAQAA AAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8EkBAAASAArwCAAAAEKM CQAACgAAcwEL8IoAAAB/AAAABACAADwJhQWBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMD ZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAI AAAAqAfyGAoawAgPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAW WAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQAEAAAAAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAA CQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBJAQAAEgAK8AgAAABDjAkAAAoA AHMBC/CKAAAAfwAAAAQAgAA0cIUFgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAQAB8A DAHzAzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKc MQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAEgD 8hgKGggFDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYA BgABAFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwTwEAABIACvAIAAAARIwJAAAKAACDAQvw kAAAAH8AAAAEAIAAWByFBYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAf AAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUC nDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAAAY D6EQYRKAEQ8ADfCBAAAAAACfDwQAAAAEAAAAAACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAG AAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAA AACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8EkBAAASAArwCAAAAEWMCQAACgAAcwEL 8IoAAAB/AAAABACAAGhahQWBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABAAHwAMAfMD MxCBAcyZAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAmAuhEGES AA4PAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEA WgCQ/wQAAAABAEcAAQAEAAQAEAAAAAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8W AAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBPAQAAEgAK8AgAAABGjAkAAAoAAIMBC/CQAAAA fwAAAAQAgAD0ZIUFgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHz AzMQgQHMmQAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAA BgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAABgPwhZK GEgRDwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgAB AFoAkP8EAAAAAQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYP FgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwSQEAABIACvAIAAAAR4wJAAAKAABzAQvwigAA AH8AAAAEAIAAqCCFBYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEB zJkAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEA AD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAACYC8IWShjIDQ8A DfCBAAAAAACfDwQAAAAEAAAAAACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/ BAAAAAEARwABAAQABAAQAAAAAAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADx HgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8E8BAAASAArwCAAAAEiMCQAACgAAgwEL8JAAAAB/AAAA BACAAJxBhQWBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCB AcyZAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAUAihEGESgAoP AA3wgQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ /wQAAAABAEcAAQAEAAQAEAAAAAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA 8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBJAQAAEgAK8AgAAABJjAkAAAoAAHMBC/CKAAAAfwAA AAQAgAAoTIUFgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAQAB8ADAHzAzMQgQHMmQAA vwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwIC AAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAANAEoRBhEsgGDwAN8IEA AAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAA AQBHAAEABAAEABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACg AlABUAGgAqAC8APwA0AFQAUPAATwSQEAABIACvAIAAAASowJAAAKAABzAQvwigAAAH8AAAAEAIAA 3DqFBYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAe AMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8C AQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAAAYCMIWShhICg8ADfCBAAAAAACf DwQAAAAEAAAAAACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwAB AAQABAAQAAAAAAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVAB oAKgAvAD8ANABUAFDwAE8E8BAAASAArwCAAAAEuMCQAACgAAgwEL8JAAAAB/AAAABACAAKRohQWB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwA HgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAmATCFkoYyAYPAA3wgQAAAAAA nw8EAAAABAAAAAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcA AQAEAAQAEAAAAAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPBPAQAAEgAK8AgAAABMjAkAAAoAAIMBC/CQAAAAfwAAAAQAgADEePkE gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEc AB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAABgPiAEQA0gRDwAN8IEAAAAA AJ8PBAAAAAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBH AAEABAAEABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlAB UAGgAqAC8APwA0AFQAUPAATwTwEAABIACvAIAAAATYwJAAAKAACDAQvwkAAAAH8AAAAEAIAAWHr5 BIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAACYC4gBEAPIDQ8ADfCBAAAA AACfDwQAAAAEAAAAAACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEA RwABAAQABAAQAAAAAAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQ AVABoAKgAvAD8ANABUAFDwAE8E8BAAASAArwCAAAAE6MCQAACgAAgwEL8JAAAAB/AAAABACAAOCO +QSBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAqA5xBzEJ2BAPAA3wgQAA AAAAnw8EAAAABAAAAAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAAB AEcAAQAEAAQAEAAAAAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKAC UAFQAaACoALwA/ADQAVABQ8ABPBJAQAAEgAK8AgAAABPjAkAAAoAAHMBC/CKAAAAfwAAAAQAgACM rPkEgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4A wAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIB AA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAGALcQcxCZANDwAN8IEAAAAAAJ8P BAAAAAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEA BAAEABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGg AqAC8APwA0AFQAUPAATwTwEAABIACvAIAAAAUIwJAAAKAACDAQvwkAAAAH8AAAAEAIAAdK75BIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAe AMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8C AQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAABQCIgBEAOACg8ADfCBAAAAAACf DwQAAAAEAAAAAACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwAB AAQABAAQAAAAAAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVAB oAKgAvAD8ANABUAFDwAE8EkBAAASAArwCAAAAFGMCQAACgAAcwEL8IoAAAB/AAAABACAAHh2+QSB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABAAHwAMAfMDMxCBAcyZAAC/ARwAHgDAAQEA AAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/ AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAA0ASIARADyAYPAA3wgQAAAAAAnw8EAAAA BAAAAAAAqA8DAAAARVZDAAChDygAAAAEAAAAAAAWWAAABgAGAAEAWgCQ/wQAAAABAEcAAQAEAAQA EAAAAAAAAACqDxQAAAADAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALw A/ADQAVABQ8ABPBPAQAAEgAK8AgAAABSjAkAAAoAAIMBC/CQAAAAfwAAAAQAgAB8ovkEgQAAAAAA ggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQHMmQAAvwEcAB4AwAEB AAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A /wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAABgIcQcxCUgKDwAN8IEAAAAAAJ8PBAAA AAQAAAAAAKgPAwAAAEVWQwAAoQ8oAAAABAAAAAAAFlgAAAYABgABAFoAkP8EAAAAAQBHAAEABAAE ABAAAAAAAAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC 8APwA0AFQAUPAATwSQEAABIACvAIAAAAU4wJAAAKAABzAQvwigAAAH8AAAAEAIAAkMD5BIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzEIEBzJkAAL8BHAAeAMABAQAACMsB akoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAACYBHEHMQnIBg8ADfCBAAAAAACfDwQAAAAEAAAA AACoDwMAAABFVkMAAKEPKAAAAAQAAAAAABZYAAAGAAYAAQBaAJD/BAAAAAEARwABAAQABAAQAAAA AAAAAKoPFAAAAAMAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANA BUAFDwAE8JQAAAAyAArwCAAAAFSMCQAACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAA DwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAFEIGQiJCGkJDwAE8JQAAAAyAArw CAAAAFWMCQAACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEA DwD/AhYAHwB/AwAADwAAABDwCAAAAEEFGQiJCFkGDwAE8JQAAAAyAArwCAAAAFaMCQAACgAAIwEL 8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYA DgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAA ABDwCAAAAMEI+AFoAtkJDwAE8JQAAAAyAArwCAAAAFeMCQAACgAAIwEL8GwAAAAEAAAAWgCFAAIA AACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRAC AvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAEEF+AFoAlkG DwAE8I4AAAAyAArwCAAAAFiMCQAACgAAEwEL8GYAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCB Af//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAGEEmASwBdEEDwAE8JQAAAAyAArwCAAAAFmMCQAA CgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEA AAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/ AwAADwAAABDwCAAAABkPGQiJCDEQDwAE8JQAAAAyAArwCAAAAFqMCQAACgAAIwEL8GwAAAAEAAAA WgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAAkM GQiJCCENDwAE8JQAAAAyAArwCAAAAFuMCQAACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/ AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwx AAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAIkP+AFoAqEQDwAE8JQAAAAy AArwCAAAAFyMCQAACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf// AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAAkM+AFoAiENDwAE8I4AAAAyAArwCAAAAF2MCQAACgAA EwEL8GYAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAA AgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDw CAAAABERmASwBYERDwAE8BgBAACiDArwCAAAAF+MCQAACgAAIwEL8GwAAACAAODO+QSBALKgAQCC AFnQAACDALKgAQCEAFnQAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEA AAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAABELMALnBwsMDwAN 8HwAAAAAAJ8PBAAAAAQAAAAAAKgPEgAAAE1ldHJvIDIgKEV0aGVybmV0KQAAoQ8cAAAAEwAAAAAA EAAAAAUAEwAAAAEAQwABAAQABAATAAAAqg8MAAAAEwAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQ AVABoAKgAvAD8ANABUAFDwAE8JQAAAAyAArwCAAAAGCMCQDACgAAIwEL8GwAAAAEAAAAWgCFAAIA AACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRAC AvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAHkMSRG5EZEN DwAE8JQAAAAyAArwCAAAAGGMCQDACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAM AfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAIkPSRG5EaEQDwAE8JQAAAAyAArwCAAA AGKMCQDACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwA HgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/ AhYAHwB/AwAADwAAABDwCAAAAAkMahfaFyENDwAE8JQAAAAyAArwCAAAAGOMCQDACgAAIwEL8GwA AAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAA AgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDw CAAAAIkPahfaF6EQDwAE8I4AAAAyAArwCAAAAGSMCQDACgAAEwEL8GYAAACFAAIAAACHAAEAAAC/ AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwx AAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAABERIhQ6FYERDwAE8JQAAAAy AArwCAAAAGWMCQDACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf// AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAJoFSRG5EbIGDwAE8JQAAAAyAArwCAAAAGaMCQDACgAA IwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/ AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAA DwAAABDwCAAAAKoISRG5EcIJDwAE8JQAAAAyAArwCAAAAGeMCQDACgAAIwEL8GwAAAAEAAAAWgCF AAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEB mRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAACoFahfa F0IGDwAE8JQAAAAyAArwCAAAAGiMCQDACgAAIwEL8GwAAAAEAAAAWgCFAAIAAACHAAEAAAC/AAAA DwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAKoIahfaF8IJDwAE8I4AAAAyAArw CAAAAGmMCQDACgAAEwEL8GYAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxCBAf//AAC/ARwAHgDA AQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYA HwB/AwAADwAAABDwCAAAAEoEIhQ6FboEDwAD8FYgAAAPAATwgAAAAAEACfAQAAAAEAIAAA0EAAAQ FAAAoQ4AAAIACvAIAAAAaowJAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAAugRoAmoX EREPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHAEQAAAAAAAAAAAAAAwABAAEAAAAAAAswDwAE 8KIAAABCAQrwCAAAAGuMCQBCCgAAMwEL8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQA AAB/AQAAAQC/AQAAEADAAcz/mQDLARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAADASAABBDgAA4BMAAKEOAAAPAATw ogAAAEIBCvAIAAAAbIwJAIIKAAAzAQvwcgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAA AH8BAAABAL8BAAAQAMABzP+ZAMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYC nDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAQAIAABEIAADwBgAAQQgAAA8ABPCi AAAAQgEK8AgAAABtjAkAggoAADMBC/ByAAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAA fwEAAAEAvwEAABAAwAHM/5kAywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKc MQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABAAgAAQQUAAMAGAADhBwAADwAE8KIA AABCAQrwCAAAAG6MCQACCgAAMwEL8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/ AQAAAQC/AQAAEADAAcz/mQDLARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAOAEAAAhBAAAwAYAAIEEAAAPAATwogAA AEIBCvAIAAAAb4wJAAIKAAAzAQvwcgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8B AAABAL8BAAAQAMABzP+ZAMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEA AD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAgAQAAFEEAADABgAAUQcAAA8ABPCiAAAA QgEK8AgAAABwjAkAAgoAADMBC/ByAAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEA AAEAvwEAABAAwAHM/5kAywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAA PwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABAAgAAQQUAAMAGAACxBwAADwAE8KIAAABC AQrwCAAAAHGMCQACCgAAMwEL8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAA AQC/AQAAEADAAcz/mQDLARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/ AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAEACAADhBAAAwAYAAOEEAAAPAATwggMAAAIA CvAIAAAAcowJAAIKAAATCAvwLAMAAAQAAAAAAIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAgAA AIcAAQAAAIgAAAAAAIkAAAAAAL8AAAAPAAgBAAABAAkBAAAAAAwB8wMzEA0BAAAAIA4BAAAAID8B AAAGAEIBVAAAAEMBgAEAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEBBAAACIIBAAAB AIMBAAAACIQBAAABAIUBAAAAIIbBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwB AAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAA AJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABzP+ZAMEB AAABAMMBAAAAIMQBAAAAAMsBGPABAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANABAAAAANEBAAAA ANIBAQAAANMBAQAAANQBAQAAANUBAQAAANcBAgAAAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAMC AAAAIAQCAAABAAUCnDEAAAYCnDEAAAcCAAAAAAgCAAAAAD8CAgADAIACAAAAAIECAAABAIICBQAA AIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMIC ZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BIT AMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUC ECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAA AEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAIgDAAAAAAMA AwDw/zAAAAAAAMAAVACAAQcACAACAABAAKwBAACsAQAArACAUwAi8R4AAACPAwAAAACQAwIAAACR AwAAAACSAwIAAAC/AwCCAIIAAA/wEAAAAMAGAABxBQAAFAcAAPEGAAAPAATwSgMAAAIACvAIAAAA c4wJAAIKAADjBwvwGgMAAAQAAAAAAIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAgAAAIcAAQAA AIgAAAAAAIkAAAAAAL8AAAAPAAwB8wMzEA0BAAAAIA4BAAAAIEIBMAAAAEMB4AEAAEQBBAAAAEXB DAAAAEbBFAAAAH8BAQABAIABAAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIbBAAAA AIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJAB AAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAA AJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABzP+ZAMEBAAABAMMBAAAAIMQBAAAAAMsBGPABAMwB AAAIAM0BAAAAAM4BAAAAAM/BAAAAANABAAAAANEBAAAAANIBAQAAANMBAQAAANQBAQAAANUBAQAA ANcBAgAAAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAMCAAAAIAQCAAABAAUCnDEAAAYCnDEAAAcC AAAAAAgCAAAAAD8CAgADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAA AIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYC AAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID/ /9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkC ECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAP AIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAIgDAAAAAAMAAwDw/wAAAAAwAPAAAADgAQcACAACAABA AKwBAACsAQAArACAAAAP8BAAAAAQAgAAcQUAAEACAABRBwAADwAE8KIAAABCAQrwCAAAAHSMCQCC CgAAMwEL8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAAcz/ mQDLARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/ AhYAHwB/AwAADwAAAA/wEAAAAEACAACBDQAAwAYAAOENAAAPAATwogAAAEIBCvAIAAAAdYwJAIIK AAAzAQvwcgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8BAAAQAMABzP+Z AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8C FgAfAH8DAAAPAAAAD/AQAAAA4AQAAOENAADABgAAoQ4AAA8ABPCiAAAAQgEK8AgAAAB2jAkAAgoA ADMBC/ByAAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEAAAEAvwEAABAAwAHM/5kA ywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIW AB8AfwMAAA8AAAAP8BAAAABAAgAA4QoAAMAGAAAhDQAADwAE8KIAAABCAQrwCAAAAHeMCQCCCgAA MwEL8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAAcz/mQDL ARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYA HwB/AwAADwAAAA/wEAAAAEACAADhCgAAwAYAAIENAAAPAATwogAAAEIBCvAIAAAAeIwJAAIKAAAz AQvwcgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8BAAAQAMABzP+ZAMsB GPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPAAAAD/AQAAAAQAIAAIEKAADABgAAgQoAAA8ABPCiAAAAQgEK8AgAAAB5jAkAggoAADMB C/ByAAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEAAAEAvwEAABAAwAHM/5kAywEY 8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8A fwMAAA8AAAAP8BAAAACABAAAQQsAAMAGAABxDgAADwAE8LYAAABCAQrwCAAAAHqMCQACCgAAQwEL 8HgAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAcz/ mQDLARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/ AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAD/AQAAAAIAcAAHELAAAgBwAAwQwAAA8ABPCiAAAA QgEK8AgAAAB7jAkAQgoAADMBC/ByAAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEA AAEAvwEAABAAwAHM/5kAywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAA PwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAwDwAAgQoAAOATAACxCgAADwAE8KIAAABC AQrwCAAAAHyMCQBCCgAAMwEL8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAA AQC/AQAAEADAAcz/mQDLARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/ AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAGAPAADhCgAA4BMAAIENAAAPAATwogAAAEIB CvAIAAAAfYwJAMIKAAAzAQvwcgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAAB AL8BAAAQAMABzP+ZAMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8C AgADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAYA8AAEEOAABAEQAAoQ4AAA8ABPCiAAAAQgEK 8AgAAAB+jAkAwgoAADMBC/ByAAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEAAAEA vwEAABAAwAHM/5kAywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwIC AAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABgDwAAcQsAAKARAABxDgAADwAE8KIAAABCAQrw CAAAAH+MCQDCCgAAMwEL8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/ AQAAEADAAcz/mQDLARjwAQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAGAPAAARCwAA4BMAAIENAAAPAATwogAAAEIBCvAI AAAAgIwJAMIKAAAzAQvwcgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8B AAAQAMABzP+ZAMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAYA8AAOENAADgEwAA4Q0AAA8ABPCCAwAAAgAK8AgA AACBjAkAwgoAABMIC/AsAwAABAAAAAAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQACAAAAhwAB AAAAiAAAAAAAiQAAAAAAvwAAAA8ACAEAAAEACQEAAAAADAHzAzMQDQEAAAAgDgEAAAAgPwEAAAYA QgFUAAAAQwGAAQAARAEEAAAARcEMAAAARsEUAAAAfwEBAAEAgAEAAAAAgQEEAAAIggEAAAEAgwEA AAAIhAEAAAEAhQEAAAAghsEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAA jQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEA AAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEMAB4AwAHM/5kAwQEAAAEA wwEAAAAgxAEAAAAAywEY8AEAzAEAAAgAzQEAAAAAzgEAAAAAz8EAAAAA0AEAAAAA0QEAAAAA0gEB AAAA0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQAwIAAAAg BAIAAAEABQKcMQAABgKcMQAABwIAAAAACAIAAAAAPwICAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKc MQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAA wwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw 7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA 1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMD AAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAiAMAAAAAAwADAPD/ MAAAAAAAwABUAIABBwAIAAIAAEAArAEAAKwBAACsAIBTACLxHgAAAI8DAAAAAJADAgAAAJEDAAAA AJIDAgAAAL8DAIIAggAAD/AQAAAADA8AANELAABgDwAAUQ0AAA8ABPBKAwAAAgAK8AgAAACCjAkA wgoAAOMHC/AaAwAABAAAAAAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQACAAAAhwABAAAAiAAA AAAAiQAAAAAAvwAAAA8ADAHzAzMQDQEAAAAgDgEAAAAgQgEwAAAAQwHgAQAARAEEAAAARcEMAAAA RsEUAAAAfwEBAAEAgAEAAAAAgQEEAAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAghsEAAAAAh8EA AAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAA kQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEA AAAAmwEAAAAAnAEDAABAvwEMAB4AwAHM/5kAwQEAAAEAwwEAAAAgxAEAAAAAywEY8AEAzAEAAAgA zQEAAAAAzgEAAAAAz8EAAAAA0AEAAAAA0QEAAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEBAAAA1wEC AAAA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQAwIAAAAgBAIAAAEABQKcMQAABgKcMQAABwIAAAAA CAIAAAAAPwICAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3 AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAA xwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIA AHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA 2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8 vgEAhQMAAAAAhgN8vgEAhwMAAAAAiAMAAAAAAwADAPD/AAAAADAA8AAAAOABBwAIAAIAAEAArAEA AKwBAACsAIAAAA/wEAAAAOATAABxCwAAEBQAAFENAAAPAATwogAAAEIBCvAIAAAAg4wJAEIKAAAz AQvwcgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8BAAAQAMABzP+ZAMsB GPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPAAAAD/AQAAAAYA8AAM0EAADgEwAALQUAAA8ABPCiAAAAQgEK8AgAAACEjAkAQgoAADMB C/ByAAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEAAAEAvwEAABAAwAHM/5kAywEY 8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8A fwMAAA8AAAAP8BAAAABgDwAADQQAAEARAADNBAAADwAE8KIAAABCAQrwCAAAAIWMCQDCCgAAMwEL 8HIAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAAcz/mQDLARjw AQD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/ AwAADwAAAA/wEAAAAGAPAACNBQAA4BMAAM0HAAAPAATwogAAAEIBCvAIAAAAhowJAEIKAAAzAQvw cgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8BAAAQAMABzP+ZAMsBGPAB AP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8D AAAPAAAAD/AQAAAAYA8AAC0FAADgEwAAzQcAAA8ABPCiAAAAQgEK8AgAAACHjAkAwgoAADMBC/By AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEAAAEAvwEAABAAwAHM/5kAywEY8AEA /wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMA AA8AAAAP8BAAAABgDwAALQgAAOATAAAtCAAADwAE8KIAAABCAQrwCAAAAIiMCQBCCgAAMwEL8HIA AACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAAcz/mQDLARjwAQD/ AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAA DwAAAA/wEAAAAGAPAAA9BAAAoBEAAG0HAAAPAATwtgAAAEIBCvAIAAAAiYwJAMIKAABDAQvweAAA AIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8BAAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzP+ZAMsB GPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAAAAAADwAA7QUAAAAPAAA9BwAADwAD8JoRAAAPAATw gAAAAAEACfAQAAAAkAAAANACAACQFQAA8Q8AAAIACvAIAAAAiowJAAECAAAjAAvwDAAAAAQAAAAA AIgDAAAAAAAAEPAIAAAASAOoACoZmRIPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHAEQAAAAA AAAAAAAABQABAAEAAAAAAAswDwAE8LYAAABCAQrwCAAAAIuMCQBCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAAsAQAANACAABwBQAAkAMAAA8ABPC2AAAAQgEK8AgAAACMjAkA wgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAJAAAAAhBAAAgAEAALEEAAAP AATwtgAAAEIBCvAIAAAAjYwJAEIKAABDAQvweAAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8B AAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAA AACQAAAAQQUAAIABAABxBQAADwAE8LYAAABCAQrwCAAAAI6MCQBCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAAkAAAABEIAACAAQAAEQgAAA8ABPC2AAAAQgEK8AgAAACPjAkA AgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAMAAAADBCQAAgAEAAFEKAAAP AATwtgAAAEIBCvAIAAAAkIwJAEIKAABDAQvweAAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8B AAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAA AACQAAAAsQoAAIABAACxCgAADwAE8LYAAABCAQrwCAAAAJGMCQBCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAAkAAAABELAACAAQAAcQsAAA8ABPC2AAAAQgEK8AgAAACSjAkA AgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAJAAAADxDAAAgAEAAIENAAAP AATwtgAAAEIBCvAIAAAAk4wJAAIKAABDAQvweAAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8B AAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAA AACQAAAA4Q0AAIABAADhDQAADwAE8LYAAABCAQrwCAAAAJSMCQBCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAAkAAAAEEOAACAAQAAoQ4AAA8ABPC2AAAAQgEK8AgAAACVjAkA AgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAKAUAAARDgAAkBUAAKEOAAAP AATwtgAAAEIBCvAIAAAAlowJAIIKAABDAQvweAAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8B AAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAA AACgFAAAUQ0AAJAVAACBDQAADwAE8LYAAABCAQrwCAAAAJeMCQCCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAAoBQAALEKAACQFQAAsQoAAA8ABPC2AAAAQgEK8AgAAACYjAkA wgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAKAUAABdCAAAYBUAAO0IAAAP AATwtgAAAEIBCvAIAAAAmYwJAIIKAABDAQvweAAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8B AAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAA AACgFAAA/QcAAJAVAAD9BwAADwAE8LYAAABCAQrwCAAAAJqMCQCCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAAoBQAAD0HAACQFQAAnQcAAA8ABPC2AAAAQgEK8AgAAACbjAkA wgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAKAUAAAtBQAAkBUAAL0FAAAP AATwtgAAAEIBCvAIAAAAnIwJAMIKAABDAQvweAAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8B AAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAA AACgFAAAzQQAAJAVAADNBAAADwAE8LYAAABCAQrwCAAAAJ2MCQCCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAAoBQAAA0EAACQFQAAbQQAAA8ABPC2AAAAQgEK8AgAAACejAkA QgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAGADAAAxDwAAIAQAAPEPAAAP AATwtgAAAEIBCvAIAAAAn4wJAAIKAABDAQvweAAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzED8B AAAGAEQBBAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAP8BAA AACABAAAMQ8AABAFAADxDwAADwAE8LYAAABCAQrwCAAAAKCMCQBCCgAAQwEL8HgAAACFAAIAAACH AAEAAAC/AAAADwAMAfMDMxA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAczs/wDLARjwAQD/AR4A HgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAD/AQAAAA4BAAADEPAACgEQAA8Q8AAA8ABPC2AAAAQgEK8AgAAAChjAkA AgoAAEMBC/B4AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQPwEAAAYARAEEAAAAfwEAAAEAvwEA ABAAwAHM7P8AywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAAA/wEAAAAAASAAAxDwAAkBIAAPEPAAAP AAPwIBMAAA8ABPCAAAAAAQAJ8BAAAACABwAAsQQAAKAOAAARDgAAAgAK8AgAAACijAkAAQIAACMA C/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAAB5BcEIERFpEA8AEfAsAAAADwAUECQAAAABAPEPHAAA AAAAAAcERAAAAAAAANAHAAAEAAEAAQAAAAAACzAPAATwogAAAEIBCvAIAAAAo4wJAAIKAAAzAQvw cgAAAIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8BAAAQAMABM8wzAMsBGPAB AP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8D AAAPAAAAD/AQAAAAgAcAALENAACgDgAAEQ4AAA8ABPCiAAAAQgEK8AgAAACkjAkAAgoAADMBC/By AAAAhQACAAAAhwABAAAAvwAAAA8ADAHzAzMQRAEEAAAAfwEAAAEAvwEAABAAwAEzzDMAywEY8AEA /wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMA AA8AAAAP8BAAAACABwAAUQcAAKAOAACxBwAADwAE8KIAAABCAQrwCAAAAKWMCQCCCgAAMwEL8HIA AACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAATPMMwDLARjwAQD/ AR4AHgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAA DwAAAA/wEAAAAIAHAADhBwAAoA4AAIENAAAPAATwogAAAEIBCvAIAAAApowJAAIKAAAzAQvwcgAA AIUAAgAAAIcAAQAAAL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8BAAAQAMABM8wzAMsBGPABAP8B HgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAP AAAAD/AQAAAAgAcAALEHAABwDgAAsQ0AAA8ABPBKAwAAAgAK8AgAAACnjAkAAgoAAOMHC/AaAwAA BAAAAAAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQACAAAAhwABAAAAiAAAAAAAiQAAAAAAvwAA AA8ADAHzAzMQDQEAAAAgDgEAAAAgQgEgAQAAQwEQBQAARAEEAAAARcEMAAAARsEUAAAAfwEBAAEA gAEAAAAAgQEEAAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAghsEAAAAAh8EAAAAAiAEAAAAAiQEA AAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAA kwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAAmwEAAAAAnAED AABAvwEMAB4AwAEzzDMAwQEAAAEAwwEAAAAgxAEAAAAAywEY8AEAzAEAAAgAzQEAAAAAzgEAAAAA z8EAAAAA0AEAAAAA0QEAAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEeAB4AAAIF AAAAAQLxAZkQAgLzA2YQAwIAAAAgBAIAAAEABQKcMQAABgKcMQAABwIAAAAACAIAAAAAPwICAAMA gAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIB AA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAA yQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIg TgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8A BAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8 vgEAhwMAAAAAiAMAAAAAAwADAPD/AAAAACABcAIAABAFBwAIAAIAAEAArAEAAKwBAACsAIAAAA/w EAAAAIAHAAARCAAAoAgAACENAAAPAATwSgMAAAIACvAIAAAAqIwJAAIKAADjBwvwGgMAAAQAAAAA AIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAAAL8AAAAPAAwB 8wMzEA0BAAAAIA4BAAAAIEIBUAEAAEMBEAUAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAA AIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIbBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoB AAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAA AJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8B DAAeAMABM8wzAMEBAAABAMMBAAAAIMQBAAAAAMsBGPABAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAA ANABAAAAANEBAAAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAANcBAgAAAP8BHgAeAAACBQAAAAEC 8QGZEAIC8wNmEAMCAAAAIAQCAAABAAUCnDEAAAYCnDEAAAcCAAAAAAgCAAAAAD8CAgADAIACAAAA AIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMAC AAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAA AMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMC UMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAA AEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcD AAAAAIgDAAAAAAMAAwDw/1ABAAAAAHACUAEQBQcACAACAABAAKwBAACsAQAArACAAAAP8BAAAABQ DQAAQQgAAKAOAABRDQAADwAE8KIAAABCAQrwCAAAAKmMCQACCgAAMwEL8HIAAACFAAIAAACHAAEA AAC/AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAAcz/mQDLARjwAQD/AR4AHgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAIAH AACxBAAAoA4AAOEEAAAPAATwogAAAEIBCvAIAAAAqowJAAIKAAAzAQvwcgAAAIUAAgAAAIcAAQAA AL8AAAAPAAwB8wMzEEQBBAAAAH8BAAABAL8BAAAQAMABzP+ZAMsBGPABAP8BHgAeAAACBQAAAAEC 8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAgAcA ABELAACgDgAAcQsAAA8ABPCiAAAAQgEK8AgAAACrjAkAAgoAADMBC/ByAAAAhQACAAAAhwABAAAA vwAAAA8ADAHzAzMQRAEEAAAAfwEAAAEAvwEAABAAwAHM/5kAywEY8AEA/wEeAB4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAACABwAA EQUAAKAOAAARCwAADwAE8KIAAABCAQrwCAAAAKyMCQBCCgAAMwEL8HIAAACFAAIAAACHAAEAAAC/ AAAADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAAcz/mQDLARjwAQD/AR4AHgAAAgUAAAABAvEB mRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAIAHAABB BQAAoA4AALEKAAAPAATwSgMAAAIACvAIAAAArYwJAAIKAADjBwvwGgMAAAQAAAAAAIEAMGUBAIIA mLIAAIMAMGUBAIQAmLIAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAAAL8AAAAPAAwB8wMzEA0BAAAA IA4BAAAAIEIBsAEAAEMB4AQAAEQBBAAAAEXBDAAAAEbBFAAAAH8BAQABAIABAAAAAIEBBAAACIIB AAABAIMBAAAACIQBAAABAIUBAAAAIIbBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAA AIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUB AAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BDAAeAMABzP+Z AMEBAAABAMMBAAAAIMQBAAAAAMsBGPABAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANABAAAAANEB AAAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAANcBAgAAAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNm EAMCAAAAIAQCAAABAAUCnDEAAAYCnDEAAAcCAAAAAAgCAAAAAD8CAgADAIACAAAAAIECAAABAIIC BQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAA AMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC 0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAA ANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEID AAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAIgDAAAA AAMAAwDw/wAAAACwATADAADgBAcACAACAABAAKwBAACsAQAArACAAAAP8BAAAACABwAAcQUAADAJ AABRCgAADwAE8EoDAAACAArwCAAAAK6MCQACCgAA4wcL8BoDAAAEAAAAAACBADBlAQCCAJiyAACD ADBlAQCEAJiyAACFAAIAAACHAAEAAACIAAAAAACJAAAAAAC/AAAADwAMAfMDMxANAQAAACAOAQAA ACBCASABAABDAeAEAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCAAQAAAACBAQQAAAiCAQAAAQCD AQAAAAiEAQAAAQCFAQAAACCGwQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAA AACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACW AQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/AQwAHgDAAcz/mQDBAQAA AQDDAQAAACDEAQAAAADLARjwAQDMAQAACADNAQAAAADOAQAAAADPwQAAAADQAQAAAADRAQAAAADS AQEAAADTAQEAAADUAQEAAADVAQEAAADXAQIAAAD/AR4AHgAAAgUAAAABAvEBmRACAvMDZhADAgAA ACAEAgAAAQAFApwxAAAGApwxAAAHAgAAAAAIAgAAAAA/AgIAAwCAAgAAAACBAgAAAQCCAgUAAACD ApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQA AADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDM AjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAn AADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABD AwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAACIAwAAAAADAAMA 8P8gAQAAAACgAiAB4AQHAAgAAgAAQACsAQAArAEAAKwAgAAAD/AQAAAAgA0AANEFAACgDgAAsQoA AA8ABPAWAQAAogwK8AgAAACvjAkAQAoAACMBC/BsAAAAgABYofkEgQCyoAEAggBZ0AAAgwCyoAEA hABZ0AAAhQACAAAAhwAGAAAAvwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAAAoC0QSghciDA8ADfB6AAAAAACfDwQA AAAEAAAAAACoDxAAAABNZXRybyAzIChQQkItVEUpAAChDxwAAAARAAAAAAAQAAAABQARAAAAAQBD AAEABAAEABMAAACqDwwAAAARAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AF QAUPAATwGAEAAKIMCvAIAAAAsIwJAEAKAAAjAQvwbAAAAIAARFv5BIEAsqABAIIAWdAAAIMAsqAB AIQAWdAAAIUAAgAAAIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAEC AgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAKARyEikYIgUPAA3wfAAAAAAAnw8E AAAABAAAAAAAqA8SAAAATWV0cm8gNCAoRXRoZXJuZXQpAAChDxwAAAATAAAAAAAQAAAABQATAAAA AQBDAAEABAAEABMAAACqDwwAAAATAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APw A0AFQAUPAATwtAAAAFIACvAIAAAAsowJAIAKAABTAQvwfgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIcAAQAAAL8AAgAPAAwB8wMzEIEB//8AAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAA AAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAA vwMAggCCAAAQ8AgAAABgBDgAqADQBA8ABPC0AAAAUgAK8AgAAACzjAkAgAoAAFMBC/B+AAAAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhwABAAAAvwACAA8ADAHzAzMQgQH//wAAvwEcAB4AwAEBAAAI ywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIW AB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAOgFOACoAFgGDwAE8LQAAABSAArwCAAAALSM CQCACgAAUwEL8H4AAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACHAAEAAAC/AAIADwAMAfMDMxCB Af//AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAA8Ao4AKgAYAsP AATwtAAAAFIACvAIAAAAtYwJAIAKAABTAQvwfgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIcA AQAAAL8AAgAPAAwB8wMzEIEB//8AAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZ EAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCC AAAQ8AgAAACoDjgAqAAYDw8ABPC6AAAAUgAK8AgAAAC2jAkAgAoAAGMBC/CEAAAABAAAALQAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhwABAAAAvwACAA8ADAHzAzMQgQH//wAAvwEcAB4AwAEBAAAI ywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIW AB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAABAROACoAIARDwAE8LoAAABSAArwCAAAALeM CQCACgAAYwEL8IQAAAAEAAAAWgCBAAAAAACCAAAAAACDAAAAAACEAAAAAACHAAEAAAC/AAIADwAM AfMDMxCBAf//AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwx AAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAYBJI A7gD0BIPAATwugAAAFIACvAIAAAAuIwJAIAKAABjAQvwhAAAAAQAAAAOAYEAAAAAAIIAAAAAAIMA AAAAAIQAAAAAAIcAAQAAAL8AAgAPAAwB8wMzEIEB//8AAL8BHAAeAMABAQAACMsBakoAAP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMA IvEGAAAAvwMAggCCAAAQ8AgAAABgEiAGkQbQEg8ABPC6AAAAUgAK8AgAAAC5jAkAgAoAAGMBC/CE AAAABAAAAMIBgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhwABAAAAvwACAA8ADAHzAzMQgQH//wAA vwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwIC AAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAGASQROyE9ASDwAE8LoA AABSAArwCAAAALqMCQCACgAAYwEL8IQAAAAEAAAADgGBAAAAAACCAAAAAACDAAAAAACEAAAAAACH AAEAAAC/AAIADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEB mRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIA ggAAEPAIAAAAmBLiFVIWCBMPAATwugAAAFIACvAIAAAAu4wJAIAKAABjAQvwhAAAAAQAAAAOAYEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIcAAQAAAL8AAgAPAAwB8wMzEIEB//8AAL8BHAAeAMABAQAA CMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8C FgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAADYEGIZ0hlIEQ8ABPC6AAAAUgAK8AgAAAC8 jAkAgAoAAGMBC/CEAAAABAAAAA4BgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhwABAAAAvwACAA8A DAHzAzMQgQH//wAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKc MQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAFAP YhnSGcAPDwAE8LoAAABSAArwCAAAAL2MCQCACgAAYwEL8IQAAAAEAAAADgGBAAAAAACCAAAAAACD AAAAAACEAAAAAACHAAEAAAC/AAIADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYA DgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwAT ACLxBgAAAL8DAIIAggAAEPAIAAAAQAxiGdIZsAwPAATwugAAAFIACvAIAAAAvowJAIAKAABjAQvw hAAAAAQAAAAOAYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIcAAQAAAL8AAgAPAAwB8wMzEIEB//8A AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8C AgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAABICioZmhm4Cg8ABPC6 AAAAUgAK8AgAAAC/jAkAgAoAAGMBC/CEAAAABAAAAA4BgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hwABAAAAvwACAA8ADAHzAzMQgQH//wAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCC AIIAABDwCAAAAPgIYhnSGWgJDwAE8LoAAABSAArwCAAAAMCMCQCACgAAYwEL8IQAAAAEAAAADgGB AAAAAACCAAAAAACDAAAAAACEAAAAAACHAAEAAAC/AAIADwAMAfMDMxCBAf//AAC/ARwAHgDAAQEA AAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/ AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAUAhiGdIZwAgPAATwugAAAFIACvAIAAAA wYwJAIAKAABjAQvwhAAAAAQAAAAOAYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIcAAQAAAL8AAgAP AAwB8wMzEIEB//8AAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUC nDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAACQ BmIZ0hkABw8ABPC6AAAAUgAK8AgAAADCjAkAgAoAAGMBC/CEAAAABAAAAGgBgQAAAAAAggAAAAAA gwAAAAAAhAAAAAAAhwABAAAAvwACAA8ADAHzAzMQgQH//wAAvwEcAB4AwAEBAAAIywFqSgAA/wEG AA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8A EwAi8QYAAAC/AwCCAIIAABDwCAAAANgCkQYBB0gDDwAE8LoAAABSAArwCAAAAMOMCQCACgAAYwEL 8IQAAAAEAAAADgGBAAAAAACCAAAAAACDAAAAAACEAAAAAACHAAEAAAC/AAIADwAMAfMDMxCBAf// AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/ AgIAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAYARiGdIZ0AQPAATw ugAAABIACvAIAAAAxYwJAAAKAABjAQvwhAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIcAAQAA AL8AAgAPAAwB8wMzEIEB6urqAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC 8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAIgDCAAAABMAIvEGAAAAvwMA ggCCAAAQ8AgAAABgEv4HchKwEw8ABPDGAAAAQgEK8AgAAADGjAkAAAoAAIMBC/CQAAAAgQAAAAAA ggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwABAAAAvwACAA8ADAHzAzMQRAEEAAAAfwEAAAEAvwEA ABAAwAHM/5kAywEY8AEA/wEeAB4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AiAMIAAAAEwAi8QYAAAC/AwCCAIIAABDwCAAAAJgSYwh7CZgSDwAE 8MYAAABCAQrwCAAAAMeMCQAACgAAgwEL8JAAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIA AACHAAEAAAC/AAIADwAMAfMDMxBEAQQAAAB/AQAAAQC/AQAAEADAATPMMwDLARjwAQD/AR4AHgAA AgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCIAwgA AAATACLxBgAAAL8DAIIAggAAEPAIAAAACBNjCHsJCBMPAATwxgAAAEIBCvAIAAAAyIwJAAAKAACD AQvwkAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AAgAPAAwB8wMzEEQB BAAAAH8BAAABAL8BAAAQAMABzOz/AMsBGPABAP8BHgAeAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAIgDCAAAABMAIvEGAAAAvwMAggCCAAAQ8AgA AAB4E2MIewl4Ew8ABPBHAQAAogwK8AgAAADJjAkAAAoAAEMBC/B4AAAAgAAwZvkEgQAAAAAAggAA AAAAgwAAAAAAhAAAAAAAhQACAAAAhwAGAAAAvwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI ywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMIAAAAEwAi8QYAAAC/ AwCCAIIAABDwCAAAAJkSswk1DgETDwAN8JEAAAAAAJ8PBAAAAAQAAAAAAKgPGwAAAFZQIHRyYWls IHN1cHBvcnRlZCBFVkMgbGluawAAoQ8gAAAAHAAAAAAAFlAAAAYABgBaAJD/HAAAAAAAQwAEAAQA DAAAAKoPFAAAABsAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANA BUAFDwAE8D8BAACiDArwCAAAAMqMCQAACgAAQwEL8HgAAACAAMhv+QSBAAAAAACCAAAAAACDAAAA AACEAAAAAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAjLAWpKAAD/ AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwgAAAATACLxBgAAAL8DAIIAggAA EPAIAAAATBO1CS8OtBMPAA3wiQAAAAAAnw8EAAAABAAAAAAAqA8bAAAAVlMgdHJhaWwgc3VwcG9y dGVkIEVWQyBsaW5rAAChDyAAAAAcAAAAAAAWUAAABgAGAFoAkP8cAAAAAABDAAQABAAMAAAAqg8M AAAAHAAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8LoAAAAyAArw CAAAAMuMCQAACgAAYwEL8IQAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACHAAEAAAC/AAIADwAM AfMDMxCBAf//AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwx AAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCIAwgAAAATACLxBgAAAL8DAIIAggAAEPAI AAAAQBOXDncPsBMPAATwugAAAFIACvAIAAAAzIwJAIAKAABjAQvwhAAAAIEAAAAAAIIAAAAAAIMA AAAAAIQAAAAAAIcAAQAAAL8AAgAPAAwB8wMzEIEB//8AAL8BHAAeAMABAQAACMsBakoAAP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAIgD CAAAABMAIvEGAAAAvwMAggCCAAAQ8AgAAACYEs8OPw8IEw8ABPA4AQAAogwK8AgAAADNjAkAAAoA AEMBC/B4AAAAgACwl3ACgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwAGAAAAvwASAB8A gQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AiAMIAAAAEwAi8QYAAAC/AwCCAIIAABDwCAAAAJkSrw/qEQETDwAN8IIAAAAAAJ8P BAAAAAQAAAAAAKgPDAAAAEVWQyBFbmRwb2ludAAAoQ8gAAAADQAAAAAAFlAAAAYABgBaAJD/DQAA AAAAQwAEAAQADAAAAKoPFAAAAAwAAAAAAAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVAB oAKgAvAD8ANABUAFDwAE8DYBAACiDArwCAAAAM6MCQAACgAAQwEL8HgAAIEAAACCAAAAgwAAAIQA AACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAA AJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAA oQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACv AAAAsAAAALEAAACyAAAAswAAALQAAAD+/////v///+IAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0A AAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADHAAAAyAAAAMkAAADKAAAAywAA AMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA 2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAAD+/////v////7///////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AIAAICxwAoEAAAAAAIIA AAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8BDAAeAMABAQAA CMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDCAAAABMAIvEGAAAA vwMAggCCAAAQ8AgAAABME7APfRG0Ew8ADfCAAAAAAACfDwQAAAAEAAAAAACoDwoAAABFVkMgTWF0 cml4AAChDyAAAAALAAAAAAAWUAAABgAGAFoAkP8LAAAAAABDAAQABAAMAAAAqg8UAAAACgAAAAAA AAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwiAAAAEIBCvAI AAAA0YwJAMAKAAADAQvwYAAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMAB AQAACMsBn28AAM4BBwAAAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAwAA AAAAEPAIAAAAMBDDEXMXMBAPAATwiAAAAEIBCvAIAAAA0owJAAAKAAADAQvwYAAAAIUAAgAAAIcA AQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAM4BBwAAAP8BHgAeAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAwAAAAAAEPAIAAAA+A8bEcMRMBAPAATwiAAAAEIB CvAIAAAA04wJAIAKAAADAQvwYAAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQ AMABAQAACMsBn28AAM4BBwAAAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgD AwAAAAAAEPAIAAAAwA9zF+QXMBAPAATwiAAAAEIBCvAIAAAA1IwJAAAKAAADAQvwYAAAAIUAAgAA AIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAM4BBwAAAP8BHgAeAAEC AgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAwAAAAAAEPAIAAAA+AjKCBsR+A8PAATwiAAA AEIBCvAIAAAA1YwJAAAKAAADAQvwYAAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8B AAAQAMABAQAACMsBn28AAM4BBwAAAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AIgDAwAAAAAAEPAIAAAAwAgiCMoI+AgPAATwiAAAAEIBCvAIAAAA1owJAMAKAAADAQvwYAAAAIUA AgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAM4BBwAAAP8BHgAe AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAwAAAAAAEPAIAAAA0AQSBSIIwAgPAATw iAAAAEIBCvAIAAAA14wJAIAKAAADAQvwYAAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACMsBn28AAM4BBwAAAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAIgDAwAAAAAAEPAIAAAAiA/kFzQZwA8PAATwiAAAAEIBCvAIAAAA2IwJAEAKAAADAQvwYAAA AIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAM4BBwAAAP8B HgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAwAAAAAAEPAIAAAASANKBWIGYAQP AATwiAAAAEIBCvAIAAAA2YwJAEAKAAADAQvwYAAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8B AAABAL8BAAAQAMABAQAACMsBn28AAM4BBwAAAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAIgDAwAAAAAAEPAIAAAAYAQSBUoF0AQPAATwEgEAAKIMCvAIAAAA2owJAAAKAAATAQvw ZgAAAIAAXC1wAoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcABgAAAL8AEgAfAIEBAAAA CL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAIgDAwAAAAAAEPAIAAAA RwOTBisH0gMPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8CAAAAQjEAAKEPJAAAAAMAAAAAABZYAAAG AAYAAQBaAJD/AwAAAAMAQwADAAQABAAQAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkIAAAAAKYP FgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwEgEAAKIMCvAIAAAA24wJAAAKAAATAQvwZgAA AIAA6DdwAoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcABgAAAL8AEgAfAIEBAAAACL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAIgDAwAAAAAAEPAIAAAArg8A GZYZORAPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8CAAAAQjIAAKEPJAAAAAMAAAAAABZYAAAGAAYA AQBaAJD/AwAAAAMAQwADAAQABAAQAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkIAAAAAKYPFgAA APEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwggAAAEIBCvAIAAAA3owJAAAKAADzAAvwWgAAAIUA AgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAAtQUVEU0R9gUPAATwggAAAEIB CvAIAAAA34wJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQ AMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAA EPAIAAAAogUlCIwIpwUPAATwggAAAEIBCvAIAAAA4IwJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAA AL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAA0AS1APIBigUPAATwggAAAEIBCvAIAAAA4YwJ AAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB n28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAAogVn AhcIogUPAATwggAAAEIBCvAIAAAA4owJAIAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAIgDAQAAAAAAEPAIAAAAhgWMCMQIogUPAATwggAAAEIBCvAIAAAA44wJAAAKAADzAAvw WgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAe AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAA9gXECBUR9gwPAATw ggAAAEIBCvAIAAAA5IwJAIAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgD AQAAAAAAEPAIAAAAhgW9EW0X9gUPAATwggAAAEIBCvAIAAAA5YwJAAAKAADzAAvwWgAAAIUAAgAA AIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAA9gXUFzIZvwYPAATwggAAAEIBCvAI AAAA5owJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMAB AQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAI AAAAhgXECBURvgUPAATwggAAAEIBCvAIAAAA54wJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8A AAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAAZg31EZUUHhEPAATwggAAAEIBCvAIAAAA6IwJAAAK AADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28A AP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAAjhEFFa0V bhIPAATwggAAAEIBCvAIAAAA6YwJAEAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAA AH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAIgDAQAAAAAAEPAIAAAAWgmiAPIBWgkPAATwggAAAEIBCvAIAAAA6owJAAAKAADzAAvwWgAA AIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAEC AgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAAlAX6AWcCogUPAATwggAA AEIBCvAIAAAA64wJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8B AAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAA AAAAEPAIAAAA9gVWEbgR+wUPAATwggAAAEIBCvAIAAAA7IwJAAAKAADzAAvwWgAAAIUAAgAAAIcA AQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAAhgV7F9kX/wUPAATwggAAAEIBCvAIAAAA 7YwJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAA CMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAA Zga9EW0XPgkPAATwggAAAEIBCvAIAAAA7owJAIAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAP AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8C FgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAATAndFzcZTAkPAATwggAAAEIBCvAIAAAA74wJAAAKAADz AAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8B HgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAA+wV7EbgRYQYP AATwggAAAEIBCvAIAAAA8IwJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8B AAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AIgDAQAAAAAAEPAIAAAAQwlpF+IXUQkPAATwggAAAEIBCvAIAAAA8YwJAAAKAADzAAvwWgAAAIUA AgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAALg1NEfURZg0PAATwggAAAEIB CvAIAAAA8owJAIAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQ AMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAA EPAIAAAA9gVrAhcIQwkPAATwggAAAEIBCvAIAAAA84wJAIAKAADzAAvwWgAAAIUAAgAAAIcAAQAA AL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAApwUhCEYI8QUPAATwggAAAEIBCvAIAAAA9IwJ AIAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB n28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAEPAIAAAAPgkA AnUCXwkPAATwggAAAEIBCvAIAAAA9YwJAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAIgDAQAAAAAAEPAIAAAAJBGUFBEVjhEPAATwjgAAAEIBCvAIAAAA9owJAMAKAAATAQvw ZgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAIgDAQAAAAAAEPAIAAAA pwVnCMQI9gUPAATwjgAAAEIBCvAIAAAA94wJAMAKAAATAQvwZgAAAIEAAAAAAIIAAAAAAIMAAAAA AIQAAAAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8B HgAeAAECAgAACD8CAAADAL8CAQAPAIgDAQAAAAAAEPAIAAAA9gwVEU0RLg0PAATwEgEAAKIMCvAI AAAA+IwJAAAKAAATAQvwZgAAAIAAEExwAoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcA BgAAAL8AEgAfAIEBAAAACL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAP AIgDAQAAAAAAEPAIAAAA3wQzAM8AagUPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8CAAAARDEAAKEP JAAAAAMAAAAAABZYAAAGAAYAAQBaAJD/AwAAAAMAQwADAAQABAAQAAAAqg8UAAAAAgAAAAAAAAAB AAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwEgEAAKIMCvAIAAAA +YwJAAAKAAATAQvwZgAAAIAAUFZwAoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcABgAA AL8AEgAfAIEBAAAACL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAIgD AQAAAAAAEPAIAAAAmAjTAG4BIwkPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8CAAAARDIAAKEPJAAA AAMAAAAAABZYAAAGAAYAAQBaAJD/AwAAAAMAQwADAAQABAAQAAAAqg8UAAAAAgAAAAAAAAABAAAA BgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwEgEAAKIMCvAIAAAA+owJ AAAKAAATAQvwZgAAAIAA3GBwAoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcABgAAAL8A EgAfAIEBAAAACL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAIgDAQAA AAAAEPAIAAAA/xHQFW0WihIPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8CAAAARDMAAKEPJAAAAAMA AAAAABZYAAAGAAYAAQBaAJD/AwAAAAMAQwADAAQABAAQAAAAqg8UAAAAAgAAAAAAAAABAAAABgAA AAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwEgEAAKIMCvAIAAAA+4wJAAAK AAATAQvwZgAAAIAAaGtwAoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcABgAAAL8AEgAf AIEBAAAACL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAIgDAQAAAAAA EPAIAAAAmgjUGG8ZJgkPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8CAAAARDQAAKEPJAAAAAMAAAAA ABZYAAAGAAYAAQBaAJD/AwAAAAMAQwADAAQABAAQAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkI AAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwEgEAAKIMCvAIAAAA/IwJAAAKAAAT AQvwZgAAAIAA9HVwAoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcABgAAAL8AEgAfAIEB AAAACL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAIgDAQAAAAAAEPAI AAAA0wbUGG8ZXQcPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8CAAAARDUAAKEPJAAAAAMAAAAAABZY AAAGAAYAAQBaAJD/AwAAAAMAQwADAAQABAAQAAAAqg8UAAAAAgAAAAAAAAABAAAABgAAAAkIAAAA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATw4gIAAAIACvAIAAAA/4wJAAAKAADjBgvw ugIAAAQAAAAAAIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAgAAAIcAAQAAAIgAAAAAAIkAAAAA AL8AAAAPAAwB9AAAEA0BAAAAIA4BAAAAIEIBHAAAAEMBlAAAAEQBBAAAAEXBDAAAAEbBFAAAAH8B AQABAIABAAAAAIEBAAAACIIBAAABAIUBAAAAIL8BHAAeAMABAQAACMEBAAABAMMBAAAAIMQBAAAA AMsBn28AAMwBAAAIAM0BAAAAAM4BBgAAAM/BAAAAANABAAAAANEBAAAAANIBAQAAANMBAQAAANQB AQAAANUBAQAAANcBAgAAAP8BHgAeAAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAUCOGMA AAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8C AAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkG AIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUC AAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAA AM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gC AAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAA AH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAIgDBwAAAAMAAwDw/wAAAAAcAEQAAACUAAcA CAACAABAAKwBAACsAQAArACAAAAQ8AgAAABODDkIWgj7DA8ABPCIAAAAQgEK8AgAAAAAjQkAAAoA AAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA zgEGAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMHAAAAAAAQ8AgAAABl C/IAFAIyDA8ABPCIAAAAQgEK8AgAAAABjQkAAAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8A RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AiAMHAAAAAAAQ8AgAAABODGQCKwhODA8ABPCIAAAAQgEK8AgAAAACjQkA gAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGf bwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMHAAAAAAAQ8AgA AACOEeoD7ASPEg8ABPCIAAAAQgEK8AgAAAADjQkAgAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAA AA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AiAMHAAAAAAAQ8AgAAAD2DDIFMAgeEQ8ABPCIAAAAQgEK8AgAAAAE jQkAgAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI ywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMHAAAAAAAQ 8AgAAAAeEf8ENwWFEQ8ABPCIAAAAQgEK8AgAAAAFjQkAAAoAAAMBC/BgAAAAhQACAAAAhwABAAAA vwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMHAAAAAAAQ8AgAAAA7DB0CZAJTDA8ABPCIAAAAQgEK8AgA AAAGjQkAgAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEB AAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMHAAAA AAAQ8AgAAAB4DDoCWgj4Dw8ABPCIAAAAQgEK8AgAAAAHjQkAAAoAAAMBC/BgAAAAhQACAAAAhwAB AAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAI PwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMHAAAAAAAQ8AgAAAAYD7EAyQHADw8ABPCIAAAAQgEK 8AgAAAAIjQkAAAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAA wAEBAAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMH AAAAAAAQ8AgAAADAD8kBOgL4Dw8ABPASAQAAogwK8AgAAAAJjQkAAAoAABMBC/BmAAAAgAAchHAC gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwAGAAAAvwASAB8AgQEAAAAIvwEcAB4AwAEB AAAIywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8AiAMHAAAAAAAQ8AgAAAC4CqkAQgFDCw8A DfB8AAAAAACfDwQAAAAEAAAAAACoDwIAAABDMQAAoQ8kAAAAAwAAAAAAFlgAAAYABgABAFoAkP8D AAAAAwBDAAMABAAEABAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKAC UAFQAaACoALwA/ADQAVABQ8ABPASAQAAogwK8AgAAAAKjQkAAAoAABMBC/BmAAAAgABcjnACgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwAGAAAAvwASAB8AgQEAAAAIvwEcAB4AwAEBAAAI ywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8AiAMHAAAAAAAQ8AgAAABwDqkAQgH7Dg8ADfB8 AAAAAACfDwQAAAAEAAAAAACoDwIAAABDMgAAoQ8kAAAAAwAAAAAAFlgAAAYABgABAFoAkP8DAAAA AwBDAAMABAAEABAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPASAQAAogwK8AgAAAALjQkAAAoAABMBC/BmAAAAgAAkBXACgQAAAAAA ggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwAGAAAAvwASAB8AgQEAAAAIvwEcAB4AwAEBAAAIywFq SgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8AiAMHAAAAAAAQ8AgAAADRERMDqwNdEg8ADfB8AAAA AACfDwQAAAAEAAAAAACoDwIAAABDMwAAoQ8kAAAAAwAAAAAAFlgAAAYABgABAFoAkP8DAAAAAwBD AAMABAAEABAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaAC oALwA/ADQAVABQ8ABPASAQAAogwK8AgAAAARjQkAAAoAABMBC/BmAAAAgACwD3ACgQAAAAAAggAA AAAAgwAAAAAAhAAAAAAAhQACAAAAhwAGAAAAvwASAB8AgQEAAAAIvwEcAB4AwAEBAAAIywFqSgAA /wEGAA4AAQICAAAIPwIAAAMAvwIBAA8AiAMFAAAAAAAQ8AgAAACYBagAQgEiBg8ADfB8AAAAAACf DwQAAAAEAAAAAACoDwIAAABBMQAAoQ8kAAAAAwAAAAAAFlgAAAYABgABAFoAkP8DAAAAAwBDAAMA BAAEABAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQAaACoALw A/ADQAVABQ8ABPCIAAAAQgEK8AgAAAASjQkAAAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8A RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAAzgEJAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AiAMFAAAAAAAQ8AgAAACECbYAAQKECQ8ABPDyAgAAAgAK8AgAAAATjQkA AAoAAOMGC/DKAgAABAAAAAAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQACAAAAhwABAAAAiAAA AAAAiQAAAAAAvwAAAA8ADAH0AAAQDQEAAAAgDgEAAAAgQgHAAQAAQwF0AgAARAEEAAAARcEUAAAA RsEcAAAAfwEBAAEAgAEAAAAAgQEAAAAIggEAAAEAhQEAAAAgvwEMAB4AwAEBAAAIwQEAAAEAwwEA AAAgxAEAAAAAywGfbwAAzAEAAAgAzQEAAAAAzgEJAAAAz8EAAAAA0AEAAAAA0QEAAAAA0gEBAAAA 0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEeAB4AAAIAAAAAAQICAAAIAgLLy8sAAwIAAAAgBAIA AAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAA DgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIA AAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAA xAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJA VIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA 1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8 vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAiAMFAAAABQAFAPD/eAF0AsAB MAGAAQgAKAEAAAAAMAALAAwAAgAAQACsAQAArAEAAKwBAACsAQAArACAAAAQ8AgAAAAdBqwAuAL4 CA8ABPCIAAAAQgEK8AgAAAAUjQkAgAoAAAMBC/BgAAAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAA fwEAAAEAvwEAABAAwAEBAAAIywGfbwAAzgEJAAAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AiAMFAAAAAAAQ8AgAAAD4CAoCXgKJCQ8ABPCeAwAAAgAK8AgAAAAXjQkAAAoAAHMI C/BQAwAABAAAAAAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQACAAAAhwABAAAAiAAAAAAAiQAA AAAAvwAAAA8ADAH0AAAQDQEAAAAgDgEAAAAgQgFEAAAAQwEcAgAARAEEAAAARcEMAAAARsEUAAAA fwEBAAEAgAEAAAAAgQEEAAAIggEAAAEAgwEAAAAIhAEAAAEAhQEAAAAghsEAAAAAh8EAAAAAiAEA AAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEAAAAA kgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAAmwEA AAAAnAEDAABAvwEMAB4AwAEBAAAIwQEAAAEAwwEAAAAgxAEAAAAAywGfbwAAzAEAAAgAzQEAAAAA zgEAAAAAz8EAAAAA0AEAAAAA0QEAAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEe AB4AAAIAAAAAAQICAAAIAgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAA CQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIA AAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAg vwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIA AAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA 0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIW AB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAA hgN8vgEAhwMAAAAAiAMKAAAAAwADAPD/DAAAAEQA+AAAABwCBwAIAAIAAEAArAEAAKwBAACsAIBT ACLxHgAAANkB/////9oB/////9sBAAAAINzBAAAAAOEB/////wAAEPAIAAAAWAY+Ao4CzggPAATw ggAAAEIBCvAIAAAAGI0JAAAKAADzAAvwWgAAAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgD CgAAAAAAEPAIAAAAmQUrAkwCXQYPAATwggAAAEIBCvAIAAAAGY0JAEAKAADzAAvwWgAAAIUAAgAA AIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDCgAAAAAAEPAIAAAA0wg1Aj4CUQkPAATwIgEAAKIMCvAI AAAAGo0JAAAKAABDAQvweAAAAIAAUCJwAoEAsqABAIIAWdAAAIMAsqABAIQAWdAAAIUAAgAAAIcA BgAAAL8AEgAfAIEBBAAACIMBAAAACL8BDAAeAMABAQAACMsBn28AAP8BBgAOAAECAgAACD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAIgDCgAAAAAAEPAIAAAAGwn4AfAC5QkPAA3wegAAAAAAnw8EAAAA BAAAAAAAqA8CAAAAc2gAAKEPHAAAAAMAAAAAABAAAAAFAAMAAAABAEMAAQAEAAQADgAAAKoPGgAA AAIAAAAHAAAAAwAJCAAAAQAAAAYAAAAJCAAAAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAF DwAE8CIBAACiDArwCAAAABuNCQAACgAAQwEL8HgAAACAAMzo8gSBALKgAQCCAFnQAACDALKgAQCE AFnQAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAjLAZ9vAAD/AQYA DgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwoAAAAAABDwCAAAAPME+AHwAr0FDwAN 8HoAAAAAAJ8PBAAAAAQAAAAAAKgPAgAAAHNoAAChDxwAAAADAAAAAAAQAAAABQADAAAAAQBDAAEA BAAEAA4AAACqDxoAAAACAAAABwAAAAMACQgAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPAcAQAAogwK8AgAAAAdjQkAAAoAADMBC/ByAAAAgADEJPIEgQCyoAEA ggBZ0AAAgwCyoAEAhABZ0AAAhQACAAAAhwAGAAAAvwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEB AAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMLAAAAAAAQ8AgAAADeBBkI EAmoBQ8ADfB6AAAAAACfDwQAAAAEAAAAAACoDwIAAABzaAAAoQ8cAAAAAwAAAAAAEAAAAAUAAwAA AAEAQwABAAQABAAOAAAAqg8aAAAAAgAAAAcAAAADAAkIAAABAAAABgAAAAkIAAAAAKYPFgAAAPEe AACgAlABUAGgAqAC8APwA0AFQAUPAATwHAEAAKIMCvAIAAAAHo0JAAAKAAAzAQvwcgAAAIAAvOvy BIEAsqABAIIAWdAAAIMAsqABAIQAWdAAAIUAAgAAAIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8B DAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDCwAAAAAAEPAI AAAA3gSCB3sIqAUPAA3wegAAAAAAnw8EAAAABAAAAAAAqA8CAAAAc2gAAKEPHAAAAAMAAAAAABAA AAAFAAMAAAABAEMAAQAEAAQADgAAAKoPGgAAAAIAAAAHAAAAAwAJCAAAAQAAAAYAAAAJCAAAAACm DxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8IIAAABCAQrwCAAAACCNCQBACgAA8wAL8FoA AACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwwAAAAAABDwCAAAANYGwQ8REeYJDwAE8IIA AABCAQrwCAAAACGNCQCACgAA8wAL8FoAAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/ AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwwA AAAAABDwCAAAAPYFSRGDEWEGDwAE8IIAAABCAQrwCAAAACKNCQBACgAA8wAL8FoAAACFAAIAAACH AAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAA AwC/AgEADwD/AhYAHwB/AwAADwCIAwwAAAAAABDwCAAAAGYGERFJEdsGDwAE8IIAAABCAQrwCAAA ACONCQAACgAA8wAL8FoAAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEA AAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwwAAAAAABDwCAAA AOYJwQ8WEYYMDwAE8BwBAACiDArwCAAAACSNCQAACgAAMwEL8HIAAACAAARl8gSBALKgAQCCAFnQ AACDALKgAQCEAFnQAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/ AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwwAAAAAABDwCAAAAN4L2RDREagM DwAN8HoAAAAAAJ8PBAAAAAQAAAAAAKgPAgAAAHNoAAChDxwAAAADAAAAAAAQAAAABQADAAAAAQBD AAEABAAEAA4AAACqDxoAAAACAAAABwAAAAMACQgAAAEAAAAGAAAACQgAAAAApg8WAAAA8R4AAKAC UAFQAaACoALwA/ADQAVABQ8ABPCCAAAAQgEK8AgAAAAljQkAAAoAAPMAC/BaAAAAhQACAAAAhwAB AAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEeAB4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AiAMMAAAAAAAQ8AgAAACGDBERbxFBDQ8ABPAcAQAAogwK8AgAAAAm jQkAAAoAADMBC/ByAAAAgABsN/IEgQCyoAEAggBZ0AAAgwCyoAEAhABZ0AAAhQACAAAAhwAGAAAA vwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AiAMMAAAAAAAQ8AgAAAAWBYgQfxHgBQ8ADfB6AAAAAACfDwQAAAAEAAAAAACoDwIA AABzaAAAoQ8cAAAAAwAAAAAAEAAAAAUAAwAAAAEAQwABAAQABAAOAAAAqg8aAAAAAgAAAAcAAAAD AAkIAAABAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwtAAAAFIA CvAIAAAAK40JAIAKAABTAQvwfgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIcAAQAAAL8AAgAP AAwB8wMzEIEB//8AAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUC nDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAADI CDIAogA4CQ8ABPC6AAAAUgAK8AgAAAAsjQkAgAoAAGMBC/CEAAAABAAAALQAgQAAAAAAggAAAAAA gwAAAAAAhAAAAAAAhwABAAAAvwACAA8ADAHzAzMQgQH//wAAvwEcAB4AwAEBAAAIywFqSgAA/wEG AA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8A EwAi8QYAAAC/AwCCAIIAABDwCAAAAGgJMgCiANgJDwAE8BIBAACiDArwCAAAABCNCQAACgAAEwEL 8GYAAACAANA58gSBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAYAAAC/ABIAHwCBAQAA AAi/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgABAgIAAAg/AgAAAwC/AgEADwCIAwUAAAAAABDwCAAA AKAJewAVASsKDwAN8HwAAAAAAJ8PBAAAAAQAAAAAAKgPAgAAAEEyAAChDyQAAAADAAAAAAAWWAAA BgAGAAEAWgCQ/wMAAAADAEMAAwAEAAQAEAAAAKoPFAAAAAIAAAAAAAAAAQAAAAYAAAAJCAAAAACm DxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8FgAAAAyAArwCAAAAC2NCQAACgAAgwAL8DAA AACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAA AA8F4AgOCXoGDwAE8CkBAADyAgrwCAAAAC6NCQAACgAAUwEL8H4AAACAAKxN8gSBACFlAQCCAJCy AACDACFlAQCEAJCyAAC/ABAAHwBHAffO//9IAY7X//9JAfH7//9KARoZAABLAa7p//9MATAqAABN Aezu//9OAdU4AACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAh/AwAADAAAABDw CAAAAE0GWwtBDz8HDwAN8HsAAAAAAJ8PBAAAAAQAAAAAAKgPDwAAAHNoIHBvcnQgZ3JvdXAgMQAA oQ8WAAAAEAAAAAAAAAgAAAEAEAAAAAAAAgAPAAAAqg8iAAAAAgAAAAcAAAADAAkIAAANAAAABgAA AAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwWAAAADIACvAIAAAAL40JAAAKAACDAAvw MAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAI AAAAPQV2B6QHqQYPAATwKQEAAPICCvAIAAAAMY0JAAAKAABTAQvwfgAAAIAAjFXyBIEAIWUBAIIA kLIAAIMAIWUBAIQAkLIAAL8AEAAfAEcBHF0AAEgBUFn+/0kBclgAAEoBNR0AAEsBCVQAAEwBeYH+ /00BiFgAAE4BFJD+/4EBAAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACH8DCAAMAAAA EPAIAAAABgo2AxgH1QoPAA3wewAAAAAAnw8EAAAABAAAAAAAqA8PAAAAc2ggcG9ydCBncm91cCAy AAChDxYAAAAQAAAAAAAACAAAAQAQAAAAAAACAA8AAACqDyIAAAACAAAABwAAAAMACQgAAA0AAAAG AAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB4AAAAEgAK8AgAAAAyjQkAIAIAAGMA C/AkAAAABAAAAAAAfwAAAAQAgADgT/IEvwEAAAEA/wEAAAEAAQMCeAEAAAAQ8AgAAAAZAFABPhqU Ag8AEfAQAAAAAADDCwgAAAAAAAAADQDyBA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8FIAAABCAQrw CAAAADONCQBACgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAT7fAAD/ARgAGAAB AgIAAAgAABDwCAAAAOIETw1eDvMFDwAE8FgAAABCAQrwCAAAADSNCQBACgAAgwAL8DAAAAAEAAAA WgBEAQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAT7fAAD/ARgAGAABAgIAAAgAABDwCAAAAOIETw1e DvMFDwAE8PIAAAACAArwCAAAADeNCQAACgAAUwEL8KQAAAAEAAAAAABCAREBAABDAYgAAABEAQQA AABFwQwAAABGwRQAAAB/AQEAAQCBAQQAAAiDAQAAAAiGQQAAAAC/AQAAEADAAf8AAADEAQAAAADL AT7fAADNAQAAAADQAQAAAADRAQEAAADUAQEAAADVAQEAAAD/ARgAGAABAgIAAAgDAAMA8P8AAAAA AACIABEBiAAHAAgAAgAAQACsAQAArAEAAKwAgFMAIvEeAAAA2QH/////2gH/////2wEAAAAg3MEA AAAA4QH/////AAAQ8AgAAAC1BFEQYhE9BQ8ABPDpAAAAogwK8AgAAAA4jQkAAAoAAOMAC/BUAAAA gACIGPIEgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwAGAAAAvwASAB8AgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAC4A5wPXRHiBA8ADfBlAAAAAACfDwQA AAAEAAAAAACoDwMAAABBSVMAAKEPGgAAAAQAAAAAAAAAAAAEAAAAAQAGAAEAGQD/AAD+AACqDxQA AAADAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwWAAAAEIBCvAIAAAAOY0J AAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsBPt8AANEBAQAAAP8BGAAYAAEC AgAACAAAEPAIAAAAPQVsDJwPPQUPAATwAgEAAAIACvAIAAAAOo0JAAAKAABTAQvwtAAAAAQAAAAA AEIBzAcAAEMBawEAAEQBBAAAAEXBFAAAAEbBHAAAAH8BAQABAIEBBAAACIMBAAAACIZBAAAAAL8B AAAQAMAB/wAAAMQBAAAAAMsBn28AAM0BAAAAANABAAAAANEBAQAAANQBAQAAANUBAQAAAP8BGAAY AAECAgAACAUABQDw/wAALQAAAIgABgYAAI4GtQDMB2sBCwAMAAIAAEAArAEAAKwBAACsAQAArAEA AKwAgFMAIvEeAAAA2QH/////2gH/////2wEAAAAg3MEAAAAA4QH/////AAAQ8AgAAAA9BY8RWxmp Bg8ABPAKAQAAAgAK8AgAAAA7jQkAAAoAAFMBC/C8AAAABAAAAAAAQgFUCAAAQwETBAAARAEEAAAA RcEYAAAARsEgAAAAfwEBAAEAgQEEAAAIgwEAAAAIhkEAAAAAvwEAABAAwAH/AAAAxAEAAAAAywGf bwAAzQEAAAAA0AEAAAAA0QEBAAAA1AEBAAAA1QEBAAAA/wEYABgAAQICAAAIBgAGAPD/AAAAAAAA tQAtABABBgYTBMsHEwRUCLkDDQAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAIBTACLxHgAA ANkB/////9oB/////9sBAAAAINzBAAAAAOEB/////wAAEPAIAAAAagViEbYZfQkPAATw6QAAAKIM CvAIAAAAPI0JAAAKAADjAAvwVAAAAIAAUBvyBIEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAA AIcABgAAAL8AEgAfAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA IwV9GJcaTgYPAA3wZQAAAAAAnw8EAAAABAAAAAAAqA8DAAAATE9DAAChDxoAAAAEAAAAAAAAAAAA BAAAAAEABgABABkAADPM/gAAqg8UAAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABf A18DDwAE8OkAAACiDArwCAAAAD2NCQAACgAA4wAL8FQAAACAALzP8gSBACFlAQCCAJCyAACDACFl AQCEAJCyAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAAB AgIAAAgAABDwCAAAAGMJeRiTGo0KDwAN8GUAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAExPQwAAoQ8a AAAABAAAAAAAAAAAAAQAAAABAAYAAQAZAAAzzP4AAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAA AACmDwgAAABACAAAXwNfAw8ABPBSAAAAQgEK8AgAAAA/jQkAQAoAAHMAC/AqAAAARAEEAAAAfwEA AAEAvwEAABAAwAH/AAAAywE+3wAA/wEYABgAAQICAAAIAAAQ8AgAAAA9BdQYPhofBg8ABPBSAAAA QgEK8AgAAABAjQkAQAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAH/AAAAywE+3wAA/wEY ABgAAQICAAAIAAAQ8AgAAAB9CdQYPhpfCg8ABPC2EwAAogQK8AgAAABBjQkAAAoAALMAC/COEwAA hQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIgMMaAAAAgcMy EwAAvwMCAAIARAB0AHMAUwBoAGEAcABlAE4AYQBtAGUAAABDAEMARQA0AEUAMwAwADMAMwAxAEUA RAA1ADkAMQBHADkANAA5ADkAMgBFAEMANwA3ADYAOQAyAEAARwA4AEIAMAA4ADUAOQBEAE0AOAA1 AEUAPgBeAEwAMQAxADgAMQAxADEAMQAzACEAIQAhAEIASQBIAE8AQABdAEwAMQAxADgAMQAxADEA MQAzACEAQABCAEAANgAxADcANAAxADEAMABCADMANABDADkAMABDAEcARwBkAHUAaQBkAHMAbwBk AHUALABgAGgAcgAsADEAMAAvAHEAcQB1ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAMQAhAGIAAAAAABDwCAAAAAAA AAABAAEADwAE8BcBAACiDArwCAAAAF6MCQAACgAAIwEL8GwAAACAAJSN3ASBALKgAQCCAFnQAACD ALKgAQCEAFnQAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYA DgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAACgEMAKABdgFDwAN8HsAAAAA AJ8PBAAAAAQAAAAAAKgPEQAAAE1ldHJvIDELKE1QTFMtVFApAAChDxwAAAASAAAAAAAQAAAABQAS AAAAAQBDAAEABAAEABMAAACqDwwAAAASAAAABgAAAAkIAAAAAKYPFgAAAPEeAACgAlABUAGgAqAC 8APwA0AFQAUPAATwSAAAABIACvAIAAAAAYwJAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBFe2i AJQBti56AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABAC8ABfAgAAAAAAAX8AgAAAAIAAAALo0JAAAA F/AIAAAACQAAADGNCQAQAPAHIAAAAMDAwAAAAAAA0v48AAAAAAD/TQAAsvoAAJbSAADMADMADwCI EyYLAAAPAIoTHgsAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixP+CgAAAAAAKwQAAADU+247 HwBE8eIKAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB/FP////8SAAAADwA98Q0AAABA AULxBQAAAAEJAAAAHwBE8Z0KAAAAACfxIAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAJUTAP////8Y AAAADwA98Q0AAABAAULxBQAAAAEEAAAAAABB8RQAAAABAAAAAQAAAAAAAAAAAAAAAwAAAD8AJfEs AAAAAAAo8RAAAAABAAAACQAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAAAAEAAABPACXxLAAAAAAA KPEQAAAAAQAAAAoAAAAAAAAAAAAAAA8APPEMAAAAAAABKwQAAAABAAAAHwBE8XgDAAAAACfxIAAA AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAA AAAAAAAAAAAAAAAA/////x8AJfEYAAAAAAAo8RAAAAACAAAAAQAAAAIAAAAAAAAAHwBE8QADAAAA ACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAA KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGoAgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA AAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAwAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEA AAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBF8RwBAAAA ACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98TEAAADQAELxAgAAAAAB IABC8QUAAAABAQAAAGAAQvEFAAAAAQEAAABQAELxBQAAAAECAAAADwAx8bMAAAAAADrxCAAAAAEA AAABAAAAEABC8Q8AAAADaABpAGQAZABlAG4AAAAPACrxhAAAAAAAM/EQAAAABAAAAAAAAAAAAAAA AAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8A PfENAAAAYABC8QUAAAABAQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAAuMCQD//////////x8A RPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx 8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz 8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBp AGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAC4wJAP//////////HwAl8RgA AAAAACjxEAAAAAAAAAAAAAAAAAAAAPMBAAAfAETxGAQAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD///// HwBE8dwBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAf ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAA AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACg AELxBQAAAAEAAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAP ADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAA ADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBz AGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAABqjAkA//////////8fACXx GAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA8wEAAB8ARPHcAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAAD AAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAPQB AAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAA AEABQvEFAAAAAQMAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAfACXx GAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA0AcAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAAD AAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REA AAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsA AAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsq FAAAAAAAAAABAAAAoowJAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAPMBAAAf AETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8dwBAAAAACfxIAAAAAAAAAAAAAAAAAAA AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA AAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0 AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAA AAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELx EQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7x KwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA +yoUAAAAAAAAAAEAAACKjAkA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA8wEA AA8AAisAAAAAAAByFygAAAABABAAAAAAAAUAEABgLgAALAAQAJA0AABAABAAFyYAALgBEAA4OQAA AAD1DxwAAAB8AQAApBkAAwAAAABpYwEAAQAAAP4BAAABAMUxAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAA AAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAA/v////7///////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////v8AAAUBAgAAAAAA AAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rpgCAABU AgAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAoAAAAAQAAADIAAAABgAAANAAAAAHAAAA2AAAAAgA AADgAAAACQAAAOgAAAAKAAAA8AAAABcAAAD4AAAACwAAAAABAAAQAAAACAEAABMAAAAQAQAAFgAA ABgBAAANAAAAIAEAAAwAAADyAQAAAgAAAOn9AAAeAAAACAAAAEN1c3RvbQAAHgAAACAAAABIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLixMdGQuAAAAAAMAAAC9YwEAAwAAAFQAAAADAAAAAQAAAAMAAAAA AAAAAwAAAAAAAAADAAAAAAAAAAMAAABkHwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAACQAAAAYAAABBcmlhbAALAAAATVMgUEdvdGhpYwAHAAAA5a6L5L2TAAoAAABXaW5nZGlu Z3MADQAAAFRyZWJ1Y2hldCBNUwAOAAAARnV0dXJhQSBCayBCVAAQAAAAVGltZXMgTmV3IFJvbWFu ABMAAABodWF3ZWktdGVtcGxhdGUtbXYARgAAAEVWQyBkaWZmZXJlbnRpYXT+/wAABQECAAAAAAAA AAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAD0VAAADAAAAAEAAABoAAAAAgAAAHAA AAAEAAAAsAAAAAcAAADAAAAACAAAANwAAAAJAAAA7AAAABIAAAD4AAAACgAAABgBAAAMAAAAJAEA AA0AAAAwAQAADwAAADwBAAARAAAARAEAAAIAAADkBAAAHgAAADgAAABFVkMgY29ubmVjdGlvbnMs IEVWQy1BSVMgYW5kIEVWQy1MT0MgYWxhcm0gc3VwcHJlc3Npb24AAB4AAAAIAAAAVmlzc2VycwAe AAAAFAAAAGh1YXdlaS10ZW1wbGF0ZS1tdgAAHgAAAAgAAABWaXNzZXJzAB4AAAAEAAAANzAzAB4A AAAYAAAATWljcm9zb2Z0IFBvd2VyUG9pbnQAAAAAQAAAAPASpu0GCAAAQAAAAKC+TXJOzcgBQAAA AMB+rYu+wckBAwAAAHcAAABHAAAAqFMAAP////8DAAAACACJEGcMAAABAAkAAAPMKQAAAQChJwAA AAAEAAAAAwEIAAUAAAALAgAAAAAFAAAADALRAsEDCQIAAPcAAAMCAQAAAACAAAAAAIAAAICAAAAA AIAAgACAAACAgADAwMAAwNzAAKbK8AAEBAQACAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVV VQBNTU0AQkJCADk5OQD/fIAA/1BQANYAkwDM7P8A79bGAOfn1gCtqZAAMwAAAGYAAACZAAAAzAAA AAAzAAAzMwAAZjMAAJkzAADMMwAA/zMAAABmAAAzZgAAZmYAAJlmAADMZgAA/2YAAACZAAAzmQAA ZpkAAJmZAADMmQAA/5kAAADMAAAzzAAAZswAAJnMAADMzAAA/8wAAGb/AACZ/wAAzP8AAAAAMwAz ADMAZgAzAJkAMwDMADMA/wAzAAAzMwAzMzMAZjMzAJkzMwDMMzMA/zMzAABmMwAzZjMAZmYzAJlm MwDMZjMA/2YzAACZMwAzmTMAZpkzAJmZMwDMmTMA/5kzAADMMwAzzDMAZswzAJnMMwDMzDMA/8wz ADP/MwBm/zMAmf8zAMz/MwD//zMAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYAADNmADMzZgBmM2YA mTNmAMwzZgD/M2YAAGZmADNmZgBmZmYAmWZmAMxmZgAAmWYAM5lmAGaZZgCZmWYAzJlmAP+ZZgAA zGYAM8xmAJnMZgDMzGYA/8xmAAD/ZgAz/2YAmf9mAMz/ZgD/AMwAzAD/AACZmQCZM5kAmQCZAMwA mQAAAJkAMzOZAGYAmQDMM5kA/wCZAABmmQAzZpkAZjOZAJlmmQDMZpkA/zOZADOZmQBmmZkAmZmZ AMyZmQD/mZkAAMyZADPMmQBmzGYAmcyZAMzMmQD/zJkAAP+ZADP/mQBmzJkAmf+ZAMz/mQD//5kA AADMADMAmQBmAMwAmQDMAMwAzAAAM5kAMzPMAGYzzACZM8wAzDPMAP8zzAAAZswAM2bMAGZmmQCZ ZswAzGbMAP9mmQAAmcwAM5nMAGaZzACZmcwAzJnMAP+ZzAAAzMwAM8zMAGbMzACZzMwAzMzMAP/M zAAA/8wAM//MAGb/mQCZ/8wAzP/MAP//zAAzAMwAZgD/AJkA/wAAM8wAMzP/AGYz/wCZM/8AzDP/ AP8z/wAAZv8AM2b/AGZmzACZZv8AzGb/AP9mzAAAmf8AM5n/AGaZ/wCZmf8AzJn/AP+Z/wAAzP8A M8z/AGbM/wCZzP8AzMz/AP/M/wAz//8AZv/MAJn//wDM//8A/2ZmAGb/ZgD//2YAZmb/AP9m/wBm //8ApQAhAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx8fEA+Pj4AP/7 8ACgoKQAgICAAP8AAAAA/wAA//8AAAAA/wD/AP8A////AAAAAABAAAAAYgAAAAQAAAA0AgAABAAA AAcBAwChJwAAQQsgAMwAeACgAAAAAADQAsADAAAAACgAAACgAAAAeAAAAAEACAAAAAAAAEsAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAMDcwADwyqYABAQE AAgICAAMDAwAERERABYWFgAcHBwAIiIiACkpKQBVVVUATU1NAEJCQgA5OTkAgHz/AFBQ/wCTANYA /+zMAMbW7wDW5+cAkKmtAAAAMwAAAGYAAACZAAAAzAAAMwAAADMzAAAzZgAAM5kAADPMAAAz/wAA ZgAAAGYzAABmZgAAZpkAAGbMAABm/wAAmQAAAJkzAACZZgAAmZkAAJnMAACZ/wAAzAAAAMwzAADM ZgAAzJkAAMzMAADM/wAA/2YAAP+ZAAD/zAAzAAAAMwAzADMAZgAzAJkAMwDMADMA/wAzMwAAMzMz ADMzZgAzM5kAMzPMADMz/wAzZgAAM2YzADNmZgAzZpkAM2bMADNm/wAzmQAAM5kzADOZZgAzmZkA M5nMADOZ/wAzzAAAM8wzADPMZgAzzJkAM8zMADPM/wAz/zMAM/9mADP/mQAz/8wAM///AGYAAABm ADMAZgBmAGYAmQBmAMwAZgD/AGYzAABmMzMAZjNmAGYzmQBmM8wAZjP/AGZmAABmZjMAZmZmAGZm mQBmZswAZpkAAGaZMwBmmWYAZpmZAGaZzABmmf8AZswAAGbMMwBmzJkAZszMAGbM/wBm/wAAZv8z AGb/mQBm/8wAzAD/AP8AzACZmQAAmTOZAJkAmQCZAMwAmQAAAJkzMwCZAGYAmTPMAJkA/wCZZgAA mWYzAJkzZgCZZpkAmWbMAJkz/wCZmTMAmZlmAJmZmQCZmcwAmZn/AJnMAACZzDMAZsxmAJnMmQCZ zMwAmcz/AJn/AACZ/zMAmcxmAJn/mQCZ/8wAmf//AMwAAACZADMAzABmAMwAmQDMAMwAmTMAAMwz MwDMM2YAzDOZAMwzzADMM/8AzGYAAMxmMwCZZmYAzGaZAMxmzACZZv8AzJkAAMyZMwDMmWYAzJmZ AMyZzADMmf8AzMwAAMzMMwDMzGYAzMyZAMzMzADMzP8AzP8AAMz/MwCZ/2YAzP+ZAMz/zADM//8A zAAzAP8AZgD/AJkAzDMAAP8zMwD/M2YA/zOZAP8zzAD/M/8A/2YAAP9mMwDMZmYA/2aZAP9mzADM Zv8A/5kAAP+ZMwD/mWYA/5mZAP+ZzAD/mf8A/8wAAP/MMwD/zGYA/8yZAP/MzAD/zP8A//8zAMz/ ZgD//5kA///MAGZm/wBm/2YAZv//AP9mZgD/Zv8A//9mACEApQBfX18Ad3d3AIaGhgCWlpYAy8vL ALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAPj4+ADw+/8ApKCgAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8A//////////////////////////////////////////////////////////// ////vP+84t3i3eLd4rwAAP8A/wAAvP8AAAAAAP8AAAD/AAAA/7wAAAC8/7ww+/v7+7z/AAAA/wD/ AAC8AAD/vP+8/23///////////////////////////////////////////////////////////// //////////////////////////8xMTExMTH//////////zExMTExMTH///////////+8/+Li3eLi 4t3/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/+/v7+/v/vP+8/7z/vP+8/7z/vP+8/7yS ////MTExMTExMf//////////MTExMTEx//////////////////////////////////////////// ////////////MTEx//8x////////////MTEx//8x//////////+8/7zi4v/d4t3/vP+8/7z/vP+8 /7z/vP+8/7z/vP+8/7z/vP+8/7z/vP/l++X/vP+8/7z/vP+8/7z/vP+8/7z/bf////8xMTH//zH/ /////////zExMf//Mf///////////////////////////////////////////////////////zH/ //8xMf///////////zH///8xMf//////////////VVVVVVVVVf+8////vP///7z///+8////vP// /7z///+8////vP///7z///+8////vP///7z///+8////vJL/////Mf///zEx//////////8x//// MTH//////////////////////////////////////////////////////3QxMTExMTH///////// /zExMTExMTH//////////7z/vFVVVVVVVVW8ALz/AP8AALz/AAAAAAD/AAAA/wAAvAC8/wAAAP+8 /7z7vP+8/wAAAP8AAAD/AAAAAAD/vP9t////MTExMTExMf////////90MTExMfsx//////////// //////////////////////////////////////////96MTAxMTEx//////////8xMTExMTEx//// ////////vP///7z/vP+8////vP+8/7z///+8/7z/vP///7z/vP+8////vP+8/7z/+zC8/7z/vP// /7z/vP+8////vP+8kv///zH7MTExMTH/////////ejEx5fv7Mf////////////////////////// ////////////////////////////dDH7+zAx3ZL/////////MTHiMTH7+///////////vP+8n5+f n5+fn7z/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/+/v7/7z/vP+8/7z/vP+8/7z/vP+8 /23///8x+/v73ZIx/////////3TiMTEx5TH///////////////////////////////////////// /////////////3ox+zEx4gDikv///////zHi3eIx5fv//////////////5+fn5+fn5//vP///7z/ //+8////vP///7z///+8////vP///7z///+8////vP///7z///+8////vP///7yS////Mfvl4uLi kv/////////i3eL///////////////////////////////////////////////////////////// ///////dAN2S///////i3eL///////////////////////////////////////////////////// ///////////////////////////////////////////////////////////d4t2S///////i3QD/ AAAA/////////////////////////////////zExMTExMf///////////////wD/AP///+Li4pL/ ////3eL///////////////////////////////////////////////////////////////////// /////////////////////////////////////////////+Li4pL/////3QD//wAA/wD///////// //////////////////////8xMTH//zH///////////////8A//8A////3eLdkv//3eL///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////8x3eLdkjEx3eIA//8xMf////////////////////////// ////////Mf///zEx/////////////////////zExMTHi4uIx3eLiMTH///////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////MTHi4uIx3eIAMTExMTH//////////////////////zExMTExMTH//zExMTEx Mf///////////////////3T/MTExMd0AMTHdMTEx//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /zExMd0xMTEAMTH/MTEx////////////////////////MTEx//8x///7+/sxMTH///////////// vP+8/7x6//8xMTExMAD7+zAxMf+8/7z/vP+8/7z/vJL///////////////////////////////// ////////////////////////////////////MTExMTExMTExMTH/vP+8/7z/vP8xMTEw+/sAMDEx /zExMbz/vP+8/23//////////////zH///8xMf//MfswMTEx/////////7y8vP+8vLz/dDH/MTEx +/v7APv7+zG8/7y8vP+8vLz/vLy8//////////////////////////////////////////////// /////////////////////zEx/zExMf//MTExvP+8vLz/vLy8MTH7+/sA+/swMf//MTG8vP+8vLz/ vP///////////zExMTExMTH//zH7MeKRMf//MTExMTExMTExMbz/vHox/zExMeX7+wD7+zGfc7z/ vP+8/7z/vP+8/7z///////////////////////////////////////////////////////////// //////8xMf8x////MTExMf+8/7z/vP+8n5+f5fsA+/vln5+fczExvP+8ejExMTExMTExMf/////i MTEx+zAx//8xMTHd4t3irjH/MTEx//8xMTG8vLx0MTExMTExMTExADGfn5+fn7y8vLy8vLy8vLy8 vJL/////////////////////////////////////////////////////////////////MTExMTEx MTExMTG8vFCfn5+fn5+fnzEAMTExMZ+fn5+fn59QvHQx/zExMf//MTH////i3eIx5fswMf//eXp5 et3i4uLdkjH///8xMTExvP+8ev//MTExMTExMQByMcKfn5+fn3L/vP8xMTExMTExMTExMf////// /////////////////////////////////////////////////////zExMTExMTExcp+fn5+fn5+f n5/DMTExAJ8xMTExMcKfn5+fn5+fn59y////MTEx/93i4uIxMTExMTH//////////+Ld4t0xMTAx MTExMby8/3QxMTExMTExMcKfADExvP+fn5+fn5+8MTH/MTEx//8xMTH///////////////////// //////////////////////////////////////8xMTExMTExMZ+fn5+fn8K8/7y8vDExAJ+fMTEx MTExMTExwp+fn5+fczExMTEx4t3i3f8xMTExMTEx/////////////zExMeX7MDExMTG8/7z/vP+8 /7z/vP+8n5+fvP+8/7zDn5+fn59z/zH///8xMTEx//////////////////////////////////// //////////8nT0lPVVVVVVVVVVVVMTH7+zHCwzH/vP+8/7z/vP+8AJ+fvP+8/7z/vP+8/7z/vHox wzEx+/sx4t3i4v//////////////////3eLd4t3i3TH7+zAxn59Qc7y8vLy8vLz/vLy8vLyfn3O8 vLy8vLy8n5+fn58xMTExMTExMf////////////////////8nSSdPVVVVVVVVVVVVVVVVVVVVVVVV VVVVVVVVVVVVVTHl+/sxn5+fn5+fn5+fn5+fAJ+fn5+fn5+fn5+fn5+fn5+fn59yMfv7MTHi//// /////////////////+Ld4uLi3eIx+/v7MZ+fn5+fn5+fn5+fn5+fc3L/wp8A/7z/vP+8/7z/wp+f MTH7MDEnTydPVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVl56Xnv////8xMTEx +wAAMQCfn58AAAAAAAAAAACfnwAAAAAAAAAAn5+fAAAAAAAAAAAA+zAxMf////////////////// /////////zExMfsA+zHCw5+fn5+fn5+fn5+fn5+fn5+fnwCfn5+fn1BzcjExMTEx+/sxVVVVVVVV VVVVVVVVVVVVVVVVVVVVl56Xnv//////////////////////////////VVUxAAD7+zExMTG8/7y8 vP+8vACfnyoqKiqfKioqKrz/vLy8/3QxMTEx+wAxMTH/////AAAA//////////////////+RkgAA +wAAn3IxvP+8/7z/vP+8w8LDn5+fn5+fAJ+fn5+fn5+fn58x5fv7MVVPl56Ynv////////////// ////////////////////////////////////////VVVVMTHl+/sxMXMx/7z/vP+8/wCfn3kqKiqf n3MqKir/vP+8/7x6MZ8xMfv7ADHd4pH//wAA/wAxMTH////////////d4gAx5fsxMQCfn7y8vLy8 vLy8vLwqKioqn58qnwBQvJ/Cn5+fn5+fMfv7+zFVVVX///////////////////////////////// ////////////////////////VVVVMTExMfv7MZ+fn1C8vLy8vLwAn7xzKioqn5+fKioqvLy8vLy8 n5+fnzH7+zEAAAAAAOLd4jEx+zAx//8xMTExMeLi4t0xMTExMTHDn5+fn7z/vP+8/7z/KioqKp+f KsOfn7z/vP+8/zExMTHl+/sxl1VVVf////////////////////////////////////////////// ////////VVUAADFVTzExn58xn5+fn/+8/7wAn/+8eSoqKp+fnyoqKv+8/7xzn5+fnzGfnzExMTH/ 3eIAADHl+/swMf//MTExkeIAAP8xMTExMTExMTGfnwCfULy8/7y8vCoqKiqfn3Iqn5+fvP+8vLwx n58x5fv7MU8nVVVV////////////////////////////////////////////////////VVUA/zFV VScxMZ+fczHCn5+fn7wAn5+8/3MqKiqfn1AqKiq8/7yfn5+fMTGfn3IxMTEx/////zExMTHlMTH/ /zEx4gAA4v//MTExMTExMTExMbyfAACfc7z/vP8qKioqn58qKiqfnwC8/7yfn5+fMTH7MZ5VVTFV VVUn////////////////////////////////////////////////VVUA//8xVVUxMTHCn58xMf+f n5/DAJ+8/7x5Kioqn58qKioq/5+fn5+8ejExn58xMTExMf////8xMTExMTEx//8x+zHdMTH///// /7y8vLy8vLz/vMKfn5+fvP+8KioqKp+fKioqn58AvJ+fn5+fMTExMTExVVUx/5hVVVX///////// //////////////////////////////////9VVVUA////VVVP/7y8/5+fvLy8vLyfAJ+fc7y8cyoq KiqfKioqn5+fn7y8vLz/vJ+fvLyS/////////zExMf//Mf//Mfsw////////////vP+8/7z/vP+8 /8KfAJ9y/yoqKiqfnyoqKiqfnwCfn8MxMTExMZ+fMZdVVf//nlVVVf////////////////////// //////////////////9VVVUA/////1VV//+8/7yfn/+8/7z/AJ+fn5+fvHkqKioqKiqfn5+fvP+8 /7z/vP+fn7z/bf////////8x////MTH///v7+wD/AP//////vP+8vLz/vLy8/7y8vJ8AAJ9zKioq KioqKiqfn5+fn7y8MTExMTGfnzExVVX/////VVVVSfj/vLz4+Pj4+Pj4+Lz/vPi8/7z4vP+8+Pj4 +PhVVVX//////1VVJ////7y8n5+8vLz/AJ+f/5+fn59QKioqKp+fn58qvP+8vLz/vLy8n5+8vJL/ //////8xMTExMTEx//8xMTEA//8A//////+8/7z/vP+8/7z/vP+8/58An58qKir/Kp+fn5/Dn59y /7z/vP+8n5///1VVT/////9VVVVPvP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP9VVVX/vP////9V Vf///7z/vJ+f/7z/wgCf/7z/vJ+fn59zn5+fn8IqKv+8/7z/vP+8n59zvP+S//////////////// ////MTEx//8x//////+8vLy8vLy8vLy8vLy8vLy8n5+fn5//n5+fn5+8vMKfn7y8vLy8vJ+f//// VVX///+8vJdVVVW8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLxVVQC8vLy8bf9VVUn///+8vJ+fn7y8 vACfvLy8vLy8vJ9zn5+fn7y8vLy8vLy8vLy8vJ+fULy8kv///////////////////zH///8xMf// /////7z/vP+8/7z/vP+8/7z/vP90n58An3Ofw3T/vP+8n58AvP+8/7yfn////1VVJ////7z/l1VV Vbz/vP+8/7z/vP+8/7z/vP+8/7z/vP9VVQD/vP+8//j/VVX/////vP+fn7z/vACf/7z/vP+8/7yf n5+fn5//vP+8/7z/vP+8/7zDn5+8/23///////////////////8xMTExMTH//////7z/vLy8/7y8 vP+8vLz/vLy8/5+fnwAAn7z/vLy8/7yfnwC8vLz/n5////+YVVX/vLz/vLy8VVVVJ/+8vLz/vLy8 /7y8vP+8vLz/vElVVQC8vP+8vLz/VVUn//////+fn5//vJ8An7y8vP+8vJ+fn5+8w5+fn3O8vLz/ vLy8/7y8vJ+fvLyS////////////////////////////////////vP+8/7z/vP+8/7z/vP+8n5+f n8PCn5+fn/+8/7z/wp8A/7z/vJ+f/////1VV+Lz/vP+8/7xVVVVJ/7z/KioqKipzKioqKrz/vFVV AAD/vP+8/7z/vFVV/zExMTExn58xMZ8An7z/vP+8n5+fnyqfKioqn5+fn3L/vP+8/7z/vP+fn7z/ kv//////////////////////////////MTExMTExMTExMf+8vLy8vCqfn5+fnyoqKirDn58Ac7y8 vP+fn5+8vLyfn/////+XVVX/vLy8vLy8vJ5VVVW8vCoqKiqfnyoqKir/vFVVALy8vP+8vLy8vFVV T/8xMTExMTExMTEAn7y8vP+fn5+fKiqfn1AqKiqfn5+fn7y8vLy8dDExn58xMTExMf////////// /////////////////zH/MTEx//8xMTG8/7z/vJ+fn5/Dn58qKioqvP+fnwCfcv+8/5+fcjExn58x MTEx/1VVvP+8/7z/vP+8/1VVVf8qKioqn58qKioqvFVVVbz/vP+8/7z/vP9VVbxtMTExMTH7MTEA nzH/vJ+fn5/DKioqn5+fKioq/7zDn5+fc7z/vHoxMZ+fcjExMTH/////////////////////3eKu //8x/zH///8xMTExvLz/n5+fn58qKp+fKioqKry8/7yfAJ+fvLwxn58AMZ+fMTExMf9VVU+8/7y8 vP+8vLz/VVVVTyoqKp+fcioqKlVVc1Bycp+fn5+fn5+fn5+fn5+fnzEx+/sAAJ8xn5+fn5//cyoq Kp+fnyoqKrz/vLyfn5+fcv90MTHDnzExMTEx/////////////////////+Li4t3iMTExMTExMTEx Mbyfn5+fwyoqKiqfn3IqKiq8/7z/vMOfn5+fMcOfADExMTExMTH//1VV/7z/vP+8c3Jzcp+fn5+f n5+fn5+fn5+fAJ+fn5+fn5+fn5+fn5+fn5+fn58xAAAAMTFzn5+fn7z/vHkqKiqfn58qKir/vP+8 /7yfn5+fejExMTExMTExMf///////////////////////93i3eLdMTH7MTExMZ+fn5+fvLwqKioq n58qKioqvLy8vLy8vJ+fAABQMTEA+zAxn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn58AAJ+f n8Ofwry8vLy8VVVJ+Ly8MTFzAAD7+zGfn5+fvLy8vLxzKioqn59QKioqvLy8vLy8vMOfn5+fMTEx +/sxMTH////////////////////////////d4jH7+zAxn5+fn8O8/7z/KioqKp+fKioqKrz/vP+8 /7z/vJ+fAJ8xMQD7MZ+fn5+fn5+fn5+fn5+fn8PCw7z/KlVVVSefVVUAKrz/vP+8/7z/vP+8/1VV vPi8/zGfAHMA+/sxn58x/7z/vP+8eSoqKsOfKioqKv+8/7z/vP+8/8Kfn59yMfv7MTEx/////zEx MTExMTH/////////////MTEx+/v7MZ+fn7y8/7y8vCoqKiqfnyoqKiq8vP+8vLz/vLy8w5+fMeUA +zExMTH///hVVf+8vLz/vLy8/7y8vCoqVVVVVVUAKiq8vP+8vLz/vLy8/1VVJ//4vLyfAJ8A5fv7 MTExMbz/vLy8/3MqKioqKioqKiq8/7y8vP+8vLz/dJ+fczH7+zExMf////8xMTExMTEx///////i 4uLd4uLiMfv7+zHDMTG8/7z/vP8qKioqKioqKioqvP+8/7z/vP+8/zExMTH7APsxMXMx//+8l1VV /7z/vP+8/7z/vP8qKiqeVVUAKioqvP+8/7z/vP+8/7xVVf+8+LyfAJ9yADH7MZ+fn5+fn5+fn5+f n3Nyc3JzKioq/7z/vP+8/7z/vHoxwzHl+/sw/93i4uLd4pExMfswMf//////3eLd4t3i3TH7+wAx n5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn58x5QD7MZ+fn///kv9VVby8vLy8/7y8vLy8 KioqVVVVVVUqKv+8vLy8vLy8/7y8VVW8vPgAAJ8xAJ8xMTGfn5+fn5+fn5+fn5+fn5+fn5+fn5+f n5+fn5+fn5+fn59yMfv7Md3i3eLd4t2RMeX7MDH//zExMTExMf//MTEx+wAxAAAAAJ+fnwAAAACf n58AAAAAn5+fAAAAAJ+fnwAAAACfMTH7+zHCn5+f/228VVX/vP+8/7z/vP+8/3R5VVVVeVVVVU+8 /7z/vP+8/7z/vFVVVbwAn58xnwAAAAAxMTExMf+8/7z/wsPCw8Kfn5+fn5+fn5+fn5+fn5+fn5+f cjH7+zExMf////8xMTExMTEx//8xMTH//zH//+LdADH7MTExMTG8vP+8vLwqKioqKioqKioqvLz/ vLy8/7y8vDExMTEx+zExn5+fn59QvFVVvLy8/7y8vP+8vLz/VQAA/7y8VVVVT7z/vLy8/7y8vP+8 VZ8An7y8MQCfAAAxMTExMTG8/7y8vP+8vLz/vLy8/7y8vP+8vLz/vLy8/3QxMTEx5TExMTH///// MTExMTExMf//Mf///zEx/+Li4jExMTExMTExvP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP8xMQAx MTExw5+fn5+fn59VSf+8/7z/vP+8/7xVVQC8/7z/vP+YVVVVvP+8/7z/vP+8/58An/i8/58A/zEx Mf//MTEx/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7x6MQAxMTH//zEx//////8xMTH//zH//zEx MTExMeIA4jExMTExAAAAAAAAvAC8AAC8ALy8AAC8ALwAvAAAALwAvAAAADEAMTEx///Cn5+fwp+f n7y8vLy8vLy8vLxVVQC8vLy8vLy8vJdVVVUqcyoqKiq8vJ8An1UnvLwAn/8x////MTExMbwAAAAA AAC8ALwAALwAALwAALwAAAAAvLy8ADEAMf///zExMf//////Mf///zEx//8xMTEx3eIA/3l6eXp5 egB6AAAAALwAvAAA/7wAvAAAAAD/AAAAAAD/AAAAAAAxADH///8xMcOfn59Vn5+fc7z/vP+8/7xV VQC8/7z/vP+8/7x5KlVVVSdzKioq/wAAn55VVbyfAHp5enl6eXp5enn/AP8AAAAAvAC8AAD/vAC8 AAAAAAAAAAAAvAAAAHl6eXp5enn/////enl6eXp5////MTExMQAA//////////+8vP+8vAD/vLy8 /7wAAP+8AAAAvAC8/7y8vP+8vLwAMQAxMTExMTExwp+fn1Wfn5+fvP+8vLxVVQC8/7y8vP+8vLz/ cyoqVVVVVSoqKgCfn7y8VVVJAJ////////+8/7y8vP+8vLz/ALy8/7y8vAAAvLwAAAAAAAC8AAAA AAD//////////////////////////zH7Mf///////////////////7z/vP+8/7z/vP+8/7z/vP+8 /7z/vP+8/7z/vP/////////////Dn5+f/8Kfn5+8/7xVVQAqn3IqKiq8/7z/vHkqKiqeVVVVnwCf vP+8/5hVnwD4////////////vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z///////////// ejExMTExMf////8x+/sA//////////////////////////////////////////////////////// /////////////8Kfn5+8vJ+fn1BVVVUqKp+fKioqvLy8vLxzKioqn59VnwCfvLy8vLy8VQCf+P// //////////////////////////////////////////////////////////////8xMTH//zH///// 5eXlAP///////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////////////////55V w5+fn/+8n5+fACoqKsKfnyoqKrz/vP+8eSoqKp+fnwCfVU+8/7z/vJ8AVf////////////////// ////////////////////////////////////////////////Mf///zEx/////zExMf////////// /////23/vAD//////////////////////////////wC8/7yS//////////9VVfjDn5+fvFXDAJ+f Kiqfn58qKir/vLy8/3MqKiqfnwCfl1VVVby8vP8An1VP//////////////////////////////// ////////////////////////////////dDExMTExMf///////////////////////7z/vP8A//// //////////8A//////////////8A/7z/vP+S////////VVX4vMOfn59VAMOfn59zwp+fKioqvP+8 /7x5KioqAACfKiqXVVVVvP+fALxVVf////////+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/ vP+8/7z//////////3oxMTH7+zH///////////////8xMTExMTExMTExAP8A/wD//wAAAAAAAP8A AAAAAAD/AP//ALy8vLy8vG3/////VVX/+Ly8wp+fALy8vJ+fn3OfnyoqKry8vLy8cypQAJ/DKioq KrxVVVUnAJ+8VVVVMTExMTExMTExvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vJL///// ///d+TEx+/sx////////////////Mf8xMTH//zExMQD/AP//////AP//AAD//wD//////wD//wAA MTExMTExMTExMVVV//i8/1UAAJ+f/7wqwp+fnyoqKiq8/7z/vHmfAJ////8qKir/vFVVnwD/vP9V Vf8xMTH//zExMf+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vP+8/zExMTExMTExMf/d4sf5x3rHx/// x////////////zH/Mf///zExMTEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEx/zExMf//MVVV ///4vFVVVcKfn7y8Kiqfn5+fKioq/7y8vP+fAJ8qKioqKioqvP+8mACfVby8VVVVMf///zExMTG8 /7y8vP+8vLz/vLy8/7y8vP+8vLz/vLy8/3QxMTExMTExMTHd4t3H//n5///Hx///MTEAAAD///8x MTExMTExMTExvP+8/7z/vP+8/7z/vP+8/7z/vP+8/7z/vAAxMf8x////MTFVVf//+FVVVf+8n5// vCoqKiqfn59yKrz/vP+fAJ//vP+8/7z/vP+8/58AVVVV/zFVVTExMTExMTEx/7z/vP+8/7z/vP+8 /7z/vP+8/7z/vP+8/7x6MTExMTExMeLd4uL/xzH5x/n5x8f///v7////AP//MTExMfsxMZ+fn3NQ clBzULy8/7y8vLy8vLz/vLy8vLy8vP8AMTExMTExMTFVVU//VVUAvLy8n59yvP8qKir//5+fn5+8 vLwAAJ//vLy8vLy8vP+8vLyfAHJVVVVJl1VVMTAxMTExMby8vP+8vLy8vLy8/yoqKioqKioqKiO8 vLy8dDExMTExMDHd4v///8f5+THHx/kxx/8x+zExMTH//zExMQD7MDGfn5+fn5+fn5+fn5+fn5+f n5+fn5+fn5+fn5+fAHJzcnNyMTExVVUxVVUAvP+8/5+fvP+8dHR5dHR0w5+fn/8An5//vP+8/7z/ vP8A/7z/wgCf+FVVVU9VMTH7+zGfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn3Ix+/sx MTH////5+fn5//8x+fn/MfsxAAAAAAAAAAAA+wAAAMOfw8LDn5+fn5+fn5+fn5+fn5+fn5+fn5+f nwCfn5+fczExl1UnVQAAkry8/5+fvP8AAAAAALwAALwAn58AcgD/vAAA/7y8AP+8ALz/vLyfAPi8 l1VVVTHl+/sxn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5/5+fn5+fn5+fn5+fn5+fkx MDH//zExMQAAAAAAAAAAAAAAAJ9yMbz/vP+8/7z/vP8qKioqn58qKioqvP+8/8IAwsPCnzH7+zEx VQBV//+8/7yfn/+8ALwAAAC8AAD/vJ8An5+fAAAA/wAAvAAA/wD/vP+8nwCfvP8xVVUx+/v7MTEx Mf+8/7z/vP+8/7z/vCoqKp+fnyoqKiP/vP+8evn5MQAAAAAAAAAA+fn5+fn5+zAx//8x+zEx//// /zExMfsAMAAAn5+8vLy8vLy8vLy8KioqKp+fKioqKry8vLy8ADExnzHl+/sxVQBV////vLyfn7y8 vLwAvLy8vLy8vJ8An5+fn5+8vAC8AAAAvLwAvLy8vLyfAE8nSVVVMfv7+zGfn3O8vLy8vLy8vLy8 vLwqKiqfn58qKiojvLy8+fmfAAAx+/sxMTH/////////5fswMf//MfswMQAAAP8xMTH7AAAxwwAA n5+8/7z/vP+8/yoqKsOfn3IqKiq8/7z/vAByn58x+/v7AABVMf////j/n5+8/7z/vP+8/7z/vAAA n7xPJ5+fn3JVVVVVVVVVVVVVVVVVnwByVVVVVTHl+/sxn5+fn7z/vP+8/7z/vP+8Kioqwp+fKioq I//5+Z8AAJ+fMfv7MTHikv//AAD//3l6ef///+Xl5TEAAP8AMTExMQAAMTExnwAAn1C8vP+8vLwq Kioqn58qKioqvLz/vLwAn5+fMQAAADExMTH///9Jn58nVVVVVVVVVVVVVQCfn1VVVVVVn5+fclVV VVVVVVVVVVVVVVUAn5eelzExMfswMTGfn5+fn7y8/7y8vP+8vCoqKiqfnyoqKvn5nwAAn58xMTH7 +zHd4t3i3QAA/wD//zD///8xMTEx/////zExMTEAMQAxMTG8nwCfn3O8/7z/KioqKp+fKioqKrz/ vJ+fAJ8xcgDl+/sxVVVVVVVVwp+fVVVVVVVVVVVVnwCfVVVVVVVVVZjDn5+f/7z/vP+8/7z/vP+8 nwBzMTExMTExMTGfnzHDn5+fc7z/vP+8/7wqKioqKioq+fmfAACfn3oxMTExMTExMTHi4uL///// MPswMf//MTExMTEx//8xMTExMQAAMTEx/7zCAACfn7z/vCoqKirCKioqKiq8n5+fnwAxn58AMfv7 MVVVVVVVVZ+fVZeel/j4+Pj4nwCfvLz/+Ly8vPi8vP+fn59z+Pj4+Ly8+Ly8vJ8AnzExMTExUHMx n59zvLyfn5+fULy8vLz/KioqKir5+Z8AAJ+fvLx0Mf8xMTH//zEx///d4t0xMeX7MDH//zExMTEx Mf//eXp5enkAAHp5/7z/vP/CAACfcv8qKioqKioqKiqfn5+f/7wAMZ8AMTExMTExMTH//8Ofn/j/ vP+SvJK8nwCfvLz/vLy8/7y8vP+8vJ+fn3OSvJL/vP+8ALz/nwB5enl6eZ+fesKfn/+8/7yfn5+f /7z/vCoqKvn5+QAAn5//vP+8ejH/Mf///zExMf////8xMTExMTEx//8xMTH//zH//////7z/AAC8 /7y8vP+8vLyfAACfcyoqKir/Kp+fn5/C/7y8AJ8AMTGfUDExMTEx//+fn///vLy8/7y8nwCfvAAA AAAA/wAAvAAAvAAAn5+fn7y8vAC8vAD/vJ8An/////+fn7z/n5+f/7y8vMOfn5+fvLwq+fn5AACf nyojvLy8/3QxMTExMTExMTH/////MTExMTExMf//Mf///zEx////////vAAAc7z/vP+8/7z/vP+f AJ+fKv//c5+fn5+8/7z/vJ8An7z/n5+8//////+fn5////+8/7z/AACf/7wAvAAAALwAAP8AALwA AADCn5+fAP8AALwAvP/4nwD///+8n5//vP+fn5//vP+8/5+fn5/5+fkAAJ+f/7z/vP+8/7z/vP+8 /7z/kv////////8xMTH//zH/////////////////vLyfAAC8vLy8vLy8vLy8vJ8AAJ+fn5+fn7y8 vLy8vJ8AALy8n5+fvP//////n5////////hyAJ+fvLy8vAC8vLy8vLy8AAC8vAAAvLyfn59QALy8 ALz//58AUP//vJ+fvLy8vJ+fULy8vLy8vPn5+QAAn5+8vLy8vLy8vLy8vLy8vLy8vJL///////// Mf///zEx//////////////////+8/wCfvP+8/7z/vP+8/7z/vJ8AAJ+fvP+8/7z/vP+fnwD/vJ+f /7z/////n5+f//////+fAJ+8+Pj4+Pj4+Pj/vP/4/7z/+P+8//j4+J+fn5/4kvj/////AJ///7yf n/+8/7zDn5+8/7z/vPn5AACfn58qKiP/vP+8/7z/vP+8/7z/vP9t////////enl6eXp5//////// //////////+8/7wAn/+8vLz/vLy8/7y8vJ+fn58An5+8/7y8vP+fn7wAvLyfn7y8/////5+f//// //+fAJ//////////////////////////////////wp+fn////////58Acv//n5+8/7y8vJ+fn7z/ +fkAAJ+fwp+fn1AjvLy8/7y8vP+8vLz/vLy8kv///////////////////////////////////7z/ AJ+8/7z/vP+8/yoqn5+fnyoqwgAAn5//vP+fAJ//AP+fn7z/vP///5+fcv////+fAJ//////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAn5+fc//////CAJ//vJ+f/7z/vP+8n5/5+QAAn58qKp+fn5+f n3O8/7z/vP+8/7z/vP+8/5L///////////////////8xMTExMTH//////7y8vAAAvLz/vLy8vLyf n5+fn58qKioqwwAAn3OfAJ//vAC8n5+8vP////+fn/////8AAJ///////wD///////////////// ////////////AP+fn5+f/////58A/7yfn7y8vLy8vPn5AACfnyoqKsOfnyoqn5+fn7y8vLy8vLz/ vLy8vLyS//////8AAAD/////////MTEx//8x////////vACfc7z/vP+8/3Kfn5/CKp+fKioqKrz/ nwAAnwD/vP8A/5+fcv+8//+fn3P///8An5////////8A//////////////8A/////////////wD/ /8Kfn5////+fAJ+8n5//vP+8+fkAAJ+f/7wqKiqfn58qKirCn5+fn/+8/7z/vP+8/7z/bf////// AAAA/zExMDH//zH///8xMf//////vP8An7z/vLy8/5+fn58qKiqfn3IqKiq8vP+8nwCfn7y8ALzC n5+8vP//n5///58An///////////AP8A/wD//wAAAAAAAP8AAAAAAAD///8A/////5+fn3L//58A /7y8vP/5+QAAn5+fn1C8Kioqw5+fKioqI7yfn5+fcrz/vLy8/7y8vJL///////8xADH7+zAx//8x MTExMTH//zExMTExAJ8xMTG8n5+fn/8qKioqn58qKioqvP+8nwCfAACfnwAAMZ+fMTExn58x/58A n////////////wD/AP//////AP//AAD//wD//////wD/AP//////n5+fnzExADH7MPn5AACfn/+8 /5+fcioqKiqfnyoqKiP/vP+fn5+fvHoxMTExMTExMTH////d+fkxMfswMf//MTEx3ZEx//8xMTEx MQAAMTGfn5+fvLy8KioqKp+fKioqKry8nwCfvLyfAAAAADGfnzExMZ8AMZ8An////////wAAAP8A /////////////////////////////wD////////Dn5+fMTEA+fkAAJ+fvLy8vLzCn58qKioqnyoq KiojvLy8vJ+fn5+fMf8xMTH//zEx+fn5+fn5MTExMTH//zExMeLdAOLi3ZIxMQAAMZ+fn5//vP+8 /yoqKiqfnyoqKiq8/wCfvP+8/7yfAACfwzH7MDHCAAAAn/////8AAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA//////////+fn59zAPkAMTExMf+8/7z/vJ+fnyoqKioqKioqI/+8/7z/vMOf n59zMf///zExMQD5+fn5MTExMTEx//8x+zDi4t3i3eIAAAAAADGfnzG8vP+8vLwqKioqKioqKioq vJ+fvLy8/7y8vAAAADEx+/sxMQAAn///AAAA//////////////////////////////////////// ////////////MZ+fMfn5ADGfn59Qc1C8vP+8n59zKioq/yoqKiO8vLz/vLy8/5+fn58x+/sxAAD5 +fn5/zExMf//Mf//Mfv7///////i4jH7APsxwzExvP+8/7z/KioqKir/KioqKp+fn/+8/7z/vP8A ADEAAPv7MQAAAAAAAP/////////////////////////////////////5/////////////////zEx MTH5AAAAAAAAAJ+fn5+fn8Kfn5+fn3JzKioj/7z/vP+8/7x6MZ8xMfv7ADH5///5x/nH/8fHMTHH /zExMQAA////MTEx+wD7MZ+fn5+fn5+fn5+fn5+fn5+fn58An5+fn5+fn5+fAACfMQD7+wDCAAD/ ////////////////////////////////+f/////5////UHNQclBzUJ+fn5+fn58A+fv5+TExw58A AAAAAAAAAAAAAACfn5+fn5+fn5+fn59yUDExMTH7ADH5Mf///8f/+fn//8fH//95enn//////zEx MfsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAc3Jzcp+fn5+fnwAA AAAAAAAAAAAAAAAAAAD5AAD5AAAA+QAAAAAAAAAAAAD5AAAAMfn5MTH5+fn5+fn5+fn5+f+fn3LD AAAAAAAAAAAAAAAAAJ+fn3IxAPv5/+Li3eLH4pHH+fnHx//////////////i3QAA+zAAAAAAALwA vAAA/7y8AP8AvLyfALy8/7y8vP+8vLwAADEx5fv7MQAAAAAAAAAAAAAAAACfn5+fn5+fn5+fn5+f n5+fn/n5n5+fn/n5+Z+fn8LCw5/D+fn5AAD5+TExn5+fn5+8vLz/vLz5+fn5+fn5+fn5+fm8/7zC wsMAAAAAAPv5+d3i3eLdx92S/8fH+f/H/////////93iAAAx5fsAAAAxAAAAAP8A/wAAvAAAALyf AJ+8/7z/vP+8/7z/AAAAAAD7AAAAAADDwsPCw8LD///////////////////////////5+f/////5 +fn5+f////////n5+fn5MTExMTHDn5+fn59zvP+8/7zDn5+8/7z/vP+8+fn5+fn5+fn5+fn7+TEx Mf/////////////5+f8AAP//Md0AAOL/MTExAAAxMTEAAAC8AAC8AAAAAACfAJ8xMby8vLyfn5+f n5+fAAAxMQAAMQAx///////////////////////////5+fn5+fn5+fn5+fn5+fn5+fn///////n5 +fn5+TEx//8xMTG8n5+fn5+fvLwxMZ+fnzExMTExvLy8vLy8vHQxMTEx+TExMeLdkf////////// ////AAD//wAA4v8x/zH///8xMTExvP+8/7z/vHoxMTExAJ8xMZ+fn5+fn5+fn5/CMTExMTExMTEA Mf/////////////////////////////////5//////n///n5+f/////////5+fn5/zH///8xMTEx /7z/wp+fn5+fcjExn58xMTExMbz/vP+8/7x6MTExMTExMf/i4t3i4jExMTExMTH//zExMQDiMf// MTExMTExMTExMby8/7y8vP90MTExMTAxMZ+fn5+fn5//vLy8MTH/MTEx//8xMTH///////////// ////////////////////////////+f/5////////////+fkxMTExMTExMTExMbz/vLy8/5+fn5+f MTExMTExMTG8vP+8vLz/dDExMTExMTEAMeLi3eLd4jExMTAx//8x+zH/MTH//////////wAAAAAA ALwAvAAAejEA+/sA+/swwv+8/7z/vP+8/zEx/zH///8xMTEx//////////////////////////// ////////////////////////////////////////vP+8/7z/vAAAAAAAAMMAnwAA+/sAMAAAvAC8 ALwAAAAxADEAAAAxADH////i4jExMPswMf//Mfv7MTEx//////////8AvAAAAAC8ALwAAHQxAPv7 APv7MTG8vLy8vLy8/7y8vLz///////////////////////////////////////////////////// ///////////5////+fn5+f////+8vLy8vLwA/wAAAAC8ADEAAPv7APsAAAAAvAAAAAAA/wAAAAAA /wD//////zExMeX7MDH//+Xl5TExMf////////////////8A//////96MQAxMTEAMTEx//////// ///////////////////////////////////////////////////////////////////////////5 //n///n/////////vP+8////vP8A/zEx5fv7+wAxMQAAALwAvP+8////////AP8A//////8xMTEx MTEx//8xMTExMTH/////////////////////////dDExMTExMeLdMf////////////////////// ///////////////////////////////////////////////////////////5+f/5+f////////// //////////////8xMTExMTExMTEx////////////////////////////MTExMTExMf//MTEx//8x /////////////////////////3oxMTExMf/iAN3///////////////////////////////////// ////////////////////////////////////////////+f//+f/5//////////////////////// MTExMTExMTExMf///////////////////////////zExMTExMTH//zH///8xMf////////////// //////////90MTExMTEx4t0A3f////////////////////////////////////////////////// /////////////////////////////////////////////////////////////zExMTExMTExMTH/ //////////////////////////8xMTExMTEx//95enl6ef//////////////////////////ejEx MTExMTH/4gDd/zH///////////////////////////////////////////////////////////// //////////////////////////////////////////////8xMTExMTExMTEx//////////////// ////////////MTExMTExMf///////////////////////////////////3Qx/zExMf//MeLdAN0x AAD///////////////////////////////////////////////////////////////////////// ////////////////////////////////Mf8xMTH//zExMf////////////////////////////8x MTH//zH///////////////////////////////////96Mf8x////MTEx/+IAMQAA//////////// //////////////////////////////////////////////////////////////////////////// /////////////////zH/Mf///zExMTH/////////////////////////////Mf///zEx//////// ///////////////////////////////////////////idDEx+zEx//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////3oxMfsxMf////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////90Mfv7+zH///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ejExMTEx//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8xMTH///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////Mf///zH///8f////H/////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////Hx8f//8fH x///x8fH//8fHx8f/x8fHx//H/8f/x//dDEfHx8xHx//Hx8f/x8fH/8f/x8fHx8fH/8fHx8f//8f H/8f/x////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////x////8f//8f/x///////Hx8f H/8fHx8f/x//H/8f/////x8fH/8f/x////8f////H/8fHx//Hx///x8fH/8f////H/8f//////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////8f////H/////8f//////x//Hx//H/8fHx8fHx// H////x//Hx//H/8fHx//Hx8f/x8fH/8fH/8f/x//Hx//Hx8f/x8fH/////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////H/////8f/x///x//H//////8f//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////Hx8fH/8fH///Hx8f////Hx//H///////Hx8f H///Hx8fH/8f//8fH/8fHx//Hx8fH/8fH/////8fH/8fH/8f/x//H/8f/x8fH/8fH/8fH///Hx// H/8f/x8fHx////8fHx8f/x8f//8fHx/////5///5+f//+fn///8fHx8f/x///x8f////Hx8fH/8f H///Hx8f/////////////////x//////Hx//H///////H/8f/x///////x8fHx///x8fHx//H/8f /x//Hx8fH/8fHx8f/x////8f//8f////H/8f/x//H/8fHx8f//8f/x//H////x//H///Hx////// H/////8fH/8f////Hx////n5+fn/////+f//Hx8fH/8f/x//H////x//////Hx//H////x8f//// //////////8fHx///x8f/x///////x8fH/8f/x8fHx8f/x8fH/8f/x8fHx//Hx8f/x//Hx8fH/8f Hx8f////Hx8fHx8f/x8fH/8fHx//H/8fHx8fHx8f/x8fH/8fHx//H/8f/////x8fH///Hx//H/// ///////5+f/5///5+f///x//Hx8fH/8fHx////8fHx///x8f/x//////////////////////H/// /x///x//H/8f/////x///////////////////////////x////////8f////////H/////////// /////////////////////x////////////////////////8f////H///H/8f/x//////+fn/+f/5 ///5//////////////8f////H////x///x//H/8f//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AGVkIGNvbm5lY3Rpb25zLCBFVkMtQUlTIGFuZCBFVkMtTE9DIGFsYXJtIHN1cHByZXNzaW9uAAwQ AAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAAHAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUA AwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAAAQAAAAAAUAAAAAMAAAAAAAAAIAAAAAEA AAAyAAAAAgAAADoAAAABAAAAAgAAAAYAAABzZmxhZwACAAAA6f0AAB4AAAAMAAAAMTIzOTk0NTQw NQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPHwAAABQAAABfwJHjmWMBAAcA9AMDAAAA Vmlzc2VycwgAAABWAGkAcwBzAGUAcgBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA QwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAMAAAANQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABS AG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAP//////////AQAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAwCxQIwcHJ AecAAABAAwAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAL1jAQAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEEAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC3AAAAJFUAAAAAAAAFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADoAgAAAAAAAIEA AACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAA AJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAA ngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACs AAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAD+/////v////////+4AAAAuQAAALoA AAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADHAAAAyAAA AMkAAADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUAAADWAAAA 1wAAANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAAD+//////////7////j AAAA/f////3////oAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAA ADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA SQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABX AAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUA AABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAA AHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAgAAAAP/////+/wAA BQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAAr LPmumAIAAFQCAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACgAAAABAAAAMgAAAAGAAAA0AAAAAcA AADYAAAACAAAAOAAAAAJAAAA6AAAAAoAAADwAAAAFwAAAPgAAAALAAAAAAEAABAAAAAIAQAAEwAA ABABAAAWAAAAGAEAAA0AAAAgAQAADAAAAPIBAAACAAAA6f0AAB4AAAAIAAAAQ3VzdG9tAAAeAAAA IAAAAEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4AAAAAAwAAAL1jAQADAAAAVAAAAAMAAAAB AAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAGQfCwALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAALAAAAAAAAAB4QAAAJAAAABgAAAEFyaWFsAAsAAABNUyBQR290aGljAAcAAADlrovkvZMACgAA AFdpbmdkaW5ncwANAAAAVHJlYnVjaGV0IE1TAA4AAABGdXR1cmFBIEJrIEJUABAAAABUaW1lcyBO ZXcgUm9tYW4AEwAAAGh1YXdlaS10ZW1wbGF0ZS1tdgBGAAAARVZDIGRpZmZlcmVudGlhdGVkIGNv bm5lY3Rpb25zLCBFVkMtQUlTIGFuZCBFVkMtTE9DIGFsYXJtIHN1cHByZXNzaW9uAAwQAAAGAAAA HgAAAAsAAABGb250cyBVc2VkAAMAAAAHAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEA AAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAAAQAAAAAAUAAAAAMAAAAAAAAAIAAAAAEAAAA0AAAA AgAAADwAAAABAAAAAgAAAAYAAABzZmxhZwACAAIAAADp/QAAHgAAAAwAAAAxMjM5OTQ1NDA1AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPHwAAABQAAABfwJHjmWMBAAcA9AMDAAAAVmlzc2Vy cwgAAABWAGkAcwBzAGUAcgBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0068_01C9C1D1.D1F48B40-- From hhelvoort@chello.nl Mon Apr 20 07:43:03 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA793A6D1B for ; Mon, 20 Apr 2009 07:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST793UfZZcNS for ; Mon, 20 Apr 2009 07:43:02 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id 6C5843A69CA for ; Mon, 20 Apr 2009 07:43:02 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042007441209855 ; Mon, 20 Apr 2009 07:44:12 -0700 Received: from McAsterix.local ([10.84.1.238]) by s-utl02-sjpop.stsn.net; Mon, 20 Apr 2009 07:44:10 -0700 Message-ID: <49EC8A30.5080203@chello.nl> Date: Mon, 20 Apr 2009 16:44:00 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eric Gray References: <001901c9bc0a$dc6fd060$6802a8c0@china.huawei.com><6FD21B53861BF44AA90A288402036AB402145621@FRVELSMBS21.ad2.ad.alcatel.com> <49E5EEC8.6080101@labn.net> <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF05002440@eusrcmw721.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 14:43:03 -0000 Hi, I agree with Eric. Regards, Huub. ================ Eric Gray wrote: > Lou/Italo, > > This gets into a fuzzy language area. > > I think it should be clear that use of associated > (non-co-routed) > bi-directional paths is not required. It also seems to me to be clear > that they might be used; hence support for them is needed in protocols > and other specifications. > > We all need to be precise in what we mean by what is required, > and where it is required. > > -- > Eric > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Lou Berger > Sent: Wednesday, April 15, 2009 10:27 AM > To: BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Italo, > > On 4/14/2009 6:12 AM, BUSI ITALO wrote: >> 2) we need to be clear that asssociated bidirectional paths are not >> required in transport networks (e.g. MPLS-TP) >> > > This doesn't match draft-ietf-mpls-tp-requirements-06. Are you > proposing dropping associated bidirectional path from the TP > requirements document? > > Lou > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon Apr 20 07:54:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197BB3A6B09 for ; Mon, 20 Apr 2009 07:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttiWDC7MNLOw for ; Mon, 20 Apr 2009 07:54:06 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id DDD313A6A81 for ; Mon, 20 Apr 2009 07:54:06 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042007541909906 ; Mon, 20 Apr 2009 07:54:19 -0700 Received: from McAsterix.local ([10.84.1.238]) by s-utl02-sjpop.stsn.net; Mon, 20 Apr 2009 07:54:17 -0700 Message-ID: <49EC8C8F.1090704@chello.nl> Date: Mon, 20 Apr 2009 16:54:07 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: BUSI ITALO References: <93DFCD4B101EB440B5B72997456C5F9403953DA8@esealmw118.eemea.ericsson.se> <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: VIGOUREUX MARTIN , mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 14:54:08 -0000 Hi, I agree with Italo, It is the behaviour of TCM that is a requirement. Therefor is should be referred to (e.g. ANSI has T1.105.05 dedicated to TCM). How the behavour is implemented should be in one of the tool drafts. Regards, Huub. ================ BUSI ITALO wrote: > Ben, > > TCM is an architectural construct well defined in G.805 in a technology-independent manner. As such TCM does not imply any specific solution. > > The solution we are working on to implement TCM within MPLS-TP is based on the JWT agreement and described in the OAM Framework document. > > I do not think we should drop a requirement because of people's misunderstandings. > > Italo > >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >> Sent: Friday, April 17, 2009 4:26 PM >> To: Annamaria Fulignoli; VIGOUREUX MARTIN >> Cc: BUSI ITALO; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: >> Associated bidirectional transport path requirements) >> >> Because IMO use of the term TCM tends to make people think of >> a particular >> solution and what we want to do at this stage is express the >> functional >> requirements and not imply any particular solution. >> >> Certainly most of my mails in this thread (and I am probably >> not the only >> one) have been based on the fact that when discussing TCM I assume a >> particular solution is being discussed. Talking purely in terms of >> functional requirements removes that ambiguity. >> >> Ben >> >> >> On 17/04/2009 12:51, "Annamaria Fulignoli" >> wrote: >> >>> Hi all, >>> sorry but I do not understand why we cannot explicitly use >> the term Tandem >>> Connection in the requirements document! >>> TCM is not a solution, it is part of functional >> architecture of a transport >>> networks as described in G.805. The solution is to realize >> it with label >>> stacking rather than MEL. >>> >>> Regards >>> Annamaria >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of >>> Martin Vigoureux >>> Sent: venerd� 17 aprile 2009 13.29 >>> To: Ben Niven-Jenkins >>> Cc: BUSI ITALO; mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was >> RE: Associated >>> bidirectional transport path requirements) >>> >>> Ben, all >>> >>> in mpls-tp-oam-requirement, the text on this item is as follows: >>> >>> The service emulated by a single segment or a >> multi-segment PW may >>> span multiple domains. A LSP may also span multiple >> domains. It >>> MUST be possible to perform OAM functions on a per >> domain basis and >>> across multiple domains. More generally it MUST be possible to >>> perform OAM functions between any two switching >> elements (e.g., LSR >>> or S-PE) of a LSP or of PW. This is referred to as >> (concatenated) >>> segment monitoring. >>> >>> I believe the text describes a functional req. >>> >>> During mead team review, the removal of the last sentence >> was discussed. >>> No strong opinion was expressed on whether it should >> effectively be removed or >>> not. >>> >>> regards, >>> martin >>> >>> Ben Niven-Jenkins a �crit : >>>> Italo, >>>> >>>> I think we are converging. If I can be so bold as to speak on his >>>> behalf Adrian's objection seemed to be to the use of the term TCM. >>>> >>>> It is defined in the MPLS-TP requirements but not used. >>>> >>>> It is not used in the MPLS-TP OAM requirements document. >>>> >>>> Therefore I think the way forward is as follows: >>>> >>>> 1) Remove the term Tandem Connection from the MPLS-TP >> requirements as >>>> it is redundant (i.e. Not used in that document). >>>> >>>> 2) Ensure the MPLS-TP OAM requirements express the necessary >>>> functional requirements around monitoring of end to end >> paths as well >>>> as parts of end to end paths. This can be done without referring >>>> explicitly to Tandem Connections. >>>> >>>> When it comes to solution design we can decide what is the best >>>> mechanism to achieve/implement those requirements be it >> LSP hierarchy or >>>> something else. >>>> The JWT has proved that it is possible to meet those requirements >>>> using existing MPLS technology (maybe with some enhancements). I do >>>> not believe we have to necessarily use the solution they propose >>>> aslong as whatever solution we ultimately decide upon meets all the >>>> necessary requirements expressed. >>>> >>>> Can we agree on that as an approach and close this off for now? >>>> >>>> Ben >>>> >>>> >>>> On 17/04/2009 10:49, "BUSI ITALO" >> wrote: >>>>> Ben, >>>>> >>>>> I think we are mixing solutions with requirements. >>>>> >>>>> The requirement for the TCM function is clearly defined and I do >>>>> think it must be addressed by the MPLS-TP design. >>>>> >>>>> The solution evaluated by the JWT to meet this >> requirement was to use >>>>> label stacking with a 1:1 relationship between the TCM LSP and the >>>>> e2e LSP. >>>>> >>>>> I think this solution, although not the best technical option, is >>>>> good enough and meets the requirements. >>>>> >>>>> However this is is a solution and has not impact on the >> requirement. >>>>> Italo >>>>> >>>>>> -----Original Message----- >>>>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>>>>> Sent: Friday, April 17, 2009 11:22 AM >>>>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>>>>> Cc: mpls-tp@ietf.org; Lou Berger >>>>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>>>>> Associated bidirectional transport path requirements) >>>>>> >>>>>> Italo, >>>>>> >>>>>> On 17/04/2009 09:34, "BUSI ITALO" >>>>>> wrote: >>>>>>> The JWT agreement is to bring the ITU-T transport >>>>>> requirements in IETF >>>>>>> to extend the MPLS architecture to meet them in a way that is >>>>>>> compatible, consistent and coherent with existing IETF >> architecture. >>>>>> So I took a look at the JWT report. It says (slide 16) >>>>>> >>>>>> " Service Providers want LSPs/PWEs to be able to be >> managed at the >>>>>> different nested levels seamlessly (path, segment, multiple >>>>>> segments) >>>>>> aka Tandem Connection Monitoring (TCM), this is used >> for example >>>>>> when a LSP/PWE crosses multiple administrations" >>>>>> >>>>>> IMO the requirement is to be able to monitor parts of a >> path as well >>>>>> as the end to end path. There are many ways to solve that >>>>>> requirement, one of which is the creation of nested LSPs, one per >>>>>> level of monitoring required (my understanding of how TCM works). >>>>>> >>>>>> I think the real discussion is therefore is the requirement to >>>>>> monitor different components of an end to end path or is the >>>>>> requirement that such monitoring MUST be achieved using >> nested LSPs? >>>>>> As an example PW technology today allows end to end and >> per segment >>>>>> monitoring but it does not achieve it using nested PWs >> or PW levels. >>>>>> Ben >>>>>> >>>>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon Apr 20 07:55:02 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524443A6C6F for ; Mon, 20 Apr 2009 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2ykM+jA7wJ5 for ; Mon, 20 Apr 2009 07:55:01 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id 05BE73A6DBD for ; Mon, 20 Apr 2009 07:55:01 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042007555109940 ; Mon, 20 Apr 2009 07:55:51 -0700 Received: from McAsterix.local ([10.84.1.238]) by s-utl02-sjpop.stsn.net; Mon, 20 Apr 2009 07:55:49 -0700 Message-ID: <49EC8CEB.40200@chello.nl> Date: Mon, 20 Apr 2009 16:55:39 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: BUSI ITALO References: <2ECAA42C79676B42AEBAC11229CA7D0C046FFE01@E03MVB2-UKBR.domain1.systemhost.net> <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4021B1A71@FRVELSMBS21.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls-tp@ietf.org, VIGOUREUX MARTIN Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 14:55:02 -0000 Hi, I agree with what Italo writes below. Regards, Huub. ================== BUSI ITALO wrote: > Neil, > > G.805 is an in-force Recommendation: G.800 was never intended to replace G.805. > > People who worked on G.800 has always claimed that for connection-oriented technologies G.800 defaults to G.805. > > When Q12/15 consented G.800, it was agreed that existing Recommendations based on G.805 (e.g. G.8110.1) will continue to be based on G.805. > > Italo > >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com >> Sent: Friday, April 17, 2009 5:22 PM >> To: dbrungard@att.com; benjamin.niven-jenkins@bt.com; >> annamaria.fulignoli@ericsson.com; VIGOUREUX MARTIN >> Cc: BUSI ITALO; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was >> RE:Associatedbidirectional transport path requirements) >> >> I agree with both Ben and Deborah. One further point to add here..... >> >> G.805 is a fairly old Recommendation written largely to give >> us a working func arch language for the development of >> management information models when we were developing >> SONET/SDH. However, our understanding of the physics of >> networking has improved significantly and G.800 (Unified >> functional architecture of transport networks) is a more >> comprehensive embodiment of that understanding that covers >> all 3 network modes (based on sound Info and Systems theory >> underpinnings). So G.800 should be the starting point for >> any references to the network func architecture for MPLS-TP >> and not G.805 IMO. >> >> regards, Neil >> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BRUNGARD, >>> DEBORAH A, ATTLABS >>> Sent: 17 April 2009 15:59 >>> To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli; Martin Vigoureux >>> Cc: BUSI ITALO; mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: >>> Associatedbidirectional transport path requirements) >>> >>> I agree with Ben. TCM, with the introduction of MEL as a >>> solution, has become architecturally confusing. When it was >>> used in reference to SDH, where trail overhead was >>> overwritten, it created a tandem connection. For cell/packet >>> technologies where the OAM cells/packets are inserted, it is >>> not clear if this is a tandem connection or a new server >>> layer, as both architectural terms are used in the standards. >>> >>> In G803, TCM is a sublayer monitoring technique for a SDH >>> tandem connection: >>> "Sublayer monitoring >>> Connections may be directly monitored at one end of a >>> connection by overwriting some portion of the original >>> trail's overhead capacity at the beginning of the connection. >>> For SDH, overhead has been defined for this purpose at the >>> higher-order and lower-order path layers. When applied to a >>> SDH tandem connection, this monitoring method is referred to >>> as tandem connection monitoring." >>> >>> Whereas in Y.1711: >>> "OAM techniques are applied on a per LSP basis. If a segment >>> of a given LSP at layer N is to be monitored for some reason >>> (e.g., via a CV or P flow say), one way to do this is by >>> creating a new server layer LSP (i.e., at layer N + 1) to >>> cover the segment at layer N." >>> >>> So I think before using TCM in reference to MPLS-TP, Q12 >>> needs to align on the use. For now, the requirements >>> documents should try to avoid it. >>> >>> Deborah >>> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >>> Sent: Friday, April 17, 2009 10:26 AM >>> To: Annamaria Fulignoli; Martin Vigoureux >>> Cc: BUSI ITALO; mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: >>> Associated bidirectional transport path requirements) >>> >>> Because IMO use of the term TCM tends to make people think of >>> a particular >>> solution and what we want to do at this stage is express the >>> functional >>> requirements and not imply any particular solution. >>> >>> Certainly most of my mails in this thread (and I am probably >>> not the only >>> one) have been based on the fact that when discussing TCM I assume a >>> particular solution is being discussed. Talking purely in terms of >>> functional requirements removes that ambiguity. >>> >>> Ben >>> >>> >>> On 17/04/2009 12:51, "Annamaria Fulignoli" >>> wrote: >>> >>>> Hi all, >>>> sorry but I do not understand why we cannot explicitly use >>> the term Tandem >>>> Connection in the requirements document! >>>> TCM is not a solution, it is part of functional >>> architecture of a transport >>>> networks as described in G.805. The solution is to realize >>> it with label >>>> stacking rather than MEL. >>>> >>>> Regards >>>> Annamaria >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of >>>> Martin Vigoureux >>>> Sent: venerd� 17 aprile 2009 13.29 >>>> To: Ben Niven-Jenkins >>>> Cc: BUSI ITALO; mpls-tp@ietf.org >>>> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was >>> RE: Associated >>>> bidirectional transport path requirements) >>>> >>>> Ben, all >>>> >>>> in mpls-tp-oam-requirement, the text on this item is as follows: >>>> >>>> The service emulated by a single segment or a >>> multi-segment PW may >>>> span multiple domains. A LSP may also span multiple >>> domains. It >>>> MUST be possible to perform OAM functions on a per >>> domain basis and >>>> across multiple domains. More generally it MUST be >> possible to >>>> perform OAM functions between any two switching >>> elements (e.g., LSR >>>> or S-PE) of a LSP or of PW. This is referred to as >>> (concatenated) >>>> segment monitoring. >>>> >>>> I believe the text describes a functional req. >>>> >>>> During mead team review, the removal of the last sentence >>> was discussed. >>>> No strong opinion was expressed on whether it should >>> effectively be removed or >>>> not. >>>> >>>> regards, >>>> martin >>>> >>>> Ben Niven-Jenkins a �crit : >>>>> Italo, >>>>> >>>>> I think we are converging. If I can be so bold as to speak on his >>>>> behalf Adrian's objection seemed to be to the use of the >> term TCM. >>>>> It is defined in the MPLS-TP requirements but not used. >>>>> >>>>> It is not used in the MPLS-TP OAM requirements document. >>>>> >>>>> Therefore I think the way forward is as follows: >>>>> >>>>> 1) Remove the term Tandem Connection from the MPLS-TP >>> requirements as >>>>> it is redundant (i.e. Not used in that document). >>>>> >>>>> 2) Ensure the MPLS-TP OAM requirements express the necessary >>>>> functional requirements around monitoring of end to end >>> paths as well >>>>> as parts of end to end paths. This can be done without referring >>>>> explicitly to Tandem Connections. >>>>> >>>>> When it comes to solution design we can decide what is the best >>>>> mechanism to achieve/implement those requirements be it >>> LSP hierarchy or >>>>> something else. >>>>> The JWT has proved that it is possible to meet those requirements >>>>> using existing MPLS technology (maybe with some >> enhancements). I do >>>>> not believe we have to necessarily use the solution they propose >>>>> aslong as whatever solution we ultimately decide upon >> meets all the >>>>> necessary requirements expressed. >>>>> >>>>> Can we agree on that as an approach and close this off for now? >>>>> >>>>> Ben >>>>> >>>>> >>>>> On 17/04/2009 10:49, "BUSI ITALO" >>> wrote: >>>>>> Ben, >>>>>> >>>>>> I think we are mixing solutions with requirements. >>>>>> >>>>>> The requirement for the TCM function is clearly defined and I do >>>>>> think it must be addressed by the MPLS-TP design. >>>>>> >>>>>> The solution evaluated by the JWT to meet this >>> requirement was to use >>>>>> label stacking with a 1:1 relationship between the TCM >> LSP and the >>>>>> e2e LSP. >>>>>> >>>>>> I think this solution, although not the best technical >> option, is >>>>>> good enough and meets the requirements. >>>>>> >>>>>> However this is is a solution and has not impact on the >>> requirement. >>>>>> Italo >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>>>>>> Sent: Friday, April 17, 2009 11:22 AM >>>>>>> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein >>>>>>> Cc: mpls-tp@ietf.org; Lou Berger >>>>>>> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] >>>>>>> Associated bidirectional transport path requirements) >>>>>>> >>>>>>> Italo, >>>>>>> >>>>>>> On 17/04/2009 09:34, "BUSI ITALO" >>>>>>> wrote: >>>>>>>> The JWT agreement is to bring the ITU-T transport >>>>>>> requirements in IETF >>>>>>>> to extend the MPLS architecture to meet them in a way that is >>>>>>>> compatible, consistent and coherent with existing IETF >>> architecture. >>>>>>> So I took a look at the JWT report. It says (slide 16) >>>>>>> >>>>>>> " Service Providers want LSPs/PWEs to be able to be >>> managed at the >>>>>>> different nested levels seamlessly (path, segment, multiple >>>>>>> segments) >>>>>>> aka Tandem Connection Monitoring (TCM), this is used >>> for example >>>>>>> when a LSP/PWE crosses multiple administrations" >>>>>>> >>>>>>> IMO the requirement is to be able to monitor parts of a >>> path as well >>>>>>> as the end to end path. There are many ways to solve that >>>>>>> requirement, one of which is the creation of nested >> LSPs, one per >>>>>>> level of monitoring required (my understanding of how >> TCM works). >>>>>>> I think the real discussion is therefore is the requirement to >>>>>>> monitor different components of an end to end path or is the >>>>>>> requirement that such monitoring MUST be achieved using >>> nested LSPs? >>>>>>> As an example PW technology today allows end to end and >>> per segment >>>>>>> monitoring but it does not achieve it using nested PWs >>> or PW levels. >>>>>>> Ben >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon Apr 20 08:05:16 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B2C3A6C6F for ; Mon, 20 Apr 2009 08:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxL2LWnRZ2-e for ; Mon, 20 Apr 2009 08:05:15 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id A87EE3A68FF for ; Mon, 20 Apr 2009 08:05:15 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042008062809978 ; Mon, 20 Apr 2009 08:06:28 -0700 Received: from McAsterix.local ([10.84.1.238]) by s-utl02-sjpop.stsn.net; Mon, 20 Apr 2009 08:06:28 -0700 Message-ID: <49EC8F69.30000@chello.nl> Date: Mon, 20 Apr 2009 17:06:17 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: loa@pi.nu References: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> In-Reply-To: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:05:16 -0000 Hej Loa, You wrote: > All, > > I'd like to comment on the current discussion on > http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-06 . > > We do our best follow the the mpls-tp process as described in: > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt I agree. > The outstanding question we have for the ITU-T ad hoc team on > MPLS-TP is step 13 in the figure on page 7 of that draft. We are > asking the ad hoc Team if the draft is good enough to send to the > IESG with a request for publication. However these are not new questions, the issues were raised during the ITU-T plenary and were supposed to be resolved. > Please note that we are only expecting a "yes" or "no" answer to > our question. I understand, but in this case it would be a conditional yes, because, as I mentioned above, not all issues were resolved. > If the response is "yes" then publication will be requested, if > the answer is "no", the document will be taken back into the > working group process and a new version produced. > > That said, there is never wrong to discuss technical improvements, > editorial issues or genereal clarifications on any draft. What is the purpose of discussing them when the publication has started. Unless this is a working method accepted in the IETF. and there is still a possibility to make technical changes/ adjustments. In the ITU-T once a recommendation draft is consented (yes is received) then the draft is pre-published. The ITU-T editors will than bring the document in a shape that is can be officially published, but in this stage no technical changes can be made any more, only typographical. Regards, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From maarten.vissers@huawei.com Mon Apr 20 08:12:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBAA3A6AB8 for ; Mon, 20 Apr 2009 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShNqWSmpr9Px for ; Mon, 20 Apr 2009 08:12:10 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id 5AB7F3A6A26 for ; Mon, 20 Apr 2009 08:12:10 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042008132125488 ; Mon, 20 Apr 2009 08:13:21 -0700 Received: from M00900002 ([10.84.1.19]) by s-utl01-sjpop.stsn.net; Mon, 20 Apr 2009 08:13:19 -0700 From: "Maarten Vissers" To: , Date: Mon, 20 Apr 2009 17:13:12 +0200 Message-ID: <00ef01c9c1ca$8bd4e670$1301540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <043601c9c071$a98876a0$fc9963e0$@com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acm/8k9J3/iDMF7NTs6dhn0tyFGmUwAV1zBQAAnTVdAAVfcbAA== Cc: 'MPLS-TP' Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:12:11 -0000 Shahram, In VLANs you don't have a OAM flag in the VLAN Tag either. Nonetheless it is no problem to detect if a frame carries OAM or non-OAM by a MEP or MIP function. This information is in the Ethertype following the VLAN Tag. A similar situation is present in MPLS-TP OAM. The ACH following the shim header carries the OAM indication. For case of LSP OAM, the label_13 header following the shim header essentially carries the OAM indication. But it is always a problem to try to extend existing equipment with new functions that require hardware support. But this is only an issue for a short period of time. If we however decide to construct the OAM support such that existing hardware can be resued, but as consequence require to change the connection (i.e. add a new LSP and modify the existing LSP), then as soon as new hardware is available we will still have to change the connection (i.e. new LSP plus modify existing LSP). But if LSPs would be single-domain and LSP protection is via client CL-SNCG/I protection, then there is no need for LSP TCM (see previous email today) and this issue becomes a don't care. Regards, Maarten -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: zondag 19 april 2009 0:05 To: 'Maarten Vissers'; xqwei@fiberhome.com.cn Cc: 'MPLS-TP' Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) Hi Maarten, I don't agree with you. Because due to lack of OAM flag or indicator in the MPLS shim header, activation of some MEPs in the middle of an LSP is complex and requires hop-by-hop deep packet inspection, and therefore from HW perspective existing MPLS routers can't be used to realize it. While nested LSP could be used on existing MPLS routers to support MPLS-TP. Regards, Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: April-18-09 1:20 PM To: xqwei@fiberhome.com.cn Cc: 'MPLS-TP' Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) Xueqin, The nested LSP is a more complex solution then TCM. TCM just requires the activation of some MEPs in the LSP. Nested LSP requires to set up the same MEP functions plus set up an additional LSP and change the existing LSP. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Xueqin WEI (Shuetsing WEI) Sent: zaterdag 18 april 2009 8:52 To: Ben Niven-Jenkins Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) Support, I think the nested LSP will be great! Until now, I didn't see any difference between the nested LSP and TCM on performance monitoring. But the nested LSP will make the things more easy. I would like select a simple way to resolve the problem. Sincerely Yours Xueqin Wei (Shuetsing Wei) Fiberhome Telecommunication Technologies Co.,Ltd., 2009-04-18 14:48:51 ==================== Following is your email===================== Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) Sent：2009-04-17 17:17:31 From:Ben Niven-Jenkins To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp >Italo, > >On 17/04/2009 09:34, "BUSI ITALO" wrote: >> The JWT agreement is to bring the ITU-T transport requirements in >> IETF to extend the MPLS architecture to meet them in a way that is >> compatible, consistent and coherent with existing IETF architecture. > >So I took a look at the JWT report. It says (slide 16) > >" Service Providers want LSPs/PWEs to be able to be managed at the >different nested levels seamlessly (path, segment, multiple segments) > aka Tandem Connection Monitoring (TCM), this is used for example >when a LSP/PWE crosses multiple administrations" > >IMO the requirement is to be able to monitor parts of a path as well as >the end to end path. There are many ways to solve that requirement, one >of which is the creation of nested LSPs, one per level of monitoring >required (my understanding of how TCM works). > >I think the real discussion is therefore is the requirement to monitor >different components of an end to end path or is the requirement that >such monitoring MUST be achieved using nested LSPs? > >As an example PW technology today allows end to end and per segment >monitoring but it does not achieve it using nested PWs or PW levels. > >Ben > >_______________________________________________ >mpls-tp mailing list >mpls-tp@ietf.org >https://www.ietf.org/mailman/listinfo/mpls-tp > ================================================================= _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From twalsh@juniper.net Mon Apr 20 08:26:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E563A6B2B for ; Mon, 20 Apr 2009 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.72 X-Spam-Level: X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hf4Yu7im2w6 for ; Mon, 20 Apr 2009 08:26:27 -0700 (PDT) Received: from chip3og52.obsmtp.com (chip3og52.obsmtp.com [64.18.14.169]) by core3.amsl.com (Postfix) with ESMTP id 4FDC63A6AC2 for ; Mon, 20 Apr 2009 08:26:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob52.postini.com ([64.18.6.12]) with SMTP ID DSNKSeyUaV360JJAQiEUjW7dKeHpWgccoxMf@postini.com; Mon, 20 Apr 2009 08:27:43 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 20 Apr 2009 08:26:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 20 Apr 2009 11:26:50 -0400 From: Thomas Walsh To: "hhelvoort@chello.nl" , "loa@pi.nu" Date: Mon, 20 Apr 2009 11:26:43 -0400 Thread-Topic: [mpls-tp] comment on MPLS-TP document processing Thread-Index: AcnByZnNl2p3WQn1TQW9B4pEwTSmXQAAoNEA Message-ID: References: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> <49EC8F69.30000@chello.nl> In-Reply-To: <49EC8F69.30000@chello.nl> 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 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:26:28 -0000 Huub, =20 > I understand, but in this case it would be a conditional yes, > because, as I mentioned above, not all issues were resolved. Conditional yes? Isn't that the same as "no" - since Loa says there is onl= y "Yes" or "No"? =20 I am confused. Maybe you could clarify. Tom > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f > Of Huub van Helvoort > Sent: Monday, April 20, 2009 8:06 AM > To: loa@pi.nu > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] comment on MPLS-TP document processing >=20 >=20 > Hej Loa, >=20 > You wrote: >=20 > > All, > > > > I'd like to comment on the current discussion on > > http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-06 . > > > > We do our best follow the the mpls-tp process as described in: > > > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process- > 01.txt >=20 > I agree. >=20 > > The outstanding question we have for the ITU-T ad hoc team on > > MPLS-TP is step 13 in the figure on page 7 of that draft. We are > > asking the ad hoc Team if the draft is good enough to send to the > > IESG with a request for publication. >=20 > However these are not new questions, the issues were raised during > the ITU-T plenary and were supposed to be resolved. >=20 > > Please note that we are only expecting a "yes" or "no" answer to > > our question. >=20 > I understand, but in this case it would be a conditional yes, > because, as I mentioned above, not all issues were resolved. >=20 > > If the response is "yes" then publication will be requested, if > > the answer is "no", the document will be taken back into the > > working group process and a new version produced. > > > > That said, there is never wrong to discuss technical improvements, > > editorial issues or genereal clarifications on any draft. >=20 > What is the purpose of discussing them when the publication has > started. Unless this is a working method accepted in the IETF. > and there is still a possibility to make technical changes/ > adjustments. >=20 > In the ITU-T once a recommendation draft is consented (yes is > received) then the draft is pre-published. > The ITU-T editors will than bring the document in a shape > that is can be officially published, but in this stage no > technical changes can be made any more, only typographical. >=20 > Regards, Huub. >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.van-helvoort.eu/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From amalis@gmail.com Mon Apr 20 08:28:55 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3A03A6DBD for ; Mon, 20 Apr 2009 08:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4IDmycW-9sO for ; Mon, 20 Apr 2009 08:28:54 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 1E5163A6DBC for ; Mon, 20 Apr 2009 08:28:54 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so805617qwe.31 for ; Mon, 20 Apr 2009 08:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=XYQs2mGt2QOvH09sheeN4gdV+7dXrBvLSNu1OnrnsWo=; b=AU3DtRPoEMnze3sQMQ02/MLelgA7uUELxj7Wyq5BJzE3Fs7lA1VQGImrjIIWe7MkI4 Xt9vQKOf5sDxUNNGOqhr87qT0KqB4n4qB933EFJKZRmIGnWz+wyvqgYHcZxVMgF7WOd2 zcr70ww2ssWmcjpI8U6So/B913R+wX0IjeHAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=rOMOa2PQX5Hryoa0EYA+qPCG8LWmSrZ0fCrhqEUXHhR5glrXaLYrC0qrkbbuH8dxNb fPXtEtvqQUPS8sEMa48Wwy1occ2tYHbyMq00F5j0jQdYWFuR4Ja5qrC5TlK6i2aIfOQL rBx04uG6lyuNwUaL4e1EVnX7hKbZSxgZcCEXY= MIME-Version: 1.0 Received: by 10.224.67.130 with SMTP id r2mr6324358qai.281.1240241409513; Mon, 20 Apr 2009 08:30:09 -0700 (PDT) In-Reply-To: <49EC8F69.30000@chello.nl> References: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> <49EC8F69.30000@chello.nl> From: "Andrew G. Malis" Date: Mon, 20 Apr 2009 11:29:54 -0400 Message-ID: To: hhelvoort@chello.nl Content-Type: multipart/alternative; boundary=0015175cb888a6bfab0467fe3410 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:28:55 -0000 --0015175cb888a6bfab0467fe3410 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Huub, In the IETF, you can always bring up technical or other issues until the RFC is actually published, although it's really best if they come up before the draft goes on the RFC editor's queue, although the IESG can pull it back if necessary. Of course, things are best if all technical issues are resolved prior to or during WG last call. However, once it goes into IESG review, one can always make issues known to the relevant AD, and the AD can decide if it's worth changing the draft. In the latter stages of IESG review, there's also an IETF last call where there's a last chance for anyone to comment on the draft back to the IESG. In this case, it still sounds like there are some issues you would like resolved before it goes to the IESG. Cheers, Andy On Mon, Apr 20, 2009 at 11:06 AM, Huub van Helvoort wrote: > > Hej Loa, > > You wrote: > > All, >> >> I'd like to comment on the current discussion on >> http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-06 . >> >> We do our best follow the the mpls-tp process as described in: >> >> http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt >> > > I agree. > > The outstanding question we have for the ITU-T ad hoc team on >> MPLS-TP is step 13 in the figure on page 7 of that draft. We are >> asking the ad hoc Team if the draft is good enough to send to the >> IESG with a request for publication. >> > > However these are not new questions, the issues were raised during > the ITU-T plenary and were supposed to be resolved. > > Please note that we are only expecting a "yes" or "no" answer to >> our question. >> > > I understand, but in this case it would be a conditional yes, > because, as I mentioned above, not all issues were resolved. > > If the response is "yes" then publication will be requested, if >> the answer is "no", the document will be taken back into the >> working group process and a new version produced. >> >> That said, there is never wrong to discuss technical improvements, >> editorial issues or genereal clarifications on any draft. >> > > What is the purpose of discussing them when the publication has > started. Unless this is a working method accepted in the IETF. > and there is still a possibility to make technical changes/ > adjustments. > > In the ITU-T once a recommendation draft is consented (yes is > received) then the draft is pre-published. > The ITU-T editors will than bring the document in a shape > that is can be officially published, but in this stage no > technical changes can be made any more, only typographical. > > Regards, Huub. > > -- > ================================================================ > http://www.van-helvoort.eu/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --0015175cb888a6bfab0467fe3410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Huub,

In the IETF, you can always bring up technical or other issues= until the RFC is actually published, although it's really best if they= come up before the draft goes on the RFC editor's queue, although the = IESG can pull it back if necessary.

Of course, things are best if all technical issues are resolved prior t= o or during WG last call. However, once it goes into IESG review, one can a= lways make issues known to the relevant AD, and the AD can decide if it'= ;s worth changing the draft. In the latter stages of IESG review, there'= ;s also an IETF last call where there's a last chance for anyone to com= ment on the draft back to the IESG.

In this case, it still sounds like there are some issues you would like= resolved before it goes to the IESG.

Cheers,
Andy

On Mon, Apr 20, 2009 at 11:06 AM, Huub van Helvoort <hhelvoort@chello.= nl> wrote:

Hej Loa,

You wrote:

All,

I'd like to comment on the current discussion on
http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements= -06 .

We do our best follow the the mpls-tp process as described in:

http://www.ietf.org/internet-drafts/draft-and= ersson-mpls-tp-process-01.txt

I agree.

The outstanding question we have for the ITU-T ad hoc team on
MPLS-TP is step 13 in the figure on page 7 of that draft. We are
asking the ad hoc Team if the draft is good enough to send to the
IESG with a request for publication.

However these are not new questions, the issues were raised during
the ITU-T plenary and were supposed to be resolved.

Please note that we are only expecting a "yes" or "no" = answer to
our question.

I understand, but in this case it would be a conditional yes,
because, as I mentioned above, not all issues were resolved.

If the response is "yes" then publication will be requested, if the answer is "no", the document will be taken back into the
working group process and a new version produced.

That said, there is never wrong to discuss technical improvements,
editorial issues or genereal clarifications on any draft.

What is the purpose of discussing them when the publication has
started. Unless this is a working method accepted in the IETF.
and there is still a possibility to make technical changes/
adjustments.

In the ITU-T once a recommendation draft is consented (yes is
received) then the draft is pre-published.
The ITU-T editors will than bring the document in a shape
that is can be officially published, but in this stage no
technical changes can be made any more, only typographical.

Regards, Huub.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.van-helvoort.eu/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp

--0015175cb888a6bfab0467fe3410-- From twalsh@juniper.net Mon Apr 20 08:33:13 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102D728C2D2 for ; Mon, 20 Apr 2009 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.716 X-Spam-Level: X-Spam-Status: No, score=-6.716 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XaImMagqQJk for ; Mon, 20 Apr 2009 08:33:08 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id 3958A28C0E6 for ; Mon, 20 Apr 2009 08:32:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob59.postini.com ([64.18.6.12]) with SMTP ID DSNKSeyVw2uNFu7KQFmnThm7pM92V0lOuphQ@postini.com; Mon, 20 Apr 2009 08:33:27 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 20 Apr 2009 08:32:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 20 Apr 2009 11:32:56 -0400 From: Thomas Walsh To: "Andrew G. Malis" , "hhelvoort@chello.nl" Date: Mon, 20 Apr 2009 11:32:51 -0400 Thread-Topic: [mpls-tp] comment on MPLS-TP document processing Thread-Index: AcnBzOocoDXhHDi4RBKy2cknJoYLlwAAB3ug Message-ID: References: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> <49EC8F69.30000@chello.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A4C6A166C36F5F40A5767E6F66358FC08E8309FF8DEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:33:13 -0000 --_000_A4C6A166C36F5F40A5767E6F66358FC08E8309FF8DEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, Huub, The way I would interpret Huub's comment is his "conditional yes" is more l= ike a "No with comments" as is done in some bodies. If the comments are r= esolved then the "no" is changed to a "yes" Is that the right interpretation? Tom ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Andrew G. Malis Sent: Monday, April 20, 2009 8:30 AM To: hhelvoort@chello.nl Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] comment on MPLS-TP document processing Huub, In the IETF, you can always bring up technical or other issues until the RF= C is actually published, although it's really best if they come up before t= he draft goes on the RFC editor's queue, although the IESG can pull it back= if necessary. Of course, things are best if all technical issues are resolved prior to or= during WG last call. However, once it goes into IESG review, one can alway= s make issues known to the relevant AD, and the AD can decide if it's worth= changing the draft. In the latter stages of IESG review, there's also an I= ETF last call where there's a last chance for anyone to comment on the draf= t back to the IESG. In this case, it still sounds like there are some issues you would like res= olved before it goes to the IESG. Cheers, Andy On Mon, Apr 20, 2009 at 11:06 AM, Huub van Helvoort > wrote: Hej Loa, You wrote: All, I'd like to comment on the current discussion on http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-06 . We do our best follow the the mpls-tp process as described in: http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt I agree. The outstanding question we have for the ITU-T ad hoc team on MPLS-TP is step 13 in the figure on page 7 of that draft. We are asking the ad hoc Team if the draft is good enough to send to the IESG with a request for publication. However these are not new questions, the issues were raised during the ITU-T plenary and were supposed to be resolved. Please note that we are only expecting a "yes" or "no" answer to our question. I understand, but in this case it would be a conditional yes, because, as I mentioned above, not all issues were resolved. If the response is "yes" then publication will be requested, if the answer is "no", the document will be taken back into the working group process and a new version produced. That said, there is never wrong to discuss technical improvements, editorial issues or genereal clarifications on any draft. What is the purpose of discussing them when the publication has started. Unless this is a working method accepted in the IETF. and there is still a possibility to make technical changes/ adjustments. In the ITU-T once a recommendation draft is consented (yes is received) then the draft is pre-published. The ITU-T editors will than bring the document in a shape that is can be officially published, but in this stage no technical changes can be made any more, only typographical. Regards, Huub. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --_000_A4C6A166C36F5F40A5767E6F66358FC08E8309FF8DEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy, Huub,

The way I would interpret Huub’s comment is his “conditional yes” is more like a “No with comments” as is done in some bodies.   If the comments are = resolved then the “no” is changed to a “yes”

Is that the right interpretation?=

Tom

From: mpls-tp-= bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Be= half Of Andrew G. Malis
Sent: Monday, April 20, 2009= 8:30 AM
To: hhelvoort@chello.nl
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] comme= nt on MPLS-TP document processing

Huub,

In the IETF, you can always bring up technical or other issues until the RF= C is actually published, although it's really best if they come up before the dr= aft goes on the RFC editor's queue, although the IESG can pull it back if necessary.

Of course, things are best if all technical issues are resolved prior to or during WG last call. However, once it goes into IESG review, one can always make issues known to the relevant AD, and the AD can decide if it's worth changing the draft. In the latter stages of IESG review, there's also an IE= TF last call where there's a last chance for anyone to comment on the draft ba= ck to the IESG.

In this case, it still sounds like there are some issues you would like resolved before it goes to the IESG.

Cheers,
Andy

On Mon, Apr 20, 2009 at 11:06 AM, Huub van Helvoort <hhelvoort@chello.nl> wrote:=

Hej Loa,

You wrote:

All,

I'd like to comment on the current discussion on
http://tools.ietf.org/html/draft-ietf-mpls-tp-requirement= s-06 .

We do our best follow the the mpls-tp process as described in:

http://www.ietf.org/internet-drafts/draft-andersson-mpls-= tp-process-01.txt

I agree.

=

The outstanding question we have for the ITU-T ad hoc team on
MPLS-TP is step 13 in the figure on page 7 of that draft. We are
asking the ad hoc Team if the draft is good enough to send to the
IESG with a request for publication.

However these are not new questions, the issues were raised during<= br> the ITU-T plenary and were supposed to be resolved.

=

Please note that we are only expecting a "yes" or "no" answer to
our question.

I understand, but in this case it would be a conditional yes,
because, as I mentioned above, not all issues were resolved.

=

If the response is "yes" then publication will be request= ed, if
the answer is "no", the document will be taken back into the
working group process and a new version produced.

That said, there is never wrong to discuss technical improvements,
editorial issues or genereal clarifications on any draft.=

What is the purpose of discussing them when the publication has
started. Unless this is a working method accepted in the IETF.
and there is still a possibility to make technical changes/
adjustments.

In the ITU-T once a recommendation draft is consented (yes is
received) then the draft is pre-published.
The ITU-T editors will than bring the document in a shape
that is can be officially published, but in this stage no
technical changes can be made any more, only typographical.

Regards, Huub.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http://www.van-helvo= ort.eu/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp=

--_000_A4C6A166C36F5F40A5767E6F66358FC08E8309FF8DEMBX01WFjnprn_-- From dbrungard@att.com Mon Apr 20 08:47:58 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C6F3A67D7 for ; Mon, 20 Apr 2009 08:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhK0O3dPo3hN for ; Mon, 20 Apr 2009 08:47:56 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id C82063A6EAE for ; Mon, 20 Apr 2009 08:47:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1240242549!9326103!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 436 invoked from network); 20 Apr 2009 15:49:10 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Apr 2009 15:49:10 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3KFn993012088 for ; Mon, 20 Apr 2009 11:49:09 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3KFn405011996 for ; Mon, 20 Apr 2009 11:49:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {ADB2306B-6B0C-494E-A709-CE6E37A192CD} x-cr-hashedpuzzle: A0Sg A5xB FmIG HaFO LjK8 RJRT RaCv RnZ/ SSlQ THqJ U7lV YPz5 ZFwO aPqS bQ/G bb12; 3; bQBhAGEAcgB0AGUAbgAuAHYAaQBzAHMAZQByAHMAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAbQBwAGwAcwAtAHQAcABAAGkAZQB0AGYALgBvAHIAZwA7AG4AZQBpAGwALgAyAC4AaABhAHIAcgBpAHMAbwBuAEAAYgB0AC4AYwBvAG0A; Sosha1_v1; 7; {ADB2306B-6B0C-494E-A709-CE6E37A192CD}; ZABiAHIAdQBuAGcAYQByAGQAQABhAHQAdAAuAGMAbwBtAA==; Mon, 20 Apr 2009 15:47:26 GMT; UgBFADoAIABbAG0AcABsAHMALQB0AHAAXQAgAEEAcwBzAG8AYwBpAGEAdABlAGQAIABiAGkAZABpAHIAZQBjAHQAaQBvAG4AYQBsACAAdAByAGEAbgBzAHAAbwByAHQAIABwAGEAdABoACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMA Content-class: urn:content-classes:message Date: Mon, 20 Apr 2009 11:47:26 -0400 Message-ID: In-Reply-To: <006701c9c1c1$0e6bbb40$1301540a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWgABQg5yAAAjIJkACKNDywAARnRGA= References: <2ECAA42C79676B42AEBAC11229CA7D0C046FFEDD@E03MVB2-UKBR.domain1.systemhost.net> <006701c9c1c1$0e6bbb40$1301540a@china.huawei.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Maarten Vissers" , Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:47:58 -0000 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From maarten.vissers@huawei.com Mon Apr 20 09:26:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3F13A6D48 for ; Mon, 20 Apr 2009 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FGqVF8jC1t9 for ; Mon, 20 Apr 2009 09:26:40 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id 750823A69D4 for ; Mon, 20 Apr 2009 09:26:40 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042009275325796 ; Mon, 20 Apr 2009 09:27:53 -0700 Received: from M00900002 ([10.84.1.19]) by s-utl01-sjpop.stsn.net; Mon, 20 Apr 2009 09:27:50 -0700 From: "Maarten Vissers" To: "'Adrian Farrel'" Date: Mon, 20 Apr 2009 18:27:42 +0200 Message-ID: <002601c9c1d4$f4dde4a0$1301540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <8E1BB972CF3B4CAD83881CAD192D6BD8@your029b8cecfe> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acm+l6VWoGN6DhPMTiCqsksguEpPBQDPIoEg Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 16:26:41 -0000 Adrian, I agree with you that the term "TCM" and its implied meaning can be replaced by the underlying specification/requirement. But the concept represented by the term TCM can not be replaced. From the latest correspondence I believe that this is now agreed. Regards, Maarten -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: donderdag 16 april 2009 14:48 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] Maarten, You take the requirement that is stated in the document and make a claim based on some *other* function that you want to achieve. In order to write a good requirements document, you must learn to state the functional requirement and not the solutions that you assume (perhaps correctly) are necessary to meet the requirement. So, from your example, you have a requirement to be able to perform loopback OAM at MIPs. Why not state that requirement and allow the solutions to flow from that? As to the following... >> The entirety of the bracketed text "(including MEPs, MIPs and other >> internal functions as appropriate)" should be deleted. It does not >> add to "The intermediate nodes." > > Your understanding is not correct. This text must not be deleted at all. I can only thank you for your constructive and well-reasoned argument. The original text reads... The intermediate nodes (including MEPs, MIPs and other internal functions as appropriate) of a co-routed bidirectional transport path Since MEPs, MIPs and other internal functions are just examples of intermediate nodes, the sentence loses nothing if it reads The intermediate nodes of a co-routed bidirectional transport path Furthermore, *any* text that reaches me as AD including "as appropriate" is highly likely to be turned around. If the authors do not know what they mean and have used the phrase to avoid working it out, then it needs to be fixed. If the authors do know what they mean, they should say it. Wrt "Tandem Connection" I'm not sure it is a fruitful discussion. Have a look at TDM OAM and tell me whether the OAM is actually inserted in the data path (hint: why is it called "overhead"?). None of this discussion of TCM is useful. The term is redundant. Adding redundant terms does not increase clarity. Adrian ----- Original Message ----- From: "Maarten Vissers" To: "'Adrian Farrel'" Cc: Sent: Thursday, April 16, 2009 1:24 PM Subject: RE: [mpls-tp] Associated bidirectional transport path requirements > Adrian, > >>> >>> The intermediate nodes (including MEPs, MIPs and other internal >>> functions as appropriate) of a co-routed bidirectional transport >>> path at each (sub-)layer MUST be aware of the pairing >>> relationship of the forward and the backward directions of that >>> transport path. >>> >> >> There is no way this is a functional requirement. That is, there is >> *nothing* that can be observed from a black box point of view that >> results from adhering to this requirement. > > Your understanding is not correct. It is very much observable if this > requirement is met from a black box point of view. The MIP functions can > only perform the Loopback when there is a co-routed bidirectional > transport > path. The MPLS-TP LBM packet received at a MIP needs to be returned (as > LBR > packet) to the originating MEP function via the other direction of the > co-routed bidirectional transport path. This other direction would not be > available in an associated bidirectional transport path... and thus the > loopback test would fail. > > Similarly, when we have to apply TCM MEPs to monitor a segment, then this > is > possible in a co-routed bidir transport path but not in a associated bidir > transport path. In the first case the TCM MEP Source and Sink functions > are > co-located and can exchange what is called "remote information" which is > necessary for performance monitoring. In the latter case the TCM MEP > Source > and Sink functions are in e.g. different nodes in the network and TCM > would > not be able to provide performance monitoring. > >> The entirety of the bracketted text "(including MEPs, MIPs and other > internal >> functions as appropriate)" should be deleted. It does not add to "The >> intermediate nodes." > > Your understanding is not correct. This text must not be deleted at all. > >> Actually, I am quite fed up about this persistent insistence on the > inclusion >> of "Tandem Connection." The definition within the ITU-T of this term is > poorly >> specified and comes from the monitoring of a path that is parallel (i.e. > tandem) >> to the data path being monitored. This definition of TC seems to be at > variance, >> and would be if the ACH was actually in band. > > I don't understand where your interpretation of tandem connection is > described in ITU-T recommendations. I.e. "from the monitoring of a path > that > is parallel (i.e. tandem) to the data path being monitored."? > > There is a "network connection" and this network connection is a set of > interconnected "link connections" and "matrix connections". A subset of > those interconnected link connections and matrix connections can be > monitored and is then referred to as a "tandem connection". There is no > "path that is parallel to the data path". There is only additional OAM > inserted inside the data path by the TCM MEP_So function and this OAM is > extracted from the data path by the TCM MEP_Sk function. > > Regards, > Maarten > > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: donderdag 16 april 2009 11:59 > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > Cc: BUSI ITALO; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Hi Sasha, > >> Unfortunately I cannot fully agree with your statement: >> >> >> From the point of view of hardware, co-routed bidirectional LSPs >> are a special case of associated bidirectional LSPs. >> >> >> This statement would be obviously correct, were it not for Requirement >> 34 in the latest MPLS-TP requirements draft > > OK. Got it. > > But what is this doing in the data plane requirements section? > > In fact, what is this requirement actually saying? > >> >> The intermediate nodes (including MEPs, MIPs and other internal >> functions as appropriate) of a co-routed bidirectional transport >> path at each (sub-)layer MUST be aware of the pairing >> relationship of the forward and the backward directions of that >> transport path. >> > > There is no way this is a functional requirement. That is, there is > *nothing* that can be observed from a black box point of view that results > from adhering to this requirement. > > Therefore it could be assumed that this requirement is met by configuring > some data plane database component through the management plane. The > database component is not used for anything except to satisfy this > requirement for "awareness". > > Ben! Can we please try to rewrite this requirement in terms of behavior? > >> Please note that Requirement 34 is the ONLY item in the list that is >> specific for co-routed bidirectional LSPs. (The pairing requirements >> at end points for co-routed and associated bidirectional paths are >> exactly the same even if they appear in two different items in the >> requirements' list). >> In other words, without Requirement 34 the notion of co-routed >> bidirectional paths would be void of any data plane content. >> >> The somewhat vague scope of this requirement ("other internal >> functions as appropriate") creates a suspicion that HW support of the >> pairing awareness may be required in order to comply with it. > > The entirety of the bracketted text "(including MEPs, MIPs and other > internal functions as appropriate)" should be deleted. It does not add to > "The intermediate nodes." > >> The following text in the draft increases this suspicion: >> >> >> Tandem Connection: A tandem connection is an arbitrary part of a >> transport path that can be monitored (via OAM) independently from the >> end-to-end monitoring (OAM). It may be a monitored segment or a >> monitored concatenated segment of a transport path. The tandem >> connection may also include the forwarding engine(s) of the node(s) >> at the edge(s) of the segment or concatenated segment. >> > > Actually, I am quite fed up about this persistent insistence on the > inclusion of "Tandem Connection." The definition within the ITU-T of this > term is poorly specified and comes from the monitoring of a path that is > parallel (i.e. tandem) to the data path being monitored. This definition > of > TC seems to be at variance, and would be if the ACH was actually in band. > >> Doesn't "forwarding engine" sound like hardware to you? > > Yes, but so what? > >> IMHO it is worth noting that neither the MPLS-TP Requirements draft >> nor the MPLS-TP OAM requirements one >> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen >> ts-01.txt) contain any requirements dealing with tandem connections. >> >> But tandem connections are discussed in the MPLS-TP OAM Framework >> draft > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt > ). > > Right. > Let's just get rid of an unnecessary term and bring all the I-Ds into > line. > >> The bottom line, IMHO, is that some clarity regarding co-routed vs. >> associated >> bidirectional paths is still required. One way to provide that could >> be by explicitly limiting Requirement 34 to specific functionality. > > Agreed. > > Adrian > > > > > ________________________________________ > From: Adrian Farrel [adrian@olddog.co.uk] > Sent: Thursday, April 16, 2009 12:13 AM > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Hi Sasha, > > Not really sure whether you are misrepresenting anyone, but... > >> 1. My reading of one of Ben's messages is that associated >> bidirectional paths are the only types of paths that can be created in >> the existing networks; "true" co-routed bidirectional paths will have >> to wait until (if ever) new equipment becomes available. > > This is clearly nonsense! > From the point of view of hardware, co-routed bidirectional LSPs are a > special case of associated bidirectional LSPs. > > If you can set up two unidirectional LSPs (e.g. using the management > plane) > you can surely set up a co-routed bidirectional LSP. > > There are shipping solutions that achieve co-routed bidirectional LSPs > using > the control plane. These either use the GMPLS (which is cleaner) or > non-standard proprietary solutions (which is messy but functional). > > But (of course) the management plane or control plane solutions have > nothing > to do with availability of equipment as they are software solutions. > >> 2. My reading of one of Neil's messages is that the actual driver for >> co-routed bidirectional paths may be experience with existing >> transport networks rather than any specific benefit. > > Isn't that the case with 75% of the MPLS-TP requirements? > Which is not to say it is a bad thing. > > A large driver for MPLS-TP is to give the packet network the look, feel, > and > behavioral characteristics of a "legacy" transport network. > >> Based on these observations, I'd guess (FWIW) that: >> * associated bidirectional paths are, at least for the time >> being, the most important type of bidirectional paths in >> MPLS-TP > > I think that is wrong both given my statement above, and given that other > upgrades to existing MPLS solutions will be needed to reach the full > function level of MPLS-TP. > >> * they had a good chance to remain the only type of bidirectional >> paths in real deployments. > > I don't see what that follows from. > > Cheers, > Adrian > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > From adrian@olddog.co.uk Mon Apr 20 10:03:49 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AC128C0FD for ; Mon, 20 Apr 2009 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9NFbqmR-kF4 for ; Mon, 20 Apr 2009 10:03:48 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id AFA9E28C16C for ; Mon, 20 Apr 2009 10:03:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3KH4tV1004565; Mon, 20 Apr 2009 18:04:56 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3KH4rOD004544; Mon, 20 Apr 2009 18:04:54 +0100 Message-ID: From: "Adrian Farrel" To: "Maarten Vissers" References: <002601c9c1d4$f4dde4a0$1301540a@china.huawei.com> Date: Mon, 20 Apr 2009 18:04:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 17:03:49 -0000 Hi, Sounds like an agreement? We will craft the relevant requirements in terms of the function we want to see, and avoid (in these documents) the term "TCM". If what we end up with is architectural and functional requirements that identical to TCM that will be fine, and if what we end up with is a subtly different that will also be fine. Then, once the requirements are fully stable, we can look at the solution. Thanks. I think the authors now have a clear path for updating the documents. Adrian ----- Original Message ----- From: "Maarten Vissers" To: "'Adrian Farrel'" Cc: Sent: Monday, April 20, 2009 5:27 PM Subject: RE: Requirement 34 and TCM[Was: Associated bidirectional transport path requirements] > Adrian, > > I agree with you that the term "TCM" and its implied meaning can be > replaced > by the underlying specification/requirement. But the concept represented > by > the term TCM can not be replaced. From the latest correspondence I believe > that this is now agreed. > > Regards, > Maarten > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: donderdag 16 april 2009 14:48 > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Requirement 34 and TCM[Was: Associated bidirectional transport > path > requirements] > > Maarten, > > You take the requirement that is stated in the document and make a claim > based on some *other* function that you want to achieve. > > In order to write a good requirements document, you must learn to state > the > functional requirement and not the solutions that you assume (perhaps > correctly) are necessary to meet the requirement. > > So, from your example, you have a requirement to be able to perform > loopback > OAM at MIPs. Why not state that requirement and allow the solutions to > flow > from that? > > > As to the following... > >>> The entirety of the bracketed text "(including MEPs, MIPs and other >>> internal functions as appropriate)" should be deleted. It does not >>> add to "The intermediate nodes." >> >> Your understanding is not correct. This text must not be deleted at all. > > I can only thank you for your constructive and well-reasoned argument. > > The original text reads... > > The intermediate nodes (including MEPs, MIPs and other internal > functions as appropriate) of a co-routed bidirectional transport > path > > Since MEPs, MIPs and other internal functions are just examples of > intermediate nodes, the sentence loses nothing if it reads > > The intermediate nodes of a co-routed bidirectional transport > path > > Furthermore, *any* text that reaches me as AD including "as appropriate" > is > highly likely to be turned around. If the authors do not know what they > mean > and have used the phrase to avoid working it out, then it needs to be > fixed. > > If the authors do know what they mean, they should say it. > > > Wrt "Tandem Connection" I'm not sure it is a fruitful discussion. Have a > look at TDM OAM and tell me whether the OAM is actually inserted in the > data > path (hint: why is it called "overhead"?). None of this discussion of TCM > is > useful. The term is redundant. Adding redundant terms does not increase > clarity. > > Adrian > > > ----- Original Message ----- > From: "Maarten Vissers" > To: "'Adrian Farrel'" > Cc: > Sent: Thursday, April 16, 2009 1:24 PM > Subject: RE: [mpls-tp] Associated bidirectional transport path > requirements > > >> Adrian, >> >>>> >>>> The intermediate nodes (including MEPs, MIPs and other internal >>>> functions as appropriate) of a co-routed bidirectional transport >>>> path at each (sub-)layer MUST be aware of the pairing >>>> relationship of the forward and the backward directions of that >>>> transport path. >>>> >>> >>> There is no way this is a functional requirement. That is, there is >>> *nothing* that can be observed from a black box point of view that >>> results from adhering to this requirement. >> >> Your understanding is not correct. It is very much observable if this >> requirement is met from a black box point of view. The MIP functions can >> only perform the Loopback when there is a co-routed bidirectional >> transport >> path. The MPLS-TP LBM packet received at a MIP needs to be returned (as >> LBR >> packet) to the originating MEP function via the other direction of the >> co-routed bidirectional transport path. This other direction would not be >> available in an associated bidirectional transport path... and thus the >> loopback test would fail. >> >> Similarly, when we have to apply TCM MEPs to monitor a segment, then this >> is >> possible in a co-routed bidir transport path but not in a associated >> bidir >> transport path. In the first case the TCM MEP Source and Sink functions >> are >> co-located and can exchange what is called "remote information" which is >> necessary for performance monitoring. In the latter case the TCM MEP >> Source >> and Sink functions are in e.g. different nodes in the network and TCM >> would >> not be able to provide performance monitoring. >> >>> The entirety of the bracketted text "(including MEPs, MIPs and other >> internal >>> functions as appropriate)" should be deleted. It does not add to "The >>> intermediate nodes." >> >> Your understanding is not correct. This text must not be deleted at all. >> >>> Actually, I am quite fed up about this persistent insistence on the >> inclusion >>> of "Tandem Connection." The definition within the ITU-T of this term is >> poorly >>> specified and comes from the monitoring of a path that is parallel (i.e. >> tandem) >>> to the data path being monitored. This definition of TC seems to be at >> variance, >>> and would be if the ACH was actually in band. >> >> I don't understand where your interpretation of tandem connection is >> described in ITU-T recommendations. I.e. "from the monitoring of a path >> that >> is parallel (i.e. tandem) to the data path being monitored."? >> >> There is a "network connection" and this network connection is a set of >> interconnected "link connections" and "matrix connections". A subset of >> those interconnected link connections and matrix connections can be >> monitored and is then referred to as a "tandem connection". There is no >> "path that is parallel to the data path". There is only additional OAM >> inserted inside the data path by the TCM MEP_So function and this OAM is >> extracted from the data path by the TCM MEP_Sk function. >> >> Regards, >> Maarten >> >> >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf >> Of Adrian Farrel >> Sent: donderdag 16 april 2009 11:59 >> To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com >> Cc: BUSI ITALO; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Hi Sasha, >> >>> Unfortunately I cannot fully agree with your statement: >>> >>> >>> From the point of view of hardware, co-routed bidirectional LSPs >>> are a special case of associated bidirectional LSPs. >>> >>> >>> This statement would be obviously correct, were it not for Requirement >>> 34 in the latest MPLS-TP requirements draft >> >> OK. Got it. >> >> But what is this doing in the data plane requirements section? >> >> In fact, what is this requirement actually saying? >> >>> >>> The intermediate nodes (including MEPs, MIPs and other internal >>> functions as appropriate) of a co-routed bidirectional transport >>> path at each (sub-)layer MUST be aware of the pairing >>> relationship of the forward and the backward directions of that >>> transport path. >>> >> >> There is no way this is a functional requirement. That is, there is >> *nothing* that can be observed from a black box point of view that >> results >> from adhering to this requirement. >> >> Therefore it could be assumed that this requirement is met by configuring >> some data plane database component through the management plane. The >> database component is not used for anything except to satisfy this >> requirement for "awareness". >> >> Ben! Can we please try to rewrite this requirement in terms of behavior? >> >>> Please note that Requirement 34 is the ONLY item in the list that is >>> specific for co-routed bidirectional LSPs. (The pairing requirements >>> at end points for co-routed and associated bidirectional paths are >>> exactly the same even if they appear in two different items in the >>> requirements' list). >>> In other words, without Requirement 34 the notion of co-routed >>> bidirectional paths would be void of any data plane content. >>> >>> The somewhat vague scope of this requirement ("other internal >>> functions as appropriate") creates a suspicion that HW support of the >>> pairing awareness may be required in order to comply with it. >> >> The entirety of the bracketted text "(including MEPs, MIPs and other >> internal functions as appropriate)" should be deleted. It does not add to >> "The intermediate nodes." >> >>> The following text in the draft increases this suspicion: >>> >>> >>> Tandem Connection: A tandem connection is an arbitrary part of a >>> transport path that can be monitored (via OAM) independently from the >>> end-to-end monitoring (OAM). It may be a monitored segment or a >>> monitored concatenated segment of a transport path. The tandem >>> connection may also include the forwarding engine(s) of the node(s) >>> at the edge(s) of the segment or concatenated segment. >>> >> >> Actually, I am quite fed up about this persistent insistence on the >> inclusion of "Tandem Connection." The definition within the ITU-T of this >> term is poorly specified and comes from the monitoring of a path that is >> parallel (i.e. tandem) to the data path being monitored. This definition >> of >> TC seems to be at variance, and would be if the ACH was actually in band. >> >>> Doesn't "forwarding engine" sound like hardware to you? >> >> Yes, but so what? >> >>> IMHO it is worth noting that neither the MPLS-TP Requirements draft >>> nor the MPLS-TP OAM requirements one >>> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen >>> ts-01.txt) contain any requirements dealing with tandem connections. >>> >>> But tandem connections are discussed in the MPLS-TP OAM Framework >>> draft >> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt >> ). >> >> Right. >> Let's just get rid of an unnecessary term and bring all the I-Ds into >> line. >> >>> The bottom line, IMHO, is that some clarity regarding co-routed vs. >>> associated >>> bidirectional paths is still required. One way to provide that could >>> be by explicitly limiting Requirement 34 to specific functionality. >> >> Agreed. >> >> Adrian >> >> >> >> >> ________________________________________ >> From: Adrian Farrel [adrian@olddog.co.uk] >> Sent: Thursday, April 16, 2009 12:13 AM >> To: Alexander Vainshtein; Lou Berger; BUSI ITALO >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Hi Sasha, >> >> Not really sure whether you are misrepresenting anyone, but... >> >>> 1. My reading of one of Ben's messages is that associated >>> bidirectional paths are the only types of paths that can be created in >>> the existing networks; "true" co-routed bidirectional paths will have >>> to wait until (if ever) new equipment becomes available. >> >> This is clearly nonsense! >> From the point of view of hardware, co-routed bidirectional LSPs are a >> special case of associated bidirectional LSPs. >> >> If you can set up two unidirectional LSPs (e.g. using the management >> plane) >> you can surely set up a co-routed bidirectional LSP. >> >> There are shipping solutions that achieve co-routed bidirectional LSPs >> using >> the control plane. These either use the GMPLS (which is cleaner) or >> non-standard proprietary solutions (which is messy but functional). >> >> But (of course) the management plane or control plane solutions have >> nothing >> to do with availability of equipment as they are software solutions. >> >>> 2. My reading of one of Neil's messages is that the actual driver for >>> co-routed bidirectional paths may be experience with existing >>> transport networks rather than any specific benefit. >> >> Isn't that the case with 75% of the MPLS-TP requirements? >> Which is not to say it is a bad thing. >> >> A large driver for MPLS-TP is to give the packet network the look, feel, >> and >> behavioral characteristics of a "legacy" transport network. >> >>> Based on these observations, I'd guess (FWIW) that: >>> * associated bidirectional paths are, at least for the time >>> being, the most important type of bidirectional paths in >>> MPLS-TP >> >> I think that is wrong both given my statement above, and given that other >> upgrades to existing MPLS solutions will be needed to reach the full >> function level of MPLS-TP. >> >>> * they had a good chance to remain the only type of bidirectional >>> paths in real deployments. >> >> I don't see what that follows from. >> >> Cheers, >> Adrian >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> > > > From neil.2.harrison@bt.com Mon Apr 20 10:38:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF903A6919 for ; Mon, 20 Apr 2009 10:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbcOHfE0HErz for ; Mon, 20 Apr 2009 10:38:11 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 339463A68D8 for ; Mon, 20 Apr 2009 10:38:10 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 18:39:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 18:38:43 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C04700536@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWgABQg5yAAAjIJkACKNDywAARnRGAAAh5sYA== From: To: , X-OriginalArrivalTime: 20 Apr 2009 17:39:25.0865 (UTC) FILETIME=[F2E34190:01C9C1DE] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 17:38:14 -0000 Thanks Deborah...we are only operators/customers...how the heck should we know what we want ;-) All I can say here is that folks need to understand the history of how AIS arose in PDH co-cs networks in the 1st place....binary all 1s (+5V) was the default death signature of the original TTL logic, it required no active/concious effort to create it. Not true in packet-switched networks....AIS generation is an active/conscious decision here. But in any case, I stand by what I said about AIS being a meaningless quantity in cl-ps networks....one needs a *real* long-holding client/server co mode relationship to even consider it of value (not some artifically imposed TCM sublayer hierarchy 'just because we can do it'...we can do lots of things, but its important to distinguish useful work items from those that just generate costs/problems). Maarten said "Ethernet AIS is indeed a requirement and a necessity." Really? If it's that vital 'a requirement and necessity' then perhaps Maarten would be kind enough to enlighten us why IEEE decided to remove Ethernet AIS from 802.1ag? =20 And I suppose IETF have also made a major error by not specifying AIS in IPv4 and IPv6. regards, Neil > -----Original Message----- > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 > Sent: 20 April 2009 16:47 > To: Maarten Vissers; Harrison,N,Neil,CXM R > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > I agree with Neil, it is very questionable the value of AIS/FDI in a > packet network- any mode. It can result in a DoS attack by an operator > on themselves so even Y1731 recommends not to block data frames: > "A MEP can decide whether it blocks data frames when it detects dAIS. > The principle requirement > that influences this decision is that data frames ought to be=20 > forwarded > as much as possible, without > the possibility of forwarding wrong data frames downstream." > Table I.7-2 shows for AIS, not to block. >=20 > And as Y1731 states, AIS can only be used under very constrained > architectures - if required for MPLS-TP, it needs to have the same > guidance as in Y1731, i.e. point-to-point and server/client=20 > one-to-one: > "for a point-to-point ETH connection, a MEP has only a single=20 > peer MEP. > Therefore, there > is no ambiguity regarding the peer MEP for which it should suppress > alarms when it receives the > ETH-AIS information." > So should only be within one domain - then no need. >=20 > Deborah >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Maarten Vissers > Sent: Monday, April 20, 2009 10:05 AM > To: neil.2.harrison@bt.com > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements >=20 > Neil, >=20 > > but AIS/FDI in the cl mode?...do me a favour! >=20 > Ethernet AIS is indeed a requirement and a necessity. And you will not > be > able to understand that as long as you refuse to accept that "cl-mode" > is a > forwarding mode within a **transport entity**. G.800 amendment 1 has > finally > reintroduced this transport entity into G.800. Besides that, it also > introduced the **differentiated connection**: >=20 > [G.800 am1] "A differentiated connection is a transport entity that > transfers information belonging to multiple communications=20 > between ports > across a subnetwork. <..> In a differentiated connection message > contents > are interpreted to identify (sets of) communications which receive > different > treatment. The sets of communications may be distinguished by the > forwarding identifier or other layer information. Order is not > necessarily > preserved between messages belonging to sets of=20 > communications receiving > different treatment. Sets of communications may be identified for > purposes > such as traffic conditioning or preserving communication=20 > message order." >=20 >=20 > Ethernet VLANs are in terms of G.800 "differentiated connections". > Ethernet > AIS provides AIS within the scope of such "differentiated connection". > If > you apply this to my proposed PTN layer stack, then the EVC layer > topology > will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and > P-OTN > VP trails inside metro and core domains interconnecting EVC matrices. > When > one of those EVC links is interrupted, e.g. in the core=20 > between metro 1 > and > metro 4 (see attached slide), then the EVC differentiated connection > that is > present on this link will be interrupted. At the EVC=20 > switch/bridge node > in > metro 4 this interruption is noticed and EVC-AIS is inserted in the > downstream direction to suppress the EVC-LOC alarms at EVC=20 > endpoints D4 > and > D5. >=20 > The EVC-AIS (i.e. Ethernet AIS) frame has a reserved=20 > multicast address, > which guarantees that the AIS is broadcast to the endpoints=20 > of the EVC. >=20 > I believe that it is time for you to adapt your view on co=20 > and cl modes > and > relate it to the forwarding mode **INSIDE** a transport entity.=20 >=20 > What we know as the internet is essentially an "IP differentiated > connection" with a billion or more ports. > What we know as an IP VPN is essentially an "IP differentiated > connection" > with e.g. n ports (n in the range of e.g. 2 to 1000). > What we know as an Ethernet VLAN is essentially an "Ethernet > differentiated > connection" with n ports (n in the range of e.g. 2 to 1000). > What we know as a p2p MPLS E-LSP is essentially an "MPLS=20 > differentiated > connection" with 2 ports. > What we know as a p2p SDH VC-n is a "SDH VC-n connection"=20 > with 2 ports. >=20 > Transport network OAM applies to transport entities, which=20 > are (in terms > of > G.800 am1) connections and differentiated connections. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: vrijdag 17 april 2009 22:00 > To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; > Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport path > requirements >=20 > John, Thanks this is a great platform to explain why OAM for the 3 > network > modes needs to be different. I am getting a wee bit tired of folks > trying > to make all 3 network modes look alike (and then, even worse,=20 > interwork > them > as as peers...esp when not not top-of-stack > networks...I mean how silly can we get?). I am even more=20 > frustrated by > the fact those peddling this FUD only ever seem to consider OAM and > forget > all other DP/CP/MP components (esp top-of-stack message/file/stream > application adaptations). How wrong can this get!=20 >=20 > In the co modes a *connection* is a very specific and *constraining* > construct.....I am assuming here we respect the rules of a connection > (ie > single source) though some folks don't even bother to respect=20 > this, and > this > is despite the fact that we all know what problems multiple-source > constructs can cause (from LDP/PHP....ergo MPLS-TP). >=20 > When we have a connection this restricts *all* DP (ie traffic and OAM) > to > stay within the bounds of the connection. Which is fine under > defect-free > conditions, but if we have leaking traffic then the=20 > constraining nature > of > the connection construct is broken. In a nutshell what this means is > that > OAM that is of a request/response nature cannot be trusted in co mode > networks under misconnectivity defects.....indeed, why should=20 > a leaking > DP > have a symmetric go/return defect behaviour?....very likely it won't. > So > whilst request/response OAM is right for the cl mode it is=20 > not right for > the > co mode under misconnectivity defect conditions. >=20 > More generally the 3 modes are different and not just in OAM > requirements....but AIS/FDI in the cl mode?...do me a=20 > favour!...at least > IEEE had the good sense to bin this for Ethernet even though=20 > it remains > in > Y.1731. And which is why I often trot-out the rather silly=20 > (to have to > say > this) observation that if IP (cl mode) could do it all then why have > IETF > found it necessary to create MPLS (co-ps) and GMPLS (CP for=20 > co-cs). The > answer lies in the physics...and G.800 attempts to explain that > physics....G.805 does not. >=20 > So, the 3 modes are different...please accept/rejoice in this fact as > they > all offer something different/important. But do not be hoodwinked by > those > who peddle a story that that tries to make the OAM of the 3 modes the > same.=20 >=20 > regards, Neil=20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > Sent: 17 April 2009 20:02 > > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > Italo, > >=20 > > As described in the MPLS TP OAM Requirements I-D, virtually=20 > all of the >=20 > > OAM functions require a return path, and in the absence of a return=20 > > path they are disabled. > >=20 > > As described in David Sinicrope's meeting minutes=20 > > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > > meeting-no > > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing=20 > is used, an=20 > > MPLS TP network needs to be capable of getting IP packets from=20 > > destination to source; neither the minutes nor I stipulate that a=20 > > control plane needs to be used to instantiate this forwarding. > >=20 > > As an aside, the issue of return path for unidirectional=20 > LSPs could be >=20 > > charaterized as the elephant in the room. In the MPLS TP OAM=20 > > Framework I-D, unicast LSPs are only mentioned three times=20 > and return=20 > > paths not at all. > >=20 > > Thanks, > >=20 > > John > > > -----Original Message----- > > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > > Sent: Friday, April 17, 2009 1:59 AM > > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > John, > > >=20 > > > I might have missed the agreement of MPLS-TP being capable of=20 > > > sending replies to OAM requests sent on uni-directional LSPs. > > >=20 > > > This requirement does not belong to the first set of requirements=20 > > > ITU-T is expecting to be met by October. > > >=20 > > > However, I think this in a potential interesting additional=20 > > > requirement to be taken into account (at worst in a > > subsequent phase). > > >=20 > > > I think that this requirement needs to be evaluated versus other=20 > > > more important requirements (e.g. the possibility to work w/o IP=20 > > > forwarding and the need for OAM to continue to monitor the data=20 > > > plane also in case of failures affecting the control or=20 > management=20 > > > plane). > > >=20 > > > I am open to discuss it but not sure this is the right=20 > time because=20 > > > I wish to avoid delaying the first phase of the design solution. > > >=20 > > > Thanks, Italo > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > > Sent: Thursday, April 16, 2009 8:00 PM > > > > To: Alexander Vainshtein; Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > At the meeting last fall at Juniper in Massachusetts, I > > > think it was > > > > agreed that an MPLS TP network needs to have a forwarding > > > capability > > > > for management, control, and OAM packets (e.g., sending > > > replies to OAM > > > > requests sent on uni-directional LSPs) even if it does not > > > have an IP > > > > forwarding data plane. > > > >=20 > > > > > -----Original Message----- > > > > > From: Alexander Vainshtein > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > > To: Maarten Vissers > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Maarten, > > > > > It seems that you've just (implicitly and, probably, > > > > > inadvertently) stated the following: > > > > >=20 > > > > > MPLS-TP OAM will not ever support MIP loopback function > > > (and fault > > > > > localization which requires this function ) for > > > unidirectional P2MP > > > > > and P2P paths. > > > > >=20 > > > > > If this statement is correct, this (IMHO and FWIW) > > raises a valid > > > > > question: > > > > >=20 > > > > > Is MPLS-TP an appropriate solution for these > > types of transport > > > > > paths? > > > > >=20 > > > > > For the reference, IP/MPLS provides this kind of > > > functionality today > > > > > for (unidirectional - but it does not know any other > > > type) P2P LSPs > > > > > as described in RFC 4379. And its extension to P2MP=20 > LSPs seems=20 > > > > > easy... > > > > >=20 > > > > > =20 > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Sasha > > > > >=20 > > > > >=20 > > > > >=20 > > > > > ________________________________________ > > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > > On Behalf > > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > > To: 'Adrian Farrel' > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Adrian, > > > > >=20 > > > > > >> > > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > > other internal > > > > > >> functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > > >> relationship of the forward and the backward > > > > > directions of that > > > > > >> transport path. > > > > > >> > > > > > > > > > > > > There is no way this is a functional requirement. That > > > > is, there is > > > > > > *nothing* that can be observed from a black box point of > > > > view that > > > > > > results from adhering to this requirement. > > > > >=20 > > > > > Your understanding is not correct. It is very much > > observable if > > > > > this requirement is met from a black box point of view. > > > > > The MIP functions can only perform the Loopback when=20 > there is a=20 > > > > > co-routed bidirectional transport path. The MPLS-TP=20 > LBM packet=20 > > > > > received at a MIP needs to be returned (as LBR > > > > > packet) to the originating MEP function via the other > > > direction of > > > > > the co-routed bidirectional transport path. This other > > direction > > > > > would not be available in an associated bidirectional=20 > transport=20 > > > > > path... and thus the loopback test > > > > would fail. > > > > >=20 > > > > > Similarly, when we have to apply TCM MEPs to monitor a > > > segment, then > > > > > this is possible in a co-routed bidir transport path > > but not in a > > > > > associated bidir transport path. In the first case=20 > the TCM MEP=20 > > > > > Source and Sink functions are co-located and can > > exchange what is > > > > > called "remote information" which is necessary for=20 > performance=20 > > > > > monitoring. > > > > > In the latter case the TCM MEP Source and Sink functions > > > are in e.g.=20 > > > > > different nodes in the network and TCM would not be able > > > to provide > > > > > performance monitoring. > > > > >=20 > > > > > > The entirety of the bracketted text "(including MEPs, > > > > MIPs and other > > > > > internal > > > > > > functions as appropriate)" should be deleted. It does not > > > > > add to "The > > > > > > intermediate nodes." > > > > >=20 > > > > > Your understanding is not correct. This text must not be > > > deleted at > > > > > all. > > > > >=20 > > > > > > Actually, I am quite fed up about this persistent > > > > insistence on the > > > > > inclusion > > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > > this term > > > > > > is > > > > > poorly > > > > > > specified and comes from the monitoring of a path that is > > > > > parallel (i.e. > > > > > tandem) > > > > > > to the data path being monitored. This definition of TC > > > > > seems to be at > > > > > variance, > > > > > > and would be if the ACH was actually in band. > > > > >=20 > > > > > I don't understand where your interpretation of tandem > > > connection is > > > > > described in ITU-T recommendations. I.e. "from the > > > monitoring of a > > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > > monitored."? > > > > >=20 > > > > > There is a "network connection" and this network > > > connection is a set > > > > > of interconnected "link connections" and "matrix > > connections". A > > > > > subset of those interconnected link connections and matrix=20 > > > > > connections can be monitored and is then referred to as > > a "tandem > > > > > connection". There is no "path that is parallel to the > > > data path".=20 > > > > > There is only additional OAM inserted inside the data > > path by the > > > > > TCM MEP_So function and this OAM is extracted from the > > > data path by > > > > > the TCM MEP_Sk function. > > > > >=20 > > > > > Regards, > > > > > Maarten > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > > Sent: donderdag 16 april 2009 11:59 > > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Hi Sasha, > > > > >=20 > > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > > bidirectional LSPs > > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > > Requirement > > > > > > 34 in the latest MPLS-TP requirements draft > > > > >=20 > > > > > OK. Got it. > > > > >=20 > > > > > But what is this doing in the data plane requirements section? > > > > >=20 > > > > > In fact, what is this requirement actually saying? > > > > >=20 > > > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > > > functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > > relationship of the forward and the backward > > > > > directions of that > > > > > > transport path. > > > > > > > > > > >=20 > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > > >=20 > > > > > Therefore it could be assumed that this requirement is met by=20 > > > > > configuring some data plane database component through the=20 > > > > > management plane. The database component is not used > > for anything > > > > > except to satisfy this requirement for "awareness". > > > > >=20 > > > > > Ben! Can we please try to rewrite this requirement in=20 > terms of=20 > > > > > behavior? > > > > >=20 > > > > > > Please note that Requirement 34 is the ONLY item in the > > > > > list that is > > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > > requirements > > > > > > at end points for co-routed and associated bidirectional > > > > paths are > > > > > > exactly the same even if they appear in two different > > > > items in the > > > > > > requirements' list). > > > > > > In other words, without Requirement 34 the notion of > > co-routed > > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > > > The somewhat vague scope of this requirement=20 > ("other internal=20 > > > > > > functions as appropriate") creates a suspicion that HW > > > > > support of the > > > > > > pairing awareness may be required in order to=20 > comply with it. > > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > > internal functions as appropriate)" should be deleted. It > > > does not > > > > > add to "The intermediate nodes." > > > > >=20 > > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > > arbitrary part of a > > > > > > transport path that can be monitored (via OAM) > > > > > independently from the > > > > > > end-to-end monitoring (OAM). It may be a monitored > > > segment or a > > > > > > monitored concatenated segment of a transport path. =20 > > > The tandem > > > > > > connection may also include the forwarding engine(s) of > > > > > the node(s) > > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > > inclusion of "Tandem Connection." The definition within > > > the ITU-T of > > > > > this term is poorly specified and comes from the > > monitoring of a > > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > > monitored. This definition of TC seems to be at variance, > > > and would > > > > > be if the ACH was actually in band. > > > > >=20 > > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > > >=20 > > > > > Yes, but so what? > > > > >=20 > > > > > > IMHO it is worth noting that neither the MPLS-TP > > > > Requirements draft > > > > > > nor the MPLS-TP OAM requirements one > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > > ts-01.txt) contain any requirements dealing with tandem > > > > connections. > > > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > > Framework > > > > > > draft > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > > amework-00.txt > > > > > ). > > > > >=20 > > > > > Right. > > > > > Let's just get rid of an unnecessary term and bring all > > the I-Ds > > > > > into line. > > > > >=20 > > > > > > The bottom line, IMHO, is that some clarity regarding > > > > co-routed vs. > > > > > > associated > > > > > > bidirectional paths is still required. One way to provide > > > > > that could > > > > > > be by explicitly limiting Requirement 34 to specific > > > > functionality. > > > > >=20 > > > > > Agreed. > > > > >=20 > > > > > Adrian > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > ________________________________________ > > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Hi Sasha, > > > > >=20 > > > > > Not really sure whether you are misrepresenting anyone, but... > > > > >=20 > > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > > bidirectional paths are the only types of paths that can be > > > > > created in > > > > > > the existing networks; "true" co-routed bidirectional paths > > > > > will have > > > > > > to wait until (if ever) new equipment becomes available. > > > > >=20 > > > > > This is clearly nonsense! > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs are > > > > > a special case of associated bidirectional LSPs. > > > > >=20 > > > > > If you can set up two unidirectional LSPs (e.g. using the > > > management > > > > > plane) you can surely set up a co-routed > > > > bidirectional LSP. > > > > >=20 > > > > > There are shipping solutions that achieve co-routed > > bidirectional > > > > > LSPs using the control plane. These either use the GMPLS > > > (which is > > > > > cleaner) or non-standard proprietary solutions (which is > > > messy but > > > > > functional). > > > > >=20 > > > > > But (of course) the management plane or control plane > > > solutions have > > > > > nothing to do with availability of equipment as they > > are software > > > > > solutions. > > > > >=20 > > > > > > 2. My reading of one of Neil's messages is that the actual > > > > > driver for > > > > > > co-routed bidirectional paths may be experience=20 > with existing=20 > > > > > > transport networks rather than any specific benefit. > > > > >=20 > > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > > Which is not to say it is a bad thing. > > > > >=20 > > > > > A large driver for MPLS-TP is to give the packet network > > > the look, > > > > > feel, and behavioral characteristics of a "legacy" > > > > > transport network. > > > > >=20 > > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > > * associated bidirectional paths are, at least for the time > > > > > > being, the most important type of bidirectional paths in > > > > > > MPLS-TP > > > > >=20 > > > > > I think that is wrong both given my statement above, and > > > given that > > > > > other upgrades to existing MPLS solutions will be > > needed to reach > > > > > the full function level of MPLS-TP. > > > > >=20 > > > > > > * they had a good chance to remain the only type of > > > bidirectional > > > > > > paths in real deployments. > > > > >=20 > > > > > I don't see what that follows from. > > > > >=20 > > > > > Cheers, > > > > > Adrian > > > > >=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 From liu.guoman@zte.com.cn Mon Apr 20 17:46:29 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6A43A6900 for ; Mon, 20 Apr 2009 17:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.597 X-Spam-Level: X-Spam-Status: No, score=-97.597 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXuil82beUDR for ; Mon, 20 Apr 2009 17:46:26 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 73CEB3A6A29 for ; Mon, 20 Apr 2009 17:46:24 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Tue, 21 Apr 2009 08:40:20 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 47274.1367178663; Tue, 21 Apr 2009 08:44:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3L0lbVN012177; Tue, 21 Apr 2009 08:47:37 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <51661468CBD1354294533DA79E85955A01A6C023@XCH-SW-5V2.sw.nos.boeing.com> To: "Drake, John E" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 21 Apr 2009 08:45:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-21 08:47:36, Serialize complete at 2009-04-21 08:47:36 Content-Type: multipart/alternative; boundary="=_alternative 00045BB44825759F_=" X-MAIL: mse2.zte.com.cn n3L0lbVN012177 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 00:46:29 -0000 This is a multipart message in MIME format. --=_alternative 00045BB44825759F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 ICBKb2huOg0KICBtYXliZSBJIGRvbid0IHlvdXIgbWVhbmluZy4gSU1PLiBpdCBpcyBuZWNlc3Nh cnkgZm9yIHVuaWRpcmVjdGlvbmFsIHBhdGggDQp0byBoYXZlIGEgcmV0dXJuIHBhdGguDQoNCiAg cmVnYXJkcw0KICBsaXUNCg0KDQoNCiJEcmFrZSwgSm9obiBFIiA8Sm9obi5FLkRyYWtlMkBib2Vp bmcuY29tPiANCjIwMDktMDQtMjAgMjA6NDgNCg0KytW8/sjLDQo8bGl1Lmd1b21hbkB6dGUuY29t LmNuPg0Ks63LzQ0KPG1wbHMtdHBAaWV0Zi5vcmc+DQrW98ziDQpSRTogW21wbHMtdHBdIEFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0KDQoNCg0K DQoNCg0KIGxpdSwNCg0KUGxlYXNlIHJlLXJlYWQgbXkgZS1tYWlsLiAgWW91IGFyZSBhZ3JlZWlu ZyB3aXRoIG1lLg0KDQpUaGFua3MsDQoNCkpvaG4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBsaXUuZ3VvbWFuQHp0ZS5jb20uY24gW21haWx0bzpsaXUuZ3VvbWFuQHp0 ZS5jb20uY25dIA0KPiBTZW50OiBTdW5kYXksIEFwcmlsIDE5LCAyMDA5IDc6MDEgUE0NCj4gVG86 IERyYWtlLCBKb2huIEUNCj4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IA0KPiBwYXRoIHJlcXVp cmVtZW50cw0KPiANCj4gDQo+IEpvaG6jug0KPiAgSSBkb24ndCBjb21wbGV0ZWx5IGFncmVlIHlv dXIgb3BpbmlvbnMuIGZvciB1bmlkaXJlY3Rpb25hbCANCj4gUDJQIGFuZCBQMk1QIHBhdGgsIGlm IHRoZXJlIGlzIG5vIHJldHVybiBwYXRoLCBob3cgY2FuIHNpbmsgDQo+IHBvaW50cyByZXBseSB0 byBzb3VyY2UgcG9pbnQncyByZXF1ZXN0IHBhY2tldD8gaWYgdGhlcmUgYXJlIA0KPiBzb21lIGZh dWx0cyBpbiB0aGUgYmFja3dhcmQgc2VjdGlvbnMgb2YgdGhpcyB1bmlkaXJlY3Rpb25hbCANCj4g cGF0aCwgdGhlIHNpbmsgcG9pbnRzIHdpbGwgZGV0ZWN0cyB0aGUgZGVmZWN0cywgaWYgbm8gcmV0 dXJuIA0KPiBwYXRoLCBob3cgY2FuIHRoZSBzaW5rIHBvaW50cyBub3RpZnkgdGhlIGZhdWx0IG1l c3NhZ2UgdG8gDQo+IHNvdXJjZSBwb2ludHMuIA0KPiBhbmQgc28sIEkgdGhpbmsgaWYgdGhlcmUg aXMgbm8gcmV0dXJuIHBhdGgsIHdoYXQgaGFwcGVuZWQgdG8gDQo+IHVuaWRpcmVjdGlvbmFsIFAy UCBhbmQgUDJNUCA/IA0KPiBJIHRoaW5rIHdlIGNvbnNpZGVyIHRoZSByZXR1cm4gcGF0aC4gDQo+ IA0KPiByZWdhcmRzDQo+IGxpdSANCj4gDQo+IA0KPiANCj4gIkRyYWtlLCBKb2huIEUiIDxKb2hu LkUuRHJha2UyQGJvZWluZy5jb20+IA0KPiC3orz+yMs6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmcgDQo+IA0KPiAyMDA5LTA0LTE4IDAzOjAyIMrVvP7Iyw0KPiAiQlVTSSBJVEFMTyIgPEl0YWxv LkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+LCAiQWxleGFuZGVyIA0KPiBWYWluc2h0ZWluIiA8QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+LCAiTWFhcnRlbiANCj4gVmlzc2VycyIgPG1h YXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPiANCj4gs63LzQ0KPiBtcGxzLXRwQGlldGYub3JnIA0K PiDW98ziDQo+IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcm9lY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCByZXF1aXJlbWVudHMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gSXRhbG8sDQo+ IA0KPiBBcyBkZXNjcmliZWQgaW4gdGhlIE1QTFMgVFAgT0FNIFJlcXVpcmVtZW50cyBJLUQsIHZp cnR1YWxseSBhbGwgb2YgdGhlDQo+IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJldHVybiBwYXRo LCBhbmQgaW4gdGhlIGFic2VuY2Ugb2YgYSANCj4gcmV0dXJuIHBhdGgNCj4gdGhleSBhcmUgZGlz YWJsZWQuDQo+IA0KPiBBcyBkZXNjcmliZWQgaW4gRGF2aWQgU2luaWNyb3BlJ3MgbWVldGluZyBt aW51dGVzDQo+IChodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9h dHRhY2htZW50L3dpa2kvDQo+IG1lZXRpbmctbm8NCj4gdGVzLzIwMDgxMDE1Lm1wbHMtaW50ZXJv cC1kdC1ub3Rlcy56aXApLCBpZiBJUCBhZGRyZXNzaW5nIGlzIHVzZWQsIGFuDQo+IE1QTFMgVFAg bmV0d29yayBuZWVkcyB0byBiZSBjYXBhYmxlIG9mIGdldHRpbmcgSVAgcGFja2V0cyBmcm9tDQo+ IGRlc3RpbmF0aW9uIHRvIHNvdXJjZTsgbmVpdGhlciB0aGUgbWludXRlcyBub3IgSSBzdGlwdWxh dGUgdGhhdCBhDQo+IGNvbnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byBpbnN0YW50aWF0 ZSB0aGlzIGZvcndhcmRpbmcuDQo+IA0KPiBBcyBhbiBhc2lkZSwgdGhlIGlzc3VlIG9mIHJldHVy biBwYXRoIGZvciB1bmlkaXJlY3Rpb25hbCBMU1BzIGNvdWxkIGJlDQo+IGNoYXJhdGVyaXplZCBh cyB0aGUgZWxlcGhhbnQgaW4gdGhlIHJvb20uICBJbiB0aGUgTVBMUyBUUCBPQU0gDQo+IEZyYW1l d29yaw0KPiBJLUQsIHVuaWNhc3QgTFNQcyBhcmUgb25seSBtZW50aW9uZWQgdGhyZWUgdGltZXMg YW5kIHJldHVybiANCj4gcGF0aHMgbm90IGF0DQo+IGFsbC4gDQo+IA0KPiBUaGFua3MsDQo+IA0K PiBKb2huDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBCVVNJIElU QUxPIFttYWlsdG86SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdF0gDQo+ID4gU2VudDogRnJp ZGF5LCBBcHJpbCAxNywgMjAwOSAxOjU5IEFNDQo+ID4gVG86IERyYWtlLCBKb2huIEU7IEFsZXhh bmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gPiBDYzogbXBscy10cEBpZXRmLm9y Zw0KPiA+IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCANCj4gPiBwYXRoIHJlcXVpcmVtZW50cw0KPiA+IA0KPiA+IEpvaG4sDQo+ID4gDQo+ ID4gSSBtaWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVtZW50IG9mIE1QTFMtVFAgYmVpbmcgY2Fw YWJsZSBvZiANCj4gPiBzZW5kaW5nIHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNlbnQgb24gdW5p LWRpcmVjdGlvbmFsIExTUHMuDQo+ID4gDQo+ID4gVGhpcyByZXF1aXJlbWVudCBkb2VzIG5vdCBi ZWxvbmcgdG8gdGhlIGZpcnN0IHNldCBvZiANCj4gPiByZXF1aXJlbWVudHMgSVRVLVQgaXMgZXhw ZWN0aW5nIHRvIGJlIG1ldCBieSBPY3RvYmVyLg0KPiA+IA0KPiA+IEhvd2V2ZXIsIEkgdGhpbmsg dGhpcyBpbiBhIHBvdGVudGlhbCBpbnRlcmVzdGluZyBhZGRpdGlvbmFsIA0KPiA+IHJlcXVpcmVt ZW50IHRvIGJlIHRha2VuIGludG8gYWNjb3VudCAoYXQgd29yc3QgaW4gYSANCj4gc3Vic2VxdWVu dCBwaGFzZSkuDQo+ID4gDQo+ID4gSSB0aGluayB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgbmVlZHMg dG8gYmUgZXZhbHVhdGVkIHZlcnN1cyANCj4gPiBvdGhlciBtb3JlIGltcG9ydGFudCByZXF1aXJl bWVudHMgKGUuZy4gdGhlIHBvc3NpYmlsaXR5IHRvIA0KPiA+IHdvcmsgdy9vIElQIGZvcndhcmRp bmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8gY29udGludWUgdG8gDQo+ID4gbW9uaXRvciB0aGUg ZGF0YSBwbGFuZSBhbHNvIGluIGNhc2Ugb2YgZmFpbHVyZXMgYWZmZWN0aW5nIHRoZSANCj4gPiBj b250cm9sIG9yIG1hbmFnZW1lbnQgcGxhbmUpLg0KPiA+IA0KPiA+IEkgYW0gb3BlbiB0byBkaXNj dXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdodCB0aW1lIA0KPiA+IGJlY2F1c2Ug SSB3aXNoIHRvIGF2b2lkIGRlbGF5aW5nIHRoZSBmaXJzdCBwaGFzZSBvZiB0aGUgDQo+ID4gZGVz aWduIHNvbHV0aW9uLg0KPiA+IA0KPiA+IFRoYW5rcywgSXRhbG8NCj4gPiANCj4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmcNCj4gPiA+IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RHJha2UsIEpvaG4gRQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDg6MDAg UE0NCj4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzDQo+ID4g PiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gPiByZXF1aXJlbWVudHMN Cj4gPiA+IA0KPiA+ID4gQXQgdGhlIG1lZXRpbmcgbGFzdCBmYWxsIGF0IEp1bmlwZXIgaW4gTWFz c2FjaHVzZXR0cywgSSANCj4gPiB0aGluayBpdCB3YXMgDQo+ID4gPiBhZ3JlZWQgdGhhdCBhbiBN UExTIFRQIG5ldHdvcmsgbmVlZHMgdG8gaGF2ZSBhIGZvcndhcmRpbmcgDQo+ID4gY2FwYWJpbGl0 eSANCj4gPiA+IGZvciBtYW5hZ2VtZW50LCBjb250cm9sLCBhbmQgT0FNIHBhY2tldHMgKGUuZy4s IHNlbmRpbmcgDQo+ID4gcmVwbGllcyB0byBPQU0gDQo+ID4gPiByZXF1ZXN0cyBzZW50IG9uIHVu aS1kaXJlY3Rpb25hbCBMU1BzKSBldmVuIGlmIGl0IGRvZXMgbm90IA0KPiA+IGhhdmUgYW4gSVAg DQo+ID4gPiBmb3J3YXJkaW5nIGRhdGEgcGxhbmUuDQo+ID4gPiANCj4gPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4g PiA+IFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQo+ID4gPiA+IFNl bnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA5OjU3IEFNDQo+ID4gPiA+IFRvOiBNYWFydGVu IFZpc3NlcnMNCj4gPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDog UmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiANCj4gPiA+ID4gTWFhcnRlbiwNCj4gPiA+ID4g SXQgc2VlbXMgdGhhdCB5b3UndmUganVzdCAoaW1wbGljaXRseSBhbmQsIHByb2JhYmx5LA0KPiA+ ID4gPiBpbmFkdmVydGVudGx5KSBzdGF0ZWQgdGhlIGZvbGxvd2luZzoNCj4gPiA+ID4gDQo+ID4g PiA+ICAgICAgICAgICAgICAgICAgTVBMUy1UUCBPQU0gd2lsbCBub3QgZXZlciBzdXBwb3J0IE1J UCANCj4gbG9vcGJhY2sgZnVuY3Rpb24gDQo+ID4gKGFuZCBmYXVsdCANCj4gPiA+ID4gbG9jYWxp emF0aW9uIHdoaWNoIHJlcXVpcmVzIHRoaXMgZnVuY3Rpb24gKSBmb3IgDQo+ID4gdW5pZGlyZWN0 aW9uYWwgUDJNUCANCj4gPiA+ID4gYW5kIFAyUCBwYXRocy4NCj4gPiA+ID4gDQo+ID4gPiA+IElm IHRoaXMgc3RhdGVtZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8gYW5kIEZXSVcpIA0KPiByYWlz ZXMgYSB2YWxpZCANCj4gPiA+ID4gcXVlc3Rpb246DQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgICAg ICAgICAgICAgIElzIE1QTFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIA0KPiB0aGVz ZSB0eXBlcyBvZiB0cmFuc3BvcnQgDQo+ID4gPiA+IHBhdGhzPw0KPiA+ID4gPiANCj4gPiA+ID4g Rm9yIHRoZSByZWZlcmVuY2UsIElQL01QTFMgcHJvdmlkZXMgdGhpcyBraW5kIG9mIA0KPiA+IGZ1 bmN0aW9uYWxpdHkgdG9kYXkgDQo+ID4gPiA+IGZvciAodW5pZGlyZWN0aW9uYWwgLSBidXQgaXQg ZG9lcyBub3Qga25vdyBhbnkgb3RoZXIgDQo+ID4gdHlwZSkgUDJQIExTUHMgDQo+ID4gPiA+IGFz IGRlc2NyaWJlZCBpbiBSRkMgNDM3OS4gQW5kIGl0cyBleHRlbnNpb24gdG8gUDJNUCBMU1BzIHNl ZW1zIA0KPiA+ID4gPiBlYXN5Li4uDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4g PiA+IFJlZ2FyZHMsDQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgIFNhc2hhDQo+ID4gPiA+IA0KPiA+ ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmddIA0KPiA+IE9uIEJlaGFsZiANCj4gPiA+ID4gT2YgTWFhcnRlbiBW aXNzZXJzIFttYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbV0NCj4gPiA+ID4gU2VudDogVGh1cnNk YXksIEFwcmlsIDE2LCAyMDA5IDM6MjQgUE0NCj4gPiA+ID4gVG86ICdBZHJpYW4gRmFycmVsJw0K PiA+ID4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCj4gPiA+ID4gcmVx dWlyZW1lbnRzDQo+ID4gPiA+IA0KPiA+ID4gPiBBZHJpYW4sDQo+ID4gPiA+IA0KPiA+ID4gPiA+ PiA8cXVvdGU+DQo+ID4gPiA+ID4+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVk aW5nIE1FUHMsIE1JUHMgYW5kDQo+ID4gPiA+IG90aGVyIGludGVybmFsDQo+ID4gPiA+ID4+ICAg ICAgIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQNCj4gPiA+ID4gYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQNCj4gPiA+ID4gPj4gICAgICAgcGF0aCBhdCBlYWNoIChzdWIt KWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmcNCj4gPiA+ID4gPj4gICAgICAgcmVs YXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQNCj4gPiA+ID4gZGlyZWN0 aW9ucyBvZiB0aGF0DQo+ID4gPiA+ID4+ICAgICAgIHRyYW5zcG9ydCBwYXRoLg0KPiA+ID4gPiA+ PiA8ZW5kIHF1b3RlPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlcmUgaXMgbm8gd2F5IHRoaXMg aXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBUaGF0DQo+ID4gPiBpcywgdGhlcmUgaXMNCj4g PiA+ID4gPiAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBw b2ludCBvZg0KPiA+ID4gdmlldyB0aGF0DQo+ID4gPiA+ID4gcmVzdWx0cyBmcm9tIGFkaGVyaW5n IHRvIHRoaXMgcmVxdWlyZW1lbnQuDQo+ID4gPiA+IA0KPiA+ID4gPiBZb3VyIHVuZGVyc3RhbmRp bmcgaXMgbm90IGNvcnJlY3QuIEl0IGlzIHZlcnkgbXVjaCANCj4gb2JzZXJ2YWJsZSBpZiANCj4g PiA+ID4gdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZiB2 aWV3Lg0KPiA+ID4gPiBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBMb29w YmFjayB3aGVuIHRoZXJlIGlzIGEgDQo+ID4gPiA+IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoLiBUaGUgTVBMUy1UUCBMQk0gcGFja2V0IA0KPiA+ID4gPiByZWNlaXZlZCBh dCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5lZCAoYXMgTEJSDQo+ID4gPiA+IHBhY2tldCkgdG8g dGhlIG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhlIG90aGVyIA0KPiA+IGRpcmVjdGlv biBvZiANCj4gPiA+ID4gdGhlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo LiBUaGlzIG90aGVyIA0KPiBkaXJlY3Rpb24gDQo+ID4gPiA+IHdvdWxkIG5vdCBiZSBhdmFpbGFi bGUgaW4gYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCANCj4gPiA+ID4gcGF0 aC4uLiBhbmQgdGh1cyB0aGUgbG9vcGJhY2sgdGVzdA0KPiA+ID4gd291bGQgZmFpbC4NCj4gPiA+ ID4gDQo+ID4gPiA+IFNpbWlsYXJseSwgd2hlbiB3ZSBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRv IG1vbml0b3IgYSANCj4gPiBzZWdtZW50LCB0aGVuIA0KPiA+ID4gPiB0aGlzIGlzIHBvc3NpYmxl IGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoIA0KPiBidXQgbm90IGluIGEgDQo+ ID4gPiA+IGFzc29jaWF0ZWQgYmlkaXIgdHJhbnNwb3J0IHBhdGguIEluIHRoZSBmaXJzdCBjYXNl IHRoZSBUQ00gTUVQIA0KPiA+ID4gPiBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zIGFyZSBjby1s b2NhdGVkIGFuZCBjYW4gDQo+IGV4Y2hhbmdlIHdoYXQgaXMgDQo+ID4gPiA+IGNhbGxlZCAicmVt b3RlIGluZm9ybWF0aW9uIiB3aGljaCBpcyBuZWNlc3NhcnkgZm9yIHBlcmZvcm1hbmNlIA0KPiA+ ID4gPiBtb25pdG9yaW5nLg0KPiA+ID4gPiBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBNRVAg U291cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucyANCj4gPiBhcmUgaW4gZS5nLiANCj4gPiA+ID4gZGlm ZmVyZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIGFuZCBUQ00gd291bGQgbm90IGJlIGFibGUgDQo+ ID4gdG8gcHJvdmlkZSANCj4gPiA+ID4gcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4NCj4gPiA+ID4g DQo+ID4gPiA+ID4gVGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRp bmcgTUVQcywNCj4gPiA+IE1JUHMgYW5kIG90aGVyDQo+ID4gPiA+IGludGVybmFsDQo+ID4gPiA+ ID4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMg bm90DQo+ID4gPiA+IGFkZCB0byAiVGhlDQo+ID4gPiA+ID4gaW50ZXJtZWRpYXRlIG5vZGVzLiIN Cj4gPiA+ID4gDQo+ID4gPiA+IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gVGhp cyB0ZXh0IG11c3Qgbm90IGJlIA0KPiA+IGRlbGV0ZWQgYXQgDQo+ID4gPiA+IGFsbC4NCj4gPiA+ ID4gDQo+ID4gPiA+ID4gQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVy c2lzdGVudA0KPiA+ID4gaW5zaXN0ZW5jZSBvbiB0aGUNCj4gPiA+ID4gaW5jbHVzaW9uDQo+ID4g PiA+ID4gb2YgIlRhbmRlbSBDb25uZWN0aW9uLiIgVGhlIGRlZmluaXRpb24gd2l0aGluIHRoZSBJ VFUtVCBvZg0KPiA+ID4gPiB0aGlzIHRlcm0NCj4gPiA+ID4gPiBpcw0KPiA+ID4gPiBwb29ybHkN Cj4gPiA+ID4gPiBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1vbml0b3Jpbmcgb2YgYSBw YXRoIHRoYXQgaXMNCj4gPiA+ID4gcGFyYWxsZWwgKGkuZS4NCj4gPiA+ID4gdGFuZGVtKQ0KPiA+ ID4gPiA+IHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24g b2YgVEMNCj4gPiA+ID4gc2VlbXMgdG8gYmUgYXQNCj4gPiA+ID4gdmFyaWFuY2UsDQo+ID4gPiA+ ID4gYW5kIHdvdWxkIGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQo+ID4gPiA+ IA0KPiA+ID4gPiBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRhdGlvbiBv ZiB0YW5kZW0gDQo+ID4gY29ubmVjdGlvbiBpcyANCj4gPiA+ID4gZGVzY3JpYmVkIGluIElUVS1U IHJlY29tbWVuZGF0aW9ucy4gSS5lLiAiZnJvbSB0aGUgDQo+ID4gbW9uaXRvcmluZyBvZiBhIA0K PiA+ID4gPiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBw YXRoIGJlaW5nIA0KPiA+ID4gPiBtb25pdG9yZWQuIj8NCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXJl IGlzIGEgIm5ldHdvcmsgY29ubmVjdGlvbiIgYW5kIHRoaXMgbmV0d29yayANCj4gPiBjb25uZWN0 aW9uIGlzIGEgc2V0IA0KPiA+ID4gPiBvZiBpbnRlcmNvbm5lY3RlZCAibGluayBjb25uZWN0aW9u cyIgYW5kICJtYXRyaXggDQo+IGNvbm5lY3Rpb25zIi4gQSANCj4gPiA+ID4gc3Vic2V0IG9mIHRo b3NlIGludGVyY29ubmVjdGVkIGxpbmsgY29ubmVjdGlvbnMgYW5kIG1hdHJpeCANCj4gPiA+ID4g Y29ubmVjdGlvbnMgY2FuIGJlIG1vbml0b3JlZCBhbmQgaXMgdGhlbiByZWZlcnJlZCB0byBhcyAN Cj4gYSAidGFuZGVtIA0KPiA+ID4gPiBjb25uZWN0aW9uIi4gVGhlcmUgaXMgbm8gInBhdGggdGhh dCBpcyBwYXJhbGxlbCB0byB0aGUgDQo+ID4gZGF0YSBwYXRoIi4gDQo+ID4gPiA+IFRoZXJlIGlz IG9ubHkgYWRkaXRpb25hbCBPQU0gaW5zZXJ0ZWQgaW5zaWRlIHRoZSBkYXRhIA0KPiBwYXRoIGJ5 IHRoZSANCj4gPiA+ID4gVENNIE1FUF9TbyBmdW5jdGlvbiBhbmQgdGhpcyBPQU0gaXMgZXh0cmFj dGVkIGZyb20gdGhlIA0KPiA+IGRhdGEgcGF0aCBieSANCj4gPiA+ID4gdGhlIFRDTSBNRVBfU2sg ZnVuY3Rpb24uDQo+ID4gPiA+IA0KPiA+ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiBNYWFydGVuDQo+ ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQo+ID4gPiA+IFttYWlsdG86bXBs cy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiA+ID4g PiBTZW50OiBkb25kZXJkYWcgMTYgYXByaWwgMjAwOSAxMTo1OQ0KPiA+ID4gPiBUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW47IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tDQo+ID4gPiA+IENj OiBCVVNJIElUQUxPOyBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBs cy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KPiA+ID4gPiBy ZXF1aXJlbWVudHMNCj4gPiA+ID4gDQo+ID4gPiA+IEhpIFNhc2hhLA0KPiA+ID4gPiANCj4gPiA+ ID4gPiBVbmZvcnR1bmF0ZWx5IEkgY2Fubm90IGZ1bGx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1l bnQ6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA8cXVvdGU+DQo+ID4gPiA+ID4gICAgIEZyb20gdGhl IHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZA0KPiA+ID4gYmlkaXJlY3Rpb25h bCBMU1BzDQo+ID4gPiA+ID4gICAgIGFyZSBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgTFNQcy4NCj4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gVGhpcyBzdGF0ZW1lbnQgd291bGQgYmUgb2J2aW91c2x5IGNvcnJlY3QsIHdlcmUgaXQg bm90IGZvcg0KPiA+ID4gPiBSZXF1aXJlbWVudA0KPiA+ID4gPiA+IDM0IGluIHRoZSBsYXRlc3Qg TVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQNCj4gPiA+ID4gDQo+ID4gPiA+IE9LLiBHb3QgaXQu DQo+ID4gPiA+IA0KPiA+ID4gPiBCdXQgd2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBs YW5lIHJlcXVpcmVtZW50cyBzZWN0aW9uPw0KPiA+ID4gPiANCj4gPiA+ID4gSW4gZmFjdCwgd2hh dCBpcyB0aGlzIHJlcXVpcmVtZW50IGFjdHVhbGx5IHNheWluZz8NCj4gPiA+ID4gDQo+ID4gPiA+ ID4gPHF1b3RlPg0KPiA+ID4gPiA+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVk aW5nIE1FUHMsIE1JUHMgYW5kDQo+ID4gPiBvdGhlciBpbnRlcm5hbA0KPiA+ID4gPiA+ICAgICAg IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQNCj4gPiA+ID4gYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQNCj4gPiA+ID4gPiAgICAgICBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5 ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KPiA+ID4gPiA+ICAgICAgIHJlbGF0aW9u c2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkDQo+ID4gPiA+IGRpcmVjdGlvbnMg b2YgdGhhdA0KPiA+ID4gPiA+ICAgICAgIHRyYW5zcG9ydCBwYXRoLg0KPiA+ID4gPiA+IDxlbmQg cXVvdGU+DQo+ID4gPiA+IA0KPiA+ID4gPiBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0 aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQgDQo+ID4gaXMsIHRoZXJlIGlzDQo+ID4gPiA+ICpub3Ro aW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIA0KPiA+ IHZpZXcgdGhhdCANCj4gPiA+ID4gcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWly ZW1lbnQuDQo+ID4gPiA+IA0KPiA+ID4gPiBUaGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0 aGF0IHRoaXMgcmVxdWlyZW1lbnQgaXMgbWV0IGJ5IA0KPiA+ID4gPiBjb25maWd1cmluZyBzb21l IGRhdGEgcGxhbmUgZGF0YWJhc2UgY29tcG9uZW50IHRocm91Z2ggdGhlIA0KPiA+ID4gPiBtYW5h Z2VtZW50IHBsYW5lLiBUaGUgZGF0YWJhc2UgY29tcG9uZW50IGlzIG5vdCB1c2VkIA0KPiBmb3Ig YW55dGhpbmcgDQo+ID4gPiA+IGV4Y2VwdCB0byBzYXRpc2Z5IHRoaXMgcmVxdWlyZW1lbnQgZm9y ICJhd2FyZW5lc3MiLg0KPiA+ID4gPiANCj4gPiA+ID4gQmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0 byByZXdyaXRlIHRoaXMgcmVxdWlyZW1lbnQgaW4gdGVybXMgb2YgDQo+ID4gPiA+IGJlaGF2aW9y Pw0KPiA+ID4gPiANCj4gPiA+ID4gPiBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlz IHRoZSBPTkxZIGl0ZW0gaW4gdGhlDQo+ID4gPiA+IGxpc3QgdGhhdCBpcw0KPiA+ID4gPiA+IHNw ZWNpZmljIGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhlIHBhaXJpbmcNCj4g PiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4gYXQgZW5kIHBvaW50cyBmb3IgY28tcm91dGVk IGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCj4gPiA+IHBhdGhzIGFyZQ0KPiA+ID4gPiA+ IGV4YWN0bHkgdGhlIHNhbWUgZXZlbiBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50DQo+ ID4gPiBpdGVtcyBpbiB0aGUNCj4gPiA+ID4gPiByZXF1aXJlbWVudHMnIGxpc3QpLg0KPiA+ID4g PiA+IEluIG90aGVyIHdvcmRzLCB3aXRob3V0IFJlcXVpcmVtZW50IDM0IHRoZSBub3Rpb24gb2Yg DQo+IGNvLXJvdXRlZCANCj4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBhdGhzIHdvdWxkIGJlIHZv aWQgb2YgYW55IGRhdGEgcGxhbmUgY29udGVudC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBz b21ld2hhdCB2YWd1ZSBzY29wZSBvZiB0aGlzIHJlcXVpcmVtZW50ICgib3RoZXIgaW50ZXJuYWwg DQo+ID4gPiA+ID4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlIikgY3JlYXRlcyBhIHN1c3BpY2lv biB0aGF0IEhXDQo+ID4gPiA+IHN1cHBvcnQgb2YgdGhlDQo+ID4gPiA+ID4gcGFpcmluZyBhd2Fy ZW5lc3MgbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRvIGNvbXBseSB3aXRoIGl0Lg0KPiA+ID4g PiANCj4gPiA+ID4gVGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRp bmcgTUVQcywgDQo+ID4gTUlQcyBhbmQgb3RoZXIgDQo+ID4gPiA+IGludGVybmFsIGZ1bmN0aW9u cyBhcyBhcHByb3ByaWF0ZSkiIHNob3VsZCBiZSBkZWxldGVkLiBJdCANCj4gPiBkb2VzIG5vdCAN Cj4gPiA+ID4gYWRkIHRvICJUaGUgaW50ZXJtZWRpYXRlIG5vZGVzLiINCj4gPiA+ID4gDQo+ID4g PiA+ID4gVGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFmdCBpbmNyZWFzZXMgdGhpcyBzdXNw aWNpb246DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA8cXVvdGU+DQo+ID4gPiA+ID4gICBUYW5kZW0g Q29ubmVjdGlvbjogQSB0YW5kZW0gY29ubmVjdGlvbiBpcyBhbiANCj4gPiBhcmJpdHJhcnkgcGFy dCBvZiBhDQo+ID4gPiA+ID4gICB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQg KHZpYSBPQU0pDQo+ID4gPiA+IGluZGVwZW5kZW50bHkgZnJvbSB0aGUNCj4gPiA+ID4gPiAgIGVu ZC10by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gIEl0IG1heSBiZSBhIG1vbml0b3JlZCANCj4gPiBz ZWdtZW50IG9yIGENCj4gPiA+ID4gPiAgIG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBv ZiBhIHRyYW5zcG9ydCBwYXRoLiANCj4gPiBUaGUgdGFuZGVtDQo+ID4gPiA+ID4gICBjb25uZWN0 aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRpbmcgZW5naW5lKHMpIG9mDQo+ID4gPiA+ IHRoZSBub2RlKHMpDQo+ID4gPiA+ID4gICBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBv ciBjb25jYXRlbmF0ZWQgc2VnbWVudC4NCj4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPiAN Cj4gPiA+ID4gQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVu dCANCj4gPiBpbnNpc3RlbmNlIG9uIHRoZSANCj4gPiA+ID4gaW5jbHVzaW9uIG9mICJUYW5kZW0g Q29ubmVjdGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbiANCj4gPiB0aGUgSVRVLVQgb2YgDQo+ ID4gPiA+IHRoaXMgdGVybSBpcyBwb29ybHkgc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZSAN Cj4gbW9uaXRvcmluZyBvZiBhIA0KPiA+ID4gPiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4g dGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIA0KPiA+ID4gPiBtb25pdG9yZWQuIFRoaXMg ZGVmaW5pdGlvbiBvZiBUQyBzZWVtcyB0byBiZSBhdCB2YXJpYW5jZSwgDQo+ID4gYW5kIHdvdWxk IA0KPiA+ID4gPiBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KPiA+ID4gPiAN Cj4gPiA+ID4gPiBEb2Vzbid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgc291bmQgbGlrZSBoYXJkd2Fy ZSB0byB5b3U/DQo+ID4gPiA+IA0KPiA+ID4gPiBZZXMsIGJ1dCBzbyB3aGF0Pw0KPiA+ID4gPiAN Cj4gPiA+ID4gPiBJTUhPIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IG5laXRoZXIgdGhlIE1QTFMt VFANCj4gPiA+IFJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ID4gPiA+IG5vciB0aGUgTVBMUy1UUCBP QU0gcmVxdWlyZW1lbnRzIG9uZQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+IA0KPiA+IA0K PiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRw LW9hbS1yZXF1aXJlbWVuDQo+ID4gPiA+ID4gdHMtMDEudHh0KSBjb250YWluIGFueSByZXF1aXJl bWVudHMgZGVhbGluZyB3aXRoIHRhbmRlbQ0KPiA+ID4gY29ubmVjdGlvbnMuDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1Q TFMtVFAgT0FNIA0KPiA+IEZyYW1ld29yayANCj4gPiA+ID4gPiBkcmFmdA0KPiA+ID4gPiAoaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1m cg0KPiA+ID4gPiBhbWV3b3JrLTAwLnR4dA0KPiA+ID4gPiApLg0KPiA+ID4gPiANCj4gPiA+ID4g UmlnaHQuDQo+ID4gPiA+IExldCdzIGp1c3QgZ2V0IHJpZCBvZiBhbiB1bm5lY2Vzc2FyeSB0ZXJt IGFuZCBicmluZyBhbGwgDQo+IHRoZSBJLURzIA0KPiA+ID4gPiBpbnRvIGxpbmUuDQo+ID4gPiA+ IA0KPiA+ID4gPiA+IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21lIGNsYXJpdHkg cmVnYXJkaW5nDQo+ID4gPiBjby1yb3V0ZWQgdnMuDQo+ID4gPiA+ID4gYXNzb2NpYXRlZA0KPiA+ ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMgaXMgc3RpbGwgcmVxdWlyZWQuIE9uZSB3YXkgdG8g cHJvdmlkZQ0KPiA+ID4gPiB0aGF0IGNvdWxkDQo+ID4gPiA+ID4gYmUgYnkgZXhwbGljaXRseSBs aW1pdGluZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYw0KPiA+ID4gZnVuY3Rpb25hbGl0eS4N Cj4gPiA+ID4gDQo+ID4gPiA+IEFncmVlZC4NCj4gPiA+ID4gDQo+ID4gPiA+IEFkcmlhbg0KPiA+ ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBGcm9tOiBBZHJpYW4gRmFycmVs IFthZHJpYW5Ab2xkZG9nLmNvLnVrXQ0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYs IDIwMDkgMTI6MTMgQU0NCj4gPiA+ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVy Z2VyOyBCVVNJIElUQUxPDQo+ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IFN1 YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBw YXRoIA0KPiA+ID4gPiByZXF1aXJlbWVudHMNCj4gPiA+ID4gDQo+ID4gPiA+IEhpIFNhc2hhLA0K PiA+ID4gPiANCj4gPiA+ID4gTm90IHJlYWxseSBzdXJlIHdoZXRoZXIgeW91IGFyZSBtaXNyZXBy ZXNlbnRpbmcgYW55b25lLCBidXQuLi4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gMS4gTXkgcmVhZGlu ZyBvZiAgb25lIG9mIEJlbidzICBtZXNzYWdlcyBpcyB0aGF0IGFzc29jaWF0ZWQgDQo+ID4gPiA+ ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgdGhlIG9ubHkgdHlwZXMgb2YgcGF0aHMgdGhhdCBj YW4gYmUNCj4gPiA+ID4gY3JlYXRlZCBpbg0KPiA+ID4gPiA+IHRoZSBleGlzdGluZyBuZXR3b3Jr czsgInRydWUiIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzDQo+ID4gPiA+IHdpbGwgaGF2 ZQ0KPiA+ID4gPiA+IHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21l cyBhdmFpbGFibGUuDQo+ID4gPiA+IA0KPiA+ID4gPiBUaGlzIGlzIGNsZWFybHkgbm9uc2Vuc2Uh DQo+ID4gPiA+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZCAN Cj4gPiBiaWRpcmVjdGlvbmFsIExTUHMgYXJlIA0KPiA+ID4gPiBhIHNwZWNpYWwgY2FzZSBvZiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4gPiA+ID4gDQo+ID4gPiA+IElmIHlvdSBj YW4gc2V0IHVwIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzIChlLmcuIHVzaW5nIHRoZSANCj4gPiBt YW5hZ2VtZW50IA0KPiA+ID4gPiBwbGFuZSkgeW91IGNhbiBzdXJlbHkgc2V0IHVwIGEgY28tcm91 dGVkDQo+ID4gPiBiaWRpcmVjdGlvbmFsIExTUC4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXJlIGFy ZSBzaGlwcGluZyBzb2x1dGlvbnMgdGhhdCBhY2hpZXZlIGNvLXJvdXRlZCANCj4gYmlkaXJlY3Rp b25hbCANCj4gPiA+ID4gTFNQcyB1c2luZyB0aGUgY29udHJvbCBwbGFuZS4gVGhlc2UgZWl0aGVy IHVzZSB0aGUgR01QTFMgDQo+ID4gKHdoaWNoIGlzIA0KPiA+ID4gPiBjbGVhbmVyKSBvciBub24t c3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpcyANCj4gPiBtZXNzeSBidXQg DQo+ID4gPiA+IGZ1bmN0aW9uYWwpLg0KPiA+ID4gPiANCj4gPiA+ID4gQnV0IChvZiBjb3Vyc2Up IHRoZSBtYW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wgcGxhbmUgDQo+ID4gc29sdXRpb25zIGhh dmUgDQo+ID4gPiA+IG5vdGhpbmcgdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50 IGFzIHRoZXkgDQo+IGFyZSBzb2Z0d2FyZSANCj4gPiA+ID4gc29sdXRpb25zLg0KPiA+ID4gPiAN Cj4gPiA+ID4gPiAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMgaXMgdGhh dCB0aGUgYWN0dWFsDQo+ID4gPiA+IGRyaXZlciBmb3INCj4gPiA+ID4gPiBjby1yb3V0ZWQgYmlk aXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIA0KPiA+ID4g PiA+IHRyYW5zcG9ydCBuZXR3b3JrcyByYXRoZXIgdGhhbiBhbnkgc3BlY2lmaWMgYmVuZWZpdC4N Cj4gPiA+ID4gDQo+ID4gPiA+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1Q TFMtVFAgcmVxdWlyZW1lbnRzPw0KPiA+ID4gPiBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEg YmFkIHRoaW5nLg0KPiA+ID4gPiANCj4gPiA+ID4gQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMtVFAg aXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsgDQo+ID4gdGhlIGxvb2ssIA0KPiA+ID4gPiBm ZWVsLCBhbmQgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSAibGVnYWN5Ig0KPiA+ID4g PiB0cmFuc3BvcnQgbmV0d29yay4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gQmFzZWQgb24gdGhlc2Ug b2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRoYXQ6DQo+ID4gPiA+ID4gKiBhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlLCBhdCBsZWFzdCBmb3IgdGhlIHRpbWUNCj4gPiA+ ID4gPiAgICBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2YgYmlkaXJlY3Rpb25hbCBw YXRocyBpbg0KPiA+ID4gPiA+ICAgIE1QTFMtVFANCj4gPiA+ID4gDQo+ID4gPiA+IEkgdGhpbmsg dGhhdCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5kIA0KPiA+IGdp dmVuIHRoYXQgDQo+ID4gPiA+IG90aGVyIHVwZ3JhZGVzIHRvIGV4aXN0aW5nIE1QTFMgc29sdXRp b25zIHdpbGwgYmUgDQo+IG5lZWRlZCB0byByZWFjaCANCj4gPiA+ID4gdGhlIGZ1bGwgZnVuY3Rp b24gbGV2ZWwgb2YgTVBMUy1UUC4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gKiB0aGV5IGhhZCBhIGdv b2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBlIG9mIA0KPiA+IGJpZGlyZWN0aW9uYWwN Cj4gPiA+ID4gPiAgIHBhdGhzIGluICByZWFsIGRlcGxveW1lbnRzLg0KPiA+ID4gPiANCj4gPiA+ ID4gSSBkb24ndCBzZWUgd2hhdCB0aGF0IGZvbGxvd3MgZnJvbS4NCj4gPiA+ID4gDQo+ID4gPiA+ IENoZWVycywNCj4gPiA+ID4gQWRyaWFuDQo+ID4gPiA+IA0KPiA+ID4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBtcGxzLXRwIG1haWxp bmcgbGlzdA0KPiA+ID4gPiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiA+ID4gPiANCj4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gbXBscy10 cCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPiA+ID4gDQo+ID4gPiA+ IA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+ID4gPiBtcGxzLXRwQGlldGYub3JnDQo+ID4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPiA+IA0K PiA+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiBtcGxzLXRwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiANCj4gDQo+IA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiANCj4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiANCj4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIA0KPiBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3Jl Y3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIA0KPiB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVz IHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCANCj4gYW5kIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgDQo+IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIA0KPiBp biBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkg DQo+IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRp dmlkdWFsIHNlbmRlci4NCj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFIA0KPiBBbnRpLVNwYW0gc3lzdGVtLg0KPiANCg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90 IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00045BB44825759F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBKb2huOjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IG1heWJlIEkgZG9uJ3Qg eW91ciBtZWFuaW5nLiBJTU8uDQppdCBpcyBuZWNlc3NhcnkgZm9yIHVuaWRpcmVjdGlvbmFsIHBh dGggdG8gaGF2ZSBhIHJldHVybiBwYXRoLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBsaXU8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7RHJha2UsIEpvaG4gRSZxdW90Ow0KJmx0 O0pvaG4uRS5EcmFrZTJAYm9laW5nLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTIwIDIwOjQ4PC9mb250Pg0KPHRkIHdpZHRoPTcz JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtsaXUuZ3VvbWFuQHp0ZS5j b20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7bXBscy10cEBpZXRmLm9yZyZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQp0 cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiBsaXUsPGJyPg0KPGJyPg0KUGxlYXNl IHJlLXJlYWQgbXkgZS1tYWlsLiAmbmJzcDtZb3UgYXJlIGFncmVlaW5nIHdpdGggbWUuPGJyPg0K PGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCkpvaG48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBsaXUuZ3VvbWFuQHp0ZS5jb20uY24gW21h aWx0bzpsaXUuZ3VvbWFuQHp0ZS5jb20uY25dIDxicj4NCiZndDsgU2VudDogU3VuZGF5LCBBcHJp bCAxOSwgMjAwOSA3OjAxIFBNPGJyPg0KJmd0OyBUbzogRHJha2UsIEpvaG4gRTxicj4NCiZndDsg Q2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCA8YnI+DQomZ3Q7IHBhdGggcmVxdWlyZW1l bnRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSm9obqO6PGJyPg0KJmd0OyAmbmJz cDtJIGRvbid0IGNvbXBsZXRlbHkgYWdyZWUgeW91ciBvcGluaW9ucy4gZm9yIHVuaWRpcmVjdGlv bmFsIDxicj4NCiZndDsgUDJQIGFuZCBQMk1QIHBhdGgsIGlmIHRoZXJlIGlzIG5vIHJldHVybiBw YXRoLCBob3cgY2FuIHNpbmsgPGJyPg0KJmd0OyBwb2ludHMgcmVwbHkgdG8gc291cmNlIHBvaW50 J3MgcmVxdWVzdCBwYWNrZXQ/IGlmIHRoZXJlIGFyZSA8YnI+DQomZ3Q7IHNvbWUgZmF1bHRzIGlu IHRoZSBiYWNrd2FyZCBzZWN0aW9ucyBvZiB0aGlzIHVuaWRpcmVjdGlvbmFsIDxicj4NCiZndDsg cGF0aCwgdGhlIHNpbmsgcG9pbnRzIHdpbGwgZGV0ZWN0cyB0aGUgZGVmZWN0cywgaWYgbm8gcmV0 dXJuIDxicj4NCiZndDsgcGF0aCwgaG93IGNhbiB0aGUgc2luayBwb2ludHMgbm90aWZ5IHRoZSBm YXVsdCBtZXNzYWdlIHRvIDxicj4NCiZndDsgc291cmNlIHBvaW50cy4gPGJyPg0KJmd0OyBhbmQg c28sIEkgdGhpbmsgaWYgdGhlcmUgaXMgbm8gcmV0dXJuIHBhdGgsIHdoYXQgaGFwcGVuZWQgdG8g PGJyPg0KJmd0OyB1bmlkaXJlY3Rpb25hbCBQMlAgYW5kIFAyTVAgPyA8YnI+DQomZ3Q7IEkgdGhp bmsgd2UgY29uc2lkZXIgdGhlIHJldHVybiBwYXRoLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgcmVn YXJkczxicj4NCiZndDsgbGl1IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgJnF1b3Q7RHJha2UsIEpvaG4gRSZxdW90OyAmbHQ7Sm9obi5FLkRyYWtlMkBib2Vpbmcu Y29tJmd0OyA8YnI+DQomZ3Q7ILeivP7IyzogJm5ic3A7bXBscy10cC1ib3VuY2VzQGlldGYub3Jn IDxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDA5LTA0LTE4IDAzOjAyIMrVvP7Iyzxicj4NCiZndDsg JnF1b3Q7QlVTSSBJVEFMTyZxdW90OyAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdCZn dDssICZxdW90O0FsZXhhbmRlcg0KPGJyPg0KJmd0OyBWYWluc2h0ZWluJnF1b3Q7ICZsdDtBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSZndDssICZxdW90O01hYXJ0ZW4NCjxicj4NCiZn dDsgVmlzc2VycyZxdW90OyAmbHQ7bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20mZ3Q7IDxicj4N CiZndDsgs63LzTxicj4NCiZndDsgbXBscy10cEBpZXRmLm9yZyA8YnI+DQomZ3Q7INb3zOI8YnI+ DQomZ3Q7IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcm9lY3Rpb25hbCB0cmFuc3BvcnQg cGF0aCByZXF1aXJlbWVudHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSXRhbG8sPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEFzIGRlc2NyaWJlZCBpbiB0aGUgTVBMUyBUUCBPQU0gUmVxdWlyZW1lbnRz IEktRCwgdmlydHVhbGx5IGFsbCBvZg0KdGhlPGJyPg0KJmd0OyBPQU0gZnVuY3Rpb25zIHJlcXVp cmUgYSByZXR1cm4gcGF0aCwgYW5kIGluIHRoZSBhYnNlbmNlIG9mIGEgPGJyPg0KJmd0OyByZXR1 cm4gcGF0aDxicj4NCiZndDsgdGhleSBhcmUgZGlzYWJsZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEFzIGRlc2NyaWJlZCBpbiBEYXZpZCBTaW5pY3JvcGUncyBtZWV0aW5nIG1pbnV0ZXM8YnI+DQom Z3Q7IChodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9hdHRhY2ht ZW50L3dpa2kvPGJyPg0KJmd0OyBtZWV0aW5nLW5vPGJyPg0KJmd0OyB0ZXMvMjAwODEwMTUubXBs cy1pbnRlcm9wLWR0LW5vdGVzLnppcCksIGlmIElQIGFkZHJlc3NpbmcgaXMgdXNlZCwNCmFuPGJy Pg0KJmd0OyBNUExTIFRQIG5ldHdvcmsgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBnZXR0aW5nIElQ IHBhY2tldHMgZnJvbTxicj4NCiZndDsgZGVzdGluYXRpb24gdG8gc291cmNlOyBuZWl0aGVyIHRo ZSBtaW51dGVzIG5vciBJIHN0aXB1bGF0ZSB0aGF0IGE8YnI+DQomZ3Q7IGNvbnRyb2wgcGxhbmUg bmVlZHMgdG8gYmUgdXNlZCB0byBpbnN0YW50aWF0ZSB0aGlzIGZvcndhcmRpbmcuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEFzIGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgcmV0dXJuIHBhdGggZm9yIHVu aWRpcmVjdGlvbmFsIExTUHMgY291bGQNCmJlPGJyPg0KJmd0OyBjaGFyYXRlcml6ZWQgYXMgdGhl IGVsZXBoYW50IGluIHRoZSByb29tLiAmbmJzcDtJbiB0aGUgTVBMUyBUUCBPQU0NCjxicj4NCiZn dDsgRnJhbWV3b3JrPGJyPg0KJmd0OyBJLUQsIHVuaWNhc3QgTFNQcyBhcmUgb25seSBtZW50aW9u ZWQgdGhyZWUgdGltZXMgYW5kIHJldHVybiA8YnI+DQomZ3Q7IHBhdGhzIG5vdCBhdDxicj4NCiZn dDsgYWxsLiAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgPGJy Pg0KJmd0OyBKb2huPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyAmZ3Q7IEZyb206IEJVU0kgSVRBTE8gW21haWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwt bHVjZW50Lml0XSA8YnI+DQomZ3Q7ICZndDsgU2VudDogRnJpZGF5LCBBcHJpbCAxNywgMjAwOSAx OjU5IEFNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBEcmFrZSwgSm9obiBFOyBBbGV4YW5kZXIgVmFpbnNo dGVpbjsgTWFhcnRlbiBWaXNzZXJzPGJyPg0KJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCA8YnI+DQomZ3Q7ICZndDsgcGF0aCByZXF1aXJlbWVudHM8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEpvaG4sPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBJIG1pZ2h0IGhhdmUgbWlzc2VkIHRoZSBhZ3JlZW1lbnQgb2YgTVBMUy1UUCBiZWluZyBj YXBhYmxlIG9mDQo8YnI+DQomZ3Q7ICZndDsgc2VuZGluZyByZXBsaWVzIHRvIE9BTSByZXF1ZXN0 cyBzZW50IG9uIHVuaS1kaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgVGhpcyByZXF1aXJlbWVudCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlIGZpcnN0IHNldCBv ZiA8YnI+DQomZ3Q7ICZndDsgcmVxdWlyZW1lbnRzIElUVS1UIGlzIGV4cGVjdGluZyB0byBiZSBt ZXQgYnkgT2N0b2Jlci48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhvd2V2ZXIsIEkg dGhpbmsgdGhpcyBpbiBhIHBvdGVudGlhbCBpbnRlcmVzdGluZyBhZGRpdGlvbmFsIDxicj4NCiZn dDsgJmd0OyByZXF1aXJlbWVudCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgKGF0IHdvcnN0IGlu IGEgPGJyPg0KJmd0OyBzdWJzZXF1ZW50IHBoYXNlKS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEkgdGhpbmsgdGhhdCB0aGlzIHJlcXVpcmVtZW50IG5lZWRzIHRvIGJlIGV2YWx1YXRl ZCB2ZXJzdXMgPGJyPg0KJmd0OyAmZ3Q7IG90aGVyIG1vcmUgaW1wb3J0YW50IHJlcXVpcmVtZW50 cyAoZS5nLiB0aGUgcG9zc2liaWxpdHkgdG8gPGJyPg0KJmd0OyAmZ3Q7IHdvcmsgdy9vIElQIGZv cndhcmRpbmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8gY29udGludWUgdG8gPGJyPg0KJmd0OyAm Z3Q7IG1vbml0b3IgdGhlIGRhdGEgcGxhbmUgYWxzbyBpbiBjYXNlIG9mIGZhaWx1cmVzIGFmZmVj dGluZyB0aGUNCjxicj4NCiZndDsgJmd0OyBjb250cm9sIG9yIG1hbmFnZW1lbnQgcGxhbmUpLjxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBhbSBvcGVuIHRvIGRpc2N1c3MgaXQgYnV0 IG5vdCBzdXJlIHRoaXMgaXMgdGhlIHJpZ2h0IHRpbWUgPGJyPg0KJmd0OyAmZ3Q7IGJlY2F1c2Ug SSB3aXNoIHRvIGF2b2lkIGRlbGF5aW5nIHRoZSBmaXJzdCBwaGFzZSBvZiB0aGUgPGJyPg0KJmd0 OyAmZ3Q7IGRlc2lnbiBzb2x1dGlvbi48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRo YW5rcywgSXRhbG88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyBGcm9tOiBtcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIERyYWtlLCBKb2huDQpFPGJyPg0KJmd0OyAmZ3Q7ICZndDsg U2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDg6MDAgUE08YnI+DQomZ3Q7ICZndDsgJmd0 OyBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vyczxicj4NCiZndDsgJmd0 OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDog UmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxi cj4NCiZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IEF0IHRoZSBtZWV0aW5nIGxhc3QgZmFsbCBhdCBKdW5pcGVyIGluIE1h c3NhY2h1c2V0dHMsIEkNCjxicj4NCiZndDsgJmd0OyB0aGluayBpdCB3YXMgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgYWdyZWVkIHRoYXQgYW4gTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGhhdmUgYSBm b3J3YXJkaW5nDQo8YnI+DQomZ3Q7ICZndDsgY2FwYWJpbGl0eSA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBmb3IgbWFuYWdlbWVudCwgY29udHJvbCwgYW5kIE9BTSBwYWNrZXRzIChlLmcuLCBzZW5kaW5n DQo8YnI+DQomZ3Q7ICZndDsgcmVwbGllcyB0byBPQU0gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVx dWVzdHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQcykgZXZlbiBpZiBpdCBkb2VzIG5vdA0K PGJyPg0KJmd0OyAmZ3Q7IGhhdmUgYW4gSVAgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZm9yd2FyZGlu ZyBkYXRhIHBsYW5lLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZy b206IEFsZXhhbmRlciBWYWluc2h0ZWluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgW21haWx0bzpBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA5OjU3IEFNPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBUbzogTWFhcnRlbiBWaXNzZXJzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYzogbXBs cy10cEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxz LXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE1hYXJ0ZW4sPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJ dCBzZWVtcyB0aGF0IHlvdSd2ZSBqdXN0IChpbXBsaWNpdGx5IGFuZCwgcHJvYmFibHksPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmFkdmVydGVudGx5KSBzdGF0ZWQgdGhlIGZvbGxvd2luZzo8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 TVBMUy1UUCBPQU0gd2lsbCBub3QgZXZlciBzdXBwb3J0IE1JUCA8YnI+DQomZ3Q7IGxvb3BiYWNr IGZ1bmN0aW9uIDxicj4NCiZndDsgJmd0OyAoYW5kIGZhdWx0IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgbG9jYWxpemF0aW9uIHdoaWNoIHJlcXVpcmVzIHRoaXMgZnVuY3Rpb24gKSBmb3IgPGJy Pg0KJmd0OyAmZ3Q7IHVuaWRpcmVjdGlvbmFsIFAyTVAgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBhbmQgUDJQIHBhdGhzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBJZiB0aGlzIHN0YXRlbWVudCBpcyBjb3JyZWN0LCB0aGlzIChJTUhPIGFuZCBG V0lXKQ0KPGJyPg0KJmd0OyByYWlzZXMgYSB2YWxpZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHF1ZXN0aW9uOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDtJcyBNUExTLVRQIGFuIGFwcHJvcHJpYXRlIHNvbHV0aW9uIGZvciA8YnI+DQom Z3Q7IHRoZXNlIHR5cGVzIG9mIHRyYW5zcG9ydCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBh dGhzPzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBG b3IgdGhlIHJlZmVyZW5jZSwgSVAvTVBMUyBwcm92aWRlcyB0aGlzIGtpbmQgb2YgPGJyPg0KJmd0 OyAmZ3Q7IGZ1bmN0aW9uYWxpdHkgdG9kYXkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBmb3Ig KHVuaWRpcmVjdGlvbmFsIC0gYnV0IGl0IGRvZXMgbm90IGtub3cgYW55IG90aGVyDQo8YnI+DQom Z3Q7ICZndDsgdHlwZSkgUDJQIExTUHMgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBh cyBkZXNjcmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0ZW5zaW9uIHRvIFAyTVANCkxTUHMg c2VlbXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBlYXN5Li4uPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw O1Nhc2hhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZ10NCjxicj4NCiZndDsgJmd0OyBPbiBCZWhhbGYgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBPZiBNYWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXTxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDM6MjQgUE08 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiAnQWRyaWFuIEZhcnJlbCc8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQNCnBhdGggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRyaWFuLDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbHQ7 cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1RoZSBpbnRlcm1lZGlhdGUgbm9kZXMNCihpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG90aGVyIGludGVybmFsPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMgYXMgYXBwcm9w cmlhdGUpDQpvZiBhIGNvLXJvdXRlZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rp b25hbCB0cmFuc3BvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHBhdGggYXQgZWFjaCAoc3ViLSlsYXllcg0KTVVTVCBiZSBhd2FyZSBvZiB0 aGUgcGFpcmluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkDQphbmQgdGhlIGJhY2t3YXJkPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCBwYXRoLjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmx0O2VuZCBxdW90ZSZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhl cmUgaXMgbm8gd2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50Lg0KVGhhdDxicj4N CiZndDsgJmd0OyAmZ3Q7IGlzLCB0aGVyZSBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveA0KcG9pbnQg b2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyB2aWV3IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFlvdXIgdW5kZXJzdGFu ZGluZyBpcyBub3QgY29ycmVjdC4gSXQgaXMgdmVyeSBtdWNoDQo8YnI+DQomZ3Q7IG9ic2VydmFi bGUgaWYgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBm cm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZpZXcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBU aGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBMb29wYmFjayB3aGVuDQp0aGVy ZSBpcyBhIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg dHJhbnNwb3J0IHBhdGguIFRoZSBNUExTLVRQDQpMQk0gcGFja2V0IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgcmVjZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUgcmV0dXJuZWQgKGFzIExCUjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcGFja2V0KSB0byB0aGUgb3JpZ2luYXRpbmcgTUVQIGZ1 bmN0aW9uIHZpYSB0aGUgb3RoZXINCjxicj4NCiZndDsgJmd0OyBkaXJlY3Rpb24gb2YgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0 IHBhdGguIFRoaXMgb3RoZXINCjxicj4NCiZndDsgZGlyZWN0aW9uIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgd291bGQgbm90IGJlIGF2YWlsYWJsZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwNCnRyYW5zcG9ydCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhdGguLi4gYW5kIHRo dXMgdGhlIGxvb3BiYWNrIHRlc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyB3b3VsZCBmYWlsLjxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTaW1pbGFybHks IHdoZW4gd2UgaGF2ZSB0byBhcHBseSBUQ00gTUVQcyB0byBtb25pdG9yDQphIDxicj4NCiZndDsg Jmd0OyBzZWdtZW50LCB0aGVuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyBpcyBwb3Nz aWJsZSBpbiBhIGNvLXJvdXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aA0KPGJyPg0KJmd0OyBidXQg bm90IGluIGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhc3NvY2lhdGVkIGJpZGlyIHRyYW5z cG9ydCBwYXRoLiBJbiB0aGUgZmlyc3QgY2FzZQ0KdGhlIFRDTSBNRVAgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zIGFyZSBjby1sb2NhdGVkIGFuZCBj YW4gPGJyPg0KJmd0OyBleGNoYW5nZSB3aGF0IGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Y2FsbGVkICZxdW90O3JlbW90ZSBpbmZvcm1hdGlvbiZxdW90OyB3aGljaCBpcyBuZWNlc3NhcnkN CmZvciBwZXJmb3JtYW5jZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JpbmcuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBNRVAgU291 cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucw0KPGJyPg0KJmd0OyAmZ3Q7IGFyZSBpbiBlLmcuIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgZGlmZmVyZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIGFuZCBU Q00gd291bGQgbm90IGJlDQphYmxlIDxicj4NCiZndDsgJmd0OyB0byBwcm92aWRlIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgcGVyZm9ybWFuY2UgbW9uaXRvcmluZy48YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZW50aXJldHkgb2Yg dGhlIGJyYWNrZXR0ZWQgdGV4dCAmcXVvdDsoaW5jbHVkaW5nDQpNRVBzLDxicj4NCiZndDsgJmd0 OyAmZ3Q7IE1JUHMgYW5kIG90aGVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRlcm5hbDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpJnF1 b3Q7IHNob3VsZCBiZSBkZWxldGVkLg0KSXQgZG9lcyBub3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IGFkZCB0byAmcXVvdDtUaGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaW50ZXJt ZWRpYXRlIG5vZGVzLiZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIFRoaXMgdGV4 dCBtdXN0IG5vdA0KYmUgPGJyPg0KJmd0OyAmZ3Q7IGRlbGV0ZWQgYXQgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBhbGwuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVy c2lzdGVudDxicj4NCiZndDsgJmd0OyAmZ3Q7IGluc2lzdGVuY2Ugb24gdGhlPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBpbmNsdXNpb248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgb2Yg JnF1b3Q7VGFuZGVtIENvbm5lY3Rpb24uJnF1b3Q7IFRoZSBkZWZpbml0aW9uDQp3aXRoaW4gdGhl IElUVS1UIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIHRlcm08YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBvb3JseTxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1v bml0b3Jpbmcgb2YgYSBwYXRoDQp0aGF0IGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXJh bGxlbCAoaS5lLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGFuZGVtKTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhpcyBk ZWZpbml0aW9uDQpvZiBUQzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2VlbXMgdG8gYmUgYXQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHZhcmlhbmNlLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBhbmQgd291bGQgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC48YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBkb24ndCB1 bmRlcnN0YW5kIHdoZXJlIHlvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGFuZGVtDQo8YnI+DQomZ3Q7 ICZndDsgY29ubmVjdGlvbiBpcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRlc2NyaWJlZCBp biBJVFUtVCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gJnF1b3Q7ZnJvbQ0KdGhlIDxicj4NCiZndDsg Jmd0OyBtb25pdG9yaW5nIG9mIGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRoIHRoYXQg aXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoDQpiZWluZyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JlZC4mcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIGEgJnF1b3Q7bmV0d29yayBj b25uZWN0aW9uJnF1b3Q7IGFuZCB0aGlzDQpuZXR3b3JrIDxicj4NCiZndDsgJmd0OyBjb25uZWN0 aW9uIGlzIGEgc2V0IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgb2YgaW50ZXJjb25uZWN0ZWQg JnF1b3Q7bGluayBjb25uZWN0aW9ucyZxdW90OyBhbmQNCiZxdW90O21hdHJpeCA8YnI+DQomZ3Q7 IGNvbm5lY3Rpb25zJnF1b3Q7LiBBIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc3Vic2V0IG9m IHRob3NlIGludGVyY29ubmVjdGVkIGxpbmsgY29ubmVjdGlvbnMgYW5kDQptYXRyaXggPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBjb25uZWN0aW9ucyBjYW4gYmUgbW9uaXRvcmVkIGFuZCBpcyB0 aGVuIHJlZmVycmVkIHRvDQphcyA8YnI+DQomZ3Q7IGEgJnF1b3Q7dGFuZGVtIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgY29ubmVjdGlvbiZxdW90Oy4gVGhlcmUgaXMgbm8gJnF1b3Q7cGF0aCB0 aGF0IGlzIHBhcmFsbGVsDQp0byB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGRhdGEgcGF0aCZxdW90Oy4g PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBpcyBvbmx5IGFkZGl0aW9uYWwgT0FNIGlu c2VydGVkIGluc2lkZSB0aGUgZGF0YQ0KPGJyPg0KJmd0OyBwYXRoIGJ5IHRoZSA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IFRDTSBNRVBfU28gZnVuY3Rpb24gYW5kIHRoaXMgT0FNIGlzIGV4dHJh Y3RlZCBmcm9tDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7IGRhdGEgcGF0aCBieSA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHRoZSBUQ00gTUVQX1NrIGZ1bmN0aW9uLjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgTWFhcnRlbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0 Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuDQpGYXJyZWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IFNlbnQ6IGRvbmRlcmRhZyAxNiBhcHJpbCAyMDA5IDExOjU5PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGJlbmphbWluLm5pdmVuLWplbmtpbnNA YnQuY29tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYzogQlVTSSBJVEFMTzsgbXBscy10cEBp ZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IEhpIFNhc2hhLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFVuZm9ydHVuYXRlbHkgSSBjYW5ub3QgZnVsbHkgYWdy ZWUgd2l0aCB5b3VyIHN0YXRlbWVudDo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFy ZHdhcmUsDQpjby1yb3V0ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIExTUHM8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBhcmUgYSBzcGVjaWFs IGNhc2Ugb2YgYXNzb2NpYXRlZA0KYmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIHN0YXRlbWVudCB3b3VsZCBi ZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZQ0KaXQgbm90IGZvcjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgUmVxdWlyZW1lbnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMzQgaW4gdGhl IGxhdGVzdCBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPSy4gR290IGl0Ljxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBCdXQgd2hhdCBpcyB0aGlzIGRvaW5n IGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cw0Kc2VjdGlvbj88YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gZmFjdCwgd2hhdCBpcyB0aGlz IHJlcXVpcmVtZW50IGFjdHVhbGx5IHNheWluZz88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIGludGVybWVkaWF0ZSBub2Rl cyAoaW5jbHVkaW5nDQpNRVBzLCBNSVBzIGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7IG90aGVyIGlu dGVybmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkNCm9mIGEgY28tcm91dGVkPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXINCk1V U1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkDQphbmQgdGhl IGJhY2t3YXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0 IHBhdGguPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlz IG5vIHdheSB0aGlzIGlzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdA0KPGJyPg0KJmd0 OyAmZ3Q7IGlzLCB0aGVyZSBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRo YXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQNCm9mIDxicj4NCiZndDsg Jmd0OyB2aWV3IHRoYXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXN1bHRzIGZyb20gYWRo ZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmVmb3JlIGl0IGNvdWxkIGJlIGFzc3VtZWQgdGhhdCB0 aGlzIHJlcXVpcmVtZW50DQppcyBtZXQgYnkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjb25m aWd1cmluZyBzb21lIGRhdGEgcGxhbmUgZGF0YWJhc2UgY29tcG9uZW50IHRocm91Z2gNCnRoZSA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1hbmFnZW1lbnQgcGxhbmUuIFRoZSBkYXRhYmFzZSBj b21wb25lbnQgaXMgbm90IHVzZWQNCjxicj4NCiZndDsgZm9yIGFueXRoaW5nIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgZXhjZXB0IHRvIHNhdGlzZnkgdGhpcyByZXF1aXJlbWVudCBmb3IgJnF1 b3Q7YXdhcmVuZXNzJnF1b3Q7Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBCZW4hIENhbiB3ZSBwbGVhc2UgdHJ5IHRvIHJld3JpdGUgdGhpcyByZXF1 aXJlbWVudA0KaW4gdGVybXMgb2YgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBiZWhhdmlvcj88 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQ bGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0NCmluIHRoZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbGlzdCB0aGF0IGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHNwZWNpZmljIGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhl DQpwYWlyaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXQgZW5kIHBvaW50cyBmb3IgY28tcm91dGVkIGFuZCBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyBwYXRocyBhcmU8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZXhhY3RseSB0aGUgc2FtZSBldmVuIGlmIHRoZXkgYXBw ZWFyIGluIHR3byBkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBpdGVtcyBpbiB0aGU8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzJyBsaXN0KS48YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgUmVxdWlyZW1lbnQg MzQgdGhlIG5vdGlvbg0Kb2YgPGJyPg0KJmd0OyBjby1yb3V0ZWQgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0 YQ0KcGxhbmUgY29udGVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVx dWlyZW1lbnQgKCZxdW90O290aGVyDQppbnRlcm5hbCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlJnF1b3Q7KSBjcmVhdGVzIGEgc3VzcGljaW9u DQp0aGF0IEhXPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzdXBwb3J0IG9mIHRoZTxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYWlyaW5nIGF3YXJlbmVzcyBtYXkgYmUgcmVxdWlyZWQg aW4gb3JkZXIgdG8NCmNvbXBseSB3aXRoIGl0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4 dCAmcXVvdDsoaW5jbHVkaW5nDQpNRVBzLCA8YnI+DQomZ3Q7ICZndDsgTUlQcyBhbmQgb3RoZXIg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRlcm5hbCBmdW5jdGlvbnMgYXMgYXBwcm9wcmlh dGUpJnF1b3Q7IHNob3VsZCBiZQ0KZGVsZXRlZC4gSXQgPGJyPg0KJmd0OyAmZ3Q7IGRvZXMgbm90 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYWRkIHRvICZxdW90O1RoZSBpbnRlcm1lZGlhdGUg bm9kZXMuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgVGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFmdCBpbmNyZWFzZXMgdGhp cw0Kc3VzcGljaW9uOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZuYnNwOyBUYW5kZW0gQ29ubmVjdGlvbjogQSB0YW5kZW0gY29ubmVjdGlvbg0KaXMgYW4g PGJyPg0KJmd0OyAmZ3Q7IGFyYml0cmFyeSBwYXJ0IG9mIGE8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7IHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlh DQpPQU0pPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmRlcGVuZGVudGx5IGZyb20gdGhlPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBlbmQtdG8tZW5kIG1vbml0b3Jpbmcg KE9BTSkuICZuYnNwO0l0IG1heQ0KYmUgYSBtb25pdG9yZWQgPGJyPg0KJmd0OyAmZ3Q7IHNlZ21l bnQgb3IgYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgbW9uaXRvcmVkIGNv bmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0DQpwYXRoLiAmbmJzcDs8YnI+DQomZ3Q7 ICZndDsgVGhlIHRhbmRlbTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgY29u bmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nDQplbmdpbmUocykgb2Y8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBub2RlKHMpPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZuYnNwOyBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBvciBjb25jYXRlbmF0 ZWQNCnNlZ21lbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgcXVvdGUm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFj dHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQgPGJyPg0KJmd0 OyAmZ3Q7IGluc2lzdGVuY2Ugb24gdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5jbHVz aW9uIG9mICZxdW90O1RhbmRlbSBDb25uZWN0aW9uLiZxdW90OyBUaGUgZGVmaW5pdGlvbg0Kd2l0 aGluIDxicj4NCiZndDsgJmd0OyB0aGUgSVRVLVQgb2YgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyB0aGlzIHRlcm0gaXMgcG9vcmx5IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUgPGJyPg0K Jmd0OyBtb25pdG9yaW5nIG9mIGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRoIHRoYXQg aXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoDQpiZWluZyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRDIHNlZW1z IHRvIGJlIGF0IHZhcmlhbmNlLA0KPGJyPg0KJmd0OyAmZ3Q7IGFuZCB3b3VsZCA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgRG9lc24n dCAmcXVvdDtmb3J3YXJkaW5nIGVuZ2luZSZxdW90OyBzb3VuZCBsaWtlDQpoYXJkd2FyZSB0byB5 b3U/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFll cywgYnV0IHNvIHdoYXQ/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0aGVyIHRoZSBN UExTLVRQPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVxdWlyZW1lbnRzIGRyYWZ0PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IChodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVt ZW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdHMtMDEudHh0KSBjb250YWluIGFueSBy ZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoDQp0YW5kZW08YnI+DQomZ3Q7ICZndDsgJmd0OyBjb25u ZWN0aW9ucy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBN UExTLVRQDQpPQU0gPGJyPg0KJmd0OyAmZ3Q7IEZyYW1ld29yayA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgZHJhZnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IChodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWZyPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBhbWV3b3JrLTAwLnR4dDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg KS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgUmln aHQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBMZXQncyBqdXN0IGdldCByaWQgb2YgYW4gdW5u ZWNlc3NhcnkgdGVybSBhbmQgYnJpbmcNCmFsbCA8YnI+DQomZ3Q7IHRoZSBJLURzIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgaW50byBsaW5lLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhh dCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY28tcm91dGVkIHZz Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhc3NvY2lhdGVkPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgaXMgc3RpbGwgcmVxdWlyZWQuIE9u ZSB3YXkNCnRvIHByb3ZpZGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoYXQgY291bGQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYmUgYnkgZXhwbGljaXRseSBsaW1pdGluZyBSZXF1 aXJlbWVudCAzNCB0byBzcGVjaWZpYzxicj4NCiZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9uYWxpdHku PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFncmVl ZC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRy aWFuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBv bGRkb2cuY28udWtdPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgQXBy aWwgMTYsIDIwMDkgMTI6MTMgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBBbGV4YW5k ZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTzxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1Ympl Y3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KcGF0 aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBTYXNoYSw8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgTm90IHJlYWxseSBzdXJlIHdo ZXRoZXIgeW91IGFyZSBtaXNyZXByZXNlbnRpbmcgYW55b25lLA0KYnV0Li4uPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMS4gTXkgcmVhZGlu ZyBvZiAmbmJzcDtvbmUgb2YgQmVuJ3MgJm5ic3A7bWVzc2FnZXMNCmlzIHRoYXQgYXNzb2NpYXRl ZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUg dGhlIG9ubHkgdHlwZXMgb2YgcGF0aHMNCnRoYXQgY2FuIGJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBjcmVhdGVkIGluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBleGlzdGlu ZyBuZXR3b3JrczsgJnF1b3Q7dHJ1ZSZxdW90OyBjby1yb3V0ZWQNCmJpZGlyZWN0aW9uYWwgcGF0 aHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdpbGwgaGF2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyB0byB3YWl0IHVudGlsIChpZiBldmVyKSBuZXcgZXF1aXBtZW50IGJlY29tZXMN CmF2YWlsYWJsZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlITxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkIDxicj4NCiZndDsg Jmd0OyBiaWRpcmVjdGlvbmFsIExTUHMgYXJlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYSBz cGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHlvdSBjYW4gc2V0IHVw IHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzIChlLmcuIHVzaW5nDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7 IG1hbmFnZW1lbnQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwbGFuZSkgeW91IGNhbiBzdXJl bHkgc2V0IHVwIGEgY28tcm91dGVkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBM U1AuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRo ZXJlIGFyZSBzaGlwcGluZyBzb2x1dGlvbnMgdGhhdCBhY2hpZXZlIGNvLXJvdXRlZA0KPGJyPg0K Jmd0OyBiaWRpcmVjdGlvbmFsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgTFNQcyB1c2luZyB0 aGUgY29udHJvbCBwbGFuZS4gVGhlc2UgZWl0aGVyIHVzZSB0aGUNCkdNUExTIDxicj4NCiZndDsg Jmd0OyAod2hpY2ggaXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjbGVhbmVyKSBvciBub24t c3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaA0KaXMgPGJyPg0KJmd0OyAmZ3Q7 IG1lc3N5IGJ1dCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9uYWwpLjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBCdXQgKG9mIGNvdXJz ZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29udHJvbCBwbGFuZQ0KPGJyPg0KJmd0OyAmZ3Q7 IHNvbHV0aW9ucyBoYXZlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbm90aGluZyB0byBkbyB3 aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMgdGhleQ0KPGJyPg0KJmd0OyBhcmUgc29m dHdhcmUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzb2x1dGlvbnMuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMi4gTXkgcmVhZGluZyBv ZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRoYXQNCnRoZSBhY3R1YWw8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGRyaXZlciBmb3I8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgY28t cm91dGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgbWF5IGJlIGV4cGVyaWVuY2UNCndpdGggZXhpc3Rp bmcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRyYW5zcG9ydCBuZXR3b3JrcyByYXRo ZXIgdGhhbiBhbnkgc3BlY2lmaWMgYmVuZWZpdC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0 aGUgTVBMUy1UUCByZXF1aXJlbWVudHM/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBXaGljaCBp cyBub3QgdG8gc2F5IGl0IGlzIGEgYmFkIHRoaW5nLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0 byBnaXZlIHRoZSBwYWNrZXQgbmV0d29yaw0KPGJyPg0KJmd0OyAmZ3Q7IHRoZSBsb29rLCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZlZWwsIGFuZCBiZWhhdmlvcmFsIGNoYXJhY3RlcmlzdGlj cyBvZiBhICZxdW90O2xlZ2FjeSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdHJhbnNw b3J0IG5ldHdvcmsuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcp DQp0aGF0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqIGFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0DQpmb3IgdGhlIHRpbWU8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2JlaW5nLCB0aGUgbW9zdCBpbXBvcnRhbnQgdHlw ZSBvZg0KYmlkaXJlY3Rpb25hbCBwYXRocyBpbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7TVBMUy1UUDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIHRoYXQgaXMgd3JvbmcgYm90aCBnaXZlbiBteSBzdGF0 ZW1lbnQgYWJvdmUsDQphbmQgPGJyPg0KJmd0OyAmZ3Q7IGdpdmVuIHRoYXQgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBvdGhlciB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9ucyB3 aWxsIGJlIDxicj4NCiZndDsgbmVlZGVkIHRvIHJlYWNoIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgdGhlIGZ1bGwgZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC48YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqIHRoZXkgaGFkIGEgZ29vZCBj aGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUNCm9mIDxicj4NCiZndDsgJmd0OyBiaWRpcmVj dGlvbmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBwYXRocyBpbiAmbmJz cDtyZWFsIGRlcGxveW1lbnRzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBJIGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93cyBmcm9tLjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDaGVlcnMsPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBZHJpYW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBt cGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBt cGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8 YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtdHA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg bXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biA8YnI+DQomZ3Q7IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gPGJyPg0KJmd0OyBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgPGJyPg0KJmd0OyBhYm92ZSBhcmUgb2JsaWdhdGVk IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIDxicj4NCiZndDsgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuPGJy Pg0KJmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIDxicj4NCiZndDsgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgPGJyPg0KJmd0OyB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCA8YnI+DQomZ3Q7IGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSA8YnI+ DQomZ3Q7IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBp bmRpdmlkdWFsIHNlbmRlci48YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSA8YnI+DQomZ3Q7IEFudGktU3BhbSBzeXN0ZW0u PGJyPg0KJmd0OyA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNw O0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5m b3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7 aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVy J3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVk Jm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWlu Jm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZu YnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7 dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtl bWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRl bmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9t Jm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJy b3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVz c2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVz ZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJz cDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00045BB44825759F_=-- From Italo.Busi@alcatel-lucent.it Mon Apr 20 18:19:29 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3343A6B20 for ; Mon, 20 Apr 2009 18:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6Fl35HKMqh1 for ; Mon, 20 Apr 2009 18:19:28 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id EA3243A6B9B for ; Mon, 20 Apr 2009 18:19:27 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3L1Kdt1011622; Tue, 21 Apr 2009 03:20:40 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 03:20:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 03:20:38 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1E1B@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: Acm91k8eN17VNhFVQzmDnE7yj0tc5wBsbrrQAICREFAAAkiTPAAieEbg References: <93DFCD4B101EB440B5B72997456C5F94039755DF@esealmw118.eemea.ericsson.se> From: "BUSI ITALO" To: "Ben Niven-Jenkins" , "Annamaria Fulignoli" , "Eric Gray" , "Lou Berger" X-OriginalArrivalTime: 21 Apr 2009 01:20:39.0227 (UTC) FILETIME=[617F30B0:01C9C21F] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 01:19:29 -0000 Ben, I think the issue is slightly different here. I copy some text of a mail = I sent last week to clarify it: > In my understanding we are working on two different targets=20 > in parallel: >=20 > A) extending MPLS protocol such that a profile for its usage in > transport network can be defined >=20 > B) defining a transport profile of MPLS (i.e. MPLS-TP) The associated bidirectional paths are not required in MPLS-TP (target = B). However, the protocol solution should be applicable to MPLS in general = (target A) and therefore associated bidirectional paths should be = considered in the protocol design. Italo > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Monday, April 20, 2009 1:39 AM > To: Annamaria Fulignoli; Eric Gray; Lou Berger; BUSI ITALO > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > I refer my learned colleagues to the following paragraph in=20 > the MPLS-TP > requirements >=20 > The requirements expressed in this document are for the behavior of > the protocol mechanisms and procedures that constitute building > blocks out of which the MPLS transport profile is constructed. The > requirements are not implementation requirements. >=20 > BTW we seem to go around this same loop every few weeks. >=20 > Ben >=20 >=20 > On 20/04/2009 08:37, "Annamaria Fulignoli" > wrote: >=20 > > Eric, > > I couldn't agree more! > >=20 > > Annamaria=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > Eric Gray > > Sent: venerd=EC 17 aprile 2009 20.15 > > To: Lou Berger; BUSI ITALO > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements > >=20 > > Lou/Italo, > >=20 > > This gets into a fuzzy language area. > >=20 > > I think it should be clear that use of associated > > (non-co-routed) > > bi-directional paths is not required. It also seems to me=20 > to be clear that > > they might be used; hence support for them is needed in=20 > protocols and other > > specifications. > >=20 > > We all need to be precise in what we mean by what is=20 > required, and where it is > > required. > >=20 > > -- > > Eric > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > Lou Berger > > Sent: Wednesday, April 15, 2009 10:27 AM > > To: BUSI ITALO > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements > >=20 > > Italo, > >=20 > > On 4/14/2009 6:12 AM, BUSI ITALO wrote: > >> 2) we need to be clear that asssociated bidirectional paths are not > >> required in transport networks (e.g. MPLS-TP) > >>=20 > >=20 > > This doesn't match draft-ietf-mpls-tp-requirements-06. Are=20 > you proposing > > dropping associated bidirectional path from the TP=20 > requirements document? > >=20 > > Lou > >=20 > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 From liu.guoman@zte.com.cn Mon Apr 20 18:40:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4B73A6AF0 for ; Mon, 20 Apr 2009 18:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.602 X-Spam-Level: X-Spam-Status: No, score=-97.602 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18W-p9ROL5Xf for ; Mon, 20 Apr 2009 18:40:11 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id D43583A6AE6 for ; Mon, 20 Apr 2009 18:40:09 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Tue, 21 Apr 2009 09:34:07 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 90033.1979762857; Tue, 21 Apr 2009 09:37:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3L1fJLD062180; Tue, 21 Apr 2009 09:41:20 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <49EC8F69.30000@chello.nl> To: hhelvoort@chello.nl MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 21 Apr 2009 09:39:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-21 09:41:19, Serialize complete at 2009-04-21 09:41:19 Content-Type: multipart/alternative; boundary="=_alternative 000945FA4825759F_=" X-MAIL: mse1.zte.com.cn n3L1fJLD062180 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 01:40:12 -0000 This is a multipart message in MIME format. --=_alternative 000945FA4825759F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KzENCg0KDQoNCkh1dWIgdmFuIEhlbHZvb3J0IDxoaGVsdm9vcnRAY2hlbGxvLm5sPiANCreivP7I yzogIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0wNC0yMCAyMzowNg0Kx+u08Li0ILj4 DQpoaGVsdm9vcnRAY2hlbGxvLm5sDQoNCg0KytW8/sjLDQpsb2FAcGkubnUNCrOty80NCm1wbHMt dHBAaWV0Zi5vcmcNCtb3zOINClJlOiBbbXBscy10cF0gY29tbWVudCBvbiBNUExTLVRQIGRvY3Vt ZW50IHByb2Nlc3NpbmcNCg0KDQoNCg0KDQoNCg0KSGVqIExvYSwNCg0KWW91IHdyb3RlOg0KDQo+ IEFsbCwNCj4gDQo+IEknZCBsaWtlIHRvIGNvbW1lbnQgb24gdGhlIGN1cnJlbnQgZGlzY3Vzc2lv biBvbg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtdHAtcmVx dWlyZW1lbnRzLTA2IC4NCj4gDQo+IFdlIGRvIG91ciBiZXN0IGZvbGxvdyB0aGUgdGhlIG1wbHMt dHAgcHJvY2VzcyBhcyBkZXNjcmliZWQgaW46DQo+IA0KPiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFuZGVyc3Nvbi1tcGxzLXRwLXByb2Nlc3MtMDEudHh0DQoN CkkgYWdyZWUuDQoNCj4gVGhlIG91dHN0YW5kaW5nIHF1ZXN0aW9uIHdlIGhhdmUgZm9yIHRoZSBJ VFUtVCBhZCBob2MgdGVhbSBvbg0KPiBNUExTLVRQIGlzIHN0ZXAgMTMgaW4gdGhlIGZpZ3VyZSBv biBwYWdlIDcgb2YgdGhhdCBkcmFmdC4gV2UgYXJlDQo+IGFza2luZyB0aGUgYWQgaG9jIFRlYW0g aWYgdGhlIGRyYWZ0IGlzIGdvb2QgZW5vdWdoIHRvIHNlbmQgdG8gdGhlDQo+IElFU0cgd2l0aCBh IHJlcXVlc3QgZm9yIHB1YmxpY2F0aW9uLg0KDQpIb3dldmVyIHRoZXNlIGFyZSBub3QgbmV3IHF1 ZXN0aW9ucywgdGhlIGlzc3VlcyB3ZXJlIHJhaXNlZCBkdXJpbmcNCnRoZSBJVFUtVCBwbGVuYXJ5 IGFuZCB3ZXJlIHN1cHBvc2VkIHRvIGJlIHJlc29sdmVkLg0KDQo+IFBsZWFzZSBub3RlIHRoYXQg d2UgYXJlIG9ubHkgZXhwZWN0aW5nIGEgInllcyIgb3IgIm5vIiBhbnN3ZXIgdG8NCj4gb3VyIHF1 ZXN0aW9uLg0KDQpJIHVuZGVyc3RhbmQsIGJ1dCBpbiB0aGlzIGNhc2UgaXQgd291bGQgYmUgYSBj b25kaXRpb25hbCB5ZXMsDQpiZWNhdXNlLCBhcyBJIG1lbnRpb25lZCBhYm92ZSwgbm90IGFsbCBp c3N1ZXMgd2VyZSByZXNvbHZlZC4NCg0KPiBJZiB0aGUgcmVzcG9uc2UgaXMgInllcyIgdGhlbiBw dWJsaWNhdGlvbiB3aWxsIGJlIHJlcXVlc3RlZCwgaWYNCj4gdGhlIGFuc3dlciBpcyAibm8iLCB0 aGUgZG9jdW1lbnQgd2lsbCBiZSB0YWtlbiBiYWNrIGludG8gdGhlDQo+IHdvcmtpbmcgZ3JvdXAg cHJvY2VzcyBhbmQgYSBuZXcgdmVyc2lvbiBwcm9kdWNlZC4NCj4gDQo+IFRoYXQgc2FpZCwgdGhl cmUgaXMgbmV2ZXIgd3JvbmcgdG8gZGlzY3VzcyB0ZWNobmljYWwgaW1wcm92ZW1lbnRzLA0KPiBl ZGl0b3JpYWwgaXNzdWVzIG9yIGdlbmVyZWFsIGNsYXJpZmljYXRpb25zIG9uIGFueSBkcmFmdC4N Cg0KV2hhdCBpcyB0aGUgcHVycG9zZSBvZiBkaXNjdXNzaW5nIHRoZW0gd2hlbiB0aGUgcHVibGlj YXRpb24gaGFzDQpzdGFydGVkLiBVbmxlc3MgdGhpcyBpcyBhIHdvcmtpbmcgbWV0aG9kIGFjY2Vw dGVkIGluIHRoZSBJRVRGLg0KYW5kIHRoZXJlIGlzIHN0aWxsIGEgcG9zc2liaWxpdHkgdG8gbWFr ZSB0ZWNobmljYWwgY2hhbmdlcy8NCmFkanVzdG1lbnRzLg0KDQpJbiB0aGUgSVRVLVQgb25jZSBh IHJlY29tbWVuZGF0aW9uIGRyYWZ0IGlzIGNvbnNlbnRlZCAoeWVzIGlzDQpyZWNlaXZlZCkgdGhl biB0aGUgZHJhZnQgaXMgcHJlLXB1Ymxpc2hlZC4NClRoZSBJVFUtVCBlZGl0b3JzIHdpbGwgdGhh biBicmluZyB0aGUgZG9jdW1lbnQgaW4gYSBzaGFwZQ0KdGhhdCBpcyBjYW4gYmUgb2ZmaWNpYWxs eSBwdWJsaXNoZWQsIGJ1dCBpbiB0aGlzIHN0YWdlIG5vDQp0ZWNobmljYWwgY2hhbmdlcyBjYW4g YmUgbWFkZSBhbnkgbW9yZSwgb25seSB0eXBvZ3JhcGhpY2FsLg0KDQpSZWdhcmRzLCBIdXViLg0K DQotLSANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCiAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnZhbi1oZWx2b29y dC5ldS8NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCkFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVz dCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 000945FA4825759F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisxPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0y NiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkh1dWIgdmFuIEhlbHZvb3J0ICZs dDtoaGVsdm9vcnRAY2hlbGxvLm5sJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0yMCAyMzow NjwvZm9udD4NCjx0YWJsZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdo aXRlPg0KPGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsfr tPC4tCC4+Dxicj4NCmhoZWx2b29ydEBjaGVsbG8ubmw8L2ZvbnQ+PC9kaXY+PC90YWJsZT4NCjxi cj4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5sb2FA cGkubnU8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHMtdHBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJlOiBbbXBscy10cF0gY29tbWVudCBvbiBNUExTLVRQIGRvY3VtZW50DQpwcm9jZXNzaW5n PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD48YnI+DQpIZWogTG9hLDxicj4NCjxicj4NCllvdSB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEFs bCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdkIGxpa2UgdG8gY29tbWVudCBvbiB0aGUgY3VycmVu dCBkaXNjdXNzaW9uIG9uPGJyPg0KJmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1wbHMtdHAtcmVxdWlyZW1lbnRzLTA2IC48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2Ug ZG8gb3VyIGJlc3QgZm9sbG93IHRoZSB0aGUgbXBscy10cCBwcm9jZXNzIGFzIGRlc2NyaWJlZCBp bjo8YnI+DQomZ3Q7IDxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYW5kZXJzc29uLW1wbHMtdHAtcHJvY2Vzcy0wMS50eHQ8YnI+DQo8YnI+DQpJIGFn cmVlLjxicj4NCjxicj4NCiZndDsgVGhlIG91dHN0YW5kaW5nIHF1ZXN0aW9uIHdlIGhhdmUgZm9y IHRoZSBJVFUtVCBhZCBob2MgdGVhbSBvbjxicj4NCiZndDsgTVBMUy1UUCBpcyBzdGVwIDEzIGlu IHRoZSBmaWd1cmUgb24gcGFnZSA3IG9mIHRoYXQgZHJhZnQuIFdlIGFyZTxicj4NCiZndDsgYXNr aW5nIHRoZSBhZCBob2MgVGVhbSBpZiB0aGUgZHJhZnQgaXMgZ29vZCBlbm91Z2ggdG8gc2VuZCB0 byB0aGU8YnI+DQomZ3Q7IElFU0cgd2l0aCBhIHJlcXVlc3QgZm9yIHB1YmxpY2F0aW9uLjxicj4N Cjxicj4NCkhvd2V2ZXIgdGhlc2UgYXJlIG5vdCBuZXcgcXVlc3Rpb25zLCB0aGUgaXNzdWVzIHdl cmUgcmFpc2VkIGR1cmluZzxicj4NCnRoZSBJVFUtVCBwbGVuYXJ5IGFuZCB3ZXJlIHN1cHBvc2Vk IHRvIGJlIHJlc29sdmVkLjxicj4NCjxicj4NCiZndDsgUGxlYXNlIG5vdGUgdGhhdCB3ZSBhcmUg b25seSBleHBlY3RpbmcgYSAmcXVvdDt5ZXMmcXVvdDsgb3IgJnF1b3Q7bm8mcXVvdDsNCmFuc3dl ciB0bzxicj4NCiZndDsgb3VyIHF1ZXN0aW9uLjxicj4NCjxicj4NCkkgdW5kZXJzdGFuZCwgYnV0 IGluIHRoaXMgY2FzZSBpdCB3b3VsZCBiZSBhIGNvbmRpdGlvbmFsIHllcyw8YnI+DQpiZWNhdXNl LCBhcyBJIG1lbnRpb25lZCBhYm92ZSwgbm90IGFsbCBpc3N1ZXMgd2VyZSByZXNvbHZlZC48YnI+ DQo8YnI+DQomZ3Q7IElmIHRoZSByZXNwb25zZSBpcyAmcXVvdDt5ZXMmcXVvdDsgdGhlbiBwdWJs aWNhdGlvbiB3aWxsIGJlIHJlcXVlc3RlZCwNCmlmPGJyPg0KJmd0OyB0aGUgYW5zd2VyIGlzICZx dW90O25vJnF1b3Q7LCB0aGUgZG9jdW1lbnQgd2lsbCBiZSB0YWtlbiBiYWNrIGludG8NCnRoZTxi cj4NCiZndDsgd29ya2luZyBncm91cCBwcm9jZXNzIGFuZCBhIG5ldyB2ZXJzaW9uIHByb2R1Y2Vk Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IHNhaWQsIHRoZXJlIGlzIG5ldmVyIHdyb25nIHRv IGRpc2N1c3MgdGVjaG5pY2FsIGltcHJvdmVtZW50cyw8YnI+DQomZ3Q7IGVkaXRvcmlhbCBpc3N1 ZXMgb3IgZ2VuZXJlYWwgY2xhcmlmaWNhdGlvbnMgb24gYW55IGRyYWZ0Ljxicj4NCjxicj4NCldo YXQgaXMgdGhlIHB1cnBvc2Ugb2YgZGlzY3Vzc2luZyB0aGVtIHdoZW4gdGhlIHB1YmxpY2F0aW9u IGhhczxicj4NCnN0YXJ0ZWQuIFVubGVzcyB0aGlzIGlzIGEgd29ya2luZyBtZXRob2QgYWNjZXB0 ZWQgaW4gdGhlIElFVEYuPGJyPg0KYW5kIHRoZXJlIGlzIHN0aWxsIGEgcG9zc2liaWxpdHkgdG8g bWFrZSB0ZWNobmljYWwgY2hhbmdlcy88YnI+DQphZGp1c3RtZW50cy48YnI+DQo8YnI+DQpJbiB0 aGUgSVRVLVQgb25jZSBhIHJlY29tbWVuZGF0aW9uIGRyYWZ0IGlzIGNvbnNlbnRlZCAoeWVzIGlz PGJyPg0KcmVjZWl2ZWQpIHRoZW4gdGhlIGRyYWZ0IGlzIHByZS1wdWJsaXNoZWQuPGJyPg0KVGhl IElUVS1UIGVkaXRvcnMgd2lsbCB0aGFuIGJyaW5nIHRoZSBkb2N1bWVudCBpbiBhIHNoYXBlPGJy Pg0KdGhhdCBpcyBjYW4gYmUgb2ZmaWNpYWxseSBwdWJsaXNoZWQsIGJ1dCBpbiB0aGlzIHN0YWdl IG5vPGJyPg0KdGVjaG5pY2FsIGNoYW5nZXMgY2FuIGJlIG1hZGUgYW55IG1vcmUsIG9ubHkgdHlw b2dyYXBoaWNhbC48YnI+DQo8YnI+DQpSZWdhcmRzLCBIdXViLjxicj4NCjxicj4NCi0tIDxicj4N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0cDovL3d3dy52YW4taGVsdm9vcnQuZXUvPGJyPg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTxicj4NCkFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVzdCBsaWtl IGV2ZXJ5b25lIGVsc2UuLi48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KbXBscy10 cEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3Jt YXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlv biZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNw O3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNw O29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJz cDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDth Ym92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtz ZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8m bmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5i c3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJz cDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5i c3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0 aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZu YnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNw O3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNw O3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZu YnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNw O2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3Rl bS4NCjwvcHJlPg== --=_alternative 000945FA4825759F_=-- From Italo.Busi@alcatel-lucent.it Mon Apr 20 18:59:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B663C3A6E43 for ; Mon, 20 Apr 2009 18:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Yt-PnR37V8b for ; Mon, 20 Apr 2009 18:59:36 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7955B28C15F for ; Mon, 20 Apr 2009 18:59:36 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3L20aZb028612; Tue, 21 Apr 2009 04:00:48 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 02:54:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 02:54:38 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4021B1E19@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) thread-index: Acm/T8WF1iR/KpjATHu9O1dOKY1vQQAATDVQAAXfjj0ACB4nIAA7e5w0AGjg1IA= References: <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> From: "BUSI ITALO" To: "Ben Niven-Jenkins" , "Annamaria Fulignoli" , "VIGOUREUX MARTIN" X-OriginalArrivalTime: 21 Apr 2009 00:54:39.0891 (UTC) FILETIME=[C00F6630:01C9C21B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 01:59:37 -0000 Ben, I am not 100% confortable with your proposal. I would propose the following changes to your proposal: 1) Remove the term Tandem Connection from the MPLS-TP requirements as it is redundant (i.e. Not used in that document) and move it to the MPLS-TP OAM Framework, where it is used extensively 2) Ensure the MPLS-TP OAM requirements express all the necessary functional requirements around monitoring of end to end paths as well as parts of end to end paths. This can be done without referring explicitly to Tandem Connections but the functional requirements MUST be fully equivalent to the TCM requirements as per ITU-T definition 3) Keep the TCM solution description, as per JWT agreement, in the MPLS-TP OAM Framework 4) If a term better than TCM is found, update the MPLS-TP OAM Framework using this term and clarify in the Rosetta stone that this IETF term is fully equivalent to the ITU-T TCM term Italo > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Saturday, April 18, 2009 3:42 PM > To: BUSI ITALO; Annamaria Fulignoli; VIGOUREUX MARTIN > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 > Associated bidirectional transport path requirements) >=20 > Italo, >=20 > On 17/04/2009 19:20, "BUSI ITALO"=20 > wrote: >=20 > > Ben, > >=20 > > TCM is an architectural construct well defined in G.805 in a > > technology-independent manner. As such TCM does not imply=20 > any specific > > solution. > >=20 > > The solution we are working on to implement TCM within=20 > MPLS-TP is based on the > > JWT agreement and described in the OAM Framework document. > >=20 > > I do not think we should drop a requirement because of people's > > misunderstandings. >=20 > See my mail from Friday which I have copied below. I do not=20 > believe I am > suggesting removal of requirements but that we describe the=20 > requirements > without reference to what appears to be a somewhat controversial term. >=20 > As Adrian has repeatedly stated what is important is we=20 > accurately capture > the functional requirements. >=20 > Given that neither the MPLS-TP requirements nor the MPLS-TP=20 > OAM requirements > documents use the term TCM when describing the requirements I=20 > think this aim > is thoroughly achievable without dropping any requirements. >=20 > That way we can close this issue IMO. >=20 > Ben >=20 > > From: Benjamin Niven-Jenkins > > Date: Fri, 17 Apr 2009 11:04:17 +0100 > > To: BUSI ITALO , Adrian Farrel > > , Alexander Vainshtein=20 > > > Cc: > > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 > RE: Associated > > bidirectional transport path requirements) > >=20 > > Italo, > >=20 > > I think we are converging. If I can be so bold as to speak=20 > on his behalf > > Adrian's objection seemed to be to the use of the term TCM. > >=20 > > It is defined in the MPLS-TP requirements but not used. > >=20 > > It is not used in the MPLS-TP OAM requirements document. > >=20 > > Therefore I think the way forward is as follows: > >=20 > > 1) Remove the term Tandem Connection from the MPLS-TP=20 > requirements as it is > > redundant (i.e. Not used in that document). > >=20 > > 2) Ensure the MPLS-TP OAM requirements express the=20 > necessary functional > > requirements around monitoring of end to end paths as well=20 > as parts of end > > to end paths. This can be done without referring explicitly=20 > to Tandem > > Connections. > >=20 > > When it comes to solution design we can decide what is the=20 > best mechanism to > > achieve/implement those requirements be it LSP hierarchy or=20 > something else. > > The JWT has proved that it is possible to meet those=20 > requirements using > > existing MPLS technology (maybe with some enhancements). I=20 > do not believe we > > have to necessarily use the solution they propose aslong as whatever > > solution we ultimately decide upon meets all the necessary=20 > requirements > > expressed. > >=20 > > Can we agree on that as an approach and close this off for now? > >=20 > > Ben >=20 >=20 From liu.guoman@zte.com.cn Mon Apr 20 19:04:49 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479363A6E20 for ; Mon, 20 Apr 2009 19:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.31 X-Spam-Level: X-Spam-Status: No, score=-97.31 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtO4VarJL2-J for ; Mon, 20 Apr 2009 19:04:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 7A37E3A6B90 for ; Mon, 20 Apr 2009 19:04:43 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 11164764009499; Tue, 21 Apr 2009 09:55:45 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.2423590222; Tue, 21 Apr 2009 10:02:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3L22ouc076390; Tue, 21 Apr 2009 10:02:51 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: "BRUNGARD, DEBORAH A, ATTLABS" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 21 Apr 2009 09:59:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-21 10:02:49, Serialize complete at 2009-04-21 10:02:49 Content-Type: multipart/alternative; boundary="=_alternative 000B18B74825759F_=" X-MAIL: mse1.zte.com.cn n3L22ouc076390 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 02:04:49 -0000 This is a multipart message in MIME format. --=_alternative 000B18B74825759F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVib3JhaDoNCiBtYXliZSB3aGF0IHlvdSBzYWlkIGlzIHJpZ2h0LiBidXQgSSBjYW4ndCBjb21w bGV0ZWx5IGFncmVlIHlvdXIgb3BpbmlvbnMuIA0KSU1PLiBtcGxzLXRwIGlzIHJlZ2FyZCBhcyB0 cmFuc3BvcnQgbmV0d29yayBsaWtlIFNESC9TT05FVC4gc28gaXQgc2hvdWxkIA0KaGF2ZSBBSVMv RkRJIGZ1Y3Rpb25zIGFzIFNESC9TT05FVC4NCg0KZG8geW91IHRoaW5rIHNvLg0KDQpiZXN0IHJl Z2FyZHMNCmxpdSANCg0KDQoNCiJCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTIiA8ZGJydW5n YXJkQGF0dC5jb20+IA0Kt6K8/sjLOiAgbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoyMDA5LTA0 LTIwIDIzOjQ3DQoNCsrVvP7Iyw0KIk1hYXJ0ZW4gVmlzc2VycyIgPG1hYXJ0ZW4udmlzc2Vyc0Bo dWF3ZWkuY29tPiwgPG5laWwuMi5oYXJyaXNvbkBidC5jb20+DQqzrcvNDQptcGxzLXRwQGlldGYu b3JnDQrW98ziDQpSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCByZXF1aXJlbWVudHMNCg0KDQoNCg0KDQoNCkkgYWdyZWUgd2l0aCBOZWlsLCBpdCBp cyB2ZXJ5IHF1ZXN0aW9uYWJsZSB0aGUgdmFsdWUgb2YgQUlTL0ZESSBpbiBhDQpwYWNrZXQgbmV0 d29yay0gYW55IG1vZGUuIEl0IGNhbiByZXN1bHQgaW4gYSBEb1MgYXR0YWNrIGJ5IGFuIG9wZXJh dG9yDQpvbiB0aGVtc2VsdmVzIHNvIGV2ZW4gWTE3MzEgcmVjb21tZW5kcyBub3QgdG8gYmxvY2sg ZGF0YSBmcmFtZXM6DQoiQSBNRVAgY2FuIGRlY2lkZSB3aGV0aGVyIGl0IGJsb2NrcyBkYXRhIGZy YW1lcyB3aGVuIGl0IGRldGVjdHMgZEFJUy4NClRoZSBwcmluY2lwbGUgcmVxdWlyZW1lbnQNCnRo YXQgaW5mbHVlbmNlcyB0aGlzIGRlY2lzaW9uIGlzIHRoYXQgZGF0YSBmcmFtZXMgb3VnaHQgdG8g YmUgZm9yd2FyZGVkDQphcyBtdWNoIGFzIHBvc3NpYmxlLCB3aXRob3V0DQp0aGUgcG9zc2liaWxp dHkgb2YgZm9yd2FyZGluZyB3cm9uZyBkYXRhIGZyYW1lcyBkb3duc3RyZWFtLiINClRhYmxlIEku Ny0yIHNob3dzIGZvciBBSVMsIG5vdCB0byBibG9jay4NCg0KQW5kIGFzIFkxNzMxIHN0YXRlcywg QUlTIGNhbiBvbmx5IGJlIHVzZWQgdW5kZXIgdmVyeSBjb25zdHJhaW5lZA0KYXJjaGl0ZWN0dXJl cyAtIGlmIHJlcXVpcmVkIGZvciBNUExTLVRQLCBpdCBuZWVkcyB0byBoYXZlIHRoZSBzYW1lDQpn dWlkYW5jZSBhcyBpbiBZMTczMSwgaS5lLiBwb2ludC10by1wb2ludCBhbmQgc2VydmVyL2NsaWVu dCBvbmUtdG8tb25lOg0KImZvciBhIHBvaW50LXRvLXBvaW50IEVUSCBjb25uZWN0aW9uLCBhIE1F UCBoYXMgb25seSBhIHNpbmdsZSBwZWVyIE1FUC4NClRoZXJlZm9yZSwgdGhlcmUNCmlzIG5vIGFt YmlndWl0eSByZWdhcmRpbmcgdGhlIHBlZXIgTUVQIGZvciB3aGljaCBpdCBzaG91bGQgc3VwcHJl c3MNCmFsYXJtcyB3aGVuIGl0IHJlY2VpdmVzIHRoZQ0KRVRILUFJUyBpbmZvcm1hdGlvbi4iDQpT byBzaG91bGQgb25seSBiZSB3aXRoaW4gb25lIGRvbWFpbiAtIHRoZW4gbm8gbmVlZC4NCg0KRGVi b3JhaA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy10cC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmIE9m IE1hYXJ0ZW4gVmlzc2Vycw0KU2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSAxMDowNSBBTQ0K VG86IG5laWwuMi5oYXJyaXNvbkBidC5jb20NCkNjOiBtcGxzLXRwQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0K cmVxdWlyZW1lbnRzDQoNCk5laWwsDQoNCj4gYnV0IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4u ZG8gbWUgYSBmYXZvdXIhDQoNCkV0aGVybmV0IEFJUyBpcyBpbmRlZWQgYSByZXF1aXJlbWVudCBh bmQgYSBuZWNlc3NpdHkuIEFuZCB5b3Ugd2lsbCBub3QNCmJlDQphYmxlIHRvIHVuZGVyc3RhbmQg dGhhdCBhcyBsb25nIGFzIHlvdSByZWZ1c2UgdG8gYWNjZXB0IHRoYXQgImNsLW1vZGUiDQppcyBh DQpmb3J3YXJkaW5nIG1vZGUgd2l0aGluIGEgKip0cmFuc3BvcnQgZW50aXR5KiouIEcuODAwIGFt ZW5kbWVudCAxIGhhcw0KZmluYWxseQ0KcmVpbnRyb2R1Y2VkIHRoaXMgdHJhbnNwb3J0IGVudGl0 eSBpbnRvIEcuODAwLiBCZXNpZGVzIHRoYXQsIGl0IGFsc28NCmludHJvZHVjZWQgdGhlICoqZGlm ZmVyZW50aWF0ZWQgY29ubmVjdGlvbioqOg0KDQpbRy44MDAgYW0xXSAiQSBkaWZmZXJlbnRpYXRl ZCBjb25uZWN0aW9uIGlzIGEgdHJhbnNwb3J0IGVudGl0eSB0aGF0DQp0cmFuc2ZlcnMgaW5mb3Jt YXRpb24gYmVsb25naW5nIHRvIG11bHRpcGxlIGNvbW11bmljYXRpb25zIGJldHdlZW4gcG9ydHMN CmFjcm9zcyBhIHN1Ym5ldHdvcmsuIDwuLj4gSW4gYSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9u IG1lc3NhZ2UNCmNvbnRlbnRzDQphcmUgaW50ZXJwcmV0ZWQgdG8gaWRlbnRpZnkgKHNldHMgb2Yp IGNvbW11bmljYXRpb25zIHdoaWNoIHJlY2VpdmUNCmRpZmZlcmVudA0KdHJlYXRtZW50LiAgVGhl IHNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIGRpc3Rpbmd1aXNoZWQgYnkgdGhlDQpmb3J3 YXJkaW5nIGlkZW50aWZpZXIgb3Igb3RoZXIgbGF5ZXIgaW5mb3JtYXRpb24uICBPcmRlciBpcyBu b3QNCm5lY2Vzc2FyaWx5DQpwcmVzZXJ2ZWQgYmV0d2VlbiBtZXNzYWdlcyBiZWxvbmdpbmcgdG8g c2V0cyBvZiBjb21tdW5pY2F0aW9ucyByZWNlaXZpbmcNCmRpZmZlcmVudCB0cmVhdG1lbnQuICBT ZXRzIG9mIGNvbW11bmljYXRpb25zIG1heSBiZSBpZGVudGlmaWVkIGZvcg0KcHVycG9zZXMNCnN1 Y2ggYXMgdHJhZmZpYyBjb25kaXRpb25pbmcgb3IgcHJlc2VydmluZyBjb21tdW5pY2F0aW9uIG1l c3NhZ2Ugb3JkZXIuIg0KDQoNCkV0aGVybmV0IFZMQU5zIGFyZSBpbiB0ZXJtcyBvZiBHLjgwMCAi ZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbnMiLg0KRXRoZXJuZXQNCkFJUyBwcm92aWRlcyBBSVMg d2l0aGluIHRoZSBzY29wZSBvZiBzdWNoICJkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIi4NCklm DQp5b3UgYXBwbHkgdGhpcyB0byBteSBwcm9wb3NlZCBQVE4gbGF5ZXIgc3RhY2ssIHRoZW4gdGhl IEVWQyBsYXllcg0KdG9wb2xvZ3kNCndpbGwgY29uc2lzdHMgb2YgRVZDIGxpbmtzIHN1cHBvcnRl ZCBieSBNUExTLVRQLCBFdGhlcm5ldCwgUEJCLVRFIGFuZA0KUC1PVE4NClZQIHRyYWlscyBpbnNp ZGUgbWV0cm8gYW5kIGNvcmUgZG9tYWlucyBpbnRlcmNvbm5lY3RpbmcgRVZDIG1hdHJpY2VzLg0K V2hlbg0Kb25lIG9mIHRob3NlIEVWQyBsaW5rcyBpcyBpbnRlcnJ1cHRlZCwgZS5nLiBpbiB0aGUg Y29yZSBiZXR3ZWVuIG1ldHJvIDENCmFuZA0KbWV0cm8gNCAoc2VlIGF0dGFjaGVkIHNsaWRlKSwg dGhlbiB0aGUgRVZDIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24NCnRoYXQgaXMNCnByZXNlbnQg b24gdGhpcyBsaW5rIHdpbGwgYmUgaW50ZXJydXB0ZWQuIEF0IHRoZSBFVkMgc3dpdGNoL2JyaWRn ZSBub2RlDQppbg0KbWV0cm8gNCB0aGlzIGludGVycnVwdGlvbiBpcyBub3RpY2VkIGFuZCBFVkMt QUlTIGlzIGluc2VydGVkIGluIHRoZQ0KZG93bnN0cmVhbSBkaXJlY3Rpb24gdG8gc3VwcHJlc3Mg dGhlIEVWQy1MT0MgYWxhcm1zIGF0IEVWQyBlbmRwb2ludHMgRDQNCmFuZA0KRDUuDQoNClRoZSBF VkMtQUlTIChpLmUuIEV0aGVybmV0IEFJUykgZnJhbWUgaGFzIGEgcmVzZXJ2ZWQgbXVsdGljYXN0 IGFkZHJlc3MsDQp3aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIEFJUyBpcyBicm9hZGNhc3QgdG8g dGhlIGVuZHBvaW50cyBvZiB0aGUgRVZDLg0KDQpJIGJlbGlldmUgdGhhdCBpdCBpcyB0aW1lIGZv ciB5b3UgdG8gYWRhcHQgeW91ciB2aWV3IG9uIGNvIGFuZCBjbCBtb2Rlcw0KYW5kDQpyZWxhdGUg aXQgdG8gdGhlIGZvcndhcmRpbmcgbW9kZSAqKklOU0lERSoqIGEgdHJhbnNwb3J0IGVudGl0eS4g DQoNCldoYXQgd2Uga25vdyBhcyB0aGUgaW50ZXJuZXQgaXMgZXNzZW50aWFsbHkgYW4gIklQIGRp ZmZlcmVudGlhdGVkDQpjb25uZWN0aW9uIiB3aXRoIGEgYmlsbGlvbiBvciBtb3JlIHBvcnRzLg0K V2hhdCB3ZSBrbm93IGFzIGFuIElQIFZQTiBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50 aWF0ZWQNCmNvbm5lY3Rpb24iDQp3aXRoIGUuZy4gbiBwb3J0cyAobiBpbiB0aGUgcmFuZ2Ugb2Yg ZS5nLiAyIHRvIDEwMDApLg0KV2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMgZXNz ZW50aWFsbHkgYW4gIkV0aGVybmV0DQpkaWZmZXJlbnRpYXRlZA0KY29ubmVjdGlvbiIgd2l0aCBu IHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuDQpXaGF0IHdlIGtub3cg YXMgYSBwMnAgTVBMUyBFLUxTUCBpcyBlc3NlbnRpYWxseSBhbiAiTVBMUyBkaWZmZXJlbnRpYXRl ZA0KY29ubmVjdGlvbiIgd2l0aCAyIHBvcnRzLg0KV2hhdCB3ZSBrbm93IGFzIGEgcDJwIFNESCBW Qy1uIGlzIGEgIlNESCBWQy1uIGNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy4NCg0KVHJhbnNwb3J0 IG5ldHdvcmsgT0FNIGFwcGxpZXMgdG8gdHJhbnNwb3J0IGVudGl0aWVzLCB3aGljaCBhcmUgKGlu IHRlcm1zDQpvZg0KRy44MDAgYW0xKSBjb25uZWN0aW9ucyBhbmQgZGlmZmVyZW50aWF0ZWQgY29u bmVjdGlvbnMuDQoNClJlZ2FyZHMsDQpNYWFydGVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBuZWlsLjIuaGFycmlzb25AYnQuY29tIFttYWlsdG86bmVpbC4yLmhhcnJpc29u QGJ0LmNvbV0gDQpTZW50OiB2cmlqZGFnIDE3IGFwcmlsIDIwMDkgMjI6MDANClRvOiBKb2huLkUu RHJha2UyQGJvZWluZy5jb207IEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ7DQpBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20NCkNj OiBtcGxzLXRwQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KcmVxdWlyZW1lbnRzDQoNCkpvaG4sICBUaGFua3Mg dGhpcyBpcyBhIGdyZWF0IHBsYXRmb3JtIHRvIGV4cGxhaW4gd2h5IE9BTSBmb3IgdGhlIDMNCm5l dHdvcmsNCm1vZGVzIG5lZWRzIHRvIGJlIGRpZmZlcmVudC4gIEkgYW0gZ2V0dGluZyBhIHdlZSBi aXQgdGlyZWQgb2YgZm9sa3MNCnRyeWluZw0KdG8gbWFrZSBhbGwgMyBuZXR3b3JrIG1vZGVzIGxv b2sgYWxpa2UgKGFuZCB0aGVuLCBldmVuIHdvcnNlLCBpbnRlcndvcmsNCnRoZW0NCmFzIGFzIHBl ZXJzLi4uZXNwIHdoZW4gbm90IG5vdCB0b3Atb2Ytc3RhY2sNCm5ldHdvcmtzLi4uSSBtZWFuIGhv dyBzaWxseSBjYW4gd2UgZ2V0PykuICAgSSBhbSBldmVuIG1vcmUgZnJ1c3RyYXRlZCBieQ0KdGhl IGZhY3QgdGhvc2UgcGVkZGxpbmcgdGhpcyBGVUQgb25seSBldmVyIHNlZW0gdG8gY29uc2lkZXIg T0FNIGFuZA0KZm9yZ2V0DQphbGwgb3RoZXIgRFAvQ1AvTVAgY29tcG9uZW50cyAoZXNwIHRvcC1v Zi1zdGFjayBtZXNzYWdlL2ZpbGUvc3RyZWFtDQphcHBsaWNhdGlvbiBhZGFwdGF0aW9ucykuICBI b3cgd3JvbmcgY2FuIHRoaXMgZ2V0ISANCg0KSW4gdGhlIGNvIG1vZGVzIGEgKmNvbm5lY3Rpb24q IGlzIGEgdmVyeSBzcGVjaWZpYyBhbmQgKmNvbnN0cmFpbmluZyoNCmNvbnN0cnVjdC4uLi4uSSBh bSBhc3N1bWluZyBoZXJlIHdlIHJlc3BlY3QgdGhlIHJ1bGVzIG9mIGEgY29ubmVjdGlvbg0KKGll DQpzaW5nbGUgc291cmNlKSB0aG91Z2ggc29tZSBmb2xrcyBkb24ndCBldmVuIGJvdGhlciB0byBy ZXNwZWN0IHRoaXMsIGFuZA0KdGhpcw0KaXMgZGVzcGl0ZSB0aGUgZmFjdCB0aGF0IHdlIGFsbCBr bm93IHdoYXQgcHJvYmxlbXMgbXVsdGlwbGUtc291cmNlDQpjb25zdHJ1Y3RzIGNhbiBjYXVzZSAo ZnJvbSBMRFAvUEhQLi4uLmVyZ28gTVBMUy1UUCkuDQoNCldoZW4gd2UgaGF2ZSBhIGNvbm5lY3Rp b24gdGhpcyByZXN0cmljdHMgKmFsbCogRFAgKGllIHRyYWZmaWMgYW5kIE9BTSkNCnRvDQpzdGF5 IHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBjb25uZWN0aW9uLiAgV2hpY2ggaXMgZmluZSB1bmRl cg0KZGVmZWN0LWZyZWUNCmNvbmRpdGlvbnMsIGJ1dCBpZiB3ZSBoYXZlIGxlYWtpbmcgdHJhZmZp YyB0aGVuIHRoZSBjb25zdHJhaW5pbmcgbmF0dXJlDQpvZg0KdGhlIGNvbm5lY3Rpb24gY29uc3Ry dWN0IGlzIGJyb2tlbi4gIEluIGEgbnV0c2hlbGwgd2hhdCB0aGlzIG1lYW5zIGlzDQp0aGF0DQpP QU0gdGhhdCBpcyBvZiBhIHJlcXVlc3QvcmVzcG9uc2UgbmF0dXJlIGNhbm5vdCBiZSB0cnVzdGVk IGluIGNvIG1vZGUNCm5ldHdvcmtzIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3RzLi4uLi5p bmRlZWQsIHdoeSBzaG91bGQgYSBsZWFraW5nDQpEUA0KaGF2ZSBhIHN5bW1ldHJpYyBnby9yZXR1 cm4gZGVmZWN0IGJlaGF2aW91cj8uLi4udmVyeSBsaWtlbHkgaXQgd29uJ3QuDQpTbw0Kd2hpbHN0 IHJlcXVlc3QvcmVzcG9uc2UgT0FNIGlzIHJpZ2h0IGZvciB0aGUgY2wgbW9kZSBpdCBpcyBub3Qg cmlnaHQgZm9yDQp0aGUNCmNvIG1vZGUgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCBjb25k aXRpb25zLg0KDQpNb3JlIGdlbmVyYWxseSB0aGUgMyBtb2RlcyBhcmUgZGlmZmVyZW50IGFuZCBu b3QganVzdCBpbiBPQU0NCnJlcXVpcmVtZW50cy4uLi5idXQgQUlTL0ZESSBpbiB0aGUgY2wgbW9k ZT8uLi5kbyBtZSBhIGZhdm91ciEuLi5hdCBsZWFzdA0KSUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2Ug dG8gYmluIHRoaXMgZm9yIEV0aGVybmV0IGV2ZW4gdGhvdWdoIGl0IHJlbWFpbnMNCmluDQpZLjE3 MzEuICBBbmQgd2hpY2ggaXMgd2h5IEkgb2Z0ZW4gdHJvdC1vdXQgdGhlIHJhdGhlciBzaWxseSAo dG8gaGF2ZSB0bw0Kc2F5DQp0aGlzKSBvYnNlcnZhdGlvbiB0aGF0IGlmIElQIChjbCBtb2RlKSBj b3VsZCBkbyBpdCBhbGwgdGhlbiB3aHkgaGF2ZQ0KSUVURg0KZm91bmQgaXQgbmVjZXNzYXJ5IHRv IGNyZWF0ZSBNUExTIChjby1wcykgYW5kIEdNUExTIChDUCBmb3IgY28tY3MpLiAgVGhlDQphbnN3 ZXIgbGllcyBpbiB0aGUgcGh5c2ljcy4uLmFuZCBHLjgwMCBhdHRlbXB0cyB0byBleHBsYWluIHRo YXQNCnBoeXNpY3MuLi4uRy44MDUgZG9lcyBub3QuDQoNClNvLCB0aGUgMyBtb2RlcyBhcmUgZGlm ZmVyZW50Li4ucGxlYXNlIGFjY2VwdC9yZWpvaWNlIGluIHRoaXMgZmFjdCBhcw0KdGhleQ0KYWxs IG9mZmVyIHNvbWV0aGluZyBkaWZmZXJlbnQvaW1wb3J0YW50LiAgQnV0IGRvIG5vdCBiZSBob29k d2lua2VkIGJ5DQp0aG9zZQ0Kd2hvIHBlZGRsZSBhIHN0b3J5IHRoYXQgdGhhdCB0cmllcyB0byBt YWtlIHRoZSBPQU0gb2YgdGhlIDMgbW9kZXMgdGhlDQpzYW1lLiANCg0KcmVnYXJkcywgTmVpbCAN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNA aWV0Zi5vcmcNCj4gW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBEcmFrZSwgSm9obiBFDQo+IFNlbnQ6IDE3IEFwcmlsIDIwMDkgMjA6MDINCj4gVG86IEJVU0kg SVRBTE87IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gQ2M6IG1wbHMt dHBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+IHJlcXVpcmVtZW50cw0KPiANCj4gSXRhbG8sDQo+IA0K PiBBcyBkZXNjcmliZWQgaW4gdGhlIE1QTFMgVFAgT0FNIFJlcXVpcmVtZW50cyBJLUQsIHZpcnR1 YWxseSBhbGwgb2YgdGhlDQoNCj4gT0FNIGZ1bmN0aW9ucyByZXF1aXJlIGEgcmV0dXJuIHBhdGgs IGFuZCBpbiB0aGUgYWJzZW5jZSBvZiBhIHJldHVybiANCj4gcGF0aCB0aGV5IGFyZSBkaXNhYmxl ZC4NCj4gDQo+IEFzIGRlc2NyaWJlZCBpbiBEYXZpZCBTaW5pY3JvcGUncyBtZWV0aW5nIG1pbnV0 ZXMgDQo+IChodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9hdHRh Y2htZW50L3dpa2kvDQo+IG1lZXRpbmctbm8NCj4gdGVzLzIwMDgxMDE1Lm1wbHMtaW50ZXJvcC1k dC1ub3Rlcy56aXApLCBpZiBJUCBhZGRyZXNzaW5nIGlzIHVzZWQsIGFuIA0KPiBNUExTIFRQIG5l dHdvcmsgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBnZXR0aW5nIElQIHBhY2tldHMgZnJvbSANCj4g ZGVzdGluYXRpb24gdG8gc291cmNlOyBuZWl0aGVyIHRoZSBtaW51dGVzIG5vciBJIHN0aXB1bGF0 ZSB0aGF0IGEgDQo+IGNvbnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byBpbnN0YW50aWF0 ZSB0aGlzIGZvcndhcmRpbmcuDQo+IA0KPiBBcyBhbiBhc2lkZSwgdGhlIGlzc3VlIG9mIHJldHVy biBwYXRoIGZvciB1bmlkaXJlY3Rpb25hbCBMU1BzIGNvdWxkIGJlDQoNCj4gY2hhcmF0ZXJpemVk IGFzIHRoZSBlbGVwaGFudCBpbiB0aGUgcm9vbS4gIEluIHRoZSBNUExTIFRQIE9BTSANCj4gRnJh bWV3b3JrIEktRCwgdW5pY2FzdCBMU1BzIGFyZSBvbmx5IG1lbnRpb25lZCB0aHJlZSB0aW1lcyBh bmQgcmV0dXJuIA0KPiBwYXRocyBub3QgYXQgYWxsLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gSm9o bg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQlVTSSBJVEFMTyBb bWFpbHRvOkl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXRdDQo+ID4gU2VudDogRnJpZGF5LCBB cHJpbCAxNywgMjAwOSAxOjU5IEFNDQo+ID4gVG86IERyYWtlLCBKb2huIEU7IEFsZXhhbmRlciBW YWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+ IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCBwYXRoIA0KPiA+IHJlcXVpcmVtZW50cw0KPiA+IA0KPiA+IEpvaG4sDQo+ID4gDQo+ID4gSSBt aWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVtZW50IG9mIE1QTFMtVFAgYmVpbmcgY2FwYWJsZSBv ZiANCj4gPiBzZW5kaW5nIHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVj dGlvbmFsIExTUHMuDQo+ID4gDQo+ID4gVGhpcyByZXF1aXJlbWVudCBkb2VzIG5vdCBiZWxvbmcg dG8gdGhlIGZpcnN0IHNldCBvZiByZXF1aXJlbWVudHMgDQo+ID4gSVRVLVQgaXMgZXhwZWN0aW5n IHRvIGJlIG1ldCBieSBPY3RvYmVyLg0KPiA+IA0KPiA+IEhvd2V2ZXIsIEkgdGhpbmsgdGhpcyBp biBhIHBvdGVudGlhbCBpbnRlcmVzdGluZyBhZGRpdGlvbmFsIA0KPiA+IHJlcXVpcmVtZW50IHRv IGJlIHRha2VuIGludG8gYWNjb3VudCAoYXQgd29yc3QgaW4gYQ0KPiBzdWJzZXF1ZW50IHBoYXNl KS4NCj4gPiANCj4gPiBJIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVudCBuZWVkcyB0byBiZSBl dmFsdWF0ZWQgdmVyc3VzIG90aGVyIA0KPiA+IG1vcmUgaW1wb3J0YW50IHJlcXVpcmVtZW50cyAo ZS5nLiB0aGUgcG9zc2liaWxpdHkgdG8gd29yayB3L28gSVAgDQo+ID4gZm9yd2FyZGluZyBhbmQg dGhlIG5lZWQgZm9yIE9BTSB0byBjb250aW51ZSB0byBtb25pdG9yIHRoZSBkYXRhIA0KPiA+IHBs YW5lIGFsc28gaW4gY2FzZSBvZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wgb3IgbWFu YWdlbWVudCANCj4gPiBwbGFuZSkuDQo+ID4gDQo+ID4gSSBhbSBvcGVuIHRvIGRpc2N1c3MgaXQg YnV0IG5vdCBzdXJlIHRoaXMgaXMgdGhlIHJpZ2h0IHRpbWUgYmVjYXVzZSANCj4gPiBJIHdpc2gg dG8gYXZvaWQgZGVsYXlpbmcgdGhlIGZpcnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24gc29sdXRpb24u DQo+ID4gDQo+ID4gVGhhbmtzLCBJdGFsbw0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiA+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gW21h aWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9obiBF DQo+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgODowMCBQTQ0KPiA+ID4gVG86 IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gPiA+IENjOiBtcGxzLXRw QGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCj4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gDQo+ID4g PiBBdCB0aGUgbWVldGluZyBsYXN0IGZhbGwgYXQgSnVuaXBlciBpbiBNYXNzYWNodXNldHRzLCBJ DQo+ID4gdGhpbmsgaXQgd2FzDQo+ID4gPiBhZ3JlZWQgdGhhdCBhbiBNUExTIFRQIG5ldHdvcmsg bmVlZHMgdG8gaGF2ZSBhIGZvcndhcmRpbmcNCj4gPiBjYXBhYmlsaXR5DQo+ID4gPiBmb3IgbWFu YWdlbWVudCwgY29udHJvbCwgYW5kIE9BTSBwYWNrZXRzIChlLmcuLCBzZW5kaW5nDQo+ID4gcmVw bGllcyB0byBPQU0NCj4gPiA+IHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMp IGV2ZW4gaWYgaXQgZG9lcyBub3QNCj4gPiBoYXZlIGFuIElQDQo+ID4gPiBmb3J3YXJkaW5nIGRh dGEgcGxhbmUuDQo+ID4gPiANCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+ID4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gPiA+IFttYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAx NiwgMjAwOSA5OjU3IEFNDQo+ID4gPiA+IFRvOiBNYWFydGVuIFZpc3NlcnMNCj4gPiA+ID4gQ2M6 IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0K PiA+ID4gPiANCj4gPiA+ID4gTWFhcnRlbiwNCj4gPiA+ID4gSXQgc2VlbXMgdGhhdCB5b3UndmUg anVzdCAoaW1wbGljaXRseSBhbmQsIHByb2JhYmx5LA0KPiA+ID4gPiBpbmFkdmVydGVudGx5KSBz dGF0ZWQgdGhlIGZvbGxvd2luZzoNCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAg TVBMUy1UUCBPQU0gd2lsbCBub3QgZXZlciBzdXBwb3J0IE1JUCBsb29wYmFjayANCmZ1bmN0aW9u DQo+ID4gKGFuZCBmYXVsdA0KPiA+ID4gPiBsb2NhbGl6YXRpb24gd2hpY2ggcmVxdWlyZXMgdGhp cyBmdW5jdGlvbiApIGZvcg0KPiA+IHVuaWRpcmVjdGlvbmFsIFAyTVANCj4gPiA+ID4gYW5kIFAy UCBwYXRocy4NCj4gPiA+ID4gDQo+ID4gPiA+IElmIHRoaXMgc3RhdGVtZW50IGlzIGNvcnJlY3Qs IHRoaXMgKElNSE8gYW5kIEZXSVcpDQo+IHJhaXNlcyBhIHZhbGlkDQo+ID4gPiA+IHF1ZXN0aW9u Og0KPiA+ID4gPiANCj4gPiA+ID4gICAgICAgICAgICAgICAgICBJcyBNUExTLVRQIGFuIGFwcHJv cHJpYXRlIHNvbHV0aW9uIGZvciB0aGVzZQ0KPiB0eXBlcyBvZiB0cmFuc3BvcnQNCj4gPiA+ID4g cGF0aHM/DQo+ID4gPiA+IA0KPiA+ID4gPiBGb3IgdGhlIHJlZmVyZW5jZSwgSVAvTVBMUyBwcm92 aWRlcyB0aGlzIGtpbmQgb2YNCj4gPiBmdW5jdGlvbmFsaXR5IHRvZGF5DQo+ID4gPiA+IGZvciAo dW5pZGlyZWN0aW9uYWwgLSBidXQgaXQgZG9lcyBub3Qga25vdyBhbnkgb3RoZXINCj4gPiB0eXBl KSBQMlAgTFNQcw0KPiA+ID4gPiBhcyBkZXNjcmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0 ZW5zaW9uIHRvIFAyTVAgTFNQcyBzZWVtcyANCj4gPiA+ID4gZWFzeS4uLg0KPiA+ID4gPiANCj4g PiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiANCj4gPiA+ID4gICAg ICBTYXNoYQ0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEZyb206IG1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0KPiA+IE9uIEJlaGFsZg0K PiA+ID4gPiBPZiBNYWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXQ0K PiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzoyNCBQTQ0KPiA+ID4gPiBU bzogJ0FkcmlhbiBGYXJyZWwnDQo+ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+ IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCBwYXRoIA0KPiA+ID4gPiByZXF1aXJlbWVudHMNCj4gPiA+ID4gDQo+ID4gPiA+IEFkcmlhbiwN Cj4gPiA+ID4gDQo+ID4gPiA+ID4+IDxxdW90ZT4NCj4gPiA+ID4gPj4gICAgICBUaGUgaW50ZXJt ZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQNCj4gPiA+ID4gb3RoZXIgaW50 ZXJuYWwNCj4gPiA+ID4gPj4gICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNv LXJvdXRlZA0KPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPiA+ID4gPiA+PiAgICAg ICBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0K PiA+ID4gPiA+PiAgICAgICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNr d2FyZA0KPiA+ID4gPiBkaXJlY3Rpb25zIG9mIHRoYXQNCj4gPiA+ID4gPj4gICAgICAgdHJhbnNw b3J0IHBhdGguDQo+ID4gPiA+ID4+IDxlbmQgcXVvdGU+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBU aGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCj4g PiA+IGlzLCB0aGVyZSBpcw0KPiA+ID4gPiA+ICpub3RoaW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZl ZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mDQo+ID4gPiB2aWV3IHRoYXQNCj4gPiA+ID4gPiBy ZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC4NCj4gPiA+ID4gDQo+ID4g PiA+IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gSXQgaXMgdmVyeSBtdWNoDQo+ IG9ic2VydmFibGUgaWYNCj4gPiA+ID4gdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgZnJvbSBhIGJs YWNrIGJveCBwb2ludCBvZiB2aWV3Lg0KPiA+ID4gPiBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25s eSBwZXJmb3JtIHRoZSBMb29wYmFjayB3aGVuIHRoZXJlIGlzIGEgDQo+ID4gPiA+IGNvLXJvdXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoLiBUaGUgTVBMUy1UUCBMQk0gcGFja2V0IA0K PiA+ID4gPiByZWNlaXZlZCBhdCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5lZCAoYXMgTEJSDQo+ ID4gPiA+IHBhY2tldCkgdG8gdGhlIG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhlIG90 aGVyDQo+ID4gZGlyZWN0aW9uIG9mDQo+ID4gPiA+IHRoZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQgcGF0aC4gVGhpcyBvdGhlcg0KPiBkaXJlY3Rpb24NCj4gPiA+ID4gd291bGQg bm90IGJlIGF2YWlsYWJsZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0 IA0KPiA+ID4gPiBwYXRoLi4uIGFuZCB0aHVzIHRoZSBsb29wYmFjayB0ZXN0DQo+ID4gPiB3b3Vs ZCBmYWlsLg0KPiA+ID4gPiANCj4gPiA+ID4gU2ltaWxhcmx5LCB3aGVuIHdlIGhhdmUgdG8gYXBw bHkgVENNIE1FUHMgdG8gbW9uaXRvciBhDQo+ID4gc2VnbWVudCwgdGhlbg0KPiA+ID4gPiB0aGlz IGlzIHBvc3NpYmxlIGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoDQo+IGJ1dCBu b3QgaW4gYQ0KPiA+ID4gPiBhc3NvY2lhdGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoLiBJbiB0aGUg Zmlyc3QgY2FzZSB0aGUgVENNIE1FUCANCj4gPiA+ID4gU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9u cyBhcmUgY28tbG9jYXRlZCBhbmQgY2FuDQo+IGV4Y2hhbmdlIHdoYXQgaXMNCj4gPiA+ID4gY2Fs bGVkICJyZW1vdGUgaW5mb3JtYXRpb24iIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgcGVyZm9ybWFu Y2UgDQo+ID4gPiA+IG1vbml0b3JpbmcuDQo+ID4gPiA+IEluIHRoZSBsYXR0ZXIgY2FzZSB0aGUg VENNIE1FUCBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zDQo+ID4gYXJlIGluIGUuZy4gDQo+ID4g PiA+IGRpZmZlcmVudCBub2RlcyBpbiB0aGUgbmV0d29yayBhbmQgVENNIHdvdWxkIG5vdCBiZSBh YmxlDQo+ID4gdG8gcHJvdmlkZQ0KPiA+ID4gPiBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLg0KPiA+ ID4gPiANCj4gPiA+ID4gPiBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGlu Y2x1ZGluZyBNRVBzLA0KPiA+ID4gTUlQcyBhbmQgb3RoZXINCj4gPiA+ID4gaW50ZXJuYWwNCj4g PiA+ID4gPiBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4gSXQg ZG9lcyBub3QNCj4gPiA+ID4gYWRkIHRvICJUaGUNCj4gPiA+ID4gPiBpbnRlcm1lZGlhdGUgbm9k ZXMuIg0KPiA+ID4gPiANCj4gPiA+ID4gWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBjb3JyZWN0 LiBUaGlzIHRleHQgbXVzdCBub3QgYmUNCj4gPiBkZWxldGVkIGF0DQo+ID4gPiA+IGFsbC4NCj4g PiA+ID4gDQo+ID4gPiA+ID4gQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMg cGVyc2lzdGVudA0KPiA+ID4gaW5zaXN0ZW5jZSBvbiB0aGUNCj4gPiA+ID4gaW5jbHVzaW9uDQo+ ID4gPiA+ID4gb2YgIlRhbmRlbSBDb25uZWN0aW9uLiIgVGhlIGRlZmluaXRpb24gd2l0aGluIHRo ZSBJVFUtVCBvZg0KPiA+ID4gPiB0aGlzIHRlcm0NCj4gPiA+ID4gPiBpcw0KPiA+ID4gPiBwb29y bHkNCj4gPiA+ID4gPiBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1vbml0b3Jpbmcgb2Yg YSBwYXRoIHRoYXQgaXMNCj4gPiA+ID4gcGFyYWxsZWwgKGkuZS4NCj4gPiA+ID4gdGFuZGVtKQ0K PiA+ID4gPiA+IHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRp b24gb2YgVEMNCj4gPiA+ID4gc2VlbXMgdG8gYmUgYXQNCj4gPiA+ID4gdmFyaWFuY2UsDQo+ID4g PiA+ID4gYW5kIHdvdWxkIGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQo+ID4g PiA+IA0KPiA+ID4gPiBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRhdGlv biBvZiB0YW5kZW0NCj4gPiBjb25uZWN0aW9uIGlzDQo+ID4gPiA+IGRlc2NyaWJlZCBpbiBJVFUt VCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gImZyb20gdGhlDQo+ID4gbW9uaXRvcmluZyBvZiBhDQo+ ID4gPiA+IHBhdGggdGhhdCBpcyBwYXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBh dGggYmVpbmcgDQo+ID4gPiA+IG1vbml0b3JlZC4iPw0KPiA+ID4gPiANCj4gPiA+ID4gVGhlcmUg aXMgYSAibmV0d29yayBjb25uZWN0aW9uIiBhbmQgdGhpcyBuZXR3b3JrDQo+ID4gY29ubmVjdGlv biBpcyBhIHNldA0KPiA+ID4gPiBvZiBpbnRlcmNvbm5lY3RlZCAibGluayBjb25uZWN0aW9ucyIg YW5kICJtYXRyaXgNCj4gY29ubmVjdGlvbnMiLiBBDQo+ID4gPiA+IHN1YnNldCBvZiB0aG9zZSBp bnRlcmNvbm5lY3RlZCBsaW5rIGNvbm5lY3Rpb25zIGFuZCBtYXRyaXggDQo+ID4gPiA+IGNvbm5l Y3Rpb25zIGNhbiBiZSBtb25pdG9yZWQgYW5kIGlzIHRoZW4gcmVmZXJyZWQgdG8gYXMNCj4gYSAi dGFuZGVtDQo+ID4gPiA+IGNvbm5lY3Rpb24iLiBUaGVyZSBpcyBubyAicGF0aCB0aGF0IGlzIHBh cmFsbGVsIHRvIHRoZQ0KPiA+IGRhdGEgcGF0aCIuIA0KPiA+ID4gPiBUaGVyZSBpcyBvbmx5IGFk ZGl0aW9uYWwgT0FNIGluc2VydGVkIGluc2lkZSB0aGUgZGF0YQ0KPiBwYXRoIGJ5IHRoZQ0KPiA+ ID4gPiBUQ00gTUVQX1NvIGZ1bmN0aW9uIGFuZCB0aGlzIE9BTSBpcyBleHRyYWN0ZWQgZnJvbSB0 aGUNCj4gPiBkYXRhIHBhdGggYnkNCj4gPiA+ID4gdGhlIFRDTSBNRVBfU2sgZnVuY3Rpb24uDQo+ ID4gPiA+IA0KPiA+ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiBNYWFydGVuDQo+ID4gPiA+IA0KPiA+ ID4gPiANCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTog bXBscy10cC1ib3VuY2VzQGlldGYub3JnDQo+ID4gPiA+IFttYWlsdG86bXBscy10cC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiA+ID4gPiBTZW50OiBkb25k ZXJkYWcgMTYgYXByaWwgMjAwOSAxMTo1OQ0KPiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRl aW47IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tDQo+ID4gPiA+IENjOiBCVVNJIElUQUxP OyBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KPiA+ID4gPiByZXF1aXJlbWVudHMN Cj4gPiA+ID4gDQo+ID4gPiA+IEhpIFNhc2hhLA0KPiA+ID4gPiANCj4gPiA+ID4gPiBVbmZvcnR1 bmF0ZWx5IEkgY2Fubm90IGZ1bGx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQ6DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiA8cXVvdGU+DQo+ID4gPiA+ID4gICAgIEZyb20gdGhlIHBvaW50IG9mIHZp ZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZA0KPiA+ID4gYmlkaXJlY3Rpb25hbCBMU1BzDQo+ID4g PiA+ID4gICAgIGFyZSBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg TFNQcy4NCj4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBz dGF0ZW1lbnQgd291bGQgYmUgb2J2aW91c2x5IGNvcnJlY3QsIHdlcmUgaXQgbm90IGZvcg0KPiA+ ID4gPiBSZXF1aXJlbWVudA0KPiA+ID4gPiA+IDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCByZXF1 aXJlbWVudHMgZHJhZnQNCj4gPiA+ID4gDQo+ID4gPiA+IE9LLiBHb3QgaXQuDQo+ID4gPiA+IA0K PiA+ID4gPiBCdXQgd2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVt ZW50cyBzZWN0aW9uPw0KPiA+ID4gPiANCj4gPiA+ID4gSW4gZmFjdCwgd2hhdCBpcyB0aGlzIHJl cXVpcmVtZW50IGFjdHVhbGx5IHNheWluZz8NCj4gPiA+ID4gDQo+ID4gPiA+ID4gPHF1b3RlPg0K PiA+ID4gPiA+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1J UHMgYW5kDQo+ID4gPiBvdGhlciBpbnRlcm5hbA0KPiA+ID4gPiA+ICAgICAgIGZ1bmN0aW9ucyBh cyBhcHByb3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQNCj4gPiA+ID4gYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQNCj4gPiA+ID4gPiAgICAgICBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBh d2FyZSBvZiB0aGUgcGFpcmluZw0KPiA+ID4gPiA+ICAgICAgIHJlbGF0aW9uc2hpcCBvZiB0aGUg Zm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkDQo+ID4gPiA+IGRpcmVjdGlvbnMgb2YgdGhhdA0KPiA+ ID4gPiA+ICAgICAgIHRyYW5zcG9ydCBwYXRoLg0KPiA+ID4gPiA+IDxlbmQgcXVvdGU+DQo+ID4g PiA+IA0KPiA+ID4gPiBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWly ZW1lbnQuIFRoYXQNCj4gPiBpcywgdGhlcmUgaXMNCj4gPiA+ID4gKm5vdGhpbmcqIHRoYXQgY2Fu IGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCj4gPiB2aWV3IHRoYXQNCj4g PiA+ID4gcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuDQo+ID4gPiA+ IA0KPiA+ID4gPiBUaGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0aGF0IHRoaXMgcmVxdWly ZW1lbnQgaXMgbWV0IGJ5IA0KPiA+ID4gPiBjb25maWd1cmluZyBzb21lIGRhdGEgcGxhbmUgZGF0 YWJhc2UgY29tcG9uZW50IHRocm91Z2ggdGhlIA0KPiA+ID4gPiBtYW5hZ2VtZW50IHBsYW5lLiBU aGUgZGF0YWJhc2UgY29tcG9uZW50IGlzIG5vdCB1c2VkDQo+IGZvciBhbnl0aGluZw0KPiA+ID4g PiBleGNlcHQgdG8gc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAiYXdhcmVuZXNzIi4NCj4g PiA+ID4gDQo+ID4gPiA+IEJlbiEgQ2FuIHdlIHBsZWFzZSB0cnkgdG8gcmV3cml0ZSB0aGlzIHJl cXVpcmVtZW50IGluIHRlcm1zIG9mIA0KPiA+ID4gPiBiZWhhdmlvcj8NCj4gPiA+ID4gDQo+ID4g PiA+ID4gUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGlu IHRoZQ0KPiA+ID4gPiBsaXN0IHRoYXQgaXMNCj4gPiA+ID4gPiBzcGVjaWZpYyBmb3IgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBwYWlyaW5nDQo+ID4gPiA+IHJlcXVpcmVtZW50 cw0KPiA+ID4gPiA+IGF0IGVuZCBwb2ludHMgZm9yIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsDQo+ID4gPiBwYXRocyBhcmUNCj4gPiA+ID4gPiBleGFjdGx5IHRoZSBzYW1l IGV2ZW4gaWYgdGhleSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudA0KPiA+ID4gaXRlbXMgaW4gdGhl DQo+ID4gPiA+ID4gcmVxdWlyZW1lbnRzJyBsaXN0KS4NCj4gPiA+ID4gPiBJbiBvdGhlciB3b3Jk cywgd2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mDQo+IGNvLXJvdXRlZA0KPiA+ ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFu ZSBjb250ZW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3Bl IG9mIHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbCANCj4gPiA+ID4gPiBmdW5jdGlv bnMgYXMgYXBwcm9wcmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcNCj4gPiA+ID4g c3VwcG9ydCBvZiB0aGUNCj4gPiA+ID4gPiBwYWlyaW5nIGF3YXJlbmVzcyBtYXkgYmUgcmVxdWly ZWQgaW4gb3JkZXIgdG8gY29tcGx5IHdpdGggaXQuDQo+ID4gPiA+IA0KPiA+ID4gPiBUaGUgZW50 aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBzLA0KPiA+IE1JUHMg YW5kIG90aGVyDQo+ID4gPiA+IGludGVybmFsIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkiIHNo b3VsZCBiZSBkZWxldGVkLiBJdA0KPiA+IGRvZXMgbm90DQo+ID4gPiA+IGFkZCB0byAiVGhlIGlu dGVybWVkaWF0ZSBub2Rlcy4iDQo+ID4gPiA+IA0KPiA+ID4gPiA+IFRoZSBmb2xsb3dpbmcgdGV4 dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gPHF1b3RlPg0KPiA+ID4gPiA+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVtIGNv bm5lY3Rpb24gaXMgYW4NCj4gPiBhcmJpdHJhcnkgcGFydCBvZiBhDQo+ID4gPiA+ID4gICB0cmFu c3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pDQo+ID4gPiA+IGluZGVw ZW5kZW50bHkgZnJvbSB0aGUNCj4gPiA+ID4gPiAgIGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FN KS4gIEl0IG1heSBiZSBhIG1vbml0b3JlZA0KPiA+IHNlZ21lbnQgb3IgYQ0KPiA+ID4gPiA+ICAg bW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguIA0KPiA+ IFRoZSB0YW5kZW0NCj4gPiA+ID4gPiAgIGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0aGUg Zm9yd2FyZGluZyBlbmdpbmUocykgb2YNCj4gPiA+ID4gdGhlIG5vZGUocykNCj4gPiA+ID4gPiAg IGF0IHRoZSBlZGdlKHMpIG9mIHRoZSBzZWdtZW50IG9yIGNvbmNhdGVuYXRlZCBzZWdtZW50Lg0K PiA+ID4gPiA+IDxlbmQgcXVvdGU+DQo+ID4gPiA+IA0KPiA+ID4gPiBBY3R1YWxseSwgSSBhbSBx dWl0ZSBmZWQgdXAgYWJvdXQgdGhpcyBwZXJzaXN0ZW50DQo+ID4gaW5zaXN0ZW5jZSBvbiB0aGUN Cj4gPiA+ID4gaW5jbHVzaW9uIG9mICJUYW5kZW0gQ29ubmVjdGlvbi4iIFRoZSBkZWZpbml0aW9u IHdpdGhpbg0KPiA+IHRoZSBJVFUtVCBvZg0KPiA+ID4gPiB0aGlzIHRlcm0gaXMgcG9vcmx5IHNw ZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUNCj4gbW9uaXRvcmluZyBvZiBhDQo+ID4gPiA+IHBh dGggdGhhdCBpcyBwYXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBhdGggYmVpbmcg DQo+ID4gPiA+IG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRDIHNlZW1zIHRvIGJlIGF0 IHZhcmlhbmNlLA0KPiA+IGFuZCB3b3VsZA0KPiA+ID4gPiBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1 YWxseSBpbiBiYW5kLg0KPiA+ID4gPiANCj4gPiA+ID4gPiBEb2Vzbid0ICJmb3J3YXJkaW5nIGVu Z2luZSIgc291bmQgbGlrZSBoYXJkd2FyZSB0byB5b3U/DQo+ID4gPiA+IA0KPiA+ID4gPiBZZXMs IGJ1dCBzbyB3aGF0Pw0KPiA+ID4gPiANCj4gPiA+ID4gPiBJTUhPIGl0IGlzIHdvcnRoIG5vdGlu ZyB0aGF0IG5laXRoZXIgdGhlIE1QTFMtVFANCj4gPiA+IFJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ ID4gPiA+IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZQ0KPiA+ID4gPiA+IA0K PiA+ID4gPiANCj4gPiA+IA0KPiA+IA0KPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1yZXF1aXJlbWVuDQo+ID4gPiA+ID4gdHMtMDEu dHh0KSBjb250YWluIGFueSByZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoIHRhbmRlbQ0KPiA+ID4g Y29ubmVjdGlvbnMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCdXQgdGFuZGVtIGNvbm5lY3Rpb25z IGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNDQo+ID4gRnJhbWV3b3JrDQo+ID4gPiA+ ID4gZHJhZnQNCj4gPiA+ID4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtbXBscy10cC1vYW0tZnINCj4gPiA+ID4gYW1ld29yay0wMC50eHQNCj4gPiA+ID4g KS4NCj4gPiA+ID4gDQo+ID4gPiA+IFJpZ2h0Lg0KPiA+ID4gPiBMZXQncyBqdXN0IGdldCByaWQg b2YgYW4gdW5uZWNlc3NhcnkgdGVybSBhbmQgYnJpbmcgYWxsDQo+IHRoZSBJLURzDQo+ID4gPiA+ IGludG8gbGluZS4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gVGhlIGJvdHRvbSBsaW5lLCBJTUhPLCBp cyB0aGF0IHNvbWUgY2xhcml0eSByZWdhcmRpbmcNCj4gPiA+IGNvLXJvdXRlZCB2cy4NCj4gPiA+ ID4gPiBhc3NvY2lhdGVkDQo+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCBy ZXF1aXJlZC4gT25lIHdheSB0byBwcm92aWRlDQo+ID4gPiA+IHRoYXQgY291bGQNCj4gPiA+ID4g PiBiZSBieSBleHBsaWNpdGx5IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNwZWNpZmljDQo+ ID4gPiBmdW5jdGlvbmFsaXR5Lg0KPiA+ID4gPiANCj4gPiA+ID4gQWdyZWVkLg0KPiA+ID4gPiAN Cj4gPiA+ID4gQWRyaWFuDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IA0K PiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ IEZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdDQo+ID4gPiA+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTQ0KPiA+ID4gPiBUbzogQWxleGFuZGVy IFZhaW5zaHRlaW47IExvdSBCZXJnZXI7IEJVU0kgSVRBTE8NCj4gPiA+ID4gQ2M6IG1wbHMtdHBA aWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiAN Cj4gPiA+ID4gSGkgU2FzaGEsDQo+ID4gPiA+IA0KPiA+ID4gPiBOb3QgcmVhbGx5IHN1cmUgd2hl dGhlciB5b3UgYXJlIG1pc3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLg0KPiA+ID4gPiANCj4g PiA+ID4gPiAxLiBNeSByZWFkaW5nIG9mICBvbmUgb2YgQmVuJ3MgIG1lc3NhZ2VzIGlzIHRoYXQg YXNzb2NpYXRlZCANCj4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0 eXBlcyBvZiBwYXRocyB0aGF0IGNhbiBiZQ0KPiA+ID4gPiBjcmVhdGVkIGluDQo+ID4gPiA+ID4g dGhlIGV4aXN0aW5nIG5ldHdvcmtzOyAidHJ1ZSIgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgcGF0 aHMNCj4gPiA+ID4gd2lsbCBoYXZlDQo+ID4gPiA+ID4gdG8gd2FpdCB1bnRpbCAoaWYgZXZlcikg bmV3IGVxdWlwbWVudCBiZWNvbWVzIGF2YWlsYWJsZS4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoaXMg aXMgY2xlYXJseSBub25zZW5zZSENCj4gPiA+ID4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBo YXJkd2FyZSwgY28tcm91dGVkDQo+ID4gYmlkaXJlY3Rpb25hbCBMU1BzIGFyZQ0KPiA+ID4gPiBh IHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4gPiA+ID4g DQo+ID4gPiA+IElmIHlvdSBjYW4gc2V0IHVwIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzIChlLmcu IHVzaW5nIHRoZQ0KPiA+IG1hbmFnZW1lbnQNCj4gPiA+ID4gcGxhbmUpIHlvdSBjYW4gc3VyZWx5 IHNldCB1cCBhIGNvLXJvdXRlZA0KPiA+ID4gYmlkaXJlY3Rpb25hbCBMU1AuDQo+ID4gPiA+IA0K PiA+ID4gPiBUaGVyZSBhcmUgc2hpcHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0 ZWQNCj4gYmlkaXJlY3Rpb25hbA0KPiA+ID4gPiBMU1BzIHVzaW5nIHRoZSBjb250cm9sIHBsYW5l LiBUaGVzZSBlaXRoZXIgdXNlIHRoZSBHTVBMUw0KPiA+ICh3aGljaCBpcw0KPiA+ID4gPiBjbGVh bmVyKSBvciBub24tc3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpcw0KPiA+ IG1lc3N5IGJ1dA0KPiA+ID4gPiBmdW5jdGlvbmFsKS4NCj4gPiA+ID4gDQo+ID4gPiA+IEJ1dCAo b2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lDQo+ID4gc29s dXRpb25zIGhhdmUNCj4gPiA+ID4gbm90aGluZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBl cXVpcG1lbnQgYXMgdGhleQ0KPiBhcmUgc29mdHdhcmUNCj4gPiA+ID4gc29sdXRpb25zLg0KPiA+ ID4gPiANCj4gPiA+ID4gPiAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMg aXMgdGhhdCB0aGUgYWN0dWFsDQo+ID4gPiA+IGRyaXZlciBmb3INCj4gPiA+ID4gPiBjby1yb3V0 ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIA0K PiA+ID4gPiA+IHRyYW5zcG9ydCBuZXR3b3JrcyByYXRoZXIgdGhhbiBhbnkgc3BlY2lmaWMgYmVu ZWZpdC4NCj4gPiA+ID4gDQo+ID4gPiA+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2Yg dGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPw0KPiA+ID4gPiBXaGljaCBpcyBub3QgdG8gc2F5IGl0 IGlzIGEgYmFkIHRoaW5nLg0KPiA+ID4gPiANCj4gPiA+ID4gQSBsYXJnZSBkcml2ZXIgZm9yIE1Q TFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsNCj4gPiB0aGUgbG9vaywNCj4gPiA+ ID4gZmVlbCwgYW5kIGJlaGF2aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgImxlZ2FjeSINCj4g PiA+ID4gdHJhbnNwb3J0IG5ldHdvcmsuDQo+ID4gPiA+IA0KPiA+ID4gPiA+IEJhc2VkIG9uIHRo ZXNlIG9ic2VydmF0aW9ucywgSSdkIGd1ZXNzIChGV0lXKSB0aGF0Og0KPiA+ID4gPiA+ICogYXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSwgYXQgbGVhc3QgZm9yIHRoZSB0aW1lDQo+ ID4gPiA+ID4gICAgYmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mIGJpZGlyZWN0aW9u YWwgcGF0aHMgaW4NCj4gPiA+ID4gPiAgICBNUExTLVRQDQo+ID4gPiA+IA0KPiA+ID4gPiBJIHRo aW5rIHRoYXQgaXMgd3JvbmcgYm90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZA0KPiA+ IGdpdmVuIHRoYXQNCj4gPiA+ID4gb3RoZXIgdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1 dGlvbnMgd2lsbCBiZQ0KPiBuZWVkZWQgdG8gcmVhY2gNCj4gPiA+ID4gdGhlIGZ1bGwgZnVuY3Rp b24gbGV2ZWwgb2YgTVBMUy1UUC4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gKiB0aGV5IGhhZCBhIGdv b2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBlIG9mDQo+ID4gYmlkaXJlY3Rpb25hbA0K PiA+ID4gPiA+ICAgcGF0aHMgaW4gIHJlYWwgZGVwbG95bWVudHMuDQo+ID4gPiA+IA0KPiA+ID4g PiBJIGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93cyBmcm9tLg0KPiA+ID4gPiANCj4gPiA+ID4g Q2hlZXJzLA0KPiA+ID4gPiBBZHJpYW4NCj4gPiA+ID4gDQo+ID4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IG1wbHMtdHAgbWFpbGlu ZyBsaXN0DQo+ID4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ID4gPiA+IA0KPiA+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBtcGxzLXRw IG1haWxpbmcgbGlzdA0KPiA+ID4gPiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiA+ID4gPiANCj4gPiA+ID4g DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiA+ID4gDQo+ ID4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+IA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxz LXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMt dHANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gc3lzdGVtLg0K --=_alternative 000B18B74825759F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5EZWJvcmFoPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwO21heWJlIHdoYXQgeW91IHNhaWQgaXMgcmlnaHQuDQpidXQgSSBjYW4ndCBjb21w bGV0ZWx5IGFncmVlIHlvdXIgb3BpbmlvbnMuIElNTy4gbXBscy10cCBpcyByZWdhcmQgYXMgdHJh bnNwb3J0DQpuZXR3b3JrIGxpa2UgU0RIL1NPTkVULiBzbyBpdCBzaG91bGQgaGF2ZSBBSVMvRkRJ IGZ1Y3Rpb25zIGFzIFNESC9TT05FVC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmRvIHlvdSB0aGluayBzby48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJlc3QgcmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bGl1IDwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtCUlVOR0FSRCwgREVCT1JBSA0KQSwgQVRU TEFCUyZxdW90OyAmbHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBscy10cC1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDkt MDQtMjAgMjM6NDc8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7TWFhcnRlbiBWaXNzZXJzJnF1b3Q7ICZsdDttYWFydGVuLnZpc3Nl cnNAaHVhd2VpLmNvbSZndDssDQombHQ7bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZndDs8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPm1wbHMtdHBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbbXBs cy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQp0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVu dHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+ PHR0PkkgYWdyZWUgd2l0aCBOZWlsLCBpdCBpcyB2ZXJ5IHF1ZXN0aW9uYWJsZSB0aGUgdmFsdWUN Cm9mIEFJUy9GREkgaW4gYTxicj4NCnBhY2tldCBuZXR3b3JrLSBhbnkgbW9kZS4gSXQgY2FuIHJl c3VsdCBpbiBhIERvUyBhdHRhY2sgYnkgYW4gb3BlcmF0b3I8YnI+DQpvbiB0aGVtc2VsdmVzIHNv IGV2ZW4gWTE3MzEgcmVjb21tZW5kcyBub3QgdG8gYmxvY2sgZGF0YSBmcmFtZXM6PGJyPg0KJnF1 b3Q7QSBNRVAgY2FuIGRlY2lkZSB3aGV0aGVyIGl0IGJsb2NrcyBkYXRhIGZyYW1lcyB3aGVuIGl0 IGRldGVjdHMgZEFJUy48YnI+DQpUaGUgcHJpbmNpcGxlIHJlcXVpcmVtZW50PGJyPg0KdGhhdCBp bmZsdWVuY2VzIHRoaXMgZGVjaXNpb24gaXMgdGhhdCBkYXRhIGZyYW1lcyBvdWdodCB0byBiZSBm b3J3YXJkZWQ8YnI+DQphcyBtdWNoIGFzIHBvc3NpYmxlLCB3aXRob3V0PGJyPg0KdGhlIHBvc3Np YmlsaXR5IG9mIGZvcndhcmRpbmcgd3JvbmcgZGF0YSBmcmFtZXMgZG93bnN0cmVhbS4mcXVvdDs8 YnI+DQpUYWJsZSBJLjctMiBzaG93cyBmb3IgQUlTLCBub3QgdG8gYmxvY2suPGJyPg0KPGJyPg0K QW5kIGFzIFkxNzMxIHN0YXRlcywgQUlTIGNhbiBvbmx5IGJlIHVzZWQgdW5kZXIgdmVyeSBjb25z dHJhaW5lZDxicj4NCmFyY2hpdGVjdHVyZXMgLSBpZiByZXF1aXJlZCBmb3IgTVBMUy1UUCwgaXQg bmVlZHMgdG8gaGF2ZSB0aGUgc2FtZTxicj4NCmd1aWRhbmNlIGFzIGluIFkxNzMxLCBpLmUuIHBv aW50LXRvLXBvaW50IGFuZCBzZXJ2ZXIvY2xpZW50IG9uZS10by1vbmU6PGJyPg0KJnF1b3Q7Zm9y IGEgcG9pbnQtdG8tcG9pbnQgRVRIIGNvbm5lY3Rpb24sIGEgTUVQIGhhcyBvbmx5IGEgc2luZ2xl IHBlZXINCk1FUC48YnI+DQpUaGVyZWZvcmUsIHRoZXJlPGJyPg0KaXMgbm8gYW1iaWd1aXR5IHJl Z2FyZGluZyB0aGUgcGVlciBNRVAgZm9yIHdoaWNoIGl0IHNob3VsZCBzdXBwcmVzczxicj4NCmFs YXJtcyB3aGVuIGl0IHJlY2VpdmVzIHRoZTxicj4NCkVUSC1BSVMgaW5mb3JtYXRpb24uJnF1b3Q7 PGJyPg0KU28gc2hvdWxkIG9ubHkgYmUgd2l0aGluIG9uZSBkb21haW4gLSB0aGVuIG5vIG5lZWQu PGJyPg0KPGJyPg0KRGVib3JhaDxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3Vu Y2VzQGlldGYub3JnXSBPbjxicj4NCkJlaGFsZiBPZiBNYWFydGVuIFZpc3NlcnM8YnI+DQpTZW50 OiBNb25kYXksIEFwcmlsIDIwLCAyMDA5IDEwOjA1IEFNPGJyPg0KVG86IG5laWwuMi5oYXJyaXNv bkBidC5jb208YnI+DQpDYzogbXBscy10cEBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFJlOiBbbXBs cy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoPGJyPg0KcmVxdWly ZW1lbnRzPGJyPg0KPGJyPg0KTmVpbCw8YnI+DQo8YnI+DQomZ3Q7IGJ1dCBBSVMvRkRJIGluIHRo ZSBjbCBtb2RlPy4uLmRvIG1lIGEgZmF2b3VyITxicj4NCjxicj4NCkV0aGVybmV0IEFJUyBpcyBp bmRlZWQgYSByZXF1aXJlbWVudCBhbmQgYSBuZWNlc3NpdHkuIEFuZCB5b3Ugd2lsbCBub3Q8YnI+ DQpiZTxicj4NCmFibGUgdG8gdW5kZXJzdGFuZCB0aGF0IGFzIGxvbmcgYXMgeW91IHJlZnVzZSB0 byBhY2NlcHQgdGhhdCAmcXVvdDtjbC1tb2RlJnF1b3Q7PGJyPg0KaXMgYTxicj4NCmZvcndhcmRp bmcgbW9kZSB3aXRoaW4gYSAqKnRyYW5zcG9ydCBlbnRpdHkqKi4gRy44MDAgYW1lbmRtZW50IDEg aGFzPGJyPg0KZmluYWxseTxicj4NCnJlaW50cm9kdWNlZCB0aGlzIHRyYW5zcG9ydCBlbnRpdHkg aW50byBHLjgwMC4gQmVzaWRlcyB0aGF0LCBpdCBhbHNvPGJyPg0KaW50cm9kdWNlZCB0aGUgKipk aWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uKio6PGJyPg0KPGJyPg0KW0cuODAwIGFtMV0gJnF1b3Q7 QSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIGlzIGEgdHJhbnNwb3J0IGVudGl0eSB0aGF0PGJy Pg0KdHJhbnNmZXJzIGluZm9ybWF0aW9uIGJlbG9uZ2luZyB0byBtdWx0aXBsZSBjb21tdW5pY2F0 aW9ucyBiZXR3ZWVuIHBvcnRzPGJyPg0KYWNyb3NzIGEgc3VibmV0d29yay4gJmx0Oy4uJmd0OyBJ biBhIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24gbWVzc2FnZTxicj4NCmNvbnRlbnRzPGJyPg0K YXJlIGludGVycHJldGVkIHRvIGlkZW50aWZ5IChzZXRzIG9mKSBjb21tdW5pY2F0aW9ucyB3aGlj aCByZWNlaXZlPGJyPg0KZGlmZmVyZW50PGJyPg0KdHJlYXRtZW50LiAmbmJzcDtUaGUgc2V0cyBv ZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgZGlzdGluZ3Vpc2hlZCBieSB0aGU8YnI+DQpmb3J3YXJk aW5nIGlkZW50aWZpZXIgb3Igb3RoZXIgbGF5ZXIgaW5mb3JtYXRpb24uICZuYnNwO09yZGVyIGlz IG5vdDxicj4NCm5lY2Vzc2FyaWx5PGJyPg0KcHJlc2VydmVkIGJldHdlZW4gbWVzc2FnZXMgYmVs b25naW5nIHRvIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgcmVjZWl2aW5nPGJyPg0KZGlmZmVyZW50 IHRyZWF0bWVudC4gJm5ic3A7U2V0cyBvZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgaWRlbnRpZmll ZCBmb3I8YnI+DQpwdXJwb3Nlczxicj4NCnN1Y2ggYXMgdHJhZmZpYyBjb25kaXRpb25pbmcgb3Ig cHJlc2VydmluZyBjb21tdW5pY2F0aW9uIG1lc3NhZ2Ugb3JkZXIuJnF1b3Q7PGJyPg0KPGJyPg0K PGJyPg0KRXRoZXJuZXQgVkxBTnMgYXJlIGluIHRlcm1zIG9mIEcuODAwICZxdW90O2RpZmZlcmVu dGlhdGVkIGNvbm5lY3Rpb25zJnF1b3Q7Ljxicj4NCkV0aGVybmV0PGJyPg0KQUlTIHByb3ZpZGVz IEFJUyB3aXRoaW4gdGhlIHNjb3BlIG9mIHN1Y2ggJnF1b3Q7ZGlmZmVyZW50aWF0ZWQgY29ubmVj dGlvbiZxdW90Oy48YnI+DQpJZjxicj4NCnlvdSBhcHBseSB0aGlzIHRvIG15IHByb3Bvc2VkIFBU TiBsYXllciBzdGFjaywgdGhlbiB0aGUgRVZDIGxheWVyPGJyPg0KdG9wb2xvZ3k8YnI+DQp3aWxs IGNvbnNpc3RzIG9mIEVWQyBsaW5rcyBzdXBwb3J0ZWQgYnkgTVBMUy1UUCwgRXRoZXJuZXQsIFBC Qi1URSBhbmQ8YnI+DQpQLU9UTjxicj4NClZQIHRyYWlscyBpbnNpZGUgbWV0cm8gYW5kIGNvcmUg ZG9tYWlucyBpbnRlcmNvbm5lY3RpbmcgRVZDIG1hdHJpY2VzLjxicj4NCldoZW48YnI+DQpvbmUg b2YgdGhvc2UgRVZDIGxpbmtzIGlzIGludGVycnVwdGVkLCBlLmcuIGluIHRoZSBjb3JlIGJldHdl ZW4gbWV0cm8gMTxicj4NCmFuZDxicj4NCm1ldHJvIDQgKHNlZSBhdHRhY2hlZCBzbGlkZSksIHRo ZW4gdGhlIEVWQyBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uPGJyPg0KdGhhdCBpczxicj4NCnBy ZXNlbnQgb24gdGhpcyBsaW5rIHdpbGwgYmUgaW50ZXJydXB0ZWQuIEF0IHRoZSBFVkMgc3dpdGNo L2JyaWRnZSBub2RlPGJyPg0KaW48YnI+DQptZXRybyA0IHRoaXMgaW50ZXJydXB0aW9uIGlzIG5v dGljZWQgYW5kIEVWQy1BSVMgaXMgaW5zZXJ0ZWQgaW4gdGhlPGJyPg0KZG93bnN0cmVhbSBkaXJl Y3Rpb24gdG8gc3VwcHJlc3MgdGhlIEVWQy1MT0MgYWxhcm1zIGF0IEVWQyBlbmRwb2ludHMgRDQ8 YnI+DQphbmQ8YnI+DQpENS48YnI+DQo8YnI+DQpUaGUgRVZDLUFJUyAoaS5lLiBFdGhlcm5ldCBB SVMpIGZyYW1lIGhhcyBhIHJlc2VydmVkIG11bHRpY2FzdCBhZGRyZXNzLDxicj4NCndoaWNoIGd1 YXJhbnRlZXMgdGhhdCB0aGUgQUlTIGlzIGJyb2FkY2FzdCB0byB0aGUgZW5kcG9pbnRzIG9mIHRo ZSBFVkMuPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHRoYXQgaXQgaXMgdGltZSBmb3IgeW91IHRvIGFk YXB0IHlvdXIgdmlldyBvbiBjbyBhbmQgY2wgbW9kZXM8YnI+DQphbmQ8YnI+DQpyZWxhdGUgaXQg dG8gdGhlIGZvcndhcmRpbmcgbW9kZSAqKklOU0lERSoqIGEgdHJhbnNwb3J0IGVudGl0eS4gPGJy Pg0KPGJyPg0KV2hhdCB3ZSBrbm93IGFzIHRoZSBpbnRlcm5ldCBpcyBlc3NlbnRpYWxseSBhbiAm cXVvdDtJUCBkaWZmZXJlbnRpYXRlZDxicj4NCmNvbm5lY3Rpb24mcXVvdDsgd2l0aCBhIGJpbGxp b24gb3IgbW9yZSBwb3J0cy48YnI+DQpXaGF0IHdlIGtub3cgYXMgYW4gSVAgVlBOIGlzIGVzc2Vu dGlhbGx5IGFuICZxdW90O0lQIGRpZmZlcmVudGlhdGVkPGJyPg0KY29ubmVjdGlvbiZxdW90Ozxi cj4NCndpdGggZS5nLiBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCku PGJyPg0KV2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMgZXNzZW50aWFsbHkgYW4g JnF1b3Q7RXRoZXJuZXQ8YnI+DQpkaWZmZXJlbnRpYXRlZDxicj4NCmNvbm5lY3Rpb24mcXVvdDsg d2l0aCBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuPGJyPg0KV2hh dCB3ZSBrbm93IGFzIGEgcDJwIE1QTFMgRS1MU1AgaXMgZXNzZW50aWFsbHkgYW4gJnF1b3Q7TVBM UyBkaWZmZXJlbnRpYXRlZDxicj4NCmNvbm5lY3Rpb24mcXVvdDsgd2l0aCAyIHBvcnRzLjxicj4N CldoYXQgd2Uga25vdyBhcyBhIHAycCBTREggVkMtbiBpcyBhICZxdW90O1NESCBWQy1uIGNvbm5l Y3Rpb24mcXVvdDsgd2l0aA0KMiBwb3J0cy48YnI+DQo8YnI+DQpUcmFuc3BvcnQgbmV0d29yayBP QU0gYXBwbGllcyB0byB0cmFuc3BvcnQgZW50aXRpZXMsIHdoaWNoIGFyZSAoaW4gdGVybXM8YnI+ DQpvZjxicj4NCkcuODAwIGFtMSkgY29ubmVjdGlvbnMgYW5kIGRpZmZlcmVudGlhdGVkIGNvbm5l Y3Rpb25zLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KTWFhcnRlbjxicj4NCjxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbmVpbC4yLmhhcnJpc29uQGJ0LmNvbSBb bWFpbHRvOm5laWwuMi5oYXJyaXNvbkBidC5jb21dIDxicj4NClNlbnQ6IHZyaWpkYWcgMTcgYXBy aWwgMjAwOSAyMjowMDxicj4NClRvOiBKb2huLkUuRHJha2UyQGJvZWluZy5jb207IEl0YWxvLkJ1 c2lAYWxjYXRlbC1sdWNlbnQuaXQ7PGJyPg0KQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b207IG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPGJyPg0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8 YnI+DQpTdWJqZWN0OiBSRTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aDxicj4NCnJlcXVpcmVtZW50czxicj4NCjxicj4NCkpvaG4sICZuYnNwO1RoYW5r cyB0aGlzIGlzIGEgZ3JlYXQgcGxhdGZvcm0gdG8gZXhwbGFpbiB3aHkgT0FNIGZvciB0aGUNCjM8 YnI+DQpuZXR3b3JrPGJyPg0KbW9kZXMgbmVlZHMgdG8gYmUgZGlmZmVyZW50LiAmbmJzcDtJIGFt IGdldHRpbmcgYSB3ZWUgYml0IHRpcmVkIG9mIGZvbGtzPGJyPg0KdHJ5aW5nPGJyPg0KdG8gbWFr ZSBhbGwgMyBuZXR3b3JrIG1vZGVzIGxvb2sgYWxpa2UgKGFuZCB0aGVuLCBldmVuIHdvcnNlLCBp bnRlcndvcms8YnI+DQp0aGVtPGJyPg0KYXMgYXMgcGVlcnMuLi5lc3Agd2hlbiBub3Qgbm90IHRv cC1vZi1zdGFjazxicj4NCm5ldHdvcmtzLi4uSSBtZWFuIGhvdyBzaWxseSBjYW4gd2UgZ2V0Pyku ICZuYnNwOyBJIGFtIGV2ZW4gbW9yZSBmcnVzdHJhdGVkDQpieTxicj4NCnRoZSBmYWN0IHRob3Nl IHBlZGRsaW5nIHRoaXMgRlVEIG9ubHkgZXZlciBzZWVtIHRvIGNvbnNpZGVyIE9BTSBhbmQ8YnI+ DQpmb3JnZXQ8YnI+DQphbGwgb3RoZXIgRFAvQ1AvTVAgY29tcG9uZW50cyAoZXNwIHRvcC1vZi1z dGFjayBtZXNzYWdlL2ZpbGUvc3RyZWFtPGJyPg0KYXBwbGljYXRpb24gYWRhcHRhdGlvbnMpLiAm bmJzcDtIb3cgd3JvbmcgY2FuIHRoaXMgZ2V0ISA8YnI+DQo8YnI+DQpJbiB0aGUgY28gbW9kZXMg YSAqY29ubmVjdGlvbiogaXMgYSB2ZXJ5IHNwZWNpZmljIGFuZCAqY29uc3RyYWluaW5nKjxicj4N CmNvbnN0cnVjdC4uLi4uSSBhbSBhc3N1bWluZyBoZXJlIHdlIHJlc3BlY3QgdGhlIHJ1bGVzIG9m IGEgY29ubmVjdGlvbjxicj4NCihpZTxicj4NCnNpbmdsZSBzb3VyY2UpIHRob3VnaCBzb21lIGZv bGtzIGRvbid0IGV2ZW4gYm90aGVyIHRvIHJlc3BlY3QgdGhpcywgYW5kPGJyPg0KdGhpczxicj4N CmlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBhbGwga25vdyB3aGF0IHByb2JsZW1zIG11bHRp cGxlLXNvdXJjZTxicj4NCmNvbnN0cnVjdHMgY2FuIGNhdXNlIChmcm9tIExEUC9QSFAuLi4uZXJn byBNUExTLVRQKS48YnI+DQo8YnI+DQpXaGVuIHdlIGhhdmUgYSBjb25uZWN0aW9uIHRoaXMgcmVz dHJpY3RzICphbGwqIERQIChpZSB0cmFmZmljIGFuZCBPQU0pPGJyPg0KdG88YnI+DQpzdGF5IHdp dGhpbiB0aGUgYm91bmRzIG9mIHRoZSBjb25uZWN0aW9uLiAmbmJzcDtXaGljaCBpcyBmaW5lIHVu ZGVyPGJyPg0KZGVmZWN0LWZyZWU8YnI+DQpjb25kaXRpb25zLCBidXQgaWYgd2UgaGF2ZSBsZWFr aW5nIHRyYWZmaWMgdGhlbiB0aGUgY29uc3RyYWluaW5nIG5hdHVyZTxicj4NCm9mPGJyPg0KdGhl IGNvbm5lY3Rpb24gY29uc3RydWN0IGlzIGJyb2tlbi4gJm5ic3A7SW4gYSBudXRzaGVsbCB3aGF0 IHRoaXMgbWVhbnMNCmlzPGJyPg0KdGhhdDxicj4NCk9BTSB0aGF0IGlzIG9mIGEgcmVxdWVzdC9y ZXNwb25zZSBuYXR1cmUgY2Fubm90IGJlIHRydXN0ZWQgaW4gY28gbW9kZTxicj4NCm5ldHdvcmtz IHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3RzLi4uLi5pbmRlZWQsIHdoeSBzaG91bGQgYSBs ZWFraW5nPGJyPg0KRFA8YnI+DQpoYXZlIGEgc3ltbWV0cmljIGdvL3JldHVybiBkZWZlY3QgYmVo YXZpb3VyPy4uLi52ZXJ5IGxpa2VseSBpdCB3b24ndC48YnI+DQpTbzxicj4NCndoaWxzdCByZXF1 ZXN0L3Jlc3BvbnNlIE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1vZGUgaXQgaXMgbm90IHJpZ2h0 IGZvcjxicj4NCnRoZTxicj4NCmNvIG1vZGUgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCBj b25kaXRpb25zLjxicj4NCjxicj4NCk1vcmUgZ2VuZXJhbGx5IHRoZSAzIG1vZGVzIGFyZSBkaWZm ZXJlbnQgYW5kIG5vdCBqdXN0IGluIE9BTTxicj4NCnJlcXVpcmVtZW50cy4uLi5idXQgQUlTL0ZE SSBpbiB0aGUgY2wgbW9kZT8uLi5kbyBtZSBhIGZhdm91ciEuLi5hdCBsZWFzdDxicj4NCklFRUUg aGFkIHRoZSBnb29kIHNlbnNlIHRvIGJpbiB0aGlzIGZvciBFdGhlcm5ldCBldmVuIHRob3VnaCBp dCByZW1haW5zPGJyPg0KaW48YnI+DQpZLjE3MzEuICZuYnNwO0FuZCB3aGljaCBpcyB3aHkgSSBv ZnRlbiB0cm90LW91dCB0aGUgcmF0aGVyIHNpbGx5ICh0byBoYXZlDQp0bzxicj4NCnNheTxicj4N CnRoaXMpIG9ic2VydmF0aW9uIHRoYXQgaWYgSVAgKGNsIG1vZGUpIGNvdWxkIGRvIGl0IGFsbCB0 aGVuIHdoeSBoYXZlPGJyPg0KSUVURjxicj4NCmZvdW5kIGl0IG5lY2Vzc2FyeSB0byBjcmVhdGUg TVBMUyAoY28tcHMpIGFuZCBHTVBMUyAoQ1AgZm9yIGNvLWNzKS4gJm5ic3A7VGhlPGJyPg0KYW5z d2VyIGxpZXMgaW4gdGhlIHBoeXNpY3MuLi5hbmQgRy44MDAgYXR0ZW1wdHMgdG8gZXhwbGFpbiB0 aGF0PGJyPg0KcGh5c2ljcy4uLi5HLjgwNSBkb2VzIG5vdC48YnI+DQo8YnI+DQpTbywgdGhlIDMg bW9kZXMgYXJlIGRpZmZlcmVudC4uLnBsZWFzZSBhY2NlcHQvcmVqb2ljZSBpbiB0aGlzIGZhY3Qg YXM8YnI+DQp0aGV5PGJyPg0KYWxsIG9mZmVyIHNvbWV0aGluZyBkaWZmZXJlbnQvaW1wb3J0YW50 LiAmbmJzcDtCdXQgZG8gbm90IGJlIGhvb2R3aW5rZWQNCmJ5PGJyPg0KdGhvc2U8YnI+DQp3aG8g cGVkZGxlIGEgc3RvcnkgdGhhdCB0aGF0IHRyaWVzIHRvIG1ha2UgdGhlIE9BTSBvZiB0aGUgMyBt b2RlcyB0aGU8YnI+DQpzYW1lLiA8YnI+DQo8YnI+DQpyZWdhcmRzLCBOZWlsIDxicj4NCjxicj4N CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IG1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9obiBFPGJyPg0KJmd0OyBTZW50OiAxNyBBcHJpbCAy MDA5IDIwOjAyPGJyPg0KJmd0OyBUbzogQlVTSSBJVEFMTzsgQWxleGFuZGVyIFZhaW5zaHRlaW47 IE1hYXJ0ZW4gVmlzc2Vyczxicj4NCiZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCBwYXRoIDxicj4NCiZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0YWxv LDxicj4NCiZndDsgPGJyPg0KJmd0OyBBcyBkZXNjcmliZWQgaW4gdGhlIE1QTFMgVFAgT0FNIFJl cXVpcmVtZW50cyBJLUQsIHZpcnR1YWxseSBhbGwgb2YNCnRoZTxicj4NCjxicj4NCiZndDsgT0FN IGZ1bmN0aW9ucyByZXF1aXJlIGEgcmV0dXJuIHBhdGgsIGFuZCBpbiB0aGUgYWJzZW5jZSBvZiBh IHJldHVybg0KPGJyPg0KJmd0OyBwYXRoIHRoZXkgYXJlIGRpc2FibGVkLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBBcyBkZXNjcmliZWQgaW4gRGF2aWQgU2luaWNyb3BlJ3MgbWVldGluZyBtaW51dGVz IDxicj4NCiZndDsgKGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL21pc2MvbXBscy1pbnRlcm9w L2F0dGFjaG1lbnQvd2lraS88YnI+DQomZ3Q7IG1lZXRpbmctbm88YnI+DQomZ3Q7IHRlcy8yMDA4 MTAxNS5tcGxzLWludGVyb3AtZHQtbm90ZXMuemlwKSwgaWYgSVAgYWRkcmVzc2luZyBpcyB1c2Vk LA0KYW4gPGJyPg0KJmd0OyBNUExTIFRQIG5ldHdvcmsgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBn ZXR0aW5nIElQIHBhY2tldHMgZnJvbSA8YnI+DQomZ3Q7IGRlc3RpbmF0aW9uIHRvIHNvdXJjZTsg bmVpdGhlciB0aGUgbWludXRlcyBub3IgSSBzdGlwdWxhdGUgdGhhdCBhDQo8YnI+DQomZ3Q7IGNv bnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byBpbnN0YW50aWF0ZSB0aGlzIGZvcndhcmRp bmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFzIGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgcmV0dXJu IHBhdGggZm9yIHVuaWRpcmVjdGlvbmFsIExTUHMgY291bGQNCmJlPGJyPg0KPGJyPg0KJmd0OyBj aGFyYXRlcml6ZWQgYXMgdGhlIGVsZXBoYW50IGluIHRoZSByb29tLiAmbmJzcDtJbiB0aGUgTVBM UyBUUCBPQU0NCjxicj4NCiZndDsgRnJhbWV3b3JrIEktRCwgdW5pY2FzdCBMU1BzIGFyZSBvbmx5 IG1lbnRpb25lZCB0aHJlZSB0aW1lcyBhbmQgcmV0dXJuDQo8YnI+DQomZ3Q7IHBhdGhzIG5vdCBh dCBhbGwuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsg Sm9objxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsg Jmd0OyBGcm9tOiBCVVNJIElUQUxPIFttYWlsdG86SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5p dF08YnI+DQomZ3Q7ICZndDsgU2VudDogRnJpZGF5LCBBcHJpbCAxNywgMjAwOSAxOjU5IEFNPGJy Pg0KJmd0OyAmZ3Q7IFRvOiBEcmFrZSwgSm9obiBFOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFh cnRlbiBWaXNzZXJzPGJyPg0KJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0 OyAmZ3Q7IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoDQo8YnI+DQomZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBKb2huLDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBt aWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVtZW50IG9mIE1QTFMtVFAgYmVpbmcgY2FwYWJsZSBv Zg0KPGJyPg0KJmd0OyAmZ3Q7IHNlbmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2VudCBv biB1bmktZGlyZWN0aW9uYWwgTFNQcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRo aXMgcmVxdWlyZW1lbnQgZG9lcyBub3QgYmVsb25nIHRvIHRoZSBmaXJzdCBzZXQgb2YgcmVxdWly ZW1lbnRzDQo8YnI+DQomZ3Q7ICZndDsgSVRVLVQgaXMgZXhwZWN0aW5nIHRvIGJlIG1ldCBieSBP Y3RvYmVyLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSG93ZXZlciwgSSB0aGluayB0 aGlzIGluIGEgcG90ZW50aWFsIGludGVyZXN0aW5nIGFkZGl0aW9uYWwgPGJyPg0KJmd0OyAmZ3Q7 IHJlcXVpcmVtZW50IHRvIGJlIHRha2VuIGludG8gYWNjb3VudCAoYXQgd29yc3QgaW4gYTxicj4N CiZndDsgc3Vic2VxdWVudCBwaGFzZSkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJ IHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVudCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVyc3Vz IG90aGVyDQo8YnI+DQomZ3Q7ICZndDsgbW9yZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIChlLmcu IHRoZSBwb3NzaWJpbGl0eSB0byB3b3JrIHcvbw0KSVAgPGJyPg0KJmd0OyAmZ3Q7IGZvcndhcmRp bmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8gY29udGludWUgdG8gbW9uaXRvciB0aGUgZGF0YQ0K PGJyPg0KJmd0OyAmZ3Q7IHBsYW5lIGFsc28gaW4gY2FzZSBvZiBmYWlsdXJlcyBhZmZlY3Rpbmcg dGhlIGNvbnRyb2wgb3IgbWFuYWdlbWVudA0KPGJyPg0KJmd0OyAmZ3Q7IHBsYW5lKS48YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgYW0gb3BlbiB0byBkaXNjdXNzIGl0IGJ1dCBub3Qg c3VyZSB0aGlzIGlzIHRoZSByaWdodCB0aW1lIGJlY2F1c2UNCjxicj4NCiZndDsgJmd0OyBJIHdp c2ggdG8gYXZvaWQgZGVsYXlpbmcgdGhlIGZpcnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24gc29sdXRp b24uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MsIEl0YWxvPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBEcmFrZSwgSm9obg0KRTxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJp bCAxNiwgMjAwOSA4OjAwIFBNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVG86IEFsZXhhbmRlciBWYWlu c2h0ZWluOyBNYWFydGVuIFZpc3NlcnM8YnI+DQomZ3Q7ICZndDsgJmd0OyBDYzogbXBscy10cEBp ZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KcGF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBy ZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBdCB0 aGUgbWVldGluZyBsYXN0IGZhbGwgYXQgSnVuaXBlciBpbiBNYXNzYWNodXNldHRzLCBJPGJyPg0K Jmd0OyAmZ3Q7IHRoaW5rIGl0IHdhczxicj4NCiZndDsgJmd0OyAmZ3Q7IGFncmVlZCB0aGF0IGFu IE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBoYXZlIGEgZm9yd2FyZGluZzxicj4NCiZndDsgJmd0 OyBjYXBhYmlsaXR5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZm9yIG1hbmFnZW1lbnQsIGNvbnRyb2ws IGFuZCBPQU0gcGFja2V0cyAoZS5nLiwgc2VuZGluZzxicj4NCiZndDsgJmd0OyByZXBsaWVzIHRv IE9BTTxicj4NCiZndDsgJmd0OyAmZ3Q7IHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFs IExTUHMpIGV2ZW4gaWYgaXQgZG9lcyBub3Q8YnI+DQomZ3Q7ICZndDsgaGF2ZSBhbiBJUDxicj4N CiZndDsgJmd0OyAmZ3Q7IGZvcndhcmRpbmcgZGF0YSBwbGFuZS48YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbjxicj4NCiZn dDsgJmd0OyAmZ3Q7IFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgOTo1 NyBBTTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVG86IE1hYXJ0ZW4gVmlzc2Vyczxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydA0KcGF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBNYWFydGVuLDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSXQgc2VlbXMgdGhhdCB5b3UndmUganVzdCAoaW1wbGlj aXRseSBhbmQsIHByb2JhYmx5LDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5hZHZlcnRlbnRs eSkgc3RhdGVkIHRoZSBmb2xsb3dpbmc6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO01QTFMtVFAgT0FNIHdpbGwgbm90IGV2ZXIgc3VwcG9y dCBNSVAgbG9vcGJhY2sgZnVuY3Rpb248YnI+DQomZ3Q7ICZndDsgKGFuZCBmYXVsdDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgbG9jYWxpemF0aW9uIHdoaWNoIHJlcXVpcmVzIHRoaXMgZnVuY3Rp b24gKSBmb3I8YnI+DQomZ3Q7ICZndDsgdW5pZGlyZWN0aW9uYWwgUDJNUDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgYW5kIFAyUCBwYXRocy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYgdGhpcyBzdGF0ZW1lbnQgaXMgY29ycmVjdCwgdGhpcyAo SU1ITyBhbmQgRldJVyk8YnI+DQomZ3Q7IHJhaXNlcyBhIHZhbGlkPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBxdWVzdGlvbjo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7SXMgTVBMUy1UUCBhbiBhcHByb3ByaWF0ZSBzb2x1dGlvbiBmb3Ig dGhlc2U8YnI+DQomZ3Q7IHR5cGVzIG9mIHRyYW5zcG9ydDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgcGF0aHM/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IEZvciB0aGUgcmVmZXJlbmNlLCBJUC9NUExTIHByb3ZpZGVzIHRoaXMga2luZCBvZjxicj4N CiZndDsgJmd0OyBmdW5jdGlvbmFsaXR5IHRvZGF5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBm b3IgKHVuaWRpcmVjdGlvbmFsIC0gYnV0IGl0IGRvZXMgbm90IGtub3cgYW55IG90aGVyPGJyPg0K Jmd0OyAmZ3Q7IHR5cGUpIFAyUCBMU1BzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhcyBkZXNj cmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0ZW5zaW9uIHRvIFAyTVANCkxTUHMgc2VlbXMg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBlYXN5Li4uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Nhc2hh PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBG cm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ108 YnI+DQomZ3Q7ICZndDsgT24gQmVoYWxmPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPZiBNYWFy dGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDM6MjQgUE08YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IFRvOiAnQWRyaWFuIEZhcnJlbCc8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0 OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCnBhdGgg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRyaWFuLDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbHQ7cXVvdGUmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Ro ZSBpbnRlcm1lZGlhdGUgbm9kZXMNCihpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQ8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IG90aGVyIGludGVybmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpDQpv ZiBhIGNvLXJvdXRlZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHBhdGggYXQgZWFjaCAoc3ViLSlsYXllcg0KTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmlu Zzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg cmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkDQphbmQgdGhlIGJhY2t3YXJkPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCBwYXRoLjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmx0O2VuZCBxdW90ZSZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8g d2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50Lg0KVGhhdDxicj4NCiZndDsgJmd0 OyAmZ3Q7IGlzLCB0aGVyZSBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqbm90aGlu ZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveA0KcG9pbnQgb2Y8YnI+DQom Z3Q7ICZndDsgJmd0OyB2aWV3IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVz dWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBu b3QgY29ycmVjdC4gSXQgaXMgdmVyeSBtdWNoPGJyPg0KJmd0OyBvYnNlcnZhYmxlIGlmPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBmcm9tIGEgYmxhY2sg Ym94IHBvaW50IG9mIHZpZXcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgTUlQIGZ1bmN0 aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBMb29wYmFjayB3aGVuDQp0aGVyZSBpcyBhIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGguIFRoZSBNUExTLVRQDQpMQk0gcGFja2V0IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVj ZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUgcmV0dXJuZWQgKGFzIExCUjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgcGFja2V0KSB0byB0aGUgb3JpZ2luYXRpbmcgTUVQIGZ1bmN0aW9uIHZpYSB0 aGUgb3RoZXI8YnI+DQomZ3Q7ICZndDsgZGlyZWN0aW9uIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyB0aGUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoaXMgb3Ro ZXI8YnI+DQomZ3Q7IGRpcmVjdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgd291bGQgbm90 IGJlIGF2YWlsYWJsZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhdGguLi4gYW5kIHRodXMgdGhlIGxvb3BiYWNrIHRl c3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyB3b3VsZCBmYWlsLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTaW1pbGFybHksIHdoZW4gd2UgaGF2ZSB0byBh cHBseSBUQ00gTUVQcyB0byBtb25pdG9yDQphPGJyPg0KJmd0OyAmZ3Q7IHNlZ21lbnQsIHRoZW48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgaXMgcG9zc2libGUgaW4gYSBjby1yb3V0ZWQg YmlkaXIgdHJhbnNwb3J0IHBhdGg8YnI+DQomZ3Q7IGJ1dCBub3QgaW4gYTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgYXNzb2NpYXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aC4gSW4gdGhlIGZpcnN0 IGNhc2UNCnRoZSBUQ00gTUVQIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU291cmNlIGFuZCBT aW5rIGZ1bmN0aW9ucyBhcmUgY28tbG9jYXRlZCBhbmQgY2FuPGJyPg0KJmd0OyBleGNoYW5nZSB3 aGF0IGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjYWxsZWQgJnF1b3Q7cmVtb3RlIGluZm9y bWF0aW9uJnF1b3Q7IHdoaWNoIGlzIG5lY2Vzc2FyeQ0KZm9yIHBlcmZvcm1hbmNlIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgbW9uaXRvcmluZy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IElu IHRoZSBsYXR0ZXIgY2FzZSB0aGUgVENNIE1FUCBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zPGJy Pg0KJmd0OyAmZ3Q7IGFyZSBpbiBlLmcuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZGlmZmVy ZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIGFuZCBUQ00gd291bGQgbm90IGJlDQphYmxlPGJyPg0K Jmd0OyAmZ3Q7IHRvIHByb3ZpZGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBlcmZvcm1hbmNl IG1vbml0b3JpbmcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgVGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgJnF1b3Q7KGlu Y2x1ZGluZw0KTUVQcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBNSVBzIGFuZCBvdGhlcjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgaW50ZXJuYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg ZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSZxdW90OyBzaG91bGQgYmUgZGVsZXRlZC4NCkl0IGRv ZXMgbm90PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhZGQgdG8gJnF1b3Q7VGhlPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGludGVybWVkaWF0ZSBub2Rlcy4mcXVvdDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgWW91ciB1bmRlcnN0YW5k aW5nIGlzIG5vdCBjb3JyZWN0LiBUaGlzIHRleHQgbXVzdCBub3QNCmJlPGJyPg0KJmd0OyAmZ3Q7 IGRlbGV0ZWQgYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFsbC48YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSBhbSBx dWl0ZSBmZWQgdXAgYWJvdXQgdGhpcyBwZXJzaXN0ZW50PGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW5z aXN0ZW5jZSBvbiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluY2x1c2lvbjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBvZiAmcXVvdDtUYW5kZW0gQ29ubmVjdGlvbi4mcXVvdDsg VGhlIGRlZmluaXRpb24NCndpdGhpbiB0aGUgSVRVLVQgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IHRoaXMgdGVybTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpczxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgcG9vcmx5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNwZWNp ZmllZCBhbmQgY29tZXMgZnJvbSB0aGUgbW9uaXRvcmluZyBvZiBhIHBhdGgNCnRoYXQgaXM8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhcmFsbGVsIChpLmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyB0YW5kZW0pPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRvIHRoZSBkYXRhIHBh dGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24NCm9mIFRDPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBzZWVtcyB0byBiZSBhdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdmFyaWFu Y2UsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNI IHdhcyBhY3R1YWxseSBpbiBiYW5kLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRh dGlvbiBvZiB0YW5kZW08YnI+DQomZ3Q7ICZndDsgY29ubmVjdGlvbiBpczxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgZGVzY3JpYmVkIGluIElUVS1UIHJlY29tbWVuZGF0aW9ucy4gSS5lLiAmcXVv dDtmcm9tDQp0aGU8YnI+DQomZ3Q7ICZndDsgbW9uaXRvcmluZyBvZiBhPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0 YSBwYXRoDQpiZWluZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JlZC4mcXVvdDs/ PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJl IGlzIGEgJnF1b3Q7bmV0d29yayBjb25uZWN0aW9uJnF1b3Q7IGFuZCB0aGlzDQpuZXR3b3JrPGJy Pg0KJmd0OyAmZ3Q7IGNvbm5lY3Rpb24gaXMgYSBzZXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IG9mIGludGVyY29ubmVjdGVkICZxdW90O2xpbmsgY29ubmVjdGlvbnMmcXVvdDsgYW5kDQomcXVv dDttYXRyaXg8YnI+DQomZ3Q7IGNvbm5lY3Rpb25zJnF1b3Q7LiBBPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBzdWJzZXQgb2YgdGhvc2UgaW50ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBh bmQNCm1hdHJpeCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvbm5lY3Rpb25zIGNhbiBiZSBt b25pdG9yZWQgYW5kIGlzIHRoZW4gcmVmZXJyZWQgdG8NCmFzPGJyPg0KJmd0OyBhICZxdW90O3Rh bmRlbTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY29ubmVjdGlvbiZxdW90Oy4gVGhlcmUgaXMg bm8gJnF1b3Q7cGF0aCB0aGF0IGlzIHBhcmFsbGVsDQp0byB0aGU8YnI+DQomZ3Q7ICZndDsgZGF0 YSBwYXRoJnF1b3Q7LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG9ubHkgYWRk aXRpb25hbCBPQU0gaW5zZXJ0ZWQgaW5zaWRlIHRoZSBkYXRhPGJyPg0KJmd0OyBwYXRoIGJ5IHRo ZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVENNIE1FUF9TbyBmdW5jdGlvbiBhbmQgdGhpcyBP QU0gaXMgZXh0cmFjdGVkIGZyb20NCnRoZTxicj4NCiZndDsgJmd0OyBkYXRhIHBhdGggYnk8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBUQ00gTUVQX1NrIGZ1bmN0aW9uLjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgTWFhcnRlbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tOiBtcGxzLXRwLWJv dW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFttYWlsdG86bXBscy10cC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuDQpGYXJyZWw8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IFNlbnQ6IGRvbmRlcmRhZyAxNiBhcHJpbCAyMDA5IDExOjU5PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGJlbmphbWluLm5pdmVu LWplbmtpbnNAYnQuY29tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYzogQlVTSSBJVEFMTzsg bXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpIFNhc2hhLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFVuZm9ydHVuYXRlbHkgSSBjYW5ub3Qg ZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudDo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEZyb20gdGhlIHBvaW50IG9mIHZp ZXcgb2YgaGFyZHdhcmUsDQpjby1yb3V0ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlv bmFsIExTUHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBhcmUg YSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZA0KYmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIHN0YXRlbWVu dCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZQ0KaXQgbm90IGZvcjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgUmVxdWlyZW1lbnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg MzQgaW4gdGhlIGxhdGVzdCBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPSy4gR290IGl0Ljxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBCdXQgd2hhdCBpcyB0 aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cw0Kc2VjdGlvbj88YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gZmFjdCwgd2hh dCBpcyB0aGlzIHJlcXVpcmVtZW50IGFjdHVhbGx5IHNheWluZz88YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIGludGVybWVk aWF0ZSBub2RlcyAoaW5jbHVkaW5nDQpNRVBzLCBNSVBzIGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7 IG90aGVyIGludGVybmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkNCm9mIGEgY28tcm91dGVkPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwYXRoIGF0IGVhY2ggKHN1Yi0p bGF5ZXINCk1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJk DQphbmQgdGhlIGJhY2t3YXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9m IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg dHJhbnNwb3J0IHBhdGguPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgcXVv dGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdDxi cj4NCiZndDsgJmd0OyBpcywgdGhlcmUgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICpub3Ro aW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50DQpvZjxicj4N CiZndDsgJmd0OyB2aWV3IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlc3VsdHMgZnJv bSBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0 aGF0IHRoaXMgcmVxdWlyZW1lbnQNCmlzIG1ldCBieSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGNvbmZpZ3VyaW5nIHNvbWUgZGF0YSBwbGFuZSBkYXRhYmFzZSBjb21wb25lbnQgdGhyb3VnaA0K dGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbWFuYWdlbWVudCBwbGFuZS4gVGhlIGRhdGFi YXNlIGNvbXBvbmVudCBpcyBub3QgdXNlZDxicj4NCiZndDsgZm9yIGFueXRoaW5nPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBleGNlcHQgdG8gc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAm cXVvdDthd2FyZW5lc3MmcXVvdDsuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IEJlbiEgQ2FuIHdlIHBsZWFzZSB0cnkgdG8gcmV3cml0ZSB0aGlzIHJl cXVpcmVtZW50DQppbiB0ZXJtcyBvZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlaGF2aW9y Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFBsZWFzZSBub3RlIHRoYXQgUmVxdWlyZW1lbnQgMzQgaXMgdGhlIE9OTFkgaXRlbQ0KaW4gdGhl PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBsaXN0IHRoYXQgaXM8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgc3BlY2lmaWMgZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChU aGUNCnBhaXJpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhdCBlbmQgcG9pbnRzIGZvciBjby1yb3V0ZWQgYW5kIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbDxicj4NCiZndDsgJmd0OyAmZ3Q7IHBhdGhzIGFyZTxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBleGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhleSBh cHBlYXIgaW4gdHdvIGRpZmZlcmVudDxicj4NCiZndDsgJmd0OyAmZ3Q7IGl0ZW1zIGluIHRoZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHMnIGxpc3QpLjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVu dCAzNCB0aGUgbm90aW9uDQpvZjxicj4NCiZndDsgY28tcm91dGVkPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0 YQ0KcGxhbmUgY29udGVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVx dWlyZW1lbnQgKCZxdW90O290aGVyDQppbnRlcm5hbCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlJnF1b3Q7KSBjcmVhdGVzIGEgc3VzcGljaW9u DQp0aGF0IEhXPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzdXBwb3J0IG9mIHRoZTxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYWlyaW5nIGF3YXJlbmVzcyBtYXkgYmUgcmVxdWlyZWQg aW4gb3JkZXIgdG8NCmNvbXBseSB3aXRoIGl0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4 dCAmcXVvdDsoaW5jbHVkaW5nDQpNRVBzLDxicj4NCiZndDsgJmd0OyBNSVBzIGFuZCBvdGhlcjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRl KSZxdW90OyBzaG91bGQgYmUNCmRlbGV0ZWQuIEl0PGJyPg0KJmd0OyAmZ3Q7IGRvZXMgbm90PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhZGQgdG8gJnF1b3Q7VGhlIGludGVybWVkaWF0ZSBub2Rl cy4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBUaGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzDQpz dXNwaWNpb246PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jm5ic3A7IFRhbmRlbSBDb25uZWN0aW9uOiBBIHRhbmRlbSBjb25uZWN0aW9uDQppcyBhbjxicj4N CiZndDsgJmd0OyBhcmJpdHJhcnkgcGFydCBvZiBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZuYnNwOyB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYQ0KT0FN KTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5kZXBlbmRlbnRseSBmcm9tIHRoZTxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgZW5kLXRvLWVuZCBtb25pdG9yaW5nIChPQU0p LiAmbmJzcDtJdCBtYXkNCmJlIGEgbW9uaXRvcmVkPGJyPg0KJmd0OyAmZ3Q7IHNlZ21lbnQgb3Ig YTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgbW9uaXRvcmVkIGNvbmNhdGVu YXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0DQpwYXRoLiAmbmJzcDs8YnI+DQomZ3Q7ICZndDsg VGhlIHRhbmRlbTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgY29ubmVjdGlv biBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nDQplbmdpbmUocykgb2Y8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IHRoZSBub2RlKHMpPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBvciBjb25jYXRlbmF0ZWQNCnNl Z21lbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFjdHVhbGx5 LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQ8YnI+DQomZ3Q7ICZndDsg aW5zaXN0ZW5jZSBvbiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluY2x1c2lvbiBvZiAm cXVvdDtUYW5kZW0gQ29ubmVjdGlvbi4mcXVvdDsgVGhlIGRlZmluaXRpb24NCndpdGhpbjxicj4N CiZndDsgJmd0OyB0aGUgSVRVLVQgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgdGVy bSBpcyBwb29ybHkgc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZTxicj4NCiZndDsgbW9uaXRv cmluZyBvZiBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRoIHRoYXQgaXMgcGFyYWxsZWwg KGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoDQpiZWluZyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRDIHNlZW1zIHRvIGJlIGF0IHZh cmlhbmNlLDxicj4NCiZndDsgJmd0OyBhbmQgd291bGQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgRG9lc24ndCAmcXVvdDtmb3J3YXJk aW5nIGVuZ2luZSZxdW90OyBzb3VuZCBsaWtlDQpoYXJkd2FyZSB0byB5b3U/PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFllcywgYnV0IHNvIHdoYXQ/ PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg SU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0aGVyIHRoZSBNUExTLVRQPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgUmVxdWlyZW1lbnRzIGRyYWZ0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IChodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVtZW48YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgdHMtMDEudHh0KSBjb250YWluIGFueSByZXF1aXJlbWVudHMgZGVh bGluZyB3aXRoDQp0YW5kZW08YnI+DQomZ3Q7ICZndDsgJmd0OyBjb25uZWN0aW9ucy48YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0 IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBNUExTLVRQDQpPQU08YnI+ DQomZ3Q7ICZndDsgRnJhbWV3b3JrPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRyYWZ0 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg YW1ld29yay0wMC50eHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICkuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJpZ2h0Ljxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgTGV0J3MganVzdCBnZXQgcmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5k IGJyaW5nDQphbGw8YnI+DQomZ3Q7IHRoZSBJLURzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBp bnRvIGxpbmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgVGhlIGJvdHRvbSBsaW5lLCBJTUhPLCBpcyB0aGF0IHNvbWUgY2xhcml0eSByZWdh cmRpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBjby1yb3V0ZWQgdnMuPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGFzc29jaWF0ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYmlk aXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdheQ0KdG8gcHJvdmlkZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhhdCBjb3VsZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBiZSBieSBleHBsaWNpdGx5IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNwZWNp ZmljPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZnVuY3Rpb25hbGl0eS48YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQWdyZWVkLjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBZHJpYW48YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgRnJvbTogQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a108YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBB TTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBMb3Ug QmVyZ2VyOyBCVVNJIElUQUxPPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYzogbXBscy10cEBp ZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IEhpIFNhc2hhLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBOb3QgcmVhbGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3Jl cHJlc2VudGluZyBhbnlvbmUsDQpidXQuLi48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAxLiBNeSByZWFkaW5nIG9mICZuYnNwO29uZSBvZiBC ZW4ncyAmbmJzcDttZXNzYWdlcw0KaXMgdGhhdCBhc3NvY2lhdGVkIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBvZiBw YXRocw0KdGhhdCBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNyZWF0ZWQgaW48YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIGV4aXN0aW5nIG5ldHdvcmtzOyAmcXVvdDt0 cnVlJnF1b3Q7IGNvLXJvdXRlZA0KYmlkaXJlY3Rpb25hbCBwYXRoczxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgd2lsbCBoYXZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRvIHdhaXQg dW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lcw0KYXZhaWxhYmxlLjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIGlzIGNsZWFy bHkgbm9uc2Vuc2UhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tIHRoZSBwb2ludCBvZiB2 aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQ8YnI+DQomZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBM U1BzIGFyZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHlvdSBjYW4gc2V0IHVwIHR3byB1bmlkaXJlY3Rpb25hbCBM U1BzIChlLmcuIHVzaW5nDQp0aGU8YnI+DQomZ3Q7ICZndDsgbWFuYWdlbWVudDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgcGxhbmUpIHlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZDxi cj4NCiZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQLjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgc2hpcHBpbmcgc29sdXRp b25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0ZWQ8YnI+DQomZ3Q7IGJpZGlyZWN0aW9uYWw8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IExTUHMgdXNpbmcgdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVp dGhlciB1c2UgdGhlDQpHTVBMUzxicj4NCiZndDsgJmd0OyAod2hpY2ggaXM8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGNsZWFuZXIpIG9yIG5vbi1zdGFuZGFyZCBwcm9wcmlldGFyeSBzb2x1dGlv bnMgKHdoaWNoDQppczxicj4NCiZndDsgJmd0OyBtZXNzeSBidXQ8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGZ1bmN0aW9uYWwpLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBCdXQgKG9mIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29u dHJvbCBwbGFuZTxicj4NCiZndDsgJmd0OyBzb2x1dGlvbnMgaGF2ZTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgbm90aGluZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMg dGhleTxicj4NCiZndDsgYXJlIHNvZnR3YXJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzb2x1 dGlvbnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAyLiBNeSByZWFkaW5nIG9mIG9uZSBv ZiBOZWlsJ3MNCm1lc3NhZ2VzIGlzIHRoYXQgdGhlIGFjdHVhbDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgZHJpdmVyIGZvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZQ0Kd2l0aCBleGlzdGluZyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdHJhbnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFu IGFueSBzcGVjaWZpYyBiZW5lZml0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBJc24ndCB0aGF0IHRoZSBjYXNlIHdpdGggNzUlIG9mIHRoZSBNUExT LVRQIHJlcXVpcmVtZW50cz88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFdoaWNoIGlzIG5vdCB0 byBzYXkgaXQgaXMgYSBiYWQgdGhpbmcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IEEgbGFyZ2UgZHJpdmVyIGZvciBNUExTLVRQIGlzIHRvIGdpdmUg dGhlIHBhY2tldCBuZXR3b3JrPGJyPg0KJmd0OyAmZ3Q7IHRoZSBsb29rLDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgZmVlbCwgYW5kIGJlaGF2aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgJnF1 b3Q7bGVnYWN5JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0cmFuc3BvcnQgbmV0d29y ay48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBCYXNlZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVzcyAoRldJVykNCnRoYXQ6PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICogYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBh dGhzIGFyZSwgYXQgbGVhc3QNCmZvciB0aGUgdGltZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7YmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mDQpiaWRp cmVjdGlvbmFsIHBhdGhzIGluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDtNUExTLVRQPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEkgdGhpbmsgdGhhdCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92 ZSwNCmFuZDxicj4NCiZndDsgJmd0OyBnaXZlbiB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBvdGhlciB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9ucyB3aWxsIGJlPGJyPg0K Jmd0OyBuZWVkZWQgdG8gcmVhY2g8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBmdWxsIGZ1 bmN0aW9uIGxldmVsIG9mIE1QTFMtVFAuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKiB0aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFp biB0aGUgb25seSB0eXBlDQpvZjxicj4NCiZndDsgJmd0OyBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBwYXRocyBpbiAmbmJzcDtyZWFsIGRlcGxveW1l bnRzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJ IGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93cyBmcm9tLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBBZHJpYW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1wbHMt dHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtcGxzLXRwQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBtcGxzLXRwIG1haWxpbmcg bGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsg Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbXBscy10cCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4NCiZndDsgPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzLXRwIG1haWxp bmcgbGlzdDxicj4NCm1wbHMtdHBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJl Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7 VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50 cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZu YnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNw O3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZu YnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4N ClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNt aXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDth bmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7 dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNw O2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmln aW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdz Jm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZu YnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0K VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2Zv ciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtB bnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 000B18B74825759F_=-- From loa@pi.nu Tue Apr 21 02:05:01 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEE63A6A01 for ; Tue, 21 Apr 2009 02:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAPiKTj6miYw for ; Tue, 21 Apr 2009 02:05:00 -0700 (PDT) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 51DE13A6980 for ; Tue, 21 Apr 2009 02:05:00 -0700 (PDT) Received: from [192.36.158.68] (wdhcp-158-68.verkstad.net [192.36.158.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 3B4BE2D88B1; Tue, 21 Apr 2009 11:06:15 +0200 (CEST) Message-ID: <49ED8C84.5070004@pi.nu> Date: Tue, 21 Apr 2009 11:06:12 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> <49EC8F69.30000@chello.nl> In-Reply-To: <49EC8F69.30000@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 09:05:01 -0000 Huub, Tom and Andy has also responded to this and basically there responses are correct, but not entirely to the point. We run a slightly modified process for MPLS-TP to allow ITU-T unprecedented possibilities to influence IETF documents. This process requires a "yes" or "no" response at this time. As the process chart in the draft-andersson-mpls-tp-process-01.txt shows a "yes" leads to a request for publication and we go back into normal IETF document processing. A "no" places the document back in the working group processes. And we need to sort out the comments that led to the "no", it is my take that if we have comments the leads to a "no" it will require at least updates that will need to be confirmed in a new working group last call. /Loa Huub van Helvoort wrote: > > Hej Loa, > > You wrote: > >> All, >> >> I'd like to comment on the current discussion on >> http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-06 . >> >> We do our best follow the the mpls-tp process as described in: >> >> http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt >> > > I agree. > >> The outstanding question we have for the ITU-T ad hoc team on >> MPLS-TP is step 13 in the figure on page 7 of that draft. We are >> asking the ad hoc Team if the draft is good enough to send to the >> IESG with a request for publication. > > However these are not new questions, the issues were raised during > the ITU-T plenary and were supposed to be resolved. > >> Please note that we are only expecting a "yes" or "no" answer to >> our question. > > I understand, but in this case it would be a conditional yes, > because, as I mentioned above, not all issues were resolved. > >> If the response is "yes" then publication will be requested, if >> the answer is "no", the document will be taken back into the >> working group process and a new version produced. >> >> That said, there is never wrong to discuss technical improvements, >> editorial issues or genereal clarifications on any draft. > > What is the purpose of discussing them when the publication has > started. Unless this is a working method accepted in the IETF. > and there is still a possibility to make technical changes/ > adjustments. > > In the ITU-T once a recommendation draft is consented (yes is > received) then the draft is pre-published. > The ITU-T editors will than bring the document in a shape > that is can be officially published, but in this stage no > technical changes can be made any more, only typographical. > > Regards, Huub. > -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From adrian@olddog.co.uk Tue Apr 21 02:08:53 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35FB83A6A72 for ; Tue, 21 Apr 2009 02:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i-moSjrbwiM for ; Tue, 21 Apr 2009 02:08:52 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 380BF3A69DE for ; Tue, 21 Apr 2009 02:08:52 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3L9A1Ef005310; Tue, 21 Apr 2009 10:10:01 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3L99ww1005270; Tue, 21 Apr 2009 10:09:59 +0100 Message-ID: <0CC61AE039C84BA687F43B010574D528@your029b8cecfe> From: "Adrian Farrel" To: "BUSI ITALO" References: <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> <6FD21B53861BF44AA90A288402036AB4021B1E19@FRVELSMBS21.ad2.ad.alcatel.com> Date: Tue, 21 Apr 2009 10:09:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 09:08:53 -0000 Italo, Well, you sent me back to look at MPLS-TP_overview-22.ppt > 3) Keep the TCM solution description, as per JWT agreement, in the > MPLS-TP OAM Framework TCM is mentioned in three ways in the slide set, as far as I can see. 1. In the context of describing the requirements 2. In reference to how solutions are achieved in TDM and Ethernet 3. In example solutions I assume it is the third of these to which you refer. I would like to remind you that the scope and objectives of the JWT was not to design solutions, but to demonstrate that a solution was achievable. There was never any commitment that the solution ideas floated in the JWT would constrain the solutions work entered into by the IETF with full input from all ITU-T participants. Indeed that would have been foolish since the JWT was operating in a hurry and was not going into technical details. If a technical solution is reached with consensus and matches what the JWT considered, that will be fine. But we must not blindly follow the JWT solutions work or use any solutions ideas in the JWT report as a prerequisite. All technical work must stand on solid technical ground. Thank you. Adrian From neil.2.harrison@bt.com Tue Apr 21 05:29:17 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D733A7018 for ; Tue, 21 Apr 2009 05:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBrAyszZq4Oq for ; Tue, 21 Apr 2009 05:29:13 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 750573A701A for ; Tue, 21 Apr 2009 05:29:12 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:30:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C27C.F2D83D8A" Date: Tue, 21 Apr 2009 13:30:55 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C04756097@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: AcnCJcNHHo+eAHyvRdGt/oqSgC/iuwAUreqg From: To: , X-OriginalArrivalTime: 21 Apr 2009 12:30:27.0437 (UTC) FILETIME=[F38961D0:01C9C27C] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:29:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C27C.F2D83D8A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGl1LA0KIA0KSWYgTVBMUy1UUCBpcyBnb2luZyB0byBiZSB0YWtlbiBzZXJpb3VzbHkgYXMgYSB0 cmFuc3BvcnQgbmV0d29yayAobGlrZSBTREgvU09ORVQpIHRoZW4gdGhlIDIga2V5IE1VU1QgSEFW RSByZXF1aXJlbWVudHMgYXJlIHRoZXNlLg0KIA0KMSAgICBQcm92aWRlIGEgdHJhbnNwYXJlbnQg Y2xpZW50L3NlcnZlciByZWxhdGlvbnNoaXAuLi53aGljaCBtZWFuczoNCi0gICAgYWxsIGNsaWVu dCBiaXRzIHRyZWF0ZWQgZXF1YWxseQ0KLSAgICBjbGllbnQgYml0IG9yZGVyaW5nIHByZXNlcnZl ZA0KLSAgICBubyBhdHRlbXB0IHRvIGluZmVyIGNsaWVudCBzeW1ib2wgKGllIHNlcXVlbmNlIG9m IGNsaWVudCBiaXRzKSBtZWFuaW5nIGFuZCBubyBhdHRlbXB0IHRvIGNoYW5nZSBjbGllbnQgc3lt Ym9scw0KLSAgICB0aGUgdHJhZmZpYyBiZWhhdmlvdXIgb2YgY2xpZW50IFggbXVzdCBub3QgaW1w YWN0IHRoZSBwZXJmb3JtYW5jZSBleHBlcmllbmNlZCBieSBjbGllbnQgWQ0KIA0KQSBrZXkgY29y b2xsYXJ5IG9mIHRoZSBhYm92ZSBpcyB0aGF0IE1QTFMtVFAgbXVzdCBvbmx5IHN1cHBvcnQgcHJv cGVyIGNvbm5lY3Rpb25zIChpZSBzaW5nbGUgc291cmNlIGNvbnN0cnVjdHMpDQogDQogDQoyICAg U2luY2UgTVBMUy1UUCBpcyBhIHRyYW5zcG9ydCBuZXR3b3JrIGl0IGlzIG5vdCBhIHRvcC1vZi1z dGFjayBuZXR3b3JrIChpZSBpdCBkb2VzIG5vdCBzdXBwb3J0IGRpcmVjdGx5IGV4dGVybmFsIG1l c3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zKS4gIE1QTFMtVFAgdGhlcmVmb3JlIGRvZXMg bm90IHJlcXVpcmUgYW4gRS1OTkkgc3BlY2lmaWNhdGlvbi4gIEEga2V5IGNvcm9sbGFyeSBvZiB0 aGlzIGlzIHRoYXQgTVBMUy1UUCB3aWxsIG5vdCBoYXZlIGFueSBwZWVyIGludGVyd29ya2luZyBy ZWxhdGlvbnNoaXAgd2l0aCBhbnkgb3RoZXIgbmV0d29yayBtb2RlL3RlY2hub2xvZ3kuDQogDQog DQpOb3cgd3J0IE9BTSBNUExTLVRQIGlzIGEgY28tcHMgbW9kZSBuZXR3b3JrLiAgWW91IGNvdWxk IGFyZ3VlIHRoaXMgc2hvdWxkIGhhdmUgRkRJL0FJUy4uLi5ob3dldmVyLCB0aGUgbWVyaXQgb2Yg dGhpcyBpcyBoaWdobHkgcXVlc3Rpb25hYmxlLiAgV2hlbiBJIGFuZCBjb2xsZWFndWVzIGRpc2N1 c3NlZCB3aGV0aGVyIFBCQi1URSAoYWxzbyBhIGNvLXBzIG1vZGUgbmV0d29yaykgc2hvdWxkIGhh dmUgRkRJL0FJUyB3ZSBjb25jbHVkZWQgdGhhdCBvbiBiYWxhbmNlIGl0IHdhcyBub3QgYSBnb29k IGlkZWEuLi4uLmFuZCBub3RlIHRoYXQgaW5pdGlhbGx5IEkgd2FzIGluIGZhdm91ciBvZiBoYXZp bmcgQUlTLCBidXQgbXkgY29sbGVhZ3VlcyBwcm92aWRlZCBzdHJvbmcgdGVjaG5pY2FsIGFyZ3Vt ZW50cyB0aGF0IGNvbnZpbmNlZCBtZSBvdGhlcndpc2UuDQogDQpBSVMvRkRJIGlzIGhpc3Rvcmlj YWxseSBsaW5rZWQgdG8gdGhlIGVhcmx5IFBESCBjby1jcyBtb2RlIGxheWVyIG5ldHdvcmtzIHRo YXQgdXNlZCBUVEwgbG9naWMuICBXaGVuIHRoaXMgZGllZCBpdCBwdXQgb3V0IGEgKzVWIChhbGwg MXMpIHNpZ25hbCBieSBkZWZhdWx0LCBpZSBpdCByZXF1aXJlZCBubyBjb25zY2lvdXMgZWZmb3J0 IHRvIGdlbmVyYXRlIGl0Li4uLi50aGlzIGlzIGtleSBwb2ludC4gIEZ1cnRoZXIsIGluIHRoZXNl IG5ldHdvcmtzIHRoZXJlIGlzIGEgZmFpcmx5IHN0YXRpYy9sb25nLWhvbGRpbmcgY2xpZW50IHNl cnZlciByZWxhdGlvbnNoaXAuICBDbGVhcmx5IHRoaXMgaXMgbm90IHRydWUgaW4gdGhlIGNsLXBz IG1vZGUgYW5kIGl0J3Mgd2h5IElFVEYgaGF2ZSBuZXZlciBzcGVjaWZpZWQgQUlTIGZvciBJUCBh bmQgaXRzIHdoeSBJRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byB0aHJvdy1vdXQgQUlTIGluIDgw Mi4xYWcgZm9yIEV0aGVybmV0ICh0aG91Z2ggSVRVIGhhdmUgdW53aXNlbHkgSU1PIHJldGFpbmVk IGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0IGFueSBvcGVyYXRvciBwbGFubmluZyB0byB1 c2UgRXRoZXJuZXQgZXF1aXBtZW50IHdvdWxkIGFsd2F5cyBsb29rIHRvIElFRUUgc3RkcyBhbmQg bm90IElUVSBvbmVzKS4NCiANCkFJUy9GREkgYW5kIHRoZSBjby1wcyBtb2RlIGlzIGRlYmF0YWJs ZS4gIEFzIEkgbm90ZWQgYWJvdmUsIG9uIGJhbGFuY2Ugd2UgY29uc2lkZXJlZCBub3QgYSBnb29k IGlkZWEgZm9yIFBCQi1URSBPQU0gYmVjYXVzZSBpdCByZXF1aXJlcyBhIGNvbnNjaW91cyBlZmZv cnQgdG8gZ2VuZXJhdGUgaXQgKHVubGlrZSB0aGUgY28tY3MgbW9kZSkgc28gdGhlcmUgYXJlIGxp a2VseSB0byBiZSBzY2FsaW5nIHByb2JsZW1zIGFuZCBpdHMgb25lIG1vcmUgdGhpbmcgdG8gZ28g d3JvbmcuDQogDQpZb3Ugc2hvdWxkIGFsc28gaGF2ZSBzZWVuIG1lIG1ha2UgdGhlIHBvaW50IG1h bnkgdGltZXMgaW4gdGhlIHBhc3QgdGhhdCB0aGUgYWx3YXlzLW9uIGRlZmVjdCBkZXRlY3Rpb24v aGFuZGxpbmcgT0FNIG5lZWRzIHRvIGJlIGFzIHNpbXBsZS9zcGFyc2UgYXMgcG9zc2libGUgd2l0 aCBhcyBsaXR0bGUgY29uZmlnIGFzIHBvc3NpYmxlIGJlY2F1c2Ugd2UgbmVlZCBzdXBlciByZWxp YWJpbGl0eS4uLi4uLlRDTSBnb2VzIGNvbXBsZXRlbHkgYWdhaW5zdCB0aGUgZ3JhaW4gaGVyZS4g IEFsc28gbm90ZSB0aGF0IHRoZSBPQU0gcmVxdWlyZWQgZm9yIGVhY2ggb2YgdGhlIDMgbmV0d29y ayBtb2RlcyBpcyBub3QgdGhlIHNhbWUsIGRlc3BpdGUgd2hhdCBzb21lIGNsYWltLg0KIA0KcmVn YXJkcywgTmVpbA0KIA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K CUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpdS5ndW9tYW5AenRlLmNvbS5jbg0KCVNlbnQ6IDIxIEFw cmlsIDIwMDkgMDI6NTkNCglUbzogQlJVTkdBUkQsIERFQk9SQUggQSwgQVRUTEFCUw0KCUNjOiBt cGxzLXRwQGlldGYub3JnDQoJU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoJDQoJDQoNCglEZWJvcmFoOiAN CgkgbWF5YmUgd2hhdCB5b3Ugc2FpZCBpcyByaWdodC4gYnV0IEkgY2FuJ3QgY29tcGxldGVseSBh Z3JlZSB5b3VyIG9waW5pb25zLiBJTU8uIG1wbHMtdHAgaXMgcmVnYXJkIGFzIHRyYW5zcG9ydCBu ZXR3b3JrIGxpa2UgU0RIL1NPTkVULiBzbyBpdCBzaG91bGQgaGF2ZSBBSVMvRkRJIGZ1Y3Rpb25z IGFzIFNESC9TT05FVC4gDQoJDQoJZG8geW91IHRoaW5rIHNvLiANCgkNCgliZXN0IHJlZ2FyZHMg DQoJbGl1IA0KCQ0KCQ0KCQ0KIkJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMiIDxkYnJ1bmdh cmRAYXR0LmNvbT4gDQrlj5Hku7bkuro6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQoNCjIw MDktMDQtMjAgMjM6NDcgDQoNCuaUtuS7tuS6ug0KIk1hYXJ0ZW4gVmlzc2VycyIgPG1hYXJ0ZW4u dmlzc2Vyc0BodWF3ZWkuY29tPiwgPG5laWwuMi5oYXJyaXNvbkBidC5jb20+IA0K5oqE6YCBDQpt cGxzLXRwQGlldGYub3JnIA0K5Li76aKYDQpSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0KCQ0KDQoNCg0KDQoJSSBhZ3Jl ZSB3aXRoIE5laWwsIGl0IGlzIHZlcnkgcXVlc3Rpb25hYmxlIHRoZSB2YWx1ZSBvZiBBSVMvRkRJ IGluIGENCglwYWNrZXQgbmV0d29yay0gYW55IG1vZGUuIEl0IGNhbiByZXN1bHQgaW4gYSBEb1Mg YXR0YWNrIGJ5IGFuIG9wZXJhdG9yDQoJb24gdGhlbXNlbHZlcyBzbyBldmVuIFkxNzMxIHJlY29t bWVuZHMgbm90IHRvIGJsb2NrIGRhdGEgZnJhbWVzOg0KCSJBIE1FUCBjYW4gZGVjaWRlIHdoZXRo ZXIgaXQgYmxvY2tzIGRhdGEgZnJhbWVzIHdoZW4gaXQgZGV0ZWN0cyBkQUlTLg0KCVRoZSBwcmlu Y2lwbGUgcmVxdWlyZW1lbnQNCgl0aGF0IGluZmx1ZW5jZXMgdGhpcyBkZWNpc2lvbiBpcyB0aGF0 IGRhdGEgZnJhbWVzIG91Z2h0IHRvIGJlIGZvcndhcmRlZA0KCWFzIG11Y2ggYXMgcG9zc2libGUs IHdpdGhvdXQNCgl0aGUgcG9zc2liaWxpdHkgb2YgZm9yd2FyZGluZyB3cm9uZyBkYXRhIGZyYW1l cyBkb3duc3RyZWFtLiINCglUYWJsZSBJLjctMiBzaG93cyBmb3IgQUlTLCBub3QgdG8gYmxvY2su DQoJDQoJQW5kIGFzIFkxNzMxIHN0YXRlcywgQUlTIGNhbiBvbmx5IGJlIHVzZWQgdW5kZXIgdmVy eSBjb25zdHJhaW5lZA0KCWFyY2hpdGVjdHVyZXMgLSBpZiByZXF1aXJlZCBmb3IgTVBMUy1UUCwg aXQgbmVlZHMgdG8gaGF2ZSB0aGUgc2FtZQ0KCWd1aWRhbmNlIGFzIGluIFkxNzMxLCBpLmUuIHBv aW50LXRvLXBvaW50IGFuZCBzZXJ2ZXIvY2xpZW50IG9uZS10by1vbmU6DQoJImZvciBhIHBvaW50 LXRvLXBvaW50IEVUSCBjb25uZWN0aW9uLCBhIE1FUCBoYXMgb25seSBhIHNpbmdsZSBwZWVyIE1F UC4NCglUaGVyZWZvcmUsIHRoZXJlDQoJaXMgbm8gYW1iaWd1aXR5IHJlZ2FyZGluZyB0aGUgcGVl ciBNRVAgZm9yIHdoaWNoIGl0IHNob3VsZCBzdXBwcmVzcw0KCWFsYXJtcyB3aGVuIGl0IHJlY2Vp dmVzIHRoZQ0KCUVUSC1BSVMgaW5mb3JtYXRpb24uIg0KCVNvIHNob3VsZCBvbmx5IGJlIHdpdGhp biBvbmUgZG9tYWluIC0gdGhlbiBubyBuZWVkLg0KCQ0KCURlYm9yYWgNCgkNCgktLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KCUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24NCglCZWhhbGYgT2YgTWFhcnRlbiBWaXNzZXJz DQoJU2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSAxMDowNSBBTQ0KCVRvOiBuZWlsLjIuaGFy cmlzb25AYnQuY29tDQoJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCglTdWJqZWN0OiBSZTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KCXJlcXVpcmVtZW50 cw0KCQ0KCU5laWwsDQoJDQoJPiBidXQgQUlTL0ZESSBpbiB0aGUgY2wgbW9kZT8uLi5kbyBtZSBh IGZhdm91ciENCgkNCglFdGhlcm5ldCBBSVMgaXMgaW5kZWVkIGEgcmVxdWlyZW1lbnQgYW5kIGEg bmVjZXNzaXR5LiBBbmQgeW91IHdpbGwgbm90DQoJYmUNCglhYmxlIHRvIHVuZGVyc3RhbmQgdGhh dCBhcyBsb25nIGFzIHlvdSByZWZ1c2UgdG8gYWNjZXB0IHRoYXQgImNsLW1vZGUiDQoJaXMgYQ0K CWZvcndhcmRpbmcgbW9kZSB3aXRoaW4gYSAqKnRyYW5zcG9ydCBlbnRpdHkqKi4gRy44MDAgYW1l bmRtZW50IDEgaGFzDQoJZmluYWxseQ0KCXJlaW50cm9kdWNlZCB0aGlzIHRyYW5zcG9ydCBlbnRp dHkgaW50byBHLjgwMC4gQmVzaWRlcyB0aGF0LCBpdCBhbHNvDQoJaW50cm9kdWNlZCB0aGUgKipk aWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uKio6DQoJDQoJW0cuODAwIGFtMV0gIkEgZGlmZmVyZW50 aWF0ZWQgY29ubmVjdGlvbiBpcyBhIHRyYW5zcG9ydCBlbnRpdHkgdGhhdA0KCXRyYW5zZmVycyBp bmZvcm1hdGlvbiBiZWxvbmdpbmcgdG8gbXVsdGlwbGUgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBw b3J0cw0KCWFjcm9zcyBhIHN1Ym5ldHdvcmsuIDwuLj4gSW4gYSBkaWZmZXJlbnRpYXRlZCBjb25u ZWN0aW9uIG1lc3NhZ2UNCgljb250ZW50cw0KCWFyZSBpbnRlcnByZXRlZCB0byBpZGVudGlmeSAo c2V0cyBvZikgY29tbXVuaWNhdGlvbnMgd2hpY2ggcmVjZWl2ZQ0KCWRpZmZlcmVudA0KCXRyZWF0 bWVudC4gIFRoZSBzZXRzIG9mIGNvbW11bmljYXRpb25zIG1heSBiZSBkaXN0aW5ndWlzaGVkIGJ5 IHRoZQ0KCWZvcndhcmRpbmcgaWRlbnRpZmllciBvciBvdGhlciBsYXllciBpbmZvcm1hdGlvbi4g IE9yZGVyIGlzIG5vdA0KCW5lY2Vzc2FyaWx5DQoJcHJlc2VydmVkIGJldHdlZW4gbWVzc2FnZXMg YmVsb25naW5nIHRvIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgcmVjZWl2aW5nDQoJZGlmZmVyZW50 IHRyZWF0bWVudC4gIFNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIGlkZW50aWZpZWQgZm9y DQoJcHVycG9zZXMNCglzdWNoIGFzIHRyYWZmaWMgY29uZGl0aW9uaW5nIG9yIHByZXNlcnZpbmcg Y29tbXVuaWNhdGlvbiBtZXNzYWdlIG9yZGVyLiINCgkNCgkNCglFdGhlcm5ldCBWTEFOcyBhcmUg aW4gdGVybXMgb2YgRy44MDAgImRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb25zIi4NCglFdGhlcm5l dA0KCUFJUyBwcm92aWRlcyBBSVMgd2l0aGluIHRoZSBzY29wZSBvZiBzdWNoICJkaWZmZXJlbnRp YXRlZCBjb25uZWN0aW9uIi4NCglJZg0KCXlvdSBhcHBseSB0aGlzIHRvIG15IHByb3Bvc2VkIFBU TiBsYXllciBzdGFjaywgdGhlbiB0aGUgRVZDIGxheWVyDQoJdG9wb2xvZ3kNCgl3aWxsIGNvbnNp c3RzIG9mIEVWQyBsaW5rcyBzdXBwb3J0ZWQgYnkgTVBMUy1UUCwgRXRoZXJuZXQsIFBCQi1URSBh bmQNCglQLU9UTg0KCVZQIHRyYWlscyBpbnNpZGUgbWV0cm8gYW5kIGNvcmUgZG9tYWlucyBpbnRl cmNvbm5lY3RpbmcgRVZDIG1hdHJpY2VzLg0KCVdoZW4NCglvbmUgb2YgdGhvc2UgRVZDIGxpbmtz IGlzIGludGVycnVwdGVkLCBlLmcuIGluIHRoZSBjb3JlIGJldHdlZW4gbWV0cm8gMQ0KCWFuZA0K CW1ldHJvIDQgKHNlZSBhdHRhY2hlZCBzbGlkZSksIHRoZW4gdGhlIEVWQyBkaWZmZXJlbnRpYXRl ZCBjb25uZWN0aW9uDQoJdGhhdCBpcw0KCXByZXNlbnQgb24gdGhpcyBsaW5rIHdpbGwgYmUgaW50 ZXJydXB0ZWQuIEF0IHRoZSBFVkMgc3dpdGNoL2JyaWRnZSBub2RlDQoJaW4NCgltZXRybyA0IHRo aXMgaW50ZXJydXB0aW9uIGlzIG5vdGljZWQgYW5kIEVWQy1BSVMgaXMgaW5zZXJ0ZWQgaW4gdGhl DQoJZG93bnN0cmVhbSBkaXJlY3Rpb24gdG8gc3VwcHJlc3MgdGhlIEVWQy1MT0MgYWxhcm1zIGF0 IEVWQyBlbmRwb2ludHMgRDQNCglhbmQNCglENS4NCgkNCglUaGUgRVZDLUFJUyAoaS5lLiBFdGhl cm5ldCBBSVMpIGZyYW1lIGhhcyBhIHJlc2VydmVkIG11bHRpY2FzdCBhZGRyZXNzLA0KCXdoaWNo IGd1YXJhbnRlZXMgdGhhdCB0aGUgQUlTIGlzIGJyb2FkY2FzdCB0byB0aGUgZW5kcG9pbnRzIG9m IHRoZSBFVkMuDQoJDQoJSSBiZWxpZXZlIHRoYXQgaXQgaXMgdGltZSBmb3IgeW91IHRvIGFkYXB0 IHlvdXIgdmlldyBvbiBjbyBhbmQgY2wgbW9kZXMNCglhbmQNCglyZWxhdGUgaXQgdG8gdGhlIGZv cndhcmRpbmcgbW9kZSAqKklOU0lERSoqIGEgdHJhbnNwb3J0IGVudGl0eS4gDQoJDQoJV2hhdCB3 ZSBrbm93IGFzIHRoZSBpbnRlcm5ldCBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0 ZWQNCgljb25uZWN0aW9uIiB3aXRoIGEgYmlsbGlvbiBvciBtb3JlIHBvcnRzLg0KCVdoYXQgd2Ug a25vdyBhcyBhbiBJUCBWUE4gaXMgZXNzZW50aWFsbHkgYW4gIklQIGRpZmZlcmVudGlhdGVkDQoJ Y29ubmVjdGlvbiINCgl3aXRoIGUuZy4gbiBwb3J0cyAobiBpbiB0aGUgcmFuZ2Ugb2YgZS5nLiAy IHRvIDEwMDApLg0KCVdoYXQgd2Uga25vdyBhcyBhbiBFdGhlcm5ldCBWTEFOIGlzIGVzc2VudGlh bGx5IGFuICJFdGhlcm5ldA0KCWRpZmZlcmVudGlhdGVkDQoJY29ubmVjdGlvbiIgd2l0aCBuIHBv cnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuDQoJV2hhdCB3ZSBrbm93IGFz IGEgcDJwIE1QTFMgRS1MU1AgaXMgZXNzZW50aWFsbHkgYW4gIk1QTFMgZGlmZmVyZW50aWF0ZWQN Cgljb25uZWN0aW9uIiB3aXRoIDIgcG9ydHMuDQoJV2hhdCB3ZSBrbm93IGFzIGEgcDJwIFNESCBW Qy1uIGlzIGEgIlNESCBWQy1uIGNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy4NCgkNCglUcmFuc3Bv cnQgbmV0d29yayBPQU0gYXBwbGllcyB0byB0cmFuc3BvcnQgZW50aXRpZXMsIHdoaWNoIGFyZSAo aW4gdGVybXMNCglvZg0KCUcuODAwIGFtMSkgY29ubmVjdGlvbnMgYW5kIGRpZmZlcmVudGlhdGVk IGNvbm5lY3Rpb25zLg0KCQ0KCVJlZ2FyZHMsDQoJTWFhcnRlbg0KCQ0KCS0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoJRnJvbTogbmVpbC4yLmhhcnJpc29uQGJ0LmNvbSBbbWFpbHRvOm5laWwu Mi5oYXJyaXNvbkBidC5jb21dIA0KCVNlbnQ6IHZyaWpkYWcgMTcgYXByaWwgMjAwOSAyMjowMA0K CVRvOiBKb2huLkUuRHJha2UyQGJvZWluZy5jb207IEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQu aXQ7DQoJQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IG1hYXJ0ZW4udmlzc2Vyc0Bo dWF3ZWkuY29tDQoJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCglTdWJqZWN0OiBSRTogW21wbHMtdHBd IEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KCXJlcXVpcmVtZW50cw0K CQ0KCUpvaG4sICBUaGFua3MgdGhpcyBpcyBhIGdyZWF0IHBsYXRmb3JtIHRvIGV4cGxhaW4gd2h5 IE9BTSBmb3IgdGhlIDMNCgluZXR3b3JrDQoJbW9kZXMgbmVlZHMgdG8gYmUgZGlmZmVyZW50LiAg SSBhbSBnZXR0aW5nIGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xrcw0KCXRyeWluZw0KCXRvIG1ha2Ug YWxsIDMgbmV0d29yayBtb2RlcyBsb29rIGFsaWtlIChhbmQgdGhlbiwgZXZlbiB3b3JzZSwgaW50 ZXJ3b3JrDQoJdGhlbQ0KCWFzIGFzIHBlZXJzLi4uZXNwIHdoZW4gbm90IG5vdCB0b3Atb2Ytc3Rh Y2sNCgluZXR3b3Jrcy4uLkkgbWVhbiBob3cgc2lsbHkgY2FuIHdlIGdldD8pLiAgIEkgYW0gZXZl biBtb3JlIGZydXN0cmF0ZWQgYnkNCgl0aGUgZmFjdCB0aG9zZSBwZWRkbGluZyB0aGlzIEZVRCBv bmx5IGV2ZXIgc2VlbSB0byBjb25zaWRlciBPQU0gYW5kDQoJZm9yZ2V0DQoJYWxsIG90aGVyIERQ L0NQL01QIGNvbXBvbmVudHMgKGVzcCB0b3Atb2Ytc3RhY2sgbWVzc2FnZS9maWxlL3N0cmVhbQ0K CWFwcGxpY2F0aW9uIGFkYXB0YXRpb25zKS4gIEhvdyB3cm9uZyBjYW4gdGhpcyBnZXQhIA0KCQ0K CUluIHRoZSBjbyBtb2RlcyBhICpjb25uZWN0aW9uKiBpcyBhIHZlcnkgc3BlY2lmaWMgYW5kICpj b25zdHJhaW5pbmcqDQoJY29uc3RydWN0Li4uLi5JIGFtIGFzc3VtaW5nIGhlcmUgd2UgcmVzcGVj dCB0aGUgcnVsZXMgb2YgYSBjb25uZWN0aW9uDQoJKGllDQoJc2luZ2xlIHNvdXJjZSkgdGhvdWdo IHNvbWUgZm9sa3MgZG9uJ3QgZXZlbiBib3RoZXIgdG8gcmVzcGVjdCB0aGlzLCBhbmQNCgl0aGlz DQoJaXMgZGVzcGl0ZSB0aGUgZmFjdCB0aGF0IHdlIGFsbCBrbm93IHdoYXQgcHJvYmxlbXMgbXVs dGlwbGUtc291cmNlDQoJY29uc3RydWN0cyBjYW4gY2F1c2UgKGZyb20gTERQL1BIUC4uLi5lcmdv IE1QTFMtVFApLg0KCQ0KCVdoZW4gd2UgaGF2ZSBhIGNvbm5lY3Rpb24gdGhpcyByZXN0cmljdHMg KmFsbCogRFAgKGllIHRyYWZmaWMgYW5kIE9BTSkNCgl0bw0KCXN0YXkgd2l0aGluIHRoZSBib3Vu ZHMgb2YgdGhlIGNvbm5lY3Rpb24uICBXaGljaCBpcyBmaW5lIHVuZGVyDQoJZGVmZWN0LWZyZWUN Cgljb25kaXRpb25zLCBidXQgaWYgd2UgaGF2ZSBsZWFraW5nIHRyYWZmaWMgdGhlbiB0aGUgY29u c3RyYWluaW5nIG5hdHVyZQ0KCW9mDQoJdGhlIGNvbm5lY3Rpb24gY29uc3RydWN0IGlzIGJyb2tl bi4gIEluIGEgbnV0c2hlbGwgd2hhdCB0aGlzIG1lYW5zIGlzDQoJdGhhdA0KCU9BTSB0aGF0IGlz IG9mIGEgcmVxdWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fubm90IGJlIHRydXN0ZWQgaW4gY28gbW9k ZQ0KCW5ldHdvcmtzIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3RzLi4uLi5pbmRlZWQsIHdo eSBzaG91bGQgYSBsZWFraW5nDQoJRFANCgloYXZlIGEgc3ltbWV0cmljIGdvL3JldHVybiBkZWZl Y3QgYmVoYXZpb3VyPy4uLi52ZXJ5IGxpa2VseSBpdCB3b24ndC4NCglTbw0KCXdoaWxzdCByZXF1 ZXN0L3Jlc3BvbnNlIE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1vZGUgaXQgaXMgbm90IHJpZ2h0 IGZvcg0KCXRoZQ0KCWNvIG1vZGUgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCBjb25kaXRp b25zLg0KCQ0KCU1vcmUgZ2VuZXJhbGx5IHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQgYW5kIG5v dCBqdXN0IGluIE9BTQ0KCXJlcXVpcmVtZW50cy4uLi5idXQgQUlTL0ZESSBpbiB0aGUgY2wgbW9k ZT8uLi5kbyBtZSBhIGZhdm91ciEuLi5hdCBsZWFzdA0KCUlFRUUgaGFkIHRoZSBnb29kIHNlbnNl IHRvIGJpbiB0aGlzIGZvciBFdGhlcm5ldCBldmVuIHRob3VnaCBpdCByZW1haW5zDQoJaW4NCglZ LjE3MzEuICBBbmQgd2hpY2ggaXMgd2h5IEkgb2Z0ZW4gdHJvdC1vdXQgdGhlIHJhdGhlciBzaWxs eSAodG8gaGF2ZSB0bw0KCXNheQ0KCXRoaXMpIG9ic2VydmF0aW9uIHRoYXQgaWYgSVAgKGNsIG1v ZGUpIGNvdWxkIGRvIGl0IGFsbCB0aGVuIHdoeSBoYXZlDQoJSUVURg0KCWZvdW5kIGl0IG5lY2Vz c2FyeSB0byBjcmVhdGUgTVBMUyAoY28tcHMpIGFuZCBHTVBMUyAoQ1AgZm9yIGNvLWNzKS4gIFRo ZQ0KCWFuc3dlciBsaWVzIGluIHRoZSBwaHlzaWNzLi4uYW5kIEcuODAwIGF0dGVtcHRzIHRvIGV4 cGxhaW4gdGhhdA0KCXBoeXNpY3MuLi4uRy44MDUgZG9lcyBub3QuDQoJDQoJU28sIHRoZSAzIG1v ZGVzIGFyZSBkaWZmZXJlbnQuLi5wbGVhc2UgYWNjZXB0L3Jlam9pY2UgaW4gdGhpcyBmYWN0IGFz DQoJdGhleQ0KCWFsbCBvZmZlciBzb21ldGhpbmcgZGlmZmVyZW50L2ltcG9ydGFudC4gIEJ1dCBk byBub3QgYmUgaG9vZHdpbmtlZCBieQ0KCXRob3NlDQoJd2hvIHBlZGRsZSBhIHN0b3J5IHRoYXQg dGhhdCB0cmllcyB0byBtYWtlIHRoZSBPQU0gb2YgdGhlIDMgbW9kZXMgdGhlDQoJc2FtZS4gDQoJ DQoJcmVnYXJkcywgTmVpbCANCgkNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBG cm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCgk+IFttYWlsdG86bXBscy10cC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4gRQ0KCT4gU2VudDogMTcgQXByaWwg MjAwOSAyMDowMg0KCT4gVG86IEJVU0kgSVRBTE87IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFy dGVuIFZpc3NlcnMNCgk+IENjOiBtcGxzLXRwQGlldGYub3JnDQoJPiBTdWJqZWN0OiBSZTogW21w bHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgk+IHJlcXVp cmVtZW50cw0KCT4gDQoJPiBJdGFsbywNCgk+IA0KCT4gQXMgZGVzY3JpYmVkIGluIHRoZSBNUExT IFRQIE9BTSBSZXF1aXJlbWVudHMgSS1ELCB2aXJ0dWFsbHkgYWxsIG9mIHRoZQ0KCQ0KCT4gT0FN IGZ1bmN0aW9ucyByZXF1aXJlIGEgcmV0dXJuIHBhdGgsIGFuZCBpbiB0aGUgYWJzZW5jZSBvZiBh IHJldHVybiANCgk+IHBhdGggdGhleSBhcmUgZGlzYWJsZWQuDQoJPiANCgk+IEFzIGRlc2NyaWJl ZCBpbiBEYXZpZCBTaW5pY3JvcGUncyBtZWV0aW5nIG1pbnV0ZXMgDQoJPiAoaHR0cDovL3dpa2ku dG9vbHMuaWV0Zi5vcmcvbWlzYy9tcGxzLWludGVyb3AvYXR0YWNobWVudC93aWtpLw0KCT4gbWVl dGluZy1ubw0KCT4gdGVzLzIwMDgxMDE1Lm1wbHMtaW50ZXJvcC1kdC1ub3Rlcy56aXApLCBpZiBJ UCBhZGRyZXNzaW5nIGlzIHVzZWQsIGFuIA0KCT4gTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGJl IGNhcGFibGUgb2YgZ2V0dGluZyBJUCBwYWNrZXRzIGZyb20gDQoJPiBkZXN0aW5hdGlvbiB0byBz b3VyY2U7IG5laXRoZXIgdGhlIG1pbnV0ZXMgbm9yIEkgc3RpcHVsYXRlIHRoYXQgYSANCgk+IGNv bnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byBpbnN0YW50aWF0ZSB0aGlzIGZvcndhcmRp bmcuDQoJPiANCgk+IEFzIGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgcmV0dXJuIHBhdGggZm9yIHVu aWRpcmVjdGlvbmFsIExTUHMgY291bGQgYmUNCgkNCgk+IGNoYXJhdGVyaXplZCBhcyB0aGUgZWxl cGhhbnQgaW4gdGhlIHJvb20uICBJbiB0aGUgTVBMUyBUUCBPQU0gDQoJPiBGcmFtZXdvcmsgSS1E LCB1bmljYXN0IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRpbWVzIGFuZCByZXR1cm4g DQoJPiBwYXRocyBub3QgYXQgYWxsLg0KCT4gDQoJPiBUaGFua3MsDQoJPiANCgk+IEpvaG4NCgk+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+ID4gRnJvbTogQlVTSSBJVEFMTyBbbWFp bHRvOkl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXRdDQoJPiA+IFNlbnQ6IEZyaWRheSwgQXBy aWwgMTcsIDIwMDkgMTo1OSBBTQ0KCT4gPiBUbzogRHJha2UsIEpvaG4gRTsgQWxleGFuZGVyIFZh aW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KCT4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KCT4g PiBTdWJqZWN0OiBSRTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCANCgk+ID4gcmVxdWlyZW1lbnRzDQoJPiA+IA0KCT4gPiBKb2huLA0KCT4gPiANCgk+ ID4gSSBtaWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVtZW50IG9mIE1QTFMtVFAgYmVpbmcgY2Fw YWJsZSBvZiANCgk+ID4gc2VuZGluZyByZXBsaWVzIHRvIE9BTSByZXF1ZXN0cyBzZW50IG9uIHVu aS1kaXJlY3Rpb25hbCBMU1BzLg0KCT4gPiANCgk+ID4gVGhpcyByZXF1aXJlbWVudCBkb2VzIG5v dCBiZWxvbmcgdG8gdGhlIGZpcnN0IHNldCBvZiByZXF1aXJlbWVudHMgDQoJPiA+IElUVS1UIGlz IGV4cGVjdGluZyB0byBiZSBtZXQgYnkgT2N0b2Jlci4NCgk+ID4gDQoJPiA+IEhvd2V2ZXIsIEkg dGhpbmsgdGhpcyBpbiBhIHBvdGVudGlhbCBpbnRlcmVzdGluZyBhZGRpdGlvbmFsIA0KCT4gPiBy ZXF1aXJlbWVudCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgKGF0IHdvcnN0IGluIGENCgk+IHN1 YnNlcXVlbnQgcGhhc2UpLg0KCT4gPiANCgk+ID4gSSB0aGluayB0aGF0IHRoaXMgcmVxdWlyZW1l bnQgbmVlZHMgdG8gYmUgZXZhbHVhdGVkIHZlcnN1cyBvdGhlciANCgk+ID4gbW9yZSBpbXBvcnRh bnQgcmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJpbGl0eSB0byB3b3JrIHcvbyBJUCANCgk+ ID4gZm9yd2FyZGluZyBhbmQgdGhlIG5lZWQgZm9yIE9BTSB0byBjb250aW51ZSB0byBtb25pdG9y IHRoZSBkYXRhIA0KCT4gPiBwbGFuZSBhbHNvIGluIGNhc2Ugb2YgZmFpbHVyZXMgYWZmZWN0aW5n IHRoZSBjb250cm9sIG9yIG1hbmFnZW1lbnQgDQoJPiA+IHBsYW5lKS4NCgk+ID4gDQoJPiA+IEkg YW0gb3BlbiB0byBkaXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdodCB0aW1l IGJlY2F1c2UgDQoJPiA+IEkgd2lzaCB0byBhdm9pZCBkZWxheWluZyB0aGUgZmlyc3QgcGhhc2Ug b2YgdGhlIGRlc2lnbiBzb2x1dGlvbi4NCgk+ID4gDQoJPiA+IFRoYW5rcywgSXRhbG8NCgk+ID4g DQoJPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+ID4gPiBGcm9tOiBtcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmcNCgk+ID4gPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIERyYWtlLCBKb2huIEUNCgk+ID4gPiBTZW50OiBUaHVyc2RheSwgQXBy aWwgMTYsIDIwMDkgODowMCBQTQ0KCT4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFh cnRlbiBWaXNzZXJzDQoJPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgk+ID4gPiBTdWJqZWN0 OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCAN Cgk+ID4gPiByZXF1aXJlbWVudHMNCgk+ID4gPiANCgk+ID4gPiBBdCB0aGUgbWVldGluZyBsYXN0 IGZhbGwgYXQgSnVuaXBlciBpbiBNYXNzYWNodXNldHRzLCBJDQoJPiA+IHRoaW5rIGl0IHdhcw0K CT4gPiA+IGFncmVlZCB0aGF0IGFuIE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBoYXZlIGEgZm9y d2FyZGluZw0KCT4gPiBjYXBhYmlsaXR5DQoJPiA+ID4gZm9yIG1hbmFnZW1lbnQsIGNvbnRyb2ws IGFuZCBPQU0gcGFja2V0cyAoZS5nLiwgc2VuZGluZw0KCT4gPiByZXBsaWVzIHRvIE9BTQ0KCT4g PiA+IHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMpIGV2ZW4gaWYgaXQgZG9l cyBub3QNCgk+ID4gaGF2ZSBhbiBJUA0KCT4gPiA+IGZvcndhcmRpbmcgZGF0YSBwbGFuZS4NCgk+ ID4gPiANCgk+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiA+ID4gPiBGcm9t OiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KCT4gPiA+IFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb21dDQoJPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkg OTo1NyBBTQ0KCT4gPiA+ID4gVG86IE1hYXJ0ZW4gVmlzc2Vycw0KCT4gPiA+ID4gQ2M6IG1wbHMt dHBAaWV0Zi5vcmcNCgk+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCT4gPiA+ID4gcmVxdWlyZW1lbnRzDQoJPiA+ ID4gPiANCgk+ID4gPiA+IE1hYXJ0ZW4sDQoJPiA+ID4gPiBJdCBzZWVtcyB0aGF0IHlvdSd2ZSBq dXN0IChpbXBsaWNpdGx5IGFuZCwgcHJvYmFibHksDQoJPiA+ID4gPiBpbmFkdmVydGVudGx5KSBz dGF0ZWQgdGhlIGZvbGxvd2luZzoNCgk+ID4gPiA+IA0KCT4gPiA+ID4gICAgICAgICAgICAgICAg ICBNUExTLVRQIE9BTSB3aWxsIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0aW9u DQoJPiA+IChhbmQgZmF1bHQNCgk+ID4gPiA+IGxvY2FsaXphdGlvbiB3aGljaCByZXF1aXJlcyB0 aGlzIGZ1bmN0aW9uICkgZm9yDQoJPiA+IHVuaWRpcmVjdGlvbmFsIFAyTVANCgk+ID4gPiA+IGFu ZCBQMlAgcGF0aHMuDQoJPiA+ID4gPiANCgk+ID4gPiA+IElmIHRoaXMgc3RhdGVtZW50IGlzIGNv cnJlY3QsIHRoaXMgKElNSE8gYW5kIEZXSVcpDQoJPiByYWlzZXMgYSB2YWxpZA0KCT4gPiA+ID4g cXVlc3Rpb246DQoJPiA+ID4gPiANCgk+ID4gPiA+ICAgICAgICAgICAgICAgICAgSXMgTVBMUy1U UCBhbiBhcHByb3ByaWF0ZSBzb2x1dGlvbiBmb3IgdGhlc2UNCgk+IHR5cGVzIG9mIHRyYW5zcG9y dA0KCT4gPiA+ID4gcGF0aHM/DQoJPiA+ID4gPiANCgk+ID4gPiA+IEZvciB0aGUgcmVmZXJlbmNl LCBJUC9NUExTIHByb3ZpZGVzIHRoaXMga2luZCBvZg0KCT4gPiBmdW5jdGlvbmFsaXR5IHRvZGF5 DQoJPiA+ID4gPiBmb3IgKHVuaWRpcmVjdGlvbmFsIC0gYnV0IGl0IGRvZXMgbm90IGtub3cgYW55 IG90aGVyDQoJPiA+IHR5cGUpIFAyUCBMU1BzDQoJPiA+ID4gPiBhcyBkZXNjcmliZWQgaW4gUkZD IDQzNzkuIEFuZCBpdHMgZXh0ZW5zaW9uIHRvIFAyTVAgTFNQcyBzZWVtcyANCgk+ID4gPiA+IGVh c3kuLi4NCgk+ID4gPiA+IA0KCT4gPiA+ID4gIA0KCT4gPiA+ID4gDQoJPiA+ID4gPiBSZWdhcmRz LA0KCT4gPiA+ID4gDQoJPiA+ID4gPiAgICAgIFNhc2hhDQoJPiA+ID4gPiANCgk+ID4gPiA+IA0K CT4gPiA+ID4gDQoJPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoJPiA+ID4gPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZ10NCgk+ID4gT24gQmVoYWxmDQoJPiA+ID4gPiBPZiBNYWFydGVuIFZpc3Nl cnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXQ0KCT4gPiA+ID4gU2VudDogVGh1cnNkYXks IEFwcmlsIDE2LCAyMDA5IDM6MjQgUE0NCgk+ID4gPiA+IFRvOiAnQWRyaWFuIEZhcnJlbCcNCgk+ ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQoJPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgk+ID4gPiA+IHJl cXVpcmVtZW50cw0KCT4gPiA+ID4gDQoJPiA+ID4gPiBBZHJpYW4sDQoJPiA+ID4gPiANCgk+ID4g PiA+ID4+IDxxdW90ZT4NCgk+ID4gPiA+ID4+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAo aW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5kDQoJPiA+ID4gPiBvdGhlciBpbnRlcm5hbA0KCT4gPiA+ ID4gPj4gICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZA0KCT4g PiA+ID4gYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCgk+ID4gPiA+ID4+ICAgICAgIHBhdGggYXQg ZWFjaCAoc3ViLSlsYXllciBNVVNUIGJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nDQoJPiA+ID4gPiA+ PiAgICAgICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KCT4g PiA+ID4gZGlyZWN0aW9ucyBvZiB0aGF0DQoJPiA+ID4gPiA+PiAgICAgICB0cmFuc3BvcnQgcGF0 aC4NCgk+ID4gPiA+ID4+IDxlbmQgcXVvdGU+DQoJPiA+ID4gPiA+DQoJPiA+ID4gPiA+IFRoZXJl IGlzIG5vIHdheSB0aGlzIGlzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdA0KCT4gPiA+ IGlzLCB0aGVyZSBpcw0KCT4gPiA+ID4gPiAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQg ZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZg0KCT4gPiA+IHZpZXcgdGhhdA0KCT4gPiA+ID4gPiBy ZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC4NCgk+ID4gPiA+IA0KCT4g PiA+ID4gWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBjb3JyZWN0LiBJdCBpcyB2ZXJ5IG11Y2gN Cgk+IG9ic2VydmFibGUgaWYNCgk+ID4gPiA+IHRoaXMgcmVxdWlyZW1lbnQgaXMgbWV0IGZyb20g YSBibGFjayBib3ggcG9pbnQgb2Ygdmlldy4NCgk+ID4gPiA+IFRoZSBNSVAgZnVuY3Rpb25zIGNh biBvbmx5IHBlcmZvcm0gdGhlIExvb3BiYWNrIHdoZW4gdGhlcmUgaXMgYSANCgk+ID4gPiA+IGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoLiBUaGUgTVBMUy1UUCBMQk0gcGFj a2V0IA0KCT4gPiA+ID4gcmVjZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUgcmV0dXJuZWQgKGFz IExCUg0KCT4gPiA+ID4gcGFja2V0KSB0byB0aGUgb3JpZ2luYXRpbmcgTUVQIGZ1bmN0aW9uIHZp YSB0aGUgb3RoZXINCgk+ID4gZGlyZWN0aW9uIG9mDQoJPiA+ID4gPiB0aGUgY28tcm91dGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoaXMgb3RoZXINCgk+IGRpcmVjdGlvbg0KCT4g PiA+ID4gd291bGQgbm90IGJlIGF2YWlsYWJsZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgdHJhbnNwb3J0IA0KCT4gPiA+ID4gcGF0aC4uLiBhbmQgdGh1cyB0aGUgbG9vcGJhY2sgdGVz dA0KCT4gPiA+IHdvdWxkIGZhaWwuDQoJPiA+ID4gPiANCgk+ID4gPiA+IFNpbWlsYXJseSwgd2hl biB3ZSBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1vbml0b3IgYQ0KCT4gPiBzZWdtZW50LCB0 aGVuDQoJPiA+ID4gPiB0aGlzIGlzIHBvc3NpYmxlIGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5z cG9ydCBwYXRoDQoJPiBidXQgbm90IGluIGENCgk+ID4gPiA+IGFzc29jaWF0ZWQgYmlkaXIgdHJh bnNwb3J0IHBhdGguIEluIHRoZSBmaXJzdCBjYXNlIHRoZSBUQ00gTUVQIA0KCT4gPiA+ID4gU291 cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucyBhcmUgY28tbG9jYXRlZCBhbmQgY2FuDQoJPiBleGNoYW5n ZSB3aGF0IGlzDQoJPiA+ID4gPiBjYWxsZWQgInJlbW90ZSBpbmZvcm1hdGlvbiIgd2hpY2ggaXMg bmVjZXNzYXJ5IGZvciBwZXJmb3JtYW5jZSANCgk+ID4gPiA+IG1vbml0b3JpbmcuDQoJPiA+ID4g PiBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBNRVAgU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9u cw0KCT4gPiBhcmUgaW4gZS5nLiANCgk+ID4gPiA+IGRpZmZlcmVudCBub2RlcyBpbiB0aGUgbmV0 d29yayBhbmQgVENNIHdvdWxkIG5vdCBiZSBhYmxlDQoJPiA+IHRvIHByb3ZpZGUNCgk+ID4gPiA+ IHBlcmZvcm1hbmNlIG1vbml0b3JpbmcuDQoJPiA+ID4gPiANCgk+ID4gPiA+ID4gVGhlIGVudGly ZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRpbmcgTUVQcywNCgk+ID4gPiBNSVBz IGFuZCBvdGhlcg0KCT4gPiA+ID4gaW50ZXJuYWwNCgk+ID4gPiA+ID4gZnVuY3Rpb25zIGFzIGFw cHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90DQoJPiA+ID4gPiBhZGQg dG8gIlRoZQ0KCT4gPiA+ID4gPiBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KCT4gPiA+ID4gDQoJPiA+ ID4gPiBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIFRoaXMgdGV4dCBtdXN0IG5v dCBiZQ0KCT4gPiBkZWxldGVkIGF0DQoJPiA+ID4gPiBhbGwuDQoJPiA+ID4gPiANCgk+ID4gPiA+ ID4gQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudA0KCT4g PiA+IGluc2lzdGVuY2Ugb24gdGhlDQoJPiA+ID4gPiBpbmNsdXNpb24NCgk+ID4gPiA+ID4gb2Yg IlRhbmRlbSBDb25uZWN0aW9uLiIgVGhlIGRlZmluaXRpb24gd2l0aGluIHRoZSBJVFUtVCBvZg0K CT4gPiA+ID4gdGhpcyB0ZXJtDQoJPiA+ID4gPiA+IGlzDQoJPiA+ID4gPiBwb29ybHkNCgk+ID4g PiA+ID4gc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZSBtb25pdG9yaW5nIG9mIGEgcGF0aCB0 aGF0IGlzDQoJPiA+ID4gPiBwYXJhbGxlbCAoaS5lLg0KCT4gPiA+ID4gdGFuZGVtKQ0KCT4gPiA+ ID4gPiB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9m IFRDDQoJPiA+ID4gPiBzZWVtcyB0byBiZSBhdA0KCT4gPiA+ID4gdmFyaWFuY2UsDQoJPiA+ID4g PiA+IGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KCT4gPiA+ ID4gDQoJPiA+ID4gPiBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRhdGlv biBvZiB0YW5kZW0NCgk+ID4gY29ubmVjdGlvbiBpcw0KCT4gPiA+ID4gZGVzY3JpYmVkIGluIElU VS1UIHJlY29tbWVuZGF0aW9ucy4gSS5lLiAiZnJvbSB0aGUNCgk+ID4gbW9uaXRvcmluZyBvZiBh DQoJPiA+ID4gPiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0 YSBwYXRoIGJlaW5nIA0KCT4gPiA+ID4gbW9uaXRvcmVkLiI/DQoJPiA+ID4gPiANCgk+ID4gPiA+ IFRoZXJlIGlzIGEgIm5ldHdvcmsgY29ubmVjdGlvbiIgYW5kIHRoaXMgbmV0d29yaw0KCT4gPiBj b25uZWN0aW9uIGlzIGEgc2V0DQoJPiA+ID4gPiBvZiBpbnRlcmNvbm5lY3RlZCAibGluayBjb25u ZWN0aW9ucyIgYW5kICJtYXRyaXgNCgk+IGNvbm5lY3Rpb25zIi4gQQ0KCT4gPiA+ID4gc3Vic2V0 IG9mIHRob3NlIGludGVyY29ubmVjdGVkIGxpbmsgY29ubmVjdGlvbnMgYW5kIG1hdHJpeCANCgk+ ID4gPiA+IGNvbm5lY3Rpb25zIGNhbiBiZSBtb25pdG9yZWQgYW5kIGlzIHRoZW4gcmVmZXJyZWQg dG8gYXMNCgk+IGEgInRhbmRlbQ0KCT4gPiA+ID4gY29ubmVjdGlvbiIuIFRoZXJlIGlzIG5vICJw YXRoIHRoYXQgaXMgcGFyYWxsZWwgdG8gdGhlDQoJPiA+IGRhdGEgcGF0aCIuIA0KCT4gPiA+ID4g VGhlcmUgaXMgb25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBpbnNpZGUgdGhlIGRhdGENCgk+ IHBhdGggYnkgdGhlDQoJPiA+ID4gPiBUQ00gTUVQX1NvIGZ1bmN0aW9uIGFuZCB0aGlzIE9BTSBp cyBleHRyYWN0ZWQgZnJvbSB0aGUNCgk+ID4gZGF0YSBwYXRoIGJ5DQoJPiA+ID4gPiB0aGUgVENN IE1FUF9TayBmdW5jdGlvbi4NCgk+ID4gPiA+IA0KCT4gPiA+ID4gUmVnYXJkcywNCgk+ID4gPiA+ IE1hYXJ0ZW4NCgk+ID4gPiA+IA0KCT4gPiA+ID4gDQoJPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KCT4gPiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoJPiA+ ID4gPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlh biBGYXJyZWwNCgk+ID4gPiA+IFNlbnQ6IGRvbmRlcmRhZyAxNiBhcHJpbCAyMDA5IDExOjU5DQoJ PiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGJlbmphbWluLm5pdmVuLWplbmtpbnNA YnQuY29tDQoJPiA+ID4gPiBDYzogQlVTSSBJVEFMTzsgbXBscy10cEBpZXRmLm9yZw0KCT4gPiA+ ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggDQoJPiA+ID4gPiByZXF1aXJlbWVudHMNCgk+ID4gPiA+IA0KCT4gPiA+ID4gSGkg U2FzaGEsDQoJPiA+ID4gPiANCgk+ID4gPiA+ID4gVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxs eSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50Og0KCT4gPiA+ID4gPg0KCT4gPiA+ID4gPiA8cXVv dGU+DQoJPiA+ID4gPiA+ICAgICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBj by1yb3V0ZWQNCgk+ID4gPiBiaWRpcmVjdGlvbmFsIExTUHMNCgk+ID4gPiA+ID4gICAgIGFyZSBh IHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCgk+ID4gPiA+ ID4gPGVuZCBxdW90ZT4NCgk+ID4gPiA+ID4NCgk+ID4gPiA+ID4gVGhpcyBzdGF0ZW1lbnQgd291 bGQgYmUgb2J2aW91c2x5IGNvcnJlY3QsIHdlcmUgaXQgbm90IGZvcg0KCT4gPiA+ID4gUmVxdWly ZW1lbnQNCgk+ID4gPiA+ID4gMzQgaW4gdGhlIGxhdGVzdCBNUExTLVRQIHJlcXVpcmVtZW50cyBk cmFmdA0KCT4gPiA+ID4gDQoJPiA+ID4gPiBPSy4gR290IGl0Lg0KCT4gPiA+ID4gDQoJPiA+ID4g PiBCdXQgd2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cyBz ZWN0aW9uPw0KCT4gPiA+ID4gDQoJPiA+ID4gPiBJbiBmYWN0LCB3aGF0IGlzIHRoaXMgcmVxdWly ZW1lbnQgYWN0dWFsbHkgc2F5aW5nPw0KCT4gPiA+ID4gDQoJPiA+ID4gPiA+IDxxdW90ZT4NCgk+ ID4gPiA+ID4gICAgICBUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQ cyBhbmQNCgk+ID4gPiBvdGhlciBpbnRlcm5hbA0KCT4gPiA+ID4gPiAgICAgICBmdW5jdGlvbnMg YXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkDQoJPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydA0KCT4gPiA+ID4gPiAgICAgICBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBi ZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KCT4gPiA+ID4gPiAgICAgICByZWxhdGlvbnNoaXAgb2Yg dGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KCT4gPiA+ID4gZGlyZWN0aW9ucyBvZiB0aGF0 DQoJPiA+ID4gPiA+ICAgICAgIHRyYW5zcG9ydCBwYXRoLg0KCT4gPiA+ID4gPiA8ZW5kIHF1b3Rl Pg0KCT4gPiA+ID4gDQoJPiA+ID4gPiBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9u YWwgcmVxdWlyZW1lbnQuIFRoYXQNCgk+ID4gaXMsIHRoZXJlIGlzDQoJPiA+ID4gPiAqbm90aGlu ZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZg0KCT4gPiB2 aWV3IHRoYXQNCgk+ID4gPiA+IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVt ZW50Lg0KCT4gPiA+ID4gDQoJPiA+ID4gPiBUaGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0 aGF0IHRoaXMgcmVxdWlyZW1lbnQgaXMgbWV0IGJ5IA0KCT4gPiA+ID4gY29uZmlndXJpbmcgc29t ZSBkYXRhIHBsYW5lIGRhdGFiYXNlIGNvbXBvbmVudCB0aHJvdWdoIHRoZSANCgk+ID4gPiA+IG1h bmFnZW1lbnQgcGxhbmUuIFRoZSBkYXRhYmFzZSBjb21wb25lbnQgaXMgbm90IHVzZWQNCgk+IGZv ciBhbnl0aGluZw0KCT4gPiA+ID4gZXhjZXB0IHRvIHNhdGlzZnkgdGhpcyByZXF1aXJlbWVudCBm b3IgImF3YXJlbmVzcyIuDQoJPiA+ID4gPiANCgk+ID4gPiA+IEJlbiEgQ2FuIHdlIHBsZWFzZSB0 cnkgdG8gcmV3cml0ZSB0aGlzIHJlcXVpcmVtZW50IGluIHRlcm1zIG9mIA0KCT4gPiA+ID4gYmVo YXZpb3I/DQoJPiA+ID4gPiANCgk+ID4gPiA+ID4gUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJlbWVu dCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZQ0KCT4gPiA+ID4gbGlzdCB0aGF0IGlzDQoJPiA+ ID4gPiA+IHNwZWNpZmljIGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhlIHBh aXJpbmcNCgk+ID4gPiA+IHJlcXVpcmVtZW50cw0KCT4gPiA+ID4gPiBhdCBlbmQgcG9pbnRzIGZv ciBjby1yb3V0ZWQgYW5kIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbA0KCT4gPiA+IHBhdGhzIGFy ZQ0KCT4gPiA+ID4gPiBleGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhleSBhcHBlYXIgaW4gdHdv IGRpZmZlcmVudA0KCT4gPiA+IGl0ZW1zIGluIHRoZQ0KCT4gPiA+ID4gPiByZXF1aXJlbWVudHMn IGxpc3QpLg0KCT4gPiA+ID4gPiBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVudCAz NCB0aGUgbm90aW9uIG9mDQoJPiBjby1yb3V0ZWQNCgk+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBw YXRocyB3b3VsZCBiZSB2b2lkIG9mIGFueSBkYXRhIHBsYW5lIGNvbnRlbnQuDQoJPiA+ID4gPiA+ DQoJPiA+ID4gPiA+IFRoZSBzb21ld2hhdCB2YWd1ZSBzY29wZSBvZiB0aGlzIHJlcXVpcmVtZW50 ICgib3RoZXIgaW50ZXJuYWwgDQoJPiA+ID4gPiA+IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSIp IGNyZWF0ZXMgYSBzdXNwaWNpb24gdGhhdCBIVw0KCT4gPiA+ID4gc3VwcG9ydCBvZiB0aGUNCgk+ ID4gPiA+ID4gcGFpcmluZyBhd2FyZW5lc3MgbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRvIGNv bXBseSB3aXRoIGl0Lg0KCT4gPiA+ID4gDQoJPiA+ID4gPiBUaGUgZW50aXJldHkgb2YgdGhlIGJy YWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBzLA0KCT4gPiBNSVBzIGFuZCBvdGhlcg0KCT4g PiA+ID4gaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRlbGV0 ZWQuIEl0DQoJPiA+IGRvZXMgbm90DQoJPiA+ID4gPiBhZGQgdG8gIlRoZSBpbnRlcm1lZGlhdGUg bm9kZXMuIg0KCT4gPiA+ID4gDQoJPiA+ID4gPiA+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUg ZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KCT4gPiA+ID4gPg0KCT4gPiA+ID4gPiA8 cXVvdGU+DQoJPiA+ID4gPiA+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rp b24gaXMgYW4NCgk+ID4gYXJiaXRyYXJ5IHBhcnQgb2YgYQ0KCT4gPiA+ID4gPiAgIHRyYW5zcG9y dCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkNCgk+ID4gPiA+IGluZGVwZW5k ZW50bHkgZnJvbSB0aGUNCgk+ID4gPiA+ID4gICBlbmQtdG8tZW5kIG1vbml0b3JpbmcgKE9BTSku ICBJdCBtYXkgYmUgYSBtb25pdG9yZWQNCgk+ID4gc2VnbWVudCBvciBhDQoJPiA+ID4gPiA+ICAg bW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguICANCgk+ ID4gVGhlIHRhbmRlbQ0KCT4gPiA+ID4gPiAgIGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0 aGUgZm9yd2FyZGluZyBlbmdpbmUocykgb2YNCgk+ID4gPiA+IHRoZSBub2RlKHMpDQoJPiA+ID4g PiA+ICAgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21l bnQuDQoJPiA+ID4gPiA+IDxlbmQgcXVvdGU+DQoJPiA+ID4gPiANCgk+ID4gPiA+IEFjdHVhbGx5 LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQNCgk+ID4gaW5zaXN0ZW5j ZSBvbiB0aGUNCgk+ID4gPiA+IGluY2x1c2lvbiBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUg ZGVmaW5pdGlvbiB3aXRoaW4NCgk+ID4gdGhlIElUVS1UIG9mDQoJPiA+ID4gPiB0aGlzIHRlcm0g aXMgcG9vcmx5IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUNCgk+IG1vbml0b3Jpbmcgb2Yg YQ0KCT4gPiA+ID4gcGF0aCB0aGF0IGlzIHBhcmFsbGVsIChpLmUuIHRhbmRlbSkgdG8gdGhlIGRh dGEgcGF0aCBiZWluZyANCgk+ID4gPiA+IG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRD IHNlZW1zIHRvIGJlIGF0IHZhcmlhbmNlLA0KCT4gPiBhbmQgd291bGQNCgk+ID4gPiA+IGJlIGlm IHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQoJPiA+ID4gPiANCgk+ID4gPiA+ID4gRG9l c24ndCAiZm9yd2FyZGluZyBlbmdpbmUiIHNvdW5kIGxpa2UgaGFyZHdhcmUgdG8geW91Pw0KCT4g PiA+ID4gDQoJPiA+ID4gPiBZZXMsIGJ1dCBzbyB3aGF0Pw0KCT4gPiA+ID4gDQoJPiA+ID4gPiA+ IElNSE8gaXQgaXMgd29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUA0KCT4gPiA+ IFJlcXVpcmVtZW50cyBkcmFmdA0KCT4gPiA+ID4gPiBub3IgdGhlIE1QTFMtVFAgT0FNIHJlcXVp cmVtZW50cyBvbmUNCgk+ID4gPiA+ID4gDQoJPiA+ID4gPiANCgk+ID4gPiANCgk+ID4gDQoJPiAo aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9h bS1yZXF1aXJlbWVuDQoJPiA+ID4gPiA+IHRzLTAxLnR4dCkgY29udGFpbiBhbnkgcmVxdWlyZW1l bnRzIGRlYWxpbmcgd2l0aCB0YW5kZW0NCgk+ID4gPiBjb25uZWN0aW9ucy4NCgk+ID4gPiA+ID4N Cgk+ID4gPiA+ID4gQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBN UExTLVRQIE9BTQ0KCT4gPiBGcmFtZXdvcmsNCgk+ID4gPiA+ID4gZHJhZnQNCgk+ID4gPiA+ICho dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2Ft LWZyDQoJPiA+ID4gPiBhbWV3b3JrLTAwLnR4dA0KCT4gPiA+ID4gKS4NCgk+ID4gPiA+IA0KCT4g PiA+ID4gUmlnaHQuDQoJPiA+ID4gPiBMZXQncyBqdXN0IGdldCByaWQgb2YgYW4gdW5uZWNlc3Nh cnkgdGVybSBhbmQgYnJpbmcgYWxsDQoJPiB0aGUgSS1Ecw0KCT4gPiA+ID4gaW50byBsaW5lLg0K CT4gPiA+ID4gDQoJPiA+ID4gPiA+IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21l IGNsYXJpdHkgcmVnYXJkaW5nDQoJPiA+ID4gY28tcm91dGVkIHZzLg0KCT4gPiA+ID4gPiBhc3Nv Y2lhdGVkDQoJPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMgaXMgc3RpbGwgcmVxdWlyZWQu IE9uZSB3YXkgdG8gcHJvdmlkZQ0KCT4gPiA+ID4gdGhhdCBjb3VsZA0KCT4gPiA+ID4gPiBiZSBi eSBleHBsaWNpdGx5IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNwZWNpZmljDQoJPiA+ID4g ZnVuY3Rpb25hbGl0eS4NCgk+ID4gPiA+IA0KCT4gPiA+ID4gQWdyZWVkLg0KCT4gPiA+ID4gDQoJ PiA+ID4gPiBBZHJpYW4NCgk+ID4gPiA+IA0KCT4gPiA+ID4gDQoJPiA+ID4gPiANCgk+ID4gPiA+ IA0KCT4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4g PiA+ID4gRnJvbTogQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a10NCgk+ID4gPiA+ IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTQ0KCT4gPiA+ID4gVG86IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPDQoJPiA+ID4gPiBDYzog bXBscy10cEBpZXRmLm9yZw0KCT4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQoJPiA+ID4gPiByZXF1aXJlbWVudHMN Cgk+ID4gPiA+IA0KCT4gPiA+ID4gSGkgU2FzaGEsDQoJPiA+ID4gPiANCgk+ID4gPiA+IE5vdCBy ZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwgYnV0Li4u DQoJPiA+ID4gPiANCgk+ID4gPiA+ID4gMS4gTXkgcmVhZGluZyBvZiAgb25lIG9mIEJlbidzICBt ZXNzYWdlcyBpcyB0aGF0IGFzc29jaWF0ZWQgDQoJPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0 aHMgYXJlIHRoZSBvbmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQgY2FuIGJlDQoJPiA+ID4gPiBjcmVh dGVkIGluDQoJPiA+ID4gPiA+IHRoZSBleGlzdGluZyBuZXR3b3JrczsgInRydWUiIGNvLXJvdXRl ZCBiaWRpcmVjdGlvbmFsIHBhdGhzDQoJPiA+ID4gPiB3aWxsIGhhdmUNCgk+ID4gPiA+ID4gdG8g d2FpdCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVudCBiZWNvbWVzIGF2YWlsYWJsZS4NCgk+ ID4gPiA+IA0KCT4gPiA+ID4gVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlIQ0KCT4gPiA+ID4gRnJv bSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkDQoJPiA+IGJpZGlyZWN0 aW9uYWwgTFNQcyBhcmUNCgk+ID4gPiA+IGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCBMU1BzLg0KCT4gPiA+ID4gDQoJPiA+ID4gPiBJZiB5b3UgY2FuIHNldCB1cCB0 d28gdW5pZGlyZWN0aW9uYWwgTFNQcyAoZS5nLiB1c2luZyB0aGUNCgk+ID4gbWFuYWdlbWVudA0K CT4gPiA+ID4gcGxhbmUpIHlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZA0KCT4gPiA+ IGJpZGlyZWN0aW9uYWwgTFNQLg0KCT4gPiA+ID4gDQoJPiA+ID4gPiBUaGVyZSBhcmUgc2hpcHBp bmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0ZWQNCgk+IGJpZGlyZWN0aW9uYWwNCgk+ ID4gPiA+IExTUHMgdXNpbmcgdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVpdGhlciB1c2UgdGhl IEdNUExTDQoJPiA+ICh3aGljaCBpcw0KCT4gPiA+ID4gY2xlYW5lcikgb3Igbm9uLXN0YW5kYXJk IHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMNCgk+ID4gbWVzc3kgYnV0DQoJPiA+ID4g PiBmdW5jdGlvbmFsKS4NCgk+ID4gPiA+IA0KCT4gPiA+ID4gQnV0IChvZiBjb3Vyc2UpIHRoZSBt YW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wgcGxhbmUNCgk+ID4gc29sdXRpb25zIGhhdmUNCgk+ ID4gPiA+IG5vdGhpbmcgdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50IGFzIHRo ZXkNCgk+IGFyZSBzb2Z0d2FyZQ0KCT4gPiA+ID4gc29sdXRpb25zLg0KCT4gPiA+ID4gDQoJPiA+ ID4gPiA+IDIuIE15IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRo ZSBhY3R1YWwNCgk+ID4gPiA+IGRyaXZlciBmb3INCgk+ID4gPiA+ID4gY28tcm91dGVkIGJpZGly ZWN0aW9uYWwgcGF0aHMgbWF5IGJlIGV4cGVyaWVuY2Ugd2l0aCBleGlzdGluZyANCgk+ID4gPiA+ ID4gdHJhbnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFuIGFueSBzcGVjaWZpYyBiZW5lZml0Lg0K CT4gPiA+ID4gDQoJPiA+ID4gPiBJc24ndCB0aGF0IHRoZSBjYXNlIHdpdGggNzUlIG9mIHRoZSBN UExTLVRQIHJlcXVpcmVtZW50cz8NCgk+ID4gPiA+IFdoaWNoIGlzIG5vdCB0byBzYXkgaXQgaXMg YSBiYWQgdGhpbmcuDQoJPiA+ID4gPiANCgk+ID4gPiA+IEEgbGFyZ2UgZHJpdmVyIGZvciBNUExT LVRQIGlzIHRvIGdpdmUgdGhlIHBhY2tldCBuZXR3b3JrDQoJPiA+IHRoZSBsb29rLA0KCT4gPiA+ ID4gZmVlbCwgYW5kIGJlaGF2aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgImxlZ2FjeSINCgk+ ID4gPiA+IHRyYW5zcG9ydCBuZXR3b3JrLg0KCT4gPiA+ID4gDQoJPiA+ID4gPiA+IEJhc2VkIG9u IHRoZXNlIG9ic2VydmF0aW9ucywgSSdkIGd1ZXNzIChGV0lXKSB0aGF0Og0KCT4gPiA+ID4gPiAq IGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0IGZvciB0aGUgdGlt ZQ0KCT4gPiA+ID4gPiAgICBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2YgYmlkaXJl Y3Rpb25hbCBwYXRocyBpbg0KCT4gPiA+ID4gPiAgICBNUExTLVRQDQoJPiA+ID4gPiANCgk+ID4g PiA+IEkgdGhpbmsgdGhhdCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwg YW5kDQoJPiA+IGdpdmVuIHRoYXQNCgk+ID4gPiA+IG90aGVyIHVwZ3JhZGVzIHRvIGV4aXN0aW5n IE1QTFMgc29sdXRpb25zIHdpbGwgYmUNCgk+IG5lZWRlZCB0byByZWFjaA0KCT4gPiA+ID4gdGhl IGZ1bGwgZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC4NCgk+ID4gPiA+IA0KCT4gPiA+ID4gPiAq IHRoZXkgaGFkIGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUgb2YNCgk+ID4g YmlkaXJlY3Rpb25hbA0KCT4gPiA+ID4gPiAgIHBhdGhzIGluICByZWFsIGRlcGxveW1lbnRzLg0K CT4gPiA+ID4gDQoJPiA+ID4gPiBJIGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93cyBmcm9tLg0K CT4gPiA+ID4gDQoJPiA+ID4gPiBDaGVlcnMsDQoJPiA+ID4gPiBBZHJpYW4NCgk+ID4gPiA+IA0K CT4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cgk+ID4gPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQoJPiA+ID4gPiBtcGxzLXRwQGlldGYub3Jn DQoJPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHAN Cgk+ID4gPiA+IA0KCT4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCgk+ID4gPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQoJPiA+ID4gPiBtcGxz LXRwQGlldGYub3JnDQoJPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMtdHANCgk+ID4gPiA+IA0KCT4gPiA+ID4gDQoJPiA+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ID4gPiBtcGxzLXRwIG1haWxpbmcg bGlzdA0KCT4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCgk+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCgk+ID4gPiANCgk+ID4gDQoJPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4gbXBscy10cCBtYWlsaW5n IGxpc3QNCgk+IG1wbHMtdHBAaWV0Zi5vcmcNCgk+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscy10cA0KCT4gDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCgltcGxzLXRwIG1haWxpbmcgbGlzdA0KCW1wbHMtdHBAaWV0Zi5v cmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCgkNCgkN CgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KCVpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NCglUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQoNCg== ------_=_NextPart_001_01C9C27C.F2D83D8A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5MaXUsPC9GT05UPjwvU1BBTj48 L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEyNjI3NTgxMS0yMTA0 MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj5JZiBNUExTLVRQIGlzIGdvaW5nIHRvIGJlIHRha2VuIA0Kc2VyaW91 c2x5IGFzIGEgdHJhbnNwb3J0IG5ldHdvcmsgKGxpa2UgU0RIL1NPTkVUKSB0aGVuIHRoZSAyJm5i c3A7a2V5IE1VU1QgSEFWRSANCnJlcXVpcmVtZW50cyBhcmUgdGhlc2UuPC9GT05UPjwvU1BBTj48 L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEyNjI3NTgxMS0yMTA0 MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj4xJm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3ZpZGUgYSANCnRyYW5zcGFy ZW50IGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwLi4ud2hpY2ggbWVhbnM6PC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEyNjI3NTgxMS0y MTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0y Pi0mbmJzcDsmbmJzcDsmbmJzcDsgYWxsIGNsaWVudCBiaXRzIA0KdHJlYXRlZCBlcXVhbGx5PC9G T05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTEy NjI3NTgxMS0yMTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgc2l6ZT0yPi0mbmJzcDsmbmJzcDsmbmJzcDsgY2xpZW50IGJpdCANCm9yZGVyaW5nIHByZXNl cnZlZDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj4tJm5ic3A7Jm5ic3A7Jm5ic3A7IG5vIGF0dGVtcHQgdG8gDQppbmZl ciBjbGllbnQgc3ltYm9sIChpZSBzZXF1ZW5jZSBvZiBjbGllbnQgYml0cykgbWVhbmluZyBhbmQg bm8gYXR0ZW1wdCB0byANCmNoYW5nZSBjbGllbnQgc3ltYm9sczwvRk9OVD48L1NQQU4+PC9ESVY+ DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+ PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj4tJm5ic3A7 Jm5ic3A7Jm5ic3A7IHRoZSB0cmFmZmljIA0KYmVoYXZpb3VyIG9mIGNsaWVudCBYIG11c3Qgbm90 IGltcGFjdCB0aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQgYnkgY2xpZW50IA0KWTwvRk9OVD48 L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMjYyNzU4 MTEtMjEwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNp emU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9MTI2Mjc1ODExLTIxMDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBN UyIgY29sb3I9IzgwMDAwMCBzaXplPTI+QSBrZXkgY29yb2xsYXJ5IG9mIHRoZSBhYm92ZSBpcyB0 aGF0IA0KTVBMUy1UUCBtdXN0IG9ubHkgc3VwcG9ydCBwcm9wZXIgY29ubmVjdGlvbnMgKGllIHNp bmdsZSBzb3VyY2UgDQpjb25zdHJ1Y3RzKTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTI2Mjc1ODExLTIx MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTEyNjI3NTgxMS0yMTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNv bG9yPSM4MDAwMDAgc2l6ZT0yPjImbmJzcDsmbmJzcDsgU2luY2UgTVBMUy1UUCBpcyBhIA0KdHJh bnNwb3J0IG5ldHdvcmsgaXQgaXMgbm90IGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgKGllIGl0IGRv ZXMgbm90IHN1cHBvcnQgDQpkaXJlY3RseSBleHRlcm5hbCBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFw cGxpY2F0aW9ucykuJm5ic3A7IE1QTFMtVFAgdGhlcmVmb3JlIA0KZG9lcyBub3QgcmVxdWlyZSBh biBFLU5OSSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBBIGtleSBjb3JvbGxhcnkgb2YgdGhpcyBpcyB0 aGF0IA0KTVBMUy1UUCB3aWxsIG5vdCBoYXZlIGFueSBwZWVyIGludGVyd29ya2luZyByZWxhdGlv bnNoaXAgd2l0aCBhbnkgb3RoZXIgbmV0d29yayANCm1vZGUvdGVjaG5vbG9neS48L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTI2Mjc1ODEx LTIxMDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTEyNjI3NTgxMS0yMTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMi IGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+PEZPTlQgDQpm YWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5Ob3cgd3J0IE9BTSBNUExT LVRQIGlzIGEgY28tcHMgbW9kZSANCm5ldHdvcmsuJm5ic3A7IFlvdSBjb3VsZCBhcmd1ZSB0aGlz IHNob3VsZCBoYXZlIEZESS9BSVMuLi4uaG93ZXZlciwgdGhlIG1lcml0IG9mIA0KdGhpcyBpcyBo aWdobHkgcXVlc3Rpb25hYmxlLiZuYnNwOyBXaGVuIEkgYW5kIGNvbGxlYWd1ZXMgZGlzY3Vzc2Vk IHdoZXRoZXIgDQpQQkItVEUgKGFsc28gYSBjby1wcyBtb2RlIG5ldHdvcmspIHNob3VsZCBoYXZl IEZESS9BSVMgd2UgY29uY2x1ZGVkIHRoYXQgb24gDQpiYWxhbmNlIGl0IHdhcyBub3QgYSBnb29k IGlkZWEuLi4uLmFuZCBub3RlIHRoYXQgaW5pdGlhbGx5IEkgd2FzIGluIGZhdm91ciBvZiANCmhh dmluZyBBSVMsIGJ1dCBteSBjb2xsZWFndWVzIHByb3ZpZGVkIHN0cm9uZyB0ZWNobmljYWwgYXJn dW1lbnRzIHRoYXQgY29udmluY2VkIA0KbWUgb3RoZXJ3aXNlLjwvRk9OVD48L1NQQU4+PC9ESVY+ DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+ PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT0i Q29taWMgU2FucyBNUyI+PEZPTlQgc2l6ZT0yPjxGT05UIA0KY29sb3I9IzgwMDAwMD48U1BBTiBj bGFzcz0xMjYyNzU4MTEtMjEwNDIwMDk+QUlTL0ZESSBpcyBoaXN0b3JpY2FsbHkgbGlua2VkIHRv IA0KdGhlIGVhcmx5IFBESCBjby1jcyBtb2RlIGxheWVyIG5ldHdvcmtzIHRoYXQgdXNlZCBUVEwg bG9naWMuJm5ic3A7IFdoZW4gdGhpcyANCmRpZWQgaXQgcHV0IG91dCBhICs1ViAoYWxsIDFzKSBz aWduYWwgYnkgZGVmYXVsdCwgaWUgaXQgcmVxdWlyZWQgbm8gY29uc2Npb3VzIA0KZWZmb3J0IHRv IGdlbmVyYXRlIGl0Li4uLi50aGlzIGlzIGtleSBwb2ludC4mbmJzcDsgRnVydGhlciwgaW4gdGhl c2UgbmV0d29ya3MgDQp0aGVyZSBpcyBhIGZhaXJseSBzdGF0aWMvbG9uZy1ob2xkaW5nIGNsaWVu dCBzZXJ2ZXIgcmVsYXRpb25zaGlwLiZuYnNwOyBDbGVhcmx5IA0KdGhpcyBpcyBub3QgdHJ1ZSBp biB0aGUgY2wtcHMgbW9kZSBhbmQgaXQncyB3aHkgSUVURiBoYXZlIG5ldmVyIHNwZWNpZmllZCBB SVMgDQpmb3IgSVAgYW5kIGl0cyB3aHkgSUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2UgdG8gdGhyb3ct b3V0IEFJUyBpbiA4MDIuMWFnIGZvciANCkV0aGVybmV0ICh0aG91Z2ggSVRVIGhhdmUgdW53aXNl bHkgSU1PIHJldGFpbmVkIGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0IA0KYW55IG9wZXJh dG9yIHBsYW5uaW5nIHRvIHVzZSBFdGhlcm5ldCBlcXVpcG1lbnQgd291bGQgYWx3YXlzIGxvb2sg dG8gSUVFRSBzdGRzIA0KYW5kIG5vdCBJVFUgb25lcykuPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9G T05UPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT0iQ29taWMgU2Fu cyBNUyI+PEZPTlQgc2l6ZT0yPjxGT05UIA0KY29sb3I9IzgwMDAwMD48U1BBTiANCmNsYXNzPTEy NjI3NTgxMS0yMTA0MjAwOT48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Rk9O VCBzaXplPTI+PEZPTlQgDQpjb2xvcj0jODAwMDAwPjxTUEFOIGNsYXNzPTEyNjI3NTgxMS0yMTA0 MjAwOT5BSVMvRkRJIGFuZCB0aGUgY28tcHMgbW9kZSBpcyANCmRlYmF0YWJsZS4mbmJzcDsgQXMg SSBub3RlZCBhYm92ZSwgb24gYmFsYW5jZSB3ZSBjb25zaWRlcmVkIG5vdCBhIGdvb2QgaWRlYSBm b3IgDQpQQkItVEUgT0FNIGJlY2F1c2UgaXQgcmVxdWlyZXMgYSBjb25zY2lvdXMgZWZmb3J0IHRv IGdlbmVyYXRlIGl0ICh1bmxpa2UgdGhlIA0KY28tY3MgbW9kZSkgc28gdGhlcmUgYXJlIGxpa2Vs eSB0byBiZSBzY2FsaW5nIHByb2JsZW1zIGFuZCBpdHMgb25lIG1vcmUgdGhpbmcgdG8gDQpnbyB3 cm9uZy48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Rk9OVCBzaXplPTI+PEZPTlQgDQpj b2xvcj0jODAwMDAwPjxTUEFOIA0KY2xhc3M9MTI2Mjc1ODExLTIxMDQyMDA5PjwvU1BBTj48L0ZP TlQ+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxG T05UIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxGT05UIHNpemU9Mj48Rk9OVCANCmNvbG9yPSM4MDAw MDA+PFNQQU4gY2xhc3M9MTI2Mjc1ODExLTIxMDQyMDA5PllvdSBzaG91bGQgYWxzbyBoYXZlIHNl ZW4gbWUgbWFrZSANCnRoZSBwb2ludCBtYW55IHRpbWVzIGluIHRoZSBwYXN0IHRoYXQgdGhlIGFs d2F5cy1vbiBkZWZlY3QgZGV0ZWN0aW9uL2hhbmRsaW5nIA0KT0FNIG5lZWRzIHRvIGJlIGFzIHNp bXBsZS9zcGFyc2UgYXMgcG9zc2libGUgd2l0aCBhcyBsaXR0bGUgY29uZmlnIGFzIHBvc3NpYmxl IA0KYmVjYXVzZSB3ZSBuZWVkIHN1cGVyIHJlbGlhYmlsaXR5Li4uLi4uVENNIGdvZXMgY29tcGxl dGVseSBhZ2FpbnN0IHRoZSBncmFpbiANCmhlcmUuJm5ic3A7IEFsc28gbm90ZSB0aGF0IHRoZSBP QU0gcmVxdWlyZWQgZm9yIGVhY2ggb2YgdGhlIDMgbmV0d29yayBtb2RlcyBpcyANCm5vdCB0aGUg c2FtZSwgZGVzcGl0ZSB3aGF0IHNvbWUgY2xhaW0uPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05U PjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBN UyI+PEZPTlQgc2l6ZT0yPjxGT05UIA0KY29sb3I9IzgwMDAwMD48U1BBTiANCmNsYXNzPTEyNjI3 NTgxMS0yMTA0MjAwOT48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Rk9OVCBz aXplPTI+PEZPTlQgDQpjb2xvcj0jODAwMDAwPjxTUEFOIGNsYXNzPTEyNjI3NTgxMS0yMTA0MjAw OT5yZWdhcmRzLCANCk5laWw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Rk9OVCBzaXpl PTI+PEZPTlQgDQpjb2xvcj0jODAwMDAwPjxTUEFOIA0KY2xhc3M9MTI2Mjc1ODExLTIxMDQyMDA5 PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj48Rk9OVCANCmZhY2U9IkNv bWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48QlI+DQo8QkxPQ0tRVU9U RSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBC T1JERVItTEVGVDogIzgwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJ ViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVm dD4NCiAgPEhSIHRhYkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJv bTo8L0I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgW21haWx0bzptcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAgPC9CPmxpdS5ndW9tYW5AenRlLmNvbS5j bjxCUj48Qj5TZW50OjwvQj4gMjEgQXByaWwgMjAwOSAwMjo1OTxCUj48Qj5Ubzo8L0I+IA0KICBC UlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTPEJSPjxCPkNjOjwvQj4gbXBscy10cEBpZXRmLm9y ZzxCUj48Qj5TdWJqZWN0OjwvQj4gDQogIFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KICByZXF1aXJlbWVudHM8QlI+PC9GT05UPjxCUj48L0RJ Vj4NCiAgPERJVj48L0RJVj48QlI+PEZPTlQgc2l6ZT0yPjxUVD5EZWJvcmFoPC9UVD48L0ZPTlQ+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICBzaXplPTI+OjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+Jm5ic3A7bWF5YmUgd2hhdCB5b3Ugc2FpZCBpcyANCiAgcmlnaHQu IGJ1dCBJIGNhbid0IGNvbXBsZXRlbHkgYWdyZWUgeW91ciBvcGluaW9ucy4gSU1PLiBtcGxzLXRw IGlzIHJlZ2FyZCBhcyANCiAgdHJhbnNwb3J0IG5ldHdvcmsgbGlrZSBTREgvU09ORVQuIHNvIGl0 IHNob3VsZCBoYXZlIEFJUy9GREkgZnVjdGlvbnMgYXMgDQogIFNESC9TT05FVC48L0ZPTlQ+IDxC Uj48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj5kbyB5b3UgdGhpbmsgc28uPC9GT05U PiANCiAgPEJSPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPmJlc3QgcmVnYXJkczwv Rk9OVD4gPEJSPjxGT05UIA0KICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPmxpdSA8L0ZPTlQ+PEJS PjxCUj48QlI+DQogIDxUQUJMRSB3aWR0aD0iMTAwJSI+DQogICAgPFRCT0RZPg0KICAgIDxUUiB2 QWxpZ249dG9wPg0KICAgICAgPFREIHdpZHRoPSIyNiUiPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTE+PEI+IkJSVU5HQVJELCBERUJPUkFIIEEsIA0KICAgICAgICBBVFRMQUJTIiAmbHQ7ZGJy dW5nYXJkQGF0dC5jb20mZ3Q7PC9CPiA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiAN CiAgICAgICAgc2l6ZT0xPuWPkeS7tuS6ujogJm5ic3A7bXBscy10cC1ib3VuY2VzQGlldGYub3Jn PC9GT05UPiANCiAgICAgICAgPFA+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4yMDA5LTA0 LTIwIDIzOjQ3PC9GT05UPiA8L1A+DQogICAgICA8VEQgd2lkdGg9IjczJSI+DQogICAgICAgIDxU QUJMRSB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgIDxUUiB2QWxp Z249dG9wPg0KICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0 PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+5pS25Lu25Lq6PC9GT05UPjwvRElWPg0KICAg ICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+Ik1hYXJ0ZW4gVmlzc2Vy cyIgDQogICAgICAgICAgICAgICZsdDttYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbSZndDssIA0K ICAgICAgICAgICAgICAmbHQ7bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZndDs8L0ZPTlQ+IA0KICAg ICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICA8 RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+5oqE6YCBPC9GT05U PjwvRElWPg0KICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+bXBs cy10cEBpZXRmLm9yZzwvRk9OVD4gDQogICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAg ICAgICA8VEQ+DQogICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5z LXNlcmlmIHNpemU9MT7kuLvpopg8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICA8VEQ+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9MT5SZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgDQogICAgICAg ICAgICAgIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQpyZXF1aXJlbWVudHM8L0ZPTlQ+ PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPg0KICAgICAgICA8VEFCTEU+DQogICAgICAgICAgPFRC T0RZPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFREPg0KICAgICAg ICAgICAgPFREPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48L1RSPjwvVEJPRFk+PC9UQUJMRT48 QlI+PEJSPjxCUj48Rk9OVCANCiAgc2l6ZT0yPjxUVD5JIGFncmVlIHdpdGggTmVpbCwgaXQgaXMg dmVyeSBxdWVzdGlvbmFibGUgdGhlIHZhbHVlIG9mIEFJUy9GREkgaW4gDQogIGE8QlI+cGFja2V0 IG5ldHdvcmstIGFueSBtb2RlLiBJdCBjYW4gcmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBhbiAN CiAgb3BlcmF0b3I8QlI+b24gdGhlbXNlbHZlcyBzbyBldmVuIFkxNzMxIHJlY29tbWVuZHMgbm90 IHRvIGJsb2NrIGRhdGEgDQogIGZyYW1lczo8QlI+IkEgTUVQIGNhbiBkZWNpZGUgd2hldGhlciBp dCBibG9ja3MgZGF0YSBmcmFtZXMgd2hlbiBpdCBkZXRlY3RzIA0KICBkQUlTLjxCUj5UaGUgcHJp bmNpcGxlIHJlcXVpcmVtZW50PEJSPnRoYXQgaW5mbHVlbmNlcyB0aGlzIGRlY2lzaW9uIGlzIHRo YXQgDQogIGRhdGEgZnJhbWVzIG91Z2h0IHRvIGJlIGZvcndhcmRlZDxCUj5hcyBtdWNoIGFzIHBv c3NpYmxlLCB3aXRob3V0PEJSPnRoZSANCiAgcG9zc2liaWxpdHkgb2YgZm9yd2FyZGluZyB3cm9u ZyBkYXRhIGZyYW1lcyBkb3duc3RyZWFtLiI8QlI+VGFibGUgSS43LTIgc2hvd3MgDQogIGZvciBB SVMsIG5vdCB0byBibG9jay48QlI+PEJSPkFuZCBhcyBZMTczMSBzdGF0ZXMsIEFJUyBjYW4gb25s eSBiZSB1c2VkIHVuZGVyIA0KICB2ZXJ5IGNvbnN0cmFpbmVkPEJSPmFyY2hpdGVjdHVyZXMgLSBp ZiByZXF1aXJlZCBmb3IgTVBMUy1UUCwgaXQgbmVlZHMgdG8gaGF2ZSANCiAgdGhlIHNhbWU8QlI+ Z3VpZGFuY2UgYXMgaW4gWTE3MzEsIGkuZS4gcG9pbnQtdG8tcG9pbnQgYW5kIHNlcnZlci9jbGll bnQgDQogIG9uZS10by1vbmU6PEJSPiJmb3IgYSBwb2ludC10by1wb2ludCBFVEggY29ubmVjdGlv biwgYSBNRVAgaGFzIG9ubHkgYSBzaW5nbGUgDQogIHBlZXIgTUVQLjxCUj5UaGVyZWZvcmUsIHRo ZXJlPEJSPmlzIG5vIGFtYmlndWl0eSByZWdhcmRpbmcgdGhlIHBlZXIgTUVQIGZvciANCiAgd2hp Y2ggaXQgc2hvdWxkIHN1cHByZXNzPEJSPmFsYXJtcyB3aGVuIGl0IHJlY2VpdmVzIHRoZTxCUj5F VEgtQUlTIA0KICBpbmZvcm1hdGlvbi4iPEJSPlNvIHNob3VsZCBvbmx5IGJlIHdpdGhpbiBvbmUg ZG9tYWluIC0gdGhlbiBubyANCiAgbmVlZC48QlI+PEJSPkRlYm9yYWg8QlI+PEJSPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPEJSPkZyb206IA0KICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uPEJSPkJlaGFsZiBPZiANCiAgTWFh cnRlbiBWaXNzZXJzPEJSPlNlbnQ6IE1vbmRheSwgQXByaWwgMjAsIDIwMDkgMTA6MDUgQU08QlI+ VG86IA0KICBuZWlsLjIuaGFycmlzb25AYnQuY29tPEJSPkNjOiBtcGxzLXRwQGlldGYub3JnPEJS PlN1YmplY3Q6IFJlOiBbbXBscy10cF0gDQogIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgDQogIHBhdGg8QlI+cmVxdWlyZW1lbnRzPEJSPjxCUj5OZWlsLDxCUj48QlI+Jmd0OyBi dXQgQUlTL0ZESSBpbiB0aGUgY2wgbW9kZT8uLi5kbyANCiAgbWUgYSBmYXZvdXIhPEJSPjxCUj5F dGhlcm5ldCBBSVMgaXMgaW5kZWVkIGEgcmVxdWlyZW1lbnQgYW5kIGEgbmVjZXNzaXR5LiBBbmQg DQogIHlvdSB3aWxsIG5vdDxCUj5iZTxCUj5hYmxlIHRvIHVuZGVyc3RhbmQgdGhhdCBhcyBsb25n IGFzIHlvdSByZWZ1c2UgdG8gYWNjZXB0IA0KICB0aGF0ICJjbC1tb2RlIjxCUj5pcyBhPEJSPmZv cndhcmRpbmcgbW9kZSB3aXRoaW4gYSAqKnRyYW5zcG9ydCBlbnRpdHkqKi4gRy44MDAgDQogIGFt ZW5kbWVudCAxIGhhczxCUj5maW5hbGx5PEJSPnJlaW50cm9kdWNlZCB0aGlzIHRyYW5zcG9ydCBl bnRpdHkgaW50byBHLjgwMC4gDQogIEJlc2lkZXMgdGhhdCwgaXQgYWxzbzxCUj5pbnRyb2R1Y2Vk IHRoZSAqKmRpZmZlcmVudGlhdGVkIA0KICBjb25uZWN0aW9uKio6PEJSPjxCUj5bRy44MDAgYW0x XSAiQSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIGlzIGEgdHJhbnNwb3J0IA0KICBlbnRpdHkg dGhhdDxCUj50cmFuc2ZlcnMgaW5mb3JtYXRpb24gYmVsb25naW5nIHRvIG11bHRpcGxlIGNvbW11 bmljYXRpb25zIA0KICBiZXR3ZWVuIHBvcnRzPEJSPmFjcm9zcyBhIHN1Ym5ldHdvcmsuICZsdDsu LiZndDsgSW4gYSBkaWZmZXJlbnRpYXRlZCANCiAgY29ubmVjdGlvbiBtZXNzYWdlPEJSPmNvbnRl bnRzPEJSPmFyZSBpbnRlcnByZXRlZCB0byBpZGVudGlmeSAoc2V0cyBvZikgDQogIGNvbW11bmlj YXRpb25zIHdoaWNoIHJlY2VpdmU8QlI+ZGlmZmVyZW50PEJSPnRyZWF0bWVudC4gJm5ic3A7VGhl IHNldHMgb2YgDQogIGNvbW11bmljYXRpb25zIG1heSBiZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZTxC Uj5mb3J3YXJkaW5nIGlkZW50aWZpZXIgb3Igb3RoZXIgDQogIGxheWVyIGluZm9ybWF0aW9uLiAm bmJzcDtPcmRlciBpcyBub3Q8QlI+bmVjZXNzYXJpbHk8QlI+cHJlc2VydmVkIGJldHdlZW4gDQog IG1lc3NhZ2VzIGJlbG9uZ2luZyB0byBzZXRzIG9mIGNvbW11bmljYXRpb25zIHJlY2VpdmluZzxC Uj5kaWZmZXJlbnQgdHJlYXRtZW50LiANCiAgJm5ic3A7U2V0cyBvZiBjb21tdW5pY2F0aW9ucyBt YXkgYmUgaWRlbnRpZmllZCBmb3I8QlI+cHVycG9zZXM8QlI+c3VjaCBhcyANCiAgdHJhZmZpYyBj b25kaXRpb25pbmcgb3IgcHJlc2VydmluZyBjb21tdW5pY2F0aW9uIG1lc3NhZ2UgDQogIG9yZGVy LiI8QlI+PEJSPjxCUj5FdGhlcm5ldCBWTEFOcyBhcmUgaW4gdGVybXMgb2YgRy44MDAgImRpZmZl cmVudGlhdGVkIA0KICBjb25uZWN0aW9ucyIuPEJSPkV0aGVybmV0PEJSPkFJUyBwcm92aWRlcyBB SVMgd2l0aGluIHRoZSBzY29wZSBvZiBzdWNoIA0KICAiZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlv biIuPEJSPklmPEJSPnlvdSBhcHBseSB0aGlzIHRvIG15IHByb3Bvc2VkIFBUTiBsYXllciANCiAg c3RhY2ssIHRoZW4gdGhlIEVWQyBsYXllcjxCUj50b3BvbG9neTxCUj53aWxsIGNvbnNpc3RzIG9m IEVWQyBsaW5rcyBzdXBwb3J0ZWQgDQogIGJ5IE1QTFMtVFAsIEV0aGVybmV0LCBQQkItVEUgYW5k PEJSPlAtT1ROPEJSPlZQIHRyYWlscyBpbnNpZGUgbWV0cm8gYW5kIGNvcmUgDQogIGRvbWFpbnMg aW50ZXJjb25uZWN0aW5nIEVWQyBtYXRyaWNlcy48QlI+V2hlbjxCUj5vbmUgb2YgdGhvc2UgRVZD IGxpbmtzIGlzIA0KICBpbnRlcnJ1cHRlZCwgZS5nLiBpbiB0aGUgY29yZSBiZXR3ZWVuIG1ldHJv IDE8QlI+YW5kPEJSPm1ldHJvIDQgKHNlZSBhdHRhY2hlZCANCiAgc2xpZGUpLCB0aGVuIHRoZSBF VkMgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbjxCUj50aGF0IGlzPEJSPnByZXNlbnQgb24gdGhp cyANCiAgbGluayB3aWxsIGJlIGludGVycnVwdGVkLiBBdCB0aGUgRVZDIHN3aXRjaC9icmlkZ2Ug bm9kZTxCUj5pbjxCUj5tZXRybyA0IHRoaXMgDQogIGludGVycnVwdGlvbiBpcyBub3RpY2VkIGFu ZCBFVkMtQUlTIGlzIGluc2VydGVkIGluIHRoZTxCUj5kb3duc3RyZWFtIGRpcmVjdGlvbiANCiAg dG8gc3VwcHJlc3MgdGhlIEVWQy1MT0MgYWxhcm1zIGF0IEVWQyBlbmRwb2ludHMgRDQ8QlI+YW5k PEJSPkQ1LjxCUj48QlI+VGhlIA0KICBFVkMtQUlTIChpLmUuIEV0aGVybmV0IEFJUykgZnJhbWUg aGFzIGEgcmVzZXJ2ZWQgbXVsdGljYXN0IGFkZHJlc3MsPEJSPndoaWNoIA0KICBndWFyYW50ZWVz IHRoYXQgdGhlIEFJUyBpcyBicm9hZGNhc3QgdG8gdGhlIGVuZHBvaW50cyBvZiB0aGUgRVZDLjxC Uj48QlI+SSANCiAgYmVsaWV2ZSB0aGF0IGl0IGlzIHRpbWUgZm9yIHlvdSB0byBhZGFwdCB5b3Vy IHZpZXcgb24gY28gYW5kIGNsIA0KICBtb2RlczxCUj5hbmQ8QlI+cmVsYXRlIGl0IHRvIHRoZSBm b3J3YXJkaW5nIG1vZGUgKipJTlNJREUqKiBhIHRyYW5zcG9ydCANCiAgZW50aXR5LiA8QlI+PEJS PldoYXQgd2Uga25vdyBhcyB0aGUgaW50ZXJuZXQgaXMgZXNzZW50aWFsbHkgYW4gIklQIA0KICBk aWZmZXJlbnRpYXRlZDxCUj5jb25uZWN0aW9uIiB3aXRoIGEgYmlsbGlvbiBvciBtb3JlIHBvcnRz LjxCUj5XaGF0IHdlIGtub3cgYXMgDQogIGFuIElQIFZQTiBpcyBlc3NlbnRpYWxseSBhbiAiSVAg ZGlmZmVyZW50aWF0ZWQ8QlI+Y29ubmVjdGlvbiI8QlI+d2l0aCBlLmcuIG4gDQogIHBvcnRzIChu IGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuPEJSPldoYXQgd2Uga25vdyBhcyBhbiBF dGhlcm5ldCBWTEFOIA0KICBpcyBlc3NlbnRpYWxseSBhbiAiRXRoZXJuZXQ8QlI+ZGlmZmVyZW50 aWF0ZWQ8QlI+Y29ubmVjdGlvbiIgd2l0aCBuIHBvcnRzIChuIA0KICBpbiB0aGUgcmFuZ2Ugb2Yg ZS5nLiAyIHRvIDEwMDApLjxCUj5XaGF0IHdlIGtub3cgYXMgYSBwMnAgTVBMUyBFLUxTUCBpcyAN CiAgZXNzZW50aWFsbHkgYW4gIk1QTFMgZGlmZmVyZW50aWF0ZWQ8QlI+Y29ubmVjdGlvbiIgd2l0 aCAyIHBvcnRzLjxCUj5XaGF0IHdlIA0KICBrbm93IGFzIGEgcDJwIFNESCBWQy1uIGlzIGEgIlNE SCBWQy1uIGNvbm5lY3Rpb24iIHdpdGggMiANCiAgcG9ydHMuPEJSPjxCUj5UcmFuc3BvcnQgbmV0 d29yayBPQU0gYXBwbGllcyB0byB0cmFuc3BvcnQgZW50aXRpZXMsIHdoaWNoIGFyZSANCiAgKGlu IHRlcm1zPEJSPm9mPEJSPkcuODAwIGFtMSkgY29ubmVjdGlvbnMgYW5kIGRpZmZlcmVudGlhdGVk IA0KICBjb25uZWN0aW9ucy48QlI+PEJSPlJlZ2FyZHMsPEJSPk1hYXJ0ZW48QlI+PEJSPi0tLS0t T3JpZ2luYWwgDQogIE1lc3NhZ2UtLS0tLTxCUj5Gcm9tOiBuZWlsLjIuaGFycmlzb25AYnQuY29t IFttYWlsdG86bmVpbC4yLmhhcnJpc29uQGJ0LmNvbV0gDQogIDxCUj5TZW50OiB2cmlqZGFnIDE3 IGFwcmlsIDIwMDkgMjI6MDA8QlI+VG86IEpvaG4uRS5EcmFrZTJAYm9laW5nLmNvbTsgDQogIEl0 YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ7PEJSPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tOyANCiAgbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb208QlI+Q2M6IG1wbHMtdHBAaWV0 Zi5vcmc8QlI+U3ViamVjdDogUkU6IFttcGxzLXRwXSANCiAgQXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCBwYXRoPEJSPnJlcXVpcmVtZW50czxCUj48QlI+Sm9obiwgDQogICZuYnNw O1RoYW5rcyB0aGlzIGlzIGEgZ3JlYXQgcGxhdGZvcm0gdG8gZXhwbGFpbiB3aHkgT0FNIGZvciB0 aGUgDQogIDM8QlI+bmV0d29yazxCUj5tb2RlcyBuZWVkcyB0byBiZSBkaWZmZXJlbnQuICZuYnNw O0kgYW0gZ2V0dGluZyBhIHdlZSBiaXQgDQogIHRpcmVkIG9mIGZvbGtzPEJSPnRyeWluZzxCUj50 byBtYWtlIGFsbCAzIG5ldHdvcmsgbW9kZXMgbG9vayBhbGlrZSAoYW5kIHRoZW4sIA0KICBldmVu IHdvcnNlLCBpbnRlcndvcms8QlI+dGhlbTxCUj5hcyBhcyBwZWVycy4uLmVzcCB3aGVuIG5vdCBu b3QgDQogIHRvcC1vZi1zdGFjazxCUj5uZXR3b3Jrcy4uLkkgbWVhbiBob3cgc2lsbHkgY2FuIHdl IGdldD8pLiAmbmJzcDsgSSBhbSBldmVuIA0KICBtb3JlIGZydXN0cmF0ZWQgYnk8QlI+dGhlIGZh Y3QgdGhvc2UgcGVkZGxpbmcgdGhpcyBGVUQgb25seSBldmVyIHNlZW0gdG8gDQogIGNvbnNpZGVy IE9BTSBhbmQ8QlI+Zm9yZ2V0PEJSPmFsbCBvdGhlciBEUC9DUC9NUCBjb21wb25lbnRzIChlc3Ag dG9wLW9mLXN0YWNrIA0KICBtZXNzYWdlL2ZpbGUvc3RyZWFtPEJSPmFwcGxpY2F0aW9uIGFkYXB0 YXRpb25zKS4gJm5ic3A7SG93IHdyb25nIGNhbiB0aGlzIGdldCEgDQogIDxCUj48QlI+SW4gdGhl IGNvIG1vZGVzIGEgKmNvbm5lY3Rpb24qIGlzIGEgdmVyeSBzcGVjaWZpYyBhbmQgDQogICpjb25z dHJhaW5pbmcqPEJSPmNvbnN0cnVjdC4uLi4uSSBhbSBhc3N1bWluZyBoZXJlIHdlIHJlc3BlY3Qg dGhlIHJ1bGVzIG9mIGEgDQogIGNvbm5lY3Rpb248QlI+KGllPEJSPnNpbmdsZSBzb3VyY2UpIHRo b3VnaCBzb21lIGZvbGtzIGRvbid0IGV2ZW4gYm90aGVyIHRvIA0KICByZXNwZWN0IHRoaXMsIGFu ZDxCUj50aGlzPEJSPmlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBhbGwga25vdyB3aGF0IA0K ICBwcm9ibGVtcyBtdWx0aXBsZS1zb3VyY2U8QlI+Y29uc3RydWN0cyBjYW4gY2F1c2UgKGZyb20g TERQL1BIUC4uLi5lcmdvIA0KICBNUExTLVRQKS48QlI+PEJSPldoZW4gd2UgaGF2ZSBhIGNvbm5l Y3Rpb24gdGhpcyByZXN0cmljdHMgKmFsbCogRFAgKGllIHRyYWZmaWMgDQogIGFuZCBPQU0pPEJS PnRvPEJSPnN0YXkgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIGNvbm5lY3Rpb24uICZuYnNwO1do aWNoIGlzIA0KICBmaW5lIHVuZGVyPEJSPmRlZmVjdC1mcmVlPEJSPmNvbmRpdGlvbnMsIGJ1dCBp ZiB3ZSBoYXZlIGxlYWtpbmcgdHJhZmZpYyB0aGVuIA0KICB0aGUgY29uc3RyYWluaW5nIG5hdHVy ZTxCUj5vZjxCUj50aGUgY29ubmVjdGlvbiBjb25zdHJ1Y3QgaXMgYnJva2VuLiAmbmJzcDtJbiAN CiAgYSBudXRzaGVsbCB3aGF0IHRoaXMgbWVhbnMgaXM8QlI+dGhhdDxCUj5PQU0gdGhhdCBpcyBv ZiBhIHJlcXVlc3QvcmVzcG9uc2UgDQogIG5hdHVyZSBjYW5ub3QgYmUgdHJ1c3RlZCBpbiBjbyBt b2RlPEJSPm5ldHdvcmtzIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSANCiAgZGVmZWN0cy4uLi4uaW5k ZWVkLCB3aHkgc2hvdWxkIGEgbGVha2luZzxCUj5EUDxCUj5oYXZlIGEgc3ltbWV0cmljIGdvL3Jl dHVybiANCiAgZGVmZWN0IGJlaGF2aW91cj8uLi4udmVyeSBsaWtlbHkgaXQgd29uJ3QuPEJSPlNv PEJSPndoaWxzdCByZXF1ZXN0L3Jlc3BvbnNlIA0KICBPQU0gaXMgcmlnaHQgZm9yIHRoZSBjbCBt b2RlIGl0IGlzIG5vdCByaWdodCBmb3I8QlI+dGhlPEJSPmNvIG1vZGUgdW5kZXIgDQogIG1pc2Nv bm5lY3Rpdml0eSBkZWZlY3QgY29uZGl0aW9ucy48QlI+PEJSPk1vcmUgZ2VuZXJhbGx5IHRoZSAz IG1vZGVzIGFyZSANCiAgZGlmZmVyZW50IGFuZCBub3QganVzdCBpbiBPQU08QlI+cmVxdWlyZW1l bnRzLi4uLmJ1dCBBSVMvRkRJIGluIHRoZSBjbCANCiAgbW9kZT8uLi5kbyBtZSBhIGZhdm91ciEu Li5hdCBsZWFzdDxCUj5JRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgDQog IEV0aGVybmV0IGV2ZW4gdGhvdWdoIGl0IHJlbWFpbnM8QlI+aW48QlI+WS4xNzMxLiAmbmJzcDtB bmQgd2hpY2ggaXMgd2h5IEkgDQogIG9mdGVuIHRyb3Qtb3V0IHRoZSByYXRoZXIgc2lsbHkgKHRv IGhhdmUgdG88QlI+c2F5PEJSPnRoaXMpIG9ic2VydmF0aW9uIHRoYXQgDQogIGlmIElQIChjbCBt b2RlKSBjb3VsZCBkbyBpdCBhbGwgdGhlbiB3aHkgaGF2ZTxCUj5JRVRGPEJSPmZvdW5kIGl0IG5l Y2Vzc2FyeSB0byANCiAgY3JlYXRlIE1QTFMgKGNvLXBzKSBhbmQgR01QTFMgKENQIGZvciBjby1j cykuICZuYnNwO1RoZTxCUj5hbnN3ZXIgbGllcyBpbiB0aGUgDQogIHBoeXNpY3MuLi5hbmQgRy44 MDAgYXR0ZW1wdHMgdG8gZXhwbGFpbiB0aGF0PEJSPnBoeXNpY3MuLi4uRy44MDUgZG9lcyANCiAg bm90LjxCUj48QlI+U28sIHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQuLi5wbGVhc2UgYWNjZXB0 L3Jlam9pY2UgaW4gdGhpcyBmYWN0IA0KICBhczxCUj50aGV5PEJSPmFsbCBvZmZlciBzb21ldGhp bmcgZGlmZmVyZW50L2ltcG9ydGFudC4gJm5ic3A7QnV0IGRvIG5vdCBiZSANCiAgaG9vZHdpbmtl ZCBieTxCUj50aG9zZTxCUj53aG8gcGVkZGxlIGEgc3RvcnkgdGhhdCB0aGF0IHRyaWVzIHRvIG1h a2UgdGhlIE9BTSANCiAgb2YgdGhlIDMgbW9kZXMgdGhlPEJSPnNhbWUuIDxCUj48QlI+cmVnYXJk cywgTmVpbCA8QlI+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCANCiAgTWVzc2FnZS0tLS0tPEJSPiZn dDsgRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnPEJSPiZndDsgDQogIFttYWlsdG86bXBs cy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4gRTxCUj4mZ3Q7 IFNlbnQ6IDE3IA0KICBBcHJpbCAyMDA5IDIwOjAyPEJSPiZndDsgVG86IEJVU0kgSVRBTE87IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIA0KICBWaXNzZXJzPEJSPiZndDsgQ2M6IG1wbHMt dHBAaWV0Zi5vcmc8QlI+Jmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgDQog IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggPEJSPiZndDsgcmVxdWlyZW1lbnRzPEJSPiZn dDsgPEJSPiZndDsgDQogIEl0YWxvLDxCUj4mZ3Q7IDxCUj4mZ3Q7IEFzIGRlc2NyaWJlZCBpbiB0 aGUgTVBMUyBUUCBPQU0gUmVxdWlyZW1lbnRzIEktRCwgDQogIHZpcnR1YWxseSBhbGwgb2YgdGhl PEJSPjxCUj4mZ3Q7IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJldHVybiBwYXRoLCBhbmQgaW4g DQogIHRoZSBhYnNlbmNlIG9mIGEgcmV0dXJuIDxCUj4mZ3Q7IHBhdGggdGhleSBhcmUgZGlzYWJs ZWQuPEJSPiZndDsgPEJSPiZndDsgQXMgDQogIGRlc2NyaWJlZCBpbiBEYXZpZCBTaW5pY3JvcGUn cyBtZWV0aW5nIG1pbnV0ZXMgPEJSPiZndDsgDQogIChodHRwOi8vd2lraS50b29scy5pZXRmLm9y Zy9taXNjL21wbHMtaW50ZXJvcC9hdHRhY2htZW50L3dpa2kvPEJSPiZndDsgDQogIG1lZXRpbmct bm88QlI+Jmd0OyB0ZXMvMjAwODEwMTUubXBscy1pbnRlcm9wLWR0LW5vdGVzLnppcCksIGlmIElQ IGFkZHJlc3NpbmcgDQogIGlzIHVzZWQsIGFuIDxCUj4mZ3Q7IE1QTFMgVFAgbmV0d29yayBuZWVk cyB0byBiZSBjYXBhYmxlIG9mIGdldHRpbmcgSVAgcGFja2V0cyANCiAgZnJvbSA8QlI+Jmd0OyBk ZXN0aW5hdGlvbiB0byBzb3VyY2U7IG5laXRoZXIgdGhlIG1pbnV0ZXMgbm9yIEkgc3RpcHVsYXRl IHRoYXQgDQogIGEgPEJSPiZndDsgY29udHJvbCBwbGFuZSBuZWVkcyB0byBiZSB1c2VkIHRvIGlu c3RhbnRpYXRlIHRoaXMgDQogIGZvcndhcmRpbmcuPEJSPiZndDsgPEJSPiZndDsgQXMgYW4gYXNp ZGUsIHRoZSBpc3N1ZSBvZiByZXR1cm4gcGF0aCBmb3IgDQogIHVuaWRpcmVjdGlvbmFsIExTUHMg Y291bGQgYmU8QlI+PEJSPiZndDsgY2hhcmF0ZXJpemVkIGFzIHRoZSBlbGVwaGFudCBpbiB0aGUg DQogIHJvb20uICZuYnNwO0luIHRoZSBNUExTIFRQIE9BTSA8QlI+Jmd0OyBGcmFtZXdvcmsgSS1E LCB1bmljYXN0IExTUHMgYXJlIG9ubHkgDQogIG1lbnRpb25lZCB0aHJlZSB0aW1lcyBhbmQgcmV0 dXJuIDxCUj4mZ3Q7IHBhdGhzIG5vdCBhdCBhbGwuPEJSPiZndDsgPEJSPiZndDsgDQogIFRoYW5r cyw8QlI+Jmd0OyA8QlI+Jmd0OyBKb2huPEJSPiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxCUj4mZ3Q7IA0KICAmZ3Q7IEZyb206IEJVU0kgSVRBTE8gW21haWx0bzpJdGFsby5C dXNpQGFsY2F0ZWwtbHVjZW50Lml0XTxCUj4mZ3Q7ICZndDsgU2VudDogDQogIEZyaWRheSwgQXBy aWwgMTcsIDIwMDkgMTo1OSBBTTxCUj4mZ3Q7ICZndDsgVG86IERyYWtlLCBKb2huIEU7IEFsZXhh bmRlciANCiAgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzPEJSPiZndDsgJmd0OyBDYzogbXBs cy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgDQogIFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIDxCUj4mZ3Q7ICZndDsgDQogIHJl cXVpcmVtZW50czxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBKb2huLDxCUj4mZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyBJIA0KICBtaWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVtZW50IG9mIE1Q TFMtVFAgYmVpbmcgY2FwYWJsZSBvZiA8QlI+Jmd0OyAmZ3Q7IA0KICBzZW5kaW5nIHJlcGxpZXMg dG8gT0FNIHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMuPEJSPiZndDsgJmd0 OyANCiAgPEJSPiZndDsgJmd0OyBUaGlzIHJlcXVpcmVtZW50IGRvZXMgbm90IGJlbG9uZyB0byB0 aGUgZmlyc3Qgc2V0IG9mIA0KICByZXF1aXJlbWVudHMgPEJSPiZndDsgJmd0OyBJVFUtVCBpcyBl eHBlY3RpbmcgdG8gYmUgbWV0IGJ5IE9jdG9iZXIuPEJSPiZndDsgDQogICZndDsgPEJSPiZndDsg Jmd0OyBIb3dldmVyLCBJIHRoaW5rIHRoaXMgaW4gYSBwb3RlbnRpYWwgaW50ZXJlc3RpbmcgYWRk aXRpb25hbCANCiAgPEJSPiZndDsgJmd0OyByZXF1aXJlbWVudCB0byBiZSB0YWtlbiBpbnRvIGFj Y291bnQgKGF0IHdvcnN0IGluIGE8QlI+Jmd0OyANCiAgc3Vic2VxdWVudCBwaGFzZSkuPEJSPiZn dDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCB0aGlzIHJlcXVpcmVtZW50IA0KICBu ZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVyc3VzIG90aGVyIDxCUj4mZ3Q7ICZndDsgbW9yZSBpbXBv cnRhbnQgcmVxdWlyZW1lbnRzIA0KICAoZS5nLiB0aGUgcG9zc2liaWxpdHkgdG8gd29yayB3L28g SVAgPEJSPiZndDsgJmd0OyBmb3J3YXJkaW5nIGFuZCB0aGUgbmVlZCBmb3IgDQogIE9BTSB0byBj b250aW51ZSB0byBtb25pdG9yIHRoZSBkYXRhIDxCUj4mZ3Q7ICZndDsgcGxhbmUgYWxzbyBpbiBj YXNlIG9mIA0KICBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wgb3IgbWFuYWdlbWVudCA8 QlI+Jmd0OyAmZ3Q7IHBsYW5lKS48QlI+Jmd0OyANCiAgJmd0OyA8QlI+Jmd0OyAmZ3Q7IEkgYW0g b3BlbiB0byBkaXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdodCB0aW1lIA0K ICBiZWNhdXNlIDxCUj4mZ3Q7ICZndDsgSSB3aXNoIHRvIGF2b2lkIGRlbGF5aW5nIHRoZSBmaXJz dCBwaGFzZSBvZiB0aGUgZGVzaWduIA0KICBzb2x1dGlvbi48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7 ICZndDsgVGhhbmtzLCBJdGFsbzxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgJmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyBGcm9tOiANCiAgbXBs cy10cC1ib3VuY2VzQGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7IFttYWlsdG86bXBscy10cC1i b3VuY2VzQGlldGYub3JnXSANCiAgT24gQmVoYWxmIE9mIERyYWtlLCBKb2huIEU8QlI+Jmd0OyAm Z3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IA0KICA4OjAwIFBNPEJSPiZn dDsgJmd0OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzPEJS PiZndDsgDQogICZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0 OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIA0KICBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGggPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICByZXF1aXJlbWVudHM8QlI+Jmd0OyAm Z3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7IEF0IHRoZSBtZWV0aW5nIGxhc3QgZmFsbCBhdCAN CiAgSnVuaXBlciBpbiBNYXNzYWNodXNldHRzLCBJPEJSPiZndDsgJmd0OyB0aGluayBpdCB3YXM8 QlI+Jmd0OyAmZ3Q7ICZndDsgYWdyZWVkIA0KICB0aGF0IGFuIE1QTFMgVFAgbmV0d29yayBuZWVk cyB0byBoYXZlIGEgZm9yd2FyZGluZzxCUj4mZ3Q7ICZndDsgDQogIGNhcGFiaWxpdHk8QlI+Jmd0 OyAmZ3Q7ICZndDsgZm9yIG1hbmFnZW1lbnQsIGNvbnRyb2wsIGFuZCBPQU0gcGFja2V0cyAoZS5n LiwgDQogIHNlbmRpbmc8QlI+Jmd0OyAmZ3Q7IHJlcGxpZXMgdG8gT0FNPEJSPiZndDsgJmd0OyAm Z3Q7IHJlcXVlc3RzIHNlbnQgb24gDQogIHVuaS1kaXJlY3Rpb25hbCBMU1BzKSBldmVuIGlmIGl0 IGRvZXMgbm90PEJSPiZndDsgJmd0OyBoYXZlIGFuIElQPEJSPiZndDsgJmd0OyANCiAgJmd0OyBm b3J3YXJkaW5nIGRhdGEgcGxhbmUuPEJSPiZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IA0KICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IEZyb206IEFsZXhhbmRlciANCiAgVmFpbnNodGVpbjxCUj4mZ3Q7ICZndDsgJmd0OyBbbWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXTxCUj4mZ3Q7IA0KICAmZ3Q7ICZn dDsgJmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgOTo1NyBBTTxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IA0KICBUbzogTWFhcnRlbiBWaXNzZXJzPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgU3ViamVj dDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgg DQogIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyBNYWFydGVuLDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IEl0IHNlZW1zIHRoYXQgeW91J3ZlIGp1c3QgKGltcGxpY2l0bHkgDQogIGFuZCwg cHJvYmFibHksPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5hZHZlcnRlbnRseSkgc3RhdGVkIHRo ZSANCiAgZm9sbG93aW5nOjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO01QTFMtVFAgT0FNIHdpbGwgbm90IGV2ZXIgc3VwcG9ydCBNSVAgDQog IGxvb3BiYWNrIGZ1bmN0aW9uPEJSPiZndDsgJmd0OyAoYW5kIGZhdWx0PEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgbG9jYWxpemF0aW9uIA0KICB3aGljaCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uICkg Zm9yPEJSPiZndDsgJmd0OyB1bmlkaXJlY3Rpb25hbCBQMk1QPEJSPiZndDsgDQogICZndDsgJmd0 OyAmZ3Q7IGFuZCBQMlAgcGF0aHMuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogIElmIHRoaXMgc3RhdGVtZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8g YW5kIEZXSVcpPEJSPiZndDsgcmFpc2VzIGEgDQogIHZhbGlkPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgcXVlc3Rpb246PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SXMgDQogIE1QTFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIHRo ZXNlPEJSPiZndDsgdHlwZXMgb2YgdHJhbnNwb3J0PEJSPiZndDsgDQogICZndDsgJmd0OyAmZ3Q7 IHBhdGhzPzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZv ciB0aGUgDQogIHJlZmVyZW5jZSwgSVAvTVBMUyBwcm92aWRlcyB0aGlzIGtpbmQgb2Y8QlI+Jmd0 OyAmZ3Q7IGZ1bmN0aW9uYWxpdHkgDQogIHRvZGF5PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgZm9y ICh1bmlkaXJlY3Rpb25hbCAtIGJ1dCBpdCBkb2VzIG5vdCBrbm93IGFueSANCiAgb3RoZXI8QlI+ Jmd0OyAmZ3Q7IHR5cGUpIFAyUCBMU1BzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYXMgZGVzY3Jp YmVkIGluIFJGQyANCiAgNDM3OS4gQW5kIGl0cyBleHRlbnNpb24gdG8gUDJNUCBMU1BzIHNlZW1z IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICBlYXN5Li4uPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7PEJSPiZndDsgJmd0OyANCiAgJmd0OyAm Z3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJlZ2FyZHMsPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgPEJSPiZndDsgDQogICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2FzaGE8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9t OiANCiAgbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmdd PEJSPiZndDsgJmd0OyBPbiANCiAgQmVoYWxmPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgT2YgTWFh cnRlbiBWaXNzZXJzIA0KICBbbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCANCiAgMjAwOSAzOjI0IFBNPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgVG86ICdBZHJpYW4gRmFycmVsJzxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IA0KICBDYzogbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1 YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCANCiAgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8QlI+Jmd0OyAmZ3Q7 IA0KICAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRyaWFuLDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgDQogICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbHQ7cXVv dGUmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyANCiAg Jm5ic3A7VGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5kPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIG90aGVyIGludGVybmFsPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25zIA0KICBhcyBhcHBy b3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlv bmFsIA0KICB0cmFuc3BvcnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBwYXRoIGF0IGVhY2ggDQogIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUg b2YgdGhlIHBhaXJpbmc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyANCiAgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dh cmQ8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgZGlyZWN0aW9ucyBvZiB0aGF0PEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyANCiAgJm5ic3A7IHRyYW5zcG9y dCBwYXRoLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZsdDtlbmQgDQogIHF1b3Rl Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IFRoZXJlIGlzIG5vIA0KICB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQu IFRoYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgaXMsIHRoZXJlIA0KICBpczxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBi b3ggDQogIHBvaW50IG9mPEJSPiZndDsgJmd0OyAmZ3Q7IHZpZXcgdGhhdDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgcmVzdWx0cyBmcm9tIA0KICBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVt ZW50LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICBZ b3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIEl0IGlzIHZlcnkgbXVjaDxCUj4mZ3Q7 IG9ic2VydmFibGUgDQogIGlmPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyByZXF1aXJlbWVu dCBpcyBtZXQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZiANCiAgdmlldy48QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBMb29wYmFj ayANCiAgd2hlbiB0aGVyZSBpcyBhIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvLXJvdXRlZCBi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCANCiAgcGF0aC4gVGhlIE1QTFMtVFAgTEJNIHBhY2tldCA8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyByZWNlaXZlZCBhdCBhIE1JUCBuZWVkcyANCiAgdG8gYmUg cmV0dXJuZWQgKGFzIExCUjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhY2tldCkgdG8gdGhlIG9y aWdpbmF0aW5nIE1FUCANCiAgZnVuY3Rpb24gdmlhIHRoZSBvdGhlcjxCUj4mZ3Q7ICZndDsgZGly ZWN0aW9uIG9mPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIA0KICBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4gVGhpcyBvdGhlcjxCUj4mZ3Q7IGRpcmVjdGlvbjxCUj4m Z3Q7IA0KICAmZ3Q7ICZndDsgJmd0OyB3b3VsZCBub3QgYmUgYXZhaWxhYmxlIGluIGFuIGFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgDQogIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHBhdGguLi4gYW5kIHRodXMgdGhlIGxvb3BiYWNrIHRlc3Q8QlI+Jmd0OyAmZ3Q7ICZndDsgDQog IHdvdWxkIGZhaWwuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgU2ltaWxhcmx5LCB3aGVuIHdlIA0KICBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1vbml0 b3IgYTxCUj4mZ3Q7ICZndDsgc2VnbWVudCwgdGhlbjxCUj4mZ3Q7ICZndDsgDQogICZndDsgJmd0 OyB0aGlzIGlzIHBvc3NpYmxlIGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoPEJS PiZndDsgYnV0IG5vdCANCiAgaW4gYTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFzc29jaWF0ZWQg YmlkaXIgdHJhbnNwb3J0IHBhdGguIEluIHRoZSBmaXJzdCBjYXNlIA0KICB0aGUgVENNIE1FUCA8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zIGFyZSBjby1s b2NhdGVkIA0KICBhbmQgY2FuPEJSPiZndDsgZXhjaGFuZ2Ugd2hhdCBpczxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGNhbGxlZCAicmVtb3RlIA0KICBpbmZvcm1hdGlvbiIgd2hpY2ggaXMgbmVjZXNz YXJ5IGZvciBwZXJmb3JtYW5jZSA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgbW9uaXRvcmlu Zy48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBNRVAg U291cmNlIGFuZCANCiAgU2luayBmdW5jdGlvbnM8QlI+Jmd0OyAmZ3Q7IGFyZSBpbiBlLmcuIDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRpZmZlcmVudCANCiAgbm9kZXMgaW4gdGhlIG5ldHdvcmsg YW5kIFRDTSB3b3VsZCBub3QgYmUgYWJsZTxCUj4mZ3Q7ICZndDsgdG8gcHJvdmlkZTxCUj4mZ3Q7 IA0KICAmZ3Q7ICZndDsgJmd0OyBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLjxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgDQogICZndDsgJmd0OyAmZ3Q7IFRoZSBlbnRpcmV0eSBv ZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICIoaW5jbHVkaW5nIE1FUHMsPEJSPiZndDsgDQogICZndDsg Jmd0OyBNSVBzIGFuZCBvdGhlcjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGludGVybmFsPEJSPiZn dDsgJmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgc2hv dWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90PEJSPiZndDsgDQogICZndDsgJmd0OyAmZ3Q7IGFk ZCB0byAiVGhlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRlcm1lZGlhdGUgDQogIG5v ZGVzLiI8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZb3Vy IHVuZGVyc3RhbmRpbmcgaXMgDQogIG5vdCBjb3JyZWN0LiBUaGlzIHRleHQgbXVzdCBub3QgYmU8 QlI+Jmd0OyAmZ3Q7IGRlbGV0ZWQgYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICZndDsgYWxsLjxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQWN0dWFs bHksIEkgYW0gDQogIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQ8QlI+Jmd0OyAm Z3Q7ICZndDsgaW5zaXN0ZW5jZSBvbiB0aGU8QlI+Jmd0OyANCiAgJmd0OyAmZ3Q7ICZndDsgaW5j bHVzaW9uPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBvZiAiVGFuZGVtIENvbm5lY3Rpb24u IiANCiAgVGhlIGRlZmluaXRpb24gd2l0aGluIHRoZSBJVFUtVCBvZjxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IHRoaXMgdGVybTxCUj4mZ3Q7IA0KICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGlzPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgcG9vcmx5PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICZndDsg c3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZSBtb25pdG9yaW5nIG9mIGEgcGF0aCB0aGF0IGlz PEJSPiZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7IHBhcmFsbGVsIChpLmUuPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgdGFuZGVtKTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAmZ3Q7IHRvIHRoZSBk YXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24gb2YgVEM8QlI+Jmd0OyAm Z3Q7ICZndDsgDQogICZndDsgc2VlbXMgdG8gYmUgYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB2 YXJpYW5jZSw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyBhbmQgd291bGQgYmUgaWYg dGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBkb24ndCB1bmRlcnN0YW5kIHdoZXJlIHlvdXIgaW50 ZXJwcmV0YXRpb24gb2YgDQogIHRhbmRlbTxCUj4mZ3Q7ICZndDsgY29ubmVjdGlvbiBpczxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IGRlc2NyaWJlZCBpbiBJVFUtVCANCiAgcmVjb21tZW5kYXRpb25z LiBJLmUuICJmcm9tIHRoZTxCUj4mZ3Q7ICZndDsgbW9uaXRvcmluZyBvZiBhPEJSPiZndDsgJmd0 OyAmZ3Q7IA0KICAmZ3Q7IHBhdGggdGhhdCBpcyBwYXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRo ZSBkYXRhIHBhdGggYmVpbmcgPEJSPiZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7IG1vbml0b3JlZC4i PzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlz IA0KICBhICJuZXR3b3JrIGNvbm5lY3Rpb24iIGFuZCB0aGlzIG5ldHdvcms8QlI+Jmd0OyAmZ3Q7 IGNvbm5lY3Rpb24gaXMgYSANCiAgc2V0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgb2YgaW50ZXJj b25uZWN0ZWQgImxpbmsgY29ubmVjdGlvbnMiIGFuZCANCiAgIm1hdHJpeDxCUj4mZ3Q7IGNvbm5l Y3Rpb25zIi4gQTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHN1YnNldCBvZiB0aG9zZSANCiAgaW50 ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQgbWF0cml4IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGNvbm5lY3Rpb25zIA0KICBjYW4gYmUgbW9uaXRvcmVkIGFuZCBpcyB0aGVuIHJlZmVy cmVkIHRvIGFzPEJSPiZndDsgYSAidGFuZGVtPEJSPiZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7IGNv bm5lY3Rpb24iLiBUaGVyZSBpcyBubyAicGF0aCB0aGF0IGlzIHBhcmFsbGVsIHRvIHRoZTxCUj4m Z3Q7ICZndDsgDQogIGRhdGEgcGF0aCIuIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlz IG9ubHkgYWRkaXRpb25hbCBPQU0gaW5zZXJ0ZWQgDQogIGluc2lkZSB0aGUgZGF0YTxCUj4mZ3Q7 IHBhdGggYnkgdGhlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgVENNIE1FUF9TbyBmdW5jdGlvbiAN CiAgYW5kIHRoaXMgT0FNIGlzIGV4dHJhY3RlZCBmcm9tIHRoZTxCUj4mZ3Q7ICZndDsgZGF0YSBw YXRoIGJ5PEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAmZ3Q7IHRoZSBUQ00gTUVQX1NrIGZ1bmN0aW9u LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICBSZWdh cmRzLDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IE1hYXJ0ZW48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyA8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICZndDsgRnJvbTog bXBscy10cC1ib3VuY2VzQGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIFttYWls dG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbDxC Uj4mZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyBTZW50OiBkb25kZXJkYWcgMTYgYXByaWwgMjAwOSAx MTo1OTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgDQogIFZhaW5zaHRlaW47 IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2M6 IEJVU0kgDQogIElUQUxPOyBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg U3ViamVjdDogUmU6IFttcGxzLXRwXSANCiAgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICByZXF1aXJlbWVudHM8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBTYXNoYSw8QlI+Jmd0 OyANCiAgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBVbmZvcnR1 bmF0ZWx5IEkgY2Fubm90IGZ1bGx5IGFncmVlIA0KICB3aXRoIHlvdXIgc3RhdGVtZW50OjxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAm bHQ7cXVvdGUmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEZy b20gdGhlIHBvaW50IG9mIHZpZXcgDQogIG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQ8QlI+Jmd0OyAm Z3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBMU1BzPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIA0KICBMU1BzLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O2VuZCBxdW90 ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgVGhpcyBzdGF0ZW1lbnQgd291bGQgYmUgb2J2aW91c2x5IGNvcnJlY3QsIA0KICB3 ZXJlIGl0IG5vdCBmb3I8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBSZXF1aXJlbWVudDxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCByZXF1aXJl bWVudHMgZHJhZnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyANCiAgJmd0OyAmZ3Q7 ICZndDsgT0suIEdvdCBpdC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyBCdXQgDQogIHdoYXQgaXMgdGhpcyBkb2luZyBpbiB0aGUgZGF0YSBwbGFuZSByZXF1 aXJlbWVudHMgc2VjdGlvbj88QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICZndDsgPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgSW4gZmFjdCwgd2hhdCBpcyB0aGlzIHJlcXVpcmVtZW50IGFjdHVhbGx5IA0K ICBzYXlpbmc/PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyANCiAgJmx0O3F1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIA0KICBub2RlcyAoaW5jbHVkaW5nIE1FUHMs IE1JUHMgYW5kPEJSPiZndDsgJmd0OyAmZ3Q7IG90aGVyIGludGVybmFsPEJSPiZndDsgJmd0OyAN CiAgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25zIGFzIGFwcHJv cHJpYXRlKSBvZiBhIA0KICBjby1yb3V0ZWQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHBhdGggYXQgZWFjaCAoc3ViLSlsYXllciBNVVNUIGJlIGF3YXJlIG9mIHRo ZSANCiAgcGFpcmluZzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSANCiAgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgZGlyZWN0aW9ucyBvZiB0aGF0PEJSPiZndDsgDQogICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0IHBhdGguPEJSPiZn dDsgJmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgJmx0O2VuZCBxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgVGhlcmUgaXMgbm8gd2F5IHRo aXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBUaGF0PEJSPiZndDsgJmd0OyBpcywgdGhl cmUgDQogIGlzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9i c2VydmVkIGZyb20gYSBibGFjayBib3ggDQogIHBvaW50IG9mPEJSPiZndDsgJmd0OyB2aWV3IHRo YXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyByZXN1bHRzIGZyb20gYWRoZXJpbmcgDQogIHRvIHRo aXMgcmVxdWlyZW1lbnQuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgVGhlcmVmb3JlIA0KICBpdCBjb3VsZCBiZSBhc3N1bWVkIHRoYXQgdGhpcyByZXF1aXJl bWVudCBpcyBtZXQgYnkgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIGNvbmZpZ3VyaW5nIHNv bWUgZGF0YSBwbGFuZSBkYXRhYmFzZSBjb21wb25lbnQgdGhyb3VnaCB0aGUgPEJSPiZndDsgJmd0 OyAmZ3Q7IA0KICAmZ3Q7IG1hbmFnZW1lbnQgcGxhbmUuIFRoZSBkYXRhYmFzZSBjb21wb25lbnQg aXMgbm90IHVzZWQ8QlI+Jmd0OyBmb3IgDQogIGFueXRoaW5nPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgZXhjZXB0IHRvIHNhdGlzZnkgdGhpcyByZXF1aXJlbWVudCBmb3IgDQogICJhd2FyZW5lc3Mi LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJlbiEgQ2Fu IHdlIHBsZWFzZSANCiAgdHJ5IHRvIHJld3JpdGUgdGhpcyByZXF1aXJlbWVudCBpbiB0ZXJtcyBv ZiA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgYmVoYXZpb3I/PEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IA0KICBS ZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IGxpc3QgdGhhdCANCiAgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNwZWNpZmlj IGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhlIA0KICBwYWlyaW5nPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBhdCBlbmQgDQogIHBvaW50cyBmb3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWw8QlI+Jmd0OyAmZ3Q7ICZndDsgcGF0aHMgDQogIGFyZTxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgZXhhY3RseSB0aGUgc2FtZSBldmVuIGlmIHRoZXkgYXBwZWFyIGluIHR3byANCiAg ZGlmZmVyZW50PEJSPiZndDsgJmd0OyAmZ3Q7IGl0ZW1zIGluIHRoZTxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogIHJlcXVpcmVtZW50cycgbGlzdCkuPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCANCiAgUmVxdWlyZW1lbnQgMzQgdGhlIG5v dGlvbiBvZjxCUj4mZ3Q7IGNvLXJvdXRlZDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQog IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250 ZW50LjxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBUaGUgc29tZXdoYXQgdmFndWUgc2NvcGUgb2YgdGhpcyANCiAgcmVxdWlyZW1lbnQg KCJvdGhlciBpbnRlcm5hbCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9ucyBh cyANCiAgYXBwcm9wcmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFc8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBzdXBwb3J0IG9mIA0KICB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IHBhaXJpbmcgYXdhcmVuZXNzIG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byANCiAgY29t cGx5IHdpdGggaXQuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgVGhlIGVudGlyZXR5IG9mIA0KICB0aGUgYnJhY2tldHRlZCB0ZXh0ICIoaW5jbHVkaW5nIE1F UHMsPEJSPiZndDsgJmd0OyBNSVBzIGFuZCBvdGhlcjxCUj4mZ3Q7ICZndDsgDQogICZndDsgJmd0 OyBpbnRlcm5hbCBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4g SXQ8QlI+Jmd0OyANCiAgJmd0OyBkb2VzIG5vdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFkZCB0 byAiVGhlIGludGVybWVkaWF0ZSBub2Rlcy4iPEJSPiZndDsgDQogICZndDsgJmd0OyAmZ3Q7IDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFm dCANCiAgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyAmbHQ7cXVvdGUmZ3Q7PEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgVGFuZGVtIENvbm5lY3Rpb246IEEgDQogIHRhbmRl bSBjb25uZWN0aW9uIGlzIGFuPEJSPiZndDsgJmd0OyBhcmJpdHJhcnkgcGFydCBvZiBhPEJSPiZn dDsgJmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgJm5ic3A7IHRyYW5zcG9ydCBwYXRoIHRoYXQgY2Fu IGJlIG1vbml0b3JlZCAodmlhIE9BTSk8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgaW5kZXBl bmRlbnRseSBmcm9tIHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IGVuZC10 by1lbmQgDQogIG1vbml0b3JpbmcgKE9BTSkuICZuYnNwO0l0IG1heSBiZSBhIG1vbml0b3JlZDxC Uj4mZ3Q7ICZndDsgc2VnbWVudCBvciANCiAgYTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jm5ic3A7IG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIA0KICB0cmFuc3BvcnQg cGF0aC4gJm5ic3A7PEJSPiZndDsgJmd0OyBUaGUgdGFuZGVtPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyANCiAgJm5ic3A7IGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0aGUgZm9yd2Fy ZGluZyBlbmdpbmUocykgb2Y8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgdGhlIG5vZGUocyk8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBhdCB0aGUgZWRnZShzKSBvZiB0aGUg DQogIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21lbnQuPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmbHQ7ZW5kIA0KICBxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSBhbSBxdWl0ZSANCiAgZmVkIHVwIGFib3V0 IHRoaXMgcGVyc2lzdGVudDxCUj4mZ3Q7ICZndDsgaW5zaXN0ZW5jZSBvbiB0aGU8QlI+Jmd0OyAm Z3Q7ICZndDsgDQogICZndDsgaW5jbHVzaW9uIG9mICJUYW5kZW0gQ29ubmVjdGlvbi4iIFRoZSBk ZWZpbml0aW9uIHdpdGhpbjxCUj4mZ3Q7ICZndDsgdGhlIA0KICBJVFUtVCBvZjxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHRoaXMgdGVybSBpcyBwb29ybHkgc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9t IA0KICB0aGU8QlI+Jmd0OyBtb25pdG9yaW5nIG9mIGE8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBw YXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gDQogIHRhbmRlbSkgdG8gdGhlIGRhdGEgcGF0aCBi ZWluZyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBtb25pdG9yZWQuIFRoaXMgDQogIGRlZmluaXRp b24gb2YgVEMgc2VlbXMgdG8gYmUgYXQgdmFyaWFuY2UsPEJSPiZndDsgJmd0OyBhbmQgd291bGQ8 QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4g YmFuZC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyANCiAgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBEb2Vzbid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgc291bmQgbGlrZSBoYXJkd2FyZSB0byAN CiAgeW91PzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFll cywgYnV0IHNvIHdoYXQ/PEJSPiZndDsgDQogICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCANCiAgbmVpdGhlciB0 aGUgTVBMUy1UUDxCUj4mZ3Q7ICZndDsgJmd0OyBSZXF1aXJlbWVudHMgZHJhZnQ8QlI+Jmd0OyAm Z3Q7ICZndDsgDQogICZndDsgJmd0OyBub3IgdGhlIE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50cyBv bmU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyANCiAgKGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVxdWly ZW1lbjxCUj4mZ3Q7IA0KICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRzLTAxLnR4dCkgY29udGFpbiBh bnkgcmVxdWlyZW1lbnRzIGRlYWxpbmcgd2l0aCANCiAgdGFuZGVtPEJSPiZndDsgJmd0OyAmZ3Q7 IGNvbm5lY3Rpb25zLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IA0K ICAmZ3Q7ICZndDsgJmd0OyBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4g dGhlIE1QTFMtVFAgT0FNPEJSPiZndDsgDQogICZndDsgRnJhbWV3b3JrPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBkcmFmdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAoaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcjxCUj4m Z3Q7ICZndDsgDQogICZndDsgJmd0OyBhbWV3b3JrLTAwLnR4dDxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICkuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFJpZ2h0LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IExldCdzIGp1c3QgZ2V0IHJpZCBvZiBhbiAN CiAgdW5uZWNlc3NhcnkgdGVybSBhbmQgYnJpbmcgYWxsPEJSPiZndDsgdGhlIEktRHM8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyBpbnRvIA0KICBsaW5lLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGJvdHRvbSBsaW5lLCANCiAgSU1ITywgaXMg dGhhdCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nPEJSPiZndDsgJmd0OyAmZ3Q7IGNvLXJvdXRlZCB2 cy48QlI+Jmd0OyANCiAgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhc3NvY2lhdGVkPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIA0KICBpcyBzdGlsbCByZXF1aXJl ZC4gT25lIHdheSB0byBwcm92aWRlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhhdCANCiAgY291 bGQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlIGJ5IGV4cGxpY2l0bHkgbGltaXRpbmcg UmVxdWlyZW1lbnQgMzQgdG8gDQogIHNwZWNpZmljPEJSPiZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9u YWxpdHkuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7 IEFncmVlZC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAN CiAgQWRyaWFuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogQWRyaWFuIA0KICBGYXJyZWwgW2Fk cmlhbkBvbGRkb2cuY28udWtdPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXks IEFwcmlsIDE2LCANCiAgMjAwOSAxMjoxMyBBTTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBB bGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsgDQogIEJVU0kgSVRBTE88QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IA0KICBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCA8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSGkgDQogIFNhc2hhLDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5vdCByZWFsbHkg c3VyZSB3aGV0aGVyIA0KICB5b3UgYXJlIG1pc3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLjxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgDQogICZndDsgJmd0OyAmZ3Q7IDEu IE15IHJlYWRpbmcgb2YgJm5ic3A7b25lIG9mIEJlbidzICZuYnNwO21lc3NhZ2VzIGlzIHRoYXQg DQogIGFzc29jaWF0ZWQgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFs IHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyANCiAgb2YgcGF0aHMgdGhhdCBjYW4gYmU8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyBjcmVhdGVkIGluPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICZn dDsgdGhlIGV4aXN0aW5nIG5ldHdvcmtzOyAidHJ1ZSIgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg cGF0aHM8QlI+Jmd0OyAmZ3Q7IA0KICAmZ3Q7ICZndDsgd2lsbCBoYXZlPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyB0byB3YWl0IHVudGlsIChpZiBldmVyKSBuZXcgDQogIGVxdWlwbWVudCBi ZWNvbWVzIGF2YWlsYWJsZS48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyANCiAgVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlITxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgDQogIGhhcmR3YXJlLCBjby1yb3V0ZWQ8QlI+ Jmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQcyBhcmU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAN CiAgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgDQogIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHlvdSBjYW4g c2V0IHVwIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzIChlLmcuIHVzaW5nIA0KICB0aGU8QlI+Jmd0 OyAmZ3Q7IG1hbmFnZW1lbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwbGFuZSkgeW91IGNhbiBz dXJlbHkgc2V0IA0KICB1cCBhIGNvLXJvdXRlZDxCUj4mZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlv bmFsIExTUC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgDQogIGNvLXJvdXRl ZDxCUj4mZ3Q7IGJpZGlyZWN0aW9uYWw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBMU1BzIHVzaW5n IHRoZSBjb250cm9sIA0KICBwbGFuZS4gVGhlc2UgZWl0aGVyIHVzZSB0aGUgR01QTFM8QlI+Jmd0 OyAmZ3Q7ICh3aGljaCBpczxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyBjbGVhbmVyKSBvciBu b24tc3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpczxCUj4mZ3Q7ICZndDsg DQogIG1lc3N5IGJ1dDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9uYWwpLjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAmZ3Q7ICZndDsgJmd0OyBCdXQgKG9mIGNvdXJz ZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29udHJvbCBwbGFuZTxCUj4mZ3Q7IA0KICAmZ3Q7 IHNvbHV0aW9ucyBoYXZlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbm90aGluZyB0byBkbyB3aXRo IGF2YWlsYWJpbGl0eSBvZiANCiAgZXF1aXBtZW50IGFzIHRoZXk8QlI+Jmd0OyBhcmUgc29mdHdh cmU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgc29sdXRpb25zLjxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDwvVFQ+PC9GT05UPjxCUj48Rk9OVCBzaXplPTI+PFRUPiZndDsgJmd0OyANCiAgJmd0 OyAmZ3Q7ICZndDsgMi4gTXkgcmVhZGluZyBvZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRo YXQgdGhlIA0KICBhY3R1YWw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBkcml2ZXIgZm9yPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjby1yb3V0ZWQgDQogIGJpZGlyZWN0aW9uYWwgcGF0aHMg bWF5IGJlIGV4cGVyaWVuY2Ugd2l0aCBleGlzdGluZyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAN CiAgJmd0OyB0cmFuc3BvcnQgbmV0d29ya3MgcmF0aGVyIHRoYW4gYW55IHNwZWNpZmljIGJlbmVm aXQuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IElz bid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAgDQogIHJlcXVpcmVtZW50 cz88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFk IA0KICB0aGluZy48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyBBIGxhcmdlIGRyaXZlciBmb3IgDQogIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5l dHdvcms8QlI+Jmd0OyAmZ3Q7IHRoZSBsb29rLDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyBm ZWVsLCBhbmQgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSAibGVnYWN5IjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IA0KICB0cmFuc3BvcnQgbmV0d29yay48QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJhc2VkIA0KICBvbiB0aGVzZSBvYnNl cnZhdGlvbnMsIEknZCBndWVzcyAoRldJVykgdGhhdDo8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICogDQogIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0IGZv ciB0aGUgdGltZTxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDti ZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2YgYmlkaXJlY3Rpb25hbCBwYXRocyANCiAg aW48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtNUExTLVRQPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgDQogIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgdGhpbmsgdGhh dCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgDQogIGFuZDxCUj4mZ3Q7 ICZndDsgZ2l2ZW4gdGhhdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG90aGVyIHVwZ3JhZGVzIHRv IGV4aXN0aW5nIA0KICBNUExTIHNvbHV0aW9ucyB3aWxsIGJlPEJSPiZndDsgbmVlZGVkIHRvIHJl YWNoPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIGZ1bGwgDQogIGZ1bmN0aW9uIGxldmVsIG9m IE1QTFMtVFAuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyANCiAgKiB0aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBl IG9mPEJSPiZndDsgJmd0OyANCiAgYmlkaXJlY3Rpb25hbDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7IHBhdGhzIGluICZuYnNwO3JlYWwgDQogIGRlcGxveW1lbnRzLjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgZG9uJ3Qgc2VlIHdoYXQg DQogIHRoYXQgZm9sbG93cyBmcm9tLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IA0KICBDaGVlcnMsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRyaWFuPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgJmd0OyAmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7 IA0KICAmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbXBs cy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgDQogICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbXBscy10cCANCiAgbWFp bGluZyBsaXN0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IA0KICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtdHA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyANCiAgJmd0OyAmZ3Q7ICZn dDsgPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxCUj4mZ3Q7ICZndDsgJmd0OyBtcGxzLXRwIA0KICBtYWlsaW5nIGxp c3Q8QlI+Jmd0OyAmZ3Q7ICZndDsgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyAN CiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPEJSPiZndDsg Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgDQogIDxCUj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgbXBscy10cCANCiAgbWFpbGluZyBs aXN0PEJSPiZndDsgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7IA0KICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8QlI+Jmd0OyANCiAgPEJSPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPm1wbHMtdHAgbWFpbGluZyAN CiAgbGlzdDxCUj5tcGxzLXRwQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscy10cDxCUj48L1RUPjwvRk9OVD48QlI+PEJSPjxQUkU+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNw O0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5m b3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7 aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVy J3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVk Jm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWlu Jm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZu YnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7 dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtl bWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRl bmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9t Jm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJy b3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVz c2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVz ZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJz cDtzeXN0ZW0uDQo8L1BSRT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C9C27C.F2D83D8A-- From IBryskin@advaoptical.com Tue Apr 21 09:11:25 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F4C28C22F for ; Tue, 21 Apr 2009 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qyuyz7UhPTDg for ; Tue, 21 Apr 2009 09:11:21 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 894493A703C for ; Tue, 21 Apr 2009 09:11:01 -0700 (PDT) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n3LGC2kG005126 for ; Tue, 21 Apr 2009 18:12:03 +0200 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 21 Apr 2009 18:12:15 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 21 Apr 2009 18:12:01 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 21 Apr 2009 12:11:57 -0400 From: Igor Bryskin To: "neil.2.harrison@bt.com" , "liu.guoman@zte.com.cn" , "dbrungard@att.com" Date: Tue, 21 Apr 2009 12:11:55 -0400 Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnCJcNHHo+eAHyvRdGt/oqSgC/iuwAUreqgAAhhG7A= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B2BD9EE@atl-srv-exgen.atl.advaoptical.com> References: <2ECAA42C79676B42AEBAC11229CA7D0C04756097@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C04756097@E03MVB2-UKBR.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_052C67B4ED558D41BBDEA7CA9FC6DCDC145B2BD9EEatlsrvexgenat_" MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:11:25 -0000 --_000_052C67B4ED558D41BBDEA7CA9FC6DCDC145B2BD9EEatlsrvexgenat_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TmVpbCwNCg0KUGxlYXNlIHNlZSBteSBxdWVzdGlvbiBpbi1saW5lLg0KDQpUaGFua3MsDQpJZ29y DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBtcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBuZWlsLjIuaGFycmlzb25AYnQuY29tDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyMSwgMjAwOSA4 OjMxIEFNDQpUbzogbGl1Lmd1b21hbkB6dGUuY29tLmNuOyBkYnJ1bmdhcmRAYXR0LmNvbQ0KQ2M6 IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KDQpMaXUsDQoNCklmIE1QTFMt VFAgaXMgZ29pbmcgdG8gYmUgdGFrZW4gc2VyaW91c2x5IGFzIGEgdHJhbnNwb3J0IG5ldHdvcmsg KGxpa2UgU0RIL1NPTkVUKSB0aGVuIHRoZSAyIGtleSBNVVNUIEhBVkUgcmVxdWlyZW1lbnRzIGFy ZSB0aGVzZS4NCg0KMSAgICBQcm92aWRlIGEgdHJhbnNwYXJlbnQgY2xpZW50L3NlcnZlciByZWxh dGlvbnNoaXAuLi53aGljaCBtZWFuczoNCi0gICAgYWxsIGNsaWVudCBiaXRzIHRyZWF0ZWQgZXF1 YWxseQ0KLSAgICBjbGllbnQgYml0IG9yZGVyaW5nIHByZXNlcnZlZA0KLSAgICBubyBhdHRlbXB0 IHRvIGluZmVyIGNsaWVudCBzeW1ib2wgKGllIHNlcXVlbmNlIG9mIGNsaWVudCBiaXRzKSBtZWFu aW5nIGFuZCBubyBhdHRlbXB0IHRvIGNoYW5nZSBjbGllbnQgc3ltYm9scw0KLSAgICB0aGUgdHJh ZmZpYyBiZWhhdmlvdXIgb2YgY2xpZW50IFggbXVzdCBub3QgaW1wYWN0IHRoZSBwZXJmb3JtYW5j ZSBleHBlcmllbmNlZCBieSBjbGllbnQgWQ0KDQpBIGtleSBjb3JvbGxhcnkgb2YgdGhlIGFib3Zl IGlzIHRoYXQgTVBMUy1UUCBtdXN0IG9ubHkgc3VwcG9ydCBwcm9wZXIgY29ubmVjdGlvbnMgKGll IHNpbmdsZSBzb3VyY2UgY29uc3RydWN0cykNCg0KDQoyICAgICAgIFNpbmNlIE1QTFMtVFAgaXMg YSB0cmFuc3BvcnQgbmV0d29yayBpdCBpcyBub3QgYSB0b3Atb2Ytc3RhY2sgbmV0d29yayAoaWUg aXQgZG9lcyBub3Qgc3VwcG9ydCBkaXJlY3RseSBleHRlcm5hbCBtZXNzYWdlL2ZpbGUvc3RyZWFt IGFwcGxpY2F0aW9ucykuICBNUExTLVRQIHRoZXJlZm9yZSBkb2VzIG5vdCByZXF1aXJlIGFuIEUt Tk5JIHNwZWNpZmljYXRpb24uICBBIGtleSBjb3JvbGxhcnkgb2YgdGhpcyBpcyB0aGF0IE1QTFMt VFAgd2lsbCBub3QgaGF2ZSBhbnkgcGVlciBpbnRlcndvcmtpbmcgcmVsYXRpb25zaGlwIHdpdGgg YW55IG90aGVyIG5ldHdvcmsgbW9kZS90ZWNobm9sb2d5Lg0KDQpJQj4+IEZyb20gd2hhdCB5b3Ug d3JvdGUgYWJvdmUgKHdoaWNoIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoKSBvbmUgY2FuIGRyYXcg YSBjb25jbHVzaW9uIHRoYXQgaXQgZG9lcyBub3QgbWFrZSBzZW5zZSAob3Igbm90IHByYWN0aWNh bCB0byBzYXkgdGhlIGxlYXN0KSBmb3IgYSBiaS1kaXJlY3Rpb25hbCBNUExTLVRQIGNvbm5lY3Rp b24gKGNvLXJvdXRlZCBvciBub3QpIHRvIGhhdmUgYXN5bW1ldHJpYyAoZGlmZmVyZW50IGZvciBl YWNoIGRpcmVjdGlvbikgYmFuZHdpZHRoIGFsbG9jYXRpb24uIERvIHlvdSBhZ3JlZSB3aXRoIHRo YXQ/IE1vcmUgZ2VuZXJhbGx5LCBkbyB5b3UgdGhpbmsgb2YgYW55IHJlYXNvbnMgd2h5IGEgbm9u LXRvcC1vZi1zdGFjayBiaS1kaXJlY3Rpb25hbCB0cmFuc3BvcnQgY29ubmVjdGlvbiBhdCBhbnkg bGF5ZXIgbmVlZHMgdG8gYmUgYmFuZHdpZHRoLXdpc2UgYXN5bW1ldHJpY2FsPw0KDQogVGhhbmtz LA0KSWdvcg0KDQpOb3cgd3J0IE9BTSBNUExTLVRQIGlzIGEgY28tcHMgbW9kZSBuZXR3b3JrLiAg WW91IGNvdWxkIGFyZ3VlIHRoaXMgc2hvdWxkIGhhdmUgRkRJL0FJUy4uLi5ob3dldmVyLCB0aGUg bWVyaXQgb2YgdGhpcyBpcyBoaWdobHkgcXVlc3Rpb25hYmxlLiAgV2hlbiBJIGFuZCBjb2xsZWFn dWVzIGRpc2N1c3NlZCB3aGV0aGVyIFBCQi1URSAoYWxzbyBhIGNvLXBzIG1vZGUgbmV0d29yaykg c2hvdWxkIGhhdmUgRkRJL0FJUyB3ZSBjb25jbHVkZWQgdGhhdCBvbiBiYWxhbmNlIGl0IHdhcyBu b3QgYSBnb29kIGlkZWEuLi4uLmFuZCBub3RlIHRoYXQgaW5pdGlhbGx5IEkgd2FzIGluIGZhdm91 ciBvZiBoYXZpbmcgQUlTLCBidXQgbXkgY29sbGVhZ3VlcyBwcm92aWRlZCBzdHJvbmcgdGVjaG5p Y2FsIGFyZ3VtZW50cyB0aGF0IGNvbnZpbmNlZCBtZSBvdGhlcndpc2UuDQoNCkFJUy9GREkgaXMg aGlzdG9yaWNhbGx5IGxpbmtlZCB0byB0aGUgZWFybHkgUERIIGNvLWNzIG1vZGUgbGF5ZXIgbmV0 d29ya3MgdGhhdCB1c2VkIFRUTCBsb2dpYy4gIFdoZW4gdGhpcyBkaWVkIGl0IHB1dCBvdXQgYSAr NVYgKGFsbCAxcykgc2lnbmFsIGJ5IGRlZmF1bHQsIGllIGl0IHJlcXVpcmVkIG5vIGNvbnNjaW91 cyBlZmZvcnQgdG8gZ2VuZXJhdGUgaXQuLi4uLnRoaXMgaXMga2V5IHBvaW50LiAgRnVydGhlciwg aW4gdGhlc2UgbmV0d29ya3MgdGhlcmUgaXMgYSBmYWlybHkgc3RhdGljL2xvbmctaG9sZGluZyBj bGllbnQgc2VydmVyIHJlbGF0aW9uc2hpcC4gIENsZWFybHkgdGhpcyBpcyBub3QgdHJ1ZSBpbiB0 aGUgY2wtcHMgbW9kZSBhbmQgaXQncyB3aHkgSUVURiBoYXZlIG5ldmVyIHNwZWNpZmllZCBBSVMg Zm9yIElQIGFuZCBpdHMgd2h5IElFRUUgaGFkIHRoZSBnb29kIHNlbnNlIHRvIHRocm93LW91dCBB SVMgaW4gODAyLjFhZyBmb3IgRXRoZXJuZXQgKHRob3VnaCBJVFUgaGF2ZSB1bndpc2VseSBJTU8g cmV0YWluZWQgaXQgaW4gWS4xNzMxLi4uLmJ1dCBJIHN1c3BlY3QgYW55IG9wZXJhdG9yIHBsYW5u aW5nIHRvIHVzZSBFdGhlcm5ldCBlcXVpcG1lbnQgd291bGQgYWx3YXlzIGxvb2sgdG8gSUVFRSBz dGRzIGFuZCBub3QgSVRVIG9uZXMpLg0KDQpBSVMvRkRJIGFuZCB0aGUgY28tcHMgbW9kZSBpcyBk ZWJhdGFibGUuICBBcyBJIG5vdGVkIGFib3ZlLCBvbiBiYWxhbmNlIHdlIGNvbnNpZGVyZWQgbm90 IGEgZ29vZCBpZGVhIGZvciBQQkItVEUgT0FNIGJlY2F1c2UgaXQgcmVxdWlyZXMgYSBjb25zY2lv dXMgZWZmb3J0IHRvIGdlbmVyYXRlIGl0ICh1bmxpa2UgdGhlIGNvLWNzIG1vZGUpIHNvIHRoZXJl IGFyZSBsaWtlbHkgdG8gYmUgc2NhbGluZyBwcm9ibGVtcyBhbmQgaXRzIG9uZSBtb3JlIHRoaW5n IHRvIGdvIHdyb25nLg0KDQpZb3Ugc2hvdWxkIGFsc28gaGF2ZSBzZWVuIG1lIG1ha2UgdGhlIHBv aW50IG1hbnkgdGltZXMgaW4gdGhlIHBhc3QgdGhhdCB0aGUgYWx3YXlzLW9uIGRlZmVjdCBkZXRl Y3Rpb24vaGFuZGxpbmcgT0FNIG5lZWRzIHRvIGJlIGFzIHNpbXBsZS9zcGFyc2UgYXMgcG9zc2li bGUgd2l0aCBhcyBsaXR0bGUgY29uZmlnIGFzIHBvc3NpYmxlIGJlY2F1c2Ugd2UgbmVlZCBzdXBl ciByZWxpYWJpbGl0eS4uLi4uLlRDTSBnb2VzIGNvbXBsZXRlbHkgYWdhaW5zdCB0aGUgZ3JhaW4g aGVyZS4gIEFsc28gbm90ZSB0aGF0IHRoZSBPQU0gcmVxdWlyZWQgZm9yIGVhY2ggb2YgdGhlIDMg bmV0d29yayBtb2RlcyBpcyBub3QgdGhlIHNhbWUsIGRlc3BpdGUgd2hhdCBzb21lIGNsYWltLg0K DQpyZWdhcmRzLCBOZWlsDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGxpdS5ndW9tYW5AenRlLmNvbS5jbg0KU2VudDogMjEgQXByaWwg MjAwOSAwMjo1OQ0KVG86IEJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMNCkNjOiBtcGxzLXRw QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0KRGVib3JhaDoNCiBtYXliZSB3aGF0IHlv dSBzYWlkIGlzIHJpZ2h0LiBidXQgSSBjYW4ndCBjb21wbGV0ZWx5IGFncmVlIHlvdXIgb3Bpbmlv bnMuIElNTy4gbXBscy10cCBpcyByZWdhcmQgYXMgdHJhbnNwb3J0IG5ldHdvcmsgbGlrZSBTREgv U09ORVQuIHNvIGl0IHNob3VsZCBoYXZlIEFJUy9GREkgZnVjdGlvbnMgYXMgU0RIL1NPTkVULg0K DQpkbyB5b3UgdGhpbmsgc28uDQoNCmJlc3QgcmVnYXJkcw0KbGl1DQoNCiJCUlVOR0FSRCwgREVC T1JBSCBBLCBBVFRMQUJTIiA8ZGJydW5nYXJkQGF0dC5jb20+DQq3orz+yMs6ICBtcGxzLXRwLWJv dW5jZXNAaWV0Zi5vcmcNCg0KMjAwOS0wNC0yMCAyMzo0Nw0KDQrK1bz+yMsNCg0KIk1hYXJ0ZW4g Vmlzc2VycyIgPG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPiwgPG5laWwuMi5oYXJyaXNvbkBi dC5jb20+DQoNCrOty80NCg0KbXBscy10cEBpZXRmLm9yZw0KDQrW98ziDQoNClJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0K DQoNCg0KDQoNCg0KDQoNCg0KDQpJIGFncmVlIHdpdGggTmVpbCwgaXQgaXMgdmVyeSBxdWVzdGlv bmFibGUgdGhlIHZhbHVlIG9mIEFJUy9GREkgaW4gYQ0KcGFja2V0IG5ldHdvcmstIGFueSBtb2Rl LiBJdCBjYW4gcmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBhbiBvcGVyYXRvcg0Kb24gdGhlbXNl bHZlcyBzbyBldmVuIFkxNzMxIHJlY29tbWVuZHMgbm90IHRvIGJsb2NrIGRhdGEgZnJhbWVzOg0K IkEgTUVQIGNhbiBkZWNpZGUgd2hldGhlciBpdCBibG9ja3MgZGF0YSBmcmFtZXMgd2hlbiBpdCBk ZXRlY3RzIGRBSVMuDQpUaGUgcHJpbmNpcGxlIHJlcXVpcmVtZW50DQp0aGF0IGluZmx1ZW5jZXMg dGhpcyBkZWNpc2lvbiBpcyB0aGF0IGRhdGEgZnJhbWVzIG91Z2h0IHRvIGJlIGZvcndhcmRlZA0K YXMgbXVjaCBhcyBwb3NzaWJsZSwgd2l0aG91dA0KdGhlIHBvc3NpYmlsaXR5IG9mIGZvcndhcmRp bmcgd3JvbmcgZGF0YSBmcmFtZXMgZG93bnN0cmVhbS4iDQpUYWJsZSBJLjctMiBzaG93cyBmb3Ig QUlTLCBub3QgdG8gYmxvY2suDQoNCkFuZCBhcyBZMTczMSBzdGF0ZXMsIEFJUyBjYW4gb25seSBi ZSB1c2VkIHVuZGVyIHZlcnkgY29uc3RyYWluZWQNCmFyY2hpdGVjdHVyZXMgLSBpZiByZXF1aXJl ZCBmb3IgTVBMUy1UUCwgaXQgbmVlZHMgdG8gaGF2ZSB0aGUgc2FtZQ0KZ3VpZGFuY2UgYXMgaW4g WTE3MzEsIGkuZS4gcG9pbnQtdG8tcG9pbnQgYW5kIHNlcnZlci9jbGllbnQgb25lLXRvLW9uZToN CiJmb3IgYSBwb2ludC10by1wb2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSBz aW5nbGUgcGVlciBNRVAuDQpUaGVyZWZvcmUsIHRoZXJlDQppcyBubyBhbWJpZ3VpdHkgcmVnYXJk aW5nIHRoZSBwZWVyIE1FUCBmb3Igd2hpY2ggaXQgc2hvdWxkIHN1cHByZXNzDQphbGFybXMgd2hl biBpdCByZWNlaXZlcyB0aGUNCkVUSC1BSVMgaW5mb3JtYXRpb24uIg0KU28gc2hvdWxkIG9ubHkg YmUgd2l0aGluIG9uZSBkb21haW4gLSB0aGVuIG5vIG5lZWQuDQoNCkRlYm9yYWgNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24NCkJlaGFsZiBPZiBNYWFydGVuIFZpc3Nl cnMNClNlbnQ6IE1vbmRheSwgQXByaWwgMjAsIDIwMDkgMTA6MDUgQU0NClRvOiBuZWlsLjIuaGFy cmlzb25AYnQuY29tDQpDYzogbXBscy10cEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzLXRw XSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCnJlcXVpcmVtZW50cw0K DQpOZWlsLA0KDQo+IGJ1dCBBSVMvRkRJIGluIHRoZSBjbCBtb2RlPy4uLmRvIG1lIGEgZmF2b3Vy IQ0KDQpFdGhlcm5ldCBBSVMgaXMgaW5kZWVkIGEgcmVxdWlyZW1lbnQgYW5kIGEgbmVjZXNzaXR5 LiBBbmQgeW91IHdpbGwgbm90DQpiZQ0KYWJsZSB0byB1bmRlcnN0YW5kIHRoYXQgYXMgbG9uZyBh cyB5b3UgcmVmdXNlIHRvIGFjY2VwdCB0aGF0ICJjbC1tb2RlIg0KaXMgYQ0KZm9yd2FyZGluZyBt b2RlIHdpdGhpbiBhICoqdHJhbnNwb3J0IGVudGl0eSoqLiBHLjgwMCBhbWVuZG1lbnQgMSBoYXMN CmZpbmFsbHkNCnJlaW50cm9kdWNlZCB0aGlzIHRyYW5zcG9ydCBlbnRpdHkgaW50byBHLjgwMC4g QmVzaWRlcyB0aGF0LCBpdCBhbHNvDQppbnRyb2R1Y2VkIHRoZSAqKmRpZmZlcmVudGlhdGVkIGNv bm5lY3Rpb24qKjoNCg0KW0cuODAwIGFtMV0gIkEgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBp cyBhIHRyYW5zcG9ydCBlbnRpdHkgdGhhdA0KdHJhbnNmZXJzIGluZm9ybWF0aW9uIGJlbG9uZ2lu ZyB0byBtdWx0aXBsZSBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHBvcnRzDQphY3Jvc3MgYSBzdWJu ZXR3b3JrLiA8Li4+IEluIGEgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBtZXNzYWdlDQpjb250 ZW50cw0KYXJlIGludGVycHJldGVkIHRvIGlkZW50aWZ5IChzZXRzIG9mKSBjb21tdW5pY2F0aW9u cyB3aGljaCByZWNlaXZlDQpkaWZmZXJlbnQNCnRyZWF0bWVudC4gIFRoZSBzZXRzIG9mIGNvbW11 bmljYXRpb25zIG1heSBiZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZQ0KZm9yd2FyZGluZyBpZGVudGlm aWVyIG9yIG90aGVyIGxheWVyIGluZm9ybWF0aW9uLiAgT3JkZXIgaXMgbm90DQpuZWNlc3Nhcmls eQ0KcHJlc2VydmVkIGJldHdlZW4gbWVzc2FnZXMgYmVsb25naW5nIHRvIHNldHMgb2YgY29tbXVu aWNhdGlvbnMgcmVjZWl2aW5nDQpkaWZmZXJlbnQgdHJlYXRtZW50LiAgU2V0cyBvZiBjb21tdW5p Y2F0aW9ucyBtYXkgYmUgaWRlbnRpZmllZCBmb3INCnB1cnBvc2VzDQpzdWNoIGFzIHRyYWZmaWMg Y29uZGl0aW9uaW5nIG9yIHByZXNlcnZpbmcgY29tbXVuaWNhdGlvbiBtZXNzYWdlIG9yZGVyLiIN Cg0KDQpFdGhlcm5ldCBWTEFOcyBhcmUgaW4gdGVybXMgb2YgRy44MDAgImRpZmZlcmVudGlhdGVk IGNvbm5lY3Rpb25zIi4NCkV0aGVybmV0DQpBSVMgcHJvdmlkZXMgQUlTIHdpdGhpbiB0aGUgc2Nv cGUgb2Ygc3VjaCAiZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiIuDQpJZg0KeW91IGFwcGx5IHRo aXMgdG8gbXkgcHJvcG9zZWQgUFROIGxheWVyIHN0YWNrLCB0aGVuIHRoZSBFVkMgbGF5ZXINCnRv cG9sb2d5DQp3aWxsIGNvbnNpc3RzIG9mIEVWQyBsaW5rcyBzdXBwb3J0ZWQgYnkgTVBMUy1UUCwg RXRoZXJuZXQsIFBCQi1URSBhbmQNClAtT1RODQpWUCB0cmFpbHMgaW5zaWRlIG1ldHJvIGFuZCBj b3JlIGRvbWFpbnMgaW50ZXJjb25uZWN0aW5nIEVWQyBtYXRyaWNlcy4NCldoZW4NCm9uZSBvZiB0 aG9zZSBFVkMgbGlua3MgaXMgaW50ZXJydXB0ZWQsIGUuZy4gaW4gdGhlIGNvcmUgYmV0d2VlbiBt ZXRybyAxDQphbmQNCm1ldHJvIDQgKHNlZSBhdHRhY2hlZCBzbGlkZSksIHRoZW4gdGhlIEVWQyBk aWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uDQp0aGF0IGlzDQpwcmVzZW50IG9uIHRoaXMgbGluayB3 aWxsIGJlIGludGVycnVwdGVkLiBBdCB0aGUgRVZDIHN3aXRjaC9icmlkZ2Ugbm9kZQ0KaW4NCm1l dHJvIDQgdGhpcyBpbnRlcnJ1cHRpb24gaXMgbm90aWNlZCBhbmQgRVZDLUFJUyBpcyBpbnNlcnRl ZCBpbiB0aGUNCmRvd25zdHJlYW0gZGlyZWN0aW9uIHRvIHN1cHByZXNzIHRoZSBFVkMtTE9DIGFs YXJtcyBhdCBFVkMgZW5kcG9pbnRzIEQ0DQphbmQNCkQ1Lg0KDQpUaGUgRVZDLUFJUyAoaS5lLiBF dGhlcm5ldCBBSVMpIGZyYW1lIGhhcyBhIHJlc2VydmVkIG11bHRpY2FzdCBhZGRyZXNzLA0Kd2hp Y2ggZ3VhcmFudGVlcyB0aGF0IHRoZSBBSVMgaXMgYnJvYWRjYXN0IHRvIHRoZSBlbmRwb2ludHMg b2YgdGhlIEVWQy4NCg0KSSBiZWxpZXZlIHRoYXQgaXQgaXMgdGltZSBmb3IgeW91IHRvIGFkYXB0 IHlvdXIgdmlldyBvbiBjbyBhbmQgY2wgbW9kZXMNCmFuZA0KcmVsYXRlIGl0IHRvIHRoZSBmb3J3 YXJkaW5nIG1vZGUgKipJTlNJREUqKiBhIHRyYW5zcG9ydCBlbnRpdHkuDQoNCldoYXQgd2Uga25v dyBhcyB0aGUgaW50ZXJuZXQgaXMgZXNzZW50aWFsbHkgYW4gIklQIGRpZmZlcmVudGlhdGVkDQpj b25uZWN0aW9uIiB3aXRoIGEgYmlsbGlvbiBvciBtb3JlIHBvcnRzLg0KV2hhdCB3ZSBrbm93IGFz IGFuIElQIFZQTiBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQNCmNvbm5lY3Rp b24iDQp3aXRoIGUuZy4gbiBwb3J0cyAobiBpbiB0aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEwMDAp Lg0KV2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMgZXNzZW50aWFsbHkgYW4gIkV0 aGVybmV0DQpkaWZmZXJlbnRpYXRlZA0KY29ubmVjdGlvbiIgd2l0aCBuIHBvcnRzIChuIGluIHRo ZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuDQpXaGF0IHdlIGtub3cgYXMgYSBwMnAgTVBMUyBF LUxTUCBpcyBlc3NlbnRpYWxseSBhbiAiTVBMUyBkaWZmZXJlbnRpYXRlZA0KY29ubmVjdGlvbiIg d2l0aCAyIHBvcnRzLg0KV2hhdCB3ZSBrbm93IGFzIGEgcDJwIFNESCBWQy1uIGlzIGEgIlNESCBW Qy1uIGNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy4NCg0KVHJhbnNwb3J0IG5ldHdvcmsgT0FNIGFw cGxpZXMgdG8gdHJhbnNwb3J0IGVudGl0aWVzLCB3aGljaCBhcmUgKGluIHRlcm1zDQpvZg0KRy44 MDAgYW0xKSBjb25uZWN0aW9ucyBhbmQgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbnMuDQoNClJl Z2FyZHMsDQpNYWFydGVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZWls LjIuaGFycmlzb25AYnQuY29tIFttYWlsdG86bmVpbC4yLmhhcnJpc29uQGJ0LmNvbV0NClNlbnQ6 IHZyaWpkYWcgMTcgYXByaWwgMjAwOSAyMjowMA0KVG86IEpvaG4uRS5EcmFrZTJAYm9laW5nLmNv bTsgSXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdDsNCkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tOyBtYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbQ0KQ2M6IG1wbHMtdHBAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoDQpyZXF1aXJlbWVudHMNCg0KSm9obiwgIFRoYW5rcyB0aGlzIGlzIGEgZ3JlYXQg cGxhdGZvcm0gdG8gZXhwbGFpbiB3aHkgT0FNIGZvciB0aGUgMw0KbmV0d29yaw0KbW9kZXMgbmVl ZHMgdG8gYmUgZGlmZmVyZW50LiAgSSBhbSBnZXR0aW5nIGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xr cw0KdHJ5aW5nDQp0byBtYWtlIGFsbCAzIG5ldHdvcmsgbW9kZXMgbG9vayBhbGlrZSAoYW5kIHRo ZW4sIGV2ZW4gd29yc2UsIGludGVyd29yaw0KdGhlbQ0KYXMgYXMgcGVlcnMuLi5lc3Agd2hlbiBu b3Qgbm90IHRvcC1vZi1zdGFjaw0KbmV0d29ya3MuLi5JIG1lYW4gaG93IHNpbGx5IGNhbiB3ZSBn ZXQ/KS4gICBJIGFtIGV2ZW4gbW9yZSBmcnVzdHJhdGVkIGJ5DQp0aGUgZmFjdCB0aG9zZSBwZWRk bGluZyB0aGlzIEZVRCBvbmx5IGV2ZXIgc2VlbSB0byBjb25zaWRlciBPQU0gYW5kDQpmb3JnZXQN CmFsbCBvdGhlciBEUC9DUC9NUCBjb21wb25lbnRzIChlc3AgdG9wLW9mLXN0YWNrIG1lc3NhZ2Uv ZmlsZS9zdHJlYW0NCmFwcGxpY2F0aW9uIGFkYXB0YXRpb25zKS4gIEhvdyB3cm9uZyBjYW4gdGhp cyBnZXQhDQoNCkluIHRoZSBjbyBtb2RlcyBhICpjb25uZWN0aW9uKiBpcyBhIHZlcnkgc3BlY2lm aWMgYW5kICpjb25zdHJhaW5pbmcqDQpjb25zdHJ1Y3QuLi4uLkkgYW0gYXNzdW1pbmcgaGVyZSB3 ZSByZXNwZWN0IHRoZSBydWxlcyBvZiBhIGNvbm5lY3Rpb24NCihpZQ0Kc2luZ2xlIHNvdXJjZSkg dGhvdWdoIHNvbWUgZm9sa3MgZG9uJ3QgZXZlbiBib3RoZXIgdG8gcmVzcGVjdCB0aGlzLCBhbmQN CnRoaXMNCmlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBhbGwga25vdyB3aGF0IHByb2JsZW1z IG11bHRpcGxlLXNvdXJjZQ0KY29uc3RydWN0cyBjYW4gY2F1c2UgKGZyb20gTERQL1BIUC4uLi5l cmdvIE1QTFMtVFApLg0KDQpXaGVuIHdlIGhhdmUgYSBjb25uZWN0aW9uIHRoaXMgcmVzdHJpY3Rz ICphbGwqIERQIChpZSB0cmFmZmljIGFuZCBPQU0pDQp0bw0Kc3RheSB3aXRoaW4gdGhlIGJvdW5k cyBvZiB0aGUgY29ubmVjdGlvbi4gIFdoaWNoIGlzIGZpbmUgdW5kZXINCmRlZmVjdC1mcmVlDQpj b25kaXRpb25zLCBidXQgaWYgd2UgaGF2ZSBsZWFraW5nIHRyYWZmaWMgdGhlbiB0aGUgY29uc3Ry YWluaW5nIG5hdHVyZQ0Kb2YNCnRoZSBjb25uZWN0aW9uIGNvbnN0cnVjdCBpcyBicm9rZW4uICBJ biBhIG51dHNoZWxsIHdoYXQgdGhpcyBtZWFucyBpcw0KdGhhdA0KT0FNIHRoYXQgaXMgb2YgYSBy ZXF1ZXN0L3Jlc3BvbnNlIG5hdHVyZSBjYW5ub3QgYmUgdHJ1c3RlZCBpbiBjbyBtb2RlDQpuZXR3 b3JrcyB1bmRlciBtaXNjb25uZWN0aXZpdHkgZGVmZWN0cy4uLi4uaW5kZWVkLCB3aHkgc2hvdWxk IGEgbGVha2luZw0KRFANCmhhdmUgYSBzeW1tZXRyaWMgZ28vcmV0dXJuIGRlZmVjdCBiZWhhdmlv dXI/Li4uLnZlcnkgbGlrZWx5IGl0IHdvbid0Lg0KU28NCndoaWxzdCByZXF1ZXN0L3Jlc3BvbnNl IE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1vZGUgaXQgaXMgbm90IHJpZ2h0IGZvcg0KdGhlDQpj byBtb2RlIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3QgY29uZGl0aW9ucy4NCg0KTW9yZSBn ZW5lcmFsbHkgdGhlIDMgbW9kZXMgYXJlIGRpZmZlcmVudCBhbmQgbm90IGp1c3QgaW4gT0FNDQpy ZXF1aXJlbWVudHMuLi4uYnV0IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZv dXIhLi4uYXQgbGVhc3QNCklFRUUgaGFkIHRoZSBnb29kIHNlbnNlIHRvIGJpbiB0aGlzIGZvciBF dGhlcm5ldCBldmVuIHRob3VnaCBpdCByZW1haW5zDQppbg0KWS4xNzMxLiAgQW5kIHdoaWNoIGlz IHdoeSBJIG9mdGVuIHRyb3Qtb3V0IHRoZSByYXRoZXIgc2lsbHkgKHRvIGhhdmUgdG8NCnNheQ0K dGhpcykgb2JzZXJ2YXRpb24gdGhhdCBpZiBJUCAoY2wgbW9kZSkgY291bGQgZG8gaXQgYWxsIHRo ZW4gd2h5IGhhdmUNCklFVEYNCmZvdW5kIGl0IG5lY2Vzc2FyeSB0byBjcmVhdGUgTVBMUyAoY28t cHMpIGFuZCBHTVBMUyAoQ1AgZm9yIGNvLWNzKS4gIFRoZQ0KYW5zd2VyIGxpZXMgaW4gdGhlIHBo eXNpY3MuLi5hbmQgRy44MDAgYXR0ZW1wdHMgdG8gZXhwbGFpbiB0aGF0DQpwaHlzaWNzLi4uLkcu ODA1IGRvZXMgbm90Lg0KDQpTbywgdGhlIDMgbW9kZXMgYXJlIGRpZmZlcmVudC4uLnBsZWFzZSBh Y2NlcHQvcmVqb2ljZSBpbiB0aGlzIGZhY3QgYXMNCnRoZXkNCmFsbCBvZmZlciBzb21ldGhpbmcg ZGlmZmVyZW50L2ltcG9ydGFudC4gIEJ1dCBkbyBub3QgYmUgaG9vZHdpbmtlZCBieQ0KdGhvc2UN CndobyBwZWRkbGUgYSBzdG9yeSB0aGF0IHRoYXQgdHJpZXMgdG8gbWFrZSB0aGUgT0FNIG9mIHRo ZSAzIG1vZGVzIHRoZQ0Kc2FtZS4NCg0KcmVnYXJkcywgTmVpbA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KPiBbbWFpbHRv Om1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERyYWtlLCBKb2huIEUNCj4g U2VudDogMTcgQXByaWwgMjAwOSAyMDowMg0KPiBUbzogQlVTSSBJVEFMTzsgQWxleGFuZGVyIFZh aW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0 aA0KPiByZXF1aXJlbWVudHMNCj4NCj4gSXRhbG8sDQo+DQo+IEFzIGRlc2NyaWJlZCBpbiB0aGUg TVBMUyBUUCBPQU0gUmVxdWlyZW1lbnRzIEktRCwgdmlydHVhbGx5IGFsbCBvZiB0aGUNCg0KPiBP QU0gZnVuY3Rpb25zIHJlcXVpcmUgYSByZXR1cm4gcGF0aCwgYW5kIGluIHRoZSBhYnNlbmNlIG9m IGEgcmV0dXJuDQo+IHBhdGggdGhleSBhcmUgZGlzYWJsZWQuDQo+DQo+IEFzIGRlc2NyaWJlZCBp biBEYXZpZCBTaW5pY3JvcGUncyBtZWV0aW5nIG1pbnV0ZXMNCj4gKGh0dHA6Ly93aWtpLnRvb2xz LmlldGYub3JnL21pc2MvbXBscy1pbnRlcm9wL2F0dGFjaG1lbnQvd2lraS8NCj4gbWVldGluZy1u bw0KPiB0ZXMvMjAwODEwMTUubXBscy1pbnRlcm9wLWR0LW5vdGVzLnppcCksIGlmIElQIGFkZHJl c3NpbmcgaXMgdXNlZCwgYW4NCj4gTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGJlIGNhcGFibGUg b2YgZ2V0dGluZyBJUCBwYWNrZXRzIGZyb20NCj4gZGVzdGluYXRpb24gdG8gc291cmNlOyBuZWl0 aGVyIHRoZSBtaW51dGVzIG5vciBJIHN0aXB1bGF0ZSB0aGF0IGENCj4gY29udHJvbCBwbGFuZSBu ZWVkcyB0byBiZSB1c2VkIHRvIGluc3RhbnRpYXRlIHRoaXMgZm9yd2FyZGluZy4NCj4NCj4gQXMg YW4gYXNpZGUsIHRoZSBpc3N1ZSBvZiByZXR1cm4gcGF0aCBmb3IgdW5pZGlyZWN0aW9uYWwgTFNQ cyBjb3VsZCBiZQ0KDQo+IGNoYXJhdGVyaXplZCBhcyB0aGUgZWxlcGhhbnQgaW4gdGhlIHJvb20u ICBJbiB0aGUgTVBMUyBUUCBPQU0NCj4gRnJhbWV3b3JrIEktRCwgdW5pY2FzdCBMU1BzIGFyZSBv bmx5IG1lbnRpb25lZCB0aHJlZSB0aW1lcyBhbmQgcmV0dXJuDQo+IHBhdGhzIG5vdCBhdCBhbGwu DQo+DQo+IFRoYW5rcywNCj4NCj4gSm9obg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gRnJvbTogQlVTSSBJVEFMTyBbbWFpbHRvOkl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQu aXRdDQo+ID4gU2VudDogRnJpZGF5LCBBcHJpbCAxNywgMjAwOSAxOjU5IEFNDQo+ID4gVG86IERy YWtlLCBKb2huIEU7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gPiBD YzogbXBscy10cEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQo+ID4gcmVxdWlyZW1lbnRzDQo+ID4NCj4g PiBKb2huLA0KPiA+DQo+ID4gSSBtaWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVtZW50IG9mIE1Q TFMtVFAgYmVpbmcgY2FwYWJsZSBvZg0KPiA+IHNlbmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVz dHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQcy4NCj4gPg0KPiA+IFRoaXMgcmVxdWlyZW1l bnQgZG9lcyBub3QgYmVsb25nIHRvIHRoZSBmaXJzdCBzZXQgb2YgcmVxdWlyZW1lbnRzDQo+ID4g SVRVLVQgaXMgZXhwZWN0aW5nIHRvIGJlIG1ldCBieSBPY3RvYmVyLg0KPiA+DQo+ID4gSG93ZXZl ciwgSSB0aGluayB0aGlzIGluIGEgcG90ZW50aWFsIGludGVyZXN0aW5nIGFkZGl0aW9uYWwNCj4g PiByZXF1aXJlbWVudCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgKGF0IHdvcnN0IGluIGENCj4g c3Vic2VxdWVudCBwaGFzZSkuDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVu dCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVyc3VzIG90aGVyDQo+ID4gbW9yZSBpbXBvcnRhbnQg cmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJpbGl0eSB0byB3b3JrIHcvbyBJUA0KPiA+IGZv cndhcmRpbmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8gY29udGludWUgdG8gbW9uaXRvciB0aGUg ZGF0YQ0KPiA+IHBsYW5lIGFsc28gaW4gY2FzZSBvZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNv bnRyb2wgb3IgbWFuYWdlbWVudA0KPiA+IHBsYW5lKS4NCj4gPg0KPiA+IEkgYW0gb3BlbiB0byBk aXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdodCB0aW1lIGJlY2F1c2UNCj4g PiBJIHdpc2ggdG8gYXZvaWQgZGVsYXlpbmcgdGhlIGZpcnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24g c29sdXRpb24uDQo+ID4NCj4gPiBUaGFua3MsIEl0YWxvDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCj4g PiA+IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2Us IEpvaG4gRQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDg6MDAgUE0NCj4g PiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzDQo+ID4gPiBDYzog bXBscy10cEBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCj4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4N Cj4gPiA+IEF0IHRoZSBtZWV0aW5nIGxhc3QgZmFsbCBhdCBKdW5pcGVyIGluIE1hc3NhY2h1c2V0 dHMsIEkNCj4gPiB0aGluayBpdCB3YXMNCj4gPiA+IGFncmVlZCB0aGF0IGFuIE1QTFMgVFAgbmV0 d29yayBuZWVkcyB0byBoYXZlIGEgZm9yd2FyZGluZw0KPiA+IGNhcGFiaWxpdHkNCj4gPiA+IGZv ciBtYW5hZ2VtZW50LCBjb250cm9sLCBhbmQgT0FNIHBhY2tldHMgKGUuZy4sIHNlbmRpbmcNCj4g PiByZXBsaWVzIHRvIE9BTQ0KPiA+ID4gcmVxdWVzdHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwg TFNQcykgZXZlbiBpZiBpdCBkb2VzIG5vdA0KPiA+IGhhdmUgYW4gSVANCj4gPiA+IGZvcndhcmRp bmcgZGF0YSBwbGFuZS4NCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiA+IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+ID4gPiBbbWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXBy aWwgMTYsIDIwMDkgOTo1NyBBTQ0KPiA+ID4gPiBUbzogTWFhcnRlbiBWaXNzZXJzDQo+ID4gPiA+ IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQo+ID4gPiA+IHJlcXVpcmVtZW50 cw0KPiA+ID4gPg0KPiA+ID4gPiBNYWFydGVuLA0KPiA+ID4gPiBJdCBzZWVtcyB0aGF0IHlvdSd2 ZSBqdXN0IChpbXBsaWNpdGx5IGFuZCwgcHJvYmFibHksDQo+ID4gPiA+IGluYWR2ZXJ0ZW50bHkp IHN0YXRlZCB0aGUgZm9sbG93aW5nOg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICAgICAg IE1QTFMtVFAgT0FNIHdpbGwgbm90IGV2ZXIgc3VwcG9ydCBNSVAgbG9vcGJhY2sgZnVuY3Rpb24N Cj4gPiAoYW5kIGZhdWx0DQo+ID4gPiA+IGxvY2FsaXphdGlvbiB3aGljaCByZXF1aXJlcyB0aGlz IGZ1bmN0aW9uICkgZm9yDQo+ID4gdW5pZGlyZWN0aW9uYWwgUDJNUA0KPiA+ID4gPiBhbmQgUDJQ IHBhdGhzLg0KPiA+ID4gPg0KPiA+ID4gPiBJZiB0aGlzIHN0YXRlbWVudCBpcyBjb3JyZWN0LCB0 aGlzIChJTUhPIGFuZCBGV0lXKQ0KPiByYWlzZXMgYSB2YWxpZA0KPiA+ID4gPiBxdWVzdGlvbjoN Cj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgICAgICBJcyBNUExTLVRQIGFuIGFwcHJvcHJp YXRlIHNvbHV0aW9uIGZvciB0aGVzZQ0KPiB0eXBlcyBvZiB0cmFuc3BvcnQNCj4gPiA+ID4gcGF0 aHM/DQo+ID4gPiA+DQo+ID4gPiA+IEZvciB0aGUgcmVmZXJlbmNlLCBJUC9NUExTIHByb3ZpZGVz IHRoaXMga2luZCBvZg0KPiA+IGZ1bmN0aW9uYWxpdHkgdG9kYXkNCj4gPiA+ID4gZm9yICh1bmlk aXJlY3Rpb25hbCAtIGJ1dCBpdCBkb2VzIG5vdCBrbm93IGFueSBvdGhlcg0KPiA+IHR5cGUpIFAy UCBMU1BzDQo+ID4gPiA+IGFzIGRlc2NyaWJlZCBpbiBSRkMgNDM3OS4gQW5kIGl0cyBleHRlbnNp b24gdG8gUDJNUCBMU1BzIHNlZW1zDQo+ID4gPiA+IGVhc3kuLi4NCj4gPiA+ID4NCj4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4NCj4gPiA+ID4gICAgICBTYXNoYQ0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9y ZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0KPiA+IE9uIEJlaGFsZg0KPiA+ID4gPiBPZiBN YWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXQ0KPiA+ID4gPiBTZW50 OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzoyNCBQTQ0KPiA+ID4gPiBUbzogJ0FkcmlhbiBG YXJyZWwnDQo+ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJl OiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQo+ID4g PiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPg0KPiA+ID4gPiBBZHJpYW4sDQo+ID4gPiA+DQo+ID4g PiA+ID4+IDxxdW90ZT4NCj4gPiA+ID4gPj4gICAgICBUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChp bmNsdWRpbmcgTUVQcywgTUlQcyBhbmQNCj4gPiA+ID4gb3RoZXIgaW50ZXJuYWwNCj4gPiA+ID4g Pj4gICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZA0KPiA+ID4g PiBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPiA+ID4gPiA+PiAgICAgICBwYXRoIGF0IGVhY2gg KHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KPiA+ID4gPiA+PiAgICAg ICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KPiA+ID4gPiBk aXJlY3Rpb25zIG9mIHRoYXQNCj4gPiA+ID4gPj4gICAgICAgdHJhbnNwb3J0IHBhdGguDQo+ID4g PiA+ID4+IDxlbmQgcXVvdGU+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGVyZSBpcyBubyB3YXkg dGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCj4gPiA+IGlzLCB0aGVyZSBp cw0KPiA+ID4gPiA+ICpub3RoaW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sg Ym94IHBvaW50IG9mDQo+ID4gPiB2aWV3IHRoYXQNCj4gPiA+ID4gPiByZXN1bHRzIGZyb20gYWRo ZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC4NCj4gPiA+ID4NCj4gPiA+ID4gWW91ciB1bmRlcnN0 YW5kaW5nIGlzIG5vdCBjb3JyZWN0LiBJdCBpcyB2ZXJ5IG11Y2gNCj4gb2JzZXJ2YWJsZSBpZg0K PiA+ID4gPiB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9m IHZpZXcuDQo+ID4gPiA+IFRoZSBNSVAgZnVuY3Rpb25zIGNhbiBvbmx5IHBlcmZvcm0gdGhlIExv b3BiYWNrIHdoZW4gdGhlcmUgaXMgYQ0KPiA+ID4gPiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0 cmFuc3BvcnQgcGF0aC4gVGhlIE1QTFMtVFAgTEJNIHBhY2tldA0KPiA+ID4gPiByZWNlaXZlZCBh dCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5lZCAoYXMgTEJSDQo+ID4gPiA+IHBhY2tldCkgdG8g dGhlIG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhlIG90aGVyDQo+ID4gZGlyZWN0aW9u IG9mDQo+ID4gPiA+IHRoZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4g VGhpcyBvdGhlcg0KPiBkaXJlY3Rpb24NCj4gPiA+ID4gd291bGQgbm90IGJlIGF2YWlsYWJsZSBp biBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ID4gPiA+IHBhdGguLi4g YW5kIHRodXMgdGhlIGxvb3BiYWNrIHRlc3QNCj4gPiA+IHdvdWxkIGZhaWwuDQo+ID4gPiA+DQo+ ID4gPiA+IFNpbWlsYXJseSwgd2hlbiB3ZSBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1vbml0 b3IgYQ0KPiA+IHNlZ21lbnQsIHRoZW4NCj4gPiA+ID4gdGhpcyBpcyBwb3NzaWJsZSBpbiBhIGNv LXJvdXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aA0KPiBidXQgbm90IGluIGENCj4gPiA+ID4gYXNz b2NpYXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aC4gSW4gdGhlIGZpcnN0IGNhc2UgdGhlIFRDTSBN RVANCj4gPiA+ID4gU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucyBhcmUgY28tbG9jYXRlZCBhbmQg Y2FuDQo+IGV4Y2hhbmdlIHdoYXQgaXMNCj4gPiA+ID4gY2FsbGVkICJyZW1vdGUgaW5mb3JtYXRp b24iIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgcGVyZm9ybWFuY2UNCj4gPiA+ID4gbW9uaXRvcmlu Zy4NCj4gPiA+ID4gSW4gdGhlIGxhdHRlciBjYXNlIHRoZSBUQ00gTUVQIFNvdXJjZSBhbmQgU2lu ayBmdW5jdGlvbnMNCj4gPiBhcmUgaW4gZS5nLg0KPiA+ID4gPiBkaWZmZXJlbnQgbm9kZXMgaW4g dGhlIG5ldHdvcmsgYW5kIFRDTSB3b3VsZCBub3QgYmUgYWJsZQ0KPiA+IHRvIHByb3ZpZGUNCj4g PiA+ID4gcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4NCj4gPiA+ID4NCj4gPiA+ID4gPiBUaGUgZW50 aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBzLA0KPiA+ID4gTUlQ cyBhbmQgb3RoZXINCj4gPiA+ID4gaW50ZXJuYWwNCj4gPiA+ID4gPiBmdW5jdGlvbnMgYXMgYXBw cm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4gSXQgZG9lcyBub3QNCj4gPiA+ID4gYWRkIHRv ICJUaGUNCj4gPiA+ID4gPiBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KPiA+ID4gPg0KPiA+ID4gPiBZ b3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIFRoaXMgdGV4dCBtdXN0IG5vdCBiZQ0K PiA+IGRlbGV0ZWQgYXQNCj4gPiA+ID4gYWxsLg0KPiA+ID4gPg0KPiA+ID4gPiA+IEFjdHVhbGx5 LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQNCj4gPiA+IGluc2lzdGVu Y2Ugb24gdGhlDQo+ID4gPiA+IGluY2x1c2lvbg0KPiA+ID4gPiA+IG9mICJUYW5kZW0gQ29ubmVj dGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbiB0aGUgSVRVLVQgb2YNCj4gPiA+ID4gdGhpcyB0 ZXJtDQo+ID4gPiA+ID4gaXMNCj4gPiA+ID4gcG9vcmx5DQo+ID4gPiA+ID4gc3BlY2lmaWVkIGFu ZCBjb21lcyBmcm9tIHRoZSBtb25pdG9yaW5nIG9mIGEgcGF0aCB0aGF0IGlzDQo+ID4gPiA+IHBh cmFsbGVsIChpLmUuDQo+ID4gPiA+IHRhbmRlbSkNCj4gPiA+ID4gPiB0byB0aGUgZGF0YSBwYXRo IGJlaW5nIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRDDQo+ID4gPiA+IHNlZW1zIHRv IGJlIGF0DQo+ID4gPiA+IHZhcmlhbmNlLA0KPiA+ID4gPiA+IGFuZCB3b3VsZCBiZSBpZiB0aGUg QUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KPiA+ID4gPg0KPiA+ID4gPiBJIGRvbid0IHVuZGVy c3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRhdGlvbiBvZiB0YW5kZW0NCj4gPiBjb25uZWN0aW9u IGlzDQo+ID4gPiA+IGRlc2NyaWJlZCBpbiBJVFUtVCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gImZy b20gdGhlDQo+ID4gbW9uaXRvcmluZyBvZiBhDQo+ID4gPiA+IHBhdGggdGhhdCBpcyBwYXJhbGxl bCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBhdGggYmVpbmcNCj4gPiA+ID4gbW9uaXRvcmVk LiI/DQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlIGlzIGEgIm5ldHdvcmsgY29ubmVjdGlvbiIgYW5k IHRoaXMgbmV0d29yaw0KPiA+IGNvbm5lY3Rpb24gaXMgYSBzZXQNCj4gPiA+ID4gb2YgaW50ZXJj b25uZWN0ZWQgImxpbmsgY29ubmVjdGlvbnMiIGFuZCAibWF0cml4DQo+IGNvbm5lY3Rpb25zIi4g QQ0KPiA+ID4gPiBzdWJzZXQgb2YgdGhvc2UgaW50ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9u cyBhbmQgbWF0cml4DQo+ID4gPiA+IGNvbm5lY3Rpb25zIGNhbiBiZSBtb25pdG9yZWQgYW5kIGlz IHRoZW4gcmVmZXJyZWQgdG8gYXMNCj4gYSAidGFuZGVtDQo+ID4gPiA+IGNvbm5lY3Rpb24iLiBU aGVyZSBpcyBubyAicGF0aCB0aGF0IGlzIHBhcmFsbGVsIHRvIHRoZQ0KPiA+IGRhdGEgcGF0aCIu DQo+ID4gPiA+IFRoZXJlIGlzIG9ubHkgYWRkaXRpb25hbCBPQU0gaW5zZXJ0ZWQgaW5zaWRlIHRo ZSBkYXRhDQo+IHBhdGggYnkgdGhlDQo+ID4gPiA+IFRDTSBNRVBfU28gZnVuY3Rpb24gYW5kIHRo aXMgT0FNIGlzIGV4dHJhY3RlZCBmcm9tIHRoZQ0KPiA+IGRhdGEgcGF0aCBieQ0KPiA+ID4gPiB0 aGUgVENNIE1FUF9TayBmdW5jdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ ID4gTWFhcnRlbg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+ID4g W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFy cmVsDQo+ID4gPiA+IFNlbnQ6IGRvbmRlcmRhZyAxNiBhcHJpbCAyMDA5IDExOjU5DQo+ID4gPiA+ IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgYmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20N Cj4gPiA+ID4gQ2M6IEJVU0kgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVj dDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgN Cj4gPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+DQo+ID4gPiA+IEhpIFNhc2hhLA0KPiA+ID4g Pg0KPiA+ID4gPiA+IFVuZm9ydHVuYXRlbHkgSSBjYW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3Vy IHN0YXRlbWVudDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDxxdW90ZT4NCj4gPiA+ID4gPiAgICAg RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkDQo+ID4gPiBiaWRp cmVjdGlvbmFsIExTUHMNCj4gPiA+ID4gPiAgICAgYXJlIGEgc3BlY2lhbCBjYXNlIG9mIGFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KPiA+ID4gPiA+IDxlbmQgcXVvdGU+DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBUaGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwg d2VyZSBpdCBub3QgZm9yDQo+ID4gPiA+IFJlcXVpcmVtZW50DQo+ID4gPiA+ID4gMzQgaW4gdGhl IGxhdGVzdCBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ID4gPg0KPiA+ID4gPiBPSy4g R290IGl0Lg0KPiA+ID4gPg0KPiA+ID4gPiBCdXQgd2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBk YXRhIHBsYW5lIHJlcXVpcmVtZW50cyBzZWN0aW9uPw0KPiA+ID4gPg0KPiA+ID4gPiBJbiBmYWN0 LCB3aGF0IGlzIHRoaXMgcmVxdWlyZW1lbnQgYWN0dWFsbHkgc2F5aW5nPw0KPiA+ID4gPg0KPiA+ ID4gPiA+IDxxdW90ZT4NCj4gPiA+ID4gPiAgICAgIFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGlu Y2x1ZGluZyBNRVBzLCBNSVBzIGFuZA0KPiA+ID4gb3RoZXIgaW50ZXJuYWwNCj4gPiA+ID4gPiAg ICAgICBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkDQo+ID4gPiA+IGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ID4gPiA+ID4gICAgICAgcGF0aCBhdCBlYWNoIChzdWIt KWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmcNCj4gPiA+ID4gPiAgICAgICByZWxh dGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KPiA+ID4gPiBkaXJlY3Rp b25zIG9mIHRoYXQNCj4gPiA+ID4gPiAgICAgICB0cmFuc3BvcnQgcGF0aC4NCj4gPiA+ID4gPiA8 ZW5kIHF1b3RlPg0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1 bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCj4gPiBpcywgdGhlcmUgaXMNCj4gPiA+ID4gKm5v dGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCj4g PiB2aWV3IHRoYXQNCj4gPiA+ID4gcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWly ZW1lbnQuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlZm9yZSBpdCBjb3VsZCBiZSBhc3N1bWVkIHRo YXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgYnkNCj4gPiA+ID4gY29uZmlndXJpbmcgc29tZSBk YXRhIHBsYW5lIGRhdGFiYXNlIGNvbXBvbmVudCB0aHJvdWdoIHRoZQ0KPiA+ID4gPiBtYW5hZ2Vt ZW50IHBsYW5lLiBUaGUgZGF0YWJhc2UgY29tcG9uZW50IGlzIG5vdCB1c2VkDQo+IGZvciBhbnl0 aGluZw0KPiA+ID4gPiBleGNlcHQgdG8gc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAiYXdh cmVuZXNzIi4NCj4gPiA+ID4NCj4gPiA+ID4gQmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdy aXRlIHRoaXMgcmVxdWlyZW1lbnQgaW4gdGVybXMgb2YNCj4gPiA+ID4gYmVoYXZpb3I/DQo+ID4g PiA+DQo+ID4gPiA+ID4gUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05M WSBpdGVtIGluIHRoZQ0KPiA+ID4gPiBsaXN0IHRoYXQgaXMNCj4gPiA+ID4gPiBzcGVjaWZpYyBm b3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBwYWlyaW5nDQo+ID4gPiA+IHJl cXVpcmVtZW50cw0KPiA+ID4gPiA+IGF0IGVuZCBwb2ludHMgZm9yIGNvLXJvdXRlZCBhbmQgYXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsDQo+ID4gPiBwYXRocyBhcmUNCj4gPiA+ID4gPiBleGFjdGx5 IHRoZSBzYW1lIGV2ZW4gaWYgdGhleSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudA0KPiA+ID4gaXRl bXMgaW4gdGhlDQo+ID4gPiA+ID4gcmVxdWlyZW1lbnRzJyBsaXN0KS4NCj4gPiA+ID4gPiBJbiBv dGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mDQo+IGNvLXJv dXRlZA0KPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkg ZGF0YSBwbGFuZSBjb250ZW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIHNvbWV3aGF0IHZh Z3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbA0KPiA+ID4gPiA+ IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSIpIGNyZWF0ZXMgYSBzdXNwaWNpb24gdGhhdCBIVw0K PiA+ID4gPiBzdXBwb3J0IG9mIHRoZQ0KPiA+ID4gPiA+IHBhaXJpbmcgYXdhcmVuZXNzIG1heSBi ZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC4NCj4gPiA+ID4NCj4gPiA+ID4g VGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRpbmcgTUVQcywNCj4g PiBNSVBzIGFuZCBvdGhlcg0KPiA+ID4gPiBpbnRlcm5hbCBmdW5jdGlvbnMgYXMgYXBwcm9wcmlh dGUpIiBzaG91bGQgYmUgZGVsZXRlZC4gSXQNCj4gPiBkb2VzIG5vdA0KPiA+ID4gPiBhZGQgdG8g IlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBmb2xsb3dp bmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPHF1b3RlPg0KPiA+ID4gPiA+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFu ZGVtIGNvbm5lY3Rpb24gaXMgYW4NCj4gPiBhcmJpdHJhcnkgcGFydCBvZiBhDQo+ID4gPiA+ID4g ICB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pDQo+ID4gPiA+ IGluZGVwZW5kZW50bHkgZnJvbSB0aGUNCj4gPiA+ID4gPiAgIGVuZC10by1lbmQgbW9uaXRvcmlu ZyAoT0FNKS4gIEl0IG1heSBiZSBhIG1vbml0b3JlZA0KPiA+IHNlZ21lbnQgb3IgYQ0KPiA+ID4g PiA+ICAgbW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGgu DQo+ID4gVGhlIHRhbmRlbQ0KPiA+ID4gPiA+ICAgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRl IHRoZSBmb3J3YXJkaW5nIGVuZ2luZShzKSBvZg0KPiA+ID4gPiB0aGUgbm9kZShzKQ0KPiA+ID4g PiA+ICAgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21l bnQuDQo+ID4gPiA+ID4gPGVuZCBxdW90ZT4NCj4gPiA+ID4NCj4gPiA+ID4gQWN0dWFsbHksIEkg YW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudA0KPiA+IGluc2lzdGVuY2Ugb24g dGhlDQo+ID4gPiA+IGluY2x1c2lvbiBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5p dGlvbiB3aXRoaW4NCj4gPiB0aGUgSVRVLVQgb2YNCj4gPiA+ID4gdGhpcyB0ZXJtIGlzIHBvb3Js eSBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlDQo+IG1vbml0b3Jpbmcgb2YgYQ0KPiA+ID4g PiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJl aW5nDQo+ID4gPiA+IG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRDIHNlZW1zIHRvIGJl IGF0IHZhcmlhbmNlLA0KPiA+IGFuZCB3b3VsZA0KPiA+ID4gPiBiZSBpZiB0aGUgQUNIIHdhcyBh Y3R1YWxseSBpbiBiYW5kLg0KPiA+ID4gPg0KPiA+ID4gPiA+IERvZXNuJ3QgImZvcndhcmRpbmcg ZW5naW5lIiBzb3VuZCBsaWtlIGhhcmR3YXJlIHRvIHlvdT8NCj4gPiA+ID4NCj4gPiA+ID4gWWVz LCBidXQgc28gd2hhdD8NCj4gPiA+ID4NCj4gPiA+ID4gPiBJTUhPIGl0IGlzIHdvcnRoIG5vdGlu ZyB0aGF0IG5laXRoZXIgdGhlIE1QTFMtVFANCj4gPiA+IFJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ ID4gPiA+IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZQ0KPiA+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPg0KPiA+DQo+IChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVtZW4NCj4gPiA+ID4gPiB0cy0wMS50eHQp IGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGggdGFuZGVtDQo+ID4gPiBjb25u ZWN0aW9ucy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJ1dCB0YW5kZW0gY29ubmVjdGlvbnMgYXJl IGRpc2N1c3NlZCBpbiB0aGUgTVBMUy1UUCBPQU0NCj4gPiBGcmFtZXdvcmsNCj4gPiA+ID4gPiBk cmFmdA0KPiA+ID4gPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1tcGxzLXRwLW9hbS1mcg0KPiA+ID4gPiBhbWV3b3JrLTAwLnR4dA0KPiA+ID4gPiApLg0K PiA+ID4gPg0KPiA+ID4gPiBSaWdodC4NCj4gPiA+ID4gTGV0J3MganVzdCBnZXQgcmlkIG9mIGFu IHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nIGFsbA0KPiB0aGUgSS1Ecw0KPiA+ID4gPiBpbnRv IGxpbmUuDQo+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIGJvdHRvbSBsaW5lLCBJTUhPLCBpcyB0aGF0 IHNvbWUgY2xhcml0eSByZWdhcmRpbmcNCj4gPiA+IGNvLXJvdXRlZCB2cy4NCj4gPiA+ID4gPiBh c3NvY2lhdGVkDQo+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCByZXF1aXJl ZC4gT25lIHdheSB0byBwcm92aWRlDQo+ID4gPiA+IHRoYXQgY291bGQNCj4gPiA+ID4gPiBiZSBi eSBleHBsaWNpdGx5IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNwZWNpZmljDQo+ID4gPiBm dW5jdGlvbmFsaXR5Lg0KPiA+ID4gPg0KPiA+ID4gPiBBZ3JlZWQuDQo+ID4gPiA+DQo+ID4gPiA+ IEFkcmlhbg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEZyb206IEFkcmlh biBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBB cHJpbCAxNiwgMjAwOSAxMjoxMyBBTQ0KPiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47 IExvdSBCZXJnZXI7IEJVU0kgSVRBTE8NCj4gPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4g PiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGgNCj4gPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+DQo+ID4gPiA+IEhpIFNh c2hhLA0KPiA+ID4gPg0KPiA+ID4gPiBOb3QgcmVhbGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1p c3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLg0KPiA+ID4gPg0KPiA+ID4gPiA+IDEuIE15IHJl YWRpbmcgb2YgIG9uZSBvZiBCZW4ncyAgbWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkDQo+ID4g PiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgdGhlIG9ubHkgdHlwZXMgb2YgcGF0aHMgdGhh dCBjYW4gYmUNCj4gPiA+ID4gY3JlYXRlZCBpbg0KPiA+ID4gPiA+IHRoZSBleGlzdGluZyBuZXR3 b3JrczsgInRydWUiIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzDQo+ID4gPiA+IHdpbGwg aGF2ZQ0KPiA+ID4gPiA+IHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVj b21lcyBhdmFpbGFibGUuDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgaXMgY2xlYXJseSBub25zZW5z ZSENCj4gPiA+ID4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVk DQo+ID4gYmlkaXJlY3Rpb25hbCBMU1BzIGFyZQ0KPiA+ID4gPiBhIHNwZWNpYWwgY2FzZSBvZiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4gPiA+ID4NCj4gPiA+ID4gSWYgeW91IGNh biBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgKGUuZy4gdXNpbmcgdGhlDQo+ID4gbWFu YWdlbWVudA0KPiA+ID4gPiBwbGFuZSkgeW91IGNhbiBzdXJlbHkgc2V0IHVwIGEgY28tcm91dGVk DQo+ID4gPiBiaWRpcmVjdGlvbmFsIExTUC4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlcmUgYXJlIHNo aXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkDQo+IGJpZGlyZWN0aW9uYWwN Cj4gPiA+ID4gTFNQcyB1c2luZyB0aGUgY29udHJvbCBwbGFuZS4gVGhlc2UgZWl0aGVyIHVzZSB0 aGUgR01QTFMNCj4gPiAod2hpY2ggaXMNCj4gPiA+ID4gY2xlYW5lcikgb3Igbm9uLXN0YW5kYXJk IHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggaXMNCj4gPiBtZXNzeSBidXQNCj4gPiA+ID4g ZnVuY3Rpb25hbCkuDQo+ID4gPiA+DQo+ID4gPiA+IEJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdl bWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lDQo+ID4gc29sdXRpb25zIGhhdmUNCj4gPiA+ID4g bm90aGluZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMgdGhleQ0KPiBh cmUgc29mdHdhcmUNCj4gPiA+ID4gc29sdXRpb25zLg0KPiA+ID4gPg0KPiA+ID4gPiA+IDIuIE15 IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWwNCj4g PiA+ID4gZHJpdmVyIGZvcg0KPiA+ID4gPiA+IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhz IG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcNCj4gPiA+ID4gPiB0cmFuc3BvcnQgbmV0 d29ya3MgcmF0aGVyIHRoYW4gYW55IHNwZWNpZmljIGJlbmVmaXQuDQo+ID4gPiA+DQo+ID4gPiA+ IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRz Pw0KPiA+ID4gPiBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFkIHRoaW5nLg0KPiA+ID4g Pg0KPiA+ID4gPiBBIGxhcmdlIGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNr ZXQgbmV0d29yaw0KPiA+IHRoZSBsb29rLA0KPiA+ID4gPiBmZWVsLCBhbmQgYmVoYXZpb3JhbCBj aGFyYWN0ZXJpc3RpY3Mgb2YgYSAibGVnYWN5Ig0KPiA+ID4gPiB0cmFuc3BvcnQgbmV0d29yay4N Cj4gPiA+ID4NCj4gPiA+ID4gPiBCYXNlZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVz cyAoRldJVykgdGhhdDoNCj4gPiA+ID4gPiAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRo cyBhcmUsIGF0IGxlYXN0IGZvciB0aGUgdGltZQ0KPiA+ID4gPiA+ICAgIGJlaW5nLCB0aGUgbW9z dCBpbXBvcnRhbnQgdHlwZSBvZiBiaWRpcmVjdGlvbmFsIHBhdGhzIGluDQo+ID4gPiA+ID4gICAg TVBMUy1UUA0KPiA+ID4gPg0KPiA+ID4gPiBJIHRoaW5rIHRoYXQgaXMgd3JvbmcgYm90aCBnaXZl biBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZA0KPiA+IGdpdmVuIHRoYXQNCj4gPiA+ID4gb3RoZXIg dXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZQ0KPiBuZWVkZWQgdG8g cmVhY2gNCj4gPiA+ID4gdGhlIGZ1bGwgZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC4NCj4gPiA+ ID4NCj4gPiA+ID4gPiAqIHRoZXkgaGFkIGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5 IHR5cGUgb2YNCj4gPiBiaWRpcmVjdGlvbmFsDQo+ID4gPiA+ID4gICBwYXRocyBpbiAgcmVhbCBk ZXBsb3ltZW50cy4NCj4gPiA+ID4NCj4gPiA+ID4gSSBkb24ndCBzZWUgd2hhdCB0aGF0IGZvbGxv d3MgZnJvbS4NCj4gPiA+ID4NCj4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBBZHJpYW4NCj4gPiA+ ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiA+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbXBscy10cEBpZXRmLm9y Zw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHAN Cj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbXBscy10cEBp ZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMtdHANCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+ID4g bXBscy10cEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzLXRwDQo+ID4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscy10 cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --_000_052C67B4ED558D41BBDEA7CA9FC6DCDC145B2BD9EEatlsrvexgenat_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Neil,

Please see my question in-line.

Thanks,

Igor

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com
Sent: Tuesday, April 21, 200= 9 8:31 AM
To: liu.guoman@zte.com.cn; dbrungard@att.com
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Assoc= iated bidirectional transport path requirements

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>Liu,

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>If MPLS= -TP is going to be taken seriously as a transport network (like SDH/SONET) then th= e 2 key MUST HAVE requirements are these.

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>1 =    Provide a transparent client/server relationship...which means:

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>- =    all client bits treated equally

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>- =    client bit ordering preserved

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>- =    no attempt to infer client symbol (ie sequence of client bits) meaning and = no attempt to change client symbols

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>- =    the traffic behaviour of client X must not impact the performance experienc= ed by client Y

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>A key corollary of the above is that MPLS-TP must only support proper connections= (ie single source constructs)

2=        Since MPLS-TP is a transport network it is not a top-of-stack network (ie it does not support directly external message/file/stream applications). MPLS-TP therefore does not require an E-NNI specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network mode/technology.

&nbs= p;

IB>> From what you wrote above (which I completely agree with) one can draw a conclusion that it does not = make sense (or not practical to say the least) for a bi-directional MPLS-TP connection (co-routed or not) to have asymmetric (different for each direct= ion) bandwidth allocation. Do you agree with that? More generally, do you think = of any reasons why a non-top-of-stack bi-directional transport connection at a= ny layer needs to be bandwidth-wise asymmetrical?

Thanks,<= /font>

Igor

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>Now wrt= OAM MPLS-TP is a co-ps mode network. You could argue this should have FDI/AIS....however, the merit of this is highly questionable. When I = and colleagues discussed whether PBB-TE (also a co-ps mode network) should have FDI/AIS we concluded that on balance it was not a good idea.....and note th= at initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>AIS/FDI= is historically linked to the early PDH co-cs mode layer networks that used TT= L logic. When this died it put out a +5V (all 1s) signal by default, ie it required = no conscious effort to generate it.....this is key point. Further, in th= ese networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode and it's why IETF have never specified AIS for IP and its why IEEE had the good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO retaine= d it in Y.1731....but I suspect any operator planning to use Ethernet equipment would always look to IEEE stds and not ITU ones).<= /p>

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>AIS/FDI= and the co-ps mode is debatable. As I noted above, on balance we consider= ed not a good idea for PBB-TE OAM because it requires a conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling probl= ems and its one more thing to go wrong.

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>You sho= uld also have seen me make the point many times in the past that the always-on defect detection/handling OAM needs to be as simple/sparse as possible with= as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note that the OAM required fo= r each of the 3 network modes is not the same, despite what some claim.

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>regards= , Neil

From:= mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATT= LABS
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Assoc= iated bidirectional transport path requirements

Deborah:
maybe what you said is right. but I can't completely agree your opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.

do you think so.

best regards
liu

"BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>=
=B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org

2009-04-20 23:47

=CA=D5=BC=FE=C8=CB

"Maarten Vissers" <maarten.vissers@huawei.com>, <neil.2.harrison@bt.com> <= o:p>

=B3=AD=CB=CD

mpls-tp@ietf.org

=D6=F7=CC=E2

Re: [mpls-tp] Associated bidirectional transport path requirements

I agree with Neil, it is very questionable the value of AIS/FDI in a
packet network- any mode. It can result in a= DoS attack by an operator
on themselves so even Y1731 recommends not t= o block data frames:
"A MEP can decide whether it blocks dat= a frames when it detects dAIS.
The principle requirement
that influences this decision is that data f= rames ought to be forwarded
as much as possible, without
the possibility of forwarding wrong data fra= mes downstream."
Table I.7-2 shows for AIS, not to block.

And as Y1731 states, AIS can only be used un= der very constrained
architectures - if required for MPLS-TP, it = needs to have the same
guidance as in Y1731, i.e. point-to-point an= d server/client one-to-one:
"for a point-to-point ETH connection, a= MEP has only a single peer MEP.
Therefore, there
is no ambiguity regarding the peer MEP for w= hich it should suppress
alarms when it receives the
ETH-AIS information."
So should only be within one domain - then n= o need.

Deborah

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
Behalf Of Maarten Vissers
Sent: Monday, April 20, 2009 10:05 AM=
To: neil.2.harri= son@bt.com
Cc: mpls-tp@ietf= .org
Subject: Re: [mpls-tp] Associated bidirectio= nal transport path
requirements

Neil,

> but AIS/FDI in the cl mode?...do me a f= avour!

Ethernet AIS is indeed a requirement and a necessity. And you will not
be
able to understand that as long as you refus= e to accept that "cl-mode"
is a
forwarding mode within a **transport entity*= *. G.800 amendment 1 has
finally
reintroduced this transport entity into G.80= 0. Besides that, it also
introduced the **differentiated connection**= :

[G.800 am1] "A differentiated connectio= n is a transport entity that
transfers information belonging to multiple communications between ports
across a subnetwork. <..> In a differentiated connection message
contents
are interpreted to identify (sets of) communications which receive
different
treatment. The sets of communications = may be distinguished by the
forwarding identifier or other layer informa= tion. Order is not
necessarily
preserved between messages belonging to sets= of communications receiving
different treatment. Sets of communica= tions may be identified for
purposes
such as traffic conditioning or preserving communication message order."

Ethernet VLANs are in terms of G.800 "differentiated connections".
Ethernet
AIS provides AIS within the scope of such "differentiated connection".
If
you apply this to my proposed PTN layer stac= k, then the EVC layer
topology
will consists of EVC links supported by MPLS= -TP, Ethernet, PBB-TE and
P-OTN
VP trails inside metro and core domains interconnecting EVC matrices.
When
one of those EVC links is interrupted, e.g. = in the core between metro 1
and
metro 4 (see attached slide), then the EVC differentiated connection
that is
present on this link will be interrupted. At= the EVC switch/bridge node
in
metro 4 this interruption is noticed and EVC= -AIS is inserted in the
downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4
and
D5.

The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address,
which guarantees that the AIS is broadcast t= o the endpoints of the EVC.

I believe that it is time for you to adapt y= our view on co and cl modes
and
relate it to the forwarding mode **INSIDE** = a transport entity.

What we know as the internet is essentially = an "IP differentiated
connection" with a billion or more port= s.
What we know as an IP VPN is essentially an "IP differentiated
connection"
with e.g. n ports (n in the range of e.g. 2 = to 1000).
What we know as an Ethernet VLAN is essentia= lly an "Ethernet
differentiated
connection" with n ports (n in the rang= e of e.g. 2 to 1000).
What we know as a p2p MPLS E-LSP is essentia= lly an "MPLS differentiated
connection" with 2 ports. What we know as a p2p SDH VC-n is a "SD= H VC-n connection" with 2 ports.

Transport network OAM applies to transport entities, which are (in terms
of
G.800 am1) connections and differentiated connections.

Regards,
Maarten

-----Original Message-----
From: neil.2.har= rison@bt.com [mailto:neil.2.harrison@bt.com= ]
Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf= .org Subject: RE: [mpls-tp] Associated bidirectio= nal transport path requirements John, Thanks this is a great platform = to explain why OAM for the 3 network modes needs to be different. I am gett= ing a wee bit tired of folks trying to make all 3 network modes look alike (and = then, even worse, interwork them as as peers...esp when not not top-of-stack<= /font> networks...I mean how silly can we get?). &n= bsp; I am even more frustrated by the fact those peddling this FUD only ever s= eem to consider OAM and forget all other DP/CP/MP components (esp top-of-st= ack message/file/stream application adaptations). How wrong ca= n this get! In the co modes a *connection* is a very spe= cific and *constraining* construct.....I am assuming here we respect = the rules of a connection (ie single source) though some folks don't even = bother to respect this, and this is despite the fact that we all know what pr= oblems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *al= l* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic t= hen the constraining nature of the connection construct is broken. In= a nutshell what this means is that OAM that is of a request/response nature can= not be trusted in co mode networks under misconnectivity defects.....i= ndeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the= cl mode it is not right for the co mode under misconnectivity defect conditi= ons. More generally the 3 modes are different and= not just in OAM requirements....but AIS/FDI in the cl mode?.= ..do me a favour!...at least IEEE had the good sense to bin this for Ethe= rnet even though it remains in Y.1731. And which is why I often trot-= out the rather silly (to have to say this) observation that if IP (cl mode) could= do it all then why have IETF found it necessary to create MPLS (co-ps) an= d GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attem= pts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. &nb= sp;But do not be hoodwinked by those who peddle a story that that tries to make t= he OAM of the 3 modes the same. regards, Neil > -----Original Message-----<= br> > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Be= half Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; M= aarten Vissers > Cc: mpls-tp= @ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Italo, > > As described in the MPLS TP OAM Require= ments I-D, virtually all of the > OAM functions require a return path, an= d in the absence of a return > path they are disabled. > > As described in David Sinicrope's meeti= ng minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/<= br> > meeting-no > tes/20081015.mpls-interop-dt-notes.zip)= , if IP addressing is used, an > MPLS TP network needs to be capable of getting IP packets from > destination to source; neither the minu= tes nor I stipulate that a > control plane needs to be used to insta= ntiate this forwarding. > > As an aside, the issue of return path f= or unidirectional LSPs could be > charaterized as the elephant in the roo= m. In the MPLS TP OAM > Framework I-D, unicast LSPs are only mentioned three times and return > paths not at all. > > Thanks, > > John > > -----Original Message-----<= /tt> > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 = AM > > To: Drake, John E; Alexander Vains= htein; Maarten Vissers > > Cc: mp= ls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path > > requirements > > > > John, > > > > I might have missed the agreement = of MPLS-TP being capable of > > sending replies to OAM requests se= nt on uni-directional LSPs. > > > > This requirement does not belong t= o the first set of requirements > > ITU-T is expecting to be met by Oc= tober. > > > > However, I think this in a potenti= al interesting additional > > requirement to be taken into accou= nt (at worst in a > subsequent phase). > > > > I think that this requirement need= s to be evaluated versus other > > more important requirements (e.g. = the possibility to work w/o IP > > forwarding and the need for OAM to continue to monitor the data > > plane also in case of failures aff= ecting the control or management > > plane). > > > > I am open to discuss it but not su= re this is the right time because > > I wish to avoid delaying the first= phase of the design solution. > > > > Thanks, Italo > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.or= g > > > [mailto:mpls-tp-bounces@ietf.= org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 200= 9 8:00 PM > > > To: Alexander Vainshtein; Maa= rten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associ= ated bidirectional transport path > > > requirements > > > > > > At the meeting last fall at J= uniper in Massachusetts<= /st1:State>, I > > think it was > > > agreed that an MPLS TP networ= k needs to have a forwarding > > capability > > > for management, control, and = OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directio= nal LSPs) even if it does not > > have an IP > > > forwarding data plane.= > > > > > > > -----Original Message---= -- > > > > From: Alexander Vainshte= in > > > [mailto:Alexander.Vainshtein@= ecitele.com] > > > > Sent: Thursday, April 16= , 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements= > > > > > > > > Maarten, > > > > It seems that you've jus= t (implicitly and, probably, > > > > inadvertently) stated th= e following: > > > > > > > > &nb= sp; MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requi= res this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > > > > > > If this statement is cor= rect, this (IMHO and FWIW) > raises a valid > > > > question: > > > > > > > > &nb= sp; Is MPLS-TP an appropriate solution for th= ese > types of transport > > > > paths? > > > > > > > > For the reference, IP/MP= LS provides this kind of > > functionality today > > > > for (unidirectional - bu= t it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379= . And its extension to P2MP LSPs seems > > > > easy... > > > > > > > > > > > > > > > > Regards, > > > > > > > > Sash= a > > > > > > > > > > > > > > > > ________________________________________ > > > > From: mpls-tp-bounces@ie= tf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16= , 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements= > > > > > > > > Adrian, > > > > > > > > >> <quote> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> &= nbsp; functions as appropriate) of a co-routed > > > > bidirectional transport<= /font> > > > > >> &= nbsp; path at each (sub-)layer MUST be aware of the pairing > > > > >> &= nbsp; relationship of the forward and the backward > > > > directions of that > > > > >> &= nbsp; transport path. > > > > >> <end quote&g= t; > > > > > > > > > > There is no way thi= s is a functional requirement. That > > > is, there is > > > > > *nothing* that can = be observed from a black box point of > > > view that > > > > > results from adheri= ng to this requirement. > > > > > > > > Your understanding is no= t correct. It is very much > observable if > > > > this requirement is met = from a black box point of view. > > > > The MIP functions can on= ly perform the Loopback when there is a > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet > > > > received at a MIP needs = to be returned (as LBR > > > > packet) to the originati= ng MEP function via the other > > direction of > > > > the co-routed bidirectio= nal transport path. This other > direction > > > > would not be available i= n an associated bidirectional transport > > > > path... and thus the loo= pback test > > > would fail. > > > > > > > > Similarly, when we have = to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transpo= rt path. In the first case the TCM MEP > > > > Source and Sink function= s are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance > > > > monitoring.<= br> > > > > In the latter case the T= CM MEP Source and Sink functions > > are in e.g. > > > > different nodes in the n= etwork and TCM would not be able > > to provide > > > > performance monitoring.<= /font> > > > > > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as approp= riate)" should be deleted. It does not > > > > add to "The<= /tt> > > > > > intermediate nodes.= " > > > > > > > > Your understanding is no= t correct. This text must not be > > deleted at > > > > all. > > > > > > > > > Actually, I am quit= e fed up about this persistent > > > insistence on the= > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes= from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path be= ing monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the= ACH was actually in band. > > > > > > > > I don't understand where= your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i= .e. tandem) to the data path being > > > > monitored."?= > > > > > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "= link connections" and "matrix > connections". A > > > > subset of those intercon= nected link connections and matrix > > > > connections can be monit= ored and is then referred to as > a "tandem > > > > connection". There = is no "path that is parallel to the > > data path". > > > > There is only additional= OAM inserted inside the data > path by the > > > > TCM MEP_So function and = this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function.= > > > > > > > > Regards, > > > > Maarten > > > > > > > > > > > > -----Original Message---= -- > > > > From: mpls-tp-bounces@ie= tf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Adrian Farrel > > > > Sent: donderdag 16 april= 2009 11:59 > > > > To: Alexander Vainshtein= ; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements= > > > > > > > > Hi Sasha, > > > > > > > > > Unfortunately I can= not fully agree with your statement: > > > > > > > > > > <quote> > > > > > From = the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > <end quote> > > > > > > > > > > This statement woul= d be obviously correct, were it not for > > > > Requirement<= br> > > > > > 34 in the latest MP= LS-TP requirements draft > > > > > > > > OK. Got it.<= br> > > > > > > > > But what is this doing i= n the data plane requirements section? > > > > > > > > In fact, what is this requirement actually saying? > > > > > > > > > <quote> > > > > > = ;The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > = ; functions as appropriate) of a co-routed > > > > bidirectional transport<= /font> > > > > > = ; path at each (sub-)layer MUST be aware of the pairing > > > > > = ; relationship of the forward and the backward > > > > directions of that > > > > > = ; transport path. > > > > > <end quote> > > > > > > > > There is no way this is = a functional requirement. That > > is, there is > > > > *nothing* that can be ob= served from a black box point of > > view that > > > > results from adhering to= this requirement. > > > > > > > > Therefore it could be as= sumed that this requirement is met by > > > > configuring some data pl= ane database component through the > > > > management plane. The da= tabase component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > > > > > > Ben! Can we please try t= o rewrite this requirement in terms of > > > > behavior? > > > > > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is= > > > > > specific for co-rou= ted bidirectional LSPs. (The pairing > > > > requirements= > > > > > at end points for c= o-routed and associated bidirectional > > > paths are > > > > > exactly the same ev= en if they appear in two different > > > items in the > > > > > requirements' list)= . > > > > > In other words, wit= hout Requirement 34 the notion of > co-routed > > > > > bidirectional paths= would be void of any data plane content. > > > > > > > > > > The somewhat vague = scope of this requirement ("other internal > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness m= ay be required in order to comply with it. > > > > > > > > The entirety of the brac= ketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The interme= diate nodes." > > > > > > > > > The following text = in the draft increases this suspicion: > > > > > > > > > > <quote> > > > > > Tandem Conne= ction: A tandem connection is an > > arbitrary part of a > > > > > transport pa= th that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. > > The tandem > > > > > connection m= ay also include the forwarding engine(s) of > > > > the node(s)<= br> > > > > > at the edge(= s) of the segment or concatenated segment. > > > > > <end quote> > > > > > > > > Actually, I am quite fed= up about this persistent > > insistence on the > > > > inclusion of "Tande= m Connection." The definition within > > the ITU-T of > > > > this term is poorly spec= ified and comes from the > monitoring of a > > > > path that is parallel (i= .e. tandem) to the data path being > > > > monitored. This definiti= on of TC seems to be at variance, > > and would > > > > be if the ACH was actual= ly in band. > > > > > > > > > Doesn't "forwa= rding engine" sound like hardware to you? > > > > > > > > Yes, but so what?= > > > > > > > > > IMHO it is worth no= ting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > > > > > > > > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain = any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connecti= ons are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr<= br> > > > > amework-00.txt > > > > ). > > > > > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > > > > > > > The bottom line, IM= HO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths= is still required. One way to provide > > > > that could > > > > > be by explicitly li= miting Requirement 34 to specific > > > functionality. > > > > > > > > Agreed. > > > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16= , 2009 12:13 AM > > > > To: Alexander Vainshtein= ; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements= > > > > > > > > Hi Sasha, > > > > > > > > Not really sure whether = you are misrepresenting anyone, but... > > > > > > > > > 1. My reading of one of Ben's messages is that associated > > > > > bidirectional paths= are the only types of paths that can be > > > > created in > > > > > the existing networ= ks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if e= ver) new equipment becomes available. > > > > > > > > This is clearly nonsense= ! > > > > From the point of view o= f hardware, co-routed > > bidirectional LSPs are= > > > > a special case of associ= ated bidirectional LSPs. > > > > > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely se= t up a co-routed > > > bidirectional LSP. > > > > > > > > There are shipping solut= ions that achieve co-routed > bidirectional > > > > LSPs using the control p= lane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional).= > > > > > > > > But (of course) the mana= gement plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >&g= t; > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirecti= onal paths may be experience with existing > > > > > transport networks = rather than any specific benefit. > > > > > > > > Isn't that the case with= 75% of the MPLS-TP requirements? > > > > Which is not to say it i= s a bad thing. > > > > > > > > A large driver for MPLS-= TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > > > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being,= the most important type of bidirectional paths in > > > > > MPLS-T= P > > > > > > > > I think that is wrong bo= th given my statement above, and > > given that > > > > other upgrades to existi= ng MPLS solutions will be > needed to reach > > > > the full function level = of MPLS-TP. > > > > > > > > > * they had a good c= hance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > > > > > > I don't see what that fo= llows from. > > > > > > > > Cheers, > > > > Adrian > > > > > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > > > _______________________________________________ > > > mpls-tp mailing list > > > m= pls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@iet= f.org > https://www.ietf.org/mailman/listinfo/m= pls-tp > ____________________________________________= ___ mpls-tp mailing list mpls-tp@ietf.org= https://www.ietf.org/mailman/listinfo/mpls-t= p
-= ------------------------------------------------------- ZTE Inf= ormation Security Notice: The information containe= d in this mail is solely property of&nbs= p;the sender's organization. This mail communicati= on is confidential. Recipients named above ar= e obligated to maintain secrecy and are = not permitted to disclose the contents of&nbs= p;this communication to others.This em= ail and any files transmitted with it ar= e confidential and intended solely for the&nb= sp;use of the individual or entity to wh= om they are addressed. If you have recei= ved this email in error please notify th= e originator of the message. Any views e= xpressed in this message are those of th= e individual sender. This me= ssage has been scanned for viruses and S= pam by ZTE Anti-Spam system.
--_000_052C67B4ED558D41BBDEA7CA9FC6DCDC145B2BD9EEatlsrvexgenat_-- From John.E.Drake2@boeing.com Tue Apr 21 09:28:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E5728C2B1 for ; Tue, 21 Apr 2009 09:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD+i1aH3BVcJ for ; Tue, 21 Apr 2009 09:28:26 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 7015428C2A6 for ; Tue, 21 Apr 2009 09:28:26 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3LGTbJ3003882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2009 11:29:39 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3LGTbxP002884; Tue, 21 Apr 2009 11:29:37 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3LGTZBo002776; Tue, 21 Apr 2009 11:29:37 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 09:29:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 09:29:33 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01A6C4AE@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnCGw6yxJ764/ZgT/CDbKOquLQB9QAgyPlg References: <51661468CBD1354294533DA79E85955A01A6C023@XCH-SW-5V2.sw.nos.boeing.com> From: "Drake, John E" To: X-OriginalArrivalTime: 21 Apr 2009 16:29:35.0045 (UTC) FILETIME=[5B609F50:01C9C29E] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:28:28 -0000 Precisely. =20 > -----Original Message----- > From: liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn]=20 > Sent: Monday, April 20, 2009 5:45 PM > To: Drake, John E > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 >=20 > John:=20 > maybe I don't your meaning. IMO. it is necessary for=20 > unidirectional path to have a return path.=20 >=20 > regards > liu=20 >=20 >=20 >=20 > "Drake, John E" =20 >=20 > 2009-04-20 20:48 =CA=D5=BC=FE=C8=CB > =20 > =B3=AD=CB=CD > =20 > =D6=F7=CC=E2 > RE: [mpls-tp] Associated bidirectional transport path requirements >=20 > =09 >=20 >=20 >=20 >=20 >=20 > liu, >=20 > Please re-read my e-mail. You are agreeing with me. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn]=20 > > Sent: Sunday, April 19, 2009 7:01 PM > > To: Drake, John E > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > >=20 > > John=A3=BA > > I don't completely agree your opinions. for unidirectional=20 > > P2P and P2MP path, if there is no return path, how can sink=20 > > points reply to source point's request packet? if there are=20 > > some faults in the backward sections of this unidirectional=20 > > path, the sink points will detects the defects, if no return=20 > > path, how can the sink points notify the fault message to=20 > > source points.=20 > > and so, I think if there is no return path, what happened to=20 > > unidirectional P2P and P2MP ?=20 > > I think we consider the return path.=20 > >=20 > > regards > > liu=20 > >=20 > >=20 > >=20 > > "Drake, John E" =20 > > =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 > >=20 > > 2009-04-18 03:02 =CA=D5=BC=FE=C8=CB > > "BUSI ITALO" , "Alexander=20 > > Vainshtein" , "Maarten=20 > > Vissers" =20 > > =B3=AD=CB=CD > > mpls-tp@ietf.org=20 > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidiroectional transport path requirements > >=20 > > =20 > >=20 > >=20 > >=20 > >=20 > > Italo, > >=20 > > As described in the MPLS TP OAM Requirements I-D, virtually=20 > all of the > > OAM functions require a return path, and in the absence of a=20 > > return path > > they are disabled. > >=20 > > As described in David Sinicrope's meeting minutes > > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > > meeting-no > > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing=20 > is used, an > > MPLS TP network needs to be capable of getting IP packets from > > destination to source; neither the minutes nor I stipulate that a > > control plane needs to be used to instantiate this forwarding. > >=20 > > As an aside, the issue of return path for unidirectional=20 > LSPs could be > > charaterized as the elephant in the room. In the MPLS TP OAM=20 > > Framework > > I-D, unicast LSPs are only mentioned three times and return=20 > > paths not at > > all. =20 > >=20 > > Thanks, > >=20 > > John > > > -----Original Message----- > > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > > > Sent: Friday, April 17, 2009 1:59 AM > > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > > > path requirements > > >=20 > > > John, > > >=20 > > > I might have missed the agreement of MPLS-TP being capable of=20 > > > sending replies to OAM requests sent on uni-directional LSPs. > > >=20 > > > This requirement does not belong to the first set of=20 > > > requirements ITU-T is expecting to be met by October. > > >=20 > > > However, I think this in a potential interesting additional=20 > > > requirement to be taken into account (at worst in a=20 > > subsequent phase). > > >=20 > > > I think that this requirement needs to be evaluated versus=20 > > > other more important requirements (e.g. the possibility to=20 > > > work w/o IP forwarding and the need for OAM to continue to=20 > > > monitor the data plane also in case of failures affecting the=20 > > > control or management plane). > > >=20 > > > I am open to discuss it but not sure this is the right time=20 > > > because I wish to avoid delaying the first phase of the=20 > > > design solution. > > >=20 > > > Thanks, Italo > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > > Sent: Thursday, April 16, 2009 8:00 PM > > > > To: Alexander Vainshtein; Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > At the meeting last fall at Juniper in Massachusetts, I=20 > > > think it was=20 > > > > agreed that an MPLS TP network needs to have a forwarding=20 > > > capability=20 > > > > for management, control, and OAM packets (e.g., sending=20 > > > replies to OAM=20 > > > > requests sent on uni-directional LSPs) even if it does not=20 > > > have an IP=20 > > > > forwarding data plane. > > > >=20 > > > > > -----Original Message----- > > > > > From: Alexander Vainshtein > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > > To: Maarten Vissers > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Maarten, > > > > > It seems that you've just (implicitly and, probably, > > > > > inadvertently) stated the following: > > > > >=20 > > > > > MPLS-TP OAM will not ever support MIP=20 > > loopback function=20 > > > (and fault=20 > > > > > localization which requires this function ) for=20 > > > unidirectional P2MP=20 > > > > > and P2P paths. > > > > >=20 > > > > > If this statement is correct, this (IMHO and FWIW)=20 > > raises a valid=20 > > > > > question: > > > > >=20 > > > > > Is MPLS-TP an appropriate solution for=20 > > these types of transport=20 > > > > > paths? > > > > >=20 > > > > > For the reference, IP/MPLS provides this kind of=20 > > > functionality today=20 > > > > > for (unidirectional - but it does not know any other=20 > > > type) P2P LSPs =20 > > > > > as described in RFC 4379. And its extension to P2MP=20 > LSPs seems=20 > > > > > easy... > > > > >=20 > > > > > =20 > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Sasha > > > > >=20 > > > > >=20 > > > > >=20 > > > > > ________________________________________ > > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org]=20 > > > On Behalf=20 > > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > > To: 'Adrian Farrel' > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Adrian, > > > > >=20 > > > > > >> > > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > > other internal > > > > > >> functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > > >> relationship of the forward and the backward > > > > > directions of that > > > > > >> transport path. > > > > > >> > > > > > > > > > > > > There is no way this is a functional requirement. That > > > > is, there is > > > > > > *nothing* that can be observed from a black box point of > > > > view that > > > > > > results from adhering to this requirement. > > > > >=20 > > > > > Your understanding is not correct. It is very much=20 > > observable if=20 > > > > > this requirement is met from a black box point of view. > > > > > The MIP functions can only perform the Loopback when=20 > there is a=20 > > > > > co-routed bidirectional transport path. The MPLS-TP=20 > LBM packet=20 > > > > > received at a MIP needs to be returned (as LBR > > > > > packet) to the originating MEP function via the other=20 > > > direction of=20 > > > > > the co-routed bidirectional transport path. This other=20 > > direction=20 > > > > > would not be available in an associated bidirectional=20 > transport=20 > > > > > path... and thus the loopback test > > > > would fail. > > > > >=20 > > > > > Similarly, when we have to apply TCM MEPs to monitor a=20 > > > segment, then=20 > > > > > this is possible in a co-routed bidir transport path=20 > > but not in a=20 > > > > > associated bidir transport path. In the first case=20 > the TCM MEP=20 > > > > > Source and Sink functions are co-located and can=20 > > exchange what is=20 > > > > > called "remote information" which is necessary for=20 > performance=20 > > > > > monitoring. > > > > > In the latter case the TCM MEP Source and Sink functions=20 > > > are in e.g.=20 > > > > > different nodes in the network and TCM would not be able=20 > > > to provide=20 > > > > > performance monitoring. > > > > >=20 > > > > > > The entirety of the bracketted text "(including MEPs, > > > > MIPs and other > > > > > internal > > > > > > functions as appropriate)" should be deleted. It does not > > > > > add to "The > > > > > > intermediate nodes." > > > > >=20 > > > > > Your understanding is not correct. This text must not be=20 > > > deleted at=20 > > > > > all. > > > > >=20 > > > > > > Actually, I am quite fed up about this persistent > > > > insistence on the > > > > > inclusion > > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > > this term > > > > > > is > > > > > poorly > > > > > > specified and comes from the monitoring of a path that is > > > > > parallel (i.e. > > > > > tandem) > > > > > > to the data path being monitored. This definition of TC > > > > > seems to be at > > > > > variance, > > > > > > and would be if the ACH was actually in band. > > > > >=20 > > > > > I don't understand where your interpretation of tandem=20 > > > connection is=20 > > > > > described in ITU-T recommendations. I.e. "from the=20 > > > monitoring of a=20 > > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > > monitored."? > > > > >=20 > > > > > There is a "network connection" and this network=20 > > > connection is a set=20 > > > > > of interconnected "link connections" and "matrix=20 > > connections". A=20 > > > > > subset of those interconnected link connections and matrix=20 > > > > > connections can be monitored and is then referred to as=20 > > a "tandem=20 > > > > > connection". There is no "path that is parallel to the=20 > > > data path".=20 > > > > > There is only additional OAM inserted inside the data=20 > > path by the=20 > > > > > TCM MEP_So function and this OAM is extracted from the=20 > > > data path by=20 > > > > > the TCM MEP_Sk function. > > > > >=20 > > > > > Regards, > > > > > Maarten > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > > Sent: donderdag 16 april 2009 11:59 > > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Hi Sasha, > > > > >=20 > > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > > bidirectional LSPs > > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > > Requirement > > > > > > 34 in the latest MPLS-TP requirements draft > > > > >=20 > > > > > OK. Got it. > > > > >=20 > > > > > But what is this doing in the data plane requirements section? > > > > >=20 > > > > > In fact, what is this requirement actually saying? > > > > >=20 > > > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > > > functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > > relationship of the forward and the backward > > > > > directions of that > > > > > > transport path. > > > > > > > > > > >=20 > > > > > There is no way this is a functional requirement. That=20 > > > is, there is > > > > > *nothing* that can be observed from a black box point of=20 > > > view that=20 > > > > > results from adhering to this requirement. > > > > >=20 > > > > > Therefore it could be assumed that this requirement is met by=20 > > > > > configuring some data plane database component through the=20 > > > > > management plane. The database component is not used=20 > > for anything=20 > > > > > except to satisfy this requirement for "awareness". > > > > >=20 > > > > > Ben! Can we please try to rewrite this requirement in=20 > terms of=20 > > > > > behavior? > > > > >=20 > > > > > > Please note that Requirement 34 is the ONLY item in the > > > > > list that is > > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > > requirements > > > > > > at end points for co-routed and associated bidirectional > > > > paths are > > > > > > exactly the same even if they appear in two different > > > > items in the > > > > > > requirements' list). > > > > > > In other words, without Requirement 34 the notion of=20 > > co-routed=20 > > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > > > The somewhat vague scope of this requirement=20 > ("other internal=20 > > > > > > functions as appropriate") creates a suspicion that HW > > > > > support of the > > > > > > pairing awareness may be required in order to=20 > comply with it. > > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs,=20 > > > MIPs and other=20 > > > > > internal functions as appropriate)" should be deleted. It=20 > > > does not=20 > > > > > add to "The intermediate nodes." > > > > >=20 > > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an=20 > > > arbitrary part of a > > > > > > transport path that can be monitored (via OAM) > > > > > independently from the > > > > > > end-to-end monitoring (OAM). It may be a monitored=20 > > > segment or a > > > > > > monitored concatenated segment of a transport path. =20 > > > The tandem > > > > > > connection may also include the forwarding engine(s) of > > > > > the node(s) > > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > > > >=20 > > > > > Actually, I am quite fed up about this persistent=20 > > > insistence on the=20 > > > > > inclusion of "Tandem Connection." The definition within=20 > > > the ITU-T of=20 > > > > > this term is poorly specified and comes from the=20 > > monitoring of a=20 > > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > > monitored. This definition of TC seems to be at variance,=20 > > > and would=20 > > > > > be if the ACH was actually in band. > > > > >=20 > > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > > >=20 > > > > > Yes, but so what? > > > > >=20 > > > > > > IMHO it is worth noting that neither the MPLS-TP > > > > Requirements draft > > > > > > nor the MPLS-TP OAM requirements one > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > > ts-01.txt) contain any requirements dealing with tandem > > > > connections. > > > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM=20 > > > Framework=20 > > > > > > draft > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > > amework-00.txt > > > > > ). > > > > >=20 > > > > > Right. > > > > > Let's just get rid of an unnecessary term and bring all=20 > > the I-Ds=20 > > > > > into line. > > > > >=20 > > > > > > The bottom line, IMHO, is that some clarity regarding > > > > co-routed vs. > > > > > > associated > > > > > > bidirectional paths is still required. One way to provide > > > > > that could > > > > > > be by explicitly limiting Requirement 34 to specific > > > > functionality. > > > > >=20 > > > > > Agreed. > > > > >=20 > > > > > Adrian > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > ________________________________________ > > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Hi Sasha, > > > > >=20 > > > > > Not really sure whether you are misrepresenting anyone, but... > > > > >=20 > > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > > bidirectional paths are the only types of paths that can be > > > > > created in > > > > > > the existing networks; "true" co-routed bidirectional paths > > > > > will have > > > > > > to wait until (if ever) new equipment becomes available. > > > > >=20 > > > > > This is clearly nonsense! > > > > > From the point of view of hardware, co-routed=20 > > > bidirectional LSPs are=20 > > > > > a special case of associated bidirectional LSPs. > > > > >=20 > > > > > If you can set up two unidirectional LSPs (e.g. using the=20 > > > management=20 > > > > > plane) you can surely set up a co-routed > > > > bidirectional LSP. > > > > >=20 > > > > > There are shipping solutions that achieve co-routed=20 > > bidirectional=20 > > > > > LSPs using the control plane. These either use the GMPLS=20 > > > (which is=20 > > > > > cleaner) or non-standard proprietary solutions (which is=20 > > > messy but=20 > > > > > functional). > > > > >=20 > > > > > But (of course) the management plane or control plane=20 > > > solutions have=20 > > > > > nothing to do with availability of equipment as they=20 > > are software=20 > > > > > solutions. > > > > >=20 > > > > > > 2. My reading of one of Neil's messages is that the actual > > > > > driver for > > > > > > co-routed bidirectional paths may be experience=20 > with existing=20 > > > > > > transport networks rather than any specific benefit. > > > > >=20 > > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > > Which is not to say it is a bad thing. > > > > >=20 > > > > > A large driver for MPLS-TP is to give the packet network=20 > > > the look,=20 > > > > > feel, and behavioral characteristics of a "legacy" > > > > > transport network. > > > > >=20 > > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > > * associated bidirectional paths are, at least for the time > > > > > > being, the most important type of bidirectional paths in > > > > > > MPLS-TP > > > > >=20 > > > > > I think that is wrong both given my statement above, and=20 > > > given that=20 > > > > > other upgrades to existing MPLS solutions will be=20 > > needed to reach=20 > > > > > the full function level of MPLS-TP. > > > > >=20 > > > > > > * they had a good chance to remain the only type of=20 > > > bidirectional > > > > > > paths in real deployments. > > > > >=20 > > > > > I don't see what that follows from. > > > > >=20 > > > > > Cheers, > > > > > Adrian > > > > >=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > >=20 > >=20 > >=20 > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in=20 > > this mail is solely property of the sender's organization.=20 > > This mail communication is confidential. Recipients named=20 > > above are obligated to maintain secrecy and are not permitted=20 > > to disclose the contents of this communication to others. > > This email and any files transmitted with it are confidential=20 > > and intended solely for the use of the individual or entity=20 > > to whom they are addressed. If you have received this email=20 > > in error please notify the originator of the message. Any=20 > > views expressed in this message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE=20 > > Anti-Spam system. > >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in=20 > this mail is solely property of the sender's organization.=20 > This mail communication is confidential. Recipients named=20 > above are obligated to maintain secrecy and are not permitted=20 > to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential=20 > and intended solely for the use of the individual or entity=20 > to whom they are addressed. If you have received this email=20 > in error please notify the originator of the message. Any=20 > views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE=20 > Anti-Spam system. >=20 From neil.2.harrison@bt.com Tue Apr 21 09:49:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350D028C15D for ; Tue, 21 Apr 2009 09:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7P-4fZ+xPPf for ; Tue, 21 Apr 2009 09:49:06 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id F118228C126 for ; Tue, 21 Apr 2009 09:49:04 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 17:50:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C2A1.3F4C919A" Date: Tue, 21 Apr 2009 17:50:22 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047562BB@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B2BD9EE@atl-srv-exgen.atl.advaoptical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: AcnCJcNHHo+eAHyvRdGt/oqSgC/iuwAUreqgAAhhG7AAALAR0A== From: To: , , X-OriginalArrivalTime: 21 Apr 2009 16:50:17.0400 (UTC) FILETIME=[3FE0F380:01C9C2A1] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:49:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C2A1.3F4C919A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIElnb3IuLi4uYW4gZ3JlYXQgcXVlc3Rpb24uLi5teSBjb21tZW50cyBhcmUgaW4tbGlu ZToNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJRnJvbTogSWdvciBC cnlza2luIFttYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tXSANCglTZW50OiAyMSBBcHJp bCAyMDA5IDE3OjEyDQoJVG86IEhhcnJpc29uLE4sTmVpbCxDWE0gUjsgbGl1Lmd1b21hbkB6dGUu Y29tLmNuOyBkYnJ1bmdhcmRAYXR0LmNvbQ0KCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJU3ViamVj dDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgg cmVxdWlyZW1lbnRzDQoJDQoJDQoNCglOZWlsLA0KDQoJIA0KDQoJUGxlYXNlIHNlZSBteSBxdWVz dGlvbiBpbi1saW5lLg0KDQoJIA0KDQoJVGhhbmtzLA0KDQoJSWdvcg0KDQoJIA0KDQoJDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCglGcm9tOiBtcGxzLXRwLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBu ZWlsLjIuaGFycmlzb25AYnQuY29tDQoJU2VudDogVHVlc2RheSwgQXByaWwgMjEsIDIwMDkgODoz MSBBTQ0KCVRvOiBsaXUuZ3VvbWFuQHp0ZS5jb20uY247IGRicnVuZ2FyZEBhdHQuY29tDQoJQ2M6 IG1wbHMtdHBAaWV0Zi5vcmcNCglTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0KCSANCg0KCUxpdSwNCg0K CSANCg0KCUlmIE1QTFMtVFAgaXMgZ29pbmcgdG8gYmUgdGFrZW4gc2VyaW91c2x5IGFzIGEgdHJh bnNwb3J0IG5ldHdvcmsgKGxpa2UgU0RIL1NPTkVUKSB0aGVuIHRoZSAyIGtleSBNVVNUIEhBVkUg cmVxdWlyZW1lbnRzIGFyZSB0aGVzZS4NCg0KCSANCg0KCTEgICAgUHJvdmlkZSBhIHRyYW5zcGFy ZW50IGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwLi4ud2hpY2ggbWVhbnM6DQoNCgktICAgIGFs bCBjbGllbnQgYml0cyB0cmVhdGVkIGVxdWFsbHkNCg0KCS0gICAgY2xpZW50IGJpdCBvcmRlcmlu ZyBwcmVzZXJ2ZWQNCg0KCS0gICAgbm8gYXR0ZW1wdCB0byBpbmZlciBjbGllbnQgc3ltYm9sIChp ZSBzZXF1ZW5jZSBvZiBjbGllbnQgYml0cykgbWVhbmluZyBhbmQgbm8gYXR0ZW1wdCB0byBjaGFu Z2UgY2xpZW50IHN5bWJvbHMNCg0KCS0gICAgdGhlIHRyYWZmaWMgYmVoYXZpb3VyIG9mIGNsaWVu dCBYIG11c3Qgbm90IGltcGFjdCB0aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQgYnkgY2xpZW50 IFkNCg0KCSANCg0KCUEga2V5IGNvcm9sbGFyeSBvZiB0aGUgYWJvdmUgaXMgdGhhdCBNUExTLVRQ IG11c3Qgb25seSBzdXBwb3J0IHByb3BlciBjb25uZWN0aW9ucyAoaWUgc2luZ2xlIHNvdXJjZSBj b25zdHJ1Y3RzKQ0KDQoJIA0KDQoJIA0KDQoJMiAgICAgICBTaW5jZSBNUExTLVRQIGlzIGEgdHJh bnNwb3J0IG5ldHdvcmsgaXQgaXMgbm90IGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgKGllIGl0IGRv ZXMgbm90IHN1cHBvcnQgZGlyZWN0bHkgZXh0ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBs aWNhdGlvbnMpLiAgTVBMUy1UUCB0aGVyZWZvcmUgZG9lcyBub3QgcmVxdWlyZSBhbiBFLU5OSSBz cGVjaWZpY2F0aW9uLiAgQSBrZXkgY29yb2xsYXJ5IG9mIHRoaXMgaXMgdGhhdCBNUExTLVRQIHdp bGwgbm90IGhhdmUgYW55IHBlZXIgaW50ZXJ3b3JraW5nIHJlbGF0aW9uc2hpcCB3aXRoIGFueSBv dGhlciBuZXR3b3JrIG1vZGUvdGVjaG5vbG9neS4NCg0KCSANCg0KCUlCPj4gRnJvbSB3aGF0IHlv dSB3cm90ZSBhYm92ZSAod2hpY2ggSSBjb21wbGV0ZWx5IGFncmVlIHdpdGgpIA0KDQoJIA0KDQoJ Tkg9PiBUaGFua3MuLi4uYW5kIHRoaXMgaXMgdmVyeSBpbXBvcnRhbnQgaWYgd2UgYXJlIHRvIGF2 b2lkIGdlbmVyYXRpbmcgbG9hZHMgb2YgdW5uZWNlc3Nhcnkgd29yayBhbmQgY3JlYXRpbmcgZG93 bnN0cmVhbSBwcm9ibGVtcy9jb3N0cy4gIEkgZG8gaG9wZSBvdGhlcnMgY2FuIGFsc28gc2VlIHRo aXMuDQoNCgkgDQoNCgkgIG9uZSBjYW4gZHJhdyBhIGNvbmNsdXNpb24gdGhhdCBpdCBkb2VzIG5v dCBtYWtlIHNlbnNlIChvciBub3QgcHJhY3RpY2FsIHRvIHNheSB0aGUgbGVhc3QpIGZvciBhIGJp LWRpcmVjdGlvbmFsIE1QTFMtVFAgY29ubmVjdGlvbiAoY28tcm91dGVkIG9yIG5vdCkgdG8gaGF2 ZSBhc3ltbWV0cmljIChkaWZmZXJlbnQgZm9yIGVhY2ggZGlyZWN0aW9uKSBiYW5kd2lkdGggYWxs b2NhdGlvbi4gRG8geW91IGFncmVlIHdpdGggdGhhdD8gIA0KDQoJIA0KDQoJTkg9PiBJdCdzIGhh cmQgdG8gdW5kZXJzdGFuZCB3aHkgYSB0cmFuc3BvcnQgbmV0d29yayB3b3VsZCByZXF1aXJlIGFz eW1tZXRyaWMgQlcuLi50aG91Z2ggY2xlYXJseSBzdWNoIGEgY29uc3RydWN0IGNvdWxkIGJlIGNy ZWF0ZWQuIA0KDQoJIA0KDQoJQnV0IGxldCB1cyBwYXVzZSBmb3IgYSBtb21lbnQgYW5kIGNvbnNp ZGVyIHdoYXQgYSB0cmFuc3BvcnQgbmV0d29yayBtdXN0IGRvIGluIHRyeWluZyB0byBhbnN3ZXIg dGhpcyBnb29kIHF1ZXN0aW9uLg0KDQoJIA0KDQoJQXMgSSBub3RlZCBpbiAxIGFib3ZlLCBhIGNy aXRpY2FsIGJlaGF2aW91ciBvZiBhIHRyYW5zcG9ydCBuZXR3b3JrIGlzIHRvIHByb3ZpZGUgYSB0 cmFuc3BhcmVudCBjbGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcC4uLi5pbiBlc3NlbmNlIGl0IGlz IGNyZWF0aW5nIGNsaWVudCBuZXR3b3JrIHRvcG9sb2d5LiANCg0KCSANCg0KCUFuZCBhbHRob3Vn aCBJIGRpZCBub3QgZWxhYm9yYXRlIGFib3ZlIHdoeSB0aGlzIGlzIHNvIGltcG9ydGFudCwgb25j ZSB5b3Ugc3RhcnQgdG8gdGhpbmsgYWJvdXQgd2hhdCBpdCB3b3VsZCBiZSBjYXJyeWluZyBpdCBp cyBsaWtlbHkgdG8gYmUgYSB2ZXJ5IGxhcmdlIGFnZ3JlZ2F0ZSBvZiAodWx0aW1hdGUuLi5ub3Qg bmVjZXNzYXJpbHkgaW4gdGhlIGltbWVkaWF0ZSBjbGllbnQgbmV0d29yaykgbWVzc2FnZS9maWxl L3N0cmVhbSBhcHBsaWNhdGlvbnMuLi4ubm90aW5nIHRoYXQgdGhlIHNwZWNpZmljIG1peCBvZiBt ZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyBjYW4gdmFyeSBlcG9jaCBieSBlcG9jaC4g ICBJbmRlZWQgaXQgbXVzdCBjYXJyeSBzdWNoIGFuIGFnZ3JlZ2F0ZSwgYmVjYXVzZSBhbGwgbmV0 d29ya3Mgb25seSBoYXZlIHB1cnBvc2UgaWYgdGhleSBhcmUgdWx0aW1hdGVseSBzdXBwb3J0aW5n IGV4dGVybmFsICh0byB0aGUgbmV0d29ya3MpIG1lc3NhZ2UvZmlsZS9zdHJlYW0gaW5mb3JtYXRp b24gdHJhbnNmZXJzLi4uc28gd2hpbHN0IHRoaXMgdHJhbnNwb3J0IG5ldHdvcmsgaXMgbm90IGEg dG9wLW9mLXN0YWNrIG5ldHdvcmsgdGhlcmUgbXVzdCBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIHBy ZXNlbnQgKHNvbWV0aGluZyBJIHRoaW5rIHNvbWUgcGVvcGxlIGZhaWwgdG8gZnVsbHkgYXBwcmVj aWF0ZSkuIA0KDQoJIA0KDQoJTm93IHdoaWxzdCB0aGUgUW9TICg9PWRlbGF5KSByZXF1aXJlbWVu dHMgb2YgZWl0aGVyIG1lc3NhZ2UsIGZpbGUgb2Ygc3RyZWFtIGFwcGxpY2F0aW9ucyBpcyBsYXJn ZWx5IGludmFyaWFudCB3aXRoaW4gZWFjaCBhcHBsaWNhdGlvbiB0eXBlLCB0aGUgc3Vydml2YWJp bGl0eSBpbXBvcnRhbmNlIGNhbiB0YWtlIG9uIGFueSB2YWx1ZSBmb3IgYW55IGFwcGxpY2F0aW9u IHR5cGUuICBTbyB0cmFuc3BhcmVuY3kgKGFzIEkgZGVmaW5lZCBpdCBhYm92ZSkgaXMgdGhlcmZv cmUgbm90IG1lcmVseSBzb21lIGFic3RyYWN0IHJlcXVpcmVtZW50IGJ1dCBpdCBpcyBwcmFjdGlj YWxseSBlc3NlbnRpYWwgdG8gaGF2ZSB0aGlzIGJlaGF2aW91ciB0byBtYWtlIHRoZSB0cmFuc3Bv cnQgbmV0d29yayBvcGVyYXRpb25hbGx5IHRyYWN0YWJsZSAoaWUgc2ltcGxlIG9mIHRyYW5zZmVy IGZ1bmN0aW9uKS4gIE1vcmVvdmVyLCBhcyBhIHNlcnZlciBsYXllciB3ZSBjYW4gbWFrZSBubyBq dWRnZW1lbnQgb24gdGhlIGltcG9ydGFuY2Ugb2YgYSBzcGVjaWZpYyBhcHBsaWNhdGlvbiB0aGF0 IG1heSBiZSBzZXJ2ZXJhbCBsYXllciBhYm92ZSB1cyBhbnl3YXkuLi4uLmVyZ28gd2UgKm11c3Qq IGhhdmUgdHJhbnNwYXJlbmN5IGFzIGEgY3JpdGljYWwgYmVoYXZpb3VyIGluIGEgdHJhbnNwb3J0 IG5ldHdvcmsuDQoNCgkgDQoNCglPZiBjb3Vyc2UgdHJhbnNwYXJlbmN5IGlzIGEgZm9yY2VkIGJl aGF2aW91ciBpbiB0aGUgY28tY3MgbW9kZSAoaWUgbm8gUW9TIG9yIHN1cnZpdmFiaWxpdHkgaW1w b3J0YW5jZSBtYXJraW5ncyBoZXJlKSwgYW5kIHRoaXMgKHNpbXBsaWNpdHkpIGlzIHdoeSB0aGUg Y28tY3MgbW9kZSBoYXMgYmVlbiBzbyBlbmR1cmluZ2x5IHN1Y2Nlc3NmdWwgaW4gYSB0cmFuc3Bv cnQgcm9sZSwgZWcgUERIIGFuZCBTREguICBXaGVuIHdlIHVzZSBhIGNvLXBzIG1vZGUgdG8gcHJv dmlkZSBhIHRyYW5zcG9ydCByb2xlIHdlIG11c3QgYmUgc3VyZSB3ZSBlbXVsYXRlIHRoaXMgdHJh bnNwYXJlbmN5IGJlaGF2aW91ci4NCg0KCSANCg0KCVNvcnJ5IEkgaGF2ZSBsYWJvcmVkIHRoaXMg cG9pbnQgb24gdHJhbnNwYXJlbmN5IGEgYml0LCBidXQgSSBob3BlIGZvbGtzIGNhbiBzZWUgd2h5 IGl0IGlzIHJhdGhlciBwcmFjdGljYWxseSBpbXBvcnRhbnQuICBBbmQgbXkgcG9pbnQgYWJvdXQg dGhlIGxhcmdlIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYWdncmVnYXRlcyB0aGF0IG11c3QgdWx0aW1h dGVseSBiZSBjYXJyaWVkIHRlbmRzIHRvIHN1cHBvcnQgYSBwb3NpdGlvbiBvZiBzeW1tZXRyaWMg QlcgSU1PLg0KDQoJICANCg0KCSANCg0KCSBNb3JlIGdlbmVyYWxseSwgZG8geW91IHRoaW5rIG9m IGFueSByZWFzb25zIHdoeSBhIG5vbi10b3Atb2Ytc3RhY2sgYmktZGlyZWN0aW9uYWwgdHJhbnNw b3J0IGNvbm5lY3Rpb24gYXQgYW55IGxheWVyIG5lZWRzIHRvIGJlIGJhbmR3aWR0aC13aXNlIGFz eW1tZXRyaWNhbD8NCg0KCSANCg0KCU5IPT4gSSBjYW4ndCBzYXkgdGhhdCBJIGNhbi4NCg0KCSAN Cg0KCSAgcmVnYXJkcywgTmVpbA0KDQoJIA0KDQoJIFRoYW5rcywNCg0KCUlnb3INCg0KCSBoZw0K DQoJTm93IHdydCBPQU0gTVBMUy1UUCBpcyBhIGNvLXBzIG1vZGUgbmV0d29yay4gIFlvdSBjb3Vs ZCBhcmd1ZSB0aGlzIHNob3VsZCBoYXZlIEZESS9BSVMuLi4uaG93ZXZlciwgdGhlIG1lcml0IG9m IHRoaXMgaXMgaGlnaGx5IHF1ZXN0aW9uYWJsZS4gIFdoZW4gSSBhbmQgY29sbGVhZ3VlcyBkaXNj dXNzZWQgd2hldGhlciBQQkItVEUgKGFsc28gYSBjby1wcyBtb2RlIG5ldHdvcmspIHNob3VsZCBo YXZlIEZESS9BSVMgd2UgY29uY2x1ZGVkIHRoYXQgb24gYmFsYW5jZSBpdCB3YXMgbm90IGEgZ29v ZCBpZGVhLi4uLi5hbmQgbm90ZSB0aGF0IGluaXRpYWxseSBJIHdhcyBpbiBmYXZvdXIgb2YgaGF2 aW5nIEFJUywgYnV0IG15IGNvbGxlYWd1ZXMgcHJvdmlkZWQgc3Ryb25nIHRlY2huaWNhbCBhcmd1 bWVudHMgdGhhdCBjb252aW5jZWQgbWUgb3RoZXJ3aXNlLg0KDQoJIA0KDQoJQUlTL0ZESSBpcyBo aXN0b3JpY2FsbHkgbGlua2VkIHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXllciBuZXR3 b3JrcyB0aGF0IHVzZWQgVFRMIGxvZ2ljLiAgV2hlbiB0aGlzIGRpZWQgaXQgcHV0IG91dCBhICs1 ViAoYWxsIDFzKSBzaWduYWwgYnkgZGVmYXVsdCwgaWUgaXQgcmVxdWlyZWQgbm8gY29uc2Npb3Vz IGVmZm9ydCB0byBnZW5lcmF0ZSBpdC4uLi4udGhpcyBpcyBrZXkgcG9pbnQuICBGdXJ0aGVyLCBp biB0aGVzZSBuZXR3b3JrcyB0aGVyZSBpcyBhIGZhaXJseSBzdGF0aWMvbG9uZy1ob2xkaW5nIGNs aWVudCBzZXJ2ZXIgcmVsYXRpb25zaGlwLiAgQ2xlYXJseSB0aGlzIGlzIG5vdCB0cnVlIGluIHRo ZSBjbC1wcyBtb2RlIGFuZCBpdCdzIHdoeSBJRVRGIGhhdmUgbmV2ZXIgc3BlY2lmaWVkIEFJUyBm b3IgSVAgYW5kIGl0cyB3aHkgSUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2UgdG8gdGhyb3ctb3V0IEFJ UyBpbiA4MDIuMWFnIGZvciBFdGhlcm5ldCAodGhvdWdoIElUVSBoYXZlIHVud2lzZWx5IElNTyBy ZXRhaW5lZCBpdCBpbiBZLjE3MzEuLi4uYnV0IEkgc3VzcGVjdCBhbnkgb3BlcmF0b3IgcGxhbm5p bmcgdG8gdXNlIEV0aGVybmV0IGVxdWlwbWVudCB3b3VsZCBhbHdheXMgbG9vayB0byBJRUVFIHN0 ZHMgYW5kIG5vdCBJVFUgb25lcykuDQoNCgkgDQoNCglBSVMvRkRJIGFuZCB0aGUgY28tcHMgbW9k ZSBpcyBkZWJhdGFibGUuICBBcyBJIG5vdGVkIGFib3ZlLCBvbiBiYWxhbmNlIHdlIGNvbnNpZGVy ZWQgbm90IGEgZ29vZCBpZGVhIGZvciBQQkItVEUgT0FNIGJlY2F1c2UgaXQgcmVxdWlyZXMgYSBj b25zY2lvdXMgZWZmb3J0IHRvIGdlbmVyYXRlIGl0ICh1bmxpa2UgdGhlIGNvLWNzIG1vZGUpIHNv IHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUgc2NhbGluZyBwcm9ibGVtcyBhbmQgaXRzIG9uZSBtb3Jl IHRoaW5nIHRvIGdvIHdyb25nLg0KDQoJIA0KDQoJWW91IHNob3VsZCBhbHNvIGhhdmUgc2VlbiBt ZSBtYWtlIHRoZSBwb2ludCBtYW55IHRpbWVzIGluIHRoZSBwYXN0IHRoYXQgdGhlIGFsd2F5cy1v biBkZWZlY3QgZGV0ZWN0aW9uL2hhbmRsaW5nIE9BTSBuZWVkcyB0byBiZSBhcyBzaW1wbGUvc3Bh cnNlIGFzIHBvc3NpYmxlIHdpdGggYXMgbGl0dGxlIGNvbmZpZyBhcyBwb3NzaWJsZSBiZWNhdXNl IHdlIG5lZWQgc3VwZXIgcmVsaWFiaWxpdHkuLi4uLi5UQ00gZ29lcyBjb21wbGV0ZWx5IGFnYWlu c3QgdGhlIGdyYWluIGhlcmUuICBBbHNvIG5vdGUgdGhhdCB0aGUgT0FNIHJlcXVpcmVkIGZvciBl YWNoIG9mIHRoZSAzIG5ldHdvcmsgbW9kZXMgaXMgbm90IHRoZSBzYW1lLCBkZXNwaXRlIHdoYXQg c29tZSBjbGFpbS4NCg0KCSANCg0KCXJlZ2FyZHMsIE5laWwNCg0KCSANCg0KCQkgDQoNCgkJDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCgkJRnJvbTogbXBscy10cC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgbGl1Lmd1b21hbkB6dGUuY29tLmNuDQoJCVNlbnQ6IDIxIEFwcmlsIDIwMDkgMDI6NTkNCgkJ VG86IEJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMNCgkJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcN CgkJU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggcmVxdWlyZW1lbnRzDQoNCgkJDQoJCURlYm9yYWg6IA0KCQkgbWF5YmUgd2hhdCB5 b3Ugc2FpZCBpcyByaWdodC4gYnV0IEkgY2FuJ3QgY29tcGxldGVseSBhZ3JlZSB5b3VyIG9waW5p b25zLiBJTU8uIG1wbHMtdHAgaXMgcmVnYXJkIGFzIHRyYW5zcG9ydCBuZXR3b3JrIGxpa2UgU0RI L1NPTkVULiBzbyBpdCBzaG91bGQgaGF2ZSBBSVMvRkRJIGZ1Y3Rpb25zIGFzIFNESC9TT05FVC4g DQoJCQ0KCQlkbyB5b3UgdGhpbmsgc28uIA0KCQkNCgkJYmVzdCByZWdhcmRzIA0KCQlsaXUgDQoJ CQ0KCQkNCg0KIkJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMiIDxkYnJ1bmdhcmRAYXR0LmNv bT4gDQrlj5Hku7bkuro6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQoNCjIwMDktMDQtMjAg MjM6NDcgDQoNCuaUtuS7tuS6ug0KDQoiTWFhcnRlbiBWaXNzZXJzIiA8bWFhcnRlbi52aXNzZXJz QGh1YXdlaS5jb20+LCA8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbT4gDQoNCuaKhOmAgQ0KDQptcGxz LXRwQGlldGYub3JnIA0KDQrkuLvpopgNCg0KUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoNCiANCg0KIA0KDQogDQoNCgkJ DQoJCQ0KCQkNCgkJSSBhZ3JlZSB3aXRoIE5laWwsIGl0IGlzIHZlcnkgcXVlc3Rpb25hYmxlIHRo ZSB2YWx1ZSBvZiBBSVMvRkRJIGluIGENCgkJcGFja2V0IG5ldHdvcmstIGFueSBtb2RlLiBJdCBj YW4gcmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBhbiBvcGVyYXRvcg0KCQlvbiB0aGVtc2VsdmVz IHNvIGV2ZW4gWTE3MzEgcmVjb21tZW5kcyBub3QgdG8gYmxvY2sgZGF0YSBmcmFtZXM6DQoJCSJB IE1FUCBjYW4gZGVjaWRlIHdoZXRoZXIgaXQgYmxvY2tzIGRhdGEgZnJhbWVzIHdoZW4gaXQgZGV0 ZWN0cyBkQUlTLg0KCQlUaGUgcHJpbmNpcGxlIHJlcXVpcmVtZW50DQoJCXRoYXQgaW5mbHVlbmNl cyB0aGlzIGRlY2lzaW9uIGlzIHRoYXQgZGF0YSBmcmFtZXMgb3VnaHQgdG8gYmUgZm9yd2FyZGVk DQoJCWFzIG11Y2ggYXMgcG9zc2libGUsIHdpdGhvdXQNCgkJdGhlIHBvc3NpYmlsaXR5IG9mIGZv cndhcmRpbmcgd3JvbmcgZGF0YSBmcmFtZXMgZG93bnN0cmVhbS4iDQoJCVRhYmxlIEkuNy0yIHNo b3dzIGZvciBBSVMsIG5vdCB0byBibG9jay4NCgkJDQoJCUFuZCBhcyBZMTczMSBzdGF0ZXMsIEFJ UyBjYW4gb25seSBiZSB1c2VkIHVuZGVyIHZlcnkgY29uc3RyYWluZWQNCgkJYXJjaGl0ZWN0dXJl cyAtIGlmIHJlcXVpcmVkIGZvciBNUExTLVRQLCBpdCBuZWVkcyB0byBoYXZlIHRoZSBzYW1lDQoJ CWd1aWRhbmNlIGFzIGluIFkxNzMxLCBpLmUuIHBvaW50LXRvLXBvaW50IGFuZCBzZXJ2ZXIvY2xp ZW50IG9uZS10by1vbmU6DQoJCSJmb3IgYSBwb2ludC10by1wb2ludCBFVEggY29ubmVjdGlvbiwg YSBNRVAgaGFzIG9ubHkgYSBzaW5nbGUgcGVlciBNRVAuDQoJCVRoZXJlZm9yZSwgdGhlcmUNCgkJ aXMgbm8gYW1iaWd1aXR5IHJlZ2FyZGluZyB0aGUgcGVlciBNRVAgZm9yIHdoaWNoIGl0IHNob3Vs ZCBzdXBwcmVzcw0KCQlhbGFybXMgd2hlbiBpdCByZWNlaXZlcyB0aGUNCgkJRVRILUFJUyBpbmZv cm1hdGlvbi4iDQoJCVNvIHNob3VsZCBvbmx5IGJlIHdpdGhpbiBvbmUgZG9tYWluIC0gdGhlbiBu byBuZWVkLg0KCQkNCgkJRGVib3JhaA0KCQkNCgkJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CgkJRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2Vz QGlldGYub3JnXSBPbg0KCQlCZWhhbGYgT2YgTWFhcnRlbiBWaXNzZXJzDQoJCVNlbnQ6IE1vbmRh eSwgQXByaWwgMjAsIDIwMDkgMTA6MDUgQU0NCgkJVG86IG5laWwuMi5oYXJyaXNvbkBidC5jb20N CgkJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCgkJcmVxdWlyZW1lbnRzDQoJCQ0KCQlO ZWlsLA0KCQkNCgkJPiBidXQgQUlTL0ZESSBpbiB0aGUgY2wgbW9kZT8uLi5kbyBtZSBhIGZhdm91 ciENCgkJDQoJCUV0aGVybmV0IEFJUyBpcyBpbmRlZWQgYSByZXF1aXJlbWVudCBhbmQgYSBuZWNl c3NpdHkuIEFuZCB5b3Ugd2lsbCBub3QNCgkJYmUNCgkJYWJsZSB0byB1bmRlcnN0YW5kIHRoYXQg YXMgbG9uZyBhcyB5b3UgcmVmdXNlIHRvIGFjY2VwdCB0aGF0ICJjbC1tb2RlIg0KCQlpcyBhDQoJ CWZvcndhcmRpbmcgbW9kZSB3aXRoaW4gYSAqKnRyYW5zcG9ydCBlbnRpdHkqKi4gRy44MDAgYW1l bmRtZW50IDEgaGFzDQoJCWZpbmFsbHkNCgkJcmVpbnRyb2R1Y2VkIHRoaXMgdHJhbnNwb3J0IGVu dGl0eSBpbnRvIEcuODAwLiBCZXNpZGVzIHRoYXQsIGl0IGFsc28NCgkJaW50cm9kdWNlZCB0aGUg KipkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uKio6DQoJCQ0KCQlbRy44MDAgYW0xXSAiQSBkaWZm ZXJlbnRpYXRlZCBjb25uZWN0aW9uIGlzIGEgdHJhbnNwb3J0IGVudGl0eSB0aGF0DQoJCXRyYW5z ZmVycyBpbmZvcm1hdGlvbiBiZWxvbmdpbmcgdG8gbXVsdGlwbGUgY29tbXVuaWNhdGlvbnMgYmV0 d2VlbiBwb3J0cw0KCQlhY3Jvc3MgYSBzdWJuZXR3b3JrLiA8Li4+IEluIGEgZGlmZmVyZW50aWF0 ZWQgY29ubmVjdGlvbiBtZXNzYWdlDQoJCWNvbnRlbnRzDQoJCWFyZSBpbnRlcnByZXRlZCB0byBp ZGVudGlmeSAoc2V0cyBvZikgY29tbXVuaWNhdGlvbnMgd2hpY2ggcmVjZWl2ZQ0KCQlkaWZmZXJl bnQNCgkJdHJlYXRtZW50LiAgVGhlIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIGRpc3Rp bmd1aXNoZWQgYnkgdGhlDQoJCWZvcndhcmRpbmcgaWRlbnRpZmllciBvciBvdGhlciBsYXllciBp bmZvcm1hdGlvbi4gIE9yZGVyIGlzIG5vdA0KCQluZWNlc3NhcmlseQ0KCQlwcmVzZXJ2ZWQgYmV0 d2VlbiBtZXNzYWdlcyBiZWxvbmdpbmcgdG8gc2V0cyBvZiBjb21tdW5pY2F0aW9ucyByZWNlaXZp bmcNCgkJZGlmZmVyZW50IHRyZWF0bWVudC4gIFNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJl IGlkZW50aWZpZWQgZm9yDQoJCXB1cnBvc2VzDQoJCXN1Y2ggYXMgdHJhZmZpYyBjb25kaXRpb25p bmcgb3IgcHJlc2VydmluZyBjb21tdW5pY2F0aW9uIG1lc3NhZ2Ugb3JkZXIuIg0KCQkNCgkJDQoJ CUV0aGVybmV0IFZMQU5zIGFyZSBpbiB0ZXJtcyBvZiBHLjgwMCAiZGlmZmVyZW50aWF0ZWQgY29u bmVjdGlvbnMiLg0KCQlFdGhlcm5ldA0KCQlBSVMgcHJvdmlkZXMgQUlTIHdpdGhpbiB0aGUgc2Nv cGUgb2Ygc3VjaCAiZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiIuDQoJCUlmDQoJCXlvdSBhcHBs eSB0aGlzIHRvIG15IHByb3Bvc2VkIFBUTiBsYXllciBzdGFjaywgdGhlbiB0aGUgRVZDIGxheWVy DQoJCXRvcG9sb2d5DQoJCXdpbGwgY29uc2lzdHMgb2YgRVZDIGxpbmtzIHN1cHBvcnRlZCBieSBN UExTLVRQLCBFdGhlcm5ldCwgUEJCLVRFIGFuZA0KCQlQLU9UTg0KCQlWUCB0cmFpbHMgaW5zaWRl IG1ldHJvIGFuZCBjb3JlIGRvbWFpbnMgaW50ZXJjb25uZWN0aW5nIEVWQyBtYXRyaWNlcy4NCgkJ V2hlbg0KCQlvbmUgb2YgdGhvc2UgRVZDIGxpbmtzIGlzIGludGVycnVwdGVkLCBlLmcuIGluIHRo ZSBjb3JlIGJldHdlZW4gbWV0cm8gMQ0KCQlhbmQNCgkJbWV0cm8gNCAoc2VlIGF0dGFjaGVkIHNs aWRlKSwgdGhlbiB0aGUgRVZDIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24NCgkJdGhhdCBpcw0K CQlwcmVzZW50IG9uIHRoaXMgbGluayB3aWxsIGJlIGludGVycnVwdGVkLiBBdCB0aGUgRVZDIHN3 aXRjaC9icmlkZ2Ugbm9kZQ0KCQlpbg0KCQltZXRybyA0IHRoaXMgaW50ZXJydXB0aW9uIGlzIG5v dGljZWQgYW5kIEVWQy1BSVMgaXMgaW5zZXJ0ZWQgaW4gdGhlDQoJCWRvd25zdHJlYW0gZGlyZWN0 aW9uIHRvIHN1cHByZXNzIHRoZSBFVkMtTE9DIGFsYXJtcyBhdCBFVkMgZW5kcG9pbnRzIEQ0DQoJ CWFuZA0KCQlENS4NCgkJDQoJCVRoZSBFVkMtQUlTIChpLmUuIEV0aGVybmV0IEFJUykgZnJhbWUg aGFzIGEgcmVzZXJ2ZWQgbXVsdGljYXN0IGFkZHJlc3MsDQoJCXdoaWNoIGd1YXJhbnRlZXMgdGhh dCB0aGUgQUlTIGlzIGJyb2FkY2FzdCB0byB0aGUgZW5kcG9pbnRzIG9mIHRoZSBFVkMuDQoJCQ0K CQlJIGJlbGlldmUgdGhhdCBpdCBpcyB0aW1lIGZvciB5b3UgdG8gYWRhcHQgeW91ciB2aWV3IG9u IGNvIGFuZCBjbCBtb2Rlcw0KCQlhbmQNCgkJcmVsYXRlIGl0IHRvIHRoZSBmb3J3YXJkaW5nIG1v ZGUgKipJTlNJREUqKiBhIHRyYW5zcG9ydCBlbnRpdHkuIA0KCQkNCgkJV2hhdCB3ZSBrbm93IGFz IHRoZSBpbnRlcm5ldCBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQNCgkJY29u bmVjdGlvbiIgd2l0aCBhIGJpbGxpb24gb3IgbW9yZSBwb3J0cy4NCgkJV2hhdCB3ZSBrbm93IGFz IGFuIElQIFZQTiBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQNCgkJY29ubmVj dGlvbiINCgkJd2l0aCBlLmcuIG4gcG9ydHMgKG4gaW4gdGhlIHJhbmdlIG9mIGUuZy4gMiB0byAx MDAwKS4NCgkJV2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMgZXNzZW50aWFsbHkg YW4gIkV0aGVybmV0DQoJCWRpZmZlcmVudGlhdGVkDQoJCWNvbm5lY3Rpb24iIHdpdGggbiBwb3J0 cyAobiBpbiB0aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEwMDApLg0KCQlXaGF0IHdlIGtub3cgYXMg YSBwMnAgTVBMUyBFLUxTUCBpcyBlc3NlbnRpYWxseSBhbiAiTVBMUyBkaWZmZXJlbnRpYXRlZA0K CQljb25uZWN0aW9uIiB3aXRoIDIgcG9ydHMuDQoJCVdoYXQgd2Uga25vdyBhcyBhIHAycCBTREgg VkMtbiBpcyBhICJTREggVkMtbiBjb25uZWN0aW9uIiB3aXRoIDIgcG9ydHMuDQoJCQ0KCQlUcmFu c3BvcnQgbmV0d29yayBPQU0gYXBwbGllcyB0byB0cmFuc3BvcnQgZW50aXRpZXMsIHdoaWNoIGFy ZSAoaW4gdGVybXMNCgkJb2YNCgkJRy44MDAgYW0xKSBjb25uZWN0aW9ucyBhbmQgZGlmZmVyZW50 aWF0ZWQgY29ubmVjdGlvbnMuDQoJCQ0KCQlSZWdhcmRzLA0KCQlNYWFydGVuDQoJCQ0KCQktLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCQlGcm9tOiBuZWlsLjIuaGFycmlzb25AYnQuY29tIFtt YWlsdG86bmVpbC4yLmhhcnJpc29uQGJ0LmNvbV0gDQoJCVNlbnQ6IHZyaWpkYWcgMTcgYXByaWwg MjAwOSAyMjowMA0KCQlUbzogSm9obi5FLkRyYWtlMkBib2VpbmcuY29tOyBJdGFsby5CdXNpQGFs Y2F0ZWwtbHVjZW50Lml0Ow0KCQlBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbWFh cnRlbi52aXNzZXJzQGh1YXdlaS5jb20NCgkJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJU3ViamVj dDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgN CgkJcmVxdWlyZW1lbnRzDQoJCQ0KCQlKb2huLCAgVGhhbmtzIHRoaXMgaXMgYSBncmVhdCBwbGF0 Zm9ybSB0byBleHBsYWluIHdoeSBPQU0gZm9yIHRoZSAzDQoJCW5ldHdvcmsNCgkJbW9kZXMgbmVl ZHMgdG8gYmUgZGlmZmVyZW50LiAgSSBhbSBnZXR0aW5nIGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xr cw0KCQl0cnlpbmcNCgkJdG8gbWFrZSBhbGwgMyBuZXR3b3JrIG1vZGVzIGxvb2sgYWxpa2UgKGFu ZCB0aGVuLCBldmVuIHdvcnNlLCBpbnRlcndvcmsNCgkJdGhlbQ0KCQlhcyBhcyBwZWVycy4uLmVz cCB3aGVuIG5vdCBub3QgdG9wLW9mLXN0YWNrDQoJCW5ldHdvcmtzLi4uSSBtZWFuIGhvdyBzaWxs eSBjYW4gd2UgZ2V0PykuICAgSSBhbSBldmVuIG1vcmUgZnJ1c3RyYXRlZCBieQ0KCQl0aGUgZmFj dCB0aG9zZSBwZWRkbGluZyB0aGlzIEZVRCBvbmx5IGV2ZXIgc2VlbSB0byBjb25zaWRlciBPQU0g YW5kDQoJCWZvcmdldA0KCQlhbGwgb3RoZXIgRFAvQ1AvTVAgY29tcG9uZW50cyAoZXNwIHRvcC1v Zi1zdGFjayBtZXNzYWdlL2ZpbGUvc3RyZWFtDQoJCWFwcGxpY2F0aW9uIGFkYXB0YXRpb25zKS4g IEhvdyB3cm9uZyBjYW4gdGhpcyBnZXQhIA0KCQkNCgkJSW4gdGhlIGNvIG1vZGVzIGEgKmNvbm5l Y3Rpb24qIGlzIGEgdmVyeSBzcGVjaWZpYyBhbmQgKmNvbnN0cmFpbmluZyoNCgkJY29uc3RydWN0 Li4uLi5JIGFtIGFzc3VtaW5nIGhlcmUgd2UgcmVzcGVjdCB0aGUgcnVsZXMgb2YgYSBjb25uZWN0 aW9uDQoJCShpZQ0KCQlzaW5nbGUgc291cmNlKSB0aG91Z2ggc29tZSBmb2xrcyBkb24ndCBldmVu IGJvdGhlciB0byByZXNwZWN0IHRoaXMsIGFuZA0KCQl0aGlzDQoJCWlzIGRlc3BpdGUgdGhlIGZh Y3QgdGhhdCB3ZSBhbGwga25vdyB3aGF0IHByb2JsZW1zIG11bHRpcGxlLXNvdXJjZQ0KCQljb25z dHJ1Y3RzIGNhbiBjYXVzZSAoZnJvbSBMRFAvUEhQLi4uLmVyZ28gTVBMUy1UUCkuDQoJCQ0KCQlX aGVuIHdlIGhhdmUgYSBjb25uZWN0aW9uIHRoaXMgcmVzdHJpY3RzICphbGwqIERQIChpZSB0cmFm ZmljIGFuZCBPQU0pDQoJCXRvDQoJCXN0YXkgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIGNvbm5l Y3Rpb24uICBXaGljaCBpcyBmaW5lIHVuZGVyDQoJCWRlZmVjdC1mcmVlDQoJCWNvbmRpdGlvbnMs IGJ1dCBpZiB3ZSBoYXZlIGxlYWtpbmcgdHJhZmZpYyB0aGVuIHRoZSBjb25zdHJhaW5pbmcgbmF0 dXJlDQoJCW9mDQoJCXRoZSBjb25uZWN0aW9uIGNvbnN0cnVjdCBpcyBicm9rZW4uICBJbiBhIG51 dHNoZWxsIHdoYXQgdGhpcyBtZWFucyBpcw0KCQl0aGF0DQoJCU9BTSB0aGF0IGlzIG9mIGEgcmVx dWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fubm90IGJlIHRydXN0ZWQgaW4gY28gbW9kZQ0KCQluZXR3 b3JrcyB1bmRlciBtaXNjb25uZWN0aXZpdHkgZGVmZWN0cy4uLi4uaW5kZWVkLCB3aHkgc2hvdWxk IGEgbGVha2luZw0KCQlEUA0KCQloYXZlIGEgc3ltbWV0cmljIGdvL3JldHVybiBkZWZlY3QgYmVo YXZpb3VyPy4uLi52ZXJ5IGxpa2VseSBpdCB3b24ndC4NCgkJU28NCgkJd2hpbHN0IHJlcXVlc3Qv cmVzcG9uc2UgT0FNIGlzIHJpZ2h0IGZvciB0aGUgY2wgbW9kZSBpdCBpcyBub3QgcmlnaHQgZm9y DQoJCXRoZQ0KCQljbyBtb2RlIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3QgY29uZGl0aW9u cy4NCgkJDQoJCU1vcmUgZ2VuZXJhbGx5IHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQgYW5kIG5v dCBqdXN0IGluIE9BTQ0KCQlyZXF1aXJlbWVudHMuLi4uYnV0IEFJUy9GREkgaW4gdGhlIGNsIG1v ZGU/Li4uZG8gbWUgYSBmYXZvdXIhLi4uYXQgbGVhc3QNCgkJSUVFRSBoYWQgdGhlIGdvb2Qgc2Vu c2UgdG8gYmluIHRoaXMgZm9yIEV0aGVybmV0IGV2ZW4gdGhvdWdoIGl0IHJlbWFpbnMNCgkJaW4N CgkJWS4xNzMxLiAgQW5kIHdoaWNoIGlzIHdoeSBJIG9mdGVuIHRyb3Qtb3V0IHRoZSByYXRoZXIg c2lsbHkgKHRvIGhhdmUgdG8NCgkJc2F5DQoJCXRoaXMpIG9ic2VydmF0aW9uIHRoYXQgaWYgSVAg KGNsIG1vZGUpIGNvdWxkIGRvIGl0IGFsbCB0aGVuIHdoeSBoYXZlDQoJCUlFVEYNCgkJZm91bmQg aXQgbmVjZXNzYXJ5IHRvIGNyZWF0ZSBNUExTIChjby1wcykgYW5kIEdNUExTIChDUCBmb3IgY28t Y3MpLiAgVGhlDQoJCWFuc3dlciBsaWVzIGluIHRoZSBwaHlzaWNzLi4uYW5kIEcuODAwIGF0dGVt cHRzIHRvIGV4cGxhaW4gdGhhdA0KCQlwaHlzaWNzLi4uLkcuODA1IGRvZXMgbm90Lg0KCQkNCgkJ U28sIHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQuLi5wbGVhc2UgYWNjZXB0L3Jlam9pY2UgaW4g dGhpcyBmYWN0IGFzDQoJCXRoZXkNCgkJYWxsIG9mZmVyIHNvbWV0aGluZyBkaWZmZXJlbnQvaW1w b3J0YW50LiAgQnV0IGRvIG5vdCBiZSBob29kd2lua2VkIGJ5DQoJCXRob3NlDQoJCXdobyBwZWRk bGUgYSBzdG9yeSB0aGF0IHRoYXQgdHJpZXMgdG8gbWFrZSB0aGUgT0FNIG9mIHRoZSAzIG1vZGVz IHRoZQ0KCQlzYW1lLiANCgkJDQoJCXJlZ2FyZHMsIE5laWwgDQoJCQ0KCQk+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoJCT4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoJCT4g W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9o biBFDQoJCT4gU2VudDogMTcgQXByaWwgMjAwOSAyMDowMg0KCQk+IFRvOiBCVVNJIElUQUxPOyBB bGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzDQoJCT4gQ2M6IG1wbHMtdHBAaWV0 Zi5vcmcNCgkJPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQgcGF0aCANCgkJPiByZXF1aXJlbWVudHMNCgkJPiANCgkJPiBJdGFsbywNCgkJ PiANCgkJPiBBcyBkZXNjcmliZWQgaW4gdGhlIE1QTFMgVFAgT0FNIFJlcXVpcmVtZW50cyBJLUQs IHZpcnR1YWxseSBhbGwgb2YgdGhlDQoJCQ0KCQk+IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJl dHVybiBwYXRoLCBhbmQgaW4gdGhlIGFic2VuY2Ugb2YgYSByZXR1cm4gDQoJCT4gcGF0aCB0aGV5 IGFyZSBkaXNhYmxlZC4NCgkJPiANCgkJPiBBcyBkZXNjcmliZWQgaW4gRGF2aWQgU2luaWNyb3Bl J3MgbWVldGluZyBtaW51dGVzIA0KCQk+IChodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9taXNj L21wbHMtaW50ZXJvcC9hdHRhY2htZW50L3dpa2kvDQoJCT4gbWVldGluZy1ubw0KCQk+IHRlcy8y MDA4MTAxNS5tcGxzLWludGVyb3AtZHQtbm90ZXMuemlwKSwgaWYgSVAgYWRkcmVzc2luZyBpcyB1 c2VkLCBhbiANCgkJPiBNUExTIFRQIG5ldHdvcmsgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBnZXR0 aW5nIElQIHBhY2tldHMgZnJvbSANCgkJPiBkZXN0aW5hdGlvbiB0byBzb3VyY2U7IG5laXRoZXIg dGhlIG1pbnV0ZXMgbm9yIEkgc3RpcHVsYXRlIHRoYXQgYSANCgkJPiBjb250cm9sIHBsYW5lIG5l ZWRzIHRvIGJlIHVzZWQgdG8gaW5zdGFudGlhdGUgdGhpcyBmb3J3YXJkaW5nLg0KCQk+IA0KCQk+ IEFzIGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgcmV0dXJuIHBhdGggZm9yIHVuaWRpcmVjdGlvbmFs IExTUHMgY291bGQgYmUNCgkJDQoJCT4gY2hhcmF0ZXJpemVkIGFzIHRoZSBlbGVwaGFudCBpbiB0 aGUgcm9vbS4gIEluIHRoZSBNUExTIFRQIE9BTSANCgkJPiBGcmFtZXdvcmsgSS1ELCB1bmljYXN0 IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRpbWVzIGFuZCByZXR1cm4gDQoJCT4gcGF0 aHMgbm90IGF0IGFsbC4NCgkJPiANCgkJPiBUaGFua3MsDQoJCT4gDQoJCT4gSm9obg0KCQk+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJPiA+IEZyb206IEJVU0kgSVRBTE8gW21haWx0 bzpJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0XQ0KCQk+ID4gU2VudDogRnJpZGF5LCBBcHJp bCAxNywgMjAwOSAxOjU5IEFNDQoJCT4gPiBUbzogRHJha2UsIEpvaG4gRTsgQWxleGFuZGVyIFZh aW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KCQk+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJ PiA+IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoIA0KCQk+ID4gcmVxdWlyZW1lbnRzDQoJCT4gPiANCgkJPiA+IEpvaG4sDQoJCT4g PiANCgkJPiA+IEkgbWlnaHQgaGF2ZSBtaXNzZWQgdGhlIGFncmVlbWVudCBvZiBNUExTLVRQIGJl aW5nIGNhcGFibGUgb2YgDQoJCT4gPiBzZW5kaW5nIHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNl bnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMuDQoJCT4gPiANCgkJPiA+IFRoaXMgcmVxdWlyZW1l bnQgZG9lcyBub3QgYmVsb25nIHRvIHRoZSBmaXJzdCBzZXQgb2YgcmVxdWlyZW1lbnRzIA0KCQk+ ID4gSVRVLVQgaXMgZXhwZWN0aW5nIHRvIGJlIG1ldCBieSBPY3RvYmVyLg0KCQk+ID4gDQoJCT4g PiBIb3dldmVyLCBJIHRoaW5rIHRoaXMgaW4gYSBwb3RlbnRpYWwgaW50ZXJlc3RpbmcgYWRkaXRp b25hbCANCgkJPiA+IHJlcXVpcmVtZW50IHRvIGJlIHRha2VuIGludG8gYWNjb3VudCAoYXQgd29y c3QgaW4gYQ0KCQk+IHN1YnNlcXVlbnQgcGhhc2UpLg0KCQk+ID4gDQoJCT4gPiBJIHRoaW5rIHRo YXQgdGhpcyByZXF1aXJlbWVudCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVyc3VzIG90aGVyIA0K CQk+ID4gbW9yZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJpbGl0eSB0 byB3b3JrIHcvbyBJUCANCgkJPiA+IGZvcndhcmRpbmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8g Y29udGludWUgdG8gbW9uaXRvciB0aGUgZGF0YSANCgkJPiA+IHBsYW5lIGFsc28gaW4gY2FzZSBv ZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wgb3IgbWFuYWdlbWVudCANCgkJPiA+IHBs YW5lKS4NCgkJPiA+IA0KCQk+ID4gSSBhbSBvcGVuIHRvIGRpc2N1c3MgaXQgYnV0IG5vdCBzdXJl IHRoaXMgaXMgdGhlIHJpZ2h0IHRpbWUgYmVjYXVzZSANCgkJPiA+IEkgd2lzaCB0byBhdm9pZCBk ZWxheWluZyB0aGUgZmlyc3QgcGhhc2Ugb2YgdGhlIGRlc2lnbiBzb2x1dGlvbi4NCgkJPiA+IA0K CQk+ID4gVGhhbmtzLCBJdGFsbw0KCQk+ID4gDQoJCT4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQoJCT4gPiA+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KCQk+ID4gPiBb bWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERyYWtlLCBKb2hu IEUNCgkJPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDg6MDAgUE0NCgkJPiA+ ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCgkJPiA+ID4gQ2M6 IG1wbHMtdHBAaWV0Zi5vcmcNCgkJPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQoJCT4gPiA+IHJlcXVpcmVtZW50cw0K CQk+ID4gPiANCgkJPiA+ID4gQXQgdGhlIG1lZXRpbmcgbGFzdCBmYWxsIGF0IEp1bmlwZXIgaW4g TWFzc2FjaHVzZXR0cywgSQ0KCQk+ID4gdGhpbmsgaXQgd2FzDQoJCT4gPiA+IGFncmVlZCB0aGF0 IGFuIE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBoYXZlIGEgZm9yd2FyZGluZw0KCQk+ID4gY2Fw YWJpbGl0eQ0KCQk+ID4gPiBmb3IgbWFuYWdlbWVudCwgY29udHJvbCwgYW5kIE9BTSBwYWNrZXRz IChlLmcuLCBzZW5kaW5nDQoJCT4gPiByZXBsaWVzIHRvIE9BTQ0KCQk+ID4gPiByZXF1ZXN0cyBz ZW50IG9uIHVuaS1kaXJlY3Rpb25hbCBMU1BzKSBldmVuIGlmIGl0IGRvZXMgbm90DQoJCT4gPiBo YXZlIGFuIElQDQoJCT4gPiA+IGZvcndhcmRpbmcgZGF0YSBwbGFuZS4NCgkJPiA+ID4gDQoJCT4g PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJPiA+ID4gPiBGcm9tOiBBbGV4YW5k ZXIgVmFpbnNodGVpbg0KCQk+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tXQ0KCQk+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA5OjU3IEFN DQoJCT4gPiA+ID4gVG86IE1hYXJ0ZW4gVmlzc2Vycw0KCQk+ID4gPiA+IENjOiBtcGxzLXRwQGll dGYub3JnDQoJCT4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQoJCT4gPiA+ID4gcmVxdWlyZW1lbnRzDQoJCT4gPiA+ ID4gDQoJCT4gPiA+ID4gTWFhcnRlbiwNCgkJPiA+ID4gPiBJdCBzZWVtcyB0aGF0IHlvdSd2ZSBq dXN0IChpbXBsaWNpdGx5IGFuZCwgcHJvYmFibHksDQoJCT4gPiA+ID4gaW5hZHZlcnRlbnRseSkg c3RhdGVkIHRoZSBmb2xsb3dpbmc6DQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gICAgICAgICAgICAg ICAgICBNUExTLVRQIE9BTSB3aWxsIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0 aW9uDQoJCT4gPiAoYW5kIGZhdWx0DQoJCT4gPiA+ID4gbG9jYWxpemF0aW9uIHdoaWNoIHJlcXVp cmVzIHRoaXMgZnVuY3Rpb24gKSBmb3INCgkJPiA+IHVuaWRpcmVjdGlvbmFsIFAyTVANCgkJPiA+ ID4gPiBhbmQgUDJQIHBhdGhzLg0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IElmIHRoaXMgc3RhdGVt ZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8gYW5kIEZXSVcpDQoJCT4gcmFpc2VzIGEgdmFsaWQN CgkJPiA+ID4gPiBxdWVzdGlvbjoNCgkJPiA+ID4gPiANCgkJPiA+ID4gPiAgICAgICAgICAgICAg ICAgIElzIE1QTFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIHRoZXNlDQoJCT4gdHlw ZXMgb2YgdHJhbnNwb3J0DQoJCT4gPiA+ID4gcGF0aHM/DQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4g Rm9yIHRoZSByZWZlcmVuY2UsIElQL01QTFMgcHJvdmlkZXMgdGhpcyBraW5kIG9mDQoJCT4gPiBm dW5jdGlvbmFsaXR5IHRvZGF5DQoJCT4gPiA+ID4gZm9yICh1bmlkaXJlY3Rpb25hbCAtIGJ1dCBp dCBkb2VzIG5vdCBrbm93IGFueSBvdGhlcg0KCQk+ID4gdHlwZSkgUDJQIExTUHMNCgkJPiA+ID4g PiBhcyBkZXNjcmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0ZW5zaW9uIHRvIFAyTVAgTFNQ cyBzZWVtcyANCgkJPiA+ID4gPiBlYXN5Li4uDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gIA0KCQk+ ID4gPiA+IA0KCQk+ID4gPiA+IFJlZ2FyZHMsDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gICAgICBT YXNoYQ0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgkJPiA+ID4gPiBGcm9tOiBtcGxz LXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10NCgkJPiA+IE9u IEJlaGFsZg0KCQk+ID4gPiA+IE9mIE1hYXJ0ZW4gVmlzc2VycyBbbWFhcnRlbi52aXNzZXJzQGh1 YXdlaS5jb21dDQoJCT4gPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDM6MjQg UE0NCgkJPiA+ID4gPiBUbzogJ0FkcmlhbiBGYXJyZWwnDQoJCT4gPiA+ID4gQ2M6IG1wbHMtdHBA aWV0Zi5vcmcNCgkJPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgkJPiA+ID4gPiByZXF1aXJlbWVudHMNCgkJPiA+ ID4gPiANCgkJPiA+ID4gPiBBZHJpYW4sDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gPj4gPHF1b3Rl Pg0KCQk+ID4gPiA+ID4+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1F UHMsIE1JUHMgYW5kDQoJCT4gPiA+ID4gb3RoZXIgaW50ZXJuYWwNCgkJPiA+ID4gPiA+PiAgICAg ICBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkDQoJCT4gPiA+ID4gYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQNCgkJPiA+ID4gPiA+PiAgICAgICBwYXRoIGF0IGVhY2ggKHN1 Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KCQk+ID4gPiA+ID4+ICAgICAg IHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkDQoJCT4gPiA+ID4g ZGlyZWN0aW9ucyBvZiB0aGF0DQoJCT4gPiA+ID4gPj4gICAgICAgdHJhbnNwb3J0IHBhdGguDQoJ CT4gPiA+ID4gPj4gPGVuZCBxdW90ZT4NCgkJPiA+ID4gPiA+DQoJCT4gPiA+ID4gPiBUaGVyZSBp cyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCgkJPiA+ID4g aXMsIHRoZXJlIGlzDQoJCT4gPiA+ID4gPiAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQg ZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZg0KCQk+ID4gPiB2aWV3IHRoYXQNCgkJPiA+ID4gPiA+ IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVtZW50Lg0KCQk+ID4gPiA+IA0K CQk+ID4gPiA+IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gSXQgaXMgdmVyeSBt dWNoDQoJCT4gb2JzZXJ2YWJsZSBpZg0KCQk+ID4gPiA+IHRoaXMgcmVxdWlyZW1lbnQgaXMgbWV0 IGZyb20gYSBibGFjayBib3ggcG9pbnQgb2Ygdmlldy4NCgkJPiA+ID4gPiBUaGUgTUlQIGZ1bmN0 aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBMb29wYmFjayB3aGVuIHRoZXJlIGlzIGEgDQoJCT4g PiA+ID4gY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoZSBNUExTLVRQ IExCTSBwYWNrZXQgDQoJCT4gPiA+ID4gcmVjZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUgcmV0 dXJuZWQgKGFzIExCUg0KCQk+ID4gPiA+IHBhY2tldCkgdG8gdGhlIG9yaWdpbmF0aW5nIE1FUCBm dW5jdGlvbiB2aWEgdGhlIG90aGVyDQoJCT4gPiBkaXJlY3Rpb24gb2YNCgkJPiA+ID4gPiB0aGUg Y28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoaXMgb3RoZXINCgkJPiBk aXJlY3Rpb24NCgkJPiA+ID4gPiB3b3VsZCBub3QgYmUgYXZhaWxhYmxlIGluIGFuIGFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgDQoJCT4gPiA+ID4gcGF0aC4uLiBhbmQgdGh1cyB0 aGUgbG9vcGJhY2sgdGVzdA0KCQk+ID4gPiB3b3VsZCBmYWlsLg0KCQk+ID4gPiA+IA0KCQk+ID4g PiA+IFNpbWlsYXJseSwgd2hlbiB3ZSBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1vbml0b3Ig YQ0KCQk+ID4gc2VnbWVudCwgdGhlbg0KCQk+ID4gPiA+IHRoaXMgaXMgcG9zc2libGUgaW4gYSBj by1yb3V0ZWQgYmlkaXIgdHJhbnNwb3J0IHBhdGgNCgkJPiBidXQgbm90IGluIGENCgkJPiA+ID4g PiBhc3NvY2lhdGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoLiBJbiB0aGUgZmlyc3QgY2FzZSB0aGUg VENNIE1FUCANCgkJPiA+ID4gPiBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zIGFyZSBjby1sb2Nh dGVkIGFuZCBjYW4NCgkJPiBleGNoYW5nZSB3aGF0IGlzDQoJCT4gPiA+ID4gY2FsbGVkICJyZW1v dGUgaW5mb3JtYXRpb24iIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgcGVyZm9ybWFuY2UgDQoJCT4g PiA+ID4gbW9uaXRvcmluZy4NCgkJPiA+ID4gPiBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBN RVAgU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucw0KCQk+ID4gYXJlIGluIGUuZy4gDQoJCT4gPiA+ ID4gZGlmZmVyZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIGFuZCBUQ00gd291bGQgbm90IGJlIGFi bGUNCgkJPiA+IHRvIHByb3ZpZGUNCgkJPiA+ID4gPiBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLg0K CQk+ID4gPiA+IA0KCQk+ID4gPiA+ID4gVGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRl eHQgIihpbmNsdWRpbmcgTUVQcywNCgkJPiA+ID4gTUlQcyBhbmQgb3RoZXINCgkJPiA+ID4gPiBp bnRlcm5hbA0KCQk+ID4gPiA+ID4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgc2hvdWxkIGJl IGRlbGV0ZWQuIEl0IGRvZXMgbm90DQoJCT4gPiA+ID4gYWRkIHRvICJUaGUNCgkJPiA+ID4gPiA+ IGludGVybWVkaWF0ZSBub2Rlcy4iDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gWW91ciB1bmRlcnN0 YW5kaW5nIGlzIG5vdCBjb3JyZWN0LiBUaGlzIHRleHQgbXVzdCBub3QgYmUNCgkJPiA+IGRlbGV0 ZWQgYXQNCgkJPiA+ID4gPiBhbGwuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gPiBBY3R1YWxseSwg SSBhbSBxdWl0ZSBmZWQgdXAgYWJvdXQgdGhpcyBwZXJzaXN0ZW50DQoJCT4gPiA+IGluc2lzdGVu Y2Ugb24gdGhlDQoJCT4gPiA+ID4gaW5jbHVzaW9uDQoJCT4gPiA+ID4gPiBvZiAiVGFuZGVtIENv bm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3aXRoaW4gdGhlIElUVS1UIG9mDQoJCT4gPiA+ID4g dGhpcyB0ZXJtDQoJCT4gPiA+ID4gPiBpcw0KCQk+ID4gPiA+IHBvb3JseQ0KCQk+ID4gPiA+ID4g c3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZSBtb25pdG9yaW5nIG9mIGEgcGF0aCB0aGF0IGlz DQoJCT4gPiA+ID4gcGFyYWxsZWwgKGkuZS4NCgkJPiA+ID4gPiB0YW5kZW0pDQoJCT4gPiA+ID4g PiB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRD DQoJCT4gPiA+ID4gc2VlbXMgdG8gYmUgYXQNCgkJPiA+ID4gPiB2YXJpYW5jZSwNCgkJPiA+ID4g PiA+IGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KCQk+ID4g PiA+IA0KCQk+ID4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGVyZSB5b3VyIGludGVycHJldGF0 aW9uIG9mIHRhbmRlbQ0KCQk+ID4gY29ubmVjdGlvbiBpcw0KCQk+ID4gPiA+IGRlc2NyaWJlZCBp biBJVFUtVCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gImZyb20gdGhlDQoJCT4gPiBtb25pdG9yaW5n IG9mIGENCgkJPiA+ID4gPiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0 aGUgZGF0YSBwYXRoIGJlaW5nIA0KCQk+ID4gPiA+IG1vbml0b3JlZC4iPw0KCQk+ID4gPiA+IA0K CQk+ID4gPiA+IFRoZXJlIGlzIGEgIm5ldHdvcmsgY29ubmVjdGlvbiIgYW5kIHRoaXMgbmV0d29y aw0KCQk+ID4gY29ubmVjdGlvbiBpcyBhIHNldA0KCQk+ID4gPiA+IG9mIGludGVyY29ubmVjdGVk ICJsaW5rIGNvbm5lY3Rpb25zIiBhbmQgIm1hdHJpeA0KCQk+IGNvbm5lY3Rpb25zIi4gQQ0KCQk+ ID4gPiA+IHN1YnNldCBvZiB0aG9zZSBpbnRlcmNvbm5lY3RlZCBsaW5rIGNvbm5lY3Rpb25zIGFu ZCBtYXRyaXggDQoJCT4gPiA+ID4gY29ubmVjdGlvbnMgY2FuIGJlIG1vbml0b3JlZCBhbmQgaXMg dGhlbiByZWZlcnJlZCB0byBhcw0KCQk+IGEgInRhbmRlbQ0KCQk+ID4gPiA+IGNvbm5lY3Rpb24i LiBUaGVyZSBpcyBubyAicGF0aCB0aGF0IGlzIHBhcmFsbGVsIHRvIHRoZQ0KCQk+ID4gZGF0YSBw YXRoIi4gDQoJCT4gPiA+ID4gVGhlcmUgaXMgb25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBp bnNpZGUgdGhlIGRhdGENCgkJPiBwYXRoIGJ5IHRoZQ0KCQk+ID4gPiA+IFRDTSBNRVBfU28gZnVu Y3Rpb24gYW5kIHRoaXMgT0FNIGlzIGV4dHJhY3RlZCBmcm9tIHRoZQ0KCQk+ID4gZGF0YSBwYXRo IGJ5DQoJCT4gPiA+ID4gdGhlIFRDTSBNRVBfU2sgZnVuY3Rpb24uDQoJCT4gPiA+ID4gDQoJCT4g PiA+ID4gUmVnYXJkcywNCgkJPiA+ID4gPiBNYWFydGVuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4g DQoJCT4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJPiA+ID4gPiBGcm9tOiBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCgkJPiA+ID4gPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCgkJPiA+ID4gPiBTZW50OiBk b25kZXJkYWcgMTYgYXByaWwgMjAwOSAxMTo1OQ0KCQk+ID4gPiA+IFRvOiBBbGV4YW5kZXIgVmFp bnNodGVpbjsgYmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20NCgkJPiA+ID4gPiBDYzogQlVT SSBJVEFMTzsgbXBscy10cEBpZXRmLm9yZw0KCQk+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCQk+ID4gPiA+IHJl cXVpcmVtZW50cw0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IEhpIFNhc2hhLA0KCQk+ID4gPiA+IA0K CQk+ID4gPiA+ID4gVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIg c3RhdGVtZW50Og0KCQk+ID4gPiA+ID4NCgkJPiA+ID4gPiA+IDxxdW90ZT4NCgkJPiA+ID4gPiA+ ICAgICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQNCgkJPiA+ ID4gYmlkaXJlY3Rpb25hbCBMU1BzDQoJCT4gPiA+ID4gPiAgICAgYXJlIGEgc3BlY2lhbCBjYXNl IG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KCQk+ID4gPiA+ID4gPGVuZCBxdW90 ZT4NCgkJPiA+ID4gPiA+DQoJCT4gPiA+ID4gPiBUaGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZp b3VzbHkgY29ycmVjdCwgd2VyZSBpdCBub3QgZm9yDQoJCT4gPiA+ID4gUmVxdWlyZW1lbnQNCgkJ PiA+ID4gPiA+IDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQNCgkJ PiA+ID4gPiANCgkJPiA+ID4gPiBPSy4gR290IGl0Lg0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IEJ1 dCB3aGF0IGlzIHRoaXMgZG9pbmcgaW4gdGhlIGRhdGEgcGxhbmUgcmVxdWlyZW1lbnRzIHNlY3Rp b24/DQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gSW4gZmFjdCwgd2hhdCBpcyB0aGlzIHJlcXVpcmVt ZW50IGFjdHVhbGx5IHNheWluZz8NCgkJPiA+ID4gPiANCgkJPiA+ID4gPiA+IDxxdW90ZT4NCgkJ PiA+ID4gPiA+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1J UHMgYW5kDQoJCT4gPiA+IG90aGVyIGludGVybmFsDQoJCT4gPiA+ID4gPiAgICAgICBmdW5jdGlv bnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkDQoJCT4gPiA+ID4gYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQNCgkJPiA+ID4gPiA+ICAgICAgIHBhdGggYXQgZWFjaCAoc3ViLSlsYXllciBN VVNUIGJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nDQoJCT4gPiA+ID4gPiAgICAgICByZWxhdGlvbnNo aXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KCQk+ID4gPiA+IGRpcmVjdGlvbnMg b2YgdGhhdA0KCQk+ID4gPiA+ID4gICAgICAgdHJhbnNwb3J0IHBhdGguDQoJCT4gPiA+ID4gPiA8 ZW5kIHF1b3RlPg0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlz IGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdA0KCQk+ID4gaXMsIHRoZXJlIGlzDQoJCT4g PiA+ID4gKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9p bnQgb2YNCgkJPiA+IHZpZXcgdGhhdA0KCQk+ID4gPiA+IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0 byB0aGlzIHJlcXVpcmVtZW50Lg0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IFRoZXJlZm9yZSBpdCBj b3VsZCBiZSBhc3N1bWVkIHRoYXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgYnkgDQoJCT4gPiA+ ID4gY29uZmlndXJpbmcgc29tZSBkYXRhIHBsYW5lIGRhdGFiYXNlIGNvbXBvbmVudCB0aHJvdWdo IHRoZSANCgkJPiA+ID4gPiBtYW5hZ2VtZW50IHBsYW5lLiBUaGUgZGF0YWJhc2UgY29tcG9uZW50 IGlzIG5vdCB1c2VkDQoJCT4gZm9yIGFueXRoaW5nDQoJCT4gPiA+ID4gZXhjZXB0IHRvIHNhdGlz ZnkgdGhpcyByZXF1aXJlbWVudCBmb3IgImF3YXJlbmVzcyIuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ ID4gQmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdyaXRlIHRoaXMgcmVxdWlyZW1lbnQgaW4g dGVybXMgb2YgDQoJCT4gPiA+ID4gYmVoYXZpb3I/DQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gPiBQ bGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0gaW4gdGhlDQoJ CT4gPiA+ID4gbGlzdCB0aGF0IGlzDQoJCT4gPiA+ID4gPiBzcGVjaWZpYyBmb3IgY28tcm91dGVk IGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBwYWlyaW5nDQoJCT4gPiA+ID4gcmVxdWlyZW1lbnRz DQoJCT4gPiA+ID4gPiBhdCBlbmQgcG9pbnRzIGZvciBjby1yb3V0ZWQgYW5kIGFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbA0KCQk+ID4gPiBwYXRocyBhcmUNCgkJPiA+ID4gPiA+IGV4YWN0bHkgdGhl IHNhbWUgZXZlbiBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50DQoJCT4gPiA+IGl0ZW1z IGluIHRoZQ0KCQk+ID4gPiA+ID4gcmVxdWlyZW1lbnRzJyBsaXN0KS4NCgkJPiA+ID4gPiA+IElu IG90aGVyIHdvcmRzLCB3aXRob3V0IFJlcXVpcmVtZW50IDM0IHRoZSBub3Rpb24gb2YNCgkJPiBj by1yb3V0ZWQNCgkJPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBv ZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50Lg0KCQk+ID4gPiA+ID4NCgkJPiA+ID4gPiA+IFRoZSBz b21ld2hhdCB2YWd1ZSBzY29wZSBvZiB0aGlzIHJlcXVpcmVtZW50ICgib3RoZXIgaW50ZXJuYWwg DQoJCT4gPiA+ID4gPiBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUiKSBjcmVhdGVzIGEgc3VzcGlj aW9uIHRoYXQgSFcNCgkJPiA+ID4gPiBzdXBwb3J0IG9mIHRoZQ0KCQk+ID4gPiA+ID4gcGFpcmlu ZyBhd2FyZW5lc3MgbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRvIGNvbXBseSB3aXRoIGl0Lg0K CQk+ID4gPiA+IA0KCQk+ID4gPiA+IFRoZSBlbnRpcmV0eSBvZiB0aGUgYnJhY2tldHRlZCB0ZXh0 ICIoaW5jbHVkaW5nIE1FUHMsDQoJCT4gPiBNSVBzIGFuZCBvdGhlcg0KCQk+ID4gPiA+IGludGVy bmFsIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkiIHNob3VsZCBiZSBkZWxldGVkLiBJdA0KCQk+ ID4gZG9lcyBub3QNCgkJPiA+ID4gPiBhZGQgdG8gIlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIg0K CQk+ID4gPiA+IA0KCQk+ID4gPiA+ID4gVGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFmdCBp bmNyZWFzZXMgdGhpcyBzdXNwaWNpb246DQoJCT4gPiA+ID4gPg0KCQk+ID4gPiA+ID4gPHF1b3Rl Pg0KCQk+ID4gPiA+ID4gICBUYW5kZW0gQ29ubmVjdGlvbjogQSB0YW5kZW0gY29ubmVjdGlvbiBp cyBhbg0KCQk+ID4gYXJiaXRyYXJ5IHBhcnQgb2YgYQ0KCQk+ID4gPiA+ID4gICB0cmFuc3BvcnQg cGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pDQoJCT4gPiA+ID4gaW5kZXBlbmRl bnRseSBmcm9tIHRoZQ0KCQk+ID4gPiA+ID4gICBlbmQtdG8tZW5kIG1vbml0b3JpbmcgKE9BTSku ICBJdCBtYXkgYmUgYSBtb25pdG9yZWQNCgkJPiA+IHNlZ21lbnQgb3IgYQ0KCQk+ID4gPiA+ID4g ICBtb25pdG9yZWQgY29uY2F0ZW5hdGVkIHNlZ21lbnQgb2YgYSB0cmFuc3BvcnQgcGF0aC4gIA0K CQk+ID4gVGhlIHRhbmRlbQ0KCQk+ID4gPiA+ID4gICBjb25uZWN0aW9uIG1heSBhbHNvIGluY2x1 ZGUgdGhlIGZvcndhcmRpbmcgZW5naW5lKHMpIG9mDQoJCT4gPiA+ID4gdGhlIG5vZGUocykNCgkJ PiA+ID4gPiA+ICAgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVk IHNlZ21lbnQuDQoJCT4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+ IEFjdHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQNCgkJPiA+ IGluc2lzdGVuY2Ugb24gdGhlDQoJCT4gPiA+ID4gaW5jbHVzaW9uIG9mICJUYW5kZW0gQ29ubmVj dGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbg0KCQk+ID4gdGhlIElUVS1UIG9mDQoJCT4gPiA+ ID4gdGhpcyB0ZXJtIGlzIHBvb3JseSBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlDQoJCT4g bW9uaXRvcmluZyBvZiBhDQoJCT4gPiA+ID4gcGF0aCB0aGF0IGlzIHBhcmFsbGVsIChpLmUuIHRh bmRlbSkgdG8gdGhlIGRhdGEgcGF0aCBiZWluZyANCgkJPiA+ID4gPiBtb25pdG9yZWQuIFRoaXMg ZGVmaW5pdGlvbiBvZiBUQyBzZWVtcyB0byBiZSBhdCB2YXJpYW5jZSwNCgkJPiA+IGFuZCB3b3Vs ZA0KCQk+ID4gPiA+IGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQoJCT4gPiA+ ID4gDQoJCT4gPiA+ID4gPiBEb2Vzbid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgc291bmQgbGlrZSBo YXJkd2FyZSB0byB5b3U/DQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gWWVzLCBidXQgc28gd2hhdD8N CgkJPiA+ID4gPiANCgkJPiA+ID4gPiA+IElNSE8gaXQgaXMgd29ydGggbm90aW5nIHRoYXQgbmVp dGhlciB0aGUgTVBMUy1UUA0KCQk+ID4gPiBSZXF1aXJlbWVudHMgZHJhZnQNCgkJPiA+ID4gPiA+ IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZQ0KCQk+ID4gPiA+ID4gDQoJCT4g PiA+ID4gDQoJCT4gPiA+IA0KCQk+ID4gDQoJCT4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVxdWlyZW1lbg0KCQk+ID4gPiA+ID4g dHMtMDEudHh0KSBjb250YWluIGFueSByZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoIHRhbmRlbQ0K CQk+ID4gPiBjb25uZWN0aW9ucy4NCgkJPiA+ID4gPiA+DQoJCT4gPiA+ID4gPiBCdXQgdGFuZGVt IGNvbm5lY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNDQoJCT4gPiBGcmFt ZXdvcmsNCgkJPiA+ID4gPiA+IGRyYWZ0DQoJCT4gPiA+ID4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tZnINCgkJPiA+ID4gPiBhbWV3 b3JrLTAwLnR4dA0KCQk+ID4gPiA+ICkuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gUmlnaHQuDQoJ CT4gPiA+ID4gTGV0J3MganVzdCBnZXQgcmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJy aW5nIGFsbA0KCQk+IHRoZSBJLURzDQoJCT4gPiA+ID4gaW50byBsaW5lLg0KCQk+ID4gPiA+IA0K CQk+ID4gPiA+ID4gVGhlIGJvdHRvbSBsaW5lLCBJTUhPLCBpcyB0aGF0IHNvbWUgY2xhcml0eSBy ZWdhcmRpbmcNCgkJPiA+ID4gY28tcm91dGVkIHZzLg0KCQk+ID4gPiA+ID4gYXNzb2NpYXRlZA0K CQk+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdh eSB0byBwcm92aWRlDQoJCT4gPiA+ID4gdGhhdCBjb3VsZA0KCQk+ID4gPiA+ID4gYmUgYnkgZXhw bGljaXRseSBsaW1pdGluZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYw0KCQk+ID4gPiBmdW5j dGlvbmFsaXR5Lg0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IEFncmVlZC4NCgkJPiA+ID4gPiANCgkJ PiA+ID4gPiBBZHJpYW4NCgkJPiA+ID4gPiANCgkJPiA+ID4gPiANCgkJPiA+ID4gPiANCgkJPiA+ ID4gPiANCgkJPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoJCT4gPiA+ID4gRnJvbTogQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a10NCgkJ PiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMTI6MTMgQU0NCgkJPiA+ID4g PiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IExvdSBCZXJnZXI7IEJVU0kgSVRBTE8NCgkJPiA+ ID4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KCQk+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCQk+ID4gPiA+IHJl cXVpcmVtZW50cw0KCQk+ID4gPiA+IA0KCQk+ID4gPiA+IEhpIFNhc2hhLA0KCQk+ID4gPiA+IA0K CQk+ID4gPiA+IE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5n IGFueW9uZSwgYnV0Li4uDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gPiAxLiBNeSByZWFkaW5nIG9m ICBvbmUgb2YgQmVuJ3MgIG1lc3NhZ2VzIGlzIHRoYXQgYXNzb2NpYXRlZCANCgkJPiA+ID4gPiA+ IGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBvbmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQgY2Fu IGJlDQoJCT4gPiA+ID4gY3JlYXRlZCBpbg0KCQk+ID4gPiA+ID4gdGhlIGV4aXN0aW5nIG5ldHdv cmtzOyAidHJ1ZSIgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMNCgkJPiA+ID4gPiB3aWxs IGhhdmUNCgkJPiA+ID4gPiA+IHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQg YmVjb21lcyBhdmFpbGFibGUuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gVGhpcyBpcyBjbGVhcmx5 IG5vbnNlbnNlIQ0KCQk+ID4gPiA+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUs IGNvLXJvdXRlZA0KCQk+ID4gYmlkaXJlY3Rpb25hbCBMU1BzIGFyZQ0KCQk+ID4gPiA+IGEgc3Bl Y2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KCQk+ID4gPiA+IA0K CQk+ID4gPiA+IElmIHlvdSBjYW4gc2V0IHVwIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzIChlLmcu IHVzaW5nIHRoZQ0KCQk+ID4gbWFuYWdlbWVudA0KCQk+ID4gPiA+IHBsYW5lKSB5b3UgY2FuIHN1 cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQNCgkJPiA+ID4gYmlkaXJlY3Rpb25hbCBMU1AuDQoJCT4g PiA+ID4gDQoJCT4gPiA+ID4gVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGll dmUgY28tcm91dGVkDQoJCT4gYmlkaXJlY3Rpb25hbA0KCQk+ID4gPiA+IExTUHMgdXNpbmcgdGhl IGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVpdGhlciB1c2UgdGhlIEdNUExTDQoJCT4gPiAod2hpY2gg aXMNCgkJPiA+ID4gPiBjbGVhbmVyKSBvciBub24tc3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRp b25zICh3aGljaCBpcw0KCQk+ID4gbWVzc3kgYnV0DQoJCT4gPiA+ID4gZnVuY3Rpb25hbCkuDQoJ CT4gPiA+ID4gDQoJCT4gPiA+ID4gQnV0IChvZiBjb3Vyc2UpIHRoZSBtYW5hZ2VtZW50IHBsYW5l IG9yIGNvbnRyb2wgcGxhbmUNCgkJPiA+IHNvbHV0aW9ucyBoYXZlDQoJCT4gPiA+ID4gbm90aGlu ZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMgdGhleQ0KCQk+IGFyZSBz b2Z0d2FyZQ0KCQk+ID4gPiA+IHNvbHV0aW9ucy4NCgkJPiA+ID4gPiANCgkJPiA+ID4gPiA+IDIu IE15IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWwN CgkJPiA+ID4gPiBkcml2ZXIgZm9yDQoJCT4gPiA+ID4gPiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIA0KCQk+ID4gPiA+ID4gdHJh bnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFuIGFueSBzcGVjaWZpYyBiZW5lZml0Lg0KCQk+ID4g PiA+IA0KCQk+ID4gPiA+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMt VFAgcmVxdWlyZW1lbnRzPw0KCQk+ID4gPiA+IFdoaWNoIGlzIG5vdCB0byBzYXkgaXQgaXMgYSBi YWQgdGhpbmcuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMt VFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsNCgkJPiA+IHRoZSBsb29rLA0KCQk+ID4g PiA+IGZlZWwsIGFuZCBiZWhhdmlvcmFsIGNoYXJhY3RlcmlzdGljcyBvZiBhICJsZWdhY3kiDQoJ CT4gPiA+ID4gdHJhbnNwb3J0IG5ldHdvcmsuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gPiBCYXNl ZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVzcyAoRldJVykgdGhhdDoNCgkJPiA+ID4g PiA+ICogYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSwgYXQgbGVhc3QgZm9yIHRo ZSB0aW1lDQoJCT4gPiA+ID4gPiAgICBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUgb2Yg YmlkaXJlY3Rpb25hbCBwYXRocyBpbg0KCQk+ID4gPiA+ID4gICAgTVBMUy1UUA0KCQk+ID4gPiA+ IA0KCQk+ID4gPiA+IEkgdGhpbmsgdGhhdCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVu dCBhYm92ZSwgYW5kDQoJCT4gPiBnaXZlbiB0aGF0DQoJCT4gPiA+ID4gb3RoZXIgdXBncmFkZXMg dG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZQ0KCQk+IG5lZWRlZCB0byByZWFjaA0K CQk+ID4gPiA+IHRoZSBmdWxsIGZ1bmN0aW9uIGxldmVsIG9mIE1QTFMtVFAuDQoJCT4gPiA+ID4g DQoJCT4gPiA+ID4gPiAqIHRoZXkgaGFkIGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5 IHR5cGUgb2YNCgkJPiA+IGJpZGlyZWN0aW9uYWwNCgkJPiA+ID4gPiA+ICAgcGF0aHMgaW4gIHJl YWwgZGVwbG95bWVudHMuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gSSBkb24ndCBzZWUgd2hhdCB0 aGF0IGZvbGxvd3MgZnJvbS4NCgkJPiA+ID4gPiANCgkJPiA+ID4gPiBDaGVlcnMsDQoJCT4gPiA+ ID4gQWRyaWFuDQoJCT4gPiA+ID4gDQoJCT4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCgkJPiA+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0K CQk+ID4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCgkJPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCgkJPiA+ID4gPiANCgkJPiA+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCQk+ID4gPiA+IG1wbHMt dHAgbWFpbGluZyBsaXN0DQoJCT4gPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KCQk+ID4gPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQk+ID4gPiA+IA0K CQk+ID4gPiA+IA0KCQk+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KCQk+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KCQk+ID4gPiBtcGxzLXRw QGlldGYub3JnDQoJCT4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscy10cA0KCQk+ID4gPiANCgkJPiA+IA0KCQk+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoJCT4gbXBscy10cCBtYWlsaW5nIGxpc3QNCgkJPiBtcGxz LXRwQGlldGYub3JnDQoJCT4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzLXRwDQoJCT4gDQoJCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoJCW1wbHMtdHAgbWFpbGluZyBsaXN0DQoJCW1wbHMtdHBAaWV0Zi5vcmcNCgkJaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoJCQ0KCQkNCg0KCQkt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K CQlaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byBvdGhlcnMuDQoJCVRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCgkJVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBz eXN0ZW0uDQoNCg== ------_=_NextPart_001_01C9C2A1.3F4C919A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1l cXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxN RVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PCEtLVtp ZiAhbXNvXT4NCjxTVFlMRT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9TVFlM RT4NCjwhW2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZSBuYW1lPSJQZXJzb25OYW1lIiANCm5hbWVz cGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48L286 U21hcnRUYWdUeXBlPjxvOlNtYXJ0VGFnVHlwZSANCm5hbWU9InBsYWNlIiANCm5hbWVzcGFjZXVy aT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48L286U21hcnRU YWdUeXBlPjxvOlNtYXJ0VGFnVHlwZSANCm5hbWU9IlN0YXRlIiANCm5hbWVzcGFjZXVyaT0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48L286U21hcnRUYWdUeXBl PjxvOlNtYXJ0VGFnVHlwZSANCm5hbWU9IkNpdHkiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PCEtLVtp ZiAhbXNvXT4NCjxTVFlMRT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9 DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+DQo8U1RZTEU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0 aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNvbWljIFNhbnMgTVMiOw0KCXBhbm9zZS0xOjMgMTUgNyAyIDMgMyAy IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjsNCglwYW5vc2Ut MTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQXJp YWwgVW5pY29kZSBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KIC8qIFN0 eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KcHJlDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQp0dA0KCXtm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOm5hdnk7 fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KIC8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0MDUzNDcxMjU7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2NjE1MDMw MjggLTMyOTQ5NTM0MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRleHQ6JTE7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgljb2xvcjptYXJvb247fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgbGFuZz1F Ti1VUyB2TGluaz1wdXJwbGUgbGluaz1ibHVlPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZP TlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+PFNQQU4gDQpjbGFz cz0yMzQwNDE4MTYtMjEwNDIwMDk+VGhhbmtzIElnb3IuLi4uYW4gZ3JlYXQgcXVlc3Rpb24uLi5t eSBjb21tZW50cyBhcmUgDQppbi1saW5lOjwvU1BBTj48L0ZPTlQ+PC9ESVY+PEJSPg0KPEJMT0NL UVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVw eDsgQk9SREVSLUxFRlQ6ICM4MDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQog IDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWdu PWxlZnQ+DQogIDxIUiB0YWJJbmRleD0tMT4NCiAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxC PkZyb206PC9CPiBJZ29yIEJyeXNraW4gDQogIFttYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwu Y29tXSA8QlI+PEI+U2VudDo8L0I+IDIxIEFwcmlsIDIwMDkgDQogIDE3OjEyPEJSPjxCPlRvOjwv Qj4gSGFycmlzb24sTixOZWlsLENYTSBSOyBsaXUuZ3VvbWFuQHp0ZS5jb20uY247IA0KICBkYnJ1 bmdhcmRAYXR0LmNvbTxCUj48Qj5DYzo8L0I+IG1wbHMtdHBAaWV0Zi5vcmc8QlI+PEI+U3ViamVj dDo8L0I+IFJFOiANCiAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCANCiAgcmVxdWlyZW1lbnRzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+PC9E SVY+DQogIDxESVYgY2xhc3M9U2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5OZWlsLDxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNp emU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQt RkFNSUxZOiBBcmlhbCI+UGxlYXNlIHNlZSBteSANCiAgcXVlc3Rpb24gaW4tbGluZS48bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5 OyBGT05ULUZBTUlMWTogQXJpYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFN SUxZOiBBcmlhbCI+SWdvcjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8RElWPg0KICA8RElWIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+PEZPTlQg DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPg0KICA8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpF PTM+DQogIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9O VCBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsg Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+ PC9CPjxGT05UIA0KICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+IA0KICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQiPk9uIEJlaGFsZiBPZiA8L1NQQU4+PC9CPjxzdDE6UGVyc29uTmFtZSAN CiAgdzpzdD0ib24iPm5laWwuMi5oYXJyaXNvbkBidC5jb208L3N0MTpQZXJzb25OYW1lPjxCUj48 Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+IFR1 ZXNkYXksIEFwcmlsIDIxLCAyMDA5IDg6MzEgDQogIEFNPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05U LVdFSUdIVDogYm9sZCI+VG86PC9TUEFOPjwvQj4gbGl1Lmd1b21hbkB6dGUuY29tLmNuOyANCiAg ZGJydW5nYXJkQGF0dC5jb208QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5D Yzo8L1NQQU4+PC9CPiANCiAgPHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9uIj5tcGxzLXRwQGlldGYu b3JnPC9zdDE6UGVyc29uTmFtZT48QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDog Ym9sZCI+U3ViamVjdDo8L1NQQU4+PC9CPiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgDQogIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzPC9TUEFOPjwvRk9OVD48bzpw PjwvbzpwPjwvUD48L0RJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9bWFyb29uIHNpemU9Mj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG1hcm9vbjsgRk9OVC1GQU1JTFk6ICdDb21pYyBT YW5zIE1TJyI+TGl1LDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPW1h cm9vbiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBtYXJv b247IEZPTlQtRkFNSUxZOiAnQ29taWMgU2FucyBNUyciPklmIA0KICBNUExTLVRQIGlzIGdvaW5n IHRvIGJlIHRha2VuIHNlcmlvdXNseSBhcyBhIHRyYW5zcG9ydCBuZXR3b3JrIChsaWtlIFNESC9T T05FVCkgDQogIHRoZW4gdGhlIDImbmJzcDtrZXkgTVVTVCBIQVZFIHJlcXVpcmVtZW50cyBhcmUg DQogIHRoZXNlLjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPW1hcm9v biBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBtYXJvb247 IEZPTlQtRkFNSUxZOiAnQ29taWMgU2FucyBNUyciPjEmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFBy b3ZpZGUgYSB0cmFuc3BhcmVudCBjbGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcC4uLndoaWNoIA0K ICBtZWFuczo8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9bWFyb29uIHNpemU9Mj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG1hcm9vbjsgRk9OVC1GQU1JTFk6ICdD b21pYyBTYW5zIE1TJyI+LSZuYnNwOyZuYnNwOyZuYnNwOyANCiAgYWxsIGNsaWVudCBiaXRzIHRy ZWF0ZWQgZXF1YWxseTwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj1tYXJvb24gc2l6ZT0yPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbWFyb29uOyBGT05ULUZBTUlM WTogJ0NvbWljIFNhbnMgTVMnIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBjbGllbnQgYml0IG9y ZGVyaW5nIHByZXNlcnZlZDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj1tYXJvb24gc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbWFyb29uOyBGT05ULUZB TUlMWTogJ0NvbWljIFNhbnMgTVMnIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBubyBhdHRlbXB0 IHRvIGluZmVyIGNsaWVudCBzeW1ib2wgKGllIHNlcXVlbmNlIG9mIGNsaWVudCBiaXRzKSBtZWFu aW5nIGFuZCBubyANCiAgYXR0ZW1wdCB0byBjaGFuZ2UgY2xpZW50IHN5bWJvbHM8L1NQQU4+PC9G T05UPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ29t aWMgU2FucyBNUyIgY29sb3I9bWFyb29uIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG1hcm9vbjsgRk9OVC1GQU1JTFk6ICdDb21pYyBTYW5zIE1TJyI+LSZu YnNwOyZuYnNwOyZuYnNwOyANCiAgdGhlIHRyYWZmaWMgYmVoYXZpb3VyIG9mIGNsaWVudCBYIG11 c3Qgbm90IGltcGFjdCB0aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQgDQogIGJ5IGNsaWVudCBZ PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9bWFyb29uIHNpemU9Mj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG1hcm9vbjsgRk9OVC1GQU1J TFk6ICdDb21pYyBTYW5zIE1TJyI+QSBrZXkgDQogIGNvcm9sbGFyeSBvZiB0aGUgYWJvdmUgaXMg dGhhdCBNUExTLVRQIG11c3Qgb25seSBzdXBwb3J0IHByb3BlciBjb25uZWN0aW9ucyANCiAgKGll IHNpbmdsZSBzb3VyY2UgY29uc3RydWN0cyk8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86 cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHls ZT0iTUFSR0lOLUxFRlQ6IDAuNWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Rk9OVCANCiAgZmFjZT0iQ29taWMg U2FucyBNUyIgY29sb3I9bWFyb29uIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG1hcm9vbjsgRk9OVC1GQU1JTFk6ICdDb21pYyBTYW5zIE1TJyI+PFNQQU4g DQogIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj4yPEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPTE+PFNQQU4gDQogIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjwvRk9OVD48L1NQ QU4+PC9TUEFOPjwvRk9OVD48IVtlbmRpZl0+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgDQog IGNvbG9yPW1hcm9vbiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBtYXJvb247IEZPTlQtRkFNSUxZOiAnQ29taWMgU2FucyBNUyciPlNpbmNlIA0KICBNUExT LVRQIGlzIGEgdHJhbnNwb3J0IG5ldHdvcmsgaXQgaXMgbm90IGEgdG9wLW9mLXN0YWNrIG5ldHdv cmsgKGllIGl0IGRvZXMgDQogIG5vdCBzdXBwb3J0IGRpcmVjdGx5IGV4dGVybmFsIG1lc3NhZ2Uv ZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zKS4mbmJzcDsgTVBMUy1UUCANCiAgdGhlcmVmb3JlIGRv ZXMgbm90IHJlcXVpcmUgYW4gRS1OTkkgc3BlY2lmaWNhdGlvbi4mbmJzcDsgQSBrZXkgY29yb2xs YXJ5IG9mIA0KICB0aGlzIGlzIHRoYXQgTVBMUy1UUCB3aWxsIG5vdCBoYXZlIGFueSBwZWVyIGlu dGVyd29ya2luZyByZWxhdGlvbnNoaXAgd2l0aCBhbnkgDQogIG90aGVyIG5ldHdvcmsgbW9kZS90 ZWNobm9sb2d5LjwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgDQogIHNp emU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb21p YyBTYW5zIE1TJyI+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6ICdD b21pYyBTYW5zIE1TJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eT48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SUIm Z3Q7Jmd0OyBGcm9tIHdoYXQgDQogIHlvdSB3cm90ZSBhYm92ZSAod2hpY2ggSSBjb21wbGV0ZWx5 IGFncmVlIHdpdGgpPFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48Rk9OVCBmYWNl PSJDb21pYyBTYW5zIE1TIiANCiAgY29sb3I9IzgwMDAwMD4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbD48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+PFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48U1BBTiBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCANCiAgY29sb3I9IzAwMDAwMD48Rk9OVCANCiAgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1NQQU4+PC9TUEFO PjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFy aWFsIj48U1BBTiANCiAgY2xhc3M9MjM0MDQxODE2LTIxMDQyMDA5PjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEycHQiPjxGT05UIA0KICBjb2xvcj0jMDAwMDAwPjxGT05UIHNpemU9Mj48U1BBTiBj bGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiPk5I PSZndDsgVGhhbmtzLi4uLmFuZCB0aGlzIGlzIHZlcnkgaW1wb3J0YW50IGlmIHdlIGFyZSB0byAN CiAgYXZvaWQgZ2VuZXJhdGluZyBsb2FkcyBvZiB1bm5lY2Vzc2FyeSB3b3JrIGFuZCBjcmVhdGlu ZyBkb3duc3RyZWFtIA0KICBwcm9ibGVtcy9jb3N0cy4mbmJzcDsgSSBkbyBob3BlIG90aGVycyBj YW4gYWxzbyBzZWUgDQogIHRoaXMuPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48 L1NQQU4+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPW5hdnk+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4MTYtMjEw NDIwMDk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgDQogIGNvbG9yPSM4MDAw MDA+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48Rk9OVCANCiAg ZmFjZT0iQ29taWMgU2FucyBNUyI+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48 L1NQQU4+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPW5hdnk+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4 MTYtMjEwNDIwMDk+Jm5ic3A7PC9TUEFOPiBvbmUgY2FuIGRyYXcgYSBjb25jbHVzaW9uIHRoYXQg aXQgZG9lcyANCiAgbm90IG1ha2Ugc2Vuc2UgKG9yIG5vdCBwcmFjdGljYWwgdG8gc2F5IHRoZSBs ZWFzdCkgZm9yIGEgYmktZGlyZWN0aW9uYWwgDQogIE1QTFMtVFAgY29ubmVjdGlvbiAoY28tcm91 dGVkIG9yIG5vdCkgdG8gaGF2ZSBhc3ltbWV0cmljIChkaWZmZXJlbnQgZm9yIGVhY2ggDQogIGRp cmVjdGlvbikgYmFuZHdpZHRoIGFsbG9jYXRpb24uIERvIHlvdSBhZ3JlZSB3aXRoIHRoYXQ/Jm5i c3A7PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxGT05UIGNvbG9yPSM4MDAwMDA+PFNQ QU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRk9O VD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9bmF2eT48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5h dnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxG T05UIGNvbG9yPSM4MDAwMDA+PFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48L1NQ QU4+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJDb21pYyBT YW5zIE1TIj48U1BBTiBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PFNQQU4gDQogIGNsYXNzPTIz NDA0MTgxNi0yMTA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jMDAwMDAw Pk5IPSZndDsgSXQncyANCiAgaGFyZCB0byB1bmRlcnN0YW5kIHdoeSBhIHRyYW5zcG9ydCBuZXR3 b3JrIHdvdWxkIHJlcXVpcmUgYXN5bW1ldHJpYyANCiAgQlcuLi50aG91Z2ggY2xlYXJseSBzdWNo IGEgY29uc3RydWN0IGNvdWxkIGJlIA0KICBjcmVhdGVkLiZuYnNwOzwvRk9OVD48L1NQQU4+PC9T UEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5 OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIj48U1BB TiBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0 MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgY29sb3I9IzAwMDAwMD48L0ZPTlQ+ PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9OVCANCiAgZmFjZT0iQ29t aWMgU2FucyBNUyI+PFNQQU4gY2xhc3M9MjM0MDQxODE2LTIxMDQyMDA5PjxTUEFOIA0KICBjbGFz cz0yMzQwNDE4MTYtMjEwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzAw MDAwMD5CdXQgbGV0IHVzIA0KICBwYXVzZSBmb3IgYSBtb21lbnQgYW5kIGNvbnNpZGVyIHdoYXQg YSB0cmFuc3BvcnQgbmV0d29yayBtdXN0IGRvIGluIHRyeWluZyB0byANCiAgYW5zd2VyIHRoaXMg Z29vZCBxdWVzdGlvbi48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9O VCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyI+PFNQQU4gY2xhc3M9MjM0MDQxODE2LTIxMDQyMDA5 PjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2Fu cyBNUyIgDQogIGNvbG9yPSMwMDAwMDA+PC9GT05UPjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BB Tj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Bcmlh bD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFN SUxZOiBBcmlhbCI+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxTUEFOIGNsYXNzPTIz NDA0MTgxNi0yMTA0MjAwOT48U1BBTiANCiAgY2xhc3M9MjM0MDQxODE2LTIxMDQyMDA5PjxGT05U IGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwMDA+QXMgSSBub3RlZCANCiAgaW4gMSBh Ym92ZSwgYSBjcml0aWNhbCBiZWhhdmlvdXIgb2YgYSB0cmFuc3BvcnQgbmV0d29yayBpcyB0byBw cm92aWRlIGEgDQogIHRyYW5zcGFyZW50IGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwLi4uLmlu IGVzc2VuY2UgaXQgaXMgY3JlYXRpbmcgY2xpZW50IA0KICBuZXR3b3JrIHRvcG9sb2d5LiZuYnNw OzwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJD b21pYyBTYW5zIE1TIj48U1BBTiBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PFNQQU4gDQogIGNs YXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgY29s b3I9IzAwMDAwMD48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD4mbmJz cDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48 Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyI+PFNQQU4gY2xhc3M9MjM0MDQxODE2LTIxMDQy MDA5PjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMg U2FucyBNUyIgY29sb3I9IzAwMDAwMD5BbmQgYWx0aG91Z2ggDQogIEkgZGlkIG5vdCBlbGFib3Jh dGUgYWJvdmUgd2h5IHRoaXMgaXMgc28gaW1wb3J0YW50LCBvbmNlIHlvdSBzdGFydCB0byB0aGlu ayANCiAgYWJvdXQgd2hhdCBpdCB3b3VsZCBiZSBjYXJyeWluZyBpdCBpcyBsaWtlbHkgdG8gYmUg YSB2ZXJ5IGxhcmdlIGFnZ3JlZ2F0ZSBvZiANCiAgKHVsdGltYXRlLi4ubm90IG5lY2Vzc2FyaWx5 IGluIHRoZSBpbW1lZGlhdGUgY2xpZW50IG5ldHdvcmspIA0KICBtZXNzYWdlL2ZpbGUvc3RyZWFt IGFwcGxpY2F0aW9ucy4uLi5ub3RpbmcgdGhhdCB0aGUgc3BlY2lmaWMmbmJzcDttaXggb2YgDQog IG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zIGNhbiB2YXJ5IGVwb2NoIGJ5IGVwb2No LiAmbmJzcDsgSW5kZWVkIGl0IA0KICBtdXN0IGNhcnJ5IHN1Y2ggYW4gYWdncmVnYXRlLCBiZWNh dXNlIGFsbCBuZXR3b3JrcyBvbmx5IGhhdmUgcHVycG9zZSBpZiB0aGV5IA0KICBhcmUgdWx0aW1h dGVseSBzdXBwb3J0aW5nIGV4dGVybmFsICh0byB0aGUgbmV0d29ya3MpIG1lc3NhZ2UvZmlsZS9z dHJlYW0gDQogIGluZm9ybWF0aW9uIHRyYW5zZmVycy4uLnNvIHdoaWxzdCB0aGlzIHRyYW5zcG9y dCBuZXR3b3JrIGlzIG5vdCBhIHRvcC1vZi1zdGFjayANCiAgbmV0d29yayB0aGVyZSBtdXN0IGEg dG9wLW9mLXN0YWNrIG5ldHdvcmsgcHJlc2VudCZuYnNwOyhzb21ldGhpbmcgSSB0aGluayBzb21l IA0KICBwZW9wbGUgZmFpbCB0byBmdWxseSANCiAgYXBwcmVjaWF0ZSkuJm5ic3A7PC9GT05UPjwv U1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMg TVMiPjxTUEFOIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48U1BBTiANCiAgY2xhc3M9MjM0MDQx ODE2LTIxMDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIA0KICBjb2xvcj0jMDAwMDAw PjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBm YWNlPSJDb21pYyBTYW5zIE1TIj48U1BBTiBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PFNQQU4g DQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBj b2xvcj0jMDAwMDAwPk5vdyB3aGlsc3QgDQogIHRoZSBRb1MgKD09ZGVsYXkpIHJlcXVpcmVtZW50 cyBvZiBlaXRoZXIgbWVzc2FnZSwgZmlsZSBvZiBzdHJlYW0gYXBwbGljYXRpb25zIA0KICBpcyBs YXJnZWx5IGludmFyaWFudCB3aXRoaW4gZWFjaCBhcHBsaWNhdGlvbiB0eXBlLCB0aGUgc3Vydml2 YWJpbGl0eSANCiAgaW1wb3J0YW5jZSBjYW4gdGFrZSBvbiBhbnkgdmFsdWUgZm9yIGFueSBhcHBs aWNhdGlvbiB0eXBlLiZuYnNwOyBTbyANCiAgdHJhbnNwYXJlbmN5IChhcyBJIGRlZmluZWQgaXQg YWJvdmUpIGlzIHRoZXJmb3JlIG5vdCBtZXJlbHkgc29tZSBhYnN0cmFjdCANCiAgcmVxdWlyZW1l bnQgYnV0IGl0IGlzIHByYWN0aWNhbGx5IGVzc2VudGlhbCB0byBoYXZlIHRoaXMgYmVoYXZpb3Vy IHRvIG1ha2UgdGhlIA0KICB0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRpb25hbGx5IHRyYWN0YWJs ZSAoaWUgc2ltcGxlIG9mIHRyYW5zZmVyIA0KICBmdW5jdGlvbikuJm5ic3A7IE1vcmVvdmVyLCBh cyBhIHNlcnZlciBsYXllciB3ZSBjYW4gbWFrZSBubyBqdWRnZW1lbnQgb24gdGhlIA0KICBpbXBv cnRhbmNlIG9mIGEgc3BlY2lmaWMgYXBwbGljYXRpb24gdGhhdCBtYXkgYmUgc2VydmVyYWwgbGF5 ZXIgYWJvdmUgdXMgDQogIGFueXdheS4uLi4uZXJnbyB3ZSAqbXVzdCogaGF2ZSB0cmFuc3BhcmVu Y3kgYXMgYSBjcml0aWNhbCBiZWhhdmlvdXIgaW4gYSANCiAgdHJhbnNwb3J0IG5ldHdvcmsuPC9G T05UPjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQgDQogIGZhY2U9IkNvbWlj IFNhbnMgTVMiPjxTUEFOIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48U1BBTiANCiAgY2xhc3M9 MjM0MDQxODE2LTIxMDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIA0KICBjb2xvcj0j MDAwMDAwPjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPiZuYnNwOzwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05U IA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIj48U1BBTiBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+ PFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5z IE1TIiBjb2xvcj0jMDAwMDAwPk9mIGNvdXJzZSANCiAgdHJhbnNwYXJlbmN5IGlzIGEgZm9yY2Vk IGJlaGF2aW91ciBpbiB0aGUgY28tY3MgbW9kZSAoaWUgbm8gUW9TIG9yIA0KICBzdXJ2aXZhYmls aXR5IGltcG9ydGFuY2UgbWFya2luZ3MgaGVyZSksIGFuZCB0aGlzIChzaW1wbGljaXR5KSBpcyB3 aHkgdGhlIA0KICBjby1jcyBtb2RlIGhhcyBiZWVuIHNvIGVuZHVyaW5nbHkgc3VjY2Vzc2Z1bCBp biBhIHRyYW5zcG9ydCByb2xlLCBlZyBQREggYW5kIA0KICBTREguJm5ic3A7IFdoZW4gd2UgdXNl IGEgY28tcHMgbW9kZSB0byBwcm92aWRlIGEgdHJhbnNwb3J0IHJvbGUgd2UgbXVzdCBiZSANCiAg c3VyZSB3ZSBlbXVsYXRlIHRoaXMgdHJhbnNwYXJlbmN5IA0KICBiZWhhdmlvdXIuPC9GT05UPjwv U1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMg TVMiPjxTUEFOIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT48U1BBTiANCiAgY2xhc3M9MjM0MDQx ODE2LTIxMDQyMDA5PjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQg DQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwMDA+PFNQQU4gY2xhc3M9MjM0MDQx ODE2LTIxMDQyMDA5PjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+U29ycnkgSSBo YXZlIGxhYm9yZWQgdGhpcyBwb2ludCBvbiB0cmFuc3BhcmVuY3kgYSANCiAgYml0LCBidXQgSSBo b3BlIGZvbGtzIGNhbiBzZWUgd2h5IGl0IGlzIHJhdGhlciBwcmFjdGljYWxseSBpbXBvcnRhbnQu Jm5ic3A7IA0KICBBbmQgbXkgcG9pbnQgYWJvdXQgdGhlIGxhcmdlIG1lc3NhZ2UvZmlsZS9zdHJl YW0gYWdncmVnYXRlcyB0aGF0IG11c3QgDQogIHVsdGltYXRlbHkgYmUgY2FycmllZCB0ZW5kcyB0 byBzdXBwb3J0IGEgcG9zaXRpb24gb2Ygc3ltbWV0cmljIEJXIA0KICBJTU8uPC9TUEFOPjwvU1BB Tj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnk+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5z IE1TIj48Rk9OVCBjb2xvcj0jODAwMDAwPjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4MTYtMjEwNDIw MDk+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+Jm5ic3A7 PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48 U1BBTiANCiAgY2xhc3M9MjM0MDQxODE2LTIxMDQyMDA5PjwvU1BBTj48L1NQQU4+PC9GT05UPiZu YnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2 eT48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFN SUxZOiBBcmlhbCI+PFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT4mbmJzcDs8L1NQ QU4+TW9yZSBnZW5lcmFsbHksIGRvIHlvdSB0aGluayBvZiBhbnkgDQogIHJlYXNvbnMgd2h5IGEg bm9uLXRvcC1vZi1zdGFjayBiaS1kaXJlY3Rpb25hbCB0cmFuc3BvcnQgY29ubmVjdGlvbiBhdCBh bnkgDQogIGxheWVyIG5lZWRzIHRvIGJlIGJhbmR3aWR0aC13aXNlIGFzeW1tZXRyaWNhbD88bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvbWljIFNh bnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9O VCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzAwMDAwMD48U1BBTiBjbGFzcz0yMzQw NDE4MTYtMjEwNDIwMDk+PFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAwOT5OSD0mZ3Q7 IEkgY2FuJ3Qgc2F5IHRoYXQgSSANCiAgY2FuLjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj48 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFy aWFsIj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzAwMDAwMD48U1BBTiBj bGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+PFNQQU4gDQogIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAw OT48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9vOnA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQgDQogIGZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwMDA+PFNQQU4gY2xhc3M9MjM0MDQxODE2LTIxMDQy MDA5PjxTUEFOIA0KICBjbGFzcz0yMzQwNDE4MTYtMjEwNDIwMDk+Jm5ic3A7IHJlZ2FyZHMsIA0K ICBOZWlsPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9 IzgwMDAwMCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJD b21pYyBTYW5zIE1TIiBjb2xvcj0jMDAwMDAwPjxTUEFOIGNsYXNzPTIzNDA0MTgxNi0yMTA0MjAw OT48U1BBTiANCiAgY2xhc3M9MjM0MDQxODE2LTIxMDQyMDA5PjwvU1BBTj48L1NQQU4+PC9GT05U PjwvU1BBTj48L286cD48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0KICBzdHlsZT0i Q09MT1I6IG5hdnkiPlRoYW5rcyw8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkg c2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9O VC1GQU1JTFk6IEFyaWFsIj5JZ29yPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8Rk9OVCBmYWNlPSJDb21pYyBTYW5z IE1TIj48Rk9OVCANCiAgY29sb3I9IzgwMDAwMD48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNz PTIzNDA0MTgxNi0yMTA0MjAwOT5oZzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvbWljIFNhbnMg TVMiIGNvbG9yPW1hcm9vbiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBtYXJvb247IEZPTlQtRkFNSUxZOiAnQ29taWMgU2FucyBNUyciPk5vdyB3cnQgDQog IE9BTSBNUExTLVRQIGlzIGEgY28tcHMgbW9kZSBuZXR3b3JrLiZuYnNwOyBZb3UgY291bGQgYXJn dWUgdGhpcyBzaG91bGQgaGF2ZSANCiAgRkRJL0FJUy4uLi5ob3dldmVyLCB0aGUgbWVyaXQgb2Yg dGhpcyBpcyBoaWdobHkgcXVlc3Rpb25hYmxlLiZuYnNwOyBXaGVuIEkgYW5kIA0KICBjb2xsZWFn dWVzIGRpc2N1c3NlZCB3aGV0aGVyIFBCQi1URSAoYWxzbyBhIGNvLXBzIG1vZGUgbmV0d29yaykg c2hvdWxkIGhhdmUgDQogIEZESS9BSVMgd2UgY29uY2x1ZGVkIHRoYXQgb24gYmFsYW5jZSBpdCB3 YXMgbm90IGEgZ29vZCBpZGVhLi4uLi5hbmQgbm90ZSB0aGF0IA0KICBpbml0aWFsbHkgSSB3YXMg aW4gZmF2b3VyIG9mIGhhdmluZyBBSVMsIGJ1dCBteSBjb2xsZWFndWVzIHByb3ZpZGVkIHN0cm9u ZyANCiAgdGVjaG5pY2FsIGFyZ3VtZW50cyB0aGF0IGNvbnZpbmNlZCBtZSBvdGhlcndpc2UuPC9T UEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9bWFyb29uIHNpemU9Mj48U1BB TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG1hcm9vbjsgRk9OVC1GQU1JTFk6 ICdDb21pYyBTYW5zIE1TJyI+QUlTL0ZESSANCiAgaXMgaGlzdG9yaWNhbGx5IGxpbmtlZCB0byB0 aGUgZWFybHkgUERIIGNvLWNzIG1vZGUgbGF5ZXIgbmV0d29ya3MgdGhhdCB1c2VkIA0KICBUVEwg bG9naWMuJm5ic3A7IFdoZW4gdGhpcyBkaWVkIGl0IHB1dCBvdXQgYSArNVYgKGFsbCAxcykgc2ln bmFsIGJ5IGRlZmF1bHQsIA0KICBpZSBpdCByZXF1aXJlZCBubyBjb25zY2lvdXMgZWZmb3J0IHRv IGdlbmVyYXRlIGl0Li4uLi50aGlzIGlzIGtleSBwb2ludC4mbmJzcDsgDQogIEZ1cnRoZXIsIGlu IHRoZXNlIG5ldHdvcmtzIHRoZXJlIGlzIGEgZmFpcmx5IHN0YXRpYy9sb25nLWhvbGRpbmcgY2xp ZW50IHNlcnZlciANCiAgcmVsYXRpb25zaGlwLiZuYnNwOyBDbGVhcmx5IHRoaXMgaXMgbm90IHRy dWUgaW4gdGhlIGNsLXBzIG1vZGUgYW5kIGl0J3Mgd2h5IA0KICBJRVRGIGhhdmUgbmV2ZXIgc3Bl Y2lmaWVkIEFJUyBmb3IgSVAgYW5kIGl0cyB3aHkgSUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2UgdG8g DQogIHRocm93LW91dCBBSVMgaW4gODAyLjFhZyBmb3IgRXRoZXJuZXQgKHRob3VnaCBJVFUgaGF2 ZSB1bndpc2VseSBJTU8gcmV0YWluZWQgDQogIGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0 IGFueSBvcGVyYXRvciBwbGFubmluZyB0byB1c2UgRXRoZXJuZXQgZXF1aXBtZW50IA0KICB3b3Vs ZCBhbHdheXMgbG9vayB0byBJRUVFIHN0ZHMgYW5kIG5vdCBJVFUgb25lcykuPC9TUEFOPjwvRk9O VD48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9bWFyb29uIHNpemU9Mj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG1hcm9vbjsgRk9OVC1GQU1JTFk6ICdDb21pYyBT YW5zIE1TJyI+QUlTL0ZESSANCiAgYW5kIHRoZSBjby1wcyBtb2RlIGlzIGRlYmF0YWJsZS4mbmJz cDsgQXMgSSBub3RlZCBhYm92ZSwgb24gYmFsYW5jZSB3ZSANCiAgY29uc2lkZXJlZCBub3QgYSBn b29kIGlkZWEgZm9yIFBCQi1URSBPQU0gYmVjYXVzZSBpdCByZXF1aXJlcyBhIGNvbnNjaW91cyAN CiAgZWZmb3J0IHRvIGdlbmVyYXRlIGl0ICh1bmxpa2UgdGhlIGNvLWNzIG1vZGUpIHNvIHRoZXJl IGFyZSBsaWtlbHkgdG8gYmUgDQogIHNjYWxpbmcgcHJvYmxlbXMgYW5kIGl0cyBvbmUgbW9yZSB0 aGluZyB0byBnbyANCiAgd3JvbmcuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIg Y29sb3I9bWFyb29uIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IG1hcm9vbjsgRk9OVC1GQU1JTFk6ICdDb21pYyBTYW5zIE1TJyI+WW91IA0KICBzaG91bGQg YWxzbyBoYXZlIHNlZW4gbWUgbWFrZSB0aGUgcG9pbnQgbWFueSB0aW1lcyBpbiB0aGUgcGFzdCB0 aGF0IHRoZSANCiAgYWx3YXlzLW9uIGRlZmVjdCBkZXRlY3Rpb24vaGFuZGxpbmcgT0FNIG5lZWRz IHRvIGJlIGFzIHNpbXBsZS9zcGFyc2UgYXMgDQogIHBvc3NpYmxlIHdpdGggYXMgbGl0dGxlIGNv bmZpZyBhcyBwb3NzaWJsZSBiZWNhdXNlIHdlIG5lZWQgc3VwZXIgDQogIHJlbGlhYmlsaXR5Li4u Li4uVENNIGdvZXMgY29tcGxldGVseSBhZ2FpbnN0IHRoZSBncmFpbiBoZXJlLiZuYnNwOyBBbHNv IG5vdGUgDQogIHRoYXQgdGhlIE9BTSByZXF1aXJlZCBmb3IgZWFjaCBvZiB0aGUgMyBuZXR3b3Jr IG1vZGVzIGlzIG5vdCB0aGUgc2FtZSwgZGVzcGl0ZSANCiAgd2hhdCBzb21lIGNsYWltLjwvU1BB Tj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPW1hcm9vbiBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBtYXJvb247IEZPTlQtRkFNSUxZOiAn Q29taWMgU2FucyBNUyciPnJlZ2FyZHMsIA0KICBOZWlsPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8QkxPQ0tRVU9URSANCiAgc3R5bGU9IkJPUkRFUi1SSUdI VDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVtIG5v bmU7IFBBRERJTkctTEVGVDogM3B0OyBQQURESU5HLUJPVFRPTTogMGluOyBNQVJHSU46IDVwdCAw aW4gNXB0IDNwdDsgQk9SREVSLUxFRlQ6IG1hcm9vbiAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6 IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg IDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBjZW50ZXIiIGFsaWduPWNl bnRlcj48Rk9OVCANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiBzdHls ZT0iRk9OVC1TSVpFOiAxMnB0Ij4NCiAgICA8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVyIHdp ZHRoPSIxMDAlIiBTSVpFPTM+DQogICAgPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICA8UCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxCPjxGT05UIGZhY2U9VGFo b21hIA0KICAgIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9GT05UPjwv Qj48Rk9OVCANCiAgICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+IA0KICAgIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gPEI+PFNQQU4gDQogICAgc3R5bGU9 IkZPTlQtV0VJR0hUOiBib2xkIj5PbiBCZWhhbGYgT2YgDQogICAgPC9TUEFOPjwvQj5saXUuZ3Vv bWFuQHp0ZS5jb20uY248QlI+PEI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xk Ij5TZW50OjwvU1BBTj48L0I+IDIxIEFwcmlsIDIwMDkgMDI6NTk8QlI+PEI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Ubzo8L1NQQU4+PC9CPiBCUlVOR0FSRCwgREVCT1JB SCBBLCANCiAgICBBVFRMQUJTPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+ Q2M6PC9TUEFOPjwvQj4gPHN0MTpQZXJzb25OYW1lIA0KICAgIHc6c3Q9Im9uIj5tcGxzLXRwQGll dGYub3JnPC9zdDE6UGVyc29uTmFtZT48QlI+PEI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJ R0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48L0I+IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCAN CiAgICBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czwvU1BBTj48L0ZP TlQ+PG86cD48L286cD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4t Qk9UVE9NOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0KICAgIHNpemU9Mz48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48QlI+PC9TUEFOPjwvRk9OVD48VFQ+PEZPTlQg DQogICAgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0Ij5EZWJvcmFoPC9TUEFOPjwvRk9OVD48L1RUPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiANCiAgICBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPjo8L1NQQU4+PC9GT05UPiA8QlI+PEZPTlQgDQogICAgZmFjZT1z YW5zLXNlcmlmIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogc2Fucy1zZXJpZiI+Jm5ic3A7bWF5YmUgd2hhdCB5b3Ugc2FpZCANCiAgICBpcyBy aWdodC4gYnV0IEkgY2FuJ3QgY29tcGxldGVseSBhZ3JlZSB5b3VyIG9waW5pb25zLiBJTU8uIG1w bHMtdHAgaXMgcmVnYXJkIA0KICAgIGFzIHRyYW5zcG9ydCBuZXR3b3JrIGxpa2UgU0RIL1NPTkVU LiBzbyBpdCBzaG91bGQgaGF2ZSBBSVMvRkRJIGZ1Y3Rpb25zIGFzIA0KICAgIFNESC9TT05FVC48 L1NQQU4+PC9GT05UPiA8QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPmRv IHlvdSB0aGluayANCiAgICBzby48L1NQQU4+PC9GT05UPiA8QlI+PEJSPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPmJlc3QgcmVnYXJkczwvU1BBTj48L0ZPTlQ+IA0KICAgIDxCUj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5saXUgDQogICAgPC9TUEFOPjwvRk9OVD48 QlI+PEJSPjxvOnA+PC9vOnA+PC9QPg0KICAgIDxUQUJMRSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBz dHlsZT0iV0lEVEg6IDEwMCUiIGNlbGxTcGFjaW5nPTMgY2VsbFBhZGRpbmc9MCANCiAgICB3aWR0 aD0iMTAwJSIgYm9yZGVyPTA+DQogICAgICA8VEJPRFk+DQogICAgICA8VFI+DQogICAgICAgIDxU RCANCiAgICAgICAgc3R5bGU9IlBBRERJTkctUklHSFQ6IDAuNzVwdDsgUEFERElORy1MRUZUOiAw Ljc1cHQ7IFBBRERJTkctQk9UVE9NOiAwLjc1cHQ7IFdJRFRIOiAyNiU7IFBBRERJTkctVE9QOiAw Ljc1cHQiIA0KICAgICAgICB2QWxpZ249dG9wIHdpZHRoPSIyNiUiPg0KICAgICAgICAgIDxQIGNs YXNzPU1zb05vcm1hbD48Qj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPjxTUEFOIA0KICAg ICAgICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA3LjVwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPiJCUlVOR0FSRCwgDQogICAgICAgICAgREVCT1JBSCBBLCBBVFRM QUJTIiAmbHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQog ICAgICAgICAgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT48U1BBTiANCiAgICAgICAgICBzdHlsZT0i Rk9OVC1TSVpFOiA3LjVwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPiANCiAgICAgICAgICA8 L1NQQU4+PC9GT05UPjxCUj48Rk9OVCBmYWNlPSJBcmlhbCBVbmljb2RlIE1TIiBzaXplPTE+PFNQ QU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogNy41cHQ7IEZPTlQtRkFNSUxZOiAnQXJp YWwgVW5pY29kZSBNUyciPuWPkeS7tuS6ujwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogICAgICAgICAg c2l6ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDcuNXB0Ij46IDwvU1BBTj48L0ZPTlQ+PEZP TlQgDQogICAgICAgICAgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT48U1BBTiANCiAgICAgICAgICBz dHlsZT0iRk9OVC1TSVpFOiA3LjVwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPiZuYnNwO21w bHMtdHAtYm91bmNlc0BpZXRmLm9yZzwvU1BBTj48L0ZPTlQ+IA0KICAgICAgICAgIDxvOnA+PC9v OnA+PC9QPg0KICAgICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+PFNQQU4g DQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogNy41cHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj4yMDA5LTA0LTIwIA0KICAgICAgICAgIDIzOjQ3PC9TUEFOPjwvRk9OVD4gPG86cD48L286 cD48L1A+PC9URD4NCiAgICAgICAgPFREIA0KICAgICAgICBzdHlsZT0iUEFERElORy1SSUdIVDog MC43NXB0OyBQQURESU5HLUxFRlQ6IDAuNzVwdDsgUEFERElORy1CT1RUT006IDAuNzVwdDsgV0lE VEg6IDczJTsgUEFERElORy1UT1A6IDAuNzVwdCIgDQogICAgICAgIHZBbGlnbj10b3Agd2lkdGg9 IjczJSI+DQogICAgICAgICAgPFRBQkxFIGNsYXNzPU1zb05vcm1hbFRhYmxlIHN0eWxlPSJXSURU SDogMTAwJSIgY2VsbFNwYWNpbmc9MyANCiAgICAgICAgICBjZWxsUGFkZGluZz0wIHdpZHRoPSIx MDAlIiBib3JkZXI9MD4NCiAgICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICAgIDxUUj4NCiAg ICAgICAgICAgICAgPFREIA0KICAgICAgICAgICAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMC43 NXB0OyBQQURESU5HLUxFRlQ6IDAuNzVwdDsgUEFERElORy1CT1RUT006IDAuNzVwdDsgUEFERElO Ry1UT1A6IDAuNzVwdCIgDQogICAgICAgICAgICAgIHZBbGlnbj10b3A+DQogICAgICAgICAgICAg ICAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiByaWdodCIgYWxpZ249cmln aHQ+PEZPTlQgDQogICAgICAgICAgICAgICAgZmFjZT0iQXJpYWwgVW5pY29kZSBNUyIgc2l6ZT0x PjxTUEFOIA0KICAgICAgICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDcuNXB0OyBGT05ULUZB TUlMWTogJ0FyaWFsIFVuaWNvZGUgTVMnIj7mlLbku7bkuro8L1NQQU4+PC9GT05UPjxvOnA+PC9v OnA+PC9QPjwvVEQ+DQogICAgICAgICAgICAgIDxURCANCiAgICAgICAgICAgICAgc3R5bGU9IlBB RERJTkctUklHSFQ6IDAuNzVwdDsgUEFERElORy1MRUZUOiAwLjc1cHQ7IFBBRERJTkctQk9UVE9N OiAwLjc1cHQ7IFBBRERJTkctVE9QOiAwLjc1cHQiIA0KICAgICAgICAgICAgICB2QWxpZ249dG9w Pg0KICAgICAgICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0xPjxTUEFOIA0KICAgICAgICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDcuNXB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Ik1hYXJ0ZW4gDQogICAgICAgICAgICAgICAgVmlz c2VycyIgJmx0OzxzdDE6UGVyc29uTmFtZSANCiAgICAgICAgICAgICAgICB3OnN0PSJvbiI+bWFh cnRlbi52aXNzZXJzQGh1YXdlaS5jb208L3N0MTpQZXJzb25OYW1lPiZndDssIA0KICAgICAgICAg ICAgICAgICZsdDs8c3QxOlBlcnNvbk5hbWUgDQogICAgICAgICAgICAgICAgdzpzdD0ib24iPm5l aWwuMi5oYXJyaXNvbkBidC5jb208L3N0MTpQZXJzb25OYW1lPiZndDs8L1NQQU4+PC9GT05UPiAN CiAgICAgICAgICAgICAgICA8bzpwPjwvbzpwPjwvUD48L1REPjwvVFI+DQogICAgICAgICAgICA8 VFI+DQogICAgICAgICAgICAgIDxURCANCiAgICAgICAgICAgICAgc3R5bGU9IlBBRERJTkctUklH SFQ6IDAuNzVwdDsgUEFERElORy1MRUZUOiAwLjc1cHQ7IFBBRERJTkctQk9UVE9NOiAwLjc1cHQ7 IFBBRERJTkctVE9QOiAwLjc1cHQiIA0KICAgICAgICAgICAgICB2QWxpZ249dG9wPg0KICAgICAg ICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjogcmlnaHQiIGFs aWduPXJpZ2h0PjxGT05UIA0KICAgICAgICAgICAgICAgIGZhY2U9IkFyaWFsIFVuaWNvZGUgTVMi IHNpemU9MT48U1BBTiANCiAgICAgICAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiA3LjVwdDsg Rk9OVC1GQU1JTFk6ICdBcmlhbCBVbmljb2RlIE1TJyI+5oqE6YCBPC9TUEFOPjwvRk9OVD48bzpw PjwvbzpwPjwvUD48L1REPg0KICAgICAgICAgICAgICA8VEQgDQogICAgICAgICAgICAgIHN0eWxl PSJQQURESU5HLVJJR0hUOiAwLjc1cHQ7IFBBRERJTkctTEVGVDogMC43NXB0OyBQQURESU5HLUJP VFRPTTogMC43NXB0OyBQQURESU5HLVRPUDogMC43NXB0IiANCiAgICAgICAgICAgICAgdkFsaWdu PXRvcD4NCiAgICAgICAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PHN0MTpQZXJzb25OYW1l IHc6c3Q9Im9uIj48Rk9OVCANCiAgICAgICAgICAgICAgICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0x PjxTUEFOIA0KICAgICAgICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDcuNXB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+bXBscy10cEBpZXRmLm9yZzwvU1BBTj48L0ZPTlQ+PC9zdDE6UGVy c29uTmFtZT4gDQogICAgICAgICAgICAgICAgPG86cD48L286cD48L1A+PC9URD48L1RSPg0KICAg ICAgICAgICAgPFRSPg0KICAgICAgICAgICAgICA8VEQgDQogICAgICAgICAgICAgIHN0eWxlPSJQ QURESU5HLVJJR0hUOiAwLjc1cHQ7IFBBRERJTkctTEVGVDogMC43NXB0OyBQQURESU5HLUJPVFRP TTogMC43NXB0OyBQQURESU5HLVRPUDogMC43NXB0IiANCiAgICAgICAgICAgICAgdkFsaWduPXRv cD4NCiAgICAgICAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046 IHJpZ2h0IiBhbGlnbj1yaWdodD48Rk9OVCANCiAgICAgICAgICAgICAgICBmYWNlPSJBcmlhbCBV bmljb2RlIE1TIiBzaXplPTE+PFNQQU4gDQogICAgICAgICAgICAgICAgc3R5bGU9IkZPTlQtU0la RTogNy41cHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwgVW5pY29kZSBNUyciPuS4u+mimDwvU1BBTj48 L0ZPTlQ+PG86cD48L286cD48L1A+PC9URD4NCiAgICAgICAgICAgICAgPFREIA0KICAgICAgICAg ICAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMC43NXB0OyBQQURESU5HLUxFRlQ6IDAuNzVwdDsg UEFERElORy1CT1RUT006IDAuNzVwdDsgUEFERElORy1UT1A6IDAuNzVwdCIgDQogICAgICAgICAg ICAgIHZBbGlnbj10b3A+DQogICAgICAgICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+PFNQQU4gDQogICAgICAgICAgICAgICAgc3R5bGU9IkZP TlQtU0laRTogNy41cHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5SZTogW21wbHMtdHBdIA0K ICAgICAgICAgICAgICAgIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCAN CiAgICAgICAgICAgICAgICByZXF1aXJlbWVudHM8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9Q PjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ DQogICAgICAgICAgPFRBQkxFIGNsYXNzPU1zb05vcm1hbFRhYmxlIGNlbGxTcGFjaW5nPTMgY2Vs bFBhZGRpbmc9MCBib3JkZXI9MD4NCiAgICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICAgIDxU Uj4NCiAgICAgICAgICAgICAgPFREIA0KICAgICAgICAgICAgICBzdHlsZT0iUEFERElORy1SSUdI VDogMC43NXB0OyBQQURESU5HLUxFRlQ6IDAuNzVwdDsgUEFERElORy1CT1RUT006IDAuNzVwdDsg UEFERElORy1UT1A6IDAuNzVwdCIgDQogICAgICAgICAgICAgIHZBbGlnbj10b3A+DQogICAgICAg ICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0zPjxTUEFOIA0KICAgICAgICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9URD4NCiAgICAgICAgICAgICAgPFRE IA0KICAgICAgICAgICAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMC43NXB0OyBQQURESU5HLUxF RlQ6IDAuNzVwdDsgUEFERElORy1CT1RUT006IDAuNzVwdDsgUEFERElORy1UT1A6IDAuNzVwdCIg DQogICAgICAgICAgICAgIHZBbGlnbj10b3A+DQogICAgICAgICAgICAgICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAg ICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT4NCiAgICAgICAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQog ICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiAN CiAgICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEJSPjxCUj48QlI+PC9T UEFOPjwvRk9OVD48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BB TiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5JIGFncmVlIHdpdGggTmVpbCwgDQogICAgaXQgaXMg dmVyeSBxdWVzdGlvbmFibGUgdGhlIHZhbHVlIG9mIEFJUy9GREkgaW4gYTwvU1BBTj48L0ZPTlQ+ PC9UVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48QlI+PFRU PjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5wYWNrZXQgbmV0d29yay0gYW55IG1vZGUu IEl0IGNhbiByZXN1bHQgaW4gYSBEb1MgYXR0YWNrIA0KICAgIGJ5IGFuIG9wZXJhdG9yPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+b24gdGhlbXNlbHZlcyBzbyAN CiAgICBldmVuIFkxNzMxIHJlY29tbWVuZHMgbm90IHRvIGJsb2NrIGRhdGEgZnJhbWVzOjwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiJBIE1FUCBjYW4g ZGVjaWRlIHdoZXRoZXIgaXQgYmxvY2tzIGRhdGEgZnJhbWVzIHdoZW4gaXQgDQogICAgZGV0ZWN0 cyBkQUlTLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPlRoZSBw cmluY2lwbGUgDQogICAgcmVxdWlyZW1lbnQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij50aGF0IGluZmx1ZW5jZXMgdGhpcyANCiAgICBkZWNpc2lvbiBpcyB0aGF0 IGRhdGEgZnJhbWVzIG91Z2h0IHRvIGJlIGZvcndhcmRlZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPmFzIG11Y2ggYXMgcG9zc2libGUsIHdpdGhvdXQ8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij50aGUgcG9z c2liaWxpdHkgb2YgZm9yd2FyZGluZyB3cm9uZyBkYXRhIGZyYW1lcyANCiAgICBkb3duc3RyZWFt LiI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5UYWJsZSBJLjct MiBzaG93cyANCiAgICBmb3IgQUlTLCBub3QgdG8gYmxvY2suPC9GT05UPjwvVFQ+PEJSPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPkFuZCANCiAgICBhcyBZMTczMSBzdGF0ZXMsIEFJ UyBjYW4gb25seSBiZSB1c2VkIHVuZGVyIHZlcnkgDQogICAgY29uc3RyYWluZWQ8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5hcmNoaXRlY3R1cmVzIC0gaWYgDQog ICAgcmVxdWlyZWQgZm9yIE1QTFMtVFAsIGl0IG5lZWRzIHRvIGhhdmUgdGhlIHNhbWU8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5ndWlkYW5jZSBhcyBp biBZMTczMSwgaS5lLiBwb2ludC10by1wb2ludCBhbmQgDQogICAgc2VydmVyL2NsaWVudCBvbmUt dG8tb25lOjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiJmb3Ig YSANCiAgICBwb2ludC10by1wb2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSBz aW5nbGUgcGVlciANCiAgICBNRVAuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+VGhlcmVmb3JlLCANCiAgICB0aGVyZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPmlzIG5vIGFtYmlndWl0eSByZWdhcmRpbmcgDQogICAgdGhlIHBl ZXIgTUVQIGZvciB3aGljaCBpdCBzaG91bGQgc3VwcHJlc3M8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5hbGFybXMgd2hlbiBpdCByZWNlaXZlcyB0aGU8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5FVEgtQUlT IGluZm9ybWF0aW9uLiI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJp ZXIgTmV3Ij5TbyBzaG91bGQgb25seSBiZSB3aXRoaW4gb25lIGRvbWFpbiAtIHRoZW4gbm8gDQog ICAgbmVlZC48L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVy IE5ldyI+RGVib3JhaDwvRk9OVD48L1RUPjxCUj48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNv dXJpZXIgTmV3Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZyANCiAgICBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT248L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5CZWhhbGYgT2YgTWFhcnRl biBWaXNzZXJzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5l dyI+U2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSAxMDowNSANCiAgICBBTTwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPlRvOiA8c3QxOlBlcnNvbk5hbWUgDQog ICAgdzpzdD0ib24iPm5laWwuMi5oYXJyaXNvbkBidC5jb208L3N0MTpQZXJzb25OYW1lPjwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPkNjOiA8c3QxOlBl cnNvbk5hbWUgDQogICAgdzpzdD0ib24iPm1wbHMtdHBAaWV0Zi5vcmc8L3N0MTpQZXJzb25OYW1l PjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPlN1Ympl Y3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCANCiAg ICBwYXRoPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ cmVxdWlyZW1lbnRzPC9GT05UPjwvVFQ+PEJSPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291 cmllciBOZXciPk5laWwsPC9GT05UPjwvVFQ+PEJSPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPiZndDsgYnV0IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSAN CiAgICBmYXZvdXIhPC9GT05UPjwvVFQ+PEJSPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPkV0aGVybmV0IEFJUyBpcyANCiAgICBpbmRlZWQgYSByZXF1aXJlbWVudCBhbmQgYSBuZWNl c3NpdHkuIEFuZCB5b3Ugd2lsbCANCiAgICBub3Q8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij5iZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPmFibGUgdG8gdW5kZXJzdGFuZCB0aGF0IGFzIGxvbmcgYXMgeW91IHJlZnVz ZSB0byBhY2NlcHQgDQogICAgdGhhdCAiY2wtbW9kZSI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3Ij5pcyANCiAgICBhPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+Zm9yd2FyZGluZyBtb2RlIHdpdGhpbiBhIA0KICAgICoqdHJhbnNw b3J0IGVudGl0eSoqLiBHLjgwMCBhbWVuZG1lbnQgMSBoYXM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5maW5hbGx5PC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+cmVpbnRyb2R1Y2VkIHRoaXMgdHJhbnNwb3J0 IGVudGl0eSBpbnRvIEcuODAwLiBCZXNpZGVzIA0KICAgIHRoYXQsIGl0IGFsc288L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5pbnRyb2R1Y2VkIHRoZSANCiAgICAq KmRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24qKjo8L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9O VCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+W0cuODAwIGFtMV0gIkEgZGlmZmVyZW50aWF0ZWQg Y29ubmVjdGlvbiBpcyBhIHRyYW5zcG9ydCANCiAgICBlbnRpdHkgdGhhdDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnRyYW5zZmVycyANCiAgICBpbmZvcm1hdGlv biBiZWxvbmdpbmcgdG8gbXVsdGlwbGUgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiANCiAgICBwb3J0 czwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPmFjcm9zcyBhIHN1 Ym5ldHdvcmsuIA0KICAgICZsdDsuLiZndDsgSW4gYSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9u IG1lc3NhZ2U8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3 Ij5jb250ZW50czwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPmFy ZSANCiAgICBpbnRlcnByZXRlZCB0byBpZGVudGlmeSAoc2V0cyBvZikgY29tbXVuaWNhdGlvbnMg d2hpY2ggDQogICAgcmVjZWl2ZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPmRpZmZlcmVudDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPnRyZWF0bWVudC4gJm5ic3A7VGhlIHNldHMgb2YgY29tbXVuaWNhdGlv bnMgbWF5IGJlIA0KICAgIGRpc3Rpbmd1aXNoZWQgYnkgdGhlPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Zm9yd2FyZGluZyANCiAgICBpZGVudGlmaWVyIG9yIG90 aGVyIGxheWVyIGluZm9ybWF0aW9uLiAmbmJzcDtPcmRlciBpcyANCiAgICBub3Q8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5uZWNlc3NhcmlseTwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPnByZXNlcnZlZCBi ZXR3ZWVuIG1lc3NhZ2VzIGJlbG9uZ2luZyB0byBzZXRzIG9mIA0KICAgIGNvbW11bmljYXRpb25z IHJlY2VpdmluZzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBO ZXciPmRpZmZlcmVudCB0cmVhdG1lbnQuICZuYnNwO1NldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5 IGJlIA0KICAgIGlkZW50aWZpZWQgZm9yPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+cHVycG9zZXM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij5zdWNoIA0KICAgIGFzIHRyYWZmaWMgY29uZGl0aW9uaW5nIG9yIHByZXNl cnZpbmcgY29tbXVuaWNhdGlvbiBtZXNzYWdlIA0KICAgIG9yZGVyLiI8L0ZPTlQ+PC9UVD48QlI+ PEJSPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPkV0aGVybmV0IFZMQU5zIA0KICAg IGFyZSBpbiB0ZXJtcyBvZiBHLjgwMCAiZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbnMiLjwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPkV0aGVybmV0PC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+QUlTIA0KICAgIHByb3Zp ZGVzIEFJUyB3aXRoaW4gdGhlIHNjb3BlIG9mIHN1Y2ggImRpZmZlcmVudGlhdGVkIA0KICAgIGNv bm5lY3Rpb24iLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBO ZXciPklmPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+eW91IGFw cGx5IA0KICAgIHRoaXMgdG8gbXkgcHJvcG9zZWQgUFROIGxheWVyIHN0YWNrLCB0aGVuIHRoZSBF VkMgDQogICAgbGF5ZXI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJp ZXIgTmV3Ij50b3BvbG9neTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPndpbGwgDQogICAgY29uc2lzdHMgb2YgRVZDIGxpbmtzIHN1cHBvcnRlZCBieSBNUExTLVRQ LCBFdGhlcm5ldCwgUEJCLVRFIA0KICAgIGFuZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQog ICAgZmFjZT0iQ291cmllciBOZXciPlAtT1ROPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+VlAgDQogICAgdHJhaWxzIGluc2lkZSBtZXRybyBhbmQgY29yZSBkb21h aW5zIGludGVyY29ubmVjdGluZyBFVkMgDQogICAgbWF0cmljZXMuPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+V2hlbjwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPm9uZSBvZiANCiAgICB0aG9zZSBFVkMgbGlua3MgaXMg aW50ZXJydXB0ZWQsIGUuZy4gaW4gdGhlIGNvcmUgYmV0d2VlbiBtZXRybyANCiAgICAxPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+YW5kPC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+bWV0cm8gNCAoc2VlIGF0dGFjaGVk IHNsaWRlKSwgdGhlbiB0aGUgRVZDIGRpZmZlcmVudGlhdGVkIA0KICAgIGNvbm5lY3Rpb248L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij50aGF0IA0KICAgIGlzPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+cHJlc2VudCBvbiB0aGlz IGxpbmsgd2lsbCBiZSANCiAgICBpbnRlcnJ1cHRlZC4gQXQgdGhlIEVWQyBzd2l0Y2gvYnJpZGdl IG5vZGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5p bjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPm1ldHJvIDQgDQog ICAgdGhpcyBpbnRlcnJ1cHRpb24gaXMgbm90aWNlZCBhbmQgRVZDLUFJUyBpcyBpbnNlcnRlZCBp biANCiAgICB0aGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5k b3duc3RyZWFtIGRpcmVjdGlvbiB0byANCiAgICBzdXBwcmVzcyB0aGUgRVZDLUxPQyBhbGFybXMg YXQgRVZDIGVuZHBvaW50cyBENDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPmFuZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291 cmllciBOZXciPkQ1LjwvRk9OVD48L1RUPjxCUj48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij5UaGUgDQogICAgRVZDLUFJUyAoaS5lLiBFdGhlcm5ldCBBSVMpIGZyYW1lIGhhcyBhIHJl c2VydmVkIG11bHRpY2FzdCANCiAgICBhZGRyZXNzLDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPndoaWNoIGd1YXJhbnRlZXMgdGhhdCANCiAgICB0aGUgQUlTIGlz IGJyb2FkY2FzdCB0byB0aGUgZW5kcG9pbnRzIG9mIHRoZSANCiAgICBFVkMuPC9GT05UPjwvVFQ+ PEJSPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPkkgYmVsaWV2ZSB0aGF0IGl0IGlz IA0KICAgIHRpbWUgZm9yIHlvdSB0byBhZGFwdCB5b3VyIHZpZXcgb24gY28gYW5kIGNsIG1vZGVz PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+YW5kPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+cmVsYXRlIGl0IA0KICAg IHRvIHRoZSBmb3J3YXJkaW5nIG1vZGUgKipJTlNJREUqKiBhIHRyYW5zcG9ydCBlbnRpdHkuIA0K ICAgIDwvRk9OVD48L1RUPjxCUj48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5XaGF0 IHdlIGtub3cgYXMgdGhlIA0KICAgIGludGVybmV0IGlzIGVzc2VudGlhbGx5IGFuICJJUCBkaWZm ZXJlbnRpYXRlZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBO ZXciPmNvbm5lY3Rpb24iIHdpdGggYSBiaWxsaW9uIG9yIG1vcmUgDQogICAgcG9ydHMuPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+V2hhdCB3ZSBrbm93IGFzIGFu IElQIFZQTiANCiAgICBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQ8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5jb25uZWN0aW9uIjwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPndpdGggZS5n LiBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gDQogICAgMTAwMCkuPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+V2hhdCB3ZSBrbm93IGFzIGFu IA0KICAgIEV0aGVybmV0IFZMQU4gaXMgZXNzZW50aWFsbHkgYW4gIkV0aGVybmV0PC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ZGlmZmVyZW50aWF0ZWQ8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5jb25uZWN0 aW9uIiB3aXRoIG4gcG9ydHMgKG4gaW4gdGhlIHJhbmdlIG9mIGUuZy4gMiB0byANCiAgICAxMDAw KS48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5XaGF0IHdlIGtu b3cgYXMgYSBwMnAgDQogICAgTVBMUyBFLUxTUCBpcyBlc3NlbnRpYWxseSBhbiAiTVBMUyBkaWZm ZXJlbnRpYXRlZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBO ZXciPmNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5XaGF0IHdlIGtub3cgYXMgYSBwMnAgU0RIIFZDLW4gaXMg YSAiU0RIIFZDLW4gY29ubmVjdGlvbiIgDQogICAgd2l0aCAyIHBvcnRzLjwvRk9OVD48L1RUPjxC Uj48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5UcmFuc3BvcnQgDQogICAgbmV0d29y ayBPQU0gYXBwbGllcyB0byB0cmFuc3BvcnQgZW50aXRpZXMsIHdoaWNoIGFyZSAoaW4gDQogICAg dGVybXM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5v ZjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPkcuODAwIGFtMSkg DQogICAgY29ubmVjdGlvbnMgYW5kIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb25zLjwvRk9OVD48 L1RUPjxCUj48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5SZWdhcmRzLDwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPk1hYXJ0ZW48 L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZh Y2U9IkNvdXJpZXIgTmV3Ij5Gcm9tOiA8c3QxOlBlcnNvbk5hbWUgDQogICAgdzpzdD0ib24iPm5l aWwuMi5oYXJyaXNvbkBidC5jb208L3N0MTpQZXJzb25OYW1lPiBbbWFpbHRvOjxzdDE6UGVyc29u TmFtZSANCiAgICB3OnN0PSJvbiI+bmVpbC4yLmhhcnJpc29uQGJ0LmNvbTwvc3QxOlBlcnNvbk5h bWU+XSA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5T ZW50OiB2cmlqZGFnIDE3IGFwcmlsIDIwMDkgDQogICAgMjI6MDA8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5UbzogDQogICAgSm9obi5FLkRyYWtlMkBib2Vpbmcu Y29tOyANCiAgICBJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0OzwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tOyA8c3QxOlBlcnNvbk5hbWUgDQogICAgdzpzdD0ib24iPm1hYXJ0ZW4udmlzc2Vy c0BodWF3ZWkuY29tPC9zdDE6UGVyc29uTmFtZT48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5DYzogPHN0MTpQZXJzb25OYW1lIA0KICAgIHc6c3Q9Im9u Ij5tcGxzLXRwQGlldGYub3JnPC9zdDE6UGVyc29uTmFtZT48L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5TdWJqZWN0OiBSRTogW21wbHMtdHBdIEFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgDQogICAgcGF0aDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPnJlcXVpcmVtZW50czwvRk9OVD48L1RU PjxCUj48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5Kb2huLCAmbmJzcDtU aGFua3MgdGhpcyBpcyBhIGdyZWF0IHBsYXRmb3JtIHRvIGV4cGxhaW4gDQogICAgd2h5IE9BTSBm b3IgdGhlIDM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3 Ij5uZXR3b3JrPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+bW9k ZXMgDQogICAgbmVlZHMgdG8gYmUgZGlmZmVyZW50LiAmbmJzcDtJIGFtIGdldHRpbmcgYSB3ZWUg Yml0IHRpcmVkIG9mIA0KICAgIGZvbGtzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+dHJ5aW5nPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+dG8gDQogICAgbWFrZSBhbGwgMyBuZXR3b3JrIG1vZGVzIGxvb2sgYWxpa2Ug KGFuZCB0aGVuLCBldmVuIHdvcnNlLCANCiAgICBpbnRlcndvcms8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij50aGVtPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+YXMgYXMgDQogICAgcGVlcnMuLi5lc3Agd2hlbiBub3Qg bm90IHRvcC1vZi1zdGFjazwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291 cmllciBOZXciPm5ldHdvcmtzLi4uSSBtZWFuIGhvdyBzaWxseSBjYW4gd2UgZ2V0PykuICZuYnNw OyBJIGFtIA0KICAgIGV2ZW4gbW9yZSBmcnVzdHJhdGVkIGJ5PC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+dGhlIGZhY3QgDQogICAgdGhvc2UgcGVkZGxpbmcgdGhp cyBGVUQgb25seSBldmVyIHNlZW0gdG8gY29uc2lkZXIgT0FNIA0KICAgIGFuZDwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPmZvcmdldDwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPmFsbCANCiAgICBvdGhlciBEUC9DUC9N UCBjb21wb25lbnRzIChlc3AgdG9wLW9mLXN0YWNrIA0KICAgIG1lc3NhZ2UvZmlsZS9zdHJlYW08 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5hcHBsaWNhdGlvbiAN CiAgICBhZGFwdGF0aW9ucykuICZuYnNwO0hvdyB3cm9uZyBjYW4gdGhpcyBnZXQhIDwvRk9OVD48 L1RUPjxCUj48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5JbiB0aGUgY28g bW9kZXMgYSAqY29ubmVjdGlvbiogaXMgYSB2ZXJ5IHNwZWNpZmljIGFuZCANCiAgICAqY29uc3Ry YWluaW5nKjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPmNvbnN0 cnVjdC4uLi4uSSANCiAgICBhbSBhc3N1bWluZyBoZXJlIHdlIHJlc3BlY3QgdGhlIHJ1bGVzIG9m IGEgDQogICAgY29ubmVjdGlvbjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPihpZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPnNpbmdsZSANCiAgICBzb3VyY2UpIHRob3VnaCBzb21lIGZvbGtzIGRvbid0IGV2ZW4gYm90 aGVyIHRvIHJlc3BlY3QgdGhpcywgDQogICAgYW5kPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+dGhpczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPmlzIA0KICAgIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBhbGwga25v dyB3aGF0IHByb2JsZW1zIA0KICAgIG11bHRpcGxlLXNvdXJjZTwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPmNvbnN0cnVjdHMgY2FuIA0KICAgIGNhdXNlIChmcm9t IExEUC9QSFAuLi4uZXJnbyBNUExTLVRQKS48L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+V2hlbiB3ZSBoYXZlIGEgY29ubmVjdGlvbiB0aGlzIHJl c3RyaWN0cyAqYWxsKiBEUCAoaWUgDQogICAgdHJhZmZpYyBhbmQgT0FNKTwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPnRvPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+c3RheSANCiAgICB3aXRoaW4gdGhlIGJvdW5kcyBv ZiB0aGUgY29ubmVjdGlvbi4gJm5ic3A7V2hpY2ggaXMgZmluZSANCiAgICB1bmRlcjwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPmRlZmVjdC1mcmVlPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Y29uZGl0aW9u cywgYnV0IGlmIHdlIGhhdmUgbGVha2luZyB0cmFmZmljIHRoZW4gdGhlIA0KICAgIGNvbnN0cmFp bmluZyBuYXR1cmU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIg TmV3Ij5vZjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnRoZSAN CiAgICBjb25uZWN0aW9uIGNvbnN0cnVjdCBpcyBicm9rZW4uICZuYnNwO0luIGEgbnV0c2hlbGwg d2hhdCB0aGlzIG1lYW5zIA0KICAgIGlzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+dGhhdDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291 cmllciBOZXciPk9BTSB0aGF0IGlzIG9mIGEgcmVxdWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fubm90 IGJlIA0KICAgIHRydXN0ZWQgaW4gY28gbW9kZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPm5ldHdvcmtzIA0KICAgIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZl Y3RzLi4uLi5pbmRlZWQsIHdoeSBzaG91bGQgYSANCiAgICBsZWFraW5nPC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+RFA8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5oYXZlIGEgDQogICAgc3ltbWV0cmljIGdvL3JldHVy biBkZWZlY3QgYmVoYXZpb3VyPy4uLi52ZXJ5IGxpa2VseSBpdCANCiAgICB3b24ndC48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5TbzwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPndoaWxzdCANCiAgICByZXF1ZXN0L3Jl c3BvbnNlIE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1vZGUgaXQgaXMgbm90IHJpZ2h0IA0KICAg IGZvcjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnRoZTwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPmNvIG1vZGUgdW5k ZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCANCiAgICBjb25kaXRpb25zLjwvRk9OVD48L1RUPjxC Uj48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5Nb3JlIGdlbmVyYWxseSANCiAgICB0 aGUgMyBtb2RlcyBhcmUgZGlmZmVyZW50IGFuZCBub3QganVzdCBpbiBPQU08L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5yZXF1aXJlbWVudHMuLi4uYnV0 IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSANCiAgICBmYXZvdXIhLi4uYXQgbGVh c3Q8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5JRUVFIGhhZCB0 aGUgDQogICAgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRoZXJuZXQgZXZlbiB0aG91Z2gg aXQgDQogICAgcmVtYWluczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291 cmllciBOZXciPmluPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ WS4xNzMxLiANCiAgICAmbmJzcDtBbmQgd2hpY2ggaXMgd2h5IEkgb2Z0ZW4gdHJvdC1vdXQgdGhl IHJhdGhlciBzaWxseSAodG8gaGF2ZSANCiAgICB0bzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPnNheTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPnRoaXMpIG9ic2VydmF0aW9uIHRoYXQgaWYgSVAgKGNsIG1vZGUpIGNv dWxkIGRvIGl0IGFsbCANCiAgICB0aGVuIHdoeSBoYXZlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+SUVURjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPmZvdW5kIGl0IA0KICAgIG5lY2Vzc2FyeSB0byBjcmVhdGUgTVBM UyAoY28tcHMpIGFuZCBHTVBMUyAoQ1AgZm9yIGNvLWNzKS4gDQogICAgJm5ic3A7VGhlPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+YW5zd2VyIGxpZXMgaW4gdGhl IA0KICAgIHBoeXNpY3MuLi5hbmQgRy44MDAgYXR0ZW1wdHMgdG8gZXhwbGFpbiB0aGF0PC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+cGh5c2ljcy4uLi5H LjgwNSBkb2VzIG5vdC48L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJD b3VyaWVyIE5ldyI+U28sIHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQuLi5wbGVhc2UgYWNjZXB0 L3Jlam9pY2UgaW4gDQogICAgdGhpcyBmYWN0IGFzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+dGhleTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPmFsbCANCiAgICBvZmZlciBzb21ldGhpbmcgZGlmZmVyZW50L2ltcG9y dGFudC4gJm5ic3A7QnV0IGRvIG5vdCBiZSBob29kd2lua2VkIA0KICAgIGJ5PC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+dGhvc2U8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij53aG8gDQogICAgcGVkZGxlIGEgc3Rvcnkg dGhhdCB0aGF0IHRyaWVzIHRvIG1ha2UgdGhlIE9BTSBvZiB0aGUgMyBtb2RlcyANCiAgICB0aGU8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5zYW1lLiANCiAgICA8 L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+cmVnYXJkcywg TmVpbCANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyAtLS0tLU9yaWdpbmFsIA0KICAgIE1lc3NhZ2UtLS0tLTwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgRnJvbTogDQogICAgbXBscy10cC1ib3Vu Y2VzQGlldGYub3JnPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyANCiAgICBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERyYWtlLCBKb2huIA0KICAgIEU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7IFNlbnQ6IDE3IEFwcmlsIDIwMDkgDQogICAgMjA6MDI8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFRvOiBCVVNJIElUQUxPOyANCiAg ICBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBDYzogPHN0MTpQZXJzb25OYW1l IA0KICAgIHc6c3Q9Im9uIj5tcGxzLXRwQGlldGYub3JnPC9zdDE6UGVyc29uTmFtZT48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFN1YmplY3Q6 IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIA0KICAgIHRyYW5zcG9ydCBw YXRoIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQog ICAgcmVxdWlyZW1lbnRzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7IA0KICAgIEl0YWxvLDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyBBcyBkZXNjcmliZWQgaW4gdGhlIE1QTFMgDQogICAgVFAgT0FNIFJlcXVpcmVt ZW50cyBJLUQsIHZpcnR1YWxseSBhbGwgb2YgdGhlPC9GT05UPjwvVFQ+PEJSPjxCUj48VFQ+PEZP TlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgT0FNIGZ1bmN0aW9ucyByZXF1aXJlIGEg cmV0dXJuIHBhdGgsIGFuZCBpbiB0aGUgDQogICAgYWJzZW5jZSBvZiBhIHJldHVybiA8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IHBhdGggDQogICAgdGhl eSBhcmUgZGlzYWJsZWQuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7IEFzIGRlc2NyaWJlZCBpbiBEYXZpZCANCiAgICBTaW5pY3JvcGUncyBtZWV0aW5nIG1p bnV0ZXMgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyANCiAgICAoaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvbWlzYy9tcGxzLWludGVyb3Av YXR0YWNobWVudC93aWtpLzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291 cmllciBOZXciPiZndDsgbWVldGluZy1ubzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgdGVzLzIwMDgxMDE1Lm1wbHMtaW50ZXJvcC1kdC1ub3Rl cy56aXApLCBpZiBJUCANCiAgICBhZGRyZXNzaW5nIGlzIHVzZWQsIGFuIDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQogICAgTVBMUyBUUCBuZXR3b3Jr IG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgZ2V0dGluZyBJUCBwYWNrZXRzIGZyb20gDQogICAgPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBkZXN0aW5hdGlv biB0byBzb3VyY2U7IA0KICAgIG5laXRoZXIgdGhlIG1pbnV0ZXMgbm9yIEkgc3RpcHVsYXRlIHRo YXQgYSA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7IGNvbnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byBpbnN0YW50aWF0ZSB0aGlzIA0K ICAgIGZvcndhcmRpbmcuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7IEFzIGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgDQogICAgcmV0dXJuIHBhdGggZm9yIHVu aWRpcmVjdGlvbmFsIExTUHMgY291bGQgYmU8L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBjaGFyYXRlcml6ZWQgYXMgdGhlIGVsZXBoYW50 IGluIHRoZSByb29tLiAmbmJzcDtJbiANCiAgICB0aGUgTVBMUyBUUCBPQU0gPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBGcmFtZXdvcmsgDQogICAgSS1E LCB1bmljYXN0IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRpbWVzIGFuZCByZXR1cm4g DQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBw YXRocyBub3QgYXQgDQogICAgYWxsLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPiZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyANCiAgICBUaGFua3MsPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgIEpvaG48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCANCiAgICBNZXNzYWdlLS0t LS08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg RnJvbTogDQogICAgQlVTSSBJVEFMTyBbbWFpbHRvOkl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQu aXRdPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyAmZ3Q7IFNlbnQ6IEZyaWRheSwgQXByaWwgMTcsIDIwMDkgMTo1OSANCiAgICBBTTwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBUbzogRHJha2Us IEpvaG4gRTsgDQogICAgQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2VyczwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBD YzogPHN0MTpQZXJzb25OYW1lIA0KICAgIHc6c3Q9Im9uIj5tcGxzLXRwQGlldGYub3JnPC9zdDE6 UGVyc29uTmFtZT48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgDQogICAgdHJhbnNwb3J0IHBhdGggPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgIHJlcXVpcmVtZW50czwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyANCiAgICA8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgSm9obiw8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQog ICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7 IEkgbWlnaHQgaGF2ZSBtaXNzZWQgDQogICAgdGhlIGFncmVlbWVudCBvZiBNUExTLVRQIGJlaW5n IGNhcGFibGUgb2YgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyAmZ3Q7IHNlbmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2VudCBvbiAN CiAgICB1bmktZGlyZWN0aW9uYWwgTFNQcy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IFRoaXMgcmVxdWlyZW1lbnQgZG9lcyANCiAgICBu b3QgYmVsb25nIHRvIHRoZSBmaXJzdCBzZXQgb2YgcmVxdWlyZW1lbnRzIDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBJVFUtVCBpcyBl eHBlY3RpbmcgdG8gYmUgbWV0IGJ5IA0KICAgIE9jdG9iZXIuPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBIb3dldmVyLCBJIHRoaW5rIHRo aXMgDQogICAgaW4gYSBwb3RlbnRpYWwgaW50ZXJlc3RpbmcgYWRkaXRpb25hbCA8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgcmVxdWly ZW1lbnQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IChhdCB3b3JzdCANCiAgICBpbiBhPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBzdWJzZXF1ZW50IA0K ICAgIHBoYXNlKS48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCB0aGlzIA0KICAgIHJlcXVpcmVtZW50IG5lZWRzIHRv IGJlIGV2YWx1YXRlZCB2ZXJzdXMgb3RoZXIgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAg ICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IG1vcmUgaW1wb3J0YW50IHJlcXVpcmVtZW50 cyAoZS5nLiB0aGUgDQogICAgcG9zc2liaWxpdHkgdG8gd29yayB3L28gSVAgPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICAmZ3Q7IGZvcndhcmRp bmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8gY29udGludWUgdG8gbW9uaXRvciB0aGUgZGF0YSAN CiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZn dDsgcGxhbmUgYWxzbyBpbiBjYXNlIG9mIA0KICAgIGZhaWx1cmVzIGFmZmVjdGluZyB0aGUgY29u dHJvbCBvciBtYW5hZ2VtZW50IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPiZndDsgJmd0OyBwbGFuZSkuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBJIGFtIG9wZW4gdG8gZGlzY3Vz cyBpdCBidXQgbm90IHN1cmUgdGhpcyBpcyANCiAgICB0aGUgcmlnaHQgdGltZSBiZWNhdXNlIDwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQogICAgJmd0 OyBJIHdpc2ggdG8gYXZvaWQgZGVsYXlpbmcgdGhlIGZpcnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24g DQogICAgc29sdXRpb24uPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyBUaGFua3MsIA0KICAgIEl0YWxvPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwg DQogICAgTWVzc2FnZS0tLS0tPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3Jn PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm Z3Q7ICZndDsgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KICAgIEJlaGFs ZiBPZiBEcmFrZSwgSm9obiBFPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyANCiAgICAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5 IDg6MDAgUE08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgJmd0OyBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gDQogICAg Vmlzc2VyczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsg Jmd0OyAmZ3Q7IENjOiANCiAgICA8c3QxOlBlcnNvbk5hbWUgDQogICAgdzpzdD0ib24iPm1wbHMt dHBAaWV0Zi5vcmc8L3N0MTpQZXJzb25OYW1lPjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQog ICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCANCiAgICBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIDwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7 IHJlcXVpcmVtZW50czwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IEF0IHRoZSBtZWV0aW5nIGxhc3QgZmFsbCBh dCBKdW5pcGVyIGluIA0KICAgIDxzdDE6U3RhdGUgdzpzdD0ib24iPjxzdDE6cGxhY2UgDQogICAg dzpzdD0ib24iPk1hc3NhY2h1c2V0dHM8L3N0MTpwbGFjZT48L3N0MTpTdGF0ZT4sIEk8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgdGhp bmsgaXQgd2FzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyAmZ3Q7ICZndDsgYWdyZWVkIHRoYXQgYW4gTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRv IA0KICAgIGhhdmUgYSBmb3J3YXJkaW5nPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgIGNhcGFiaWxpdHk8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyBmb3IgDQogICAgbWFuYWdl bWVudCwgY29udHJvbCwgYW5kIE9BTSBwYWNrZXRzIChlLmcuLCBzZW5kaW5nPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IHJlcGxpZXMg dG8gT0FNPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgcmVxdWVzdHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQcykgDQog ICAgZXZlbiBpZiBpdCBkb2VzIG5vdDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPiZndDsgJmd0OyANCiAgICBoYXZlIGFuIElQPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgZm9yd2FyZGluZyBk YXRhIHBsYW5lLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZn dDsgJmd0OyANCiAgICAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAg ICZndDsgJmd0OyAmZ3Q7IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluPC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAg W21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV08L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA5OjU3IA0KICAgIEFNPC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogDQog ICAgTWFhcnRlbiBWaXNzZXJzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgJmd0OyBDYzogPHN0MTpQZXJzb25OYW1lIA0KICAg IHc6c3Q9Im9uIj5tcGxzLXRwQGlldGYub3JnPC9zdDE6UGVyc29uTmFtZT48L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCANCiAgICBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IE1hYXJ0ZW4sPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJdCBzZWVtcyB0aGF0IHlvdSd2ZSBqdXN0 IChpbXBsaWNpdGx5IA0KICAgIGFuZCwgcHJvYmFibHksPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgJmd0OyBpbmFkdmVydGVu dGx5KSBzdGF0ZWQgdGhlIGZvbGxvd2luZzo8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAg IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtNUExTLVRQIE9BTSB3aWxsIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3BiYWNrIA0K ICAgIGZ1bmN0aW9uPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7IChhbmQgDQogICAgZmF1bHQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIGxvY2FsaXphdGlvbiB3aGlj aCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uICkgZm9yPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IHVuaWRpcmVjdGlvbmFsIFAyTVA8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGFuZCBQMlAgDQogICAgcGF0aHMuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHRo aXMgDQogICAgc3RhdGVtZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8gYW5kIEZXSVcpPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyByYWlzZXMg YSB2YWxpZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7ICZndDsgcXVlc3Rpb246PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SXMgTVBMUy1UUCBhbiBhcHByb3ByaWF0ZSBzb2x1dGlvbiBmb3IgDQogICAg dGhlc2U8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IHR5 cGVzIG9mIA0KICAgIHRyYW5zcG9ydDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgcGF0aHM/PC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEZvciB0aGUgDQogICAgcmVmZXJlbmNlLCBJUC9NUExTIHByb3ZpZGVzIHRoaXMga2lu ZCBvZjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZn dDsgJmd0OyBmdW5jdGlvbmFsaXR5IHRvZGF5PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAg ICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBmb3IgKHVuaWRpcmVjdGlv bmFsIC0gYnV0IGl0IGRvZXMgbm90IA0KICAgIGtub3cgYW55IG90aGVyPC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IHR5cGUpIA0KICAgIFAyUCBM U1BzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyBhcyANCiAgICBkZXNjcmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0ZW5z aW9uIHRvIFAyTVAgTFNQcyBzZWVtcyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIGVhc3kuLi48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsg Jmd0OyAmZ3Q7ICZndDsgDQogICAgJm5ic3A7PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIFJl Z2FyZHMsPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAmbmJzcDsgJm5ic3A7U2Fz aGE8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg DQogICAgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZy b206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgICBbbXBscy10cC1ib3VuY2VzQGlldGYu b3JnXTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQog ICAgJmd0OyBPbiBCZWhhbGY8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgJmd0OyANCiAgICAmZ3Q7IE9mIE1hYXJ0ZW4gVmlzc2VycyBbPHN0MTpQ ZXJzb25OYW1lIA0KICAgIHc6c3Q9Im9uIj5tYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbTwvc3Qx OlBlcnNvbk5hbWU+XTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5 IDM6MjQgDQogICAgUE08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiANCiAgICAnPHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9u Ij5BZHJpYW4gDQogICAgRmFycmVsPC9zdDE6UGVyc29uTmFtZT4nPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICAmZ3Q7ICZndDsgJmd0OyBDYzog PHN0MTpQZXJzb25OYW1lIA0KICAgIHc6c3Q9Im9uIj5tcGxzLXRwQGlldGYub3JnPC9zdDE6UGVy c29uTmFtZT48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCAN CiAgICBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1l bnRzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpw bGFjZSANCiAgICB3OnN0PSJvbiI+QWRyaWFuPC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT4sPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IA0KICAgICZsdDtxdW90ZSZndDs8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyANCiAg ICAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIGludGVybWVkaWF0ZSBub2Rl cyAoaW5jbHVkaW5nIE1FUHMsIA0KICAgIE1JUHMgYW5kPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICBvdGhlciBpbnRl cm5hbDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0 OyAmZ3Q7IA0KICAgICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25z IGFzIGFwcHJvcHJpYXRlKSBvZiBhIA0KICAgIGNvLXJvdXRlZDwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHBhdGggYXQgZWFjaCAoc3ViLSlsYXllciBNVVNUIA0KICAgIGJlIGF3YXJlIG9mIHRoZSBw YWlyaW5nPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAN CiAgICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGlv bnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIA0KICAgIHRoZSBiYWNrd2FyZDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAg ZGlyZWN0aW9ucyBvZiB0aGF0PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyAmZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB0cmFuc3BvcnQgDQogICAgcGF0aC48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICZndDsmZ3Q7ICZsdDtlbmQg cXVvdGUmZ3Q7PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyANCiAgICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5v IHdheSB0aGlzIGlzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gDQogICAgVGhhdDwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IGlzLCB0 aGVyZSANCiAgICBpczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAqbm90aGluZyogdGhhdCBjYW4gYmUgb2Jz ZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCANCiAgICBvZjwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IHZpZXcgDQogICAgdGhhdDwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyANCiAgICByZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVu dC48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291 cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBj b3JyZWN0LiBJdCANCiAgICBpcyB2ZXJ5IG11Y2g8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IG9ic2VydmFibGUgDQogICAgaWY8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgDQog ICAgcmVxdWlyZW1lbnQgaXMgbWV0IGZyb20gYSBibGFjayBib3ggcG9pbnQgb2Ygdmlldy48L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFRoZSBNSVAgZnVuY3Rpb25zIGNhbiBvbmx5IHBlcmZvcm0gDQogICAgdGhlIExv b3BiYWNrIHdoZW4gdGhlcmUgaXMgYSA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCANCiAgICBwYXRoLiBUaGUgTVBMUy1UUCBMQk0gcGFja2V0IDwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7 ICZndDsgcmVjZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUgDQogICAgcmV0dXJuZWQgKGFzIExC UjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAm Z3Q7IA0KICAgICZndDsgcGFja2V0KSB0byB0aGUgb3JpZ2luYXRpbmcgTUVQIGZ1bmN0aW9uIHZp YSB0aGUgDQogICAgb3RoZXI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgZGlyZWN0aW9uIA0KICAgIG9mPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgDQogICAgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoaXMgb3RoZXI8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IGRpcmVjdGlvbjwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAm Z3Q7ICZndDsgd291bGQgbm90IGJlIGF2YWlsYWJsZSBpbiBhbiANCiAgICBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgcGF0aC4uLiBhbmQgdGh1cyB0aGUg bG9vcGJhY2sgDQogICAgdGVzdDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7IHdvdWxkIA0KICAgIGZhaWwuPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IFNpbWlsYXJseSwgDQogICAgd2hlbiB3ZSBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1v bml0b3IgYTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyBzZWdtZW50LCB0aGVuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIGlzIHBvc3NpYmxlIGlu IGEgY28tcm91dGVkIGJpZGlyIA0KICAgIHRyYW5zcG9ydCBwYXRoPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBidXQgbm90IGluIA0KICAgIGE8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGFzc29jaWF0ZWQgDQogICAgYmlkaXIgdHJhbnNwb3J0IHBhdGguIEluIHRoZSBmaXJzdCBjYXNl IHRoZSBUQ00gTUVQIA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgU291cmNlIGFuZCANCiAgICBTaW5rIGZ1bmN0aW9u cyBhcmUgY28tbG9jYXRlZCBhbmQgY2FuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBleGNoYW5nZSB3aGF0IGlzPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBjYWxs ZWQgInJlbW90ZSBpbmZvcm1hdGlvbiIgd2hpY2ggaXMgDQogICAgbmVjZXNzYXJ5IGZvciBwZXJm b3JtYW5jZSA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 IA0KICAgICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JpbmcuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICAmZ3Q7ICZndDsgJmd0OyBJbiB0aGUgbGF0 dGVyIGNhc2UgdGhlIFRDTSBNRVAgU291cmNlIGFuZCBTaW5rIA0KICAgIGZ1bmN0aW9uczwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBhcmUgaW4g ZS5nLiANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IGRpZmZlcmVudCANCiAgICBub2RlcyBpbiB0aGUgbmV0d29yayBh bmQgVENNIHdvdWxkIG5vdCBiZSBhYmxlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IHRvIHByb3ZpZGU8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBlcmZv cm1hbmNlIA0KICAgIG1vbml0b3JpbmcuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIA0K ICAgIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRpbmcgTUVQcyw8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg Jmd0OyBNSVBzIGFuZCBvdGhlcjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50ZXJuYWw8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgDQogICAgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0 IGRvZXMgbm90PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhZGQgdG8gIlRoZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRl cm1lZGlhdGUgDQogICAgbm9kZXMuIjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZb3VyIA0KICAgIHVu ZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIFRoaXMgdGV4dCBtdXN0IG5vdCBiZTwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBkZWxl dGVkIGF0PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhbGwuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg QWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIA0KICAgIGFib3V0IHRoaXMgcGVyc2lzdGVudDwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyANCiAg ICAmZ3Q7IGluc2lzdGVuY2Ugb24gdGhlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgICZndDsgJmd0OyBpbmNsdXNpb248L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgJmd0OyAm Z3Q7ICZndDsgb2YgIlRhbmRlbSBDb25uZWN0aW9uLiIgVGhlIGRlZmluaXRpb24gd2l0aGluIHRo ZSBJVFUtVCANCiAgICBvZjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyANCiAgICB0ZXJtPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg IGlzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyANCiAgICBwb29ybHk8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgc3BlY2lmaWVkIGFuZCBj b21lcyBmcm9tIHRoZSBtb25pdG9yaW5nIG9mIGEgcGF0aCB0aGF0IA0KICAgIGlzPC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBw YXJhbGxlbCANCiAgICAoaS5lLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgdGFuZGVtKTwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAg ICB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIA0K ICAgIFRDPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBzZWVtcyB0byANCiAgICBiZSBhdDwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgdmFyaWFuY2Us PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyANCiAgICAmZ3Q7IGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBp biBiYW5kLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7ICZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJIGRvbid0IHVuZGVyc3RhbmQgd2hl cmUgeW91ciANCiAgICBpbnRlcnByZXRhdGlvbiBvZiB0YW5kZW08L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgY29ubmVjdGlvbiBpczwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyANCiAg ICAmZ3Q7ICZndDsgZGVzY3JpYmVkIGluIElUVS1UIHJlY29tbWVuZGF0aW9ucy4gSS5lLiAiZnJv bSANCiAgICB0aGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZndDsgbW9uaXRvcmluZyBvZiANCiAgICBhPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRoIHRoYXQgDQogICAgaXMg cGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIDwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZn dDsgbW9uaXRvcmVkLiI/PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIGEgIm5l dHdvcmsgY29ubmVjdGlvbiIgYW5kIA0KICAgIHRoaXMgbmV0d29yazwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyANCiAgICBjb25uZWN0aW9uIGlz IGEgc2V0PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm Z3Q7IA0KICAgICZndDsgJmd0OyBvZiBpbnRlcmNvbm5lY3RlZCAibGluayBjb25uZWN0aW9ucyIg YW5kIA0KICAgICJtYXRyaXg8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7IGNvbm5lY3Rpb25zIi4gDQogICAgQTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgc3Vic2V0IG9mIA0KICAgIHRo b3NlIGludGVyY29ubmVjdGVkIGxpbmsgY29ubmVjdGlvbnMgYW5kIG1hdHJpeCA8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IGNvbm5lY3Rpb25zIGNhbiBiZSBtb25pdG9yZWQgYW5kIGlzIA0KICAgIHRoZW4gcmVmZXJy ZWQgdG8gYXM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 IGEgDQogICAgInRhbmRlbTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgY29ubmVjdGlvbiIuIFRoZXJlIGlzIG5vICJw YXRoIHRoYXQgaXMgcGFyYWxsZWwgdG8gDQogICAgdGhlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IGRhdGEgcGF0aCIuIA0KICAgIDwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsg VGhlcmUgaXMgDQogICAgb25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBpbnNpZGUgdGhlIGRh dGE8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 IHBhdGggYnkgdGhlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUQ00gTUVQX1NvIGZ1bmN0aW9uIGFuZCB0aGlzIE9B TSBpcyANCiAgICBleHRyYWN0ZWQgZnJvbSB0aGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgZGF0YSBwYXRoIGJ5PC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAg ICB0aGUgVENNIE1FUF9TayBmdW5jdGlvbi48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IA0KICAgICZndDsgUmVn YXJkcyw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZn dDsgJmd0OyANCiAgICAmZ3Q7IE1hYXJ0ZW48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQogICAgJmd0OyAmZ3Q7ICZndDsgRnJvbTog bXBscy10cC1ib3VuY2VzQGlldGYub3JnPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBbbWFpbHRvOm1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZ10gT24gDQogICAgQmVoYWxmIE9mIDxzdDE6UGVyc29uTmFtZSB3OnN0PSJv biI+QWRyaWFuIA0KICAgIEZhcnJlbDwvc3QxOlBlcnNvbk5hbWU+PC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICAmZ3Q7ICZndDsgJmd0OyBTZW50 OiBkb25kZXJkYWcgMTYgYXByaWwgMjAwOSAxMTo1OTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg DQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgVG86IEFsZXhhbmRl ciBWYWluc2h0ZWluOyANCiAgICBiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbTwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7 ICZndDsgQ2M6IEJVU0kgSVRBTE87IDxzdDE6UGVyc29uTmFtZSANCiAgICB3OnN0PSJvbiI+bXBs cy10cEBpZXRmLm9yZzwvc3QxOlBlcnNvbk5hbWU+PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTog W21wbHMtdHBdIEFzc29jaWF0ZWQgDQogICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCA8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBT YXNoYSw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBVbmZvcnR1bmF0ZWx5IEkgY2Fu bm90IGZ1bGx5IA0KICAgIGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQ6PC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICAmZ3Q7ICZndDsgJmd0OyAm Z3Q7PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7 IA0KICAgICZndDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyBGcm9tIHRoZSBwb2ludCBvZiANCiAgICB2aWV3IG9mIGhhcmR3YXJlLCBjby1y b3V0ZWQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0K ICAgICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIExTUHM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyBhcmUgYSBzcGVjaWFsIGNhc2UgDQogICAgb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIExTUHMuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgDQogICAgcXVvdGUmZ3Q7PC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyANCiAgICAmZ3Q7PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIFRoaXMgc3RhdGVtZW50IHdvdWxkIGJlIG9i dmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0IG5vdCANCiAgICBmb3I8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIFJlcXVp cmVtZW50PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyANCiAgICAmZ3Q7IDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCByZXF1aXJl bWVudHMgZHJhZnQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgT0suIEdvdCBpdC48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0IHdoYXQgaXMgdGhpcyBkb2luZyBpbiB0aGUgZGF0YSAN CiAgICBwbGFuZSByZXF1aXJlbWVudHMgc2VjdGlvbj88L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IA0KICAgICZn dDsgSW4gZmFjdCwgd2hhdCBpcyB0aGlzIHJlcXVpcmVtZW50IGFjdHVhbGx5IA0KICAgIHNheWlu Zz88L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAmbHQ7cXVvdGUmZ3Q7PC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5j bHVkaW5nIE1FUHMsIE1JUHMgDQogICAgYW5kPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgb3RoZXIgDQogICAgaW50ZXJuYWw8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IA0KICAgICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRl KSBvZiBhIA0KICAgIGNvLXJvdXRlZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAg ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGF0aCBhdCBlYWNoIChz dWItKWxheWVyIE1VU1QgYmUgDQogICAgYXdhcmUgb2YgdGhlIHBhaXJpbmc8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFu ZCB0aGUgDQogICAgYmFja3dhcmQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIGRpcmVjdGlvbnMgb2YgdGhhdDwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyANCiAgICAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFuc3BvcnQgcGF0aC48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJmx0O2VuZCANCiAgICBxdW90ZSZndDs8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsg VGhlcmUgaXMgbm8gDQogICAgd2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiBU aGF0PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyAmZ3Q7IGlzLCB0aGVyZSBpczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0i Q291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9i c2VydmVkIGZyb20gYSANCiAgICBibGFjayBib3ggcG9pbnQgb2Y8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgdmlldyB0aGF0PC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyANCiAgICByZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmVmb3JlIGl0IGNvdWxkIGJlIGFzc3VtZWQgdGhhdCAN CiAgICB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBieSA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7IGNvbmZpZ3VyaW5n IHNvbWUgZGF0YSBwbGFuZSBkYXRhYmFzZSBjb21wb25lbnQgdGhyb3VnaCB0aGUgDQogICAgPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBtYW5hZ2VtZW50IA0KICAgIHBsYW5lLiBUaGUgZGF0YWJhc2UgY29tcG9uZW50IGlzIG5v dCB1c2VkPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyBmb3IgYW55dGhpbmc8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGV4Y2VwdCB0byBzYXRpc2Z5IHRoaXMgcmVx dWlyZW1lbnQgDQogICAgZm9yICJhd2FyZW5lc3MiLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IA0KICAgICZndDsgPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBCZW4h IA0KICAgIENhbiB3ZSBwbGVhc2UgdHJ5IHRvIHJld3JpdGUgdGhpcyByZXF1aXJlbWVudCBpbiB0 ZXJtcyBvZiANCiAgICA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIGJlaGF2aW9yPzwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFBsZWFzZSANCiAgICBub3RlIHRoYXQgUmVxdWlyZW1lbnQgMzQgaXMgdGhlIE9OTFkg aXRlbSBpbiB0aGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxpc3QgdGhhdCBpczwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBz cGVjaWZpYyBmb3IgY28tcm91dGVkIA0KICAgIGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBwYWly aW5nPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXQgZW5kIHBv aW50cyBmb3IgY28tcm91dGVkIGFuZCANCiAgICBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWw8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsg Jmd0OyBwYXRocyBhcmU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgDQogICAgJmd0OyAmZ3Q7ICZndDsgZXhhY3RseSB0aGUgc2FtZSBldmVuIGlm IHRoZXkgYXBwZWFyIGluIHR3byANCiAgICBkaWZmZXJlbnQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyBpdGVtcyANCiAgICBpbiB0aGU8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogICAgcmVxdWlyZW1lbnRzJyBsaXN0KS48L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgJmd0OyAmZ3Q7ICZndDsg SW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlvbiANCiAgICBv ZjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQogICAg Y28tcm91dGVkPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUg dm9pZCBvZiBhbnkgZGF0YSBwbGFuZSANCiAgICBjb250ZW50LjwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgJmd0Ozwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyANCiAgICBUaGUgc29tZXdoYXQgdmFndWUgc2NvcGUgb2YgdGhpcyByZXF1aXJl bWVudCAoIm90aGVyIGludGVybmFsIA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICBmdW5jdGlvbnMg YXMgYXBwcm9wcmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgDQogICAgSFc8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHN1cHBvcnQgDQogICAgb2YgdGhlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIHBhaXJpbmcgYXdhcmVuZXNz IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCANCiAgICBpdC48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsg Jmd0OyAmZ3Q7ICZndDsgVGhlIA0KICAgIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQg IihpbmNsdWRpbmcgTUVQcyw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgTUlQcyBhbmQgb3RoZXI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGludGVybmFs IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkiIA0KICAgIHNob3VsZCBiZSBkZWxldGVkLiBJdDwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyANCiAg ICBkb2VzIG5vdDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZn dDsgJmd0OyAmZ3Q7ICZndDsgYWRkIA0KICAgIHRvICJUaGUgaW50ZXJtZWRpYXRlIG5vZGVzLiI8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZm9sbG93aW5nIHRleHQgaW4gdGhl IGRyYWZ0IA0KICAgIGluY3JlYXNlcyB0aGlzIHN1c3BpY2lvbjo8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7ICZndDs8 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQog ICAgJmd0OyAmZ3Q7ICZndDsgJmx0O3F1b3RlJmd0OzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg DQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg VGFuZGVtIENvbm5lY3Rpb246IEEgDQogICAgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgYXJi aXRyYXJ5IHBhcnQgb2YgYTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgDQogICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgdHJhbnNwb3J0IHBhdGgg dGhhdCBjYW4gYmUgbW9uaXRvcmVkICh2aWEgDQogICAgT0FNKTwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgaW5kZXBl bmRlbnRseSBmcm9tIHRoZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyANCiAgICAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgZW5kLXRvLWVuZCBtb25p dG9yaW5nIChPQU0pLiAmbmJzcDtJdCBtYXkgYmUgYSANCiAgICBtb25pdG9yZWQ8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgc2VnbWVudCBvciAN CiAgICBhPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICZuYnNwOyBtb25pdG9yZWQgY29uY2F0ZW5hdGVkIHNl Z21lbnQgb2YgYSB0cmFuc3BvcnQgcGF0aC4gDQogICAgJm5ic3A7PC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IFRoZSANCiAgICB0YW5kZW08L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgDQogICAgJm5ic3A7IGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0aGUgZm9y d2FyZGluZyBlbmdpbmUocykgDQogICAgb2Y8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSANCiAgICBub2RlKHMpPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IA0KICAgICZuYnNwOyBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBvciBjb25j YXRlbmF0ZWQgDQogICAgc2VnbWVudC48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICZndDsgJmx0O2VuZCBxdW90ZSZn dDs8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsg DQogICAgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVw IGFib3V0IHRoaXMgcGVyc2lzdGVudDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyBpbnNpc3RlbmNlIG9uIHRoZTwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsg aW5jbHVzaW9uIG9mICJUYW5kZW0gQ29ubmVjdGlvbi4iIFRoZSANCiAgICBkZWZpbml0aW9uIHdp dGhpbjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0 OyB0aGUgDQogICAgSVRVLVQgb2Y8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIHRoaXMgdGVybSBpcyBwb29ybHkgc3Bl Y2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgbW9uaXRvcmluZyBvZiBhPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRo IHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSANCiAgICB0byB0aGUgZGF0YSBwYXRoIGJl aW5nIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQog ICAgJmd0OyAmZ3Q7ICZndDsgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24gb2YgVEMgc2VlbXMg dG8gYmUgYXQgDQogICAgdmFyaWFuY2UsPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IGFuZCANCiAgICB3b3VsZDwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgYmUgaWYgDQogICAg dGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBEb2Vzbid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgDQogICAgc291bmQgbGlrZSBoYXJkd2Fy ZSB0byB5b3U/PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyANCiAgICAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyANCiAgICAmZ3Q7IFllcywgYnV0IHNvIHdoYXQ/PC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAg ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICZndDsgSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhh dCBuZWl0aGVyIHRoZSANCiAgICBNUExTLVRQPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgUmVxdWlyZW1lbnRzIGRyYWZ0PC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAg ICZndDsgJmd0OyAmZ3Q7IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZTwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQog ICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgIChodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVt ZW48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgdHMtMDEudHh0KSBjb250YWluIGFueSANCiAgICByZXF1aXJl bWVudHMgZGVhbGluZyB3aXRoIHRhbmRlbTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IGNvbm5lY3Rpb25zLjwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSANCiAg ICBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgT0FNPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IEZyYW1ld29yazwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBkcmFmdDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tZnI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIGFt ZXdvcmstMDAudHh0PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgDQogICAgJmd0OyApLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICBS aWdodC48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IExldCdzIA0KICAgIGp1c3QgZ2V0IHJpZCBvZiBhbiB1bm5lY2Vzc2FyeSB0 ZXJtIGFuZCBicmluZyBhbGw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7IHRoZSBJLURzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRvIGxpbmUuPC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGJvdHRvbSBsaW5lLCBJTUhPLCBpcyB0aGF0IA0K ICAgIHNvbWUgY2xhcml0eSByZWdhcmRpbmc8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgJmd0OyBjby1yb3V0ZWQgdnMuPC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgICZndDsg Jmd0OyAmZ3Q7IGFzc29jaWF0ZWQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBwYXRo cyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdheSB0byANCiAgICBwcm92aWRlPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGF0 IA0KICAgIGNvdWxkPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIGJlIGJ5IGV4cGxpY2l0bHkgbGltaXRpbmcg UmVxdWlyZW1lbnQgMzQgdG8gDQogICAgc3BlY2lmaWM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyANCiAgICBmdW5jdGlvbmFsaXR5Ljwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7 IA0KICAgICZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICBBZ3JlZWQuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxz dDE6Q2l0eSANCiAgICB3OnN0PSJvbiI+PHN0MTpwbGFjZSANCiAgICB3OnN0PSJvbiI+QWRyaWFu PC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogPHN0MTpQZXJzb25O YW1lIA0KICAgIHc6c3Q9Im9uIj5BZHJpYW4gRmFycmVsPC9zdDE6UGVyc29uTmFtZT4gDQogICAg W2FkcmlhbkBvbGRkb2cuY28udWtdPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwg MTYsIDIwMDkgMTI6MTMgQU08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsg TG91IEJlcmdlcjsgDQogICAgQlVTSSBJVEFMTzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgQ2M6IDxzdDE6UGVyc29u TmFtZSANCiAgICB3OnN0PSJvbiI+bXBscy10cEBpZXRmLm9yZzwvc3QxOlBlcnNvbk5hbWU+PC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgDQogICAgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBTYXNoYSw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsg Tm90IHJlYWxseSBzdXJlIHdoZXRoZXIgeW91IGFyZSANCiAgICBtaXNyZXByZXNlbnRpbmcgYW55 b25lLCBidXQuLi48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAxLiBNeSByZWFkaW5n IG9mICZuYnNwO29uZSBvZiANCiAgICBCZW4ncyAmbmJzcDttZXNzYWdlcyBpcyB0aGF0IGFzc29j aWF0ZWQgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBvbmx5 IA0KICAgIHR5cGVzIG9mIHBhdGhzIHRoYXQgY2FuIGJlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICAmZ3Q7ICZndDsgJmd0OyBjcmVhdGVkIGlu PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCiAgICAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBleGlzdGluZyBuZXR3b3JrczsgInRydWUiIGNvLXJvdXRl ZCBiaWRpcmVjdGlvbmFsIA0KICAgIHBhdGhzPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB3aWxsIA0KICAgIGhhdmU8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgdG8gDQogICAgd2FpdCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVudCBiZWNvbWVz IA0KICAgIGF2YWlsYWJsZS48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyANCiAgICBjbGVh cmx5IG5vbnNlbnNlITwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7IA0KICAgICZndDsgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJk d2FyZSwgY28tcm91dGVkPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQcyBhcmU8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGEg c3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgDQogICAgYmlkaXJlY3Rpb25hbCBMU1BzLjwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyANCiAgICAm Z3Q7ICZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyANCiAgICBJZiB5b3UgY2FuIHNldCB1cCB0d28gdW5pZGlyZWN0aW9u YWwgTFNQcyAoZS5nLiB1c2luZyANCiAgICB0aGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgbWFuYWdlbWVudDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAg cGxhbmUpIHlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNvLXJvdXRlZDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0 aW9uYWwgDQogICAgTFNQLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgDQogICAgc2hp cHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0ZWQ8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IGJpZGlyZWN0aW9uYWw8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IExTUHMgdXNpbmcgdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIA0KICAgIGVpdGhlciB1 c2UgdGhlIEdNUExTPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7IA0KICAgICh3aGljaCBpczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0i Q291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgY2xlYW5lcikgb3Igbm9uLXN0 YW5kYXJkIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2ggDQogICAgaXM8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgbWVzc3kgDQogICAgYnV0 PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyANCiAgICBmdW5jdGlvbmFsKS48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0IChvZiAN CiAgICBjb3Vyc2UpIHRoZSBtYW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wgcGxhbmU8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgc29s dXRpb25zIGhhdmU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5vdGhpbmcgdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkg b2YgDQogICAgZXF1aXBtZW50IGFzIHRoZXk8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IGFyZSANCiAgICBzb2Z0d2FyZTwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgc29sdXRp b25zLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogICAgPC9GT05UPjwvVFQ+PC9TUEFOPjwvRk9OVD48QlI+PFRUPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIuIE15IHJlYWRpbmcgb2Ygb25lIG9mIA0K ICAgIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWw8L1NQQU4+PC9GT05UPjwvVFQ+ PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PEJSPjxUVD48Rk9O VCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBkcml2ZXIgZm9y PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIA0KICAgIG1h eSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCAN CiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRyYW5zcG9y dCBuZXR3b3JrcyByYXRoZXIgdGhhbiANCiAgICBhbnkgc3BlY2lmaWMgYmVuZWZpdC48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgDQogICAgJmd0 OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsg Jmd0OyAmZ3Q7ICZndDsgDQogICAgSXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUg TVBMUy1UUCANCiAgICByZXF1aXJlbWVudHM/PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgJmd0OyBXaGljaCBpcyBub3QgdG8g c2F5IGl0IGlzIGEgYmFkIHRoaW5nLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBIGxhcmdl IGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIA0KICAgIHRoZSBwYWNrZXQgbmV0d29yazwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyB0aGUg DQogICAgbG9vayw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IGZlZWwsIA0KICAgIGFuZCBiZWhhdmlvcmFsIGNoYXJhY3Rlcmlz dGljcyBvZiBhICJsZWdhY3kiPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0cmFuc3BvcnQgDQogICAgbmV0d29yay48 L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBCYXNlZCANCiAgICBvbiB0aGVzZSBvYnNlcnZhdGlv bnMsIEknZCBndWVzcyAoRldJVykgdGhhdDo8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAg IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKiBhc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgcGF0aHMgDQogICAgYXJlLCBhdCBsZWFzdCBmb3IgdGhlIHRpbWU8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2JlaW5nLCB0aGUgbW9zdCBpbXBvcnRhbnQgdHlw ZSBvZiANCiAgICBiaWRpcmVjdGlvbmFsIHBhdGhzIGluPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtNUExTLVRQPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCBp cyB3cm9uZyBib3RoIGdpdmVuIG15IA0KICAgIHN0YXRlbWVudCBhYm92ZSwgYW5kPC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7IA0KICAgIGdpdmVu IHRoYXQ8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IA0KICAgIG90aGVyIHVwZ3JhZGVzIHRvIGV4aXN0aW5nIE1QTFMgc29sdXRp b25zIHdpbGwgYmU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7IG5lZWRlZCB0byByZWFjaDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIGZ1bGwgZnVuY3Rpb24g bGV2ZWwgb2YgDQogICAgTVBMUy1UUC48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqIHRoZXkg DQogICAgaGFkIGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUgb2Y8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgYmlk aXJlY3Rpb25hbDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgcGF0aHMgaW4gJm5ic3A7cmVhbCAN CiAgICBkZXBsb3ltZW50cy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBkb24ndCBzZWUgDQogICAg d2hhdCB0aGF0IGZvbGxvd3MgZnJvbS48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7IA0KICAgICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IA0KICAgICZndDsgQ2hlZXJz LDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAm Z3Q7ICZndDsgDQogICAgPHN0MTpDaXR5IHc6c3Q9Im9uIj48c3QxOnBsYWNlIA0KICAgIHc6c3Q9 Im9uIj5BZHJpYW48L3N0MTpwbGFjZT48L3N0MTpDaXR5PjwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgPC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsg Jmd0OyAmZ3Q7ICZndDsgbXBscy10cCBtYWlsaW5nIA0KICAgIGxpc3Q8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgIDxz dDE6UGVyc29uTmFtZSANCiAgICB3OnN0PSJvbiI+bXBscy10cEBpZXRmLm9yZzwvc3QxOlBlcnNv bk5hbWU+PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMtdHA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQog ICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1wbHMt dHAgbWFpbGluZyANCiAgICBsaXN0PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICA8c3QxOlBlcnNvbk5hbWUgDQogICAg dzpzdD0ib24iPm1wbHMtdHBAaWV0Zi5vcmc8L3N0MTpQZXJzb25OYW1lPjwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7ICZndDsg DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IA0KICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAg ICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmZ3Q7ICZndDsgbXBscy10cCBtYWlsaW5nIA0KICAg IGxpc3Q8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZn dDsgJmd0OyANCiAgICA8c3QxOlBlcnNvbk5hbWUgDQogICAgdzpzdD0ib24iPm1wbHMtdHBAaWV0 Zi5vcmc8L3N0MTpQZXJzb25OYW1lPjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IA0KICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscy10cDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAg ZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyAmZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBtcGxzLXRwIG1haWxpbmcgbGlzdDwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgPHN0MTpQ ZXJzb25OYW1lIA0KICAgIHc6c3Q9Im9uIj5tcGxzLXRwQGlldGYub3JnPC9zdDE6UGVyc29uTmFt ZT48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 IA0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij5tcGxzLXRwIG1haWxpbmcgbGlzdDwvRk9OVD48 L1RUPjxCUj48c3QxOlBlcnNvbk5hbWUgDQogICAgdzpzdD0ib24iPjxUVD48Rk9OVCANCiAgICBm YWNlPSJDb3VyaWVyIE5ldyI+bXBscy10cEBpZXRmLm9yZzwvRk9OVD48L1RUPjwvc3QxOlBlcnNv bk5hbWU+PEJSPjxUVD48Rk9OVCANCiAgICBmYWNlPSJDb3VyaWVyIE5ldyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPC9GT05UPjwvVFQ+PEJSPjxCUj48L1NQ QU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjxQUkU+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNp emU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1BSRT48UFJFPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+WlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+VGhp cyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRl ZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZu YnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZu YnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4m bmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0 b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJz cDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7 dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUFJFPjxQUkU+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNp emU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5UaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS48 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QUkU+PC9CTE9DS1FVT1RFPjwvRElWPjwvQkxPQ0tR VU9URT48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C9C2A1.3F4C919A-- From rahul@juniper.net Tue Apr 21 23:49:27 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133423A6A0B for ; Tue, 21 Apr 2009 23:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSc5FPgVhmke for ; Tue, 21 Apr 2009 23:49:26 -0700 (PDT) Received: from chip3og52.obsmtp.com (chip3og52.obsmtp.com [64.18.14.169]) by core3.amsl.com (Postfix) with ESMTP id 13FFE3A69A8 for ; Tue, 21 Apr 2009 23:49:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob52.postini.com ([64.18.6.12]) with SMTP ID DSNKSe6+PRrERbsb6Kv5VN8KrZ3dcnhOO0Dc@postini.com; Tue, 21 Apr 2009 23:50:43 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 21 Apr 2009 23:46:16 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 23:46:16 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 23:46:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 23:46:15 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3M6kFM99134; Tue, 21 Apr 2009 23:46:15 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Tue, 21 Apr 2009 23:46:15 -0700 From: Rahul Aggarwal To: Adrian Farrel In-Reply-To: <0CC61AE039C84BA687F43B010574D528@your029b8cecfe> Message-ID: <20090421234553.W19546@sapphire.juniper.net> References: <6FD21B53861BF44AA90A288402036AB4021B1A70@FRVELSMBS21.ad2.ad.alcatel.com> <6FD21B53861BF44AA90A288402036AB4021B1E19@FRVELSMBS21.ad2.ad.alcatel.com> <0CC61AE039C84BA687F43B010574D528@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-OriginalArrivalTime: 22 Apr 2009 06:46:15.0430 (UTC) FILETIME=[0864F260:01C9C316] Cc: BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 06:49:27 -0000 Hi Adrian, Completely agreed. rahul On Tue, 21 Apr 2009, Adrian Farrel wrote: > Italo, > > Well, you sent me back to look at MPLS-TP_overview-22.ppt > > > 3) Keep the TCM solution description, as per JWT agreement, in the > > MPLS-TP OAM Framework > > TCM is mentioned in three ways in the slide set, as far as I can see. > 1. In the context of describing the requirements > 2. In reference to how solutions are achieved in TDM and Ethernet > 3. In example solutions > > I assume it is the third of these to which you refer. > > I would like to remind you that the scope and objectives of the JWT was not > to design solutions, but to demonstrate that a solution was achievable. > There was never any commitment that the solution ideas floated in the JWT > would constrain the solutions work entered into by the IETF with full input > from all ITU-T participants. Indeed that would have been foolish since the > JWT was operating in a hurry and was not going into technical details. > > If a technical solution is reached with consensus and matches what the JWT > considered, that will be fine. But we must not blindly follow the JWT > solutions work or use any solutions ideas in the JWT report as a > prerequisite. All technical work must stand on solid technical ground. > > Thank you. > Adrian > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From xqwei@fiberhome.com.cn Wed Apr 22 00:17:33 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D78528C40D for ; Wed, 22 Apr 2009 00:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[AWL=2.201, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKCLlelAdzHC for ; Wed, 22 Apr 2009 00:17:32 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id 14B253A6CC8 for ; Wed, 22 Apr 2009 00:17:28 -0700 (PDT) Received: from xqwei ([10.82.25.4]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Apr 2009 15:13:53 +0800 Date: Wed, 22 Apr 2009 15:18:29 +0800 From: "Xueqin WEI (Shuetsing WEI)" To: "Maarten Vissers" Message-ID: <200904221518293285128@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2009 07:13:53.0725 (UTC) FILETIME=[E4D0AED0:01C9C319] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 07:17:33 -0000 Maarten: Sorry reply you later because I have a trip on Monday and Tuesday. IMO, nested LSP is a already exist mechanism but TCM is a new added one. Addtion of TCM will make the thing more complicate. Second, TCM need to provision the TCM label along the monitored segmant too, I didn't see any provision difference between nested LSP and TCM. Sincerely Yours Xueqin Wei (Shuetsing Wei) 2009-04-22 15:12:35 ==================== Following is your email===================== Subject:RE: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Sent：2009-04-19 01:16:02 From:Maarten Vissers To:xqwei CC to:'MPLS-TP' >Xueqin, > >The nested LSP is a more complex solution then TCM. TCM just requires the >activation of some MEPs in the LSP. Nested LSP requires to set up the same >MEP functions plus set up an additional LSP and change the existing LSP. > >Regards, >Maarten > >-----Original Message----- >From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf >Of Xueqin WEI (Shuetsing WEI) >Sent: zaterdag 18 april 2009 8:52 >To: Ben Niven-Jenkins >Cc: MPLS-TP >Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was >RE:Associatedbidirectional transport path requirements) > >Support, I think the nested LSP will be great! Until now, I didn't see any >difference between the nested LSP and TCM on performance monitoring. But the >nested LSP will make the things more easy. I would like select a simple way >to resolve the problem. > >Sincerely Yours >Xueqin Wei (Shuetsing Wei) > >Fiberhome Telecommunication Technologies Co.,Ltd., >2009-04-18 14:48:51 > >==================== Following is your email===================== >Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: >Associatedbidirectional transport path requirements) >Sent：2009-04-17 17:17:31 >From:Ben Niven-Jenkins >To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp > >>Italo, >> >>On 17/04/2009 09:34, "BUSI ITALO" wrote: >>> The JWT agreement is to bring the ITU-T transport requirements in >>> IETF to extend the MPLS architecture to meet them in a way that is >>> compatible, consistent and coherent with existing IETF architecture. >> >>So I took a look at the JWT report. It says (slide 16) >> >>" Service Providers want LSPs/PWEs to be able to be managed at the >>different nested levels seamlessly (path, segment, multiple segments) >> aka Tandem Connection Monitoring (TCM), this is used for example >>when a LSP/PWE crosses multiple administrations" >> >>IMO the requirement is to be able to monitor parts of a path as well as >>the end to end path. There are many ways to solve that requirement, one >>of which is the creation of nested LSPs, one per level of monitoring >>required (my understanding of how TCM works). >> >>I think the real discussion is therefore is the requirement to monitor >>different components of an end to end path or is the requirement that >>such monitoring MUST be achieved using nested LSPs? >> >>As an example PW technology today allows end to end and per segment >>monitoring but it does not achieve it using nested PWs or PW levels. >> >>Ben >> >>_______________________________________________ >>mpls-tp mailing list >>mpls-tp@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls-tp >> > >================================================================= >_______________________________________________ >mpls-tp mailing list >mpls-tp@ietf.org >https://www.ietf.org/mailman/listinfo/mpls-tp > > ================================================================= From guoxinchun@huawei.com Wed Apr 22 00:42:52 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDF53A6CB5 for ; Wed, 22 Apr 2009 00:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.26 X-Spam-Level: * X-Spam-Status: No, score=1.26 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvWnTnHcPLrx for ; Wed, 22 Apr 2009 00:42:50 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 59CBA3A67E1 for ; Wed, 22 Apr 2009 00:42:49 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIH009P5S57NY@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 22 Apr 2009 15:43:55 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIH0050MS57EZ@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 22 Apr 2009 15:43:55 +0800 (CST) Received: from g67564 ([10.111.13.23]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIH00L9HS56Z4@szxml04-in.huawei.com> for mpls-tp@ietf.org; Wed, 22 Apr 2009 15:43:55 +0800 (CST) Date: Wed, 22 Apr 2009 15:43:53 +0800 From: guoxinchun In-reply-to: <51661468CBD1354294533DA79E85955A01A6C4AE@XCH-SW-5V2.sw.nos.boeing.com> To: liu.guoman@zte.com.cn, "'Drake, John E'" Message-id: <002101c9c31e$16620e90$170d6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcnCGw6yxJ764/ZgT/CDbKOquLQB9QAgyPlgABO/6iA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 07:42:52 -0000 Hi Liu, Drake and all, we have discussed this question for a long time, = I have read the mails, I want to say something about it. First, I think if MPLS-TP is achieved by extending transport capability based the existent MPLS network (form the mail list we can see this is expected by many operators), associated bidirectional LSP is = necessary.(this is also the opinion of someone as I remembrance) Second, I want to say is that I agree unidirectional P2P and P2MP path = needs a return path sometimes, and I think the return path is not MUST to be = the one being associated. However IMO associated bidirectional path may be a very suitable application for some conditions. For example, sometimes procedure sends data is form the interface from = which it receives packets from the other. When the interface is = unidirectional, there will be no reverse interface to choose. This condition, if we associated two unidirectional interfaces, each from a unidirectional = path, it will be very convenient. It looks,feels and behaves like a = bidirectional interface for the upper layer applications. In addition, associated bidirectional transport path can specify which = path to be associated, that is to say, it can specify the path which with = some specialities such as higher reliability and so on. It is very useful for some conditions, such as some OAM tools which reply packet is needed. If = the return path is selected randomly, when the random path is unreliable and fails to transport the reply packet, ingress will mis-consider that the forward path being checked is unworkable, but in fact the return path failed. This case, associated bidirectional path is a appropriate resolution. As the paths associated can be specified as needed, operator = can choose a return path with high reliability to decrease the condition of mis-judgement. =20 For the above reason listed, I think associated bidirectional path is = needed in MPLS-TP and it should be defined in the requirement. Best regards! Xinchun Guo -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Drake, John E Sent: Wednesday, April 22, 2009 12:30 AM To: liu.guoman@zte.com.cn Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Precisely. =20 > -----Original Message----- > From: liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn]=20 > Sent: Monday, April 20, 2009 5:45 PM > To: Drake, John E > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 >=20 > John:=20 > maybe I don't your meaning. IMO. it is necessary for=20 > unidirectional path to have a return path.=20 >=20 > regards > liu=20 >=20 >=20 >=20 > "Drake, John E" =20 >=20 > 2009-04-20 20:48 =CA=D5=BC=FE=C8=CB > =20 > =B3=AD=CB=CD > =20 > =D6=F7=CC=E2 > RE: [mpls-tp] Associated bidirectional transport path requirements >=20 > =09 >=20 >=20 >=20 >=20 >=20 > liu, >=20 > Please re-read my e-mail. You are agreeing with me. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn]=20 > > Sent: Sunday, April 19, 2009 7:01 PM > > To: Drake, John E > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > > path requirements > >=20 > >=20 > > John=A3=BA > > I don't completely agree your opinions. for unidirectional=20 > > P2P and P2MP path, if there is no return path, how can sink=20 > > points reply to source point's request packet? if there are=20 > > some faults in the backward sections of this unidirectional=20 > > path, the sink points will detects the defects, if no return=20 > > path, how can the sink points notify the fault message to=20 > > source points.=20 > > and so, I think if there is no return path, what happened to=20 > > unidirectional P2P and P2MP ?=20 > > I think we consider the return path.=20 > >=20 > > regards > > liu=20 > >=20 > >=20 > >=20 > > "Drake, John E" =20 > > =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 > >=20 > > 2009-04-18 03:02 =CA=D5=BC=FE=C8=CB > > "BUSI ITALO" , "Alexander=20 > > Vainshtein" , "Maarten=20 > > Vissers" =20 > > =B3=AD=CB=CD > > mpls-tp@ietf.org=20 > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidiroectional transport path requirements > >=20 > > =20 > >=20 > >=20 > >=20 > >=20 > > Italo, > >=20 > > As described in the MPLS TP OAM Requirements I-D, virtually=20 > all of the > > OAM functions require a return path, and in the absence of a=20 > > return path > > they are disabled. > >=20 > > As described in David Sinicrope's meeting minutes > > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > > meeting-no > > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing=20 > is used, an > > MPLS TP network needs to be capable of getting IP packets from > > destination to source; neither the minutes nor I stipulate that a > > control plane needs to be used to instantiate this forwarding. > >=20 > > As an aside, the issue of return path for unidirectional=20 > LSPs could be > > charaterized as the elephant in the room. In the MPLS TP OAM=20 > > Framework > > I-D, unicast LSPs are only mentioned three times and return=20 > > paths not at > > all. =20 > >=20 > > Thanks, > >=20 > > John > > > -----Original Message----- > > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > > > Sent: Friday, April 17, 2009 1:59 AM > > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] Associated bidirectional transport=20 > > > path requirements > > >=20 > > > John, > > >=20 > > > I might have missed the agreement of MPLS-TP being capable of=20 > > > sending replies to OAM requests sent on uni-directional LSPs. > > >=20 > > > This requirement does not belong to the first set of=20 > > > requirements ITU-T is expecting to be met by October. > > >=20 > > > However, I think this in a potential interesting additional=20 > > > requirement to be taken into account (at worst in a=20 > > subsequent phase). > > >=20 > > > I think that this requirement needs to be evaluated versus=20 > > > other more important requirements (e.g. the possibility to=20 > > > work w/o IP forwarding and the need for OAM to continue to=20 > > > monitor the data plane also in case of failures affecting the=20 > > > control or management plane). > > >=20 > > > I am open to discuss it but not sure this is the right time=20 > > > because I wish to avoid delaying the first phase of the=20 > > > design solution. > > >=20 > > > Thanks, Italo > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > > Sent: Thursday, April 16, 2009 8:00 PM > > > > To: Alexander Vainshtein; Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > At the meeting last fall at Juniper in Massachusetts, I=20 > > > think it was=20 > > > > agreed that an MPLS TP network needs to have a forwarding=20 > > > capability=20 > > > > for management, control, and OAM packets (e.g., sending=20 > > > replies to OAM=20 > > > > requests sent on uni-directional LSPs) even if it does not=20 > > > have an IP=20 > > > > forwarding data plane. > > > >=20 > > > > > -----Original Message----- > > > > > From: Alexander Vainshtein > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > > To: Maarten Vissers > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Maarten, > > > > > It seems that you've just (implicitly and, probably, > > > > > inadvertently) stated the following: > > > > >=20 > > > > > MPLS-TP OAM will not ever support MIP=20 > > loopback function=20 > > > (and fault=20 > > > > > localization which requires this function ) for=20 > > > unidirectional P2MP=20 > > > > > and P2P paths. > > > > >=20 > > > > > If this statement is correct, this (IMHO and FWIW)=20 > > raises a valid=20 > > > > > question: > > > > >=20 > > > > > Is MPLS-TP an appropriate solution for=20 > > these types of transport=20 > > > > > paths? > > > > >=20 > > > > > For the reference, IP/MPLS provides this kind of=20 > > > functionality today=20 > > > > > for (unidirectional - but it does not know any other=20 > > > type) P2P LSPs =20 > > > > > as described in RFC 4379. And its extension to P2MP=20 > LSPs seems=20 > > > > > easy... > > > > >=20 > > > > > =20 > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Sasha > > > > >=20 > > > > >=20 > > > > >=20 > > > > > ________________________________________ > > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org]=20 > > > On Behalf=20 > > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > > To: 'Adrian Farrel' > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Adrian, > > > > >=20 > > > > > >> > > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > > other internal > > > > > >> functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > > >> relationship of the forward and the backward > > > > > directions of that > > > > > >> transport path. > > > > > >> > > > > > > > > > > > > There is no way this is a functional requirement. That > > > > is, there is > > > > > > *nothing* that can be observed from a black box point of > > > > view that > > > > > > results from adhering to this requirement. > > > > >=20 > > > > > Your understanding is not correct. It is very much=20 > > observable if=20 > > > > > this requirement is met from a black box point of view. > > > > > The MIP functions can only perform the Loopback when=20 > there is a=20 > > > > > co-routed bidirectional transport path. The MPLS-TP=20 > LBM packet=20 > > > > > received at a MIP needs to be returned (as LBR > > > > > packet) to the originating MEP function via the other=20 > > > direction of=20 > > > > > the co-routed bidirectional transport path. This other=20 > > direction=20 > > > > > would not be available in an associated bidirectional=20 > transport=20 > > > > > path... and thus the loopback test > > > > would fail. > > > > >=20 > > > > > Similarly, when we have to apply TCM MEPs to monitor a=20 > > > segment, then=20 > > > > > this is possible in a co-routed bidir transport path=20 > > but not in a=20 > > > > > associated bidir transport path. In the first case=20 > the TCM MEP=20 > > > > > Source and Sink functions are co-located and can=20 > > exchange what is=20 > > > > > called "remote information" which is necessary for=20 > performance=20 > > > > > monitoring. > > > > > In the latter case the TCM MEP Source and Sink functions=20 > > > are in e.g.=20 > > > > > different nodes in the network and TCM would not be able=20 > > > to provide=20 > > > > > performance monitoring. > > > > >=20 > > > > > > The entirety of the bracketted text "(including MEPs, > > > > MIPs and other > > > > > internal > > > > > > functions as appropriate)" should be deleted. It does not > > > > > add to "The > > > > > > intermediate nodes." > > > > >=20 > > > > > Your understanding is not correct. This text must not be=20 > > > deleted at=20 > > > > > all. > > > > >=20 > > > > > > Actually, I am quite fed up about this persistent > > > > insistence on the > > > > > inclusion > > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > > this term > > > > > > is > > > > > poorly > > > > > > specified and comes from the monitoring of a path that is > > > > > parallel (i.e. > > > > > tandem) > > > > > > to the data path being monitored. This definition of TC > > > > > seems to be at > > > > > variance, > > > > > > and would be if the ACH was actually in band. > > > > >=20 > > > > > I don't understand where your interpretation of tandem=20 > > > connection is=20 > > > > > described in ITU-T recommendations. I.e. "from the=20 > > > monitoring of a=20 > > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > > monitored."? > > > > >=20 > > > > > There is a "network connection" and this network=20 > > > connection is a set=20 > > > > > of interconnected "link connections" and "matrix=20 > > connections". A=20 > > > > > subset of those interconnected link connections and matrix=20 > > > > > connections can be monitored and is then referred to as=20 > > a "tandem=20 > > > > > connection". There is no "path that is parallel to the=20 > > > data path".=20 > > > > > There is only additional OAM inserted inside the data=20 > > path by the=20 > > > > > TCM MEP_So function and this OAM is extracted from the=20 > > > data path by=20 > > > > > the TCM MEP_Sk function. > > > > >=20 > > > > > Regards, > > > > > Maarten > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > > Sent: donderdag 16 april 2009 11:59 > > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Hi Sasha, > > > > >=20 > > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > > bidirectional LSPs > > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > > Requirement > > > > > > 34 in the latest MPLS-TP requirements draft > > > > >=20 > > > > > OK. Got it. > > > > >=20 > > > > > But what is this doing in the data plane requirements section? > > > > >=20 > > > > > In fact, what is this requirement actually saying? > > > > >=20 > > > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > > > functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > > relationship of the forward and the backward > > > > > directions of that > > > > > > transport path. > > > > > > > > > > >=20 > > > > > There is no way this is a functional requirement. That=20 > > > is, there is > > > > > *nothing* that can be observed from a black box point of=20 > > > view that=20 > > > > > results from adhering to this requirement. > > > > >=20 > > > > > Therefore it could be assumed that this requirement is met by=20 > > > > > configuring some data plane database component through the=20 > > > > > management plane. The database component is not used=20 > > for anything=20 > > > > > except to satisfy this requirement for "awareness". > > > > >=20 > > > > > Ben! Can we please try to rewrite this requirement in=20 > terms of=20 > > > > > behavior? > > > > >=20 > > > > > > Please note that Requirement 34 is the ONLY item in the > > > > > list that is > > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > > requirements > > > > > > at end points for co-routed and associated bidirectional > > > > paths are > > > > > > exactly the same even if they appear in two different > > > > items in the > > > > > > requirements' list). > > > > > > In other words, without Requirement 34 the notion of=20 > > co-routed=20 > > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > > > The somewhat vague scope of this requirement=20 > ("other internal=20 > > > > > > functions as appropriate") creates a suspicion that HW > > > > > support of the > > > > > > pairing awareness may be required in order to=20 > comply with it. > > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs,=20 > > > MIPs and other=20 > > > > > internal functions as appropriate)" should be deleted. It=20 > > > does not=20 > > > > > add to "The intermediate nodes." > > > > >=20 > > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an=20 > > > arbitrary part of a > > > > > > transport path that can be monitored (via OAM) > > > > > independently from the > > > > > > end-to-end monitoring (OAM). It may be a monitored=20 > > > segment or a > > > > > > monitored concatenated segment of a transport path. =20 > > > The tandem > > > > > > connection may also include the forwarding engine(s) of > > > > > the node(s) > > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > > > >=20 > > > > > Actually, I am quite fed up about this persistent=20 > > > insistence on the=20 > > > > > inclusion of "Tandem Connection." The definition within=20 > > > the ITU-T of=20 > > > > > this term is poorly specified and comes from the=20 > > monitoring of a=20 > > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > > monitored. This definition of TC seems to be at variance,=20 > > > and would=20 > > > > > be if the ACH was actually in band. > > > > >=20 > > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > > >=20 > > > > > Yes, but so what? > > > > >=20 > > > > > > IMHO it is worth noting that neither the MPLS-TP > > > > Requirements draft > > > > > > nor the MPLS-TP OAM requirements one > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > > ts-01.txt) contain any requirements dealing with tandem > > > > connections. > > > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM=20 > > > Framework=20 > > > > > > draft > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > > amework-00.txt > > > > > ). > > > > >=20 > > > > > Right. > > > > > Let's just get rid of an unnecessary term and bring all=20 > > the I-Ds=20 > > > > > into line. > > > > >=20 > > > > > > The bottom line, IMHO, is that some clarity regarding > > > > co-routed vs. > > > > > > associated > > > > > > bidirectional paths is still required. One way to provide > > > > > that could > > > > > > be by explicitly limiting Requirement 34 to specific > > > > functionality. > > > > >=20 > > > > > Agreed. > > > > >=20 > > > > > Adrian > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > ________________________________________ > > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional=20 > transport path=20 > > > > > requirements > > > > >=20 > > > > > Hi Sasha, > > > > >=20 > > > > > Not really sure whether you are misrepresenting anyone, but... > > > > >=20 > > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > > bidirectional paths are the only types of paths that can be > > > > > created in > > > > > > the existing networks; "true" co-routed bidirectional paths > > > > > will have > > > > > > to wait until (if ever) new equipment becomes available. > > > > >=20 > > > > > This is clearly nonsense! > > > > > From the point of view of hardware, co-routed=20 > > > bidirectional LSPs are=20 > > > > > a special case of associated bidirectional LSPs. > > > > >=20 > > > > > If you can set up two unidirectional LSPs (e.g. using the=20 > > > management=20 > > > > > plane) you can surely set up a co-routed > > > > bidirectional LSP. > > > > >=20 > > > > > There are shipping solutions that achieve co-routed=20 > > bidirectional=20 > > > > > LSPs using the control plane. These either use the GMPLS=20 > > > (which is=20 > > > > > cleaner) or non-standard proprietary solutions (which is=20 > > > messy but=20 > > > > > functional). > > > > >=20 > > > > > But (of course) the management plane or control plane=20 > > > solutions have=20 > > > > > nothing to do with availability of equipment as they=20 > > are software=20 > > > > > solutions. > > > > >=20 > > > > > > 2. My reading of one of Neil's messages is that the actual > > > > > driver for > > > > > > co-routed bidirectional paths may be experience=20 > with existing=20 > > > > > > transport networks rather than any specific benefit. > > > > >=20 > > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > > Which is not to say it is a bad thing. > > > > >=20 > > > > > A large driver for MPLS-TP is to give the packet network=20 > > > the look,=20 > > > > > feel, and behavioral characteristics of a "legacy" > > > > > transport network. > > > > >=20 > > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > > * associated bidirectional paths are, at least for the time > > > > > > being, the most important type of bidirectional paths in > > > > > > MPLS-TP > > > > >=20 > > > > > I think that is wrong both given my statement above, and=20 > > > given that=20 > > > > > other upgrades to existing MPLS solutions will be=20 > > needed to reach=20 > > > > > the full function level of MPLS-TP. > > > > >=20 > > > > > > * they had a good chance to remain the only type of=20 > > > bidirectional > > > > > > paths in real deployments. > > > > >=20 > > > > > I don't see what that follows from. > > > > >=20 > > > > > Cheers, > > > > > Adrian > > > > >=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > >=20 > >=20 > >=20 > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in=20 > > this mail is solely property of the sender's organization.=20 > > This mail communication is confidential. Recipients named=20 > > above are obligated to maintain secrecy and are not permitted=20 > > to disclose the contents of this communication to others. > > This email and any files transmitted with it are confidential=20 > > and intended solely for the use of the individual or entity=20 > > to whom they are addressed. If you have received this email=20 > > in error please notify the originator of the message. Any=20 > > views expressed in this message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE=20 > > Anti-Spam system. > >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in=20 > this mail is solely property of the sender's organization.=20 > This mail communication is confidential. Recipients named=20 > above are obligated to maintain secrecy and are not permitted=20 > to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential=20 > and intended solely for the use of the individual or entity=20 > to whom they are addressed. If you have received this email=20 > in error please notify the originator of the message. Any=20 > views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE=20 > Anti-Spam system. >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From loa@pi.nu Wed Apr 22 01:09:47 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312003A70E3 for ; Wed, 22 Apr 2009 01:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr6EshKxX7k6 for ; Wed, 22 Apr 2009 01:09:46 -0700 (PDT) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id EB5323A70DA for ; Wed, 22 Apr 2009 01:09:45 -0700 (PDT) Received: from [192.36.158.68] (wdhcp-158-68.verkstad.net [192.36.158.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 44A9C2D8287; Wed, 22 Apr 2009 10:10:46 +0200 (CEST) Message-ID: <49EED102.508@pi.nu> Date: Wed, 22 Apr 2009 10:10:42 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <8ae4d2ef274065d49bd96e2ce1c2683f.squirrel@webmail.elverljung.se> <49EC8F69.30000@chello.nl> In-Reply-To: <49EC8F69.30000@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] comment on MPLS-TP document processing X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 08:09:47 -0000 Huub, inline please Huub van Helvoort wrote: > > Hej Loa, > > You wrote: > >> All, >> >> I'd like to comment on the current discussion on >> http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-06 . >> >> We do our best follow the the mpls-tp process as described in: >> >> http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt >> > > I agree. > >> The outstanding question we have for the ITU-T ad hoc team on >> MPLS-TP is step 13 in the figure on page 7 of that draft. We are >> asking the ad hoc Team if the draft is good enough to send to the >> IESG with a request for publication. > > However these are not new questions, the issues were raised during > the ITU-T plenary and were supposed to be resolved. > As I see there are two different ways of reading this 1. This is an ITU-T requirement and the IETF can only accept it! 2. This is an ITU-T requirement and we need to converge on an common understanding that may or not deviate from what was in the original requirement I sincerely hope that we are working according to the latter model. >> Please note that we are only expecting a "yes" or "no" answer to >> our question. > > I understand, but in this case it would be a conditional yes, > because, as I mentioned above, not all issues were resolved. Huub this is not really correct. Ben responded to each and every comment that had been sent to the mpls-tp and the ad hod team list. Some were accepted others were rejected, after that the list went completely silent. When this happens it is normal IETF process to assume that people are happy. And we can go ahead and update the document, nothing were said at the mpls working group meeting in San Francisco, again an indication that we could go ahead. However I can understand that IETF processes are confusing and that we should done a better job advising you on how this works. The situation today is that we have two documents that has been sent to the ITU-T for final approval, my advice today would be to respond "no" as quickly as possible so we can take the document back into the working group process and do necessary updates. This reminds me of the situation when I was in the WP3 meeting and suddenly found out that SG15 was going to decide that there were no proposal to deprecate existing T-MPLS Recommendations, regardless of the IAB liaison to the contrary. We have the brilliant decision that SG15 decides that IAB changed their mind and no longer thinks it is important to deprecate the T-MPLS Recommendations. Yes - I don't not understand how the ITU-T processes work and need help in those situation. /Loa > >> If the response is "yes" then publication will be requested, if >> the answer is "no", the document will be taken back into the >> working group process and a new version produced. >> >> That said, there is never wrong to discuss technical improvements, >> editorial issues or genereal clarifications on any draft. > > What is the purpose of discussing them when the publication has > started. Unless this is a working method accepted in the IETF. > and there is still a possibility to make technical changes/ > adjustments. > > In the ITU-T once a recommendation draft is consented (yes is > received) then the draft is pre-published. > The ITU-T editors will than bring the document in a shape > that is can be officially published, but in this stage no > technical changes can be made any more, only typographical. > > Regards, Huub. > -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From liu.guoman@zte.com.cn Wed Apr 22 01:16:58 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0250B28C323 for ; Wed, 22 Apr 2009 01:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.775 X-Spam-Level: X-Spam-Status: No, score=-96.775 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, J_CHICKENPOX_82=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYUN7mSK2PE0 for ; Wed, 22 Apr 2009 01:16:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 891983A698B for ; Wed, 22 Apr 2009 01:16:52 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 11164764009499; Wed, 22 Apr 2009 16:07:35 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 47274.2864862920; Wed, 22 Apr 2009 16:14:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3M8HUZt028936; Wed, 22 Apr 2009 16:17:30 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C04756097@E03MVB2-UKBR.domain1.systemhost.net> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Wed, 22 Apr 2009 16:15:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-22 16:17:19, Serialize complete at 2009-04-22 16:17:19 Content-Type: multipart/alternative; boundary="=_alternative 002D8773482575A0_=" X-MAIL: mse2.zte.com.cn n3M8HUZt028936 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 08:16:58 -0000 This is a multipart message in MIME format. --=_alternative 002D8773482575A0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TmVpbDoNCiAgdGhhbmsgeW91IGZvciB3YXN0aW5nIG1vcmUgdGltZSBpbiBkZXNjcmlibGluZyB0 aGUgcHJvYmxlbXMuIGJ1dCBJIHRoaW5rIA0Kc29tZSBvZiB3aGF0IHlvdSBzYWlkIGlzIG5vIHJl bGF0aW9ucyB3aXRoIG91ciBwcm9ibGVtLmZvciBtZSwgbWF5YmUgDQpBSVMvRkRJIGZ1bmN0aW9u cyBpcyBubyBzZW5zZSBpbiBjbC1wcyAsZWcuIElQLiBidXQgZm9yIENPLVBTIG5ldHdvcmtzLmlm IA0KdGhlcmUgaXMgbm8gQUlTL0ZESSBmdW5jdGlvbnMsIHdoZW4gdGhlcmUgaXMgYSBkZWZlY3Rz IGluIGEgZ2l2ZW4gbGF5ZXIgDQpuZXR3b3JrLCBpdCBjYW4gY2F1c2UgbXVsdGlwbGUgYWxhcm0g ZXZlbnRzIHRvIGJlIHJhaXNlZC4gaXQgaXMgZGlmZmN1bHQgDQpmb3Igb3BlcmF0b3JzIHRvIGxv Y2F0ZSBhbmQgZGlhZ25vc2UgdGhlIGZhdWx0cy4NCiB0aG91Z2ggSSBjb21wbGV0ZWx5IGFncmVl IHlvdSBvbiAgYWRkaW5nIG5ldyB0aGluZ3MgYW5kIGZ1bmN0aW9ucyB3aWxsIA0KYnJpbmcgc29t ZSBjb21wbGV4aXR5IC4gYnV0IGlmIHdlIGhhdmUgbm8gZnVuY3Rpb25zLCBpdCBpcyBtb3JlIGNv bXBsZXggDQphbmQgZGlmY3VsdCBmb3Igb3BlcmF0b3JzIHRvIG1haW50ZW5jZSBhbmQgYWRtaW5p c3RyYXRvciB0aGUgbmV0d29yay4gc28gSSANCnRoaW5rIGV2ZXJ5IG5ldyBmdW5jdGlvbnMgYW5k IHRoaW5ncyBtYXkgaGF2ZSBwb3NpdGl2ZSBhbmQgbmVnYXRpdmUgDQplZmZlY3RzLiBidXQgd2Ug c2hvdWxkIGNvbnNpZGVyIGl0IHZlcnkgbXVjaCwgZG9uJ3QgZGVsZXRlIHNvbWUgZnVuY3Rpb25z IA0KYXQgcmFuZG9tLg0KDQoNCmJlc3QgcmVnYXJkcw0KbGl1DQoNCg0KDQo8bmVpbC4yLmhhcnJp c29uQGJ0LmNvbT4gDQoyMDA5LTA0LTIxIDIwOjMwDQoNCsrVvP7Iyw0KPGxpdS5ndW9tYW5AenRl LmNvbS5jbj4sIDxkYnJ1bmdhcmRAYXR0LmNvbT4NCrOty80NCjxtcGxzLXRwQGlldGYub3JnPg0K 1vfM4g0KUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzDQoNCg0KDQoNCg0KDQpMaXUsDQogDQpJZiBNUExTLVRQIGlzIGdvaW5n IHRvIGJlIHRha2VuIHNlcmlvdXNseSBhcyBhIHRyYW5zcG9ydCBuZXR3b3JrIChsaWtlIA0KU0RI L1NPTkVUKSB0aGVuIHRoZSAyIGtleSBNVVNUIEhBVkUgcmVxdWlyZW1lbnRzIGFyZSB0aGVzZS4N CiANCjEgICAgUHJvdmlkZSBhIHRyYW5zcGFyZW50IGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlw Li4ud2hpY2ggbWVhbnM6DQotICAgIGFsbCBjbGllbnQgYml0cyB0cmVhdGVkIGVxdWFsbHkNCi0g ICAgY2xpZW50IGJpdCBvcmRlcmluZyBwcmVzZXJ2ZWQNCi0gICAgbm8gYXR0ZW1wdCB0byBpbmZl ciBjbGllbnQgc3ltYm9sIChpZSBzZXF1ZW5jZSBvZiBjbGllbnQgYml0cykgDQptZWFuaW5nIGFu ZCBubyBhdHRlbXB0IHRvIGNoYW5nZSBjbGllbnQgc3ltYm9scw0KLSAgICB0aGUgdHJhZmZpYyBi ZWhhdmlvdXIgb2YgY2xpZW50IFggbXVzdCBub3QgaW1wYWN0IHRoZSBwZXJmb3JtYW5jZSANCmV4 cGVyaWVuY2VkIGJ5IGNsaWVudCBZDQogDQpBIGtleSBjb3JvbGxhcnkgb2YgdGhlIGFib3ZlIGlz IHRoYXQgTVBMUy1UUCBtdXN0IG9ubHkgc3VwcG9ydCBwcm9wZXIgDQpjb25uZWN0aW9ucyAoaWUg c2luZ2xlIHNvdXJjZSBjb25zdHJ1Y3RzKQ0KIA0KIA0KMiAgIFNpbmNlIE1QTFMtVFAgaXMgYSB0 cmFuc3BvcnQgbmV0d29yayBpdCBpcyBub3QgYSB0b3Atb2Ytc3RhY2sgbmV0d29yayANCihpZSBp dCBkb2VzIG5vdCBzdXBwb3J0IGRpcmVjdGx5IGV4dGVybmFsIG1lc3NhZ2UvZmlsZS9zdHJlYW0g DQphcHBsaWNhdGlvbnMpLiAgTVBMUy1UUCB0aGVyZWZvcmUgZG9lcyBub3QgcmVxdWlyZSBhbiBF LU5OSSBzcGVjaWZpY2F0aW9uLiANCiBBIGtleSBjb3JvbGxhcnkgb2YgdGhpcyBpcyB0aGF0IE1Q TFMtVFAgd2lsbCBub3QgaGF2ZSBhbnkgcGVlciANCmludGVyd29ya2luZyByZWxhdGlvbnNoaXAg d2l0aCBhbnkgb3RoZXIgbmV0d29yayBtb2RlL3RlY2hub2xvZ3kuDQogDQogDQpOb3cgd3J0IE9B TSBNUExTLVRQIGlzIGEgY28tcHMgbW9kZSBuZXR3b3JrLiAgWW91IGNvdWxkIGFyZ3VlIHRoaXMg c2hvdWxkIA0KaGF2ZSBGREkvQUlTLi4uLmhvd2V2ZXIsIHRoZSBtZXJpdCBvZiB0aGlzIGlzIGhp Z2hseSBxdWVzdGlvbmFibGUuICBXaGVuIEkgDQphbmQgY29sbGVhZ3VlcyBkaXNjdXNzZWQgd2hl dGhlciBQQkItVEUgKGFsc28gYSBjby1wcyBtb2RlIG5ldHdvcmspIHNob3VsZCANCmhhdmUgRkRJ L0FJUyB3ZSBjb25jbHVkZWQgdGhhdCBvbiBiYWxhbmNlIGl0IHdhcyBub3QgYSBnb29kIGlkZWEu Li4uLmFuZCANCm5vdGUgdGhhdCBpbml0aWFsbHkgSSB3YXMgaW4gZmF2b3VyIG9mIGhhdmluZyBB SVMsIGJ1dCBteSBjb2xsZWFndWVzIA0KcHJvdmlkZWQgc3Ryb25nIHRlY2huaWNhbCBhcmd1bWVu dHMgdGhhdCBjb252aW5jZWQgbWUgb3RoZXJ3aXNlLg0KIA0KQUlTL0ZESSBpcyBoaXN0b3JpY2Fs bHkgbGlua2VkIHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXllciBuZXR3b3JrcyANCnRo YXQgdXNlZCBUVEwgbG9naWMuICBXaGVuIHRoaXMgZGllZCBpdCBwdXQgb3V0IGEgKzVWIChhbGwg MXMpIHNpZ25hbCBieSANCmRlZmF1bHQsIGllIGl0IHJlcXVpcmVkIG5vIGNvbnNjaW91cyBlZmZv cnQgdG8gZ2VuZXJhdGUgaXQuLi4uLnRoaXMgaXMga2V5IA0KcG9pbnQuICBGdXJ0aGVyLCBpbiB0 aGVzZSBuZXR3b3JrcyB0aGVyZSBpcyBhIGZhaXJseSBzdGF0aWMvbG9uZy1ob2xkaW5nIA0KY2xp ZW50IHNlcnZlciByZWxhdGlvbnNoaXAuICBDbGVhcmx5IHRoaXMgaXMgbm90IHRydWUgaW4gdGhl IGNsLXBzIG1vZGUgDQphbmQgaXQncyB3aHkgSUVURiBoYXZlIG5ldmVyIHNwZWNpZmllZCBBSVMg Zm9yIElQIGFuZCBpdHMgd2h5IElFRUUgaGFkIHRoZSANCmdvb2Qgc2Vuc2UgdG8gdGhyb3ctb3V0 IEFJUyBpbiA4MDIuMWFnIGZvciBFdGhlcm5ldCAodGhvdWdoIElUVSBoYXZlIA0KdW53aXNlbHkg SU1PIHJldGFpbmVkIGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0IGFueSBvcGVyYXRvciBw bGFubmluZyANCnRvIHVzZSBFdGhlcm5ldCBlcXVpcG1lbnQgd291bGQgYWx3YXlzIGxvb2sgdG8g SUVFRSBzdGRzIGFuZCBub3QgSVRVIA0Kb25lcykuDQogDQpBSVMvRkRJIGFuZCB0aGUgY28tcHMg bW9kZSBpcyBkZWJhdGFibGUuICBBcyBJIG5vdGVkIGFib3ZlLCBvbiBiYWxhbmNlIHdlIA0KY29u c2lkZXJlZCBub3QgYSBnb29kIGlkZWEgZm9yIFBCQi1URSBPQU0gYmVjYXVzZSBpdCByZXF1aXJl cyBhIGNvbnNjaW91cyANCmVmZm9ydCB0byBnZW5lcmF0ZSBpdCAodW5saWtlIHRoZSBjby1jcyBt b2RlKSBzbyB0aGVyZSBhcmUgbGlrZWx5IHRvIGJlIA0Kc2NhbGluZyBwcm9ibGVtcyBhbmQgaXRz IG9uZSBtb3JlIHRoaW5nIHRvIGdvIHdyb25nLg0KIA0KWW91IHNob3VsZCBhbHNvIGhhdmUgc2Vl biBtZSBtYWtlIHRoZSBwb2ludCBtYW55IHRpbWVzIGluIHRoZSBwYXN0IHRoYXQgDQp0aGUgYWx3 YXlzLW9uIGRlZmVjdCBkZXRlY3Rpb24vaGFuZGxpbmcgT0FNIG5lZWRzIHRvIGJlIGFzIHNpbXBs ZS9zcGFyc2UgDQphcyBwb3NzaWJsZSB3aXRoIGFzIGxpdHRsZSBjb25maWcgYXMgcG9zc2libGUg YmVjYXVzZSB3ZSBuZWVkIHN1cGVyIA0KcmVsaWFiaWxpdHkuLi4uLi5UQ00gZ29lcyBjb21wbGV0 ZWx5IGFnYWluc3QgdGhlIGdyYWluIGhlcmUuICBBbHNvIG5vdGUgDQp0aGF0IHRoZSBPQU0gcmVx dWlyZWQgZm9yIGVhY2ggb2YgdGhlIDMgbmV0d29yayBtb2RlcyBpcyBub3QgdGhlIHNhbWUsIA0K ZGVzcGl0ZSB3aGF0IHNvbWUgY2xhaW0uDQogDQpyZWdhcmRzLCBOZWlsDQogDQoNCkZyb206IG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIA0KT2YgbGl1Lmd1b21hbkB6dGUuY29tLmNuDQpTZW50OiAyMSBBcHJpbCAyMDA5 IDAyOjU5DQpUbzogQlJVTkdBUkQsIERFQk9SQUggQSwgQVRUTEFCUw0KQ2M6IG1wbHMtdHBAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIA0KcmVxdWlyZW1lbnRzDQoNCg0KRGVib3JhaDogDQogbWF5YmUgd2hhdCB5 b3Ugc2FpZCBpcyByaWdodC4gYnV0IEkgY2FuJ3QgY29tcGxldGVseSBhZ3JlZSB5b3VyIG9waW5p b25zLiANCklNTy4gbXBscy10cCBpcyByZWdhcmQgYXMgdHJhbnNwb3J0IG5ldHdvcmsgbGlrZSBT REgvU09ORVQuIHNvIGl0IHNob3VsZCANCmhhdmUgQUlTL0ZESSBmdWN0aW9ucyBhcyBTREgvU09O RVQuIA0KDQpkbyB5b3UgdGhpbmsgc28uIA0KDQpiZXN0IHJlZ2FyZHMgDQpsaXUgDQoNCg0KIkJS VU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMiIDxkYnJ1bmdhcmRAYXR0LmNvbT4gDQq3orz+yMs6 ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDA5LTA0LTIwIDIzOjQ3IA0KDQoNCsrVvP7I yw0KIk1hYXJ0ZW4gVmlzc2VycyIgPG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPiwgPG5laWwu Mi5oYXJyaXNvbkBidC5jb20+IA0Ks63LzQ0KbXBscy10cEBpZXRmLm9yZyANCtb3zOINClJlOiBb bXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVt ZW50cw0KDQoNCg0KDQoNCg0KDQoNCkkgYWdyZWUgd2l0aCBOZWlsLCBpdCBpcyB2ZXJ5IHF1ZXN0 aW9uYWJsZSB0aGUgdmFsdWUgb2YgQUlTL0ZESSBpbiBhDQpwYWNrZXQgbmV0d29yay0gYW55IG1v ZGUuIEl0IGNhbiByZXN1bHQgaW4gYSBEb1MgYXR0YWNrIGJ5IGFuIG9wZXJhdG9yDQpvbiB0aGVt c2VsdmVzIHNvIGV2ZW4gWTE3MzEgcmVjb21tZW5kcyBub3QgdG8gYmxvY2sgZGF0YSBmcmFtZXM6 DQoiQSBNRVAgY2FuIGRlY2lkZSB3aGV0aGVyIGl0IGJsb2NrcyBkYXRhIGZyYW1lcyB3aGVuIGl0 IGRldGVjdHMgZEFJUy4NClRoZSBwcmluY2lwbGUgcmVxdWlyZW1lbnQNCnRoYXQgaW5mbHVlbmNl cyB0aGlzIGRlY2lzaW9uIGlzIHRoYXQgZGF0YSBmcmFtZXMgb3VnaHQgdG8gYmUgZm9yd2FyZGVk DQphcyBtdWNoIGFzIHBvc3NpYmxlLCB3aXRob3V0DQp0aGUgcG9zc2liaWxpdHkgb2YgZm9yd2Fy ZGluZyB3cm9uZyBkYXRhIGZyYW1lcyBkb3duc3RyZWFtLiINClRhYmxlIEkuNy0yIHNob3dzIGZv ciBBSVMsIG5vdCB0byBibG9jay4NCg0KQW5kIGFzIFkxNzMxIHN0YXRlcywgQUlTIGNhbiBvbmx5 IGJlIHVzZWQgdW5kZXIgdmVyeSBjb25zdHJhaW5lZA0KYXJjaGl0ZWN0dXJlcyAtIGlmIHJlcXVp cmVkIGZvciBNUExTLVRQLCBpdCBuZWVkcyB0byBoYXZlIHRoZSBzYW1lDQpndWlkYW5jZSBhcyBp biBZMTczMSwgaS5lLiBwb2ludC10by1wb2ludCBhbmQgc2VydmVyL2NsaWVudCBvbmUtdG8tb25l Og0KImZvciBhIHBvaW50LXRvLXBvaW50IEVUSCBjb25uZWN0aW9uLCBhIE1FUCBoYXMgb25seSBh IHNpbmdsZSBwZWVyIE1FUC4NClRoZXJlZm9yZSwgdGhlcmUNCmlzIG5vIGFtYmlndWl0eSByZWdh cmRpbmcgdGhlIHBlZXIgTUVQIGZvciB3aGljaCBpdCBzaG91bGQgc3VwcHJlc3MNCmFsYXJtcyB3 aGVuIGl0IHJlY2VpdmVzIHRoZQ0KRVRILUFJUyBpbmZvcm1hdGlvbi4iDQpTbyBzaG91bGQgb25s eSBiZSB3aXRoaW4gb25lIGRvbWFpbiAtIHRoZW4gbm8gbmVlZC4NCg0KRGVib3JhaA0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmIE9mIE1hYXJ0ZW4gVmlz c2Vycw0KU2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSAxMDowNSBBTQ0KVG86IG5laWwuMi5o YXJyaXNvbkBidC5jb20NCkNjOiBtcGxzLXRwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KcmVxdWlyZW1lbnRz DQoNCk5laWwsDQoNCj4gYnV0IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZv dXIhDQoNCkV0aGVybmV0IEFJUyBpcyBpbmRlZWQgYSByZXF1aXJlbWVudCBhbmQgYSBuZWNlc3Np dHkuIEFuZCB5b3Ugd2lsbCBub3QNCmJlDQphYmxlIHRvIHVuZGVyc3RhbmQgdGhhdCBhcyBsb25n IGFzIHlvdSByZWZ1c2UgdG8gYWNjZXB0IHRoYXQgImNsLW1vZGUiDQppcyBhDQpmb3J3YXJkaW5n IG1vZGUgd2l0aGluIGEgKip0cmFuc3BvcnQgZW50aXR5KiouIEcuODAwIGFtZW5kbWVudCAxIGhh cw0KZmluYWxseQ0KcmVpbnRyb2R1Y2VkIHRoaXMgdHJhbnNwb3J0IGVudGl0eSBpbnRvIEcuODAw LiBCZXNpZGVzIHRoYXQsIGl0IGFsc28NCmludHJvZHVjZWQgdGhlICoqZGlmZmVyZW50aWF0ZWQg Y29ubmVjdGlvbioqOg0KDQpbRy44MDAgYW0xXSAiQSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9u IGlzIGEgdHJhbnNwb3J0IGVudGl0eSB0aGF0DQp0cmFuc2ZlcnMgaW5mb3JtYXRpb24gYmVsb25n aW5nIHRvIG11bHRpcGxlIGNvbW11bmljYXRpb25zIGJldHdlZW4gcG9ydHMNCmFjcm9zcyBhIHN1 Ym5ldHdvcmsuIDwuLj4gSW4gYSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIG1lc3NhZ2UNCmNv bnRlbnRzDQphcmUgaW50ZXJwcmV0ZWQgdG8gaWRlbnRpZnkgKHNldHMgb2YpIGNvbW11bmljYXRp b25zIHdoaWNoIHJlY2VpdmUNCmRpZmZlcmVudA0KdHJlYXRtZW50LiAgVGhlIHNldHMgb2YgY29t bXVuaWNhdGlvbnMgbWF5IGJlIGRpc3Rpbmd1aXNoZWQgYnkgdGhlDQpmb3J3YXJkaW5nIGlkZW50 aWZpZXIgb3Igb3RoZXIgbGF5ZXIgaW5mb3JtYXRpb24uICBPcmRlciBpcyBub3QNCm5lY2Vzc2Fy aWx5DQpwcmVzZXJ2ZWQgYmV0d2VlbiBtZXNzYWdlcyBiZWxvbmdpbmcgdG8gc2V0cyBvZiBjb21t dW5pY2F0aW9ucyByZWNlaXZpbmcNCmRpZmZlcmVudCB0cmVhdG1lbnQuICBTZXRzIG9mIGNvbW11 bmljYXRpb25zIG1heSBiZSBpZGVudGlmaWVkIGZvcg0KcHVycG9zZXMNCnN1Y2ggYXMgdHJhZmZp YyBjb25kaXRpb25pbmcgb3IgcHJlc2VydmluZyBjb21tdW5pY2F0aW9uIG1lc3NhZ2Ugb3JkZXIu Ig0KDQoNCkV0aGVybmV0IFZMQU5zIGFyZSBpbiB0ZXJtcyBvZiBHLjgwMCAiZGlmZmVyZW50aWF0 ZWQgY29ubmVjdGlvbnMiLg0KRXRoZXJuZXQNCkFJUyBwcm92aWRlcyBBSVMgd2l0aGluIHRoZSBz Y29wZSBvZiBzdWNoICJkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIi4NCklmDQp5b3UgYXBwbHkg dGhpcyB0byBteSBwcm9wb3NlZCBQVE4gbGF5ZXIgc3RhY2ssIHRoZW4gdGhlIEVWQyBsYXllcg0K dG9wb2xvZ3kNCndpbGwgY29uc2lzdHMgb2YgRVZDIGxpbmtzIHN1cHBvcnRlZCBieSBNUExTLVRQ LCBFdGhlcm5ldCwgUEJCLVRFIGFuZA0KUC1PVE4NClZQIHRyYWlscyBpbnNpZGUgbWV0cm8gYW5k IGNvcmUgZG9tYWlucyBpbnRlcmNvbm5lY3RpbmcgRVZDIG1hdHJpY2VzLg0KV2hlbg0Kb25lIG9m IHRob3NlIEVWQyBsaW5rcyBpcyBpbnRlcnJ1cHRlZCwgZS5nLiBpbiB0aGUgY29yZSBiZXR3ZWVu IG1ldHJvIDENCmFuZA0KbWV0cm8gNCAoc2VlIGF0dGFjaGVkIHNsaWRlKSwgdGhlbiB0aGUgRVZD IGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24NCnRoYXQgaXMNCnByZXNlbnQgb24gdGhpcyBsaW5r IHdpbGwgYmUgaW50ZXJydXB0ZWQuIEF0IHRoZSBFVkMgc3dpdGNoL2JyaWRnZSBub2RlDQppbg0K bWV0cm8gNCB0aGlzIGludGVycnVwdGlvbiBpcyBub3RpY2VkIGFuZCBFVkMtQUlTIGlzIGluc2Vy dGVkIGluIHRoZQ0KZG93bnN0cmVhbSBkaXJlY3Rpb24gdG8gc3VwcHJlc3MgdGhlIEVWQy1MT0Mg YWxhcm1zIGF0IEVWQyBlbmRwb2ludHMgRDQNCmFuZA0KRDUuDQoNClRoZSBFVkMtQUlTIChpLmUu IEV0aGVybmV0IEFJUykgZnJhbWUgaGFzIGEgcmVzZXJ2ZWQgbXVsdGljYXN0IGFkZHJlc3MsDQp3 aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIEFJUyBpcyBicm9hZGNhc3QgdG8gdGhlIGVuZHBvaW50 cyBvZiB0aGUgRVZDLg0KDQpJIGJlbGlldmUgdGhhdCBpdCBpcyB0aW1lIGZvciB5b3UgdG8gYWRh cHQgeW91ciB2aWV3IG9uIGNvIGFuZCBjbCBtb2Rlcw0KYW5kDQpyZWxhdGUgaXQgdG8gdGhlIGZv cndhcmRpbmcgbW9kZSAqKklOU0lERSoqIGEgdHJhbnNwb3J0IGVudGl0eS4gDQoNCldoYXQgd2Ug a25vdyBhcyB0aGUgaW50ZXJuZXQgaXMgZXNzZW50aWFsbHkgYW4gIklQIGRpZmZlcmVudGlhdGVk DQpjb25uZWN0aW9uIiB3aXRoIGEgYmlsbGlvbiBvciBtb3JlIHBvcnRzLg0KV2hhdCB3ZSBrbm93 IGFzIGFuIElQIFZQTiBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQNCmNvbm5l Y3Rpb24iDQp3aXRoIGUuZy4gbiBwb3J0cyAobiBpbiB0aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEw MDApLg0KV2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMgZXNzZW50aWFsbHkgYW4g IkV0aGVybmV0DQpkaWZmZXJlbnRpYXRlZA0KY29ubmVjdGlvbiIgd2l0aCBuIHBvcnRzIChuIGlu IHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuDQpXaGF0IHdlIGtub3cgYXMgYSBwMnAgTVBM UyBFLUxTUCBpcyBlc3NlbnRpYWxseSBhbiAiTVBMUyBkaWZmZXJlbnRpYXRlZA0KY29ubmVjdGlv biIgd2l0aCAyIHBvcnRzLg0KV2hhdCB3ZSBrbm93IGFzIGEgcDJwIFNESCBWQy1uIGlzIGEgIlNE SCBWQy1uIGNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy4NCg0KVHJhbnNwb3J0IG5ldHdvcmsgT0FN IGFwcGxpZXMgdG8gdHJhbnNwb3J0IGVudGl0aWVzLCB3aGljaCBhcmUgKGluIHRlcm1zDQpvZg0K Ry44MDAgYW0xKSBjb25uZWN0aW9ucyBhbmQgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbnMuDQoN ClJlZ2FyZHMsDQpNYWFydGVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBu ZWlsLjIuaGFycmlzb25AYnQuY29tIFttYWlsdG86bmVpbC4yLmhhcnJpc29uQGJ0LmNvbV0gDQpT ZW50OiB2cmlqZGFnIDE3IGFwcmlsIDIwMDkgMjI6MDANClRvOiBKb2huLkUuRHJha2UyQGJvZWlu Zy5jb207IEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ7DQpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTsgbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20NCkNjOiBtcGxzLXRwQGll dGYub3JnDQpTdWJqZWN0OiBSRTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0 cmFuc3BvcnQgcGF0aA0KcmVxdWlyZW1lbnRzDQoNCkpvaG4sICBUaGFua3MgdGhpcyBpcyBhIGdy ZWF0IHBsYXRmb3JtIHRvIGV4cGxhaW4gd2h5IE9BTSBmb3IgdGhlIDMNCm5ldHdvcmsNCm1vZGVz IG5lZWRzIHRvIGJlIGRpZmZlcmVudC4gIEkgYW0gZ2V0dGluZyBhIHdlZSBiaXQgdGlyZWQgb2Yg Zm9sa3MNCnRyeWluZw0KdG8gbWFrZSBhbGwgMyBuZXR3b3JrIG1vZGVzIGxvb2sgYWxpa2UgKGFu ZCB0aGVuLCBldmVuIHdvcnNlLCBpbnRlcndvcmsNCnRoZW0NCmFzIGFzIHBlZXJzLi4uZXNwIHdo ZW4gbm90IG5vdCB0b3Atb2Ytc3RhY2sNCm5ldHdvcmtzLi4uSSBtZWFuIGhvdyBzaWxseSBjYW4g d2UgZ2V0PykuICAgSSBhbSBldmVuIG1vcmUgZnJ1c3RyYXRlZCBieQ0KdGhlIGZhY3QgdGhvc2Ug cGVkZGxpbmcgdGhpcyBGVUQgb25seSBldmVyIHNlZW0gdG8gY29uc2lkZXIgT0FNIGFuZA0KZm9y Z2V0DQphbGwgb3RoZXIgRFAvQ1AvTVAgY29tcG9uZW50cyAoZXNwIHRvcC1vZi1zdGFjayBtZXNz YWdlL2ZpbGUvc3RyZWFtDQphcHBsaWNhdGlvbiBhZGFwdGF0aW9ucykuICBIb3cgd3JvbmcgY2Fu IHRoaXMgZ2V0ISANCg0KSW4gdGhlIGNvIG1vZGVzIGEgKmNvbm5lY3Rpb24qIGlzIGEgdmVyeSBz cGVjaWZpYyBhbmQgKmNvbnN0cmFpbmluZyoNCmNvbnN0cnVjdC4uLi4uSSBhbSBhc3N1bWluZyBo ZXJlIHdlIHJlc3BlY3QgdGhlIHJ1bGVzIG9mIGEgY29ubmVjdGlvbg0KKGllDQpzaW5nbGUgc291 cmNlKSB0aG91Z2ggc29tZSBmb2xrcyBkb24ndCBldmVuIGJvdGhlciB0byByZXNwZWN0IHRoaXMs IGFuZA0KdGhpcw0KaXMgZGVzcGl0ZSB0aGUgZmFjdCB0aGF0IHdlIGFsbCBrbm93IHdoYXQgcHJv YmxlbXMgbXVsdGlwbGUtc291cmNlDQpjb25zdHJ1Y3RzIGNhbiBjYXVzZSAoZnJvbSBMRFAvUEhQ Li4uLmVyZ28gTVBMUy1UUCkuDQoNCldoZW4gd2UgaGF2ZSBhIGNvbm5lY3Rpb24gdGhpcyByZXN0 cmljdHMgKmFsbCogRFAgKGllIHRyYWZmaWMgYW5kIE9BTSkNCnRvDQpzdGF5IHdpdGhpbiB0aGUg Ym91bmRzIG9mIHRoZSBjb25uZWN0aW9uLiAgV2hpY2ggaXMgZmluZSB1bmRlcg0KZGVmZWN0LWZy ZWUNCmNvbmRpdGlvbnMsIGJ1dCBpZiB3ZSBoYXZlIGxlYWtpbmcgdHJhZmZpYyB0aGVuIHRoZSBj b25zdHJhaW5pbmcgbmF0dXJlDQpvZg0KdGhlIGNvbm5lY3Rpb24gY29uc3RydWN0IGlzIGJyb2tl bi4gIEluIGEgbnV0c2hlbGwgd2hhdCB0aGlzIG1lYW5zIGlzDQp0aGF0DQpPQU0gdGhhdCBpcyBv ZiBhIHJlcXVlc3QvcmVzcG9uc2UgbmF0dXJlIGNhbm5vdCBiZSB0cnVzdGVkIGluIGNvIG1vZGUN Cm5ldHdvcmtzIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3RzLi4uLi5pbmRlZWQsIHdoeSBz aG91bGQgYSBsZWFraW5nDQpEUA0KaGF2ZSBhIHN5bW1ldHJpYyBnby9yZXR1cm4gZGVmZWN0IGJl aGF2aW91cj8uLi4udmVyeSBsaWtlbHkgaXQgd29uJ3QuDQpTbw0Kd2hpbHN0IHJlcXVlc3QvcmVz cG9uc2UgT0FNIGlzIHJpZ2h0IGZvciB0aGUgY2wgbW9kZSBpdCBpcyBub3QgcmlnaHQgZm9yDQp0 aGUNCmNvIG1vZGUgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCBjb25kaXRpb25zLg0KDQpN b3JlIGdlbmVyYWxseSB0aGUgMyBtb2RlcyBhcmUgZGlmZmVyZW50IGFuZCBub3QganVzdCBpbiBP QU0NCnJlcXVpcmVtZW50cy4uLi5idXQgQUlTL0ZESSBpbiB0aGUgY2wgbW9kZT8uLi5kbyBtZSBh IGZhdm91ciEuLi5hdCBsZWFzdA0KSUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2UgdG8gYmluIHRoaXMg Zm9yIEV0aGVybmV0IGV2ZW4gdGhvdWdoIGl0IHJlbWFpbnMNCmluDQpZLjE3MzEuICBBbmQgd2hp Y2ggaXMgd2h5IEkgb2Z0ZW4gdHJvdC1vdXQgdGhlIHJhdGhlciBzaWxseSAodG8gaGF2ZSB0bw0K c2F5DQp0aGlzKSBvYnNlcnZhdGlvbiB0aGF0IGlmIElQIChjbCBtb2RlKSBjb3VsZCBkbyBpdCBh bGwgdGhlbiB3aHkgaGF2ZQ0KSUVURg0KZm91bmQgaXQgbmVjZXNzYXJ5IHRvIGNyZWF0ZSBNUExT IChjby1wcykgYW5kIEdNUExTIChDUCBmb3IgY28tY3MpLiAgVGhlDQphbnN3ZXIgbGllcyBpbiB0 aGUgcGh5c2ljcy4uLmFuZCBHLjgwMCBhdHRlbXB0cyB0byBleHBsYWluIHRoYXQNCnBoeXNpY3Mu Li4uRy44MDUgZG9lcyBub3QuDQoNClNvLCB0aGUgMyBtb2RlcyBhcmUgZGlmZmVyZW50Li4ucGxl YXNlIGFjY2VwdC9yZWpvaWNlIGluIHRoaXMgZmFjdCBhcw0KdGhleQ0KYWxsIG9mZmVyIHNvbWV0 aGluZyBkaWZmZXJlbnQvaW1wb3J0YW50LiAgQnV0IGRvIG5vdCBiZSBob29kd2lua2VkIGJ5DQp0 aG9zZQ0Kd2hvIHBlZGRsZSBhIHN0b3J5IHRoYXQgdGhhdCB0cmllcyB0byBtYWtlIHRoZSBPQU0g b2YgdGhlIDMgbW9kZXMgdGhlDQpzYW1lLiANCg0KcmVnYXJkcywgTmVpbCANCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCj4g W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9o biBFDQo+IFNlbnQ6IDE3IEFwcmlsIDIwMDkgMjA6MDINCj4gVG86IEJVU0kgSVRBTE87IEFsZXhh bmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggDQo+IHJlcXVpcmVtZW50cw0KPiANCj4gSXRhbG8sDQo+IA0KPiBBcyBkZXNjcmli ZWQgaW4gdGhlIE1QTFMgVFAgT0FNIFJlcXVpcmVtZW50cyBJLUQsIHZpcnR1YWxseSBhbGwgb2Yg dGhlDQoNCj4gT0FNIGZ1bmN0aW9ucyByZXF1aXJlIGEgcmV0dXJuIHBhdGgsIGFuZCBpbiB0aGUg YWJzZW5jZSBvZiBhIHJldHVybiANCj4gcGF0aCB0aGV5IGFyZSBkaXNhYmxlZC4NCj4gDQo+IEFz IGRlc2NyaWJlZCBpbiBEYXZpZCBTaW5pY3JvcGUncyBtZWV0aW5nIG1pbnV0ZXMgDQo+IChodHRw Oi8vd2lraS50b29scy5pZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9hdHRhY2htZW50L3dpa2kv DQo+IG1lZXRpbmctbm8NCj4gdGVzLzIwMDgxMDE1Lm1wbHMtaW50ZXJvcC1kdC1ub3Rlcy56aXAp LCBpZiBJUCBhZGRyZXNzaW5nIGlzIHVzZWQsIGFuIA0KPiBNUExTIFRQIG5ldHdvcmsgbmVlZHMg dG8gYmUgY2FwYWJsZSBvZiBnZXR0aW5nIElQIHBhY2tldHMgZnJvbSANCj4gZGVzdGluYXRpb24g dG8gc291cmNlOyBuZWl0aGVyIHRoZSBtaW51dGVzIG5vciBJIHN0aXB1bGF0ZSB0aGF0IGEgDQo+ IGNvbnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byBpbnN0YW50aWF0ZSB0aGlzIGZvcndh cmRpbmcuDQo+IA0KPiBBcyBhbiBhc2lkZSwgdGhlIGlzc3VlIG9mIHJldHVybiBwYXRoIGZvciB1 bmlkaXJlY3Rpb25hbCBMU1BzIGNvdWxkIGJlDQoNCj4gY2hhcmF0ZXJpemVkIGFzIHRoZSBlbGVw aGFudCBpbiB0aGUgcm9vbS4gIEluIHRoZSBNUExTIFRQIE9BTSANCj4gRnJhbWV3b3JrIEktRCwg dW5pY2FzdCBMU1BzIGFyZSBvbmx5IG1lbnRpb25lZCB0aHJlZSB0aW1lcyBhbmQgcmV0dXJuIA0K PiBwYXRocyBub3QgYXQgYWxsLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gSm9obg0KPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQlVTSSBJVEFMTyBbbWFpbHRvOkl0YWxv LkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXRdDQo+ID4gU2VudDogRnJpZGF5LCBBcHJpbCAxNywgMjAw OSAxOjU5IEFNDQo+ID4gVG86IERyYWtlLCBKb2huIEU7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBN YWFydGVuIFZpc3NlcnMNCj4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJF OiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KPiA+ IHJlcXVpcmVtZW50cw0KPiA+IA0KPiA+IEpvaG4sDQo+ID4gDQo+ID4gSSBtaWdodCBoYXZlIG1p c3NlZCB0aGUgYWdyZWVtZW50IG9mIE1QTFMtVFAgYmVpbmcgY2FwYWJsZSBvZiANCj4gPiBzZW5k aW5nIHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMu DQo+ID4gDQo+ID4gVGhpcyByZXF1aXJlbWVudCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlIGZpcnN0 IHNldCBvZiByZXF1aXJlbWVudHMgDQo+ID4gSVRVLVQgaXMgZXhwZWN0aW5nIHRvIGJlIG1ldCBi eSBPY3RvYmVyLg0KPiA+IA0KPiA+IEhvd2V2ZXIsIEkgdGhpbmsgdGhpcyBpbiBhIHBvdGVudGlh bCBpbnRlcmVzdGluZyBhZGRpdGlvbmFsIA0KPiA+IHJlcXVpcmVtZW50IHRvIGJlIHRha2VuIGlu dG8gYWNjb3VudCAoYXQgd29yc3QgaW4gYQ0KPiBzdWJzZXF1ZW50IHBoYXNlKS4NCj4gPiANCj4g PiBJIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVudCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVy c3VzIG90aGVyIA0KPiA+IG1vcmUgaW1wb3J0YW50IHJlcXVpcmVtZW50cyAoZS5nLiB0aGUgcG9z c2liaWxpdHkgdG8gd29yayB3L28gSVAgDQo+ID4gZm9yd2FyZGluZyBhbmQgdGhlIG5lZWQgZm9y IE9BTSB0byBjb250aW51ZSB0byBtb25pdG9yIHRoZSBkYXRhIA0KPiA+IHBsYW5lIGFsc28gaW4g Y2FzZSBvZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wgb3IgbWFuYWdlbWVudCANCj4g PiBwbGFuZSkuDQo+ID4gDQo+ID4gSSBhbSBvcGVuIHRvIGRpc2N1c3MgaXQgYnV0IG5vdCBzdXJl IHRoaXMgaXMgdGhlIHJpZ2h0IHRpbWUgYmVjYXVzZSANCj4gPiBJIHdpc2ggdG8gYXZvaWQgZGVs YXlpbmcgdGhlIGZpcnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24gc29sdXRpb24uDQo+ID4gDQo+ID4g VGhhbmtzLCBJdGFsbw0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gW21haWx0bzptcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9obiBFDQo+ID4gPiBTZW50 OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgODowMCBQTQ0KPiA+ID4gVG86IEFsZXhhbmRlciBW YWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCANCj4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gDQo+ID4gPiBBdCB0aGUgbWVl dGluZyBsYXN0IGZhbGwgYXQgSnVuaXBlciBpbiBNYXNzYWNodXNldHRzLCBJDQo+ID4gdGhpbmsg aXQgd2FzDQo+ID4gPiBhZ3JlZWQgdGhhdCBhbiBNUExTIFRQIG5ldHdvcmsgbmVlZHMgdG8gaGF2 ZSBhIGZvcndhcmRpbmcNCj4gPiBjYXBhYmlsaXR5DQo+ID4gPiBmb3IgbWFuYWdlbWVudCwgY29u dHJvbCwgYW5kIE9BTSBwYWNrZXRzIChlLmcuLCBzZW5kaW5nDQo+ID4gcmVwbGllcyB0byBPQU0N Cj4gPiA+IHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMpIGV2ZW4gaWYgaXQg ZG9lcyBub3QNCj4gPiBoYXZlIGFuIElQDQo+ID4gPiBmb3J3YXJkaW5nIGRhdGEgcGxhbmUuDQo+ ID4gPiANCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTog QWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gPiA+IFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb21dDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA5OjU3 IEFNDQo+ID4gPiA+IFRvOiBNYWFydGVuIFZpc3NlcnMNCj4gPiA+ID4gQ2M6IG1wbHMtdHBAaWV0 Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiANCj4g PiA+ID4gTWFhcnRlbiwNCj4gPiA+ID4gSXQgc2VlbXMgdGhhdCB5b3UndmUganVzdCAoaW1wbGlj aXRseSBhbmQsIHByb2JhYmx5LA0KPiA+ID4gPiBpbmFkdmVydGVudGx5KSBzdGF0ZWQgdGhlIGZv bGxvd2luZzoNCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgTVBMUy1UUCBPQU0g d2lsbCBub3QgZXZlciBzdXBwb3J0IE1JUCBsb29wYmFjayANCmZ1bmN0aW9uDQo+ID4gKGFuZCBm YXVsdA0KPiA+ID4gPiBsb2NhbGl6YXRpb24gd2hpY2ggcmVxdWlyZXMgdGhpcyBmdW5jdGlvbiAp IGZvcg0KPiA+IHVuaWRpcmVjdGlvbmFsIFAyTVANCj4gPiA+ID4gYW5kIFAyUCBwYXRocy4NCj4g PiA+ID4gDQo+ID4gPiA+IElmIHRoaXMgc3RhdGVtZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8g YW5kIEZXSVcpDQo+IHJhaXNlcyBhIHZhbGlkDQo+ID4gPiA+IHF1ZXN0aW9uOg0KPiA+ID4gPiAN Cj4gPiA+ID4gICAgICAgICAgICAgICAgICBJcyBNUExTLVRQIGFuIGFwcHJvcHJpYXRlIHNvbHV0 aW9uIGZvciB0aGVzZQ0KPiB0eXBlcyBvZiB0cmFuc3BvcnQNCj4gPiA+ID4gcGF0aHM/DQo+ID4g PiA+IA0KPiA+ID4gPiBGb3IgdGhlIHJlZmVyZW5jZSwgSVAvTVBMUyBwcm92aWRlcyB0aGlzIGtp bmQgb2YNCj4gPiBmdW5jdGlvbmFsaXR5IHRvZGF5DQo+ID4gPiA+IGZvciAodW5pZGlyZWN0aW9u YWwgLSBidXQgaXQgZG9lcyBub3Qga25vdyBhbnkgb3RoZXINCj4gPiB0eXBlKSBQMlAgTFNQcw0K PiA+ID4gPiBhcyBkZXNjcmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0ZW5zaW9uIHRvIFAy TVAgTFNQcyBzZWVtcyANCj4gPiA+ID4gZWFzeS4uLg0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4g PiA+IA0KPiA+ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiANCj4gPiA+ID4gICAgICBTYXNoYQ0KPiA+ ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9y ZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0KPiA+IE9uIEJlaGFsZg0KPiA+ID4gPiBPZiBN YWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXQ0KPiA+ID4gPiBTZW50 OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzoyNCBQTQ0KPiA+ID4gPiBUbzogJ0FkcmlhbiBG YXJyZWwnDQo+ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJl OiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KPiA+ ID4gPiByZXF1aXJlbWVudHMNCj4gPiA+ID4gDQo+ID4gPiA+IEFkcmlhbiwNCj4gPiA+ID4gDQo+ ID4gPiA+ID4+IDxxdW90ZT4NCj4gPiA+ID4gPj4gICAgICBUaGUgaW50ZXJtZWRpYXRlIG5vZGVz IChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQNCj4gPiA+ID4gb3RoZXIgaW50ZXJuYWwNCj4gPiA+ ID4gPj4gICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZA0KPiA+ ID4gPiBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPiA+ID4gPiA+PiAgICAgICBwYXRoIGF0IGVh Y2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KPiA+ID4gPiA+PiAg ICAgICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KPiA+ID4g PiBkaXJlY3Rpb25zIG9mIHRoYXQNCj4gPiA+ID4gPj4gICAgICAgdHJhbnNwb3J0IHBhdGguDQo+ ID4gPiA+ID4+IDxlbmQgcXVvdGU+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGVyZSBpcyBubyB3 YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCj4gPiA+IGlzLCB0aGVy ZSBpcw0KPiA+ID4gPiA+ICpub3RoaW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxh Y2sgYm94IHBvaW50IG9mDQo+ID4gPiB2aWV3IHRoYXQNCj4gPiA+ID4gPiByZXN1bHRzIGZyb20g YWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC4NCj4gPiA+ID4gDQo+ID4gPiA+IFlvdXIgdW5k ZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gSXQgaXMgdmVyeSBtdWNoDQo+IG9ic2VydmFibGUg aWYNCj4gPiA+ID4gdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgZnJvbSBhIGJsYWNrIGJveCBwb2lu dCBvZiB2aWV3Lg0KPiA+ID4gPiBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJmb3JtIHRo ZSBMb29wYmFjayB3aGVuIHRoZXJlIGlzIGEgDQo+ID4gPiA+IGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCBwYXRoLiBUaGUgTVBMUy1UUCBMQk0gcGFja2V0IA0KPiA+ID4gPiByZWNl aXZlZCBhdCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5lZCAoYXMgTEJSDQo+ID4gPiA+IHBhY2tl dCkgdG8gdGhlIG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhlIG90aGVyDQo+ID4gZGly ZWN0aW9uIG9mDQo+ID4gPiA+IHRoZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQg cGF0aC4gVGhpcyBvdGhlcg0KPiBkaXJlY3Rpb24NCj4gPiA+ID4gd291bGQgbm90IGJlIGF2YWls YWJsZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IA0KPiA+ID4gPiBw YXRoLi4uIGFuZCB0aHVzIHRoZSBsb29wYmFjayB0ZXN0DQo+ID4gPiB3b3VsZCBmYWlsLg0KPiA+ ID4gPiANCj4gPiA+ID4gU2ltaWxhcmx5LCB3aGVuIHdlIGhhdmUgdG8gYXBwbHkgVENNIE1FUHMg dG8gbW9uaXRvciBhDQo+ID4gc2VnbWVudCwgdGhlbg0KPiA+ID4gPiB0aGlzIGlzIHBvc3NpYmxl IGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoDQo+IGJ1dCBub3QgaW4gYQ0KPiA+ ID4gPiBhc3NvY2lhdGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoLiBJbiB0aGUgZmlyc3QgY2FzZSB0 aGUgVENNIE1FUCANCj4gPiA+ID4gU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucyBhcmUgY28tbG9j YXRlZCBhbmQgY2FuDQo+IGV4Y2hhbmdlIHdoYXQgaXMNCj4gPiA+ID4gY2FsbGVkICJyZW1vdGUg aW5mb3JtYXRpb24iIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgcGVyZm9ybWFuY2UgDQo+ID4gPiA+ IG1vbml0b3JpbmcuDQo+ID4gPiA+IEluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgVENNIE1FUCBTb3Vy Y2UgYW5kIFNpbmsgZnVuY3Rpb25zDQo+ID4gYXJlIGluIGUuZy4gDQo+ID4gPiA+IGRpZmZlcmVu dCBub2RlcyBpbiB0aGUgbmV0d29yayBhbmQgVENNIHdvdWxkIG5vdCBiZSBhYmxlDQo+ID4gdG8g cHJvdmlkZQ0KPiA+ID4gPiBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLg0KPiA+ID4gPiANCj4gPiA+ ID4gPiBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBz LA0KPiA+ID4gTUlQcyBhbmQgb3RoZXINCj4gPiA+ID4gaW50ZXJuYWwNCj4gPiA+ID4gPiBmdW5j dGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4gSXQgZG9lcyBub3QNCj4g PiA+ID4gYWRkIHRvICJUaGUNCj4gPiA+ID4gPiBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KPiA+ID4g PiANCj4gPiA+ID4gWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBjb3JyZWN0LiBUaGlzIHRleHQg bXVzdCBub3QgYmUNCj4gPiBkZWxldGVkIGF0DQo+ID4gPiA+IGFsbC4NCj4gPiA+ID4gDQo+ID4g PiA+ID4gQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudA0K PiA+ID4gaW5zaXN0ZW5jZSBvbiB0aGUNCj4gPiA+ID4gaW5jbHVzaW9uDQo+ID4gPiA+ID4gb2Yg IlRhbmRlbSBDb25uZWN0aW9uLiIgVGhlIGRlZmluaXRpb24gd2l0aGluIHRoZSBJVFUtVCBvZg0K PiA+ID4gPiB0aGlzIHRlcm0NCj4gPiA+ID4gPiBpcw0KPiA+ID4gPiBwb29ybHkNCj4gPiA+ID4g PiBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1vbml0b3Jpbmcgb2YgYSBwYXRoIHRoYXQg aXMNCj4gPiA+ID4gcGFyYWxsZWwgKGkuZS4NCj4gPiA+ID4gdGFuZGVtKQ0KPiA+ID4gPiA+IHRv IHRoZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24gb2YgVEMNCj4g PiA+ID4gc2VlbXMgdG8gYmUgYXQNCj4gPiA+ID4gdmFyaWFuY2UsDQo+ID4gPiA+ID4gYW5kIHdv dWxkIGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQo+ID4gPiA+IA0KPiA+ID4g PiBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRhdGlvbiBvZiB0YW5kZW0N Cj4gPiBjb25uZWN0aW9uIGlzDQo+ID4gPiA+IGRlc2NyaWJlZCBpbiBJVFUtVCByZWNvbW1lbmRh dGlvbnMuIEkuZS4gImZyb20gdGhlDQo+ID4gbW9uaXRvcmluZyBvZiBhDQo+ID4gPiA+IHBhdGgg dGhhdCBpcyBwYXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgDQo+ ID4gPiA+IG1vbml0b3JlZC4iPw0KPiA+ID4gPiANCj4gPiA+ID4gVGhlcmUgaXMgYSAibmV0d29y ayBjb25uZWN0aW9uIiBhbmQgdGhpcyBuZXR3b3JrDQo+ID4gY29ubmVjdGlvbiBpcyBhIHNldA0K PiA+ID4gPiBvZiBpbnRlcmNvbm5lY3RlZCAibGluayBjb25uZWN0aW9ucyIgYW5kICJtYXRyaXgN Cj4gY29ubmVjdGlvbnMiLiBBDQo+ID4gPiA+IHN1YnNldCBvZiB0aG9zZSBpbnRlcmNvbm5lY3Rl ZCBsaW5rIGNvbm5lY3Rpb25zIGFuZCBtYXRyaXggDQo+ID4gPiA+IGNvbm5lY3Rpb25zIGNhbiBi ZSBtb25pdG9yZWQgYW5kIGlzIHRoZW4gcmVmZXJyZWQgdG8gYXMNCj4gYSAidGFuZGVtDQo+ID4g PiA+IGNvbm5lY3Rpb24iLiBUaGVyZSBpcyBubyAicGF0aCB0aGF0IGlzIHBhcmFsbGVsIHRvIHRo ZQ0KPiA+IGRhdGEgcGF0aCIuIA0KPiA+ID4gPiBUaGVyZSBpcyBvbmx5IGFkZGl0aW9uYWwgT0FN IGluc2VydGVkIGluc2lkZSB0aGUgZGF0YQ0KPiBwYXRoIGJ5IHRoZQ0KPiA+ID4gPiBUQ00gTUVQ X1NvIGZ1bmN0aW9uIGFuZCB0aGlzIE9BTSBpcyBleHRyYWN0ZWQgZnJvbSB0aGUNCj4gPiBkYXRh IHBhdGggYnkNCj4gPiA+ID4gdGhlIFRDTSBNRVBfU2sgZnVuY3Rpb24uDQo+ID4gPiA+IA0KPiA+ ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiBNYWFydGVuDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogbXBscy10cC1ib3Vu Y2VzQGlldGYub3JnDQo+ID4gPiA+IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiA+ID4gPiBTZW50OiBkb25kZXJkYWcgMTYgYXBy aWwgMjAwOSAxMTo1OQ0KPiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGJlbmphbWlu Lm5pdmVuLWplbmtpbnNAYnQuY29tDQo+ID4gPiA+IENjOiBCVVNJIElUQUxPOyBtcGxzLXRwQGll dGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KPiA+ID4gPiByZXF1aXJlbWVudHMNCj4gPiA+ID4gDQo+ ID4gPiA+IEhpIFNhc2hhLA0KPiA+ID4gPiANCj4gPiA+ID4gPiBVbmZvcnR1bmF0ZWx5IEkgY2Fu bm90IGZ1bGx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQ6DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiA8cXVvdGU+DQo+ID4gPiA+ID4gICAgIEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdh cmUsIGNvLXJvdXRlZA0KPiA+ID4gYmlkaXJlY3Rpb25hbCBMU1BzDQo+ID4gPiA+ID4gICAgIGFy ZSBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4gPiA+ ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBzdGF0ZW1lbnQgd291 bGQgYmUgb2J2aW91c2x5IGNvcnJlY3QsIHdlcmUgaXQgbm90IGZvcg0KPiA+ID4gPiBSZXF1aXJl bWVudA0KPiA+ID4gPiA+IDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCByZXF1aXJlbWVudHMgZHJh ZnQNCj4gPiA+ID4gDQo+ID4gPiA+IE9LLiBHb3QgaXQuDQo+ID4gPiA+IA0KPiA+ID4gPiBCdXQg d2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cyBzZWN0aW9u Pw0KPiA+ID4gPiANCj4gPiA+ID4gSW4gZmFjdCwgd2hhdCBpcyB0aGlzIHJlcXVpcmVtZW50IGFj dHVhbGx5IHNheWluZz8NCj4gPiA+ID4gDQo+ID4gPiA+ID4gPHF1b3RlPg0KPiA+ID4gPiA+ICAg ICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5kDQo+ID4g PiBvdGhlciBpbnRlcm5hbA0KPiA+ID4gPiA+ICAgICAgIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0 ZSkgb2YgYSBjby1yb3V0ZWQNCj4gPiA+ID4gYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCj4gPiA+ ID4gPiAgICAgICBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUg cGFpcmluZw0KPiA+ID4gPiA+ICAgICAgIHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQg dGhlIGJhY2t3YXJkDQo+ID4gPiA+IGRpcmVjdGlvbnMgb2YgdGhhdA0KPiA+ID4gPiA+ICAgICAg IHRyYW5zcG9ydCBwYXRoLg0KPiA+ID4gPiA+IDxlbmQgcXVvdGU+DQo+ID4gPiA+IA0KPiA+ID4g PiBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQN Cj4gPiBpcywgdGhlcmUgaXMNCj4gPiA+ID4gKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVk IGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCj4gPiB2aWV3IHRoYXQNCj4gPiA+ID4gcmVzdWx0 cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuDQo+ID4gPiA+IA0KPiA+ID4gPiBU aGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgaXMgbWV0 IGJ5IA0KPiA+ID4gPiBjb25maWd1cmluZyBzb21lIGRhdGEgcGxhbmUgZGF0YWJhc2UgY29tcG9u ZW50IHRocm91Z2ggdGhlIA0KPiA+ID4gPiBtYW5hZ2VtZW50IHBsYW5lLiBUaGUgZGF0YWJhc2Ug Y29tcG9uZW50IGlzIG5vdCB1c2VkDQo+IGZvciBhbnl0aGluZw0KPiA+ID4gPiBleGNlcHQgdG8g c2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAiYXdhcmVuZXNzIi4NCj4gPiA+ID4gDQo+ID4g PiA+IEJlbiEgQ2FuIHdlIHBsZWFzZSB0cnkgdG8gcmV3cml0ZSB0aGlzIHJlcXVpcmVtZW50IGlu IHRlcm1zIG9mIA0KPiA+ID4gPiBiZWhhdmlvcj8NCj4gPiA+ID4gDQo+ID4gPiA+ID4gUGxlYXNl IG5vdGUgdGhhdCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZQ0KPiA+ID4g PiBsaXN0IHRoYXQgaXMNCj4gPiA+ID4gPiBzcGVjaWZpYyBmb3IgY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwgTFNQcy4gKFRoZSBwYWlyaW5nDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiA+ IGF0IGVuZCBwb2ludHMgZm9yIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs DQo+ID4gPiBwYXRocyBhcmUNCj4gPiA+ID4gPiBleGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhl eSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudA0KPiA+ID4gaXRlbXMgaW4gdGhlDQo+ID4gPiA+ID4g cmVxdWlyZW1lbnRzJyBsaXN0KS4NCj4gPiA+ID4gPiBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCBS ZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mDQo+IGNvLXJvdXRlZA0KPiA+ID4gPiA+IGJpZGly ZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50Lg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVx dWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbCANCj4gPiA+ID4gPiBmdW5jdGlvbnMgYXMgYXBwcm9w cmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcNCj4gPiA+ID4gc3VwcG9ydCBvZiB0 aGUNCj4gPiA+ID4gPiBwYWlyaW5nIGF3YXJlbmVzcyBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIg dG8gY29tcGx5IHdpdGggaXQuDQo+ID4gPiA+IA0KPiA+ID4gPiBUaGUgZW50aXJldHkgb2YgdGhl IGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBzLA0KPiA+IE1JUHMgYW5kIG90aGVyDQo+ ID4gPiA+IGludGVybmFsIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkiIHNob3VsZCBiZSBkZWxl dGVkLiBJdA0KPiA+IGRvZXMgbm90DQo+ID4gPiA+IGFkZCB0byAiVGhlIGludGVybWVkaWF0ZSBu b2Rlcy4iDQo+ID4gPiA+IA0KPiA+ID4gPiA+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJh ZnQgaW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPHF1b3Rl Pg0KPiA+ID4gPiA+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rpb24gaXMg YW4NCj4gPiBhcmJpdHJhcnkgcGFydCBvZiBhDQo+ID4gPiA+ID4gICB0cmFuc3BvcnQgcGF0aCB0 aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pDQo+ID4gPiA+IGluZGVwZW5kZW50bHkgZnJv bSB0aGUNCj4gPiA+ID4gPiAgIGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gIEl0IG1heSBi ZSBhIG1vbml0b3JlZA0KPiA+IHNlZ21lbnQgb3IgYQ0KPiA+ID4gPiA+ICAgbW9uaXRvcmVkIGNv bmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguIA0KPiA+IFRoZSB0YW5kZW0N Cj4gPiA+ID4gPiAgIGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0aGUgZm9yd2FyZGluZyBl bmdpbmUocykgb2YNCj4gPiA+ID4gdGhlIG5vZGUocykNCj4gPiA+ID4gPiAgIGF0IHRoZSBlZGdl KHMpIG9mIHRoZSBzZWdtZW50IG9yIGNvbmNhdGVuYXRlZCBzZWdtZW50Lg0KPiA+ID4gPiA+IDxl bmQgcXVvdGU+DQo+ID4gPiA+IA0KPiA+ID4gPiBBY3R1YWxseSwgSSBhbSBxdWl0ZSBmZWQgdXAg YWJvdXQgdGhpcyBwZXJzaXN0ZW50DQo+ID4gaW5zaXN0ZW5jZSBvbiB0aGUNCj4gPiA+ID4gaW5j bHVzaW9uIG9mICJUYW5kZW0gQ29ubmVjdGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbg0KPiA+ IHRoZSBJVFUtVCBvZg0KPiA+ID4gPiB0aGlzIHRlcm0gaXMgcG9vcmx5IHNwZWNpZmllZCBhbmQg Y29tZXMgZnJvbSB0aGUNCj4gbW9uaXRvcmluZyBvZiBhDQo+ID4gPiA+IHBhdGggdGhhdCBpcyBw YXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgDQo+ID4gPiA+IG1v bml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRDIHNlZW1zIHRvIGJlIGF0IHZhcmlhbmNlLA0K PiA+IGFuZCB3b3VsZA0KPiA+ID4gPiBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5k Lg0KPiA+ID4gPiANCj4gPiA+ID4gPiBEb2Vzbid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgc291bmQg bGlrZSBoYXJkd2FyZSB0byB5b3U/DQo+ID4gPiA+IA0KPiA+ID4gPiBZZXMsIGJ1dCBzbyB3aGF0 Pw0KPiA+ID4gPiANCj4gPiA+ID4gPiBJTUhPIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IG5laXRo ZXIgdGhlIE1QTFMtVFANCj4gPiA+IFJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ID4gPiA+IG5vciB0 aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIG9uZQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiANCj4g PiA+IA0KPiA+IA0KPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1tcGxzLXRwLW9hbS1yZXF1aXJlbWVuDQo+ID4gPiA+ID4gdHMtMDEudHh0KSBjb250YWlu IGFueSByZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoIHRhbmRlbQ0KPiA+ID4gY29ubmVjdGlvbnMu DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCdXQgdGFuZGVtIGNvbm5lY3Rpb25zIGFyZSBkaXNjdXNz ZWQgaW4gdGhlIE1QTFMtVFAgT0FNDQo+ID4gRnJhbWV3b3JrDQo+ID4gPiA+ID4gZHJhZnQNCj4g PiA+ID4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBs cy10cC1vYW0tZnINCj4gPiA+ID4gYW1ld29yay0wMC50eHQNCj4gPiA+ID4gKS4NCj4gPiA+ID4g DQo+ID4gPiA+IFJpZ2h0Lg0KPiA+ID4gPiBMZXQncyBqdXN0IGdldCByaWQgb2YgYW4gdW5uZWNl c3NhcnkgdGVybSBhbmQgYnJpbmcgYWxsDQo+IHRoZSBJLURzDQo+ID4gPiA+IGludG8gbGluZS4N Cj4gPiA+ID4gDQo+ID4gPiA+ID4gVGhlIGJvdHRvbSBsaW5lLCBJTUhPLCBpcyB0aGF0IHNvbWUg Y2xhcml0eSByZWdhcmRpbmcNCj4gPiA+IGNvLXJvdXRlZCB2cy4NCj4gPiA+ID4gPiBhc3NvY2lh dGVkDQo+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25l IHdheSB0byBwcm92aWRlDQo+ID4gPiA+IHRoYXQgY291bGQNCj4gPiA+ID4gPiBiZSBieSBleHBs aWNpdGx5IGxpbWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNwZWNpZmljDQo+ID4gPiBmdW5jdGlv bmFsaXR5Lg0KPiA+ID4gPiANCj4gPiA+ID4gQWdyZWVkLg0KPiA+ID4gPiANCj4gPiA+ID4gQWRy aWFuDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEZyb206IEFkcmlh biBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBB cHJpbCAxNiwgMjAwOSAxMjoxMyBBTQ0KPiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47 IExvdSBCZXJnZXI7IEJVU0kgSVRBTE8NCj4gPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4g PiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGggDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiANCj4gPiA+ID4gSGkg U2FzaGEsDQo+ID4gPiA+IA0KPiA+ID4gPiBOb3QgcmVhbGx5IHN1cmUgd2hldGhlciB5b3UgYXJl IG1pc3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLg0KPiA+ID4gPiANCj4gPiA+ID4gPiAxLiBN eSByZWFkaW5nIG9mICBvbmUgb2YgQmVuJ3MgIG1lc3NhZ2VzIGlzIHRoYXQgYXNzb2NpYXRlZCAN Cj4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBvZiBwYXRo cyB0aGF0IGNhbiBiZQ0KPiA+ID4gPiBjcmVhdGVkIGluDQo+ID4gPiA+ID4gdGhlIGV4aXN0aW5n IG5ldHdvcmtzOyAidHJ1ZSIgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMNCj4gPiA+ID4g d2lsbCBoYXZlDQo+ID4gPiA+ID4gdG8gd2FpdCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVu dCBiZWNvbWVzIGF2YWlsYWJsZS4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoaXMgaXMgY2xlYXJseSBu b25zZW5zZSENCj4gPiA+ID4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28t cm91dGVkDQo+ID4gYmlkaXJlY3Rpb25hbCBMU1BzIGFyZQ0KPiA+ID4gPiBhIHNwZWNpYWwgY2Fz ZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4gPiA+ID4gDQo+ID4gPiA+IElm IHlvdSBjYW4gc2V0IHVwIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzIChlLmcuIHVzaW5nIHRoZQ0K PiA+IG1hbmFnZW1lbnQNCj4gPiA+ID4gcGxhbmUpIHlvdSBjYW4gc3VyZWx5IHNldCB1cCBhIGNv LXJvdXRlZA0KPiA+ID4gYmlkaXJlY3Rpb25hbCBMU1AuDQo+ID4gPiA+IA0KPiA+ID4gPiBUaGVy ZSBhcmUgc2hpcHBpbmcgc29sdXRpb25zIHRoYXQgYWNoaWV2ZSBjby1yb3V0ZWQNCj4gYmlkaXJl Y3Rpb25hbA0KPiA+ID4gPiBMU1BzIHVzaW5nIHRoZSBjb250cm9sIHBsYW5lLiBUaGVzZSBlaXRo ZXIgdXNlIHRoZSBHTVBMUw0KPiA+ICh3aGljaCBpcw0KPiA+ID4gPiBjbGVhbmVyKSBvciBub24t c3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpcw0KPiA+IG1lc3N5IGJ1dA0K PiA+ID4gPiBmdW5jdGlvbmFsKS4NCj4gPiA+ID4gDQo+ID4gPiA+IEJ1dCAob2YgY291cnNlKSB0 aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lDQo+ID4gc29sdXRpb25zIGhhdmUN Cj4gPiA+ID4gbm90aGluZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgYXMg dGhleQ0KPiBhcmUgc29mdHdhcmUNCj4gPiA+ID4gc29sdXRpb25zLg0KPiA+ID4gPiANCj4gPiA+ ID4gPiAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMgaXMgdGhhdCB0aGUg YWN0dWFsDQo+ID4gPiA+IGRyaXZlciBmb3INCj4gPiA+ID4gPiBjby1yb3V0ZWQgYmlkaXJlY3Rp b25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIA0KPiA+ID4gPiA+IHRy YW5zcG9ydCBuZXR3b3JrcyByYXRoZXIgdGhhbiBhbnkgc3BlY2lmaWMgYmVuZWZpdC4NCj4gPiA+ ID4gDQo+ID4gPiA+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAg cmVxdWlyZW1lbnRzPw0KPiA+ID4gPiBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFkIHRo aW5nLg0KPiA+ID4gPiANCj4gPiA+ID4gQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMtVFAgaXMgdG8g Z2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsNCj4gPiB0aGUgbG9vaywNCj4gPiA+ID4gZmVlbCwgYW5k IGJlaGF2aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgImxlZ2FjeSINCj4gPiA+ID4gdHJhbnNw b3J0IG5ldHdvcmsuDQo+ID4gPiA+IA0KPiA+ID4gPiA+IEJhc2VkIG9uIHRoZXNlIG9ic2VydmF0 aW9ucywgSSdkIGd1ZXNzIChGV0lXKSB0aGF0Og0KPiA+ID4gPiA+ICogYXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIHBhdGhzIGFyZSwgYXQgbGVhc3QgZm9yIHRoZSB0aW1lDQo+ID4gPiA+ID4gICAg YmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mIGJpZGlyZWN0aW9uYWwgcGF0aHMgaW4N Cj4gPiA+ID4gPiAgICBNUExTLVRQDQo+ID4gPiA+IA0KPiA+ID4gPiBJIHRoaW5rIHRoYXQgaXMg d3JvbmcgYm90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZA0KPiA+IGdpdmVuIHRoYXQN Cj4gPiA+ID4gb3RoZXIgdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBi ZQ0KPiBuZWVkZWQgdG8gcmVhY2gNCj4gPiA+ID4gdGhlIGZ1bGwgZnVuY3Rpb24gbGV2ZWwgb2Yg TVBMUy1UUC4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gKiB0aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRv IHJlbWFpbiB0aGUgb25seSB0eXBlIG9mDQo+ID4gYmlkaXJlY3Rpb25hbA0KPiA+ID4gPiA+ICAg cGF0aHMgaW4gIHJlYWwgZGVwbG95bWVudHMuDQo+ID4gPiA+IA0KPiA+ID4gPiBJIGRvbid0IHNl ZSB3aGF0IHRoYXQgZm9sbG93cyBmcm9tLg0KPiA+ID4gPiANCj4gPiA+ID4gQ2hlZXJzLA0KPiA+ ID4gPiBBZHJpYW4NCj4gPiA+ID4gDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+ID4g PiA+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzLXRwDQo+ID4gPiA+IA0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlz dA0KPiA+ID4gPiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbXBscy10 cCBtYWlsaW5nIGxpc3QNCj4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiA+ID4gDQo+ID4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFp bGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwDQo+IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFy ZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmlj YXRpb24gdG8gDQpvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gDQpzeXN0ZW0uDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 002D8773482575A0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPk5laWw6PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgdGhhbmsgeW91IGZvciB3YXN0aW5n IG1vcmUgdGltZQ0KaW4gZGVzY3JpYmxpbmcgdGhlIHByb2JsZW1zLiBidXQgSSB0aGluayBzb21l IG9mIHdoYXQgeW91IHNhaWQgaXMgbm8gcmVsYXRpb25zDQp3aXRoIG91ciBwcm9ibGVtLmZvciBt ZSwgbWF5YmUgQUlTL0ZESSBmdW5jdGlvbnMgaXMgbm8gc2Vuc2UgaW4gY2wtcHMgLGVnLg0KSVAu IGJ1dCBmb3IgQ08tUFMgbmV0d29ya3MuaWYgdGhlcmUgaXMgbm8gQUlTL0ZESSBmdW5jdGlvbnMs IHdoZW4gdGhlcmUNCmlzIGEgZGVmZWN0cyBpbiBhIGdpdmVuIGxheWVyIG5ldHdvcmssIGl0IGNh biBjYXVzZSBtdWx0aXBsZSBhbGFybSBldmVudHMNCnRvIGJlIHJhaXNlZC4gaXQgaXMgZGlmZmN1 bHQgJm5ic3A7Zm9yIG9wZXJhdG9ycyB0byBsb2NhdGUgYW5kIGRpYWdub3NlDQp0aGUgZmF1bHRz LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7dGhvdWdo IEkgY29tcGxldGVseSBhZ3JlZSB5b3UNCm9uICZuYnNwO2FkZGluZyBuZXcgdGhpbmdzIGFuZCBm dW5jdGlvbnMgd2lsbCBicmluZyBzb21lIGNvbXBsZXhpdHkgLiBidXQNCmlmIHdlIGhhdmUgbm8g ZnVuY3Rpb25zLCBpdCBpcyBtb3JlIGNvbXBsZXggYW5kIGRpZmN1bHQgZm9yIG9wZXJhdG9ycyB0 bw0KbWFpbnRlbmNlIGFuZCBhZG1pbmlzdHJhdG9yIHRoZSBuZXR3b3JrLiBzbyBJIHRoaW5rIGV2 ZXJ5IG5ldyBmdW5jdGlvbnMNCmFuZCB0aGluZ3MgbWF5IGhhdmUgcG9zaXRpdmUgYW5kIG5lZ2F0 aXZlIGVmZmVjdHMuIGJ1dCB3ZSBzaG91bGQgY29uc2lkZXINCml0IHZlcnkgbXVjaCwgZG9uJ3Qg ZGVsZXRlIHNvbWUgZnVuY3Rpb25zIGF0IHJhbmRvbS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmJlc3QgcmVnYXJkczwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+bGl1PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZsdDtuZWlsLjIuaGFycmlzb25AYnQuY29t Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5 LTA0LTIxIDIwOjMwPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZsdDtsaXUuZ3VvbWFuQHp0ZS5jb20uY24mZ3Q7LCAmbHQ7ZGJydW5nYXJk QGF0dC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7bXBscy10cEBpZXRmLm9yZyZndDs8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs DQp0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJs ZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5z IE1TIj5MaXUsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+SWYgTVBMUy1UUCBp cyBnb2luZw0KdG8gYmUgdGFrZW4gc2VyaW91c2x5IGFzIGEgdHJhbnNwb3J0IG5ldHdvcmsgKGxp a2UgU0RIL1NPTkVUKSB0aGVuIHRoZQ0KMiBrZXkgTVVTVCBIQVZFIHJlcXVpcmVtZW50cyBhcmUg dGhlc2UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+MSAmbmJzcDsgJm5ic3A7 UHJvdmlkZQ0KYSB0cmFuc3BhcmVudCBjbGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcC4uLndoaWNo IG1lYW5zOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21p YyBTYW5zIE1TIj4tICZuYnNwOyAmbmJzcDthbGwNCmNsaWVudCBiaXRzIHRyZWF0ZWQgZXF1YWxs eTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5z IE1TIj4tICZuYnNwOyAmbmJzcDtjbGllbnQNCmJpdCBvcmRlcmluZyBwcmVzZXJ2ZWQ8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+LSAm bmJzcDsgJm5ic3A7bm8gYXR0ZW1wdA0KdG8gaW5mZXIgY2xpZW50IHN5bWJvbCAoaWUgc2VxdWVu Y2Ugb2YgY2xpZW50IGJpdHMpIG1lYW5pbmcgYW5kIG5vIGF0dGVtcHQNCnRvIGNoYW5nZSBjbGll bnQgc3ltYm9sczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJD b21pYyBTYW5zIE1TIj4tICZuYnNwOyAmbmJzcDt0aGUNCnRyYWZmaWMgYmVoYXZpb3VyIG9mIGNs aWVudCBYIG11c3Qgbm90IGltcGFjdCB0aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQNCmJ5IGNs aWVudCBZPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+QSBrZXkgY29yb2xsYXJ5 IG9mDQp0aGUgYWJvdmUgaXMgdGhhdCBNUExTLVRQIG11c3Qgb25seSBzdXBwb3J0IHByb3BlciBj b25uZWN0aW9ucyAoaWUgc2luZ2xlDQpzb3VyY2UgY29uc3RydWN0cyk8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjIgJm5i c3A7IFNpbmNlIE1QTFMtVFANCmlzIGEgdHJhbnNwb3J0IG5ldHdvcmsgaXQgaXMgbm90IGEgdG9w LW9mLXN0YWNrIG5ldHdvcmsgKGllIGl0IGRvZXMgbm90DQpzdXBwb3J0IGRpcmVjdGx5IGV4dGVy bmFsIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zKS4gJm5ic3A7TVBMUy1UUA0KdGhl cmVmb3JlIGRvZXMgbm90IHJlcXVpcmUgYW4gRS1OTkkgc3BlY2lmaWNhdGlvbi4gJm5ic3A7QSBr ZXkgY29yb2xsYXJ5DQpvZiB0aGlzIGlzIHRoYXQgTVBMUy1UUCB3aWxsIG5vdCBoYXZlIGFueSBw ZWVyIGludGVyd29ya2luZyByZWxhdGlvbnNoaXANCndpdGggYW55IG90aGVyIG5ldHdvcmsgbW9k ZS90ZWNobm9sb2d5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAw MDAgZmFjZT0iQ29taWMgU2FucyBNUyI+Tm93IHdydCBPQU0gTVBMUy1UUA0KaXMgYSBjby1wcyBt b2RlIG5ldHdvcmsuICZuYnNwO1lvdSBjb3VsZCBhcmd1ZSB0aGlzIHNob3VsZCBoYXZlIEZESS9B SVMuLi4uaG93ZXZlciwNCnRoZSBtZXJpdCBvZiB0aGlzIGlzIGhpZ2hseSBxdWVzdGlvbmFibGUu ICZuYnNwO1doZW4gSSBhbmQgY29sbGVhZ3VlcyBkaXNjdXNzZWQNCndoZXRoZXIgUEJCLVRFIChh bHNvIGEgY28tcHMgbW9kZSBuZXR3b3JrKSBzaG91bGQgaGF2ZSBGREkvQUlTIHdlIGNvbmNsdWRl ZA0KdGhhdCBvbiBiYWxhbmNlIGl0IHdhcyBub3QgYSBnb29kIGlkZWEuLi4uLmFuZCBub3RlIHRo YXQgaW5pdGlhbGx5IEkgd2FzDQppbiBmYXZvdXIgb2YgaGF2aW5nIEFJUywgYnV0IG15IGNvbGxl YWd1ZXMgcHJvdmlkZWQgc3Ryb25nIHRlY2huaWNhbCBhcmd1bWVudHMNCnRoYXQgY29udmluY2Vk IG1lIG90aGVyd2lzZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj5BSVMvRkRJ IGlzIGhpc3RvcmljYWxseQ0KbGlua2VkIHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXll ciBuZXR3b3JrcyB0aGF0IHVzZWQgVFRMIGxvZ2ljLg0KJm5ic3A7V2hlbiB0aGlzIGRpZWQgaXQg cHV0IG91dCBhICs1ViAoYWxsIDFzKSBzaWduYWwgYnkgZGVmYXVsdCwgaWUgaXQNCnJlcXVpcmVk IG5vIGNvbnNjaW91cyBlZmZvcnQgdG8gZ2VuZXJhdGUgaXQuLi4uLnRoaXMgaXMga2V5IHBvaW50 LiAmbmJzcDtGdXJ0aGVyLA0KaW4gdGhlc2UgbmV0d29ya3MgdGhlcmUgaXMgYSBmYWlybHkgc3Rh dGljL2xvbmctaG9sZGluZyBjbGllbnQgc2VydmVyIHJlbGF0aW9uc2hpcC4NCiZuYnNwO0NsZWFy bHkgdGhpcyBpcyBub3QgdHJ1ZSBpbiB0aGUgY2wtcHMgbW9kZSBhbmQgaXQncyB3aHkgSUVURiBo YXZlDQpuZXZlciBzcGVjaWZpZWQgQUlTIGZvciBJUCBhbmQgaXRzIHdoeSBJRUVFIGhhZCB0aGUg Z29vZCBzZW5zZSB0byB0aHJvdy1vdXQNCkFJUyBpbiA4MDIuMWFnIGZvciBFdGhlcm5ldCAodGhv dWdoIElUVSBoYXZlIHVud2lzZWx5IElNTyByZXRhaW5lZCBpdCBpbg0KWS4xNzMxLi4uLmJ1dCBJ IHN1c3BlY3QgYW55IG9wZXJhdG9yIHBsYW5uaW5nIHRvIHVzZSBFdGhlcm5ldCBlcXVpcG1lbnQN CndvdWxkIGFsd2F5cyBsb29rIHRvIElFRUUgc3RkcyBhbmQgbm90IElUVSBvbmVzKS48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj5BSVMvRkRJIGFuZCB0aGUgY28tcHMNCm1vZGUg aXMgZGViYXRhYmxlLiAmbmJzcDtBcyBJIG5vdGVkIGFib3ZlLCBvbiBiYWxhbmNlIHdlIGNvbnNp ZGVyZWQgbm90DQphIGdvb2QgaWRlYSBmb3IgUEJCLVRFIE9BTSBiZWNhdXNlIGl0IHJlcXVpcmVz IGEgY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0ZQ0KaXQgKHVubGlrZSB0aGUgY28tY3MgbW9k ZSkgc28gdGhlcmUgYXJlIGxpa2VseSB0byBiZSBzY2FsaW5nIHByb2JsZW1zIGFuZA0KaXRzIG9u ZSBtb3JlIHRoaW5nIHRvIGdvIHdyb25nLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMg TVMiPllvdSBzaG91bGQgYWxzbyBoYXZlDQpzZWVuIG1lIG1ha2UgdGhlIHBvaW50IG1hbnkgdGlt ZXMgaW4gdGhlIHBhc3QgdGhhdCB0aGUgYWx3YXlzLW9uIGRlZmVjdA0KZGV0ZWN0aW9uL2hhbmRs aW5nIE9BTSBuZWVkcyB0byBiZSBhcyBzaW1wbGUvc3BhcnNlIGFzIHBvc3NpYmxlIHdpdGggYXMN CmxpdHRsZSBjb25maWcgYXMgcG9zc2libGUgYmVjYXVzZSB3ZSBuZWVkIHN1cGVyIHJlbGlhYmls aXR5Li4uLi4uVENNIGdvZXMNCmNvbXBsZXRlbHkgYWdhaW5zdCB0aGUgZ3JhaW4gaGVyZS4gJm5i c3A7QWxzbyBub3RlIHRoYXQgdGhlIE9BTSByZXF1aXJlZA0KZm9yIGVhY2ggb2YgdGhlIDMgbmV0 d29yayBtb2RlcyBpcyBub3QgdGhlIHNhbWUsIGRlc3BpdGUgd2hhdCBzb21lIGNsYWltLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPnJlZ2FyZHMsIE5laWw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxocj48Zm9udCBzaXplPTIg ZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5saXUuZ3Vv bWFuQHp0ZS5jb20uY248Yj48YnI+DQpTZW50OjwvYj4gMjEgQXByaWwgMjAwOSAwMjo1OTxiPjxi cj4NClRvOjwvYj4gQlJVTkdBUkQsIERFQk9SQUggQSwgQVRUTEFCUzxiPjxicj4NCkNjOjwvYj4g bXBscy10cEBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW21wbHMtdHBdIEFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHM8L2ZvbnQ+PGZv bnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkRlYm9y YWg8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+OjwvZm9udD48Zm9u dCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiBt YXliZSB3aGF0IHlvdSBzYWlkIGlzIHJpZ2h0LiBidXQgSSBjYW4ndCBjb21wbGV0ZWx5IGFncmVl IHlvdXIgb3BpbmlvbnMuDQpJTU8uIG1wbHMtdHAgaXMgcmVnYXJkIGFzIHRyYW5zcG9ydCBuZXR3 b3JrIGxpa2UgU0RIL1NPTkVULiBzbyBpdCBzaG91bGQNCmhhdmUgQUlTL0ZESSBmdWN0aW9ucyBh cyBTREgvU09ORVQuPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpkbyB5b3UgdGhpbmsgc28uPC9mb250Pjxmb250IHNp emU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpi ZXN0IHJlZ2FyZHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCmxpdSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwv Zm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDIl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtCUlVOR0FSRCwgREVCT1JB SA0KQSwgQVRUTEFCUyZxdW90OyAmbHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9iPiA8YnI+DQq3 orz+yMs6ICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTM+ IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTIwIDIz OjQ3PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjx0ZCB3aWR0aD01NyU+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTclPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250Pjwv ZGl2Pg0KPHRkIHdpZHRoPTkyJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7 TWFhcnRlbiBWaXNzZXJzJnF1b3Q7DQombHQ7bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20mZ3Q7 LCAmbHQ7bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5tcGxzLXRwQGlldGYub3JnPC9mb250Pjxmb250IHNpemU9Mz4NCjwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwN CnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQg d2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0K PGJyPg0KPC9mb250Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KSSBhZ3JlZSB3aXRoIE5laWwsIGl0 IGlzIHZlcnkgcXVlc3Rpb25hYmxlIHRoZSB2YWx1ZSBvZiBBSVMvRkRJIGluIGE8YnI+DQpwYWNr ZXQgbmV0d29yay0gYW55IG1vZGUuIEl0IGNhbiByZXN1bHQgaW4gYSBEb1MgYXR0YWNrIGJ5IGFu IG9wZXJhdG9yPGJyPg0Kb24gdGhlbXNlbHZlcyBzbyBldmVuIFkxNzMxIHJlY29tbWVuZHMgbm90 IHRvIGJsb2NrIGRhdGEgZnJhbWVzOjxicj4NCiZxdW90O0EgTUVQIGNhbiBkZWNpZGUgd2hldGhl ciBpdCBibG9ja3MgZGF0YSBmcmFtZXMgd2hlbiBpdCBkZXRlY3RzIGRBSVMuPGJyPg0KVGhlIHBy aW5jaXBsZSByZXF1aXJlbWVudDxicj4NCnRoYXQgaW5mbHVlbmNlcyB0aGlzIGRlY2lzaW9uIGlz IHRoYXQgZGF0YSBmcmFtZXMgb3VnaHQgdG8gYmUgZm9yd2FyZGVkPGJyPg0KYXMgbXVjaCBhcyBw b3NzaWJsZSwgd2l0aG91dDxicj4NCnRoZSBwb3NzaWJpbGl0eSBvZiBmb3J3YXJkaW5nIHdyb25n IGRhdGEgZnJhbWVzIGRvd25zdHJlYW0uJnF1b3Q7PGJyPg0KVGFibGUgSS43LTIgc2hvd3MgZm9y IEFJUywgbm90IHRvIGJsb2NrLjxicj4NCjxicj4NCkFuZCBhcyBZMTczMSBzdGF0ZXMsIEFJUyBj YW4gb25seSBiZSB1c2VkIHVuZGVyIHZlcnkgY29uc3RyYWluZWQ8YnI+DQphcmNoaXRlY3R1cmVz IC0gaWYgcmVxdWlyZWQgZm9yIE1QTFMtVFAsIGl0IG5lZWRzIHRvIGhhdmUgdGhlIHNhbWU8YnI+ DQpndWlkYW5jZSBhcyBpbiBZMTczMSwgaS5lLiBwb2ludC10by1wb2ludCBhbmQgc2VydmVyL2Ns aWVudCBvbmUtdG8tb25lOjxicj4NCiZxdW90O2ZvciBhIHBvaW50LXRvLXBvaW50IEVUSCBjb25u ZWN0aW9uLCBhIE1FUCBoYXMgb25seSBhIHNpbmdsZSBwZWVyDQpNRVAuPGJyPg0KVGhlcmVmb3Jl LCB0aGVyZTxicj4NCmlzIG5vIGFtYmlndWl0eSByZWdhcmRpbmcgdGhlIHBlZXIgTUVQIGZvciB3 aGljaCBpdCBzaG91bGQgc3VwcHJlc3M8YnI+DQphbGFybXMgd2hlbiBpdCByZWNlaXZlcyB0aGU8 YnI+DQpFVEgtQUlTIGluZm9ybWF0aW9uLiZxdW90Ozxicj4NClNvIHNob3VsZCBvbmx5IGJlIHdp dGhpbiBvbmUgZG9tYWluIC0gdGhlbiBubyBuZWVkLjxicj4NCjxicj4NCkRlYm9yYWg8YnI+DQo8 YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IG1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT248YnI+DQpCZWhh bGYgT2YgTWFhcnRlbiBWaXNzZXJzPGJyPg0KU2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSAx MDowNSBBTTxicj4NClRvOiBuZWlsLjIuaGFycmlzb25AYnQuY29tPGJyPg0KQ2M6IG1wbHMtdHBA aWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCB0cmFuc3BvcnQgcGF0aDxicj4NCnJlcXVpcmVtZW50czxicj4NCjxicj4NCk5laWwsPGJy Pg0KPGJyPg0KJmd0OyBidXQgQUlTL0ZESSBpbiB0aGUgY2wgbW9kZT8uLi5kbyBtZSBhIGZhdm91 ciE8YnI+DQo8YnI+DQpFdGhlcm5ldCBBSVMgaXMgaW5kZWVkIGEgcmVxdWlyZW1lbnQgYW5kIGEg bmVjZXNzaXR5LiBBbmQgeW91IHdpbGwgbm90PGJyPg0KYmU8YnI+DQphYmxlIHRvIHVuZGVyc3Rh bmQgdGhhdCBhcyBsb25nIGFzIHlvdSByZWZ1c2UgdG8gYWNjZXB0IHRoYXQgJnF1b3Q7Y2wtbW9k ZSZxdW90Ozxicj4NCmlzIGE8YnI+DQpmb3J3YXJkaW5nIG1vZGUgd2l0aGluIGEgKip0cmFuc3Bv cnQgZW50aXR5KiouIEcuODAwIGFtZW5kbWVudCAxIGhhczxicj4NCmZpbmFsbHk8YnI+DQpyZWlu dHJvZHVjZWQgdGhpcyB0cmFuc3BvcnQgZW50aXR5IGludG8gRy44MDAuIEJlc2lkZXMgdGhhdCwg aXQgYWxzbzxicj4NCmludHJvZHVjZWQgdGhlICoqZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbioq Ojxicj4NCjxicj4NCltHLjgwMCBhbTFdICZxdW90O0EgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlv biBpcyBhIHRyYW5zcG9ydCBlbnRpdHkgdGhhdDxicj4NCnRyYW5zZmVycyBpbmZvcm1hdGlvbiBi ZWxvbmdpbmcgdG8gbXVsdGlwbGUgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBwb3J0czxicj4NCmFj cm9zcyBhIHN1Ym5ldHdvcmsuICZsdDsuLiZndDsgSW4gYSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0 aW9uIG1lc3NhZ2U8YnI+DQpjb250ZW50czxicj4NCmFyZSBpbnRlcnByZXRlZCB0byBpZGVudGlm eSAoc2V0cyBvZikgY29tbXVuaWNhdGlvbnMgd2hpY2ggcmVjZWl2ZTxicj4NCmRpZmZlcmVudDxi cj4NCnRyZWF0bWVudC4gJm5ic3A7VGhlIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIGRp c3Rpbmd1aXNoZWQgYnkgdGhlPGJyPg0KZm9yd2FyZGluZyBpZGVudGlmaWVyIG9yIG90aGVyIGxh eWVyIGluZm9ybWF0aW9uLiAmbmJzcDtPcmRlciBpcyBub3Q8YnI+DQpuZWNlc3NhcmlseTxicj4N CnByZXNlcnZlZCBiZXR3ZWVuIG1lc3NhZ2VzIGJlbG9uZ2luZyB0byBzZXRzIG9mIGNvbW11bmlj YXRpb25zIHJlY2VpdmluZzxicj4NCmRpZmZlcmVudCB0cmVhdG1lbnQuICZuYnNwO1NldHMgb2Yg Y29tbXVuaWNhdGlvbnMgbWF5IGJlIGlkZW50aWZpZWQgZm9yPGJyPg0KcHVycG9zZXM8YnI+DQpz dWNoIGFzIHRyYWZmaWMgY29uZGl0aW9uaW5nIG9yIHByZXNlcnZpbmcgY29tbXVuaWNhdGlvbiBt ZXNzYWdlIG9yZGVyLiZxdW90Ozxicj4NCjxicj4NCjxicj4NCkV0aGVybmV0IFZMQU5zIGFyZSBp biB0ZXJtcyBvZiBHLjgwMCAmcXVvdDtkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9ucyZxdW90Oy48 YnI+DQpFdGhlcm5ldDxicj4NCkFJUyBwcm92aWRlcyBBSVMgd2l0aGluIHRoZSBzY29wZSBvZiBz dWNoICZxdW90O2RpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24mcXVvdDsuPGJyPg0KSWY8YnI+DQp5 b3UgYXBwbHkgdGhpcyB0byBteSBwcm9wb3NlZCBQVE4gbGF5ZXIgc3RhY2ssIHRoZW4gdGhlIEVW QyBsYXllcjxicj4NCnRvcG9sb2d5PGJyPg0Kd2lsbCBjb25zaXN0cyBvZiBFVkMgbGlua3Mgc3Vw cG9ydGVkIGJ5IE1QTFMtVFAsIEV0aGVybmV0LCBQQkItVEUgYW5kPGJyPg0KUC1PVE48YnI+DQpW UCB0cmFpbHMgaW5zaWRlIG1ldHJvIGFuZCBjb3JlIGRvbWFpbnMgaW50ZXJjb25uZWN0aW5nIEVW QyBtYXRyaWNlcy48YnI+DQpXaGVuPGJyPg0Kb25lIG9mIHRob3NlIEVWQyBsaW5rcyBpcyBpbnRl cnJ1cHRlZCwgZS5nLiBpbiB0aGUgY29yZSBiZXR3ZWVuIG1ldHJvIDE8YnI+DQphbmQ8YnI+DQpt ZXRybyA0IChzZWUgYXR0YWNoZWQgc2xpZGUpLCB0aGVuIHRoZSBFVkMgZGlmZmVyZW50aWF0ZWQg Y29ubmVjdGlvbjxicj4NCnRoYXQgaXM8YnI+DQpwcmVzZW50IG9uIHRoaXMgbGluayB3aWxsIGJl IGludGVycnVwdGVkLiBBdCB0aGUgRVZDIHN3aXRjaC9icmlkZ2Ugbm9kZTxicj4NCmluPGJyPg0K bWV0cm8gNCB0aGlzIGludGVycnVwdGlvbiBpcyBub3RpY2VkIGFuZCBFVkMtQUlTIGlzIGluc2Vy dGVkIGluIHRoZTxicj4NCmRvd25zdHJlYW0gZGlyZWN0aW9uIHRvIHN1cHByZXNzIHRoZSBFVkMt TE9DIGFsYXJtcyBhdCBFVkMgZW5kcG9pbnRzIEQ0PGJyPg0KYW5kPGJyPg0KRDUuPGJyPg0KPGJy Pg0KVGhlIEVWQy1BSVMgKGkuZS4gRXRoZXJuZXQgQUlTKSBmcmFtZSBoYXMgYSByZXNlcnZlZCBt dWx0aWNhc3QgYWRkcmVzcyw8YnI+DQp3aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIEFJUyBpcyBi cm9hZGNhc3QgdG8gdGhlIGVuZHBvaW50cyBvZiB0aGUgRVZDLjxicj4NCjxicj4NCkkgYmVsaWV2 ZSB0aGF0IGl0IGlzIHRpbWUgZm9yIHlvdSB0byBhZGFwdCB5b3VyIHZpZXcgb24gY28gYW5kIGNs IG1vZGVzPGJyPg0KYW5kPGJyPg0KcmVsYXRlIGl0IHRvIHRoZSBmb3J3YXJkaW5nIG1vZGUgKipJ TlNJREUqKiBhIHRyYW5zcG9ydCBlbnRpdHkuIDxicj4NCjxicj4NCldoYXQgd2Uga25vdyBhcyB0 aGUgaW50ZXJuZXQgaXMgZXNzZW50aWFsbHkgYW4gJnF1b3Q7SVAgZGlmZmVyZW50aWF0ZWQ8YnI+ DQpjb25uZWN0aW9uJnF1b3Q7IHdpdGggYSBiaWxsaW9uIG9yIG1vcmUgcG9ydHMuPGJyPg0KV2hh dCB3ZSBrbm93IGFzIGFuIElQIFZQTiBpcyBlc3NlbnRpYWxseSBhbiAmcXVvdDtJUCBkaWZmZXJl bnRpYXRlZDxicj4NCmNvbm5lY3Rpb24mcXVvdDs8YnI+DQp3aXRoIGUuZy4gbiBwb3J0cyAobiBp biB0aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEwMDApLjxicj4NCldoYXQgd2Uga25vdyBhcyBhbiBF dGhlcm5ldCBWTEFOIGlzIGVzc2VudGlhbGx5IGFuICZxdW90O0V0aGVybmV0PGJyPg0KZGlmZmVy ZW50aWF0ZWQ8YnI+DQpjb25uZWN0aW9uJnF1b3Q7IHdpdGggbiBwb3J0cyAobiBpbiB0aGUgcmFu Z2Ugb2YgZS5nLiAyIHRvIDEwMDApLjxicj4NCldoYXQgd2Uga25vdyBhcyBhIHAycCBNUExTIEUt TFNQIGlzIGVzc2VudGlhbGx5IGFuICZxdW90O01QTFMgZGlmZmVyZW50aWF0ZWQ8YnI+DQpjb25u ZWN0aW9uJnF1b3Q7IHdpdGggMiBwb3J0cy48YnI+DQpXaGF0IHdlIGtub3cgYXMgYSBwMnAgU0RI IFZDLW4gaXMgYSAmcXVvdDtTREggVkMtbiBjb25uZWN0aW9uJnF1b3Q7IHdpdGgNCjIgcG9ydHMu PGJyPg0KPGJyPg0KVHJhbnNwb3J0IG5ldHdvcmsgT0FNIGFwcGxpZXMgdG8gdHJhbnNwb3J0IGVu dGl0aWVzLCB3aGljaCBhcmUgKGluIHRlcm1zPGJyPg0Kb2Y8YnI+DQpHLjgwMCBhbTEpIGNvbm5l Y3Rpb25zIGFuZCBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9ucy48YnI+DQo8YnI+DQpSZWdhcmRz LDxicj4NCk1hYXJ0ZW48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IG5laWwuMi5oYXJyaXNvbkBidC5jb20gW21haWx0bzpuZWlsLjIuaGFycmlzb25AYnQu Y29tXSA8YnI+DQpTZW50OiB2cmlqZGFnIDE3IGFwcmlsIDIwMDkgMjI6MDA8YnI+DQpUbzogSm9o bi5FLkRyYWtlMkBib2VpbmcuY29tOyBJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0Ozxicj4N CkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBtYWFydGVuLnZpc3NlcnNAaHVhd2Vp LmNvbTxicj4NCkNjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KU3ViamVjdDogUkU6IFttcGxzLXRw XSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGg8YnI+DQpyZXF1aXJlbWVu dHM8YnI+DQo8YnI+DQpKb2huLCAmbmJzcDtUaGFua3MgdGhpcyBpcyBhIGdyZWF0IHBsYXRmb3Jt IHRvIGV4cGxhaW4gd2h5IE9BTSBmb3IgdGhlDQozPGJyPg0KbmV0d29yazxicj4NCm1vZGVzIG5l ZWRzIHRvIGJlIGRpZmZlcmVudC4gJm5ic3A7SSBhbSBnZXR0aW5nIGEgd2VlIGJpdCB0aXJlZCBv ZiBmb2xrczxicj4NCnRyeWluZzxicj4NCnRvIG1ha2UgYWxsIDMgbmV0d29yayBtb2RlcyBsb29r IGFsaWtlIChhbmQgdGhlbiwgZXZlbiB3b3JzZSwgaW50ZXJ3b3JrPGJyPg0KdGhlbTxicj4NCmFz IGFzIHBlZXJzLi4uZXNwIHdoZW4gbm90IG5vdCB0b3Atb2Ytc3RhY2s8YnI+DQpuZXR3b3Jrcy4u LkkgbWVhbiBob3cgc2lsbHkgY2FuIHdlIGdldD8pLiAmbmJzcDsgSSBhbSBldmVuIG1vcmUgZnJ1 c3RyYXRlZA0KYnk8YnI+DQp0aGUgZmFjdCB0aG9zZSBwZWRkbGluZyB0aGlzIEZVRCBvbmx5IGV2 ZXIgc2VlbSB0byBjb25zaWRlciBPQU0gYW5kPGJyPg0KZm9yZ2V0PGJyPg0KYWxsIG90aGVyIERQ L0NQL01QIGNvbXBvbmVudHMgKGVzcCB0b3Atb2Ytc3RhY2sgbWVzc2FnZS9maWxlL3N0cmVhbTxi cj4NCmFwcGxpY2F0aW9uIGFkYXB0YXRpb25zKS4gJm5ic3A7SG93IHdyb25nIGNhbiB0aGlzIGdl dCEgPGJyPg0KPGJyPg0KSW4gdGhlIGNvIG1vZGVzIGEgKmNvbm5lY3Rpb24qIGlzIGEgdmVyeSBz cGVjaWZpYyBhbmQgKmNvbnN0cmFpbmluZyo8YnI+DQpjb25zdHJ1Y3QuLi4uLkkgYW0gYXNzdW1p bmcgaGVyZSB3ZSByZXNwZWN0IHRoZSBydWxlcyBvZiBhIGNvbm5lY3Rpb248YnI+DQooaWU8YnI+ DQpzaW5nbGUgc291cmNlKSB0aG91Z2ggc29tZSBmb2xrcyBkb24ndCBldmVuIGJvdGhlciB0byBy ZXNwZWN0IHRoaXMsIGFuZDxicj4NCnRoaXM8YnI+DQppcyBkZXNwaXRlIHRoZSBmYWN0IHRoYXQg d2UgYWxsIGtub3cgd2hhdCBwcm9ibGVtcyBtdWx0aXBsZS1zb3VyY2U8YnI+DQpjb25zdHJ1Y3Rz IGNhbiBjYXVzZSAoZnJvbSBMRFAvUEhQLi4uLmVyZ28gTVBMUy1UUCkuPGJyPg0KPGJyPg0KV2hl biB3ZSBoYXZlIGEgY29ubmVjdGlvbiB0aGlzIHJlc3RyaWN0cyAqYWxsKiBEUCAoaWUgdHJhZmZp YyBhbmQgT0FNKTxicj4NCnRvPGJyPg0Kc3RheSB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgY29u bmVjdGlvbi4gJm5ic3A7V2hpY2ggaXMgZmluZSB1bmRlcjxicj4NCmRlZmVjdC1mcmVlPGJyPg0K Y29uZGl0aW9ucywgYnV0IGlmIHdlIGhhdmUgbGVha2luZyB0cmFmZmljIHRoZW4gdGhlIGNvbnN0 cmFpbmluZyBuYXR1cmU8YnI+DQpvZjxicj4NCnRoZSBjb25uZWN0aW9uIGNvbnN0cnVjdCBpcyBi cm9rZW4uICZuYnNwO0luIGEgbnV0c2hlbGwgd2hhdCB0aGlzIG1lYW5zDQppczxicj4NCnRoYXQ8 YnI+DQpPQU0gdGhhdCBpcyBvZiBhIHJlcXVlc3QvcmVzcG9uc2UgbmF0dXJlIGNhbm5vdCBiZSB0 cnVzdGVkIGluIGNvIG1vZGU8YnI+DQpuZXR3b3JrcyB1bmRlciBtaXNjb25uZWN0aXZpdHkgZGVm ZWN0cy4uLi4uaW5kZWVkLCB3aHkgc2hvdWxkIGEgbGVha2luZzxicj4NCkRQPGJyPg0KaGF2ZSBh IHN5bW1ldHJpYyBnby9yZXR1cm4gZGVmZWN0IGJlaGF2aW91cj8uLi4udmVyeSBsaWtlbHkgaXQg d29uJ3QuPGJyPg0KU288YnI+DQp3aGlsc3QgcmVxdWVzdC9yZXNwb25zZSBPQU0gaXMgcmlnaHQg Zm9yIHRoZSBjbCBtb2RlIGl0IGlzIG5vdCByaWdodCBmb3I8YnI+DQp0aGU8YnI+DQpjbyBtb2Rl IHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3QgY29uZGl0aW9ucy48YnI+DQo8YnI+DQpNb3Jl IGdlbmVyYWxseSB0aGUgMyBtb2RlcyBhcmUgZGlmZmVyZW50IGFuZCBub3QganVzdCBpbiBPQU08 YnI+DQpyZXF1aXJlbWVudHMuLi4uYnV0IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUg YSBmYXZvdXIhLi4uYXQgbGVhc3Q8YnI+DQpJRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4g dGhpcyBmb3IgRXRoZXJuZXQgZXZlbiB0aG91Z2ggaXQgcmVtYWluczxicj4NCmluPGJyPg0KWS4x NzMxLiAmbmJzcDtBbmQgd2hpY2ggaXMgd2h5IEkgb2Z0ZW4gdHJvdC1vdXQgdGhlIHJhdGhlciBz aWxseSAodG8gaGF2ZQ0KdG88YnI+DQpzYXk8YnI+DQp0aGlzKSBvYnNlcnZhdGlvbiB0aGF0IGlm IElQIChjbCBtb2RlKSBjb3VsZCBkbyBpdCBhbGwgdGhlbiB3aHkgaGF2ZTxicj4NCklFVEY8YnI+ DQpmb3VuZCBpdCBuZWNlc3NhcnkgdG8gY3JlYXRlIE1QTFMgKGNvLXBzKSBhbmQgR01QTFMgKENQ IGZvciBjby1jcykuICZuYnNwO1RoZTxicj4NCmFuc3dlciBsaWVzIGluIHRoZSBwaHlzaWNzLi4u YW5kIEcuODAwIGF0dGVtcHRzIHRvIGV4cGxhaW4gdGhhdDxicj4NCnBoeXNpY3MuLi4uRy44MDUg ZG9lcyBub3QuPGJyPg0KPGJyPg0KU28sIHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQuLi5wbGVh c2UgYWNjZXB0L3Jlam9pY2UgaW4gdGhpcyBmYWN0IGFzPGJyPg0KdGhleTxicj4NCmFsbCBvZmZl ciBzb21ldGhpbmcgZGlmZmVyZW50L2ltcG9ydGFudC4gJm5ic3A7QnV0IGRvIG5vdCBiZSBob29k d2lua2VkDQpieTxicj4NCnRob3NlPGJyPg0Kd2hvIHBlZGRsZSBhIHN0b3J5IHRoYXQgdGhhdCB0 cmllcyB0byBtYWtlIHRoZSBPQU0gb2YgdGhlIDMgbW9kZXMgdGhlPGJyPg0Kc2FtZS4gPGJyPg0K PGJyPg0KcmVnYXJkcywgTmVpbCA8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7 IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpv aG4gRTxicj4NCiZndDsgU2VudDogMTcgQXByaWwgMjAwOSAyMDowMjxicj4NCiZndDsgVG86IEJV U0kgSVRBTE87IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnM8YnI+DQomZ3Q7 IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCA8YnI+DQomZ3Q7IHJlcXVpcmVt ZW50czxicj4NCiZndDsgPGJyPg0KJmd0OyBJdGFsbyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMg ZGVzY3JpYmVkIGluIHRoZSBNUExTIFRQIE9BTSBSZXF1aXJlbWVudHMgSS1ELCB2aXJ0dWFsbHkg YWxsIG9mDQp0aGU8YnI+DQo8YnI+DQomZ3Q7IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJldHVy biBwYXRoLCBhbmQgaW4gdGhlIGFic2VuY2Ugb2YgYSByZXR1cm4NCjxicj4NCiZndDsgcGF0aCB0 aGV5IGFyZSBkaXNhYmxlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgZGVzY3JpYmVkIGluIERh dmlkIFNpbmljcm9wZSdzIG1lZXRpbmcgbWludXRlcyA8YnI+DQomZ3Q7IChodHRwOi8vd2lraS50 b29scy5pZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9hdHRhY2htZW50L3dpa2kvPGJyPg0KJmd0 OyBtZWV0aW5nLW5vPGJyPg0KJmd0OyB0ZXMvMjAwODEwMTUubXBscy1pbnRlcm9wLWR0LW5vdGVz LnppcCksIGlmIElQIGFkZHJlc3NpbmcgaXMgdXNlZCwNCmFuIDxicj4NCiZndDsgTVBMUyBUUCBu ZXR3b3JrIG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgZ2V0dGluZyBJUCBwYWNrZXRzIGZyb20gPGJy Pg0KJmd0OyBkZXN0aW5hdGlvbiB0byBzb3VyY2U7IG5laXRoZXIgdGhlIG1pbnV0ZXMgbm9yIEkg c3RpcHVsYXRlIHRoYXQgYQ0KPGJyPg0KJmd0OyBjb250cm9sIHBsYW5lIG5lZWRzIHRvIGJlIHVz ZWQgdG8gaW5zdGFudGlhdGUgdGhpcyBmb3J3YXJkaW5nLjxicj4NCiZndDsgPGJyPg0KJmd0OyBB cyBhbiBhc2lkZSwgdGhlIGlzc3VlIG9mIHJldHVybiBwYXRoIGZvciB1bmlkaXJlY3Rpb25hbCBM U1BzIGNvdWxkDQpiZTxicj4NCjxicj4NCiZndDsgY2hhcmF0ZXJpemVkIGFzIHRoZSBlbGVwaGFu dCBpbiB0aGUgcm9vbS4gJm5ic3A7SW4gdGhlIE1QTFMgVFAgT0FNDQo8YnI+DQomZ3Q7IEZyYW1l d29yayBJLUQsIHVuaWNhc3QgTFNQcyBhcmUgb25seSBtZW50aW9uZWQgdGhyZWUgdGltZXMgYW5k IHJldHVybg0KPGJyPg0KJmd0OyBwYXRocyBub3QgYXQgYWxsLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGFua3MsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEpvaG48YnI+DQomZ3Q7ICZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogQlVTSSBJVEFMTyBbbWFp bHRvOkl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXRdPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IEZy aWRheSwgQXByaWwgMTcsIDIwMDkgMTo1OSBBTTxicj4NCiZndDsgJmd0OyBUbzogRHJha2UsIEpv aG4gRTsgQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vyczxicj4NCiZndDsgJmd0 OyBDYzogbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSRTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KPGJyPg0KJmd0OyAm Z3Q7IHJlcXVpcmVtZW50czxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSm9obiw8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgbWlnaHQgaGF2ZSBtaXNzZWQgdGhlIGFncmVl bWVudCBvZiBNUExTLVRQIGJlaW5nIGNhcGFibGUgb2YNCjxicj4NCiZndDsgJmd0OyBzZW5kaW5n IHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMuPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGlzIHJlcXVpcmVtZW50IGRvZXMgbm90IGJl bG9uZyB0byB0aGUgZmlyc3Qgc2V0IG9mIHJlcXVpcmVtZW50cw0KPGJyPg0KJmd0OyAmZ3Q7IElU VS1UIGlzIGV4cGVjdGluZyB0byBiZSBtZXQgYnkgT2N0b2Jlci48YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IEhvd2V2ZXIsIEkgdGhpbmsgdGhpcyBpbiBhIHBvdGVudGlhbCBpbnRlcmVz dGluZyBhZGRpdGlvbmFsIDxicj4NCiZndDsgJmd0OyByZXF1aXJlbWVudCB0byBiZSB0YWtlbiBp bnRvIGFjY291bnQgKGF0IHdvcnN0IGluIGE8YnI+DQomZ3Q7IHN1YnNlcXVlbnQgcGhhc2UpLjxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGF0IHRoaXMgcmVxdWlyZW1l bnQgbmVlZHMgdG8gYmUgZXZhbHVhdGVkIHZlcnN1cyBvdGhlcg0KPGJyPg0KJmd0OyAmZ3Q7IG1v cmUgaW1wb3J0YW50IHJlcXVpcmVtZW50cyAoZS5nLiB0aGUgcG9zc2liaWxpdHkgdG8gd29yayB3 L28NCklQIDxicj4NCiZndDsgJmd0OyBmb3J3YXJkaW5nIGFuZCB0aGUgbmVlZCBmb3IgT0FNIHRv IGNvbnRpbnVlIHRvIG1vbml0b3IgdGhlIGRhdGENCjxicj4NCiZndDsgJmd0OyBwbGFuZSBhbHNv IGluIGNhc2Ugb2YgZmFpbHVyZXMgYWZmZWN0aW5nIHRoZSBjb250cm9sIG9yIG1hbmFnZW1lbnQN Cjxicj4NCiZndDsgJmd0OyBwbGFuZSkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJ IGFtIG9wZW4gdG8gZGlzY3VzcyBpdCBidXQgbm90IHN1cmUgdGhpcyBpcyB0aGUgcmlnaHQgdGlt ZSBiZWNhdXNlDQo8YnI+DQomZ3Q7ICZndDsgSSB3aXNoIHRvIGF2b2lkIGRlbGF5aW5nIHRoZSBm aXJzdCBwaGFzZSBvZiB0aGUgZGVzaWduIHNvbHV0aW9uLjxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgVGhhbmtzLCBJdGFsbzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IFttYWlsdG86bXBscy10 cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4NCkU8YnI+DQomZ3Q7 ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgODowMCBQTTxicj4NCiZn dDsgJmd0OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0 OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQNCnBhdGggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXQgdGhlIG1lZXRpbmcgbGFzdCBmYWxsIGF0IEp1 bmlwZXIgaW4gTWFzc2FjaHVzZXR0cywgSTxicj4NCiZndDsgJmd0OyB0aGluayBpdCB3YXM8YnI+ DQomZ3Q7ICZndDsgJmd0OyBhZ3JlZWQgdGhhdCBhbiBNUExTIFRQIG5ldHdvcmsgbmVlZHMgdG8g aGF2ZSBhIGZvcndhcmRpbmc8YnI+DQomZ3Q7ICZndDsgY2FwYWJpbGl0eTxicj4NCiZndDsgJmd0 OyAmZ3Q7IGZvciBtYW5hZ2VtZW50LCBjb250cm9sLCBhbmQgT0FNIHBhY2tldHMgKGUuZy4sIHNl bmRpbmc8YnI+DQomZ3Q7ICZndDsgcmVwbGllcyB0byBPQU08YnI+DQomZ3Q7ICZndDsgJmd0OyBy ZXF1ZXN0cyBzZW50IG9uIHVuaS1kaXJlY3Rpb25hbCBMU1BzKSBldmVuIGlmIGl0IGRvZXMgbm90 PGJyPg0KJmd0OyAmZ3Q7IGhhdmUgYW4gSVA8YnI+DQomZ3Q7ICZndDsgJmd0OyBmb3J3YXJkaW5n IGRhdGEgcGxhbmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJv bTogQWxleGFuZGVyIFZhaW5zaHRlaW48YnI+DQomZ3Q7ICZndDsgJmd0OyBbbWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU2Vu dDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDk6NTcgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IFRvOiBNYWFydGVuIFZpc3NlcnM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IENjOiBtcGxz LXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHMt dHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCnBhdGggPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgTWFhcnRlbiw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEl0 IHNlZW1zIHRoYXQgeW91J3ZlIGp1c3QgKGltcGxpY2l0bHkgYW5kLCBwcm9iYWJseSw8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IGluYWR2ZXJ0ZW50bHkpIHN0YXRlZCB0aGUgZm9sbG93aW5nOjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtN UExTLVRQIE9BTSB3aWxsIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0aW9uPGJy Pg0KJmd0OyAmZ3Q7IChhbmQgZmF1bHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxvY2FsaXph dGlvbiB3aGljaCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uICkgZm9yPGJyPg0KJmd0OyAmZ3Q7IHVu aWRpcmVjdGlvbmFsIFAyTVA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuZCBQMlAgcGF0aHMu PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHRo aXMgc3RhdGVtZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8gYW5kIEZXSVcpPGJyPg0KJmd0OyBy YWlzZXMgYSB2YWxpZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcXVlc3Rpb246PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0lzIE1QTFMt VFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIHRoZXNlPGJyPg0KJmd0OyB0eXBlcyBvZiB0 cmFuc3BvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhdGhzPzxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGb3IgdGhlIHJlZmVyZW5jZSwgSVAv TVBMUyBwcm92aWRlcyB0aGlzIGtpbmQgb2Y8YnI+DQomZ3Q7ICZndDsgZnVuY3Rpb25hbGl0eSB0 b2RheTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZm9yICh1bmlkaXJlY3Rpb25hbCAtIGJ1dCBp dCBkb2VzIG5vdCBrbm93IGFueSBvdGhlcjxicj4NCiZndDsgJmd0OyB0eXBlKSBQMlAgTFNQczxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYXMgZGVzY3JpYmVkIGluIFJGQyA0Mzc5LiBBbmQgaXRz IGV4dGVuc2lvbiB0byBQMk1QDQpMU1BzIHNlZW1zIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg ZWFzeS4uLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTYXNoYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYu b3JnIFttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddPGJyPg0KJmd0OyAmZ3Q7IE9uIEJlaGFsZjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT2YgTWFhcnRlbiBWaXNzZXJzIFttYWFydGVuLnZpc3Nl cnNAaHVhd2VpLmNvbV08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBB cHJpbCAxNiwgMjAwOSAzOjI0IFBNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogJ0Fkcmlh biBGYXJyZWwnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg cmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEFkcmlhbiw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIG5vZGVzDQooaW5j bHVkaW5nIE1FUHMsIE1JUHMgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBvdGhlciBpbnRl cm5hbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKQ0Kb2YgYSBjby1yb3V0ZWQ8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5 ZXINCk1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2Fy ZA0KYW5kIHRoZSBiYWNrd2FyZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZGlyZWN0aW9ucyBv ZiB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB0cmFuc3BvcnQgcGF0aC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZs dDtlbmQgcXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlzIGEgZnVuY3Rpb25hbCBy ZXF1aXJlbWVudC4NClRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBpcywgdGhlcmUgaXM8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZy b20gYSBibGFjayBib3gNCnBvaW50IG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdmlldyB0aGF0PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlz IHJlcXVpcmVtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIEl0IGlzIHZlcnkgbXVj aDxicj4NCiZndDsgb2JzZXJ2YWJsZSBpZjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyBy ZXF1aXJlbWVudCBpcyBtZXQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZiB2aWV3Ljxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgVGhlIE1JUCBmdW5jdGlvbnMgY2FuIG9ubHkgcGVyZm9ybSB0aGUg TG9vcGJhY2sgd2hlbg0KdGhlcmUgaXMgYSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvLXJv dXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoLiBUaGUgTVBMUy1UUA0KTEJNIHBhY2tl dCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlY2VpdmVkIGF0IGEgTUlQIG5lZWRzIHRvIGJl IHJldHVybmVkIChhcyBMQlI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhY2tldCkgdG8gdGhl IG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhlIG90aGVyPGJyPg0KJmd0OyAmZ3Q7IGRp cmVjdGlvbiBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoLiBUaGlzIG90aGVyPGJyPg0KJmd0OyBkaXJlY3Rpb248YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdvdWxkIG5vdCBiZSBhdmFpbGFibGUgaW4gYW4gYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsDQp0cmFuc3BvcnQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBw YXRoLi4uIGFuZCB0aHVzIHRoZSBsb29wYmFjayB0ZXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgd291 bGQgZmFpbC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgU2ltaWxhcmx5LCB3aGVuIHdlIGhhdmUgdG8gYXBwbHkgVENNIE1FUHMgdG8gbW9uaXRvcg0K YTxicj4NCiZndDsgJmd0OyBzZWdtZW50LCB0aGVuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0 aGlzIGlzIHBvc3NpYmxlIGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoPGJyPg0K Jmd0OyBidXQgbm90IGluIGE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFzc29jaWF0ZWQgYmlk aXIgdHJhbnNwb3J0IHBhdGguIEluIHRoZSBmaXJzdCBjYXNlDQp0aGUgVENNIE1FUCA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IFNvdXJjZSBhbmQgU2luayBmdW5jdGlvbnMgYXJlIGNvLWxvY2F0 ZWQgYW5kIGNhbjxicj4NCiZndDsgZXhjaGFuZ2Ugd2hhdCBpczxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgY2FsbGVkICZxdW90O3JlbW90ZSBpbmZvcm1hdGlvbiZxdW90OyB3aGljaCBpcyBuZWNl c3NhcnkNCmZvciBwZXJmb3JtYW5jZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3Jp bmcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBN RVAgU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9uczxicj4NCiZndDsgJmd0OyBhcmUgaW4gZS5nLiA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRpZmZlcmVudCBub2RlcyBpbiB0aGUgbmV0d29yayBh bmQgVENNIHdvdWxkIG5vdCBiZQ0KYWJsZTxicj4NCiZndDsgJmd0OyB0byBwcm92aWRlPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBlbnRpcmV0eSBv ZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICZxdW90OyhpbmNsdWRpbmcNCk1FUHMsPGJyPg0KJmd0OyAm Z3Q7ICZndDsgTUlQcyBhbmQgb3RoZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGludGVybmFs PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkm cXVvdDsgc2hvdWxkIGJlIGRlbGV0ZWQuDQpJdCBkb2VzIG5vdDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgYWRkIHRvICZxdW90O1RoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRl cm1lZGlhdGUgbm9kZXMuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gVGhpcyB0 ZXh0IG11c3Qgbm90DQpiZTxicj4NCiZndDsgJmd0OyBkZWxldGVkIGF0PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBhbGwuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVy c2lzdGVudDxicj4NCiZndDsgJmd0OyAmZ3Q7IGluc2lzdGVuY2Ugb24gdGhlPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBpbmNsdXNpb248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgb2Yg JnF1b3Q7VGFuZGVtIENvbm5lY3Rpb24uJnF1b3Q7IFRoZSBkZWZpbml0aW9uDQp3aXRoaW4gdGhl IElUVS1UIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIHRlcm08YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBvb3JseTxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1v bml0b3Jpbmcgb2YgYSBwYXRoDQp0aGF0IGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXJh bGxlbCAoaS5lLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGFuZGVtKTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhpcyBk ZWZpbml0aW9uDQpvZiBUQzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2VlbXMgdG8gYmUgYXQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHZhcmlhbmNlLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBhbmQgd291bGQgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC48YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBkb24ndCB1 bmRlcnN0YW5kIHdoZXJlIHlvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGFuZGVtPGJyPg0KJmd0OyAm Z3Q7IGNvbm5lY3Rpb24gaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRlc2NyaWJlZCBpbiBJ VFUtVCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gJnF1b3Q7ZnJvbQ0KdGhlPGJyPg0KJmd0OyAmZ3Q7 IG1vbml0b3Jpbmcgb2YgYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcGF0aCB0aGF0IGlzIHBh cmFsbGVsIChpLmUuIHRhbmRlbSkgdG8gdGhlIGRhdGEgcGF0aA0KYmVpbmcgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBtb25pdG9yZWQuJnF1b3Q7Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBpcyBhICZxdW90O25ldHdvcmsgY29ubmVj dGlvbiZxdW90OyBhbmQgdGhpcw0KbmV0d29yazxicj4NCiZndDsgJmd0OyBjb25uZWN0aW9uIGlz IGEgc2V0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBvZiBpbnRlcmNvbm5lY3RlZCAmcXVvdDts aW5rIGNvbm5lY3Rpb25zJnF1b3Q7IGFuZA0KJnF1b3Q7bWF0cml4PGJyPg0KJmd0OyBjb25uZWN0 aW9ucyZxdW90Oy4gQTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc3Vic2V0IG9mIHRob3NlIGlu dGVyY29ubmVjdGVkIGxpbmsgY29ubmVjdGlvbnMgYW5kDQptYXRyaXggPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBjb25uZWN0aW9ucyBjYW4gYmUgbW9uaXRvcmVkIGFuZCBpcyB0aGVuIHJlZmVy cmVkIHRvDQphczxicj4NCiZndDsgYSAmcXVvdDt0YW5kZW08YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IGNvbm5lY3Rpb24mcXVvdDsuIFRoZXJlIGlzIG5vICZxdW90O3BhdGggdGhhdCBpcyBwYXJh bGxlbA0KdG8gdGhlPGJyPg0KJmd0OyAmZ3Q7IGRhdGEgcGF0aCZxdW90Oy4gPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBUaGVyZSBpcyBvbmx5IGFkZGl0aW9uYWwgT0FNIGluc2VydGVkIGluc2lk ZSB0aGUgZGF0YTxicj4NCiZndDsgcGF0aCBieSB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFRDTSBNRVBfU28gZnVuY3Rpb24gYW5kIHRoaXMgT0FNIGlzIGV4dHJhY3RlZCBmcm9tDQp0aGU8 YnI+DQomZ3Q7ICZndDsgZGF0YSBwYXRoIGJ5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUg VENNIE1FUF9TayBmdW5jdGlvbi48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE1hYXJ0ZW48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFkcmlhbg0KRmFycmVsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50OiBkb25kZXJk YWcgMTYgYXByaWwgMjAwOSAxMTo1OTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVG86IEFsZXhh bmRlciBWYWluc2h0ZWluOyBiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbTxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgQ2M6IEJVU0kgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydA0KcGF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVt ZW50czxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBI aSBTYXNoYSw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBVbmZvcnR1bmF0ZWx5IEkgY2Fubm90IGZ1bGx5IGFncmVlIHdpdGggeW91ciBzdGF0 ZW1lbnQ6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLA0KY28tcm91dGVk PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBMU1BzPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgYXJlIGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0 ZWQNCmJpZGlyZWN0aW9uYWwgTFNQcy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0 O2VuZCBxdW90ZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgVGhpcyBzdGF0ZW1lbnQgd291bGQgYmUgb2J2aW91c2x5IGNvcnJl Y3QsIHdlcmUNCml0IG5vdCBmb3I8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJlcXVpcmVtZW50 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCBy ZXF1aXJlbWVudHMgZHJhZnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgT0suIEdvdCBpdC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgQnV0IHdoYXQgaXMgdGhpcyBkb2luZyBpbiB0aGUgZGF0YSBwbGFu ZSByZXF1aXJlbWVudHMNCnNlY3Rpb24/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IEluIGZhY3QsIHdoYXQgaXMgdGhpcyByZXF1aXJlbWVudCBhY3R1 YWxseSBzYXlpbmc/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZw0KTUVQ cywgTUlQcyBhbmQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBvdGhlciBpbnRlcm5hbDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMgYXMgYXBw cm9wcmlhdGUpDQpvZiBhIGNvLXJvdXRlZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgcGF0aCBhdCBlYWNoIChzdWItKWxheWVyDQpNVVNUIGJlIGF3YXJlIG9mIHRo ZSBwYWlyaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZA0KYW5kIHRoZSBiYWNrd2FyZDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgZGlyZWN0aW9ucyBvZiB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCBwYXRoLjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBh IGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQ8YnI+DQomZ3Q7ICZndDsgaXMsIHRoZXJlIGlz PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQg ZnJvbSBhIGJsYWNrIGJveCBwb2ludA0Kb2Y8YnI+DQomZ3Q7ICZndDsgdmlldyB0aGF0PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyByZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJl bWVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg VGhlcmVmb3JlIGl0IGNvdWxkIGJlIGFzc3VtZWQgdGhhdCB0aGlzIHJlcXVpcmVtZW50DQppcyBt ZXQgYnkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjb25maWd1cmluZyBzb21lIGRhdGEgcGxh bmUgZGF0YWJhc2UgY29tcG9uZW50IHRocm91Z2gNCnRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IG1hbmFnZW1lbnQgcGxhbmUuIFRoZSBkYXRhYmFzZSBjb21wb25lbnQgaXMgbm90IHVzZWQ8 YnI+DQomZ3Q7IGZvciBhbnl0aGluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZXhjZXB0IHRv IHNhdGlzZnkgdGhpcyByZXF1aXJlbWVudCBmb3IgJnF1b3Q7YXdhcmVuZXNzJnF1b3Q7Ljxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBCZW4hIENhbiB3 ZSBwbGVhc2UgdHJ5IHRvIHJld3JpdGUgdGhpcyByZXF1aXJlbWVudA0KaW4gdGVybXMgb2YgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBiZWhhdmlvcj88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVt ZW50IDM0IGlzIHRoZSBPTkxZIGl0ZW0NCmluIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg bGlzdCB0aGF0IGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNwZWNpZmljIGZvciBj by1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhlDQpwYWlyaW5nPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXQg ZW5kIHBvaW50cyBmb3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWw8YnI+ DQomZ3Q7ICZndDsgJmd0OyBwYXRocyBhcmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg ZXhhY3RseSB0aGUgc2FtZSBldmVuIGlmIHRoZXkgYXBwZWFyIGluIHR3byBkaWZmZXJlbnQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyBpdGVtcyBpbiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgcmVxdWlyZW1lbnRzJyBsaXN0KS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSW4g b3RoZXIgd29yZHMsIHdpdGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlvbg0Kb2Y8YnI+DQom Z3Q7IGNvLXJvdXRlZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFs IHBhdGhzIHdvdWxkIGJlIHZvaWQgb2YgYW55IGRhdGENCnBsYW5lIGNvbnRlbnQuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBz b21ld2hhdCB2YWd1ZSBzY29wZSBvZiB0aGlzIHJlcXVpcmVtZW50ICgmcXVvdDtvdGhlcg0KaW50 ZXJuYWwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9ucyBhcyBhcHByb3By aWF0ZSZxdW90OykgY3JlYXRlcyBhIHN1c3BpY2lvbg0KdGhhdCBIVzxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgc3VwcG9ydCBvZiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcGFp cmluZyBhd2FyZW5lc3MgbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRvDQpjb21wbHkgd2l0aCBp dC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhl IGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgJnF1b3Q7KGluY2x1ZGluZw0KTUVQcyw8 YnI+DQomZ3Q7ICZndDsgTUlQcyBhbmQgb3RoZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGlu dGVybmFsIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkmcXVvdDsgc2hvdWxkIGJlDQpkZWxldGVk LiBJdDxicj4NCiZndDsgJmd0OyBkb2VzIG5vdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYWRk IHRvICZxdW90O1RoZSBpbnRlcm1lZGlhdGUgbm9kZXMuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGZvbGxvd2luZyB0ZXh0 IGluIHRoZSBkcmFmdCBpbmNyZWFzZXMgdGhpcw0Kc3VzcGljaW9uOjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7cXVvdGUmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBUYW5kZW0gQ29ubmVjdGlvbjog QSB0YW5kZW0gY29ubmVjdGlvbg0KaXMgYW48YnI+DQomZ3Q7ICZndDsgYXJiaXRyYXJ5IHBhcnQg b2YgYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgdHJhbnNwb3J0IHBhdGgg dGhhdCBjYW4gYmUgbW9uaXRvcmVkICh2aWENCk9BTSk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGluZGVwZW5kZW50bHkgZnJvbSB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i c3A7IGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gJm5ic3A7SXQgbWF5DQpiZSBhIG1vbml0 b3JlZDxicj4NCiZndDsgJmd0OyBzZWdtZW50IG9yIGE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7IG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBhIHRyYW5zcG9y dA0KcGF0aC4gJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IFRoZSB0YW5kZW08YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7IGNvbm5lY3Rpb24gbWF5IGFsc28gaW5jbHVkZSB0aGUgZm9y d2FyZGluZw0KZW5naW5lKHMpIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgbm9kZShz KTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgYXQgdGhlIGVkZ2Uocykgb2Yg dGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkDQpzZWdtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSBhbSBxdWl0ZSBmZWQgdXAgYWJvdXQg dGhpcyBwZXJzaXN0ZW50PGJyPg0KJmd0OyAmZ3Q7IGluc2lzdGVuY2Ugb24gdGhlPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBpbmNsdXNpb24gb2YgJnF1b3Q7VGFuZGVtIENvbm5lY3Rpb24uJnF1 b3Q7IFRoZSBkZWZpbml0aW9uDQp3aXRoaW48YnI+DQomZ3Q7ICZndDsgdGhlIElUVS1UIG9mPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIHRlcm0gaXMgcG9vcmx5IHNwZWNpZmllZCBhbmQg Y29tZXMgZnJvbSB0aGU8YnI+DQomZ3Q7IG1vbml0b3Jpbmcgb2YgYTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgcGF0aCB0aGF0IGlzIHBhcmFsbGVsIChpLmUuIHRhbmRlbSkgdG8gdGhlIGRhdGEg cGF0aA0KYmVpbmcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtb25pdG9yZWQuIFRoaXMgZGVm aW5pdGlvbiBvZiBUQyBzZWVtcyB0byBiZSBhdCB2YXJpYW5jZSw8YnI+DQomZ3Q7ICZndDsgYW5k IHdvdWxkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxs eSBpbiBiYW5kLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IERvZXNuJ3QgJnF1b3Q7Zm9yd2FyZGluZyBlbmdpbmUmcXVvdDsgc291bmQgbGlr ZQ0KaGFyZHdhcmUgdG8geW91Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBZZXMsIGJ1dCBzbyB3aGF0Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IElNSE8gaXQgaXMgd29ydGggbm90aW5nIHRo YXQgbmVpdGhlciB0aGUgTVBMUy1UUDxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlcXVpcmVtZW50cyBk cmFmdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBub3IgdGhlIE1QTFMtVFAgT0FNIHJl cXVpcmVtZW50cyBvbmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxz LXRwLW9hbS1yZXF1aXJlbWVuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRzLTAxLnR4 dCkgY29udGFpbiBhbnkgcmVxdWlyZW1lbnRzIGRlYWxpbmcgd2l0aA0KdGFuZGVtPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgY29ubmVjdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJ1dCB0YW5kZW0gY29ubmVjdGlvbnMgYXJlIGRp c2N1c3NlZCBpbiB0aGUgTVBMUy1UUA0KT0FNPGJyPg0KJmd0OyAmZ3Q7IEZyYW1ld29yazxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBkcmFmdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg KGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1v YW0tZnI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFtZXdvcmstMDAudHh0PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyApLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBSaWdodC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IExldCdzIGp1c3QgZ2V0 IHJpZCBvZiBhbiB1bm5lY2Vzc2FyeSB0ZXJtIGFuZCBicmluZw0KYWxsPGJyPg0KJmd0OyB0aGUg SS1Eczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50byBsaW5lLjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBib3R0b20gbGluZSwg SU1ITywgaXMgdGhhdCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Y28tcm91dGVkIHZzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhc3NvY2lhdGVkPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgaXMgc3RpbGwg cmVxdWlyZWQuIE9uZSB3YXkNCnRvIHByb3ZpZGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRo YXQgY291bGQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYmUgYnkgZXhwbGljaXRseSBs aW1pdGluZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYzxicj4NCiZndDsgJmd0OyAmZ3Q7IGZ1 bmN0aW9uYWxpdHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEFncmVlZC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgQWRyaWFuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb206IEFkcmlhbiBGYXJy ZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50OiBU aHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMTI6MTMgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTzxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydA0KcGF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBTYXNoYSw8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgTm90IHJl YWxseSBzdXJlIHdoZXRoZXIgeW91IGFyZSBtaXNyZXByZXNlbnRpbmcgYW55b25lLA0KYnV0Li4u PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg MS4gTXkgcmVhZGluZyBvZiAmbmJzcDtvbmUgb2YgQmVuJ3MgJm5ic3A7bWVzc2FnZXMNCmlzIHRo YXQgYXNzb2NpYXRlZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25h bCBwYXRocyBhcmUgdGhlIG9ubHkgdHlwZXMgb2YgcGF0aHMNCnRoYXQgY2FuIGJlPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBjcmVhdGVkIGluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHRoZSBleGlzdGluZyBuZXR3b3JrczsgJnF1b3Q7dHJ1ZSZxdW90OyBjby1yb3V0ZWQNCmJpZGly ZWN0aW9uYWwgcGF0aHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdpbGwgaGF2ZTxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0byB3YWl0IHVudGlsIChpZiBldmVyKSBuZXcgZXF1aXBt ZW50IGJlY29tZXMNCmF2YWlsYWJsZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlITxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVk PGJyPg0KJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQcyBhcmU8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJZiB5b3Ug Y2FuIHNldCB1cCB0d28gdW5pZGlyZWN0aW9uYWwgTFNQcyAoZS5nLiB1c2luZw0KdGhlPGJyPg0K Jmd0OyAmZ3Q7IG1hbmFnZW1lbnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBsYW5lKSB5b3Ug Y2FuIHN1cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBiaWRpcmVj dGlvbmFsIExTUC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVk PGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBMU1BzIHVz aW5nIHRoZSBjb250cm9sIHBsYW5lLiBUaGVzZSBlaXRoZXIgdXNlIHRoZQ0KR01QTFM8YnI+DQom Z3Q7ICZndDsgKHdoaWNoIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjbGVhbmVyKSBvciBu b24tc3RhbmRhcmQgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaA0KaXM8YnI+DQomZ3Q7ICZn dDsgbWVzc3kgYnV0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBmdW5jdGlvbmFsKS48YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0IChvZiBjb3Vy c2UpIHRoZSBtYW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wgcGxhbmU8YnI+DQomZ3Q7ICZndDsg c29sdXRpb25zIGhhdmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5vdGhpbmcgdG8gZG8gd2l0 aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50IGFzIHRoZXk8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgYXJlIHNvZnR3YXJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBz b2x1dGlvbnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgMi4gTXkgcmVhZGluZyBvZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRoYXQN CnRoZSBhY3R1YWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRyaXZlciBmb3I8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgbWF5IGJl IGV4cGVyaWVuY2UNCndpdGggZXhpc3RpbmcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHRyYW5zcG9ydCBuZXR3b3JrcyByYXRoZXIgdGhhbiBhbnkgc3BlY2lmaWMgYmVuZWZpdC48YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSXNuJ3QgdGhh dCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUgTVBMUy1UUCByZXF1aXJlbWVudHM/PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFkIHRoaW5nLjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBIGxhcmdl IGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNrZXQgbmV0d29yazxicj4NCiZn dDsgJmd0OyB0aGUgbG9vayw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZlZWwsIGFuZCBiZWhh dmlvcmFsIGNoYXJhY3RlcmlzdGljcyBvZiBhICZxdW90O2xlZ2FjeSZxdW90Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgdHJhbnNwb3J0IG5ldHdvcmsuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRp b25zLCBJJ2QgZ3Vlc3MgKEZXSVcpDQp0aGF0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAqIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0DQpmb3IgdGhl IHRpbWU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2JlaW5nLCB0 aGUgbW9zdCBpbXBvcnRhbnQgdHlwZSBvZg0KYmlkaXJlY3Rpb25hbCBwYXRocyBpbjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7TVBMUy1UUDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIHRoYXQgaXMgd3Jv bmcgYm90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsDQphbmQ8YnI+DQomZ3Q7ICZndDsgZ2l2 ZW4gdGhhdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgb3RoZXIgdXBncmFkZXMgdG8gZXhpc3Rp bmcgTVBMUyBzb2x1dGlvbnMgd2lsbCBiZTxicj4NCiZndDsgbmVlZGVkIHRvIHJlYWNoPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZnVsbCBmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICog dGhleSBoYWQgYSBnb29kIGNoYW5jZSB0byByZW1haW4gdGhlIG9ubHkgdHlwZQ0Kb2Y8YnI+DQom Z3Q7ICZndDsgYmlkaXJlY3Rpb25hbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsgcGF0aHMgaW4gJm5ic3A7cmVhbCBkZXBsb3ltZW50cy48YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBkb24ndCBzZWUgd2hhdCB0aGF0IGZvbGxv d3MgZnJvbS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgQ2hlZXJzLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRyaWFuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtcGxz LXRwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbXBscy10cEBpZXRmLm9y Zzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBt cGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBtcGxzLXRwQGll dGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMtdHA8YnI+DQomZ3Q7IDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzLXRwQGlldGYu b3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPC90 dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+PHR0Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50 aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2Vj cmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2Vu ZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBT cGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJy PjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTom bmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFp bCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNp cGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNw O3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90 Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRl bnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3Ro ZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0 cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZu YnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7 dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkm bmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNw O0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWls Jm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNw O29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7 dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7 YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5k ZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5i c3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZu YnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002D8773482575A0_=-- From xqwei@fiberhome.com.cn Wed Apr 22 01:21:43 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DA23A70D9 for ; Wed, 22 Apr 2009 01:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.493 X-Spam-Level: ** X-Spam-Status: No, score=2.493 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_05=-1.11, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcHX41FpOcTa for ; Wed, 22 Apr 2009 01:21:42 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id CE8943A70C9 for ; Wed, 22 Apr 2009 01:21:30 -0700 (PDT) Received: from xqwei ([10.82.25.4]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Apr 2009 16:17:54 +0800 Date: Wed, 22 Apr 2009 16:22:30 +0800 From: "Xueqin WEI (Shuetsing WEI)" To: "HUANG Feng F" References: , <200904181452174219225@fiberhome.com.cn>, Message-ID: <200904221622298593406@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 22 Apr 2009 08:17:54.0169 (UTC) FILETIME=[D5E5EE90:01C9C322] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 08:21:43 -0000 RmVuZzoNCg0KVGhlIGZ1bmN0aW9uIG9mIFRDTSBjYW4gYmUgcHJvdmlkZWQgYnkgbmVzdGVkIExT UCAoV2hpY2ggaXMgdGhlIGJhc2ljIGZ1bmN0aW9uIG9mIE1QTFMtVFApLCB3ZSBuZWVkbid0IHRv IGRlZmluZSBUQ00uDQoNCg0KU2luY2VyZWx5IFlvdXJzDQpYdWVxaW4gV2VpIChTaHVldHNpbmcg V2VpKQ0KMjAwOS0wNC0yMiAgMTY6MjA6MTANCg0KPT09PT09PT09PT09PT09PT09PT0gRm9sbG93 aW5nIGlzIHlvdXIgZW1haWw9PT09PT09PT09PT09PT09PT09PT0NClN1YmplY3Q6UkU6IFttcGxz LXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOkFzc29jaWF0ZWRiaWRp cmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNClNlbnSjujIwMDktMDQtMjAg MjE6NTg6MTgNCkZyb206SFVBTkcgRmVuZyBGDQpUbzp4cXdlaUBmaWJlcmhvbWUuY29tLmNuOyBC ZW4gTml2ZW4tSmVua2luczsgQnVzaSBJdGFsbw0KQ0MgdG86TVBMUy1UUA0KDQo+RGVhciBYdWVx aW4sDQo+ICAgICBXZSBhcmUgZGlzY3Vzc2luZyByZXF1aXJlbWVudCBvZiBUQ00sIG5vdCBmb3Ig IGZ1bmN0aW9uIGFuZCBtZXRob2QgaW4gZGV0YWlscy4NCj5CLlIuDQo+RmVuZyANCj4NCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1ZXFpbiBXRUkg KFNodWV0c2luZyBXRUkpDQo+U2VudDogMjAwOcTqNNTCMTjI1SAxNDo1Mg0KPlRvOiBCZW4gTml2 ZW4tSmVua2lucw0KPkNjOiBNUExTLVRQDQo+U3ViamVjdDogUmU6IFttcGxzLXRwXSBUYW5kZW0g Q29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj4NCj5TdXBwb3J0LCBJIHRoaW5rIHRoZSBuZXN0 ZWQgTFNQIHdpbGwgYmUgZ3JlYXQhIFVudGlsIG5vdywgSSBkaWRuJ3Qgc2VlIGFueSBkaWZmZXJl bmNlIGJldHdlZW4gdGhlIG5lc3RlZCBMU1AgYW5kIFRDTSBvbiBwZXJmb3JtYW5jZSBtb25pdG9y aW5nLiBCdXQgdGhlIG5lc3RlZCBMU1Agd2lsbCBtYWtlIHRoZSB0aGluZ3MgbW9yZSBlYXN5LiBJ IHdvdWxkIGxpa2Ugc2VsZWN0IGEgc2ltcGxlIHdheSB0byByZXNvbHZlIHRoZSBwcm9ibGVtLg0K Pg0KPlNpbmNlcmVseSBZb3Vycw0KPlh1ZXFpbiBXZWkgKFNodWV0c2luZyBXZWkpDQo+DQo+Rmli ZXJob21lIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ2llcyBDby4sTHRkLiwNCj4yMDA5LTA0 LTE4ICAxNDo0ODo1MQ0KPg0KPj09PT09PT09PT09PT09PT09PT09IEZvbGxvd2luZyBpcyB5b3Vy IGVtYWlsPT09PT09PT09PT09PT09PT09PT09DQo+U3ViamVjdDpSZTogW21wbHMtdHBdIFRhbmRl bSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgUkU6IEFzc29jaWF0ZWRiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj5TZW50o7oyMDA5LTA0LTE3IDE3OjE3OjMx DQo+RnJvbTpCZW4gTml2ZW4tSmVua2lucw0KPlRvOkJVU0kgSVRBTE87IEFkcmlhbiBGYXJyZWw7 IEFsZXhhbmRlciBWYWluc2h0ZWluIENDIHRvOm1wbHMtdHANCj4NCj4+SXRhbG8sDQo+Pg0KPj5P biAxNy8wNC8yMDA5IDA5OjM0LCAiQlVTSSBJVEFMTyIgPEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNl bnQuaXQ+IHdyb3RlOg0KPj4+IFRoZSBKV1QgYWdyZWVtZW50IGlzIHRvIGJyaW5nIHRoZSBJVFUt VCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGluIA0KPj4+IElFVEYgdG8gZXh0ZW5kIHRoZSBNUExT IGFyY2hpdGVjdHVyZSB0byBtZWV0IHRoZW0gaW4gYSB3YXkgdGhhdCBpcyANCj4+PiBjb21wYXRp YmxlLCBjb25zaXN0ZW50IGFuZCBjb2hlcmVudCB3aXRoIGV4aXN0aW5nIElFVEYgYXJjaGl0ZWN0 dXJlLg0KPj4NCj4+U28gSSB0b29rIGEgbG9vayBhdCB0aGUgSldUIHJlcG9ydC4gSXQgc2F5cyAo c2xpZGUgMTYpDQo+Pg0KPj4iIFNlcnZpY2UgUHJvdmlkZXJzIHdhbnQgTFNQcy9QV0VzIHRvIGJl IGFibGUgdG8gYmUgbWFuYWdlZCBhdCB0aGUgDQo+PmRpZmZlcmVudCBuZXN0ZWQgbGV2ZWxzIHNl YW1sZXNzbHkgKHBhdGgsIHNlZ21lbnQsIG11bHRpcGxlIHNlZ21lbnRzKQ0KPj4gICAgYWthIFRh bmRlbSBDb25uZWN0aW9uIE1vbml0b3JpbmcgKFRDTSksIHRoaXMgaXMgdXNlZCBmb3IgZXhhbXBs ZSANCj4+d2hlbiBhIExTUC9QV0UgY3Jvc3NlcyBtdWx0aXBsZSBhZG1pbmlzdHJhdGlvbnMiDQo+ Pg0KPj5JTU8gdGhlIHJlcXVpcmVtZW50IGlzIHRvIGJlIGFibGUgdG8gbW9uaXRvciBwYXJ0cyBv ZiBhIHBhdGggYXMgd2VsbCBhcyANCj4+dGhlIGVuZCB0byBlbmQgcGF0aC4gVGhlcmUgYXJlIG1h bnkgd2F5cyB0byBzb2x2ZSB0aGF0IHJlcXVpcmVtZW50LCBvbmUgDQo+Pm9mIHdoaWNoIGlzIHRo ZSBjcmVhdGlvbiBvZiBuZXN0ZWQgTFNQcywgb25lIHBlciBsZXZlbCBvZiBtb25pdG9yaW5nIA0K Pj5yZXF1aXJlZCAobXkgdW5kZXJzdGFuZGluZyBvZiBob3cgVENNIHdvcmtzKS4NCj4+DQo+Pkkg dGhpbmsgdGhlIHJlYWwgZGlzY3Vzc2lvbiBpcyB0aGVyZWZvcmUgaXMgdGhlIHJlcXVpcmVtZW50 IHRvIG1vbml0b3IgDQo+PmRpZmZlcmVudCBjb21wb25lbnRzIG9mIGFuIGVuZCB0byBlbmQgcGF0 aCBvciBpcyB0aGUgcmVxdWlyZW1lbnQgdGhhdCANCj4+c3VjaCBtb25pdG9yaW5nIE1VU1QgYmUg YWNoaWV2ZWQgdXNpbmcgbmVzdGVkIExTUHM/DQo+Pg0KPj5BcyBhbiBleGFtcGxlIFBXIHRlY2hu b2xvZ3kgdG9kYXkgYWxsb3dzIGVuZCB0byBlbmQgYW5kIHBlciBzZWdtZW50IA0KPj5tb25pdG9y aW5nIGJ1dCBpdCBkb2VzIG5vdCBhY2hpZXZlIGl0IHVzaW5nIG5lc3RlZCBQV3Mgb3IgUFcgbGV2 ZWxzLg0KPj4NCj4+QmVuDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj5tcGxzLXRwIG1haWxpbmcgbGlzdA0KPj5tcGxzLXRwQGlldGYub3Jn DQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPj4NCj4N Cj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+bXBscy10cCBtYWlsaW5nIGxpc3QNCj5tcGxzLXRwQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+DQoNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo= From liu.guoman@zte.com.cn Wed Apr 22 02:04:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B3E3A6ACE for ; Wed, 22 Apr 2009 02:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.111 X-Spam-Level: X-Spam-Status: No, score=-96.111 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIG9tLccNLBg for ; Wed, 22 Apr 2009 02:04:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id DB22F3A6BCF for ; Wed, 22 Apr 2009 02:04:35 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 11164764009499; Wed, 22 Apr 2009 16:56:02 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.2238491106; Wed, 22 Apr 2009 17:02:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3M94lUO085859; Wed, 22 Apr 2009 17:04:48 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <200904221622298593406@fiberhome.com.cn> To: xqwei@fiberhome.com.cn MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Wed, 22 Apr 2009 17:02:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-22 17:04:38, Serialize complete at 2009-04-22 17:04:38 Content-Type: multipart/alternative; boundary="=_alternative 0031DD98482575A0_=" X-MAIL: mse1.zte.com.cn n3M94lUO085859 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 09:04:37 -0000 This is a multipart message in MIME format. --=_alternative 0031DD98482575A0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGh1YW5mZW5nJ3Mgb3BpbmlvbnMsIGhlcmUgd2Ugb25seSBkaXNzY3VzcyB0aGUg cmVxdWlyZW1lbnRzIG9mIA0KVENNLiBob3cgdG8gcmVhbGl6ZSB0aGUgZnVuY3Rpb25zIG9mIFRD TSB3aWxsIGJlIGRpc3NjdXNzZWQgaW4gdGhlIGZ1dHVyZS4gDQpJIHdpc2ggdGhhdCB4dWVxaW4g Y29uc2lkZXIgaXQgdmVyeSB3ZWxsLg0KDQp0aGFuayB5b3UNCmxpdQ0KDQoNCg0KIlh1ZXFpbiBX RUkgKFNodWV0c2luZyBXRUkpIiA8eHF3ZWlAZmliZXJob21lLmNvbS5jbj4gDQq3orz+yMs6ICBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDQtMjIgMTY6MjINCsfrtPC4tCC4+A0KeHF3 ZWlAZmliZXJob21lLmNvbS5jbg0KDQoNCsrVvP7Iyw0KIkhVQU5HIEZlbmcgRiIgPEZlbmcuZi5I dWFuZ0BhbGNhdGVsLXNiZWxsLmNvbS5jbj4NCrOty80NCk1QTFMtVFAgPG1wbHMtdHBAaWV0Zi5v cmc+DQrW98ziDQpSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3 YXMgDQpSRTpBc3NvY2lhdGVkYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVu dHMpDQoNCg0KDQoNCg0KDQpGZW5nOg0KDQpUaGUgZnVuY3Rpb24gb2YgVENNIGNhbiBiZSBwcm92 aWRlZCBieSBuZXN0ZWQgTFNQIChXaGljaCBpcyB0aGUgYmFzaWMgDQpmdW5jdGlvbiBvZiBNUExT LVRQKSwgd2UgbmVlZG4ndCB0byBkZWZpbmUgVENNLg0KDQoNClNpbmNlcmVseSBZb3Vycw0KWHVl cWluIFdlaSAoU2h1ZXRzaW5nIFdlaSkNCjIwMDktMDQtMjIgIDE2OjIwOjEwDQoNCj09PT09PT09 PT09PT09PT09PT09IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09PT09PT09PT09PT09 DQpTdWJqZWN0OlJFOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdh cyANClJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50 cykNClNlbnSjujIwMDktMDQtMjAgMjE6NTg6MTgNCkZyb206SFVBTkcgRmVuZyBGDQpUbzp4cXdl aUBmaWJlcmhvbWUuY29tLmNuOyBCZW4gTml2ZW4tSmVua2luczsgQnVzaSBJdGFsbw0KQ0MgdG86 TVBMUy1UUA0KDQo+RGVhciBYdWVxaW4sDQo+ICAgICBXZSBhcmUgZGlzY3Vzc2luZyByZXF1aXJl bWVudCBvZiBUQ00sIG5vdCBmb3IgIGZ1bmN0aW9uIGFuZCBtZXRob2QgDQppbiBkZXRhaWxzLg0K PkIuUi4NCj5GZW5nIA0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbXBs cy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBP biANCkJlaGFsZiBPZiBYdWVxaW4gV0VJIChTaHVldHNpbmcgV0VJKQ0KPlNlbnQ6IDIwMDnE6jTU wjE4yNUgMTQ6NTINCj5UbzogQmVuIE5pdmVuLUplbmtpbnMNCj5DYzogTVBMUy1UUA0KPlN1Ympl Y3Q6IFJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyANClJF OkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj4N Cj5TdXBwb3J0LCBJIHRoaW5rIHRoZSBuZXN0ZWQgTFNQIHdpbGwgYmUgZ3JlYXQhIFVudGlsIG5v dywgSSBkaWRuJ3Qgc2VlIA0KYW55IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmVzdGVkIExTUCBh bmQgVENNIG9uIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcuIA0KQnV0IHRoZSBuZXN0ZWQgTFNQIHdp bGwgbWFrZSB0aGUgdGhpbmdzIG1vcmUgZWFzeS4gSSB3b3VsZCBsaWtlIHNlbGVjdCBhIA0Kc2lt cGxlIHdheSB0byByZXNvbHZlIHRoZSBwcm9ibGVtLg0KPg0KPlNpbmNlcmVseSBZb3Vycw0KPlh1 ZXFpbiBXZWkgKFNodWV0c2luZyBXZWkpDQo+DQo+RmliZXJob21lIFRlbGVjb21tdW5pY2F0aW9u IFRlY2hub2xvZ2llcyBDby4sTHRkLiwNCj4yMDA5LTA0LTE4ICAxNDo0ODo1MQ0KPg0KPj09PT09 PT09PT09PT09PT09PT09IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09PT09PT09PT09 PT09DQo+U3ViamVjdDpSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQ ICh3YXMgUkU6IA0KQXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWly ZW1lbnRzKQ0KPlNlbnSjujIwMDktMDQtMTcgMTc6MTc6MzENCj5Gcm9tOkJlbiBOaXZlbi1KZW5r aW5zDQo+VG86QlVTSSBJVEFMTzsgQWRyaWFuIEZhcnJlbDsgQWxleGFuZGVyIFZhaW5zaHRlaW4g Q0MgdG86bXBscy10cA0KPg0KPj5JdGFsbywNCj4+DQo+Pk9uIDE3LzA0LzIwMDkgMDk6MzQsICJC VVNJIElUQUxPIiA8SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdD4gd3JvdGU6DQo+Pj4gVGhl IEpXVCBhZ3JlZW1lbnQgaXMgdG8gYnJpbmcgdGhlIElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVu dHMgaW4gDQo+Pj4gSUVURiB0byBleHRlbmQgdGhlIE1QTFMgYXJjaGl0ZWN0dXJlIHRvIG1lZXQg dGhlbSBpbiBhIHdheSB0aGF0IGlzIA0KPj4+IGNvbXBhdGlibGUsIGNvbnNpc3RlbnQgYW5kIGNv aGVyZW50IHdpdGggZXhpc3RpbmcgSUVURiBhcmNoaXRlY3R1cmUuDQo+Pg0KPj5TbyBJIHRvb2sg YSBsb29rIGF0IHRoZSBKV1QgcmVwb3J0LiBJdCBzYXlzIChzbGlkZSAxNikNCj4+DQo+PiIgU2Vy dmljZSBQcm92aWRlcnMgd2FudCBMU1BzL1BXRXMgdG8gYmUgYWJsZSB0byBiZSBtYW5hZ2VkIGF0 IHRoZSANCj4+ZGlmZmVyZW50IG5lc3RlZCBsZXZlbHMgc2VhbWxlc3NseSAocGF0aCwgc2VnbWVu dCwgbXVsdGlwbGUgc2VnbWVudHMpDQo+PiAgICBha2EgVGFuZGVtIENvbm5lY3Rpb24gTW9uaXRv cmluZyAoVENNKSwgdGhpcyBpcyB1c2VkIGZvciBleGFtcGxlIA0KPj53aGVuIGEgTFNQL1BXRSBj cm9zc2VzIG11bHRpcGxlIGFkbWluaXN0cmF0aW9ucyINCj4+DQo+PklNTyB0aGUgcmVxdWlyZW1l bnQgaXMgdG8gYmUgYWJsZSB0byBtb25pdG9yIHBhcnRzIG9mIGEgcGF0aCBhcyB3ZWxsIGFzIA0K Pj50aGUgZW5kIHRvIGVuZCBwYXRoLiBUaGVyZSBhcmUgbWFueSB3YXlzIHRvIHNvbHZlIHRoYXQg cmVxdWlyZW1lbnQsIG9uZSANCj4+b2Ygd2hpY2ggaXMgdGhlIGNyZWF0aW9uIG9mIG5lc3RlZCBM U1BzLCBvbmUgcGVyIGxldmVsIG9mIG1vbml0b3JpbmcgDQo+PnJlcXVpcmVkIChteSB1bmRlcnN0 YW5kaW5nIG9mIGhvdyBUQ00gd29ya3MpLg0KPj4NCj4+SSB0aGluayB0aGUgcmVhbCBkaXNjdXNz aW9uIGlzIHRoZXJlZm9yZSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gbW9uaXRvciANCj4+ZGlmZmVy ZW50IGNvbXBvbmVudHMgb2YgYW4gZW5kIHRvIGVuZCBwYXRoIG9yIGlzIHRoZSByZXF1aXJlbWVu dCB0aGF0IA0KPj5zdWNoIG1vbml0b3JpbmcgTVVTVCBiZSBhY2hpZXZlZCB1c2luZyBuZXN0ZWQg TFNQcz8NCj4+DQo+PkFzIGFuIGV4YW1wbGUgUFcgdGVjaG5vbG9neSB0b2RheSBhbGxvd3MgZW5k IHRvIGVuZCBhbmQgcGVyIHNlZ21lbnQgDQo+Pm1vbml0b3JpbmcgYnV0IGl0IGRvZXMgbm90IGFj aGlldmUgaXQgdXNpbmcgbmVzdGVkIFBXcyBvciBQVyBsZXZlbHMuDQo+Pg0KPj5CZW4NCj4+DQo+ Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pm1wbHMt dHAgbWFpbGluZyBsaXN0DQo+Pm1wbHMtdHBAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+Pg0KPg0KPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tcGxzLXRwIG1haWxpbmcg bGlzdA0KPm1wbHMtdHBAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMtdHANCj4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptcGxzLXRwIG1haWxpbmcgbGlzdA0KbXBscy10cEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 0031DD98482575A0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgc3VwcG9ydCBodWFuZmVuZydz IG9waW5pb25zLCBoZXJlDQp3ZSBvbmx5IGRpc3NjdXNzIHRoZSByZXF1aXJlbWVudHMgb2YgVENN LiBob3cgdG8gcmVhbGl6ZSB0aGUgZnVuY3Rpb25zDQpvZiBUQ00gd2lsbCBiZSBkaXNzY3Vzc2Vk IGluIHRoZSBmdXR1cmUuIEkgd2lzaCB0aGF0IHh1ZXFpbiBjb25zaWRlciBpdA0KdmVyeSB3ZWxs LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhhbmsg eW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5saXU8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7WHVl cWluIFdFSSAoU2h1ZXRzaW5nDQpXRUkpJnF1b3Q7ICZsdDt4cXdlaUBmaWJlcmhvbWUuY29tLmNu Jmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+ yMs6ICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTIyIDE2OjIyPC9mb250Pg0KPHRhYmxlIGJvcmRl cj4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRl cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+x+u08Li0ILj4PGJyPg0KeHF3ZWlAZmli ZXJob21lLmNvbS5jbjwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTczJT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0hVQU5HIEZlbmcgRiZxdW90 OyAmbHQ7RmVuZy5mLkh1YW5nQGFsY2F0ZWwtc2JlbGwuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+TVBMUy1UUCAmbHQ7bXBscy10cEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluDQpNUExTLVRQICh3YXMgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkU6QXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9y dCBwYXRoIHJlcXVpcmVtZW50cyk8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTI+PHR0PkZlbmc6PGJyPg0KPGJyPg0KVGhlIGZ1bmN0aW9uIG9mIFRD TSBjYW4gYmUgcHJvdmlkZWQgYnkgbmVzdGVkIExTUCAoV2hpY2ggaXMgdGhlIGJhc2ljIGZ1bmN0 aW9uDQpvZiBNUExTLVRQKSwgd2UgbmVlZG4ndCB0byBkZWZpbmUgVENNLjxicj4NCjxicj4NCjxi cj4NClNpbmNlcmVseSBZb3Vyczxicj4NClh1ZXFpbiBXZWkgKFNodWV0c2luZyBXZWkpPGJyPg0K MjAwOS0wNC0yMiAmbmJzcDsxNjoyMDoxMDxicj4NCjxicj4NCj09PT09PT09PT09PT09PT09PT09 IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09PT09PT09PT09PT09PGJyPg0KU3ViamVj dDpSRTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgUkU6QXNz b2NpYXRlZGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cyk8YnI+DQpT ZW50o7oyMDA5LTA0LTIwIDIxOjU4OjE4PGJyPg0KRnJvbTpIVUFORyBGZW5nIEY8YnI+DQpUbzp4 cXdlaUBmaWJlcmhvbWUuY29tLmNuOyBCZW4gTml2ZW4tSmVua2luczsgQnVzaSBJdGFsbzxicj4N CkNDIHRvOk1QTFMtVFA8YnI+DQo8YnI+DQomZ3Q7RGVhciBYdWVxaW4sPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IFdlIGFyZSBkaXNjdXNzaW5nIHJlcXVpcmVtZW50IG9mIFRDTSwgbm90IGZvciAm bmJzcDtmdW5jdGlvbg0KYW5kIG1ldGhvZCBpbiBkZXRhaWxzLjxicj4NCiZndDtCLlIuPGJyPg0K Jmd0O0ZlbmcgPGJyPg0KJmd0Ozxicj4NCiZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDtGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQpCZWhhbGYgT2YgWHVlcWluIFdFSSAoU2h1ZXRzaW5nIFdFSSk8 YnI+DQomZ3Q7U2VudDogMjAwOcTqNNTCMTjI1SAxNDo1Mjxicj4NCiZndDtUbzogQmVuIE5pdmVu LUplbmtpbnM8YnI+DQomZ3Q7Q2M6IE1QTFMtVFA8YnI+DQomZ3Q7U3ViamVjdDogUmU6IFttcGxz LXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOkFzc29jaWF0ZWRiaWRp cmVjdGlvbmFsDQp0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpPGJyPg0KJmd0Ozxicj4NCiZn dDtTdXBwb3J0LCBJIHRoaW5rIHRoZSBuZXN0ZWQgTFNQIHdpbGwgYmUgZ3JlYXQhIFVudGlsIG5v dywgSSBkaWRuJ3QNCnNlZSBhbnkgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBuZXN0ZWQgTFNQIGFu ZCBUQ00gb24gcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4NCkJ1dCB0aGUgbmVzdGVkIExTUCB3aWxs IG1ha2UgdGhlIHRoaW5ncyBtb3JlIGVhc3kuIEkgd291bGQgbGlrZSBzZWxlY3QNCmEgc2ltcGxl IHdheSB0byByZXNvbHZlIHRoZSBwcm9ibGVtLjxicj4NCiZndDs8YnI+DQomZ3Q7U2luY2VyZWx5 IFlvdXJzPGJyPg0KJmd0O1h1ZXFpbiBXZWkgKFNodWV0c2luZyBXZWkpPGJyPg0KJmd0Ozxicj4N CiZndDtGaWJlcmhvbWUgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9naWVzIENvLixMdGQuLDxi cj4NCiZndDsyMDA5LTA0LTE4ICZuYnNwOzE0OjQ4OjUxPGJyPg0KJmd0Ozxicj4NCiZndDs9PT09 PT09PT09PT09PT09PT09PSBGb2xsb3dpbmcgaXMgeW91ciBlbWFpbD09PT09PT09PT09PT09PT09 PT09PTxicj4NCiZndDtTdWJqZWN0OlJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGlu IE1QTFMtVFAgKHdhcyBSRTogQXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCBwYXRo IHJlcXVpcmVtZW50cyk8YnI+DQomZ3Q7U2VudKO6MjAwOS0wNC0xNyAxNzoxNzozMTxicj4NCiZn dDtGcm9tOkJlbiBOaXZlbi1KZW5raW5zPGJyPg0KJmd0O1RvOkJVU0kgSVRBTE87IEFkcmlhbiBG YXJyZWw7IEFsZXhhbmRlciBWYWluc2h0ZWluIENDIHRvOm1wbHMtdHA8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZndDtJdGFsbyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7T24gMTcvMDQvMjAwOSAw OTozNCwgJnF1b3Q7QlVTSSBJVEFMTyZxdW90OyAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2Vu dC5pdCZndDsNCndyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgSldUIGFncmVlbWVudCBpcyB0 byBicmluZyB0aGUgSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KaW4gPGJyPg0KJmd0OyZn dDsmZ3Q7IElFVEYgdG8gZXh0ZW5kIHRoZSBNUExTIGFyY2hpdGVjdHVyZSB0byBtZWV0IHRoZW0g aW4gYSB3YXkNCnRoYXQgaXMgPGJyPg0KJmd0OyZndDsmZ3Q7IGNvbXBhdGlibGUsIGNvbnNpc3Rl bnQgYW5kIGNvaGVyZW50IHdpdGggZXhpc3RpbmcgSUVURiBhcmNoaXRlY3R1cmUuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0O1NvIEkgdG9vayBhIGxvb2sgYXQgdGhlIEpXVCByZXBvcnQuIEl0 IHNheXMgKHNsaWRlIDE2KTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmcXVvdDsgU2Vydmlj ZSBQcm92aWRlcnMgd2FudCBMU1BzL1BXRXMgdG8gYmUgYWJsZSB0byBiZSBtYW5hZ2VkDQphdCB0 aGUgPGJyPg0KJmd0OyZndDtkaWZmZXJlbnQgbmVzdGVkIGxldmVscyBzZWFtbGVzc2x5IChwYXRo LCBzZWdtZW50LCBtdWx0aXBsZSBzZWdtZW50cyk8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 YWthIFRhbmRlbSBDb25uZWN0aW9uIE1vbml0b3JpbmcgKFRDTSksIHRoaXMgaXMgdXNlZA0KZm9y IGV4YW1wbGUgPGJyPg0KJmd0OyZndDt3aGVuIGEgTFNQL1BXRSBjcm9zc2VzIG11bHRpcGxlIGFk bWluaXN0cmF0aW9ucyZxdW90Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtJTU8gdGhlIHJl cXVpcmVtZW50IGlzIHRvIGJlIGFibGUgdG8gbW9uaXRvciBwYXJ0cyBvZiBhIHBhdGggYXMNCndl bGwgYXMgPGJyPg0KJmd0OyZndDt0aGUgZW5kIHRvIGVuZCBwYXRoLiBUaGVyZSBhcmUgbWFueSB3 YXlzIHRvIHNvbHZlIHRoYXQgcmVxdWlyZW1lbnQsDQpvbmUgPGJyPg0KJmd0OyZndDtvZiB3aGlj aCBpcyB0aGUgY3JlYXRpb24gb2YgbmVzdGVkIExTUHMsIG9uZSBwZXIgbGV2ZWwgb2YgbW9uaXRv cmluZw0KPGJyPg0KJmd0OyZndDtyZXF1aXJlZCAobXkgdW5kZXJzdGFuZGluZyBvZiBob3cgVENN IHdvcmtzKS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7SSB0aGluayB0aGUgcmVhbCBkaXNj dXNzaW9uIGlzIHRoZXJlZm9yZSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8NCm1vbml0b3IgPGJyPg0K Jmd0OyZndDtkaWZmZXJlbnQgY29tcG9uZW50cyBvZiBhbiBlbmQgdG8gZW5kIHBhdGggb3IgaXMg dGhlIHJlcXVpcmVtZW50DQp0aGF0IDxicj4NCiZndDsmZ3Q7c3VjaCBtb25pdG9yaW5nIE1VU1Qg YmUgYWNoaWV2ZWQgdXNpbmcgbmVzdGVkIExTUHM/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 O0FzIGFuIGV4YW1wbGUgUFcgdGVjaG5vbG9neSB0b2RheSBhbGxvd3MgZW5kIHRvIGVuZCBhbmQg cGVyIHNlZ21lbnQNCjxicj4NCiZndDsmZ3Q7bW9uaXRvcmluZyBidXQgaXQgZG9lcyBub3QgYWNo aWV2ZSBpdCB1c2luZyBuZXN0ZWQgUFdzIG9yIFBXIGxldmVscy48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7QmVuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDttcGxzLXRwIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7bXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Oz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0O19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O21wbHMtdHAgbWFpbGluZyBsaXN0PGJy Pg0KJmd0O21wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0Ozxicj4NCjxicj4NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxz LXRwIG1haWxpbmcgbGlzdDxicj4NCm1wbHMtdHBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4N Cjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3Rp Y2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNw O21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7 UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQm bmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNw O25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtj b250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNw O290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5i c3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRp YWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZu YnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50 aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4m bmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtl bWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUm bmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZu YnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZu YnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5l ZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDta VEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0031DD98482575A0_=-- From andy.bd.reid@bt.com Wed Apr 22 03:13:02 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226883A6AEF for ; Wed, 22 Apr 2009 03:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.252 X-Spam-Level: * X-Spam-Status: No, score=1.252 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJNpWMIwfkMl for ; Wed, 22 Apr 2009 03:12:57 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 78D3E3A6945 for ; Wed, 22 Apr 2009 03:12:56 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.47]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 11:14:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C333.14B603B2" Date: Wed, 22 Apr 2009 11:14:11 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUg From: To: , X-OriginalArrivalTime: 22 Apr 2009 10:14:12.0518 (UTC) FILETIME=[15517C60:01C9C333] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 10:13:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C333.14B603B2 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg = misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have = a good server/section layer and a loss of CC at the client layer, I = *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys = like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will = bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so = I think every new functions and things may have positive and negative = effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like = SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance = experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper = connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse = as possible with as little config as possible because we need super = reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 =09 =09 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. =09 I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated = by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an = > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could = be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return = > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because = > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback = function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a = > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport = > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal = > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing = > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C333.14B603B2 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Liu, Allow me to jump in. You are bringing together = two things=20 which are separate and for which AIS/FDI is no help. Maintenance = operations are=20 concerned with two separate things. 1) Identifying faults in equipment, line = plant, and=20 other systems (eg misconfigurations) and fixing them (equipment=20 maintenance). 2) Identifying the health of end to end = connections,=20 especially when they are directly supporting customer services (service=20 maintenance). The problem is *not* about a lack of alarm = suppression in=20 the data plane - that information is readily available. If, at an end = equipment,=20 I have a good server/section layer and a loss of CC at the client layer, = I=20 *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you=20 think about, if the fault is in the end equipment, it is quite likely = that the=20 fault means it cannot report the traffic loss to the management=20 system!) The issue arises because the two sides of = maintenance want=20 different things. The fault fixing guys want to locate the fault and = don't want=20 any other information. The service maintenance guys want to know whether = their=20 customer service is working. This arose in the early days of SONET/SDH, when = the=20 operations guys demanded that the equipment did *not* suppress the = traffic alarm=20 even when AIS was being received as the service guys want to know about = the=20 alarms. The normal practice is for the equipment to report the = alarms=20 *including* AIS and then a filter is applied in the management = system to=20 suppress alarms to the fault fixing guys. As I'm aware, there are many = different=20 techniques applied for the filtering algorithms, especially when you = consider=20 multiple concurrent faults in a network, however, the existance of = AIS/FDI=20 doesn't add anything to these that's not already known. In fact, I = believe=20 simple time-stamp correlation is one of the most powerful and = widely used=20 techniques. And if the equipment starts messing up the reporting of loss = of CC=20 because it waiting for/persistence checking AIS/FDI, it could end = up=20 messing up simple time-stamp correlation! In practice, it is often not quite a simple as = this, as the=20 service guys like to be able to 'localise' the fault. However, under = most=20 circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter hasn't = worked for=20 some reason. But the bottom line is, whatever operations = process you=20 want to use, AIS/FDI doesn't add anything other than complexity and = fault=20 liability to the equipment. Remember AIS goes back to the TDM world = where=20 you *have to fill the bit stream with something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = =20 British=20 Telecommunications plc Registered office: 81 Newgate Street London = EC1A=20 7AJ Registered in England no. 1800000 This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009 = 09:15 To:=20 Harrison,N,Neil,CXM R Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Neil: thank you for wasting more time in = describling=20 the problems. but I think some of what you said is no relations with = our=20 problem.for me, maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. = but for=20 CO-PS networks.if there is no AIS/FDI functions, when there is a = defects in a=20 given layer network, it can cause multiple alarm events to be raised. = it is=20 diffcult for operators to locate and diagnose the faults. = though I completely agree = you on=20 adding new things and functions will bring some complexity . but = if we=20 have no functions, it is more complex and difcult for operators to = maintence=20 and administrator the network. so I think every new functions and = things may=20 have positive and negative effects. but we should consider it very = much, don't=20 delete some functions at random. best regards liu=20 <neil.2.harrison@bt.com> 2009-04-21 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = Liu, If=20 MPLS-TP is going to be taken seriously as a transport network (like = SDH/SONET)=20 then the 2 key MUST HAVE requirements are these. 1=20 Provide a transparent client/server relationship...which=20 means: - =20 all client bits treated equally - client bit ordering = preserved=20 - = no attempt=20 to infer client symbol (ie sequence of client bits) meaning and no = attempt to=20 change client symbols - the traffic behaviour of client X must not = impact the=20 performance experienced by client Y =20 A key = corollary of the=20 above is that MPLS-TP must only support proper connections (ie single = source=20 constructs) 2=20 Since MPLS-TP is a transport network it is not a top-of-stack = network=20 (ie it does not support directly external message/file/stream = applications).=20 MPLS-TP therefore does not require an E-NNI specification. = A key=20 corollary of this is that MPLS-TP will not have any peer interworking=20 relationship with any other network mode/technology. Now wrt OAM MPLS-TP is = a co-ps mode=20 network. You could argue this should have FDI/AIS....however, = the merit=20 of this is highly questionable. When I and colleagues discussed = whether=20 PBB-TE (also a co-ps mode network) should have FDI/AIS we concluded = that on=20 balance it was not a good idea.....and note that initially I was in = favour of=20 having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise. = AIS/FDI is = historically linked to=20 the early PDH co-cs mode layer networks that used TTL logic. = When this=20 died it put out a +5V (all 1s) signal by default, ie it required no = conscious=20 effort to generate it.....this is key point. Further, in these = networks=20 there is a fairly static/long-holding client server relationship.=20 Clearly this is not true in the cl-ps mode and it's why IETF = have never=20 specified AIS for IP and its why IEEE had the good sense to throw-out = AIS in=20 802.1ag for Ethernet (though ITU have unwisely IMO retained it in=20 Y.1731....but I suspect any operator planning to use Ethernet = equipment would=20 always look to IEEE stds and not ITU ones). AIS/FDI and the co-ps mode is debatable. As I noted = above, on=20 balance we considered not a good idea for PBB-TE OAM because it = requires a=20 conscious effort to generate it (unlike the co-cs mode) so there are = likely to=20 be scaling problems and its one more thing to go wrong. = You=20 should also have seen me make the point many times in the past that = the=20 always-on defect detection/handling OAM needs to be as simple/sparse = as=20 possible with as little config as possible because we need super=20 reliability......TCM goes completely against the grain here. = Also note=20 that the OAM required for each of the 3 network modes is not the same, = despite=20 what some claim. regards, Neil = From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009 = 02:59 To:=20 BRUNGARD, DEBORAH A, ATTLABS Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah: maybe what you said is right. but I can't completely = agree your=20 opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. = so it=20 should have AIS/FDI fuctions as SDH/SONET.=20 do you think = so. best = regards liu "BRUNGARD, = DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten = Vissers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with Neil, it = is very=20 questionable the value of AIS/FDI in a packet network- any mode. It = can=20 result in a DoS attack by an operator on themselves so even Y1731=20 recommends not to block data frames: "A MEP can decide whether it = blocks=20 data frames when it detects dAIS. The principle requirement that = influences this decision is that data frames ought to be = forwarded as much=20 as possible, without the possibility of forwarding wrong data = frames=20 downstream." Table I.7-2 shows for AIS, not to block. And as = Y1731=20 states, AIS can only be used under very constrained architectures - = if=20 required for MPLS-TP, it needs to have the same guidance as in = Y1731, i.e.=20 point-to-point and server/client one-to-one: "for a point-to-point = ETH=20 connection, a MEP has only a single peer MEP. Therefore, = there is no=20 ambiguity regarding the peer MEP for which it should = suppress alarms when=20 it receives the ETH-AIS information." So should only be within = one=20 domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten = Vissers Sent:=20 Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements Neil, > but AIS/FDI in the cl = mode?...do=20 me a favour! Ethernet AIS is indeed a requirement and a = necessity. And=20 you will not be able to understand that as long as you refuse to = accept=20 that "cl-mode" is a forwarding mode within a **transport = entity**. G.800=20 amendment 1 has finally reintroduced this transport entity into = G.800.=20 Besides that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is a = transport=20 entity that transfers information belonging to multiple = communications=20 between ports across a subnetwork. <..> In a differentiated=20 connection message contents are interpreted to identify (sets = of)=20 communications which receive different treatment. The sets = of=20 communications may be distinguished by the forwarding identifier or = other=20 layer information. Order is not necessarily preserved = between=20 messages belonging to sets of communications receiving different = treatment.=20 Sets of communications may be identified for purposes such = as=20 traffic conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 = "differentiated=20 connections". Ethernet AIS provides AIS within the scope of such = "differentiated connection". If you apply this to my proposed = PTN layer=20 stack, then the EVC layer topology will consists of EVC links = supported=20 by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro = and core=20 domains interconnecting EVC matrices. When one of those EVC = links is=20 interrupted, e.g. in the core between metro 1 and metro 4 (see = attached=20 slide), then the EVC differentiated connection that is present = on this=20 link will be interrupted. At the EVC switch/bridge node in metro = 4 this=20 interruption is noticed and EVC-AIS is inserted in the downstream = direction=20 to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. The=20 EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which=20 guarantees that the AIS is broadcast to the endpoints of the = EVC. I=20 believe that it is time for you to adapt your view on co and cl=20 modes and relate it to the forwarding mode **INSIDE** a = transport=20 entity. What we know as the internet is essentially an "IP=20 differentiated connection" with a billion or more ports. What we = know as=20 an IP VPN is essentially an "IP differentiated connection" with = e.g. n=20 ports (n in the range of e.g. 2 to 1000). What we know as an = Ethernet VLAN=20 is essentially an "Ethernet differentiated connection" with n = ports (n=20 in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP = is=20 essentially an "MPLS differentiated connection" with 2 = ports. What we=20 know as a p2p SDH VC-n is a "SDH VC-n connection" with 2=20 ports. Transport network OAM applies to transport entities, = which are=20 (in terms of G.800 am1) connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com = [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting a wee = bit=20 tired of folks trying to make all 3 network modes look alike = (and then,=20 even worse, interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I am = even=20 more frustrated by the fact those peddling this FUD only ever seem = to=20 consider OAM and forget all other DP/CP/MP components (esp = top-of-stack=20 message/file/stream application adaptations). How wrong can = this get!=20 In the co modes a *connection* is a very specific and=20 *constraining* construct.....I am assuming here we respect the = rules of a=20 connection (ie single source) though some folks don't even = bother to=20 respect this, and this is despite the fact that we all know what = problems multiple-source constructs can cause (from LDP/PHP....ergo = MPLS-TP). When we have a connection this restricts *all* DP (ie = traffic=20 and OAM) to stay within the bounds of the connection. = Which is=20 fine under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is broken. = In=20 a nutshell what this means is that OAM that is of a = request/response=20 nature cannot be trusted in co mode networks under misconnectivity=20 defects.....indeed, why should a leaking DP have a symmetric = go/return=20 defect behaviour?....very likely it won't. So whilst = request/response=20 OAM is right for the cl mode it is not right for the co mode = under=20 misconnectivity defect conditions. More generally the 3 modes = are=20 different and not just in OAM requirements....but AIS/FDI in the cl = mode?...do me a favour!...at least IEEE had the good sense to bin = this for=20 Ethernet even though it remains in Y.1731. And which is = why I=20 often trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found it = necessary to=20 create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies = in the=20 physics...and G.800 attempts to explain that physics....G.805 does=20 not. So, the 3 modes are different...please accept/rejoice in = this fact=20 as they all offer something different/important. But do = not be=20 hoodwinked by those who peddle a story that that tries to make = the OAM=20 of the 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > = Sent: 17=20 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten = Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > requirements > >=20 Italo, > > As described in the MPLS TP OAM Requirements = I-D,=20 virtually all of the > OAM functions require a return path, = and in=20 the absence of a return > path they are disabled. > = > As=20 described in David Sinicrope's meeting minutes >=20 (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > = meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP = addressing=20 is used, an > MPLS TP network needs to be capable of getting IP = packets=20 from > destination to source; neither the minutes nor I = stipulate that=20 a > control plane needs to be used to instantiate this=20 forwarding. > > As an aside, the issue of return path for = unidirectional LSPs could be > charaterized as the elephant = in the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs = are only=20 mentioned three times and return > paths not at all. > = >=20 Thanks, > > John > > -----Original = Message----- >=20 > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > = > Sent:=20 Friday, April 17, 2009 1:59 AM > > To: Drake, John E; = Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > = >=20 Subject: RE: [mpls-tp] Associated bidirectional transport path = > >=20 requirements > > > > John, > > > = > I=20 might have missed the agreement of MPLS-TP being capable of > = >=20 sending replies to OAM requests sent on uni-directional LSPs. > = >=20 > > This requirement does not belong to the first set of=20 requirements > > ITU-T is expecting to be met by = October. >=20 > > > However, I think this in a potential interesting = additional=20 > > requirement to be taken into account (at worst in = a >=20 subsequent phase). > > > > I think that this = requirement=20 needs to be evaluated versus other > > more important = requirements=20 (e.g. the possibility to work w/o IP > > forwarding and the = need for=20 OAM to continue to monitor the data > > plane also in case = of=20 failures affecting the control or management > > = plane). >=20 > > > I am open to discuss it but not sure this is the = right time=20 because > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = > >=20 > -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of Drake, John E > > > Sent: Thursday, April 16, = 2009=20 8:00 PM > > > To: Alexander Vainshtein; Maarten = Vissers >=20 > > Cc: mpls-tp@ietf.org > > > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > > >=20 requirements > > > > > > At the meeting last = fall at=20 Juniper in Massachusetts, I > > think it was > > = > agreed=20 that an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM packets = (e.g.,=20 sending > > replies to OAM > > > requests sent on = uni-directional LSPs) even if it does not > > have an = IP > >=20 > forwarding data plane. > > > > > > >=20 -----Original Message----- > > > > From: Alexander=20 Vainshtein > > > = [mailto:Alexander.Vainshtein@ecitele.com] >=20 > > > Sent: Thursday, April 16, 2009 9:57 AM > > = > >=20 To: Maarten Vissers > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > > = > >=20 > Maarten, > > > > It seems that you've just = (implicitly=20 and, probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will not ever = support MIP=20 loopback function > > (and fault > > > > = localization=20 which requires this function ) for > > unidirectional = P2MP >=20 > > > and P2P paths. > > > > > > = > >=20 If this statement is correct, this (IMHO and FWIW) > raises a=20 valid > > > > question: > > > > > = >=20 > > = Is=20 MPLS-TP an appropriate solution for these > types of = transport >=20 > > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > functionality=20 today > > > > for (unidirectional - but it does not = know any=20 other > > type) P2P LSPs > > > > as described = in RFC=20 4379. And its extension to P2MP LSPs seems > > > >=20 easy... > > > > > > > > > = >=20 > > > > > > Regards, > > > > = >=20 > > > Sasha > > > > = > >=20 > > > > > > > > > >=20 ________________________________________ > > > > From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: Thursday, = April 16,=20 2009 3:24 PM > > > > To: 'Adrian Farrel' > > = > >=20 Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > > = requirements > >=20 > > > > > > Adrian, > > > > = > >=20 > > >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > > = > >=20 other internal > > > > >> = functions=20 as appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> path at = each=20 (sub-)layer MUST be aware of the pairing > > > > = >>=20 relationship of the forward and the = backward > >=20 > > directions of that > > > > >> = =20 transport path. > > > > >> <end=20 quote> > > > > > > > > > > = There is no=20 way this is a functional requirement. That > > > is, there = is > > > > > *nothing* that can be observed from a = black box=20 point of > > > view that > > > > > = results from=20 adhering to this requirement. > > > > > > = > >=20 Your understanding is not correct. It is very much > observable=20 if > > > > this requirement is met from a black box = point of=20 view. > > > > The MIP functions can only perform the = Loopback=20 when there is a > > > > co-routed bidirectional = transport=20 path. The MPLS-TP LBM packet > > > > received at a MIP = needs=20 to be returned (as LBR > > > > packet) to the = originating MEP=20 function via the other > > direction of > > > = > the=20 co-routed bidirectional transport path. This other > = direction >=20 > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > = > >=20 would fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, then > = >=20 > > this is possible in a co-routed bidir transport path > = but not=20 in a > > > > associated bidir transport path. In the = first case=20 the TCM MEP > > > > Source and Sink functions are = co-located=20 and can > exchange what is > > > > called "remote = information" which is necessary for performance > > > = >=20 monitoring. > > > > In the latter case the TCM MEP = Source and=20 Sink functions > > are in e.g. > > > > = different=20 nodes in the network and TCM would not be able > > to = provide >=20 > > > performance monitoring. > > > > > = >=20 > > > The entirety of the bracketted text "(including = MEPs, >=20 > > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does = not >=20 > > > add to "The > > > > > intermediate=20 nodes." > > > > > > > > Your = understanding is=20 not correct. This text must not be > > deleted at > = > >=20 > all. > > > > > > > > > = Actually, I am=20 quite fed up about this persistent > > > insistence on = the >=20 > > > inclusion > > > > > of "Tandem = Connection."=20 The definition within the ITU-T of > > > > this = term >=20 > > > > is > > > > poorly > > > = >=20 > specified and comes from the monitoring of a path that is > = >=20 > > parallel (i.e. > > > > tandem) > > = > >=20 > to the data path being monitored. This definition of TC > = > >=20 > seems to be at > > > > variance, > > > = >=20 > and would be if the ACH was actually in band. > > > = >=20 > > > > I don't understand where your interpretation = of=20 tandem > > connection is > > > > described in = ITU-T=20 recommendations. I.e. "from the > > monitoring of a > = > >=20 > path that is parallel (i.e. tandem) to the data path being = > >=20 > > monitored."? > > > > > > > > = There is=20 a "network connection" and this network > > connection is a=20 set > > > > of interconnected "link connections" and=20 "matrix > connections". A > > > > subset of those = interconnected link connections and matrix > > > > = connections=20 can be monitored and is then referred to as > a "tandem > = >=20 > > connection". There is no "path that is parallel to = the > >=20 data path". > > > > There is only additional OAM = inserted=20 inside the data > path by the > > > > TCM MEP_So = function=20 and this OAM is extracted from the > > data path by > = > >=20 > the TCM MEP_Sk function. > > > > > > = > >=20 Regards, > > > > Maarten > > > > = > >=20 > > > > > > -----Original Message----- > = > >=20 > From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > = > >=20 > Sent: donderdag 16 april 2009 11:59 > > > > To: = Alexander=20 Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: = BUSI=20 ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi = Sasha, >=20 > > > > > > > > Unfortunately I cannot = fully agree=20 with your statement: > > > > > > > > = > >=20 <quote> > > > > > From the point = of view=20 of hardware, co-routed > > > bidirectional LSPs > = > >=20 > > are a special case of associated bidirectional = LSPs. > > > > > <end quote> > > > = >=20 > > > > > > This statement would be obviously = correct,=20 were it not for > > > > Requirement > > > = > >=20 34 in the latest MPLS-TP requirements draft > > > > = >=20 > > > OK. Got it. > > > > > > > = > But=20 what is this doing in the data plane requirements section? > = > >=20 > > > > > In fact, what is this requirement = actually=20 saying? > > > > > > > > >=20 <quote> > > > > > The = intermediate=20 nodes (including MEPs, MIPs and > > > other = internal > >=20 > > > functions as appropriate) of a=20 co-routed > > > > bidirectional transport > > = >=20 > > path at each (sub-)layer MUST be aware = of the=20 pairing > > > > > relationship = of the=20 forward and the backward > > > > directions of = that >=20 > > > > transport path. > > = >=20 > > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > > = is, there=20 is > > > > *nothing* that can be observed from a black = box=20 point of > > view that > > > > results from = adhering=20 to this requirement. > > > > > > > > = Therefore=20 it could be assumed that this requirement is met by > > > = >=20 configuring some data plane database component through the > = > >=20 > management plane. The database component is not used > for=20 anything > > > > except to satisfy this requirement for = "awareness". > > > > > > > > Ben! Can = we please=20 try to rewrite this requirement in terms of > > > >=20 behavior? > > > > > > > > > Please = note that=20 Requirement 34 is the ONLY item in the > > > > list = that=20 is > > > > > specific for co-routed bidirectional = LSPs. (The=20 pairing > > > > requirements > > > > = > at end=20 points for co-routed and associated bidirectional > > > = paths=20 are > > > > > exactly the same even if they appear = in two=20 different > > > items in the > > > > >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > > = >=20 bidirectional paths would be void of any data plane content. > = > >=20 > > > > > > > The somewhat vague scope of this = requirement ("other internal > > > > > functions as = appropriate") creates a suspicion that HW > > > > = support of=20 the > > > > > pairing awareness may be required in = order to=20 comply with it. > > > > > > > > The = entirety of=20 the bracketted text "(including MEPs, > > MIPs and = other > >=20 > > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate = nodes." >=20 > > > > > > > > The following text in the = draft=20 increases this suspicion: > > > > > > > = > >=20 > <quote> > > > > > Tandem = Connection: A=20 tandem connection is an > > arbitrary part of a > > = >=20 > > transport path that can be monitored (via = OAM) > >=20 > > independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > segment or=20 a > > > > > monitored concatenated segment of = a=20 transport path. > > The tandem > > > > = >=20 connection may also include the forwarding engine(s) of > = >=20 > > the node(s) > > > > > at the = edge(s) of the=20 segment or concatenated segment. > > > > > <end=20 quote> > > > > > > > > Actually, I = am quite=20 fed up about this persistent > > insistence on the > = > >=20 > inclusion of "Tandem Connection." The definition within > = > the=20 ITU-T of > > > > this term is poorly specified and = comes from=20 the > monitoring of a > > > > path that is = parallel (i.e.=20 tandem) to the data path being > > > > monitored. This = definition of TC seems to be at variance, > > and = would > >=20 > > be if the ACH was actually in band. > > > > = >=20 > > > > Doesn't "forwarding engine" sound like hardware to = you? > > > > > > > > Yes, but so = what? >=20 > > > > > > > > IMHO it is worth noting = that=20 neither the MPLS-TP > > > Requirements draft > > = >=20 > > nor the MPLS-TP OAM requirements one > > > > = >=20 > > > > > > > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing with=20 tandem > > > connections. > > > > = > > >=20 > > > But tandem connections are discussed in the MPLS-TP = OAM >=20 > Framework > > > > > draft > > > = >=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > = >=20 > > amework-00.txt > > > > ). > > > = >=20 > > > > Right. > > > > Let's just get = rid of an=20 unnecessary term and bring all > the I-Ds > > > > = into=20 line. > > > > > > > > > The bottom = line,=20 IMHO, is that some clarity regarding > > > co-routed = vs. >=20 > > > > associated > > > > > = bidirectional paths=20 is still required. One way to provide > > > > that=20 could > > > > > be by explicitly limiting = Requirement 34 to=20 specific > > > functionality. > > > > = > >=20 > > Agreed. > > > > > > > >=20 Adrian > > > > > > > > > > = > >=20 > > > > > > > >=20 ________________________________________ > > > > From: = Adrian=20 Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, = April 16,=20 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou = Berger;=20 BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = > >=20 > > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > Not really sure = whether=20 you are misrepresenting anyone, but... > > > > > = >=20 > > > 1. My reading of one of Ben's messages is = that=20 associated > > > > > bidirectional paths are the = only types=20 of paths that can be > > > > created in > > = > >=20 > the existing networks; "true" co-routed bidirectional = paths > >=20 > > will have > > > > > to wait until (if = ever) new=20 equipment becomes available. > > > > > > > = >=20 This is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > > = > >=20 a special case of associated bidirectional LSPs. > > > = >=20 > > > > If you can set up two unidirectional LSPs = (e.g. using=20 the > > management > > > > plane) you can = surely set=20 up a co-routed > > > bidirectional LSP. > > > = >=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using the = control=20 plane. These either use the GMPLS > > (which is > > = >=20 > cleaner) or non-standard proprietary solutions (which is > = >=20 messy but > > > > functional). > > > > = >=20 > > > But (of course) the management plane or control = plane >=20 > solutions have > > > > nothing to do with = availability of=20 equipment as they > are = software >=20 > > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the actual > = > >=20 > driver for > > > > > co-routed bidirectional = paths may=20 be experience with existing > > > > > transport = networks=20 rather than any specific benefit. > > > > > > = >=20 > Isn't that the case with 75% of the MPLS-TP requirements? > = >=20 > > Which is not to say it is a bad thing. > > > = >=20 > > > > A large driver for MPLS-TP is to give the = packet=20 network > > the look, > > > > feel, and = behavioral=20 characteristics of a "legacy" > > > > transport=20 network. > > > > > > > > > Based on = these=20 observations, I'd guess (FWIW) that: > > > > > * = associated=20 bidirectional paths are, at least for the time > > > > = >=20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = > >=20 > > I think that is wrong both given my statement above, = and >=20 > given that > > > > other upgrades to existing MPLS = solutions will be > needed to reach > > > > the = full=20 function level of MPLS-TP. > > > > > > > = > >=20 * they had a good chance to remain the only type of > >=20 bidirectional > > > > > paths in real=20 deployments. > > > > > > > > I don't = see what=20 that follows from. > > > > > > > >=20 Cheers, > > > > Adrian > > > > > = >=20 > > _______________________________________________ > > = >=20 > mpls-tp mailing list > > > > = mpls-tp@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > = > >=20 > > > >=20 _______________________________________________ > > > > = mpls-tp=20 mailing list > > > > mpls-tp@ietf.org > > > = >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > > = >=20 > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = > >=20 > _______________________________________________ > = mpls-tp=20 mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing = = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this mail is = solely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy = and are=20 not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender. This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9C333.14B603B2-- From Alexander.Vainshtein@ecitele.com Wed Apr 22 03:28:35 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F5928C4A5 for ; Wed, 22 Apr 2009 03:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.991 X-Spam-Level: X-Spam-Status: No, score=0.991 tagged_above=-999 required=5 tests=[AWL=-3.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdEVH5MB+oyl for ; Wed, 22 Apr 2009 03:28:30 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 0948D3A68B4 for ; Wed, 22 Apr 2009 03:28:26 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 22 Apr 2009 13:36:36 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 13:29:42 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 22 Apr 2009 13:29:41 +0300 From: Alexander Vainshtein To: "andy.bd.reid@bt.com" Date: Wed, 22 Apr 2009 13:29:40 +0300 Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAAIWOFA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76A8CF16E022ILPTMAIL02eci_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2009 10:29:42.0718 (UTC) FILETIME=[3FC2BDE0:01C9C335] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 10:28:35 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76A8CF16E022ILPTMAIL02eci_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QW5keSwNCkkgY2Fubm90IGFncmVlIG1vcmUuDQoNCkluZGVlZCwgaW4gdGhlIFRETSB3b3JsZCB5 b3UgaGFkIHRvIGZpbGwgdGhlIGNsaWVudCBiaXQgc3RyZWFtIHdpdGggc29tZXRoaW5nIHByZWRp Y3RhYmxlIEFORCBkaXN0aW5ndWlzaGFibGUgZnJvbSB2YWxpZCBjbGllbnQgdHJhZmZpYy4NCklu IHRoZSBwYWNrZXQgd29ybGQsIGxvc3Mgb2Ygc2VydmVyIGNvbm5lY3Rpdml0eSBtZWFucyB0aGF0 IHRoZSBjbGllbnQgYXBwbGljYXRpb24gZG9lcyBub3QgcmVjZWl2ZSBhbnkgcGFja2V0cywgc28g dGhlcmUgaXMgbm90aGluZyB0byBtaXNpbnRlcnByZXQgYXMgY2xpZW50IHRyYWZmaWMuDQpIZW5j ZSBubyBuZWVkIHRvICJmaWxsIGluIiBBSVMvRkRJLg0KDQpSZWdhcmRzLA0KICAgIFNhc2hhDQoN Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIGFuZHkuYmQucmVpZEBidC5jb20NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjIsIDIw MDkgMToxNCBQTQ0KVG86IGxpdS5ndW9tYW5AenRlLmNvbS5jbjsgbmVpbC4yLmhhcnJpc29uQGJ0 LmNvbQ0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KDQpMaXUsDQoN CkFsbG93IG1lIHRvIGp1bXAgaW4uIFlvdSBhcmUgYnJpbmdpbmcgdG9nZXRoZXIgdHdvIHRoaW5n cyB3aGljaCBhcmUgc2VwYXJhdGUgYW5kIGZvciB3aGljaCBBSVMvRkRJIGlzIG5vIGhlbHAuIE1h aW50ZW5hbmNlIG9wZXJhdGlvbnMgYXJlIGNvbmNlcm5lZCB3aXRoIHR3byBzZXBhcmF0ZSB0aGlu Z3MuDQoNCjEpICBJZGVudGlmeWluZyBmYXVsdHMgaW4gZXF1aXBtZW50LCBsaW5lIHBsYW50LCBh bmQgb3RoZXIgc3lzdGVtcyAoZWcgbWlzY29uZmlndXJhdGlvbnMpIGFuZCBmaXhpbmcgdGhlbSAo ZXF1aXBtZW50IG1haW50ZW5hbmNlKS4NCjIpICBJZGVudGlmeWluZyB0aGUgaGVhbHRoIG9mIGVu ZCB0byBlbmQgY29ubmVjdGlvbnMsIGVzcGVjaWFsbHkgd2hlbiB0aGV5IGFyZSBkaXJlY3RseSBz dXBwb3J0aW5nIGN1c3RvbWVyIHNlcnZpY2VzIChzZXJ2aWNlIG1haW50ZW5hbmNlKS4NCg0KVGhl IHByb2JsZW0gaXMgKm5vdCogYWJvdXQgYSBsYWNrIG9mIGFsYXJtIHN1cHByZXNzaW9uIGluIHRo ZSBkYXRhIHBsYW5lIC0gdGhhdCBpbmZvcm1hdGlvbiBpcyByZWFkaWx5IGF2YWlsYWJsZS4gSWYs IGF0IGFuIGVuZCBlcXVpcG1lbnQsIEkgaGF2ZSBhIGdvb2Qgc2VydmVyL3NlY3Rpb24gbGF5ZXIg YW5kIGEgbG9zcyBvZiBDQyBhdCB0aGUgY2xpZW50IGxheWVyLCBJICprbm93KiB0aGUgZmF1bHQg aXMgZWxzZXdoZXJlIC0gSSBkb24ndCBuZWVkIEFJUy9GREkgdG8gdGVsbCBtZS4gKEluZGVlZCwg aWYgeW91IHRoaW5rIGFib3V0LCBpZiB0aGUgZmF1bHQgaXMgaW4gdGhlIGVuZCBlcXVpcG1lbnQs IGl0IGlzIHF1aXRlIGxpa2VseSB0aGF0IHRoZSBmYXVsdCBtZWFucyBpdCBjYW5ub3QgcmVwb3J0 IHRoZSB0cmFmZmljIGxvc3MgdG8gdGhlIG1hbmFnZW1lbnQgc3lzdGVtISkNCg0KVGhlIGlzc3Vl IGFyaXNlcyBiZWNhdXNlIHRoZSB0d28gc2lkZXMgb2YgbWFpbnRlbmFuY2Ugd2FudCBkaWZmZXJl bnQgdGhpbmdzLiBUaGUgZmF1bHQgZml4aW5nIGd1eXMgd2FudCB0byBsb2NhdGUgdGhlIGZhdWx0 IGFuZCBkb24ndCB3YW50IGFueSBvdGhlciBpbmZvcm1hdGlvbi4gVGhlIHNlcnZpY2UgbWFpbnRl bmFuY2UgZ3V5cyB3YW50IHRvIGtub3cgd2hldGhlciB0aGVpciBjdXN0b21lciBzZXJ2aWNlIGlz IHdvcmtpbmcuDQoNClRoaXMgYXJvc2UgaW4gdGhlIGVhcmx5IGRheXMgb2YgU09ORVQvU0RILCB3 aGVuIHRoZSBvcGVyYXRpb25zIGd1eXMgZGVtYW5kZWQgdGhhdCB0aGUgZXF1aXBtZW50IGRpZCAq bm90KiBzdXBwcmVzcyB0aGUgdHJhZmZpYyBhbGFybSBldmVuIHdoZW4gQUlTIHdhcyBiZWluZyBy ZWNlaXZlZCBhcyB0aGUgc2VydmljZSBndXlzIHdhbnQgdG8ga25vdyBhYm91dCB0aGUgYWxhcm1z LiBUaGUgbm9ybWFsIHByYWN0aWNlIGlzIGZvciB0aGUgZXF1aXBtZW50IHRvIHJlcG9ydCB0aGUg YWxhcm1zICppbmNsdWRpbmcqIEFJUyBhbmQgdGhlbiBhIGZpbHRlciBpcyBhcHBsaWVkIGluIHRo ZSBtYW5hZ2VtZW50IHN5c3RlbSB0byBzdXBwcmVzcyBhbGFybXMgdG8gdGhlIGZhdWx0IGZpeGlu ZyBndXlzLiBBcyBJJ20gYXdhcmUsIHRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB0ZWNobmlxdWVz IGFwcGxpZWQgZm9yIHRoZSBmaWx0ZXJpbmcgYWxnb3JpdGhtcywgZXNwZWNpYWxseSB3aGVuIHlv dSBjb25zaWRlciBtdWx0aXBsZSBjb25jdXJyZW50IGZhdWx0cyBpbiBhIG5ldHdvcmssIGhvd2V2 ZXIsIHRoZSBleGlzdGFuY2Ugb2YgQUlTL0ZESSBkb2Vzbid0IGFkZCBhbnl0aGluZyB0byB0aGVz ZSB0aGF0J3Mgbm90IGFscmVhZHkga25vd24uIEluIGZhY3QsIEkgYmVsaWV2ZSBzaW1wbGUgdGlt ZS1zdGFtcCBjb3JyZWxhdGlvbiBpcyBvbmUgb2YgdGhlIG1vc3QgcG93ZXJmdWwgYW5kIHdpZGVs eSB1c2VkIHRlY2huaXF1ZXMuIEFuZCBpZiB0aGUgZXF1aXBtZW50IHN0YXJ0cyBtZXNzaW5nIHVw IHRoZSByZXBvcnRpbmcgb2YgbG9zcyBvZiBDQyBiZWNhdXNlIGl0IHdhaXRpbmcgZm9yL3BlcnNp c3RlbmNlIGNoZWNraW5nIEFJUy9GREksIGl0IGNvdWxkIGVuZCB1cCBtZXNzaW5nIHVwIHNpbXBs ZSB0aW1lLXN0YW1wIGNvcnJlbGF0aW9uIQ0KDQpJbiBwcmFjdGljZSwgaXQgaXMgb2Z0ZW4gbm90 IHF1aXRlIGEgc2ltcGxlIGFzIHRoaXMsIGFzIHRoZSBzZXJ2aWNlIGd1eXMgbGlrZSB0byBiZSBh YmxlIHRvICdsb2NhbGlzZScgdGhlIGZhdWx0LiBIb3dldmVyLCB1bmRlciBtb3N0IGNpcmN1bXN0 YW5jZXMsIHRoZSBmaWx0ZXIgaGFzIGF1dG9tYXRpY2FsbHkgZG9uZSB0aGlzLiBTbyBsb2NhbGlz YXRpb24geW91IGRlc2NyaWJlIGlzIG9ubHkgd2hlbiB0aGUgZmlsdGVyIGhhc24ndCB3b3JrZWQg Zm9yIHNvbWUgcmVhc29uLg0KDQpCdXQgdGhlIGJvdHRvbSBsaW5lIGlzLCB3aGF0ZXZlciBvcGVy YXRpb25zIHByb2Nlc3MgeW91IHdhbnQgdG8gdXNlLCBBSVMvRkRJIGRvZXNuJ3QgYWRkIGFueXRo aW5nIG90aGVyIHRoYW4gY29tcGxleGl0eSBhbmQgZmF1bHQgbGlhYmlsaXR5IHRvIHRoZSBlcXVp cG1lbnQuIFJlbWVtYmVyIEFJUyBnb2VzIGJhY2sgdG8gdGhlIFRETSB3b3JsZCB3aGVyZSB5b3Ug KmhhdmUgdG8gZmlsbCB0aGUgYml0IHN0cmVhbSB3aXRoIHNvbWV0aGluZyouDQoNCg0KDQpBbmR5 DQoNCg0KQW5keSBSZWlkDQpDaGllZiBOZXR3b3JrIFNlcnZpY2VzIFN0cmF0ZWdpc3QNCkJUIElu bm92YXRlDQoNCk9mZmljZTogKzQ0ICgwKTEyNzcgMzIyMDM4DQpNb2JpbGU6ICs0NCAoMCk3OTE3 IDAyNTQ1MQ0KRmF4IDogICAgICAgKzQ0ICgwKTEyNzcgMzI0MDE1DQpFbWFpbDogIGFuZHkuYmQu cmVpZEBidC5jb20NCg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQpSZWdpc3RlcmVk IG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQpSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgbm8uIDE4MDAwMDANClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGlu Zm9ybWF0aW9uIGZyb20gQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjIHdoaWNoIG1heSBi ZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVk IHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBh Ym92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0 IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250 ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGJ5 IHRlbGVwaG9uZSBvciBlbWFpbCAodG8gdGhlIG51bWJlcnMgb3IgYWRkcmVzcyBhYm92ZSkgaW1t ZWRpYXRlbHkuDQoNCkFjdGl2aXR5IGFuZCB1c2Ugb2YgdGhlIEJyaXRpc2ggVGVsZWNvbW11bmlj YXRpb25zIHBsYyBlbWFpbCBzeXN0ZW0gaXMgbW9uaXRvcmVkIHRvIHNlY3VyZSBpdHMgZWZmZWN0 aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBidXNpbmVzcyBwdXJwb3Nlcy4gQ29t bXVuaWNhdGlvbnMgdXNpbmcgdGhpcyBzeXN0ZW0gd2lsbCBhbHNvIGJlIG1vbml0b3JlZCBhbmQg bWF5IGJlIHJlY29yZGVkIHRvIHNlY3VyZSBlZmZlY3RpdmUgb3BlcmF0aW9uIGFuZCBmb3Igb3Ro ZXIgbGF3ZnVsIGJ1c2luZXNzIHB1cnBvc2VzLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMt dHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpdS5ndW9tYW5AenRlLmNvbS5jbg0K U2VudDogMjIgQXByaWwgMjAwOSAwOToxNQ0KVG86IEhhcnJpc29uLE4sTmVpbCxDWE0gUg0KQ2M6 IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KDQoNCk5laWw6DQogIHRoYW5r IHlvdSBmb3Igd2FzdGluZyBtb3JlIHRpbWUgaW4gZGVzY3JpYmxpbmcgdGhlIHByb2JsZW1zLiBi dXQgSSB0aGluayBzb21lIG9mIHdoYXQgeW91IHNhaWQgaXMgbm8gcmVsYXRpb25zIHdpdGggb3Vy IHByb2JsZW0uZm9yIG1lLCBtYXliZSBBSVMvRkRJIGZ1bmN0aW9ucyBpcyBubyBzZW5zZSBpbiBj bC1wcyAsZWcuIElQLiBidXQgZm9yIENPLVBTIG5ldHdvcmtzLmlmIHRoZXJlIGlzIG5vIEFJUy9G REkgZnVuY3Rpb25zLCB3aGVuIHRoZXJlIGlzIGEgZGVmZWN0cyBpbiBhIGdpdmVuIGxheWVyIG5l dHdvcmssIGl0IGNhbiBjYXVzZSBtdWx0aXBsZSBhbGFybSBldmVudHMgdG8gYmUgcmFpc2VkLiBp dCBpcyBkaWZmY3VsdCAgZm9yIG9wZXJhdG9ycyB0byBsb2NhdGUgYW5kIGRpYWdub3NlIHRoZSBm YXVsdHMuDQogdGhvdWdoIEkgY29tcGxldGVseSBhZ3JlZSB5b3Ugb24gIGFkZGluZyBuZXcgdGhp bmdzIGFuZCBmdW5jdGlvbnMgd2lsbCBicmluZyBzb21lIGNvbXBsZXhpdHkgLiBidXQgaWYgd2Ug aGF2ZSBubyBmdW5jdGlvbnMsIGl0IGlzIG1vcmUgY29tcGxleCBhbmQgZGlmY3VsdCBmb3Igb3Bl cmF0b3JzIHRvIG1haW50ZW5jZSBhbmQgYWRtaW5pc3RyYXRvciB0aGUgbmV0d29yay4gc28gSSB0 aGluayBldmVyeSBuZXcgZnVuY3Rpb25zIGFuZCB0aGluZ3MgbWF5IGhhdmUgcG9zaXRpdmUgYW5k IG5lZ2F0aXZlIGVmZmVjdHMuIGJ1dCB3ZSBzaG91bGQgY29uc2lkZXIgaXQgdmVyeSBtdWNoLCBk b24ndCBkZWxldGUgc29tZSBmdW5jdGlvbnMgYXQgcmFuZG9tLg0KDQoNCmJlc3QgcmVnYXJkcw0K bGl1DQoNCg0KPG5laWwuMi5oYXJyaXNvbkBidC5jb20+DQoNCjIwMDktMDQtMjEgMjA6MzANCg0K ytW8/sjLDQo8bGl1Lmd1b21hbkB6dGUuY29tLmNuPiwgPGRicnVuZ2FyZEBhdHQuY29tPg0Ks63L zQ0KPG1wbHMtdHBAaWV0Zi5vcmc+DQrW98ziDQpSRTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0KDQoNCg0KDQoNCg0KTGl1 LA0KDQpJZiBNUExTLVRQIGlzIGdvaW5nIHRvIGJlIHRha2VuIHNlcmlvdXNseSBhcyBhIHRyYW5z cG9ydCBuZXR3b3JrIChsaWtlIFNESC9TT05FVCkgdGhlbiB0aGUgMiBrZXkgTVVTVCBIQVZFIHJl cXVpcmVtZW50cyBhcmUgdGhlc2UuDQoNCjEgICAgUHJvdmlkZSBhIHRyYW5zcGFyZW50IGNsaWVu dC9zZXJ2ZXIgcmVsYXRpb25zaGlwLi4ud2hpY2ggbWVhbnM6DQotICAgIGFsbCBjbGllbnQgYml0 cyB0cmVhdGVkIGVxdWFsbHkNCi0gICAgY2xpZW50IGJpdCBvcmRlcmluZyBwcmVzZXJ2ZWQNCi0g ICAgbm8gYXR0ZW1wdCB0byBpbmZlciBjbGllbnQgc3ltYm9sIChpZSBzZXF1ZW5jZSBvZiBjbGll bnQgYml0cykgbWVhbmluZyBhbmQgbm8gYXR0ZW1wdCB0byBjaGFuZ2UgY2xpZW50IHN5bWJvbHMN Ci0gICAgdGhlIHRyYWZmaWMgYmVoYXZpb3VyIG9mIGNsaWVudCBYIG11c3Qgbm90IGltcGFjdCB0 aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQgYnkgY2xpZW50IFkNCg0KQSBrZXkgY29yb2xsYXJ5 IG9mIHRoZSBhYm92ZSBpcyB0aGF0IE1QTFMtVFAgbXVzdCBvbmx5IHN1cHBvcnQgcHJvcGVyIGNv bm5lY3Rpb25zIChpZSBzaW5nbGUgc291cmNlIGNvbnN0cnVjdHMpDQoNCg0KMiAgIFNpbmNlIE1Q TFMtVFAgaXMgYSB0cmFuc3BvcnQgbmV0d29yayBpdCBpcyBub3QgYSB0b3Atb2Ytc3RhY2sgbmV0 d29yayAoaWUgaXQgZG9lcyBub3Qgc3VwcG9ydCBkaXJlY3RseSBleHRlcm5hbCBtZXNzYWdlL2Zp bGUvc3RyZWFtIGFwcGxpY2F0aW9ucykuICBNUExTLVRQIHRoZXJlZm9yZSBkb2VzIG5vdCByZXF1 aXJlIGFuIEUtTk5JIHNwZWNpZmljYXRpb24uICBBIGtleSBjb3JvbGxhcnkgb2YgdGhpcyBpcyB0 aGF0IE1QTFMtVFAgd2lsbCBub3QgaGF2ZSBhbnkgcGVlciBpbnRlcndvcmtpbmcgcmVsYXRpb25z aGlwIHdpdGggYW55IG90aGVyIG5ldHdvcmsgbW9kZS90ZWNobm9sb2d5Lg0KDQoNCk5vdyB3cnQg T0FNIE1QTFMtVFAgaXMgYSBjby1wcyBtb2RlIG5ldHdvcmsuICBZb3UgY291bGQgYXJndWUgdGhp cyBzaG91bGQgaGF2ZSBGREkvQUlTLi4uLmhvd2V2ZXIsIHRoZSBtZXJpdCBvZiB0aGlzIGlzIGhp Z2hseSBxdWVzdGlvbmFibGUuICBXaGVuIEkgYW5kIGNvbGxlYWd1ZXMgZGlzY3Vzc2VkIHdoZXRo ZXIgUEJCLVRFIChhbHNvIGEgY28tcHMgbW9kZSBuZXR3b3JrKSBzaG91bGQgaGF2ZSBGREkvQUlT IHdlIGNvbmNsdWRlZCB0aGF0IG9uIGJhbGFuY2UgaXQgd2FzIG5vdCBhIGdvb2QgaWRlYS4uLi4u YW5kIG5vdGUgdGhhdCBpbml0aWFsbHkgSSB3YXMgaW4gZmF2b3VyIG9mIGhhdmluZyBBSVMsIGJ1 dCBteSBjb2xsZWFndWVzIHByb3ZpZGVkIHN0cm9uZyB0ZWNobmljYWwgYXJndW1lbnRzIHRoYXQg Y29udmluY2VkIG1lIG90aGVyd2lzZS4NCg0KQUlTL0ZESSBpcyBoaXN0b3JpY2FsbHkgbGlua2Vk IHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXllciBuZXR3b3JrcyB0aGF0IHVzZWQgVFRM IGxvZ2ljLiAgV2hlbiB0aGlzIGRpZWQgaXQgcHV0IG91dCBhICs1ViAoYWxsIDFzKSBzaWduYWwg YnkgZGVmYXVsdCwgaWUgaXQgcmVxdWlyZWQgbm8gY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0 ZSBpdC4uLi4udGhpcyBpcyBrZXkgcG9pbnQuICBGdXJ0aGVyLCBpbiB0aGVzZSBuZXR3b3JrcyB0 aGVyZSBpcyBhIGZhaXJseSBzdGF0aWMvbG9uZy1ob2xkaW5nIGNsaWVudCBzZXJ2ZXIgcmVsYXRp b25zaGlwLiAgQ2xlYXJseSB0aGlzIGlzIG5vdCB0cnVlIGluIHRoZSBjbC1wcyBtb2RlIGFuZCBp dCdzIHdoeSBJRVRGIGhhdmUgbmV2ZXIgc3BlY2lmaWVkIEFJUyBmb3IgSVAgYW5kIGl0cyB3aHkg SUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2UgdG8gdGhyb3ctb3V0IEFJUyBpbiA4MDIuMWFnIGZvciBF dGhlcm5ldCAodGhvdWdoIElUVSBoYXZlIHVud2lzZWx5IElNTyByZXRhaW5lZCBpdCBpbiBZLjE3 MzEuLi4uYnV0IEkgc3VzcGVjdCBhbnkgb3BlcmF0b3IgcGxhbm5pbmcgdG8gdXNlIEV0aGVybmV0 IGVxdWlwbWVudCB3b3VsZCBhbHdheXMgbG9vayB0byBJRUVFIHN0ZHMgYW5kIG5vdCBJVFUgb25l cykuDQoNCkFJUy9GREkgYW5kIHRoZSBjby1wcyBtb2RlIGlzIGRlYmF0YWJsZS4gIEFzIEkgbm90 ZWQgYWJvdmUsIG9uIGJhbGFuY2Ugd2UgY29uc2lkZXJlZCBub3QgYSBnb29kIGlkZWEgZm9yIFBC Qi1URSBPQU0gYmVjYXVzZSBpdCByZXF1aXJlcyBhIGNvbnNjaW91cyBlZmZvcnQgdG8gZ2VuZXJh dGUgaXQgKHVubGlrZSB0aGUgY28tY3MgbW9kZSkgc28gdGhlcmUgYXJlIGxpa2VseSB0byBiZSBz Y2FsaW5nIHByb2JsZW1zIGFuZCBpdHMgb25lIG1vcmUgdGhpbmcgdG8gZ28gd3JvbmcuDQoNCllv dSBzaG91bGQgYWxzbyBoYXZlIHNlZW4gbWUgbWFrZSB0aGUgcG9pbnQgbWFueSB0aW1lcyBpbiB0 aGUgcGFzdCB0aGF0IHRoZSBhbHdheXMtb24gZGVmZWN0IGRldGVjdGlvbi9oYW5kbGluZyBPQU0g bmVlZHMgdG8gYmUgYXMgc2ltcGxlL3NwYXJzZSBhcyBwb3NzaWJsZSB3aXRoIGFzIGxpdHRsZSBj b25maWcgYXMgcG9zc2libGUgYmVjYXVzZSB3ZSBuZWVkIHN1cGVyIHJlbGlhYmlsaXR5Li4uLi4u VENNIGdvZXMgY29tcGxldGVseSBhZ2FpbnN0IHRoZSBncmFpbiBoZXJlLiAgQWxzbyBub3RlIHRo YXQgdGhlIE9BTSByZXF1aXJlZCBmb3IgZWFjaCBvZiB0aGUgMyBuZXR3b3JrIG1vZGVzIGlzIG5v dCB0aGUgc2FtZSwgZGVzcGl0ZSB3aGF0IHNvbWUgY2xhaW0uDQoNCnJlZ2FyZHMsIE5laWwNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogbXBscy10cC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg bGl1Lmd1b21hbkB6dGUuY29tLmNuDQpTZW50OiAyMSBBcHJpbCAyMDA5IDAyOjU5DQpUbzogQlJV TkdBUkQsIERFQk9SQUggQSwgQVRUTEFCUw0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJl cXVpcmVtZW50cw0KDQoNCkRlYm9yYWg6DQptYXliZSB3aGF0IHlvdSBzYWlkIGlzIHJpZ2h0LiBi dXQgSSBjYW4ndCBjb21wbGV0ZWx5IGFncmVlIHlvdXIgb3BpbmlvbnMuIElNTy4gbXBscy10cCBp cyByZWdhcmQgYXMgdHJhbnNwb3J0IG5ldHdvcmsgbGlrZSBTREgvU09ORVQuIHNvIGl0IHNob3Vs ZCBoYXZlIEFJUy9GREkgZnVjdGlvbnMgYXMgU0RIL1NPTkVULg0KDQpkbyB5b3UgdGhpbmsgc28u DQoNCmJlc3QgcmVnYXJkcw0KbGl1DQoNCiJCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTIiA8 ZGJydW5nYXJkQGF0dC5jb20+DQq3orz+yMs6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCg0K MjAwOS0wNC0yMCAyMzo0Nw0KDQrK1bz+yMsNCiJNYWFydGVuIFZpc3NlcnMiIDxtYWFydGVuLnZp c3NlcnNAaHVhd2VpLmNvbT4sIDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0Ks63LzQ0KbXBscy10 cEBpZXRmLm9yZw0K1vfM4g0KUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg dHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoNCg0KDQoNCg0KDQoNCg0KDQpJIGFncmVlIHdp dGggTmVpbCwgaXQgaXMgdmVyeSBxdWVzdGlvbmFibGUgdGhlIHZhbHVlIG9mIEFJUy9GREkgaW4g YQ0KcGFja2V0IG5ldHdvcmstIGFueSBtb2RlLiBJdCBjYW4gcmVzdWx0IGluIGEgRG9TIGF0dGFj ayBieSBhbiBvcGVyYXRvcg0Kb24gdGhlbXNlbHZlcyBzbyBldmVuIFkxNzMxIHJlY29tbWVuZHMg bm90IHRvIGJsb2NrIGRhdGEgZnJhbWVzOg0KIkEgTUVQIGNhbiBkZWNpZGUgd2hldGhlciBpdCBi bG9ja3MgZGF0YSBmcmFtZXMgd2hlbiBpdCBkZXRlY3RzIGRBSVMuDQpUaGUgcHJpbmNpcGxlIHJl cXVpcmVtZW50DQp0aGF0IGluZmx1ZW5jZXMgdGhpcyBkZWNpc2lvbiBpcyB0aGF0IGRhdGEgZnJh bWVzIG91Z2h0IHRvIGJlIGZvcndhcmRlZA0KYXMgbXVjaCBhcyBwb3NzaWJsZSwgd2l0aG91dA0K dGhlIHBvc3NpYmlsaXR5IG9mIGZvcndhcmRpbmcgd3JvbmcgZGF0YSBmcmFtZXMgZG93bnN0cmVh bS4iDQpUYWJsZSBJLjctMiBzaG93cyBmb3IgQUlTLCBub3QgdG8gYmxvY2suDQoNCkFuZCBhcyBZ MTczMSBzdGF0ZXMsIEFJUyBjYW4gb25seSBiZSB1c2VkIHVuZGVyIHZlcnkgY29uc3RyYWluZWQN CmFyY2hpdGVjdHVyZXMgLSBpZiByZXF1aXJlZCBmb3IgTVBMUy1UUCwgaXQgbmVlZHMgdG8gaGF2 ZSB0aGUgc2FtZQ0KZ3VpZGFuY2UgYXMgaW4gWTE3MzEsIGkuZS4gcG9pbnQtdG8tcG9pbnQgYW5k IHNlcnZlci9jbGllbnQgb25lLXRvLW9uZToNCiJmb3IgYSBwb2ludC10by1wb2ludCBFVEggY29u bmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSBzaW5nbGUgcGVlciBNRVAuDQpUaGVyZWZvcmUsIHRo ZXJlDQppcyBubyBhbWJpZ3VpdHkgcmVnYXJkaW5nIHRoZSBwZWVyIE1FUCBmb3Igd2hpY2ggaXQg c2hvdWxkIHN1cHByZXNzDQphbGFybXMgd2hlbiBpdCByZWNlaXZlcyB0aGUNCkVUSC1BSVMgaW5m b3JtYXRpb24uIg0KU28gc2hvdWxkIG9ubHkgYmUgd2l0aGluIG9uZSBkb21haW4gLSB0aGVuIG5v IG5lZWQuDQoNCkRlYm9yYWgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10g T24NCkJlaGFsZiBPZiBNYWFydGVuIFZpc3NlcnMNClNlbnQ6IE1vbmRheSwgQXByaWwgMjAsIDIw MDkgMTA6MDUgQU0NClRvOiBuZWlsLjIuaGFycmlzb25AYnQuY29tDQpDYzogbXBscy10cEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGgNCnJlcXVpcmVtZW50cw0KDQpOZWlsLA0KDQo+IGJ1dCBBSVMvRkRJIGluIHRo ZSBjbCBtb2RlPy4uLmRvIG1lIGEgZmF2b3VyIQ0KDQpFdGhlcm5ldCBBSVMgaXMgaW5kZWVkIGEg cmVxdWlyZW1lbnQgYW5kIGEgbmVjZXNzaXR5LiBBbmQgeW91IHdpbGwgbm90DQpiZQ0KYWJsZSB0 byB1bmRlcnN0YW5kIHRoYXQgYXMgbG9uZyBhcyB5b3UgcmVmdXNlIHRvIGFjY2VwdCB0aGF0ICJj bC1tb2RlIg0KaXMgYQ0KZm9yd2FyZGluZyBtb2RlIHdpdGhpbiBhICoqdHJhbnNwb3J0IGVudGl0 eSoqLiBHLjgwMCBhbWVuZG1lbnQgMSBoYXMNCmZpbmFsbHkNCnJlaW50cm9kdWNlZCB0aGlzIHRy YW5zcG9ydCBlbnRpdHkgaW50byBHLjgwMC4gQmVzaWRlcyB0aGF0LCBpdCBhbHNvDQppbnRyb2R1 Y2VkIHRoZSAqKmRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24qKjoNCg0KW0cuODAwIGFtMV0gIkEg ZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBpcyBhIHRyYW5zcG9ydCBlbnRpdHkgdGhhdA0KdHJh bnNmZXJzIGluZm9ybWF0aW9uIGJlbG9uZ2luZyB0byBtdWx0aXBsZSBjb21tdW5pY2F0aW9ucyBi ZXR3ZWVuIHBvcnRzDQphY3Jvc3MgYSBzdWJuZXR3b3JrLiA8Li4+IEluIGEgZGlmZmVyZW50aWF0 ZWQgY29ubmVjdGlvbiBtZXNzYWdlDQpjb250ZW50cw0KYXJlIGludGVycHJldGVkIHRvIGlkZW50 aWZ5IChzZXRzIG9mKSBjb21tdW5pY2F0aW9ucyB3aGljaCByZWNlaXZlDQpkaWZmZXJlbnQNCnRy ZWF0bWVudC4gIFRoZSBzZXRzIG9mIGNvbW11bmljYXRpb25zIG1heSBiZSBkaXN0aW5ndWlzaGVk IGJ5IHRoZQ0KZm9yd2FyZGluZyBpZGVudGlmaWVyIG9yIG90aGVyIGxheWVyIGluZm9ybWF0aW9u LiAgT3JkZXIgaXMgbm90DQpuZWNlc3NhcmlseQ0KcHJlc2VydmVkIGJldHdlZW4gbWVzc2FnZXMg YmVsb25naW5nIHRvIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgcmVjZWl2aW5nDQpkaWZmZXJlbnQg dHJlYXRtZW50LiAgU2V0cyBvZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgaWRlbnRpZmllZCBmb3IN CnB1cnBvc2VzDQpzdWNoIGFzIHRyYWZmaWMgY29uZGl0aW9uaW5nIG9yIHByZXNlcnZpbmcgY29t bXVuaWNhdGlvbiBtZXNzYWdlIG9yZGVyLiINCg0KDQpFdGhlcm5ldCBWTEFOcyBhcmUgaW4gdGVy bXMgb2YgRy44MDAgImRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb25zIi4NCkV0aGVybmV0DQpBSVMg cHJvdmlkZXMgQUlTIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc3VjaCAiZGlmZmVyZW50aWF0ZWQgY29u bmVjdGlvbiIuDQpJZg0KeW91IGFwcGx5IHRoaXMgdG8gbXkgcHJvcG9zZWQgUFROIGxheWVyIHN0 YWNrLCB0aGVuIHRoZSBFVkMgbGF5ZXINCnRvcG9sb2d5DQp3aWxsIGNvbnNpc3RzIG9mIEVWQyBs aW5rcyBzdXBwb3J0ZWQgYnkgTVBMUy1UUCwgRXRoZXJuZXQsIFBCQi1URSBhbmQNClAtT1RODQpW UCB0cmFpbHMgaW5zaWRlIG1ldHJvIGFuZCBjb3JlIGRvbWFpbnMgaW50ZXJjb25uZWN0aW5nIEVW QyBtYXRyaWNlcy4NCldoZW4NCm9uZSBvZiB0aG9zZSBFVkMgbGlua3MgaXMgaW50ZXJydXB0ZWQs IGUuZy4gaW4gdGhlIGNvcmUgYmV0d2VlbiBtZXRybyAxDQphbmQNCm1ldHJvIDQgKHNlZSBhdHRh Y2hlZCBzbGlkZSksIHRoZW4gdGhlIEVWQyBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uDQp0aGF0 IGlzDQpwcmVzZW50IG9uIHRoaXMgbGluayB3aWxsIGJlIGludGVycnVwdGVkLiBBdCB0aGUgRVZD IHN3aXRjaC9icmlkZ2Ugbm9kZQ0KaW4NCm1ldHJvIDQgdGhpcyBpbnRlcnJ1cHRpb24gaXMgbm90 aWNlZCBhbmQgRVZDLUFJUyBpcyBpbnNlcnRlZCBpbiB0aGUNCmRvd25zdHJlYW0gZGlyZWN0aW9u IHRvIHN1cHByZXNzIHRoZSBFVkMtTE9DIGFsYXJtcyBhdCBFVkMgZW5kcG9pbnRzIEQ0DQphbmQN CkQ1Lg0KDQpUaGUgRVZDLUFJUyAoaS5lLiBFdGhlcm5ldCBBSVMpIGZyYW1lIGhhcyBhIHJlc2Vy dmVkIG11bHRpY2FzdCBhZGRyZXNzLA0Kd2hpY2ggZ3VhcmFudGVlcyB0aGF0IHRoZSBBSVMgaXMg YnJvYWRjYXN0IHRvIHRoZSBlbmRwb2ludHMgb2YgdGhlIEVWQy4NCg0KSSBiZWxpZXZlIHRoYXQg aXQgaXMgdGltZSBmb3IgeW91IHRvIGFkYXB0IHlvdXIgdmlldyBvbiBjbyBhbmQgY2wgbW9kZXMN CmFuZA0KcmVsYXRlIGl0IHRvIHRoZSBmb3J3YXJkaW5nIG1vZGUgKipJTlNJREUqKiBhIHRyYW5z cG9ydCBlbnRpdHkuDQoNCldoYXQgd2Uga25vdyBhcyB0aGUgaW50ZXJuZXQgaXMgZXNzZW50aWFs bHkgYW4gIklQIGRpZmZlcmVudGlhdGVkDQpjb25uZWN0aW9uIiB3aXRoIGEgYmlsbGlvbiBvciBt b3JlIHBvcnRzLg0KV2hhdCB3ZSBrbm93IGFzIGFuIElQIFZQTiBpcyBlc3NlbnRpYWxseSBhbiAi SVAgZGlmZmVyZW50aWF0ZWQNCmNvbm5lY3Rpb24iDQp3aXRoIGUuZy4gbiBwb3J0cyAobiBpbiB0 aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEwMDApLg0KV2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0 IFZMQU4gaXMgZXNzZW50aWFsbHkgYW4gIkV0aGVybmV0DQpkaWZmZXJlbnRpYXRlZA0KY29ubmVj dGlvbiIgd2l0aCBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuDQpX aGF0IHdlIGtub3cgYXMgYSBwMnAgTVBMUyBFLUxTUCBpcyBlc3NlbnRpYWxseSBhbiAiTVBMUyBk aWZmZXJlbnRpYXRlZA0KY29ubmVjdGlvbiIgd2l0aCAyIHBvcnRzLg0KV2hhdCB3ZSBrbm93IGFz IGEgcDJwIFNESCBWQy1uIGlzIGEgIlNESCBWQy1uIGNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy4N Cg0KVHJhbnNwb3J0IG5ldHdvcmsgT0FNIGFwcGxpZXMgdG8gdHJhbnNwb3J0IGVudGl0aWVzLCB3 aGljaCBhcmUgKGluIHRlcm1zDQpvZg0KRy44MDAgYW0xKSBjb25uZWN0aW9ucyBhbmQgZGlmZmVy ZW50aWF0ZWQgY29ubmVjdGlvbnMuDQoNClJlZ2FyZHMsDQpNYWFydGVuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZWlsLjIuaGFycmlzb25AYnQuY29tIFttYWlsdG86bmVp bC4yLmhhcnJpc29uQGJ0LmNvbV0NClNlbnQ6IHZyaWpkYWcgMTcgYXByaWwgMjAwOSAyMjowMA0K VG86IEpvaG4uRS5EcmFrZTJAYm9laW5nLmNvbTsgSXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5p dDsNCkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBtYWFydGVuLnZpc3NlcnNAaHVh d2VpLmNvbQ0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQpyZXF1aXJlbWVudHMNCg0KSm9o biwgIFRoYW5rcyB0aGlzIGlzIGEgZ3JlYXQgcGxhdGZvcm0gdG8gZXhwbGFpbiB3aHkgT0FNIGZv ciB0aGUgMw0KbmV0d29yaw0KbW9kZXMgbmVlZHMgdG8gYmUgZGlmZmVyZW50LiAgSSBhbSBnZXR0 aW5nIGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xrcw0KdHJ5aW5nDQp0byBtYWtlIGFsbCAzIG5ldHdv cmsgbW9kZXMgbG9vayBhbGlrZSAoYW5kIHRoZW4sIGV2ZW4gd29yc2UsIGludGVyd29yaw0KdGhl bQ0KYXMgYXMgcGVlcnMuLi5lc3Agd2hlbiBub3Qgbm90IHRvcC1vZi1zdGFjaw0KbmV0d29ya3Mu Li5JIG1lYW4gaG93IHNpbGx5IGNhbiB3ZSBnZXQ/KS4gICBJIGFtIGV2ZW4gbW9yZSBmcnVzdHJh dGVkIGJ5DQp0aGUgZmFjdCB0aG9zZSBwZWRkbGluZyB0aGlzIEZVRCBvbmx5IGV2ZXIgc2VlbSB0 byBjb25zaWRlciBPQU0gYW5kDQpmb3JnZXQNCmFsbCBvdGhlciBEUC9DUC9NUCBjb21wb25lbnRz IChlc3AgdG9wLW9mLXN0YWNrIG1lc3NhZ2UvZmlsZS9zdHJlYW0NCmFwcGxpY2F0aW9uIGFkYXB0 YXRpb25zKS4gIEhvdyB3cm9uZyBjYW4gdGhpcyBnZXQhDQoNCkluIHRoZSBjbyBtb2RlcyBhICpj b25uZWN0aW9uKiBpcyBhIHZlcnkgc3BlY2lmaWMgYW5kICpjb25zdHJhaW5pbmcqDQpjb25zdHJ1 Y3QuLi4uLkkgYW0gYXNzdW1pbmcgaGVyZSB3ZSByZXNwZWN0IHRoZSBydWxlcyBvZiBhIGNvbm5l Y3Rpb24NCihpZQ0Kc2luZ2xlIHNvdXJjZSkgdGhvdWdoIHNvbWUgZm9sa3MgZG9uJ3QgZXZlbiBi b3RoZXIgdG8gcmVzcGVjdCB0aGlzLCBhbmQNCnRoaXMNCmlzIGRlc3BpdGUgdGhlIGZhY3QgdGhh dCB3ZSBhbGwga25vdyB3aGF0IHByb2JsZW1zIG11bHRpcGxlLXNvdXJjZQ0KY29uc3RydWN0cyBj YW4gY2F1c2UgKGZyb20gTERQL1BIUC4uLi5lcmdvIE1QTFMtVFApLg0KDQpXaGVuIHdlIGhhdmUg YSBjb25uZWN0aW9uIHRoaXMgcmVzdHJpY3RzICphbGwqIERQIChpZSB0cmFmZmljIGFuZCBPQU0p DQp0bw0Kc3RheSB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgY29ubmVjdGlvbi4gIFdoaWNoIGlz IGZpbmUgdW5kZXINCmRlZmVjdC1mcmVlDQpjb25kaXRpb25zLCBidXQgaWYgd2UgaGF2ZSBsZWFr aW5nIHRyYWZmaWMgdGhlbiB0aGUgY29uc3RyYWluaW5nIG5hdHVyZQ0Kb2YNCnRoZSBjb25uZWN0 aW9uIGNvbnN0cnVjdCBpcyBicm9rZW4uICBJbiBhIG51dHNoZWxsIHdoYXQgdGhpcyBtZWFucyBp cw0KdGhhdA0KT0FNIHRoYXQgaXMgb2YgYSByZXF1ZXN0L3Jlc3BvbnNlIG5hdHVyZSBjYW5ub3Qg YmUgdHJ1c3RlZCBpbiBjbyBtb2RlDQpuZXR3b3JrcyB1bmRlciBtaXNjb25uZWN0aXZpdHkgZGVm ZWN0cy4uLi4uaW5kZWVkLCB3aHkgc2hvdWxkIGEgbGVha2luZw0KRFANCmhhdmUgYSBzeW1tZXRy aWMgZ28vcmV0dXJuIGRlZmVjdCBiZWhhdmlvdXI/Li4uLnZlcnkgbGlrZWx5IGl0IHdvbid0Lg0K U28NCndoaWxzdCByZXF1ZXN0L3Jlc3BvbnNlIE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1vZGUg aXQgaXMgbm90IHJpZ2h0IGZvcg0KdGhlDQpjbyBtb2RlIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBk ZWZlY3QgY29uZGl0aW9ucy4NCg0KTW9yZSBnZW5lcmFsbHkgdGhlIDMgbW9kZXMgYXJlIGRpZmZl cmVudCBhbmQgbm90IGp1c3QgaW4gT0FNDQpyZXF1aXJlbWVudHMuLi4uYnV0IEFJUy9GREkgaW4g dGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZvdXIhLi4uYXQgbGVhc3QNCklFRUUgaGFkIHRoZSBn b29kIHNlbnNlIHRvIGJpbiB0aGlzIGZvciBFdGhlcm5ldCBldmVuIHRob3VnaCBpdCByZW1haW5z DQppbg0KWS4xNzMxLiAgQW5kIHdoaWNoIGlzIHdoeSBJIG9mdGVuIHRyb3Qtb3V0IHRoZSByYXRo ZXIgc2lsbHkgKHRvIGhhdmUgdG8NCnNheQ0KdGhpcykgb2JzZXJ2YXRpb24gdGhhdCBpZiBJUCAo Y2wgbW9kZSkgY291bGQgZG8gaXQgYWxsIHRoZW4gd2h5IGhhdmUNCklFVEYNCmZvdW5kIGl0IG5l Y2Vzc2FyeSB0byBjcmVhdGUgTVBMUyAoY28tcHMpIGFuZCBHTVBMUyAoQ1AgZm9yIGNvLWNzKS4g IFRoZQ0KYW5zd2VyIGxpZXMgaW4gdGhlIHBoeXNpY3MuLi5hbmQgRy44MDAgYXR0ZW1wdHMgdG8g ZXhwbGFpbiB0aGF0DQpwaHlzaWNzLi4uLkcuODA1IGRvZXMgbm90Lg0KDQpTbywgdGhlIDMgbW9k ZXMgYXJlIGRpZmZlcmVudC4uLnBsZWFzZSBhY2NlcHQvcmVqb2ljZSBpbiB0aGlzIGZhY3QgYXMN CnRoZXkNCmFsbCBvZmZlciBzb21ldGhpbmcgZGlmZmVyZW50L2ltcG9ydGFudC4gIEJ1dCBkbyBu b3QgYmUgaG9vZHdpbmtlZCBieQ0KdGhvc2UNCndobyBwZWRkbGUgYSBzdG9yeSB0aGF0IHRoYXQg dHJpZXMgdG8gbWFrZSB0aGUgT0FNIG9mIHRoZSAzIG1vZGVzIHRoZQ0Kc2FtZS4NCg0KcmVnYXJk cywgTmVpbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZw0KPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIERyYWtlLCBKb2huIEUNCj4gU2VudDogMTcgQXByaWwgMjAwOSAyMDowMg0KPiBU bzogQlVTSSBJVEFMTzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KPiBD YzogbXBscy10cEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aA0KPiByZXF1aXJlbWVudHMNCj4NCj4gSXRhbG8s DQo+DQo+IEFzIGRlc2NyaWJlZCBpbiB0aGUgTVBMUyBUUCBPQU0gUmVxdWlyZW1lbnRzIEktRCwg dmlydHVhbGx5IGFsbCBvZiB0aGUNCg0KPiBPQU0gZnVuY3Rpb25zIHJlcXVpcmUgYSByZXR1cm4g cGF0aCwgYW5kIGluIHRoZSBhYnNlbmNlIG9mIGEgcmV0dXJuDQo+IHBhdGggdGhleSBhcmUgZGlz YWJsZWQuDQo+DQo+IEFzIGRlc2NyaWJlZCBpbiBEYXZpZCBTaW5pY3JvcGUncyBtZWV0aW5nIG1p bnV0ZXMNCj4gKGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL21pc2MvbXBscy1pbnRlcm9wL2F0 dGFjaG1lbnQvd2lraS8NCj4gbWVldGluZy1ubw0KPiB0ZXMvMjAwODEwMTUubXBscy1pbnRlcm9w LWR0LW5vdGVzLnppcCksIGlmIElQIGFkZHJlc3NpbmcgaXMgdXNlZCwgYW4NCj4gTVBMUyBUUCBu ZXR3b3JrIG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgZ2V0dGluZyBJUCBwYWNrZXRzIGZyb20NCj4g ZGVzdGluYXRpb24gdG8gc291cmNlOyBuZWl0aGVyIHRoZSBtaW51dGVzIG5vciBJIHN0aXB1bGF0 ZSB0aGF0IGENCj4gY29udHJvbCBwbGFuZSBuZWVkcyB0byBiZSB1c2VkIHRvIGluc3RhbnRpYXRl IHRoaXMgZm9yd2FyZGluZy4NCj4NCj4gQXMgYW4gYXNpZGUsIHRoZSBpc3N1ZSBvZiByZXR1cm4g cGF0aCBmb3IgdW5pZGlyZWN0aW9uYWwgTFNQcyBjb3VsZCBiZQ0KDQo+IGNoYXJhdGVyaXplZCBh cyB0aGUgZWxlcGhhbnQgaW4gdGhlIHJvb20uICBJbiB0aGUgTVBMUyBUUCBPQU0NCj4gRnJhbWV3 b3JrIEktRCwgdW5pY2FzdCBMU1BzIGFyZSBvbmx5IG1lbnRpb25lZCB0aHJlZSB0aW1lcyBhbmQg cmV0dXJuDQo+IHBhdGhzIG5vdCBhdCBhbGwuDQo+DQo+IFRoYW5rcywNCj4NCj4gSm9obg0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQlVTSSBJVEFMTyBbbWFpbHRv Okl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXRdDQo+ID4gU2VudDogRnJpZGF5LCBBcHJpbCAx NywgMjAwOSAxOjU5IEFNDQo+ID4gVG86IERyYWtlLCBKb2huIEU7IEFsZXhhbmRlciBWYWluc2h0 ZWluOyBNYWFydGVuIFZpc3NlcnMNCj4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+IFN1Ympl Y3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo DQo+ID4gcmVxdWlyZW1lbnRzDQo+ID4NCj4gPiBKb2huLA0KPiA+DQo+ID4gSSBtaWdodCBoYXZl IG1pc3NlZCB0aGUgYWdyZWVtZW50IG9mIE1QTFMtVFAgYmVpbmcgY2FwYWJsZSBvZg0KPiA+IHNl bmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQ cy4NCj4gPg0KPiA+IFRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3QgYmVsb25nIHRvIHRoZSBmaXJz dCBzZXQgb2YgcmVxdWlyZW1lbnRzDQo+ID4gSVRVLVQgaXMgZXhwZWN0aW5nIHRvIGJlIG1ldCBi eSBPY3RvYmVyLg0KPiA+DQo+ID4gSG93ZXZlciwgSSB0aGluayB0aGlzIGluIGEgcG90ZW50aWFs IGludGVyZXN0aW5nIGFkZGl0aW9uYWwNCj4gPiByZXF1aXJlbWVudCB0byBiZSB0YWtlbiBpbnRv IGFjY291bnQgKGF0IHdvcnN0IGluIGENCj4gc3Vic2VxdWVudCBwaGFzZSkuDQo+ID4NCj4gPiBJ IHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVudCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVyc3Vz IG90aGVyDQo+ID4gbW9yZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJp bGl0eSB0byB3b3JrIHcvbyBJUA0KPiA+IGZvcndhcmRpbmcgYW5kIHRoZSBuZWVkIGZvciBPQU0g dG8gY29udGludWUgdG8gbW9uaXRvciB0aGUgZGF0YQ0KPiA+IHBsYW5lIGFsc28gaW4gY2FzZSBv ZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wgb3IgbWFuYWdlbWVudA0KPiA+IHBsYW5l KS4NCj4gPg0KPiA+IEkgYW0gb3BlbiB0byBkaXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlz IHRoZSByaWdodCB0aW1lIGJlY2F1c2UNCj4gPiBJIHdpc2ggdG8gYXZvaWQgZGVsYXlpbmcgdGhl IGZpcnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24gc29sdXRpb24uDQo+ID4NCj4gPiBUaGFua3MsIEl0 YWxvDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4gRQ0KPiA+ID4gU2VudDogVGh1cnNkYXks IEFwcmlsIDE2LCAyMDA5IDg6MDAgUE0NCj4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsg TWFhcnRlbiBWaXNzZXJzDQo+ID4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gU3ViamVj dDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgN Cj4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4NCj4gPiA+IEF0IHRoZSBtZWV0aW5nIGxhc3QgZmFs bCBhdCBKdW5pcGVyIGluIE1hc3NhY2h1c2V0dHMsIEkNCj4gPiB0aGluayBpdCB3YXMNCj4gPiA+ IGFncmVlZCB0aGF0IGFuIE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBoYXZlIGEgZm9yd2FyZGlu Zw0KPiA+IGNhcGFiaWxpdHkNCj4gPiA+IGZvciBtYW5hZ2VtZW50LCBjb250cm9sLCBhbmQgT0FN IHBhY2tldHMgKGUuZy4sIHNlbmRpbmcNCj4gPiByZXBsaWVzIHRvIE9BTQ0KPiA+ID4gcmVxdWVz dHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQcykgZXZlbiBpZiBpdCBkb2VzIG5vdA0KPiA+ IGhhdmUgYW4gSVANCj4gPiA+IGZvcndhcmRpbmcgZGF0YSBwbGFuZS4NCj4gPiA+DQo+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IEFsZXhhbmRlciBWYWlu c2h0ZWluDQo+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0K PiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgOTo1NyBBTQ0KPiA+ID4gPiBU bzogTWFhcnRlbiBWaXNzZXJzDQo+ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+ID4gPiA+ IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCBwYXRoDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPg0KPiA+ID4gPiBNYWFydGVuLA0K PiA+ID4gPiBJdCBzZWVtcyB0aGF0IHlvdSd2ZSBqdXN0IChpbXBsaWNpdGx5IGFuZCwgcHJvYmFi bHksDQo+ID4gPiA+IGluYWR2ZXJ0ZW50bHkpIHN0YXRlZCB0aGUgZm9sbG93aW5nOg0KPiA+ID4g Pg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgIE1QTFMtVFAgT0FNIHdpbGwgbm90IGV2ZXIgc3Vw cG9ydCBNSVAgbG9vcGJhY2sgZnVuY3Rpb24NCj4gPiAoYW5kIGZhdWx0DQo+ID4gPiA+IGxvY2Fs aXphdGlvbiB3aGljaCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uICkgZm9yDQo+ID4gdW5pZGlyZWN0 aW9uYWwgUDJNUA0KPiA+ID4gPiBhbmQgUDJQIHBhdGhzLg0KPiA+ID4gPg0KPiA+ID4gPiBJZiB0 aGlzIHN0YXRlbWVudCBpcyBjb3JyZWN0LCB0aGlzIChJTUhPIGFuZCBGV0lXKQ0KPiByYWlzZXMg YSB2YWxpZA0KPiA+ID4gPiBxdWVzdGlvbjoNCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAg ICAgICBJcyBNUExTLVRQIGFuIGFwcHJvcHJpYXRlIHNvbHV0aW9uIGZvciB0aGVzZQ0KPiB0eXBl cyBvZiB0cmFuc3BvcnQNCj4gPiA+ID4gcGF0aHM/DQo+ID4gPiA+DQo+ID4gPiA+IEZvciB0aGUg cmVmZXJlbmNlLCBJUC9NUExTIHByb3ZpZGVzIHRoaXMga2luZCBvZg0KPiA+IGZ1bmN0aW9uYWxp dHkgdG9kYXkNCj4gPiA+ID4gZm9yICh1bmlkaXJlY3Rpb25hbCAtIGJ1dCBpdCBkb2VzIG5vdCBr bm93IGFueSBvdGhlcg0KPiA+IHR5cGUpIFAyUCBMU1BzDQo+ID4gPiA+IGFzIGRlc2NyaWJlZCBp biBSRkMgNDM3OS4gQW5kIGl0cyBleHRlbnNpb24gdG8gUDJNUCBMU1BzIHNlZW1zDQo+ID4gPiA+ IGVhc3kuLi4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkcywNCj4g PiA+ID4NCj4gPiA+ID4gICAgICBTYXNoYQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEZy b206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0K PiA+IE9uIEJlaGFsZg0KPiA+ID4gPiBPZiBNYWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vy c0BodWF3ZWkuY29tXQ0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzoy NCBQTQ0KPiA+ID4gPiBUbzogJ0FkcmlhbiBGYXJyZWwnDQo+ID4gPiA+IENjOiBtcGxzLXRwQGll dGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPg0KPiA+ ID4gPiBBZHJpYW4sDQo+ID4gPiA+DQo+ID4gPiA+ID4+IDxxdW90ZT4NCj4gPiA+ID4gPj4gICAg ICBUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQNCj4gPiA+ ID4gb3RoZXIgaW50ZXJuYWwNCj4gPiA+ID4gPj4gICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJp YXRlKSBvZiBhIGNvLXJvdXRlZA0KPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KPiA+ ID4gPiA+PiAgICAgICBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0 aGUgcGFpcmluZw0KPiA+ID4gPiA+PiAgICAgICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQg YW5kIHRoZSBiYWNrd2FyZA0KPiA+ID4gPiBkaXJlY3Rpb25zIG9mIHRoYXQNCj4gPiA+ID4gPj4g ICAgICAgdHJhbnNwb3J0IHBhdGguDQo+ID4gPiA+ID4+IDxlbmQgcXVvdGU+DQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1l bnQuIFRoYXQNCj4gPiA+IGlzLCB0aGVyZSBpcw0KPiA+ID4gPiA+ICpub3RoaW5nKiB0aGF0IGNh biBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mDQo+ID4gPiB2aWV3IHRoYXQN Cj4gPiA+ID4gPiByZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC4NCj4g PiA+ID4NCj4gPiA+ID4gWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBjb3JyZWN0LiBJdCBpcyB2 ZXJ5IG11Y2gNCj4gb2JzZXJ2YWJsZSBpZg0KPiA+ID4gPiB0aGlzIHJlcXVpcmVtZW50IGlzIG1l dCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZpZXcuDQo+ID4gPiA+IFRoZSBNSVAgZnVuY3Rp b25zIGNhbiBvbmx5IHBlcmZvcm0gdGhlIExvb3BiYWNrIHdoZW4gdGhlcmUgaXMgYQ0KPiA+ID4g PiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4gVGhlIE1QTFMtVFAgTEJN IHBhY2tldA0KPiA+ID4gPiByZWNlaXZlZCBhdCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5lZCAo YXMgTEJSDQo+ID4gPiA+IHBhY2tldCkgdG8gdGhlIG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2 aWEgdGhlIG90aGVyDQo+ID4gZGlyZWN0aW9uIG9mDQo+ID4gPiA+IHRoZSBjby1yb3V0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4gVGhpcyBvdGhlcg0KPiBkaXJlY3Rpb24NCj4gPiA+ ID4gd291bGQgbm90IGJlIGF2YWlsYWJsZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg dHJhbnNwb3J0DQo+ID4gPiA+IHBhdGguLi4gYW5kIHRodXMgdGhlIGxvb3BiYWNrIHRlc3QNCj4g PiA+IHdvdWxkIGZhaWwuDQo+ID4gPiA+DQo+ID4gPiA+IFNpbWlsYXJseSwgd2hlbiB3ZSBoYXZl IHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1vbml0b3IgYQ0KPiA+IHNlZ21lbnQsIHRoZW4NCj4gPiA+ ID4gdGhpcyBpcyBwb3NzaWJsZSBpbiBhIGNvLXJvdXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aA0K PiBidXQgbm90IGluIGENCj4gPiA+ID4gYXNzb2NpYXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aC4g SW4gdGhlIGZpcnN0IGNhc2UgdGhlIFRDTSBNRVANCj4gPiA+ID4gU291cmNlIGFuZCBTaW5rIGZ1 bmN0aW9ucyBhcmUgY28tbG9jYXRlZCBhbmQgY2FuDQo+IGV4Y2hhbmdlIHdoYXQgaXMNCj4gPiA+ ID4gY2FsbGVkICJyZW1vdGUgaW5mb3JtYXRpb24iIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgcGVy Zm9ybWFuY2UNCj4gPiA+ID4gbW9uaXRvcmluZy4NCj4gPiA+ID4gSW4gdGhlIGxhdHRlciBjYXNl IHRoZSBUQ00gTUVQIFNvdXJjZSBhbmQgU2luayBmdW5jdGlvbnMNCj4gPiBhcmUgaW4gZS5nLg0K PiA+ID4gPiBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgYW5kIFRDTSB3b3VsZCBub3Qg YmUgYWJsZQ0KPiA+IHRvIHByb3ZpZGUNCj4gPiA+ID4gcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4N Cj4gPiA+ID4NCj4gPiA+ID4gPiBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAi KGluY2x1ZGluZyBNRVBzLA0KPiA+ID4gTUlQcyBhbmQgb3RoZXINCj4gPiA+ID4gaW50ZXJuYWwN Cj4gPiA+ID4gPiBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4g SXQgZG9lcyBub3QNCj4gPiA+ID4gYWRkIHRvICJUaGUNCj4gPiA+ID4gPiBpbnRlcm1lZGlhdGUg bm9kZXMuIg0KPiA+ID4gPg0KPiA+ID4gPiBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJl Y3QuIFRoaXMgdGV4dCBtdXN0IG5vdCBiZQ0KPiA+IGRlbGV0ZWQgYXQNCj4gPiA+ID4gYWxsLg0K PiA+ID4gPg0KPiA+ID4gPiA+IEFjdHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlz IHBlcnNpc3RlbnQNCj4gPiA+IGluc2lzdGVuY2Ugb24gdGhlDQo+ID4gPiA+IGluY2x1c2lvbg0K PiA+ID4gPiA+IG9mICJUYW5kZW0gQ29ubmVjdGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbiB0 aGUgSVRVLVQgb2YNCj4gPiA+ID4gdGhpcyB0ZXJtDQo+ID4gPiA+ID4gaXMNCj4gPiA+ID4gcG9v cmx5DQo+ID4gPiA+ID4gc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZSBtb25pdG9yaW5nIG9m IGEgcGF0aCB0aGF0IGlzDQo+ID4gPiA+IHBhcmFsbGVsIChpLmUuDQo+ID4gPiA+IHRhbmRlbSkN Cj4gPiA+ID4gPiB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0 aW9uIG9mIFRDDQo+ID4gPiA+IHNlZW1zIHRvIGJlIGF0DQo+ID4gPiA+IHZhcmlhbmNlLA0KPiA+ ID4gPiA+IGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KPiA+ ID4gPg0KPiA+ID4gPiBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRhdGlv biBvZiB0YW5kZW0NCj4gPiBjb25uZWN0aW9uIGlzDQo+ID4gPiA+IGRlc2NyaWJlZCBpbiBJVFUt VCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gImZyb20gdGhlDQo+ID4gbW9uaXRvcmluZyBvZiBhDQo+ ID4gPiA+IHBhdGggdGhhdCBpcyBwYXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBh dGggYmVpbmcNCj4gPiA+ID4gbW9uaXRvcmVkLiI/DQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlIGlz IGEgIm5ldHdvcmsgY29ubmVjdGlvbiIgYW5kIHRoaXMgbmV0d29yaw0KPiA+IGNvbm5lY3Rpb24g aXMgYSBzZXQNCj4gPiA+ID4gb2YgaW50ZXJjb25uZWN0ZWQgImxpbmsgY29ubmVjdGlvbnMiIGFu ZCAibWF0cml4DQo+IGNvbm5lY3Rpb25zIi4gQQ0KPiA+ID4gPiBzdWJzZXQgb2YgdGhvc2UgaW50 ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQgbWF0cml4DQo+ID4gPiA+IGNvbm5lY3Rp b25zIGNhbiBiZSBtb25pdG9yZWQgYW5kIGlzIHRoZW4gcmVmZXJyZWQgdG8gYXMNCj4gYSAidGFu ZGVtDQo+ID4gPiA+IGNvbm5lY3Rpb24iLiBUaGVyZSBpcyBubyAicGF0aCB0aGF0IGlzIHBhcmFs bGVsIHRvIHRoZQ0KPiA+IGRhdGEgcGF0aCIuDQo+ID4gPiA+IFRoZXJlIGlzIG9ubHkgYWRkaXRp b25hbCBPQU0gaW5zZXJ0ZWQgaW5zaWRlIHRoZSBkYXRhDQo+IHBhdGggYnkgdGhlDQo+ID4gPiA+ IFRDTSBNRVBfU28gZnVuY3Rpb24gYW5kIHRoaXMgT0FNIGlzIGV4dHJhY3RlZCBmcm9tIHRoZQ0K PiA+IGRhdGEgcGF0aCBieQ0KPiA+ID4gPiB0aGUgVENNIE1FUF9TayBmdW5jdGlvbi4NCj4gPiA+ ID4NCj4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4gTWFhcnRlbg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBtcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+ID4gW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQo+ID4gPiA+IFNlbnQ6IGRvbmRlcmRhZyAx NiBhcHJpbCAyMDA5IDExOjU5DQo+ID4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgYmVu amFtaW4ubml2ZW4tamVua2luc0BidC5jb20NCj4gPiA+ID4gQ2M6IEJVU0kgSVRBTE87IG1wbHMt dHBAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCj4gPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+ DQo+ID4gPiA+IEhpIFNhc2hhLA0KPiA+ID4gPg0KPiA+ID4gPiA+IFVuZm9ydHVuYXRlbHkgSSBj YW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudDoNCj4gPiA+ID4gPg0KPiA+ID4g PiA+IDxxdW90ZT4NCj4gPiA+ID4gPiAgICAgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJk d2FyZSwgY28tcm91dGVkDQo+ID4gPiBiaWRpcmVjdGlvbmFsIExTUHMNCj4gPiA+ID4gPiAgICAg YXJlIGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KPiA+ ID4gPiA+IDxlbmQgcXVvdGU+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGlzIHN0YXRlbWVudCB3 b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZSBpdCBub3QgZm9yDQo+ID4gPiA+IFJlcXVp cmVtZW50DQo+ID4gPiA+ID4gMzQgaW4gdGhlIGxhdGVzdCBNUExTLVRQIHJlcXVpcmVtZW50cyBk cmFmdA0KPiA+ID4gPg0KPiA+ID4gPiBPSy4gR290IGl0Lg0KPiA+ID4gPg0KPiA+ID4gPiBCdXQg d2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cyBzZWN0aW9u Pw0KPiA+ID4gPg0KPiA+ID4gPiBJbiBmYWN0LCB3aGF0IGlzIHRoaXMgcmVxdWlyZW1lbnQgYWN0 dWFsbHkgc2F5aW5nPw0KPiA+ID4gPg0KPiA+ID4gPiA+IDxxdW90ZT4NCj4gPiA+ID4gPiAgICAg IFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZyBNRVBzLCBNSVBzIGFuZA0KPiA+ID4g b3RoZXIgaW50ZXJuYWwNCj4gPiA+ID4gPiAgICAgICBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUp IG9mIGEgY28tcm91dGVkDQo+ID4gPiA+IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ID4gPiA+ ID4gICAgICAgcGF0aCBhdCBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBh aXJpbmcNCj4gPiA+ID4gPiAgICAgICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRo ZSBiYWNrd2FyZA0KPiA+ID4gPiBkaXJlY3Rpb25zIG9mIHRoYXQNCj4gPiA+ID4gPiAgICAgICB0 cmFuc3BvcnQgcGF0aC4NCj4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KPiA+ID4gPg0KPiA+ID4gPiBU aGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCj4g PiBpcywgdGhlcmUgaXMNCj4gPiA+ID4gKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZy b20gYSBibGFjayBib3ggcG9pbnQgb2YNCj4gPiB2aWV3IHRoYXQNCj4gPiA+ID4gcmVzdWx0cyBm cm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJl Zm9yZSBpdCBjb3VsZCBiZSBhc3N1bWVkIHRoYXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgYnkN Cj4gPiA+ID4gY29uZmlndXJpbmcgc29tZSBkYXRhIHBsYW5lIGRhdGFiYXNlIGNvbXBvbmVudCB0 aHJvdWdoIHRoZQ0KPiA+ID4gPiBtYW5hZ2VtZW50IHBsYW5lLiBUaGUgZGF0YWJhc2UgY29tcG9u ZW50IGlzIG5vdCB1c2VkDQo+IGZvciBhbnl0aGluZw0KPiA+ID4gPiBleGNlcHQgdG8gc2F0aXNm eSB0aGlzIHJlcXVpcmVtZW50IGZvciAiYXdhcmVuZXNzIi4NCj4gPiA+ID4NCj4gPiA+ID4gQmVu ISBDYW4gd2UgcGxlYXNlIHRyeSB0byByZXdyaXRlIHRoaXMgcmVxdWlyZW1lbnQgaW4gdGVybXMg b2YNCj4gPiA+ID4gYmVoYXZpb3I/DQo+ID4gPiA+DQo+ID4gPiA+ID4gUGxlYXNlIG5vdGUgdGhh dCBSZXF1aXJlbWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZQ0KPiA+ID4gPiBsaXN0IHRo YXQgaXMNCj4gPiA+ID4gPiBzcGVjaWZpYyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQ cy4gKFRoZSBwYWlyaW5nDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiA+IGF0IGVuZCBw b2ludHMgZm9yIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQo+ID4gPiBw YXRocyBhcmUNCj4gPiA+ID4gPiBleGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhleSBhcHBlYXIg aW4gdHdvIGRpZmZlcmVudA0KPiA+ID4gaXRlbXMgaW4gdGhlDQo+ID4gPiA+ID4gcmVxdWlyZW1l bnRzJyBsaXN0KS4NCj4gPiA+ID4gPiBJbiBvdGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVu dCAzNCB0aGUgbm90aW9uIG9mDQo+IGNvLXJvdXRlZA0KPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwg cGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50Lg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQg KCJvdGhlciBpbnRlcm5hbA0KPiA+ID4gPiA+IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSIpIGNy ZWF0ZXMgYSBzdXNwaWNpb24gdGhhdCBIVw0KPiA+ID4gPiBzdXBwb3J0IG9mIHRoZQ0KPiA+ID4g PiA+IHBhaXJpbmcgYXdhcmVuZXNzIG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkg d2l0aCBpdC4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVk IHRleHQgIihpbmNsdWRpbmcgTUVQcywNCj4gPiBNSVBzIGFuZCBvdGhlcg0KPiA+ID4gPiBpbnRl cm5hbCBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4gSXQNCj4g PiBkb2VzIG5vdA0KPiA+ID4gPiBhZGQgdG8gIlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KPiA+ ID4gPg0KPiA+ID4gPiA+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQgaW5jcmVhc2Vz IHRoaXMgc3VzcGljaW9uOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPHF1b3RlPg0KPiA+ID4gPiA+ ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW4NCj4gPiBhcmJp dHJhcnkgcGFydCBvZiBhDQo+ID4gPiA+ID4gICB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBt b25pdG9yZWQgKHZpYSBPQU0pDQo+ID4gPiA+IGluZGVwZW5kZW50bHkgZnJvbSB0aGUNCj4gPiA+ ID4gPiAgIGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FNKS4gIEl0IG1heSBiZSBhIG1vbml0b3Jl ZA0KPiA+IHNlZ21lbnQgb3IgYQ0KPiA+ID4gPiA+ICAgbW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBz ZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguDQo+ID4gVGhlIHRhbmRlbQ0KPiA+ID4gPiA+ICAg Y29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVuZ2luZShzKSBvZg0K PiA+ID4gPiB0aGUgbm9kZShzKQ0KPiA+ID4gPiA+ICAgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNl Z21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21lbnQuDQo+ID4gPiA+ID4gPGVuZCBxdW90ZT4NCj4g PiA+ID4NCj4gPiA+ID4gQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVy c2lzdGVudA0KPiA+IGluc2lzdGVuY2Ugb24gdGhlDQo+ID4gPiA+IGluY2x1c2lvbiBvZiAiVGFu ZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3aXRoaW4NCj4gPiB0aGUgSVRVLVQgb2YN Cj4gPiA+ID4gdGhpcyB0ZXJtIGlzIHBvb3JseSBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhl DQo+IG1vbml0b3Jpbmcgb2YgYQ0KPiA+ID4gPiBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4g dGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nDQo+ID4gPiA+IG1vbml0b3JlZC4gVGhpcyBk ZWZpbml0aW9uIG9mIFRDIHNlZW1zIHRvIGJlIGF0IHZhcmlhbmNlLA0KPiA+IGFuZCB3b3VsZA0K PiA+ID4gPiBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KPiA+ID4gPg0KPiA+ ID4gPiA+IERvZXNuJ3QgImZvcndhcmRpbmcgZW5naW5lIiBzb3VuZCBsaWtlIGhhcmR3YXJlIHRv IHlvdT8NCj4gPiA+ID4NCj4gPiA+ID4gWWVzLCBidXQgc28gd2hhdD8NCj4gPiA+ID4NCj4gPiA+ ID4gPiBJTUhPIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IG5laXRoZXIgdGhlIE1QTFMtVFANCj4g PiA+IFJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ID4gPiA+IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVx dWlyZW1lbnRzIG9uZQ0KPiA+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPg0KPiA+DQo+IChodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVp cmVtZW4NCj4gPiA+ID4gPiB0cy0wMS50eHQpIGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFs aW5nIHdpdGggdGFuZGVtDQo+ID4gPiBjb25uZWN0aW9ucy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IEJ1dCB0YW5kZW0gY29ubmVjdGlvbnMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgTVBMUy1UUCBPQU0N Cj4gPiBGcmFtZXdvcmsNCj4gPiA+ID4gPiBkcmFmdA0KPiA+ID4gPiAoaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcg0KPiA+ID4gPiBh bWV3b3JrLTAwLnR4dA0KPiA+ID4gPiApLg0KPiA+ID4gPg0KPiA+ID4gPiBSaWdodC4NCj4gPiA+ ID4gTGV0J3MganVzdCBnZXQgcmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nIGFs bA0KPiB0aGUgSS1Ecw0KPiA+ID4gPiBpbnRvIGxpbmUuDQo+ID4gPiA+DQo+ID4gPiA+ID4gVGhl IGJvdHRvbSBsaW5lLCBJTUhPLCBpcyB0aGF0IHNvbWUgY2xhcml0eSByZWdhcmRpbmcNCj4gPiA+ IGNvLXJvdXRlZCB2cy4NCj4gPiA+ID4gPiBhc3NvY2lhdGVkDQo+ID4gPiA+ID4gYmlkaXJlY3Rp b25hbCBwYXRocyBpcyBzdGlsbCByZXF1aXJlZC4gT25lIHdheSB0byBwcm92aWRlDQo+ID4gPiA+ IHRoYXQgY291bGQNCj4gPiA+ID4gPiBiZSBieSBleHBsaWNpdGx5IGxpbWl0aW5nIFJlcXVpcmVt ZW50IDM0IHRvIHNwZWNpZmljDQo+ID4gPiBmdW5jdGlvbmFsaXR5Lg0KPiA+ID4gPg0KPiA+ID4g PiBBZ3JlZWQuDQo+ID4gPiA+DQo+ID4gPiA+IEFkcmlhbg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gPiA+IEZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtd DQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTQ0KPiA+ID4g PiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IExvdSBCZXJnZXI7IEJVU0kgSVRBTE8NCj4gPiA+ ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCj4gPiA+ID4gcmVxdWlyZW1l bnRzDQo+ID4gPiA+DQo+ID4gPiA+IEhpIFNhc2hhLA0KPiA+ID4gPg0KPiA+ID4gPiBOb3QgcmVh bGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1dC4uLg0K PiA+ID4gPg0KPiA+ID4gPiA+IDEuIE15IHJlYWRpbmcgb2YgIG9uZSBvZiBCZW4ncyAgbWVzc2Fn ZXMgaXMgdGhhdCBhc3NvY2lhdGVkDQo+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUg dGhlIG9ubHkgdHlwZXMgb2YgcGF0aHMgdGhhdCBjYW4gYmUNCj4gPiA+ID4gY3JlYXRlZCBpbg0K PiA+ID4gPiA+IHRoZSBleGlzdGluZyBuZXR3b3JrczsgInRydWUiIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIHBhdGhzDQo+ID4gPiA+IHdpbGwgaGF2ZQ0KPiA+ID4gPiA+IHRvIHdhaXQgdW50aWwg KGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lcyBhdmFpbGFibGUuDQo+ID4gPiA+DQo+ID4g PiA+IFRoaXMgaXMgY2xlYXJseSBub25zZW5zZSENCj4gPiA+ID4gRnJvbSB0aGUgcG9pbnQgb2Yg dmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkDQo+ID4gYmlkaXJlY3Rpb25hbCBMU1BzIGFyZQ0K PiA+ID4gPiBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4N Cj4gPiA+ID4NCj4gPiA+ID4gSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExT UHMgKGUuZy4gdXNpbmcgdGhlDQo+ID4gbWFuYWdlbWVudA0KPiA+ID4gPiBwbGFuZSkgeW91IGNh biBzdXJlbHkgc2V0IHVwIGEgY28tcm91dGVkDQo+ID4gPiBiaWRpcmVjdGlvbmFsIExTUC4NCj4g PiA+ID4NCj4gPiA+ID4gVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUg Y28tcm91dGVkDQo+IGJpZGlyZWN0aW9uYWwNCj4gPiA+ID4gTFNQcyB1c2luZyB0aGUgY29udHJv bCBwbGFuZS4gVGhlc2UgZWl0aGVyIHVzZSB0aGUgR01QTFMNCj4gPiAod2hpY2ggaXMNCj4gPiA+ ID4gY2xlYW5lcikgb3Igbm9uLXN0YW5kYXJkIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2gg aXMNCj4gPiBtZXNzeSBidXQNCj4gPiA+ID4gZnVuY3Rpb25hbCkuDQo+ID4gPiA+DQo+ID4gPiA+ IEJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBsYW5lDQo+ ID4gc29sdXRpb25zIGhhdmUNCj4gPiA+ID4gbm90aGluZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0 eSBvZiBlcXVpcG1lbnQgYXMgdGhleQ0KPiBhcmUgc29mdHdhcmUNCj4gPiA+ID4gc29sdXRpb25z Lg0KPiA+ID4gPg0KPiA+ID4gPiA+IDIuIE15IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwncyBtZXNz YWdlcyBpcyB0aGF0IHRoZSBhY3R1YWwNCj4gPiA+ID4gZHJpdmVyIGZvcg0KPiA+ID4gPiA+IGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3Rp bmcNCj4gPiA+ID4gPiB0cmFuc3BvcnQgbmV0d29ya3MgcmF0aGVyIHRoYW4gYW55IHNwZWNpZmlj IGJlbmVmaXQuDQo+ID4gPiA+DQo+ID4gPiA+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUg b2YgdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPw0KPiA+ID4gPiBXaGljaCBpcyBub3QgdG8gc2F5 IGl0IGlzIGEgYmFkIHRoaW5nLg0KPiA+ID4gPg0KPiA+ID4gPiBBIGxhcmdlIGRyaXZlciBmb3Ig TVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNrZXQgbmV0d29yaw0KPiA+IHRoZSBsb29rLA0KPiA+ ID4gPiBmZWVsLCBhbmQgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSAibGVnYWN5Ig0K PiA+ID4gPiB0cmFuc3BvcnQgbmV0d29yay4NCj4gPiA+ID4NCj4gPiA+ID4gPiBCYXNlZCBvbiB0 aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVzcyAoRldJVykgdGhhdDoNCj4gPiA+ID4gPiAqIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUsIGF0IGxlYXN0IGZvciB0aGUgdGltZQ0K PiA+ID4gPiA+ICAgIGJlaW5nLCB0aGUgbW9zdCBpbXBvcnRhbnQgdHlwZSBvZiBiaWRpcmVjdGlv bmFsIHBhdGhzIGluDQo+ID4gPiA+ID4gICAgTVBMUy1UUA0KPiA+ID4gPg0KPiA+ID4gPiBJIHRo aW5rIHRoYXQgaXMgd3JvbmcgYm90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZA0KPiA+ IGdpdmVuIHRoYXQNCj4gPiA+ID4gb3RoZXIgdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBzb2x1 dGlvbnMgd2lsbCBiZQ0KPiBuZWVkZWQgdG8gcmVhY2gNCj4gPiA+ID4gdGhlIGZ1bGwgZnVuY3Rp b24gbGV2ZWwgb2YgTVBMUy1UUC4NCj4gPiA+ID4NCj4gPiA+ID4gPiAqIHRoZXkgaGFkIGEgZ29v ZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUgb2YNCj4gPiBiaWRpcmVjdGlvbmFsDQo+ ID4gPiA+ID4gICBwYXRocyBpbiAgcmVhbCBkZXBsb3ltZW50cy4NCj4gPiA+ID4NCj4gPiA+ID4g SSBkb24ndCBzZWUgd2hhdCB0aGF0IGZvbGxvd3MgZnJvbS4NCj4gPiA+ID4NCj4gPiA+ID4gQ2hl ZXJzLA0KPiA+ID4gPiBBZHJpYW4NCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gbXBscy10cCBtYWlsaW5nIGxp c3QNCj4gPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gbXBscy10cCBtYWls aW5nIGxpc3QNCj4gPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBt cGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ID4gPg0KPiA+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAg bWFpbGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4N Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg0K --_000_A3C5DF08D38B6049839A6F553B331C76A8CF16E022ILPTMAIL02eci_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Andy, I=20 cannot agree more. Indeed, in the TDM world you had to fill the cli= ent bit=20 stream with something predictable AND distinguishable from valid client=20 traffic. In the=20 packet world, loss of server connectivity means that the client applic= ation=20 does not receive any packets, so there is nothing to misinterpret = as=20 client traffic. Hence=20 no need to "fill in" AIS/FDI. Regards,     Sasha From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: Wednesday, April 22, 2009 1:14=20 PM To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc:<= /B>=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectiona= l=20 transport path requirements Liu, Allow me to jump in. You are bringing together t= wo things=20 which are separate and for which AIS/FDI is no help. Maintenance operatio= ns=20 are concerned with two separate things. 1) Identifying faults in equipment, line p= lant, and=20 other systems (eg misconfigurations) and fixing them (equipment=20 maintenance). 2) Identifying the health of end to end=20 connections, especially when they are directly supporting customer servic= es=20 (service maintenance). The problem is *not* about a lack of alarm suppr= ession in=20 the data plane - that information is readily available. If, at an end=20 equipment, I have a good server/section layer and a loss of CC at the cli= ent=20 layer, I *know* the fault is elsewhere - I don't need AIS/FDI to tell me.= =20 (Indeed, if you think about, if the fault is in the end equipment, it is = quite=20 likely that the fault means it cannot report the traffic loss to the=20 management system!) The issue arises because the two sides of mainte= nance=20 want different things. The fault fixing guys want to locate the fault and= =20 don't want any other information. The service maintenance guys want to kn= ow=20 whether their customer service is working. This arose in the early days of SONET/SDH, when = the=20 operations guys demanded that the equipment did *not* suppress the traffi= c=20 alarm even when AIS was being received as the service guys want to know a= bout=20 the alarms. The normal practice is for the equipment to report the a= larms=20 *including* AIS and then a filter is applied in the management system&nbs= p;to=20 suppress alarms to the fault fixing guys. As I'm aware, there are many=20 different techniques applied for the filtering algorithms, especially whe= n you=20 consider multiple concurrent faults in a network, however, the existance = of=20 AIS/FDI doesn't add anything to these that's not already known. In fact, = I=20 believe simple time-stamp correlation is one of the most powerful an= d=20 widely used techniques. And if the equipment starts messing up the report= ing=20 of loss of CC because it waiting for/persistence checking AIS/FDI, i= t=20 could end up messing up simple time-stamp=20 correlation! In practice, it is often not quite a simple as t= his, as=20 the service guys like to be able to 'localise' the fault. However, under = most=20 circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter hasn't wor= ked=20 for some reason. = ; But the bottom line is, whatever operations proc= ess you=20 want to use, AIS/FDI doesn't add anything other than complexity and = fault=20 liability to the equipment. Remember AIS goes back to the TDM world = where=20 you *have to fill the bit stream with something*. Andy Andy= =20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    =20 Office: +44 (0)1277=20 322038 M= obile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 Newgate = Street=20 London EC1A 7AJ Registered in England no. 1800000 This electronic = message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the use= of=20 the individual(s) or entity named above. If you are not the intended reci= pient=20 be aware that any disclosure, copying, distribution or use of the content= s of=20 this information is prohibited. If you have received this electronic mess= age=20 in error, please notify us by telephone or email (to the numbers or addre= ss=20 above) immediately. Activit= y and use of=20 the British Telecommunications plc email system is monitored to secure it= s=20 effective operation and for other lawful business purposes. Communication= s=20 using this system will also be monitored and may be recorded to secure=20 effective operation and for other lawful business purposes.= From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To:= =20 Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject:= Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Neil: thank you for wasting more time in de= scribling=20 the problems. but I think some of what you said is no relations with ou= r=20 problem.for me, maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. b= ut=20 for CO-PS networks.if there is no AIS/FDI functions, when there is a de= fects=20 in a given layer network, it can cause multiple alarm events to be rais= ed.=20 it is diffcult for operators to locate and diagnose the faults.=20 though I completely agree yo= u on=20 adding new things and functions will bring some complexity . but = if we=20 have no functions, it is more complex and difcult for operators to main= tence=20 and administrator the network. so I think every new functions and thing= s may=20 have positive and negative effects. but we should consider it very much= ,=20 don't delete some functions at random. best regards liu <neil.2.harrison@bt.com> 2009-04-21 20:30 =CA=D5= =BC=FE=C8=CB <liu.guoman@zte.com.c= n>,=20 <dbrungard@att.com>=20 =B3=AD= =CB=CD <mpls-tp@ietf.org>= =20 =D6=F7= =CC=E2 RE: [mpls-tp] Associated= =20 bidirectional transport path=20 requirements <= BR> Liu, If=20 MPLS-TP is going to be taken seriously as a transport network (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are these. = 1=20 Provide a transparent client/server relationship...which=20 means: - =20 all client bits treated equally - client bit ordering preserved=20 - &nbs= p;no=20 attempt to infer client symbol (ie sequence of client bits) meaning and= no=20 attempt to change client symbols A=20 key corollary of the above is that MPLS-TP must only support proper=20 connections (ie single source constructs) 2 Since MPLS-TP = is a=20 transport network it is not a top-of-stack network (ie it does not supp= ort=20 directly external message/file/stream applications). MPLS-TP ther= efore=20 does not require an E-NNI specification. A key corollary of this = is=20 that MPLS-TP will not have any peer interworking relationship with any = other=20 network mode/technology. Now=20 wrt OAM MPLS-TP is a co-ps mode network. You could argue this sho= uld=20 have FDI/AIS....however, the merit of this is highly questionable.=20 When I and colleagues discussed whether PBB-TE (also a co-ps mode= =20 network) should have FDI/AIS we concluded that on balance it was not a = good=20 idea.....and note that initially I was in favour of having AIS, but my= =20 colleagues provided strong technical arguments that convinced me=20 otherwise. AIS/FDI is historically= linked to=20 the early PDH co-cs mode layer networks that used TTL logic. When= this=20 died it put out a +5V (all 1s) signal by default, ie it required no=20 conscious effort to generate it.....this is key point. Further, i= n=20 these networks there is a fairly static/long-holding client server=20 relationship. Clearly this is not true in the cl-ps mode and it's= why=20 IETF have never specified AIS for IP and its why IEEE had the good sens= e to=20 throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO ret= ained=20 it in Y.1731....but I suspect any operator planning to use Ethernet=20 equipment would always look to IEEE stds and not ITU ones). = AIS/FDI and the co-ps mode is debatable. As I noted abov= e, on=20 balance we considered not a good idea for PBB-TE OAM because it require= s a=20 conscious effort to generate it (unlike the co-cs mode) so there are li= kely=20 to be scaling problems and its one more thing to go wrong. <= FONT=20 size=3D3> You=20 should also have seen me make the point many times in the past that the= =20 always-on defect detection/handling OAM needs to be as simple/sparse as= =20 possible with as little config as possible because we need super=20 reliability......TCM goes completely against the grain here. Also= note=20 that the OAM required for each of the 3 network modes is not the same,= =20 despite what some claim. regards, Neil From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To:= =20 BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectio= nal=20 transport path requirements Deborah:<= /FONT> maybe what you sa= id is=20 right. but I can't completely agree your opinions. IMO. mpls-tp is rega= rd as=20 transport network like SDH/SONET. so it should have AIS/FDI fuctions as= =20 SDH/SONET. do you think so. best regards liu "BRUNGARD, DE= BORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org 2009-04-20 23:47=20 =CA=D5= =BC=FE=C8=CB "Maarten V= issers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> =B3=AD= =CB=CD mpls-tp@ietf.org<= FONT=20 size=3D3> =D6=F7= =CC=E2 Re: [mpls-tp] Associated= =20 bidirectional transport path=20 requirements <= BR> I agree with Neil, it is= very=20 questionable the value of AIS/FDI in a packet network- any mode. It = can=20 result in a DoS attack by an operator on themselves so even Y1731=20 recommends not to block data frames: "A MEP can decide whether it bl= ocks=20 data frames when it detects dAIS. The principle requirement that= =20 influences this decision is that data frames ought to be forwarded a= s=20 much as possible, without the possibility of forwarding wrong data f= rames=20 downstream." Table I.7-2 shows for AIS, not to block. And as = Y1731=20 states, AIS can only be used under very constrained architectures - = if=20 required for MPLS-TP, it needs to have the same guidance as in Y1731= ,=20 i.e. point-to-point and server/client one-to-one: "for a point-to-po= int=20 ETH connection, a MEP has only a single peer MEP. Therefore, thereis=20 no ambiguity regarding the peer MEP for which it should suppress ala= rms=20 when it receives the ETH-AIS information." So should only be with= in=20 one domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Se= nt:=20 Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional=20 transport path requirements Neil, > but AIS/FDI in = the=20 cl mode?...do me a favour! Ethernet AIS is indeed a requirement = and a=20 necessity. And you will not be able to understand that as long as= you=20 refuse to accept that "cl-mode" is a forwarding mode within a=20 **transport entity**. G.800 amendment 1 has finally reintroduced = this=20 transport entity into G.800. Besides that, it also introduced the=20 **differentiated connection**: [G.800 am1] "A differentiated=20 connection is a transport entity that transfers information belongin= g to=20 multiple communications between ports across a subnetwork. <..>= ; In=20 a differentiated connection message contents are interpreted to=20 identify (sets of) communications which receive different treatme= nt.=20 The sets of communications may be distinguished by the forward= ing=20 identifier or other layer information. Order is=20 not necessarily preserved between messages belonging to sets of=20 communications receiving different treatment. Sets of=20 communications may be identified for purposes such as traffic=20 conditioning or preserving communication message order." Eth= ernet=20 VLANs are in terms of G.800 "differentiated connections". EthernetAIS=20 provides AIS within the scope of such "differentiated=20 connection". If you apply this to my proposed PTN layer stack, th= en=20 the EVC layer topology will consists of EVC links supported by=20 MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and co= re=20 domains interconnecting EVC matrices. When one of those EVC links= is=20 interrupted, e.g. in the core between metro 1 and metro 4 (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC switch/bridg= e=20 node in metro 4 this interruption is noticed and EVC-AIS is inser= ted=20 in the downstream direction to suppress the EVC-LOC alarms at EVC=20 endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame= has=20 a reserved multicast address, which guarantees that the AIS is broad= cast=20 to the endpoints of the EVC. I believe that it is time for you t= o=20 adapt your view on co and cl modes and relate it to the forwardin= g=20 mode **INSIDE** a transport entity. What we know as the interne= t is=20 essentially an "IP differentiated connection" with a billion or more= =20 ports. What we know as an IP VPN is essentially an "IP=20 differentiated connection" with e.g. n ports (n in the range of e= .g. 2=20 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in the range= of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an = "MPLS=20 differentiated connection" with 2 ports. What we know as a p2p SD= H=20 VC-n is a "SDH VC-n connection" with 2 ports. Transport network = OAM=20 applies to transport entities, which are (in terms of G.800 am1)= =20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt= .com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com;= =20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpl= s-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting a wee b= it=20 tired of folks trying to make all 3 network modes look alike (and= =20 then, even worse, interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I am e= ven=20 more frustrated by the fact those peddling this FUD only ever seem t= o=20 consider OAM and forget all other DP/CP/MP components (esp=20 top-of-stack message/file/stream application adaptations). How= =20 wrong can this get! In the co modes a *connection* is a very=20 specific and *constraining* construct.....I am assuming here we resp= ect=20 the rules of a connection (ie single source) though some folks do= n't=20 even bother to respect this, and this is despite the fact that we= all=20 know what problems multiple-source constructs can cause (from=20 LDP/PHP....ergo MPLS-TP). When we have a connection this restric= ts=20 *all* DP (ie traffic and OAM) to stay within the bounds of the=20 connection. Which is fine under defect-free conditions, but= if=20 we have leaking traffic then the constraining nature of the conne= ction=20 construct is broken. In a nutshell what this means is that = OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity defects.....indeed, why should a= =20 leaking DP have a symmetric go/return defect behaviour?....very l= ikely=20 it won't. So whilst request/response OAM is right for the cl mode= it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and not jus= t in=20 OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...= at=20 least IEEE had the good sense to bin this for Ethernet even though i= t=20 remains in Y.1731. And which is why I often trot-out the ra= ther=20 silly (to have to say this) observation that if IP (cl mode) coul= d do=20 it all then why have IETF found it necessary to create MPLS (co-p= s)=20 and GMPLS (CP for co-cs). The answer lies in the physics...and= =20 G.800 attempts to explain that physics....G.805 does not. So,= the=20 3 modes are different...please accept/rejoice in this fact as theyall=20 offer something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the OAM of th= e 3=20 modes the same. regards, Neil > -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Se= nt:=20 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maart= en=20 Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > requirements >=20 > Italo, > > As described in the MPLS TP OAM=20 Requirements I-D, virtually all of the > OAM functions requir= e a=20 return path, and in the absence of a return > path they are=20 disabled. > > As described in David Sinicrope's meeting mi= nutes=20 >=20 (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >= =20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addre= ssing=20 is used, an > MPLS TP network needs to be capable of getting IP= =20 packets from > destination to source; neither the minutes nor I= =20 stipulate that a > control plane needs to be used to instantiate= this=20 forwarding. > > As an aside, the issue of return path for= =20 unidirectional LSPs could be > charaterized as the elephant i= n the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs are= only=20 mentioned three times and return > paths not at all. > >=20 Thanks, > > John > > -----Original=20 Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April = 17,=20 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maar= ten=20 Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE:=20 [mpls-tp] Associated bidirectional transport path > >=20 requirements > > > > John, > > > >= ; I=20 might have missed the agreement of MPLS-TP being capable of > &g= t;=20 sending replies to OAM requests sent on uni-directional LSPs. > &= gt;=20 > > This requirement does not belong to the first set of=20 requirements > > ITU-T is expecting to be met by October. = >=20 > > > However, I think this in a potential interesting=20 additional > > requirement to be taken into account (at worst= in=20 a > subsequent phase). > > > > I think that th= is=20 requirement needs to be evaluated versus other > > more impor= tant=20 requirements (e.g. the possibility to work w/o IP > > forward= ing=20 and the need for OAM to continue to monitor the data > > plan= e=20 also in case of failures affecting the control or management > &= gt;=20 plane). > > > > I am open to discuss it but not sure= this=20 is the right time because > > I wish to avoid delaying the fi= rst=20 phase of the design solution. > > > > Thanks,=20 Italo > > > > > -----Original Message----- >= ;=20 > > From: mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > &g= t;=20 > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexa= nder=20 Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org &= gt;=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport pat= h=20 > > > requirements > > > > > > At= the=20 meeting last fall at Juniper in Massachusetts, I > > think it= =20 was > > > agreed that an MPLS TP network needs to have a=20 forwarding > > capability > > > for management,=20 control, and OAM packets (e.g., sending > > replies to OAM = >=20 > > requests sent on uni-directional LSPs) even if it does not>=20 > have an IP > > > forwarding data plane. > > &= gt;=20 > > > > -----Original Message----- > > > &g= t;=20 From: Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent:= =20 Thursday, April 16, 2009 9:57 AM > > > > To: Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > > &= gt;=20 Subject: Re: [mpls-tp] Associated bidirectional transport path >= >=20 > > requirements > > > > > > > >=20 Maarten, > > > > It seems that you've just (implicitly a= nd,=20 probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will not ev= er=20 support MIP loopback function > > (and fault > > >= >=20 localization which requires this function ) for > > unidirecti= onal=20 P2MP > > > > and P2P paths. > > > > &= gt;=20 > > > If this statement is correct, this (IMHO and FWIW) &g= t;=20 raises a valid > > > > question: > > > >= =20 > > > > = ;=20 Is MPLS-TP an appropriate solution for these > types= of=20 transport > > > > paths? > > > > >= >=20 > > For the reference, IP/MPLS provides this kind of > >= =20 functionality today > > > > for (unidirectional - but it= does=20 not know any other > > type) P2P LSPs > > > > a= s=20 described in RFC 4379. And its extension to P2MP LSPs seems > &g= t;=20 > > easy... > > > > > > > >=20 > > > > > > > > Regards, > = >=20 > > > > > > Sasha > >= ;=20 > > > > > > > > > > > >= >=20 > ________________________________________ > > > > Fr= om:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: Thursday, Apr= il=20 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > >= ;=20 > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpl= s-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Adrian, = >=20 > > > > > > > >> <quote> > &= gt;=20 > > >> The intermediate nodes (includin= g=20 MEPs, MIPs and > > > > other internal > > > = >=20 >> functions as appropriate) of a=20 co-routed > > > > bidirectional transport > > &= gt;=20 > >> path at each (sub-)layer MUST be awa= re of=20 the pairing > > > > >> =20 relationship of the forward and the backward > > > >=20 directions of that > > > > >> = =20 transport path. > > > > >> <end quote> &g= t;=20 > > > > > > > > > There is no way this is= a=20 functional requirement. That > > > is, there is > >= ;=20 > > > *nothing* that can be observed from a black box point=20 of > > > view that > > > > > results from= =20 adhering to this requirement. > > > > > > >= >=20 Your understanding is not correct. It is very much > observable=20 if > > > > this requirement is met from a black box poin= t of=20 view. > > > > The MIP functions can only perform the Loo= pback=20 when there is a > > > > co-routed bidirectional transpo= rt=20 path. The MPLS-TP LBM packet > > > > received at a MIP = needs=20 to be returned (as LBR > > > > packet) to the originatin= g MEP=20 function via the other > > direction of > > > >= the=20 co-routed bidirectional transport path. This other > direction>=20 > > > would not be available in an associated bidirectional=20 transport > > > > path... and thus the loopback test>=20 > > would fail. > > > > > > > >=20 Similarly, when we have to apply TCM MEPs to monitor a > > seg= ment,=20 then > > > > this is possible in a co-routed bidir trans= port=20 path > but not in a > > > > associated bidir trans= port=20 path. In the first case the TCM MEP > > > > Source and = Sink=20 functions are co-located and can > exchange what is > > = >=20 > called "remote information" which is necessary for performance >=20 > > > monitoring. > > > > In the latter case th= e TCM=20 MEP Source and Sink functions > > are in e.g. > > &g= t;=20 > different nodes in the network and TCM would not be able > &= gt;=20 to provide > > > > performance monitoring. > > = >=20 > > > > > > The entirety of the bracketted text=20 "(including MEPs, > > > MIPs and other > > > &g= t;=20 internal > > > > > functions as appropriate)" should = be=20 deleted. It does not > > > > add to "The > > &g= t;=20 > > intermediate nodes." > > > > > > >= ;=20 > Your understanding is not correct. This text must not be > &= gt;=20 deleted at > > > > all. > > > > > = >=20 > > > Actually, I am quite fed up about this persistent >= ;=20 > > insistence on the > > > > inclusion > &g= t;=20 > > > of "Tandem Connection." The definition within the ITU-T= =20 of > > > > this term > > > > > is &= gt;=20 > > > poorly > > > > > specified and comes f= rom=20 the monitoring of a path that is > > > > parallel=20 (i.e. > > > > tandem) > > > > > to the= data=20 path being monitored. This definition of TC > > > > seem= s to=20 be at > > > > variance, > > > > > and = would=20 be if the ACH was actually in band. > > > > > >= ;=20 > > I don't understand where your interpretation of tandem >= ;=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of a > &g= t;=20 > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > > > &g= t;=20 > > There is a "network connection" and this network > >= =20 connection is a set > > > > of interconnected "link=20 connections" and "matrix > connections". A > > > >= =20 subset of those interconnected link connections and matrix > >= ;=20 > > connections can be monitored and is then referred to as &g= t; a=20 "tandem > > > > connection". There is no "path that is=20 parallel to the > > data path". > > > > There = is=20 only additional OAM inserted inside the data > path by the >= ;=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM MEP_Sk=20 function. > > > > > > > > Regards, &g= t;=20 > > > Maarten > > > > > > > >=20 > > > > -----Original Message----- > > > &g= t;=20 From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > &g= t;=20 > > Sent: donderdag 16 april 2009 11:59 > > > > To= :=20 Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > &= gt;=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > > &g= t;=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > Unfortunatel= y I=20 cannot fully agree with your statement: > > > > > = >=20 > > > > <quote> > > > > > &n= bsp;=20 From the point of view of hardware, co-routed > > >=20 bidirectional LSPs > > > > > are a spec= ial=20 case of associated bidirectional LSPs. > > > > > <= end=20 quote> > > > > > > > > > > This= =20 statement would be obviously correct, were it not for > > >= >=20 Requirement > > > > > 34 in the latest MPLS-TP=20 requirements draft > > > > > > > > OK. G= ot=20 it. > > > > > > > > But what is this doi= ng in=20 the data plane requirements section? > > > > > &g= t;=20 > > In fact, what is this requirement actually saying? > &g= t;=20 > > > > > > > <quote> > > > = >=20 > The intermediate nodes (including MEPs, MIPs=20 and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > > >= ;=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > &g= t;=20 > > > relationship of the forward and the= =20 backward > > > > directions of that > > > &g= t;=20 > transport path. > > > > >=20 <end quote> > > > > > > > > There = is no=20 way this is a functional requirement. That > > is, there is>=20 > > > *nothing* that can be observed from a black box point=20 of > > view that > > > > results from adhering = to=20 this requirement. > > > > > > > > Theref= ore=20 it could be assumed that this requirement is met by > > > = >=20 configuring some data plane database component through the > >= ;=20 > > management plane. The database component is not used > = for=20 anything > > > > except to satisfy this requirement for= =20 "awareness". > > > > > > > > Ben! Can we= =20 please try to rewrite this requirement in terms of > > > &= gt;=20 behavior? > > > > > > > > > Please no= te=20 that Requirement 34 is the ONLY item in the > > > > list= that=20 is > > > > > specific for co-routed bidirectional LSP= s.=20 (The pairing > > > > requirements > > > >= >=20 at end points for co-routed and associated bidirectional > > &= gt;=20 paths are > > > > > exactly the same even if they app= ear=20 in two different > > > items in the > > > > = >=20 requirements' list). > > > > > In other words, withou= t=20 Requirement 34 the notion of > co-routed > > > > &= gt;=20 bidirectional paths would be void of any data plane content. > &g= t;=20 > > > > > > > > The somewhat vague scope of = this=20 requirement ("other internal > > > > > functions as= =20 appropriate") creates a suspicion that HW > > > > suppor= t of=20 the > > > > > pairing awareness may be required in or= der=20 to comply with it. > > > > > > > > The=20 entirety of the bracketted text "(including MEPs, > > MIPs and= =20 other > > > > internal functions as appropriate)" should= be=20 deleted. It > > does not > > > > add to "The=20 intermediate nodes." > > > > > > > > >= ; The=20 following text in the draft increases this suspicion: > > >= >=20 > > > > > > <quote> > > > > &= gt;=20 Tandem Connection: A tandem connection is an > > arbitr= ary=20 part of a > > > > > transport path that can be= =20 monitored (via OAM) > > > > independently from the &g= t;=20 > > > > end-to-end monitoring (OAM). It may be= a=20 monitored > > segment or a > > > > > = =20 monitored concatenated segment of a transport path. > >= The=20 tandem > > > > > connection may also include t= he=20 forwarding engine(s) of > > > > the node(s) > >= >=20 > > at the edge(s) of the segment or concatenated=20 segment. > > > > > <end quote> > > >= ;=20 > > > > > Actually, I am quite fed up about this=20 persistent > > insistence on the > > > > inclus= ion=20 of "Tandem Connection." The definition within > > the ITU-T=20 of > > > > this term is poorly specified and comes from= =20 the > monitoring of a > > > > path that is paralle= l=20 (i.e. tandem) to the data path being > > > > monitored.= This=20 definition of TC seems to be at variance, > > and would >= ;=20 > > > be if the ACH was actually in band. > > > &g= t;=20 > > > > > Doesn't "forwarding engine" sound like har= dware=20 to you? > > > > > > > > Yes, but so=20 what? > > > > > > > > > IMHO it is wo= rth=20 noting that neither the MPLS-TP > > > Requirements draft>=20 > > > > nor the MPLS-TP OAM requirements one > > &= gt;=20 > > > > > > > > > > > = >=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen<= BR>>=20 > > > > ts-01.txt) contain any requirements dealing with=20 tandem > > > connections. > > > > > &g= t;=20 > > > > But tandem connections are discussed in the MPLS-TP= =20 OAM > > Framework > > > > > draft > &g= t;=20 > >=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > = >=20 > > amework-00.txt > > > > ). > > > &g= t;=20 > > > > Right. > > > > Let's just get ri= d of=20 an unnecessary term and bring all > the I-Ds > > > &g= t;=20 into line. > > > > > > > > > The bott= om=20 line, IMHO, is that some clarity regarding > > > co-routed= =20 vs. > > > > > associated > > > > >= =20 bidirectional paths is still required. One way to provide > > = >=20 > that could > > > > > be by explicitly limiting=20 Requirement 34 to specific > > > functionality. > >= ;=20 > > > > > > Agreed. > > > > &g= t;=20 > > > Adrian > > > > > > > >=20 > > > > > > > > > > > >= =20 ________________________________________ > > > > From: A= drian=20 Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, Apr= il=20 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou= =20 Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > = >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport pat= h=20 > > > > requirements > > > > > &g= t;=20 > > Hi Sasha, > > > > > > > > Not= =20 really sure whether you are misrepresenting anyone, but... > >= >=20 > > > > > > 1. My reading of one of Ben's=20 messages is that associated > > > > > bidirect= ional=20 paths are the only types of paths that can be > > > > cr= eated=20 in > > > > > the existing networks; "true" co-routed= =20 bidirectional paths > > > > will have > > > = >=20 > to wait until (if ever) new equipment becomes available. > &= gt;=20 > > > > > > This is clearly nonsense! > >= ;=20 > > From the point of view of hardware, co-routed > >=20 bidirectional LSPs are > > > > a special case of associa= ted=20 bidirectional LSPs. > > > > > > > > If y= ou=20 can set up two unidirectional LSPs (e.g. using the > >=20 management > > > > plane) you can surely set up a=20 co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using the=20 control plane. These either use the GMPLS > > (which is >= ;=20 > > > cleaner) or non-standard proprietary solutions (which=20 is > > messy but > > > > functional). > &= gt;=20 > > > > > > But (of course) the management plane = or=20 control plane > > solutions have > > > > nothin= g to=20 do with availability of equipment as they > are software > > > > solutions. >= ; >=20 > > > > > > > 2. My reading of one of Neil's=20 messages is that the actual > > > > driver for > &= gt;=20 > > > co-routed bidirectional paths may be experience with exi= sting=20 > > > > > transport networks rather than any specifi= c=20 benefit. > > > > > > > > Isn't that the = case=20 with 75% of the MPLS-TP requirements? > > > > Which is n= ot to=20 say it is a bad thing. > > > > > > > > A= =20 large driver for MPLS-TP is to give the packet network > > the= =20 look, > > > > feel, and behavioral characteristics of a= =20 "legacy" > > > > transport network. > > > &g= t;=20 > > > > > Based on these observations, I'd guess (FW= IW)=20 that: > > > > > * associated bidirectional paths are,= at=20 least for the time > > > > > being, the = most=20 important type of bidirectional paths in > > > > > &n= bsp;=20 MPLS-TP > > > > > > > > I think th= at is=20 wrong both given my statement above, and > > given that >= ;=20 > > > other upgrades to existing MPLS solutions will be >= ;=20 needed to reach > > > > the full function level of=20 MPLS-TP. > > > > > > > > > * they had= a=20 good chance to remain the only type of > > bidirectional &g= t;=20 > > > > paths in real deployments. > >= ;=20 > > > > > > I don't see what that follows=20 from. > > > > > > > > Cheers, > &g= t;=20 > > Adrian > > > > > > > >=20 _______________________________________________ > > > >= =20 mpls-tp mailing list > > > > mpls-tp@ietf.org > &g= t;=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > &g= t;=20 > > > > >=20 _______________________________________________ > > > >= =20 mpls-tp mailing list > > > > mpls-tp@ietf.org > &g= t;=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > &g= t;=20 > > > > > > > >=20 _______________________________________________ > > > mpls-= tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > >= ;=20 > > _______________________________________________ >=20 mpls-tp mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing= =20 list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-= tp --------------------------------------------------------ZTE=20 Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication i= s=20 confidential. Recipients named above are obligated to maintain secrecy = and=20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidentia= l and=20 intended solely for the use of the individual or entity to whom they ar= e=20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are thos= e of=20 the individual sender. This message has been scanned for viruses and= Spam=20 by ZTE Anti-Spam system. ------------------= -------------------------------------- ZTE Information Security Notice: The information&n= bsp;contained in this mail is solely property= of the sender's organization. This mail = ;communication is confidential. Recipients named a= bove are obligated to maintain secrecy and&nb= sp;are not permitted to disclose the contents= of this communication to others. This email and any files transmitted with&nbs= p;it are confidential and intended solely for= the use of the individual or entity&nbs= p;to whom they are addressed. If you hav= e received this email in error please no= tify the originator of the message. Any = views expressed in this message are those&nbs= p;of the individual sender. This message has been scanned for viruses&nbs= p;and Spam by ZTE Anti-Spam system. --_000_A3C5DF08D38B6049839A6F553B331C76A8CF16E022ILPTMAIL02eci_-- From maarten.vissers@huawei.com Wed Apr 22 05:44:22 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A5128C4D7 for ; Wed, 22 Apr 2009 05:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0A+vJ8yQ9Ky for ; Wed, 22 Apr 2009 05:44:17 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id C729F28C4D5 for ; Wed, 22 Apr 2009 05:44:17 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042205453520107 ; Wed, 22 Apr 2009 05:45:35 -0700 Received: from M00900002 ([10.84.2.164]) by s-utl02-sjpop.stsn.net; Wed, 22 Apr 2009 05:45:28 -0700 From: "Maarten Vissers" To: Date: Wed, 22 Apr 2009 14:45:21 +0200 Message-ID: <004101c9c348$3950d470$a402540a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C9C358.FCD9A470" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnCJcNHHo+eAHyvRdGt/oqSgC/iuwAUreqgADNrmLA= In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C04756097@E03MVB2-UKBR.domain1.systemhost.net> Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 12:44:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C9C358.FCD9A470 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Neil, =20 I expect that the main requirement for a packet transport network = technology like MPLS-TP is that it is able to support at least the following = services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed manner. =20 Another main requirement is that it must be able to support those = services in a scalable manner between points anywhere in the world. =20 The E-Line, E-Tree and E-LAN services allow to reorder client frames = that belong to different priorities and to drop client frames that are drop eligible. =20 The E-Tree and E-LAN services require that client bits are read to = deliver the frames to the appropriate output port or ports of the E-Tree or = E-LAN supporting transport entity/differentiated connection. =20 The packet transport network technology must as such support traffic engineered transport entities (differentiated connections) with n input ports (i.e. multi source constructs). This in addition of traffic = engineered transport entities with 1 input port. =20 Regards, Maarten _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these. =20 1 Provide a transparent client/server relationship...which means: - all client bits treated equally - client bit ordering preserved - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols - the traffic behaviour of client X must not impact the performance experienced by client Y =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs) =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology. =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise. =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones). =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong. =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim. =20 regards, Neil =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------=_NextPart_000_0042_01C9C358.FCD9A470 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Neil, I expect that the main requirement for a packet = transport network technology like MPLS-TP is that it is able to = support at=20 least the following services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed=20 manner. Another main requirement is that it must be = able to support=20 those services in a scalable manner between points anywhere in the=20 world. The E-Line, E-Tree and E-LAN services allow to = reorder=20 client frames that belong to different priorities and to drop=20 client frames that are drop eligible. The E-Tree and E-LAN services require that = client bits are=20 read to deliver the frames to the appropriate output port or = ports of the=20 E-Tree or E-LAN supporting transport entity/differentiated=20 connection. The packet transport network technology must as = such=20 support traffic engineered transport entities (differentiated = connections)=20 with n input ports (i.e. multi source constructs). This in addition of = traffic=20 engineered transport entities with 1 input port. Regards, Maarten From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 neil.2.harrison@bt.com Sent: dinsdag 21 april 2009=20 14:31 To: liu.guoman@zte.com.cn; = dbrungard@att.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Liu, If MPLS-TP is going to = be taken=20 seriously as a transport network (like SDH/SONET) then the 2 key = MUST HAVE=20 requirements are these. 1    = Provide a=20 transparent client/server relationship...which = means: -    all = client bits=20 treated equally -    = client bit=20 ordering preserved -    no = attempt to=20 infer client symbol (ie sequence of client bits) meaning and no attempt = to=20 change client symbols -    the = traffic=20 behaviour of client X must not impact the performance experienced by = client=20 Y A key corollary of the = above is that=20 MPLS-TP must only support proper connections (ie single source=20 constructs) 2   Since = MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does not = support=20 directly external message/file/stream applications). MPLS-TP = therefore=20 does not require an E-NNI specification. A key corollary of this = is that=20 MPLS-TP will not have any peer interworking relationship with any other = network=20 mode/technology. Now wrt OAM MPLS-TP is a = co-ps mode=20 network. You could argue this should have FDI/AIS....however, the = merit of=20 this is highly questionable. When I and colleagues discussed = whether=20 PBB-TE (also a co-ps mode network) should have FDI/AIS we concluded that = on=20 balance it was not a good idea.....and note that initially I was in = favour of=20 having AIS, but my colleagues provided strong technical arguments that = convinced=20 me otherwise. AIS/FDI is historically = linked to=20 the early PDH co-cs mode layer networks that used TTL logic. When = this=20 died it put out a +5V (all 1s) signal by default, ie it required no = conscious=20 effort to generate it.....this is key point. Further, in these = networks=20 there is a fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never = specified AIS=20 for IP and its why IEEE had the good sense to throw-out AIS in 802.1ag = for=20 Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect=20 any operator planning to use Ethernet equipment would always look to = IEEE stds=20 and not ITU ones). AIS/FDI and the co-ps = mode is=20 debatable. As I noted above, on balance we considered not a good = idea for=20 PBB-TE OAM because it requires a conscious effort to generate it (unlike = the=20 co-cs mode) so there are likely to be scaling problems and its one more = thing to=20 go wrong. You should also have = seen me make=20 the point many times in the past that the always-on defect = detection/handling=20 OAM needs to be as simple/sparse as possible with as little config as = possible=20 because we need super reliability......TCM goes completely against the = grain=20 here. Also note that the OAM required for each of the 3 network = modes is=20 not the same, despite what some claim. regards,=20 Neil From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009 = 02:59 To:=20 BRUNGARD, DEBORAH A, ATTLABS Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Deborah: maybe = what you said is=20 right. but I can't completely agree your opinions. IMO. mpls-tp is = regard as=20 transport network like SDH/SONET. so it should have AIS/FDI fuctions = as=20 SDH/SONET. do you = think so.=20 best regards liu "BRUNGARD, = DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB: = mpls-tp-bounces@ietf.org=20 2009-04-20 23:47 =CA=D5=BC=FE=C8=CB "Maarten Vissers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com>=20 =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 size=3D2>I agree with Neil, it is very questionable the value of = AIS/FDI in=20 a packet network- any mode. It can result in a DoS attack by an=20 operator on themselves so even Y1731 recommends not to block data=20 frames: "A MEP can decide whether it blocks data frames when it = detects=20 dAIS. The principle requirement that influences this decision is = that=20 data frames ought to be forwarded as much as possible, = without the=20 possibility of forwarding wrong data frames downstream." Table = I.7-2 shows=20 for AIS, not to block. And as Y1731 states, AIS can only be = used under=20 very constrained architectures - if required for MPLS-TP, it needs = to have=20 the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a point-to-point ETH connection, a MEP has only a = single=20 peer MEP. Therefore, there is no ambiguity regarding the peer = MEP for=20 which it should suppress alarms when it receives the ETH-AIS=20 information." So should only be within one domain - then no=20 need. Deborah -----Original Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] = On Behalf Of=20 Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the cl = mode?...do=20 me a favour! Ethernet AIS is indeed a requirement and a = necessity. And=20 you will not be able to understand that as long as you refuse to = accept=20 that "cl-mode" is a forwarding mode within a **transport = entity**. G.800=20 amendment 1 has finally reintroduced this transport entity into = G.800.=20 Besides that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is a = transport=20 entity that transfers information belonging to multiple = communications=20 between ports across a subnetwork. <..> In a differentiated=20 connection message contents are interpreted to identify (sets = of)=20 communications which receive different treatment. The sets = of=20 communications may be distinguished by the forwarding identifier or = other=20 layer information. Order is not necessarily preserved = between=20 messages belonging to sets of communications receiving different = treatment.=20 Sets of communications may be identified for purposes such = as=20 traffic conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 = "differentiated=20 connections". Ethernet AIS provides AIS within the scope of such = "differentiated connection". If you apply this to my proposed = PTN layer=20 stack, then the EVC layer topology will consists of EVC links = supported=20 by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro = and core=20 domains interconnecting EVC matrices. When one of those EVC = links is=20 interrupted, e.g. in the core between metro 1 and metro 4 (see = attached=20 slide), then the EVC differentiated connection that is present = on this=20 link will be interrupted. At the EVC switch/bridge node in metro = 4 this=20 interruption is noticed and EVC-AIS is inserted in the downstream = direction=20 to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. The=20 EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which=20 guarantees that the AIS is broadcast to the endpoints of the = EVC. I=20 believe that it is time for you to adapt your view on co and cl=20 modes and relate it to the forwarding mode **INSIDE** a = transport=20 entity. What we know as the internet is essentially an "IP=20 differentiated connection" with a billion or more ports. What we = know as=20 an IP VPN is essentially an "IP differentiated connection" with = e.g. n=20 ports (n in the range of e.g. 2 to 1000). What we know as an = Ethernet VLAN=20 is essentially an "Ethernet differentiated connection" with n = ports (n=20 in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP = is=20 essentially an "MPLS differentiated connection" with 2 = ports. What we=20 know as a p2p SDH VC-n is a "SDH VC-n connection" with 2=20 ports. Transport network OAM applies to transport entities, = which are=20 (in terms of G.800 am1) connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com = [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting a wee = bit=20 tired of folks trying to make all 3 network modes look alike = (and then,=20 even worse, interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I am = even=20 more frustrated by the fact those peddling this FUD only ever seem = to=20 consider OAM and forget all other DP/CP/MP components (esp = top-of-stack=20 message/file/stream application adaptations). How wrong can = this get!=20 In the co modes a *connection* is a very specific and=20 *constraining* construct.....I am assuming here we respect the = rules of a=20 connection (ie single source) though some folks don't even = bother to=20 respect this, and this is despite the fact that we all know what = problems multiple-source constructs can cause (from LDP/PHP....ergo = MPLS-TP). When we have a connection this restricts *all* DP (ie = traffic=20 and OAM) to stay within the bounds of the connection. = Which is=20 fine under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is broken. = In=20 a nutshell what this means is that OAM that is of a = request/response=20 nature cannot be trusted in co mode networks under misconnectivity=20 defects.....indeed, why should a leaking DP have a symmetric = go/return=20 defect behaviour?....very likely it won't. So whilst = request/response=20 OAM is right for the cl mode it is not right for the co mode = under=20 misconnectivity defect conditions. More generally the 3 modes = are=20 different and not just in OAM requirements....but AIS/FDI in the cl = mode?...do me a favour!...at least IEEE had the good sense to bin = this for=20 Ethernet even though it remains in Y.1731. And which is = why I=20 often trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found it = necessary to=20 create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies = in the=20 physics...and G.800 attempts to explain that physics....G.805 does=20 not. So, the 3 modes are different...please accept/rejoice in = this fact=20 as they all offer something different/important. But do = not be=20 hoodwinked by those who peddle a story that that tries to make = the OAM=20 of the 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > = Sent: 17=20 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten = Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > requirements > >=20 Italo, > > As described in the MPLS TP OAM Requirements = I-D,=20 virtually all of the > OAM functions require a return path, = and in=20 the absence of a return > path they are disabled. > = > As=20 described in David Sinicrope's meeting minutes >=20 (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > = meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP = addressing=20 is used, an > MPLS TP network needs to be capable of getting IP = packets=20 from > destination to source; neither the minutes nor I = stipulate that=20 a > control plane needs to be used to instantiate this=20 forwarding. > > As an aside, the issue of return path for = unidirectional LSPs could be > charaterized as the elephant = in the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs = are only=20 mentioned three times and return > paths not at all. > = >=20 Thanks, > > John > > -----Original = Message----- >=20 > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > = > Sent:=20 Friday, April 17, 2009 1:59 AM > > To: Drake, John E; = Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > = >=20 Subject: RE: [mpls-tp] Associated bidirectional transport path = > >=20 requirements > > > > John, > > > = > I=20 might have missed the agreement of MPLS-TP being capable of > = >=20 sending replies to OAM requests sent on uni-directional LSPs. > = >=20 > > This requirement does not belong to the first set of=20 requirements > > ITU-T is expecting to be met by = October. >=20 > > > However, I think this in a potential interesting = additional=20 > > requirement to be taken into account (at worst in = a >=20 subsequent phase). > > > > I think that this = requirement=20 needs to be evaluated versus other > > more important = requirements=20 (e.g. the possibility to work w/o IP > > forwarding and the = need for=20 OAM to continue to monitor the data > > plane also in case = of=20 failures affecting the control or management > > = plane). >=20 > > > I am open to discuss it but not sure this is the = right time=20 because > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = > >=20 > -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of Drake, John E > > > Sent: Thursday, April 16, = 2009=20 8:00 PM > > > To: Alexander Vainshtein; Maarten = Vissers >=20 > > Cc: mpls-tp@ietf.org > > > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > > >=20 requirements > > > > > > At the meeting last = fall at=20 Juniper in Massachusetts, I > > think it was > > = > agreed=20 that an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM packets = (e.g.,=20 sending > > replies to OAM > > > requests sent on = uni-directional LSPs) even if it does not > > have an = IP > >=20 > forwarding data plane. > > > > > > >=20 -----Original Message----- > > > > From: Alexander=20 Vainshtein > > > = [mailto:Alexander.Vainshtein@ecitele.com] >=20 > > > Sent: Thursday, April 16, 2009 9:57 AM > > = > >=20 To: Maarten Vissers > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > > = > >=20 > Maarten, > > > > It seems that you've just = (implicitly=20 and, probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will not ever = support MIP=20 loopback function > > (and fault > > > > = localization=20 which requires this function ) for > > unidirectional = P2MP >=20 > > > and P2P paths. > > > > > > = > >=20 If this statement is correct, this (IMHO and FWIW) > raises a=20 valid > > > > question: > > > > > = >=20 > > = Is=20 MPLS-TP an appropriate solution for these > types of = transport >=20 > > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > functionality=20 today > > > > for (unidirectional - but it does not = know any=20 other > > type) P2P LSPs > > > > as described = in RFC=20 4379. And its extension to P2MP LSPs seems > > > >=20 easy... > > > > > > > > > = >=20 > > > > > > Regards, > > > > = >=20 > > > Sasha > > > > = > >=20 > > > > > > > > > >=20 ________________________________________ > > > > From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: Thursday, = April 16,=20 2009 3:24 PM > > > > To: 'Adrian Farrel' > > = > >=20 Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > > = requirements > >=20 > > > > > > Adrian, > > > > = > >=20 > > >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > > = > >=20 other internal > > > > >> = functions=20 as appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> path at = each=20 (sub-)layer MUST be aware of the pairing > > > > = >>=20 relationship of the forward and the = backward > >=20 > > directions of that > > > > >> = =20 transport path. > > > > >> <end=20 quote> > > > > > > > > > > = There is no=20 way this is a functional requirement. That > > > is, there = is > > > > > *nothing* that can be observed from a = black box=20 point of > > > view that > > > > > = results from=20 adhering to this requirement. > > > > > > = > >=20 Your understanding is not correct. It is very much > observable=20 if > > > > this requirement is met from a black box = point of=20 view. > > > > The MIP functions can only perform the = Loopback=20 when there is a > > > > co-routed bidirectional = transport=20 path. The MPLS-TP LBM packet > > > > received at a MIP = needs=20 to be returned (as LBR > > > > packet) to the = originating MEP=20 function via the other > > direction of > > > = > the=20 co-routed bidirectional transport path. This other > = direction >=20 > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > = > >=20 would fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, then > = >=20 > > this is possible in a co-routed bidir transport path > = but not=20 in a > > > > associated bidir transport path. In the = first case=20 the TCM MEP > > > > Source and Sink functions are = co-located=20 and can > exchange what is > > > > called "remote = information" which is necessary for performance > > > = >=20 monitoring. > > > > In the latter case the TCM MEP = Source and=20 Sink functions > > are in e.g. > > > > = different=20 nodes in the network and TCM would not be able > > to = provide >=20 > > > performance monitoring. > > > > > = >=20 > > > The entirety of the bracketted text "(including = MEPs, >=20 > > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does = not >=20 > > > add to "The > > > > > intermediate=20 nodes." > > > > > > > > Your = understanding is=20 not correct. This text must not be > > deleted at > = > >=20 > all. > > > > > > > > > = Actually, I am=20 quite fed up about this persistent > > > insistence on = the >=20 > > > inclusion > > > > > of "Tandem = Connection."=20 The definition within the ITU-T of > > > > this = term >=20 > > > > is > > > > poorly > > > = >=20 > specified and comes from the monitoring of a path that is > = >=20 > > parallel (i.e. > > > > tandem) > > = > >=20 > to the data path being monitored. This definition of TC > = > >=20 > seems to be at > > > > variance, > > > = >=20 > and would be if the ACH was actually in band. > > > = >=20 > > > > I don't understand where your interpretation = of=20 tandem > > connection is > > > > described in = ITU-T=20 recommendations. I.e. "from the > > monitoring of a > = > >=20 > path that is parallel (i.e. tandem) to the data path being = > >=20 > > monitored."? > > > > > > > > = There is=20 a "network connection" and this network > > connection is a=20 set > > > > of interconnected "link connections" and=20 "matrix > connections". A > > > > subset of those = interconnected link connections and matrix > > > > = connections=20 can be monitored and is then referred to as > a "tandem > = >=20 > > connection". There is no "path that is parallel to = the > >=20 data path". > > > > There is only additional OAM = inserted=20 inside the data > path by the > > > > TCM MEP_So = function=20 and this OAM is extracted from the > > data path by > = > >=20 > the TCM MEP_Sk function. > > > > > > = > >=20 Regards, > > > > Maarten > > > > = > >=20 > > > > > > -----Original Message----- > = > >=20 > From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > = > >=20 > Sent: donderdag 16 april 2009 11:59 > > > > To: = Alexander=20 Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: = BUSI=20 ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi = Sasha, >=20 > > > > > > > > Unfortunately I cannot = fully agree=20 with your statement: > > > > > > > > = > >=20 <quote> > > > > > From the point = of view=20 of hardware, co-routed > > > bidirectional LSPs > = > >=20 > > are a special case of associated bidirectional = LSPs. > > > > > <end quote> > > > = >=20 > > > > > > This statement would be obviously = correct,=20 were it not for > > > > Requirement > > > = > >=20 34 in the latest MPLS-TP requirements draft > > > > = >=20 > > > OK. Got it. > > > > > > > = > But=20 what is this doing in the data plane requirements section? > = > >=20 > > > > > In fact, what is this requirement = actually=20 saying? > > > > > > > > >=20 <quote> > > > > > The = intermediate=20 nodes (including MEPs, MIPs and > > > other = internal > >=20 > > > functions as appropriate) of a=20 co-routed > > > > bidirectional transport > > = >=20 > > path at each (sub-)layer MUST be aware = of the=20 pairing > > > > > relationship = of the=20 forward and the backward > > > > directions of = that >=20 > > > > transport path. > > = >=20 > > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > > = is, there=20 is > > > > *nothing* that can be observed from a black = box=20 point of > > view that > > > > results from = adhering=20 to this requirement. > > > > > > > > = Therefore=20 it could be assumed that this requirement is met by > > > = >=20 configuring some data plane database component through the > = > >=20 > management plane. The database component is not used > for=20 anything > > > > except to satisfy this requirement for = "awareness". > > > > > > > > Ben! Can = we please=20 try to rewrite this requirement in terms of > > > >=20 behavior? > > > > > > > > > Please = note that=20 Requirement 34 is the ONLY item in the > > > > list = that=20 is > > > > > specific for co-routed bidirectional = LSPs. (The=20 pairing > > > > requirements > > > > = > at end=20 points for co-routed and associated bidirectional > > > = paths=20 are > > > > > exactly the same even if they appear = in two=20 different > > > items in the > > > > >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > > = >=20 bidirectional paths would be void of any data plane content. > = > >=20 > > > > > > > The somewhat vague scope of this = requirement ("other internal > > > > > functions as = appropriate") creates a suspicion that HW > > > > = support of=20 the > > > > > pairing awareness may be required in = order to=20 comply with it. > > > > > > > > The = entirety of=20 the bracketted text "(including MEPs, > > MIPs and = other > >=20 > > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate = nodes." >=20 > > > > > > > > The following text in the = draft=20 increases this suspicion: > > > > > > > = > >=20 > <quote> > > > > > Tandem = Connection: A=20 tandem connection is an > > arbitrary part of a > > = >=20 > > transport path that can be monitored (via = OAM) > >=20 > > independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > segment or=20 a > > > > > monitored concatenated segment of = a=20 transport path. > > The tandem > > > > = >=20 connection may also include the forwarding engine(s) of > = >=20 > > the node(s) > > > > > at the = edge(s) of the=20 segment or concatenated segment. > > > > > <end=20 quote> > > > > > > > > Actually, I = am quite=20 fed up about this persistent > > insistence on the > = > >=20 > inclusion of "Tandem Connection." The definition within > = > the=20 ITU-T of > > > > this term is poorly specified and = comes from=20 the > monitoring of a > > > > path that is = parallel (i.e.=20 tandem) to the data path being > > > > monitored. This = definition of TC seems to be at variance, > > and = would > >=20 > > be if the ACH was actually in band. > > > > = >=20 > > > > Doesn't "forwarding engine" sound like hardware to = you? > > > > > > > > Yes, but so = what? >=20 > > > > > > > > IMHO it is worth noting = that=20 neither the MPLS-TP > > > Requirements draft > > = >=20 > > nor the MPLS-TP OAM requirements one > > > > = >=20 > > > > > > > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing with=20 tandem > > > connections. > > > > = > > >=20 > > > But tandem connections are discussed in the MPLS-TP = OAM >=20 > Framework > > > > > draft > > > = >=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > = >=20 > > amework-00.txt > > > > ). > > > = >=20 > > > > Right. > > > > Let's just get = rid of an=20 unnecessary term and bring all > the I-Ds > > > > = into=20 line. > > > > > > > > > The bottom = line,=20 IMHO, is that some clarity regarding > > > co-routed = vs. >=20 > > > > associated > > > > > = bidirectional paths=20 is still required. One way to provide > > > > that=20 could > > > > > be by explicitly limiting = Requirement 34 to=20 specific > > > functionality. > > > > = > >=20 > > Agreed. > > > > > > > >=20 Adrian > > > > > > > > > > = > >=20 > > > > > > > >=20 ________________________________________ > > > > From: = Adrian=20 Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, = April 16,=20 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou = Berger;=20 BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = > >=20 > > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > Not really sure = whether=20 you are misrepresenting anyone, but... > > > > > = >=20 > > > 1. My reading of one of Ben's messages is = that=20 associated > > > > > bidirectional paths are the = only types=20 of paths that can be > > > > created in > > = > >=20 > the existing networks; "true" co-routed bidirectional = paths > >=20 > > will have > > > > > to wait until (if = ever) new=20 equipment becomes available. > > > > > > > = >=20 This is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > > = > >=20 a special case of associated bidirectional LSPs. > > > = >=20 > > > > If you can set up two unidirectional LSPs = (e.g. using=20 the > > management > > > > plane) you can = surely set=20 up a co-routed > > > bidirectional LSP. > > > = >=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using the = control=20 plane. These either use the GMPLS > > (which is > > = >=20 > cleaner) or non-standard proprietary solutions (which is > = >=20 messy but > > > > functional). > > > > = >=20 > > > But (of course) the management plane or control = plane >=20 > solutions have > > > > nothing to do with = availability of=20 equipment as they > are software > > > >=20 solutions. > > > > > >=20 > > > 2. My reading of one of Neil's messages is that the=20 actual > > > > driver for > > > > > = co-routed=20 bidirectional paths may be experience with existing > > > = >=20 > transport networks rather than any specific benefit. > > = >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a bad=20 thing. > > > > > > > > A large driver = for=20 MPLS-TP is to give the packet network > > the look, > = > >=20 > feel, and behavioral characteristics of a "legacy" > > = > >=20 transport network. > > > > > > > > > = Based=20 on these observations, I'd guess (FWIW) that: > > > > = > *=20 associated bidirectional paths are, at least for the time > > = >=20 > > being, the most important type of bidirectional = paths=20 in > > > > > MPLS-TP > > > = >=20 > > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other upgrades to = existing=20 MPLS solutions will be > needed to reach > > > > = the full=20 function level of MPLS-TP. > > > > > > > = > >=20 * they had a good chance to remain the only type of > >=20 bidirectional > > > > > paths in real=20 deployments. > > > > > > > > I don't = see what=20 that follows from. > > > > > > > >=20 Cheers, > > > > Adrian > > > > > = >=20 > > _______________________________________________ > > = >=20 > mpls-tp mailing list > > > > = mpls-tp@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > = > >=20 > > > >=20 _______________________________________________ > > > > = mpls-tp=20 mailing list > > > > mpls-tp@ietf.org > > > = >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > > = >=20 > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = > >=20 > _______________________________________________ > = mpls-tp=20 mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing = = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= --------------------------------------------= ------------ ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------=_NextPart_000_0042_01C9C358.FCD9A470-- From xqwei@fiberhome.com.cn Wed Apr 22 05:49:39 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE6828C4D3 for ; Wed, 22 Apr 2009 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.127 X-Spam-Level: **** X-Spam-Status: No, score=4.127 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185, J_CHICKENPOX_25=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRTbJS2tQs+H for ; Wed, 22 Apr 2009 05:49:38 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id 8D8FC3A6D00 for ; Wed, 22 Apr 2009 05:49:36 -0700 (PDT) Received: from xqwei ([58.49.48.98]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Apr 2009 20:46:04 +0800 Date: Wed, 22 Apr 2009 20:50:40 +0800 From: "Xueqin WEI (Shuetsing WEI)" To: "liu.guoman" References: Message-ID: <200904222050402508137@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 22 Apr 2009 12:46:04.0126 (UTC) FILETIME=[4C4287E0:01C9C348] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectionaltransport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 12:49:39 -0000 R3VvbWFuOg0KDQpDb3JyZWN0OiB3ZSBhcmUgZGlzY3Vzc2luZyByZXF1aXJlbWVudHMgb2Ygc2Vn bWVudCBtb25pdG9yaW5nIG9mIGFuIEVuZCB0byBFbmQgTFNQLg0KDQpTaW5jZXJlbHkgWW91cnMN Clh1ZXFpbiBXZWkgKFNodWV0c2luZyBXZWkpDQoNCkRldmVsb3BtZW50ICYgUGxhbm5pbmcgRGVw YXJ0bWVudCwNCkZpYmVyaG9tZSBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2dpZXMgQ28uLEx0 ZC4sDQpOby44OCBZb3VrZXl1YW4gUm9hZCxIb25nc2hhbiBEaXN0LixXdWhhbixIdWJlaSxQLlIu Q2hpbmEsNDMwMDc0DQpUZWw6ICAgICs4NiAyNyA4NzY5MTMxMA0KRmF4OiAgICArODYgMjcgODc2 OTQzNjINCkVtYWlsOiAgeHF3ZWlAZmliZXJob21lLmNvbS5jbg0KMjAwOS0wNC0yMiAgMjA6NDc6 MzgNCg0KPT09PT09PT09PT09PT09PT09PT0gRm9sbG93aW5nIGlzIHlvdXIgZW1haWw9PT09PT09 PT09PT09PT09PT09PT0NClN1YmplY3Q6UmU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMg aW4gTVBMUy1UUCAod2FzIFJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsdHJhbnNwb3J0IHBhdGgg cmVxdWlyZW1lbnRzKQ0KU2VudKO6MjAwOS0wNC0yMiAxNzowMjoxMw0KRnJvbTpsaXUuZ3VvbWFu DQpUbzp4cXdlaQ0KQ0MgdG86bXBscy10cA0KDQo+SSBzdXBwb3J0IGh1YW5mZW5nJ3Mgb3Bpbmlv bnMsIGhlcmUgd2Ugb25seSBkaXNzY3VzcyB0aGUgcmVxdWlyZW1lbnRzIG9mIA0KPlRDTS4gaG93 IHRvIHJlYWxpemUgdGhlIGZ1bmN0aW9ucyBvZiBUQ00gd2lsbCBiZSBkaXNzY3Vzc2VkIGluIHRo ZSBmdXR1cmUuIA0KPkkgd2lzaCB0aGF0IHh1ZXFpbiBjb25zaWRlciBpdCB2ZXJ5IHdlbGwuDQo+ DQo+dGhhbmsgeW91DQo+bGl1DQo+DQo+DQo+DQo+Ilh1ZXFpbiBXRUkgKFNodWV0c2luZyBXRUkp IiA8eHF3ZWlAZmliZXJob21lLmNvbS5jbj4gDQo+t6K8/sjLOiAgbXBscy10cC1ib3VuY2VzQGll dGYub3JnDQo+MjAwOS0wNC0yMiAxNjoyMg0KPsfrtPC4tCC4+A0KPnhxd2VpQGZpYmVyaG9tZS5j b20uY24NCj4NCj4NCj7K1bz+yMsNCj4iSFVBTkcgRmVuZyBGIiA8RmVuZy5mLkh1YW5nQGFsY2F0 ZWwtc2JlbGwuY29tLmNuPg0KPrOty80NCj5NUExTLVRQIDxtcGxzLXRwQGlldGYub3JnPg0KPtb3 zOINCj5SZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgDQo+ UkU6QXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0K Pg0KPg0KPg0KPg0KPg0KPg0KPkZlbmc6DQo+DQo+VGhlIGZ1bmN0aW9uIG9mIFRDTSBjYW4gYmUg cHJvdmlkZWQgYnkgbmVzdGVkIExTUCAoV2hpY2ggaXMgdGhlIGJhc2ljIA0KPmZ1bmN0aW9uIG9m IE1QTFMtVFApLCB3ZSBuZWVkbid0IHRvIGRlZmluZSBUQ00uDQo+DQo+DQo+U2luY2VyZWx5IFlv dXJzDQo+WHVlcWluIFdlaSAoU2h1ZXRzaW5nIFdlaSkNCj4yMDA5LTA0LTIyICAxNjoyMDoxMA0K Pg0KPj09PT09PT09PT09PT09PT09PT09IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09 PT09PT09PT09PT09DQo+U3ViamVjdDpSRTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBp biBNUExTLVRQICh3YXMgDQo+UkU6QXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzKQ0KPlNlbnSjujIwMDktMDQtMjAgMjE6NTg6MTgNCj5Gcm9tOkhVQU5H IEZlbmcgRg0KPlRvOnhxd2VpQGZpYmVyaG9tZS5jb20uY247IEJlbiBOaXZlbi1KZW5raW5zOyBC dXNpIEl0YWxvDQo+Q0MgdG86TVBMUy1UUA0KPg0KPj5EZWFyIFh1ZXFpbiwNCj4+ICAgICBXZSBh cmUgZGlzY3Vzc2luZyByZXF1aXJlbWVudCBvZiBUQ00sIG5vdCBmb3IgIGZ1bmN0aW9uIGFuZCBt ZXRob2QgDQo+aW4gZGV0YWlscy4NCj4+Qi5SLg0KPj5GZW5nIA0KPj4NCj4+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiANCj5CZWhhbGYgT2YgWHVlcWluIFdFSSAoU2h1 ZXRzaW5nIFdFSSkNCj4+U2VudDogMjAwOcTqNNTCMTjI1SAxNDo1Mg0KPj5UbzogQmVuIE5pdmVu LUplbmtpbnMNCj4+Q2M6IE1QTFMtVFANCj4+U3ViamVjdDogUmU6IFttcGxzLXRwXSBUYW5kZW0g Q29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIA0KPlJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj4+DQo+PlN1cHBvcnQsIEkgdGhpbmsgdGhl IG5lc3RlZCBMU1Agd2lsbCBiZSBncmVhdCEgVW50aWwgbm93LCBJIGRpZG4ndCBzZWUgDQo+YW55 IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmVzdGVkIExTUCBhbmQgVENNIG9uIHBlcmZvcm1hbmNl IG1vbml0b3JpbmcuIA0KPkJ1dCB0aGUgbmVzdGVkIExTUCB3aWxsIG1ha2UgdGhlIHRoaW5ncyBt b3JlIGVhc3kuIEkgd291bGQgbGlrZSBzZWxlY3QgYSANCj5zaW1wbGUgd2F5IHRvIHJlc29sdmUg dGhlIHByb2JsZW0uDQo+Pg0KPj5TaW5jZXJlbHkgWW91cnMNCj4+WHVlcWluIFdlaSAoU2h1ZXRz aW5nIFdlaSkNCj4+DQo+PkZpYmVyaG9tZSBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2dpZXMg Q28uLEx0ZC4sDQo+PjIwMDktMDQtMTggIDE0OjQ4OjUxDQo+Pg0KPj49PT09PT09PT09PT09PT09 PT09PSBGb2xsb3dpbmcgaXMgeW91ciBlbWFpbD09PT09PT09PT09PT09PT09PT09PQ0KPj5TdWJq ZWN0OlJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyBSRTog DQo+QXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0K Pj5TZW50o7oyMDA5LTA0LTE3IDE3OjE3OjMxDQo+PkZyb206QmVuIE5pdmVuLUplbmtpbnMNCj4+ VG86QlVTSSBJVEFMTzsgQWRyaWFuIEZhcnJlbDsgQWxleGFuZGVyIFZhaW5zaHRlaW4gQ0MgdG86 bXBscy10cA0KPj4NCj4+Pkl0YWxvLA0KPj4+DQo+Pj5PbiAxNy8wNC8yMDA5IDA5OjM0LCAiQlVT SSBJVEFMTyIgPEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+IHdyb3RlOg0KPj4+PiBUaGUg SldUIGFncmVlbWVudCBpcyB0byBicmluZyB0aGUgSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50 cyBpbiANCj4+Pj4gSUVURiB0byBleHRlbmQgdGhlIE1QTFMgYXJjaGl0ZWN0dXJlIHRvIG1lZXQg dGhlbSBpbiBhIHdheSB0aGF0IGlzIA0KPj4+PiBjb21wYXRpYmxlLCBjb25zaXN0ZW50IGFuZCBj b2hlcmVudCB3aXRoIGV4aXN0aW5nIElFVEYgYXJjaGl0ZWN0dXJlLg0KPj4+DQo+Pj5TbyBJIHRv b2sgYSBsb29rIGF0IHRoZSBKV1QgcmVwb3J0LiBJdCBzYXlzIChzbGlkZSAxNikNCj4+Pg0KPj4+ IiBTZXJ2aWNlIFByb3ZpZGVycyB3YW50IExTUHMvUFdFcyB0byBiZSBhYmxlIHRvIGJlIG1hbmFn ZWQgYXQgdGhlIA0KPj4+ZGlmZmVyZW50IG5lc3RlZCBsZXZlbHMgc2VhbWxlc3NseSAocGF0aCwg c2VnbWVudCwgbXVsdGlwbGUgc2VnbWVudHMpDQo+Pj4gICAgYWthIFRhbmRlbSBDb25uZWN0aW9u IE1vbml0b3JpbmcgKFRDTSksIHRoaXMgaXMgdXNlZCBmb3IgZXhhbXBsZSANCj4+PndoZW4gYSBM U1AvUFdFIGNyb3NzZXMgbXVsdGlwbGUgYWRtaW5pc3RyYXRpb25zIg0KPj4+DQo+Pj5JTU8gdGhl IHJlcXVpcmVtZW50IGlzIHRvIGJlIGFibGUgdG8gbW9uaXRvciBwYXJ0cyBvZiBhIHBhdGggYXMg d2VsbCBhcyANCj4+PnRoZSBlbmQgdG8gZW5kIHBhdGguIFRoZXJlIGFyZSBtYW55IHdheXMgdG8g c29sdmUgdGhhdCByZXF1aXJlbWVudCwgb25lIA0KPj4+b2Ygd2hpY2ggaXMgdGhlIGNyZWF0aW9u IG9mIG5lc3RlZCBMU1BzLCBvbmUgcGVyIGxldmVsIG9mIG1vbml0b3JpbmcgDQo+Pj5yZXF1aXJl ZCAobXkgdW5kZXJzdGFuZGluZyBvZiBob3cgVENNIHdvcmtzKS4NCj4+Pg0KPj4+SSB0aGluayB0 aGUgcmVhbCBkaXNjdXNzaW9uIGlzIHRoZXJlZm9yZSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gbW9u aXRvciANCj4+PmRpZmZlcmVudCBjb21wb25lbnRzIG9mIGFuIGVuZCB0byBlbmQgcGF0aCBvciBp cyB0aGUgcmVxdWlyZW1lbnQgdGhhdCANCj4+PnN1Y2ggbW9uaXRvcmluZyBNVVNUIGJlIGFjaGll dmVkIHVzaW5nIG5lc3RlZCBMU1BzPw0KPj4+DQo+Pj5BcyBhbiBleGFtcGxlIFBXIHRlY2hub2xv Z3kgdG9kYXkgYWxsb3dzIGVuZCB0byBlbmQgYW5kIHBlciBzZWdtZW50IA0KPj4+bW9uaXRvcmlu ZyBidXQgaXQgZG9lcyBub3QgYWNoaWV2ZSBpdCB1c2luZyBuZXN0ZWQgUFdzIG9yIFBXIGxldmVs cy4NCj4+Pg0KPj4+QmVuDQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj5tcGxzLXRwIG1haWxpbmcgbGlzdA0KPj4+bXBscy10cEBpZXRm Lm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ Pj4NCj4+DQo+Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pm1wbHMtdHAgbWFpbGluZyBsaXN0DQo+Pm1wbHMtdHBAaWV0Zi5vcmcN Cj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+Pg0KPg0K Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5tcGxzLXRwIG1haWxpbmcgbGlzdA0KPm1wbHMtdHBAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4NCj4NCj4NCj4NCj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFt ZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv IG90aGVycy4NCj5UaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+VGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQoN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo= From neil.2.harrison@bt.com Wed Apr 22 06:14:05 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5083A6C0E for ; Wed, 22 Apr 2009 06:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy0Od489rE64 for ; Wed, 22 Apr 2009 06:14:00 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 80B323A6774 for ; Wed, 22 Apr 2009 06:13:59 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 14:15:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C34C.5F5BF353" Date: Wed, 22 Apr 2009 14:14:51 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047566D3@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAAIWOFAAAEotAA== From: To: , X-OriginalArrivalTime: 22 Apr 2009 13:15:15.0552 (UTC) FILETIME=[6030EE00:01C9C34C] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:14:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C34C.5F5BF353 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIHRvIGJvdGggQW5keSBhbmQgU2FzaGEgaGVyZS4gIEV4YWN0bHkgcmlnaHQgU2FzaGEu Li4uYW5kIHRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSBPQU0gaXMgbm90IHRoZSBzYW1l IGZvciBhbGwgMyBtb2Rlcy4NCiANCkkgYW0gZXNwZWNpYWxseSBkZWxpZ2h0ZWQgdG8gc2VlIEFu ZHkncyBjb21tZW50cyB0aGF0IGFtcGxpZnkgd2h5IHdlIGRvbid0IHRoaW5rIEFJUyBpcyBhIGdy ZWF0IGlkZWEgb3BlcmF0aW9uYWxseSBpbiBwYWNrZXQtbmV0d29ya3MuICAgDQogDQpyZWdhcmRz LCBOZWlsIA0KICANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJRnJv bTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbV0gDQoJU2VudDogMjIgQXByaWwgMjAwOSAxMTozMA0KCVRvOiBSZWlkLEFCRCxBbmR5 LENYTSBSDQoJQ2M6IG1wbHMtdHBAaWV0Zi5vcmc7IGxpdS5ndW9tYW5AenRlLmNvbS5jbjsgSGFy cmlzb24sTixOZWlsLENYTSBSDQoJU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoJDQoJDQoJQW5keSwNCglJ IGNhbm5vdCBhZ3JlZSBtb3JlLg0KCSANCglJbmRlZWQsIGluIHRoZSBURE0gd29ybGQgeW91IGhh ZCB0byBmaWxsIHRoZSBjbGllbnQgYml0IHN0cmVhbSB3aXRoIHNvbWV0aGluZyBwcmVkaWN0YWJs ZSBBTkQgZGlzdGluZ3Vpc2hhYmxlIGZyb20gdmFsaWQgY2xpZW50IHRyYWZmaWMuDQoJSW4gdGhl IHBhY2tldCB3b3JsZCwgbG9zcyBvZiBzZXJ2ZXIgY29ubmVjdGl2aXR5IG1lYW5zIHRoYXQgdGhl IGNsaWVudCBhcHBsaWNhdGlvbiBkb2VzIG5vdCByZWNlaXZlIGFueSBwYWNrZXRzLCBzbyB0aGVy ZSBpcyBub3RoaW5nIHRvIG1pc2ludGVycHJldCBhcyBjbGllbnQgdHJhZmZpYy4NCglIZW5jZSBu byBuZWVkIHRvICJmaWxsIGluIiBBSVMvRkRJLg0KCSANCglSZWdhcmRzLA0KCSAgICBTYXNoYQ0K CSANCgkgDQoJIA0KCSANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJ CUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGFuZHkuYmQucmVpZEBidC5jb20NCgkJU2VudDogV2VkbmVz ZGF5LCBBcHJpbCAyMiwgMjAwOSAxOjE0IFBNDQoJCVRvOiBsaXUuZ3VvbWFuQHp0ZS5jb20uY247 IG5laWwuMi5oYXJyaXNvbkBidC5jb20NCgkJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJU3ViamVj dDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgg cmVxdWlyZW1lbnRzDQoJCQ0KCQkNCgkJTGl1LA0KCQkgDQoJCUFsbG93IG1lIHRvIGp1bXAgaW4u IFlvdSBhcmUgYnJpbmdpbmcgdG9nZXRoZXIgdHdvIHRoaW5ncyB3aGljaCBhcmUgc2VwYXJhdGUg YW5kIGZvciB3aGljaCBBSVMvRkRJIGlzIG5vIGhlbHAuIE1haW50ZW5hbmNlIG9wZXJhdGlvbnMg YXJlIGNvbmNlcm5lZCB3aXRoIHR3byBzZXBhcmF0ZSB0aGluZ3MuDQoJCSANCgkJMSkgIElkZW50 aWZ5aW5nIGZhdWx0cyBpbiBlcXVpcG1lbnQsIGxpbmUgcGxhbnQsIGFuZCBvdGhlciBzeXN0ZW1z IChlZyBtaXNjb25maWd1cmF0aW9ucykgYW5kIGZpeGluZyB0aGVtIChlcXVpcG1lbnQgbWFpbnRl bmFuY2UpLg0KCQkyKSAgSWRlbnRpZnlpbmcgdGhlIGhlYWx0aCBvZiBlbmQgdG8gZW5kIGNvbm5l Y3Rpb25zLCBlc3BlY2lhbGx5IHdoZW4gdGhleSBhcmUgZGlyZWN0bHkgc3VwcG9ydGluZyBjdXN0 b21lciBzZXJ2aWNlcyAoc2VydmljZSBtYWludGVuYW5jZSkuDQoJCSANCgkJVGhlIHByb2JsZW0g aXMgKm5vdCogYWJvdXQgYSBsYWNrIG9mIGFsYXJtIHN1cHByZXNzaW9uIGluIHRoZSBkYXRhIHBs YW5lIC0gdGhhdCBpbmZvcm1hdGlvbiBpcyByZWFkaWx5IGF2YWlsYWJsZS4gSWYsIGF0IGFuIGVu ZCBlcXVpcG1lbnQsIEkgaGF2ZSBhIGdvb2Qgc2VydmVyL3NlY3Rpb24gbGF5ZXIgYW5kIGEgbG9z cyBvZiBDQyBhdCB0aGUgY2xpZW50IGxheWVyLCBJICprbm93KiB0aGUgZmF1bHQgaXMgZWxzZXdo ZXJlIC0gSSBkb24ndCBuZWVkIEFJUy9GREkgdG8gdGVsbCBtZS4gKEluZGVlZCwgaWYgeW91IHRo aW5rIGFib3V0LCBpZiB0aGUgZmF1bHQgaXMgaW4gdGhlIGVuZCBlcXVpcG1lbnQsIGl0IGlzIHF1 aXRlIGxpa2VseSB0aGF0IHRoZSBmYXVsdCBtZWFucyBpdCBjYW5ub3QgcmVwb3J0IHRoZSB0cmFm ZmljIGxvc3MgdG8gdGhlIG1hbmFnZW1lbnQgc3lzdGVtISkNCgkJIA0KCQlUaGUgaXNzdWUgYXJp c2VzIGJlY2F1c2UgdGhlIHR3byBzaWRlcyBvZiBtYWludGVuYW5jZSB3YW50IGRpZmZlcmVudCB0 aGluZ3MuIFRoZSBmYXVsdCBmaXhpbmcgZ3V5cyB3YW50IHRvIGxvY2F0ZSB0aGUgZmF1bHQgYW5k IGRvbid0IHdhbnQgYW55IG90aGVyIGluZm9ybWF0aW9uLiBUaGUgc2VydmljZSBtYWludGVuYW5j ZSBndXlzIHdhbnQgdG8ga25vdyB3aGV0aGVyIHRoZWlyIGN1c3RvbWVyIHNlcnZpY2UgaXMgd29y a2luZy4NCgkJIA0KCQlUaGlzIGFyb3NlIGluIHRoZSBlYXJseSBkYXlzIG9mIFNPTkVUL1NESCwg d2hlbiB0aGUgb3BlcmF0aW9ucyBndXlzIGRlbWFuZGVkIHRoYXQgdGhlIGVxdWlwbWVudCBkaWQg Km5vdCogc3VwcHJlc3MgdGhlIHRyYWZmaWMgYWxhcm0gZXZlbiB3aGVuIEFJUyB3YXMgYmVpbmcg cmVjZWl2ZWQgYXMgdGhlIHNlcnZpY2UgZ3V5cyB3YW50IHRvIGtub3cgYWJvdXQgdGhlIGFsYXJt cy4gVGhlIG5vcm1hbCBwcmFjdGljZSBpcyBmb3IgdGhlIGVxdWlwbWVudCB0byByZXBvcnQgdGhl IGFsYXJtcyAqaW5jbHVkaW5nKiBBSVMgYW5kIHRoZW4gYSBmaWx0ZXIgaXMgYXBwbGllZCBpbiB0 aGUgbWFuYWdlbWVudCBzeXN0ZW0gdG8gc3VwcHJlc3MgYWxhcm1zIHRvIHRoZSBmYXVsdCBmaXhp bmcgZ3V5cy4gQXMgSSdtIGF3YXJlLCB0aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgdGVjaG5pcXVl cyBhcHBsaWVkIGZvciB0aGUgZmlsdGVyaW5nIGFsZ29yaXRobXMsIGVzcGVjaWFsbHkgd2hlbiB5 b3UgY29uc2lkZXIgbXVsdGlwbGUgY29uY3VycmVudCBmYXVsdHMgaW4gYSBuZXR3b3JrLCBob3dl dmVyLCB0aGUgZXhpc3RhbmNlIG9mIEFJUy9GREkgZG9lc24ndCBhZGQgYW55dGhpbmcgdG8gdGhl c2UgdGhhdCdzIG5vdCBhbHJlYWR5IGtub3duLiBJbiBmYWN0LCBJIGJlbGlldmUgc2ltcGxlIHRp bWUtc3RhbXAgY29ycmVsYXRpb24gaXMgb25lIG9mIHRoZSBtb3N0IHBvd2VyZnVsIGFuZCB3aWRl bHkgdXNlZCB0ZWNobmlxdWVzLiBBbmQgaWYgdGhlIGVxdWlwbWVudCBzdGFydHMgbWVzc2luZyB1 cCB0aGUgcmVwb3J0aW5nIG9mIGxvc3Mgb2YgQ0MgYmVjYXVzZSBpdCB3YWl0aW5nIGZvci9wZXJz aXN0ZW5jZSBjaGVja2luZyBBSVMvRkRJLCBpdCBjb3VsZCBlbmQgdXAgbWVzc2luZyB1cCBzaW1w bGUgdGltZS1zdGFtcCBjb3JyZWxhdGlvbiEgDQoJCSANCgkJSW4gcHJhY3RpY2UsIGl0IGlzIG9m dGVuIG5vdCBxdWl0ZSBhIHNpbXBsZSBhcyB0aGlzLCBhcyB0aGUgc2VydmljZSBndXlzIGxpa2Ug dG8gYmUgYWJsZSB0byAnbG9jYWxpc2UnIHRoZSBmYXVsdC4gSG93ZXZlciwgdW5kZXIgbW9zdCBj aXJjdW1zdGFuY2VzLCB0aGUgZmlsdGVyIGhhcyBhdXRvbWF0aWNhbGx5IGRvbmUgdGhpcy4gU28g bG9jYWxpc2F0aW9uIHlvdSBkZXNjcmliZSBpcyBvbmx5IHdoZW4gdGhlIGZpbHRlciBoYXNuJ3Qg d29ya2VkIGZvciBzb21lIHJlYXNvbi4NCgkJIA0KCQlCdXQgdGhlIGJvdHRvbSBsaW5lIGlzLCB3 aGF0ZXZlciBvcGVyYXRpb25zIHByb2Nlc3MgeW91IHdhbnQgdG8gdXNlLCBBSVMvRkRJIGRvZXNu J3QgYWRkIGFueXRoaW5nIG90aGVyIHRoYW4gY29tcGxleGl0eSBhbmQgZmF1bHQgbGlhYmlsaXR5 IHRvIHRoZSBlcXVpcG1lbnQuIFJlbWVtYmVyIEFJUyBnb2VzIGJhY2sgdG8gdGhlIFRETSB3b3Js ZCB3aGVyZSB5b3UgKmhhdmUgdG8gZmlsbCB0aGUgYml0IHN0cmVhbSB3aXRoIHNvbWV0aGluZyou DQoJCSANCgkJIA0KCQkgDQoJCUFuZHkNCgkJIA0KDQoJCUFuZHkgUmVpZCANCgkJQ2hpZWYgTmV0 d29yayBTZXJ2aWNlcyBTdHJhdGVnaXN0IA0KCQlCVCBJbm5vdmF0ZSANCgkJICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KCQlPZmZpY2U6ICs0NCAoMCkxMjc3IDMyMjAzOCANCgkJ TW9iaWxlOiArNDQgKDApNzkxNyAwMjU0NTEgDQoJCUZheCA6ICAgICAgICs0NCAoMCkxMjc3IDMy NDAxNSANCgkJRW1haWw6ICBhbmR5LmJkLnJlaWRAYnQuY29tIA0KDQoJCQ0KCQlCcml0aXNoIFRl bGVjb21tdW5pY2F0aW9ucyBwbGMNCgkJUmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3Ry ZWV0IExvbmRvbiBFQzFBIDdBSg0KCQlSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm8uIDE4MDAwMDAg DQoJCVRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIGZyb20gQnJp dGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNv bmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBj b3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9y bWF0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZWxlY3Ryb25p YyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHRlbGVwaG9uZSBvciBlbWFp bCAodG8gdGhlIG51bWJlcnMgb3IgYWRkcmVzcyBhYm92ZSkgaW1tZWRpYXRlbHkuDQoNCgkJQWN0 aXZpdHkgYW5kIHVzZSBvZiB0aGUgQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjIGVtYWls IHN5c3RlbSBpcyBtb25pdG9yZWQgdG8gc2VjdXJlIGl0cyBlZmZlY3RpdmUgb3BlcmF0aW9uIGFu ZCBmb3Igb3RoZXIgbGF3ZnVsIGJ1c2luZXNzIHB1cnBvc2VzLiBDb21tdW5pY2F0aW9ucyB1c2lu ZyB0aGlzIHN5c3RlbSB3aWxsIGFsc28gYmUgbW9uaXRvcmVkIGFuZCBtYXkgYmUgcmVjb3JkZWQg dG8gc2VjdXJlIGVmZmVjdGl2ZSBvcGVyYXRpb24gYW5kIGZvciBvdGhlciBsYXdmdWwgYnVzaW5l c3MgcHVycG9zZXMuDQoNCgkJIA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCgkJCUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpdS5ndW9tYW5AenRlLmNvbS5jbg0KCQkJU2Vu dDogMjIgQXByaWwgMjAwOSAwOToxNQ0KCQkJVG86IEhhcnJpc29uLE4sTmVpbCxDWE0gUg0KCQkJ Q2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCVN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KCQkJDQoJCQkNCg0K CQkJTmVpbDogDQoJCQkgIHRoYW5rIHlvdSBmb3Igd2FzdGluZyBtb3JlIHRpbWUgaW4gZGVzY3Jp YmxpbmcgdGhlIHByb2JsZW1zLiBidXQgSSB0aGluayBzb21lIG9mIHdoYXQgeW91IHNhaWQgaXMg bm8gcmVsYXRpb25zIHdpdGggb3VyIHByb2JsZW0uZm9yIG1lLCBtYXliZSBBSVMvRkRJIGZ1bmN0 aW9ucyBpcyBubyBzZW5zZSBpbiBjbC1wcyAsZWcuIElQLiBidXQgZm9yIENPLVBTIG5ldHdvcmtz LmlmIHRoZXJlIGlzIG5vIEFJUy9GREkgZnVuY3Rpb25zLCB3aGVuIHRoZXJlIGlzIGEgZGVmZWN0 cyBpbiBhIGdpdmVuIGxheWVyIG5ldHdvcmssIGl0IGNhbiBjYXVzZSBtdWx0aXBsZSBhbGFybSBl dmVudHMgdG8gYmUgcmFpc2VkLiBpdCBpcyBkaWZmY3VsdCAgZm9yIG9wZXJhdG9ycyB0byBsb2Nh dGUgYW5kIGRpYWdub3NlIHRoZSBmYXVsdHMuIA0KCQkJIHRob3VnaCBJIGNvbXBsZXRlbHkgYWdy ZWUgeW91IG9uICBhZGRpbmcgbmV3IHRoaW5ncyBhbmQgZnVuY3Rpb25zIHdpbGwgYnJpbmcgc29t ZSBjb21wbGV4aXR5IC4gYnV0IGlmIHdlIGhhdmUgbm8gZnVuY3Rpb25zLCBpdCBpcyBtb3JlIGNv bXBsZXggYW5kIGRpZmN1bHQgZm9yIG9wZXJhdG9ycyB0byBtYWludGVuY2UgYW5kIGFkbWluaXN0 cmF0b3IgdGhlIG5ldHdvcmsuIHNvIEkgdGhpbmsgZXZlcnkgbmV3IGZ1bmN0aW9ucyBhbmQgdGhp bmdzIG1heSBoYXZlIHBvc2l0aXZlIGFuZCBuZWdhdGl2ZSBlZmZlY3RzLiBidXQgd2Ugc2hvdWxk IGNvbnNpZGVyIGl0IHZlcnkgbXVjaCwgZG9uJ3QgZGVsZXRlIHNvbWUgZnVuY3Rpb25zIGF0IHJh bmRvbS4gDQoJCQkNCgkJCQ0KCQkJYmVzdCByZWdhcmRzIA0KCQkJbGl1IA0KCQkJDQoJCQkNCgkJ CQ0KPG5laWwuMi5oYXJyaXNvbkBidC5jb20+IA0KDQoyMDA5LTA0LTIxIDIwOjMwIA0KDQrmlLbk u7bkuroNCjxsaXUuZ3VvbWFuQHp0ZS5jb20uY24+LCA8ZGJydW5nYXJkQGF0dC5jb20+IA0K5oqE 6YCBDQo8bXBscy10cEBpZXRmLm9yZz4gDQrkuLvpopgNClJFOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cwkNCg0KCQkNCg0KDQoN Cg0KCQkJTGl1LCANCgkJCSAgDQoJCQlJZiBNUExTLVRQIGlzIGdvaW5nIHRvIGJlIHRha2VuIHNl cmlvdXNseSBhcyBhIHRyYW5zcG9ydCBuZXR3b3JrIChsaWtlIFNESC9TT05FVCkgdGhlbiB0aGUg MiBrZXkgTVVTVCBIQVZFIHJlcXVpcmVtZW50cyBhcmUgdGhlc2UuIA0KCQkJICANCgkJCTEgICAg UHJvdmlkZSBhIHRyYW5zcGFyZW50IGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwLi4ud2hpY2gg bWVhbnM6IA0KCQkJLSAgICBhbGwgY2xpZW50IGJpdHMgdHJlYXRlZCBlcXVhbGx5IA0KCQkJLSAg ICBjbGllbnQgYml0IG9yZGVyaW5nIHByZXNlcnZlZCANCgkJCS0gICAgbm8gYXR0ZW1wdCB0byBp bmZlciBjbGllbnQgc3ltYm9sIChpZSBzZXF1ZW5jZSBvZiBjbGllbnQgYml0cykgbWVhbmluZyBh bmQgbm8gYXR0ZW1wdCB0byBjaGFuZ2UgY2xpZW50IHN5bWJvbHMgDQoJCQktICAgIHRoZSB0cmFm ZmljIGJlaGF2aW91ciBvZiBjbGllbnQgWCBtdXN0IG5vdCBpbXBhY3QgdGhlIHBlcmZvcm1hbmNl IGV4cGVyaWVuY2VkIGJ5IGNsaWVudCBZIA0KCQkJICANCgkJCUEga2V5IGNvcm9sbGFyeSBvZiB0 aGUgYWJvdmUgaXMgdGhhdCBNUExTLVRQIG11c3Qgb25seSBzdXBwb3J0IHByb3BlciBjb25uZWN0 aW9ucyAoaWUgc2luZ2xlIHNvdXJjZSBjb25zdHJ1Y3RzKSANCgkJCSAgDQoJCQkgIA0KCQkJMiAg IFNpbmNlIE1QTFMtVFAgaXMgYSB0cmFuc3BvcnQgbmV0d29yayBpdCBpcyBub3QgYSB0b3Atb2Yt c3RhY2sgbmV0d29yayAoaWUgaXQgZG9lcyBub3Qgc3VwcG9ydCBkaXJlY3RseSBleHRlcm5hbCBt ZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucykuICBNUExTLVRQIHRoZXJlZm9yZSBkb2Vz IG5vdCByZXF1aXJlIGFuIEUtTk5JIHNwZWNpZmljYXRpb24uICBBIGtleSBjb3JvbGxhcnkgb2Yg dGhpcyBpcyB0aGF0IE1QTFMtVFAgd2lsbCBub3QgaGF2ZSBhbnkgcGVlciBpbnRlcndvcmtpbmcg cmVsYXRpb25zaGlwIHdpdGggYW55IG90aGVyIG5ldHdvcmsgbW9kZS90ZWNobm9sb2d5LiANCgkJ CSAgDQoJCQkgIA0KCQkJTm93IHdydCBPQU0gTVBMUy1UUCBpcyBhIGNvLXBzIG1vZGUgbmV0d29y ay4gIFlvdSBjb3VsZCBhcmd1ZSB0aGlzIHNob3VsZCBoYXZlIEZESS9BSVMuLi4uaG93ZXZlciwg dGhlIG1lcml0IG9mIHRoaXMgaXMgaGlnaGx5IHF1ZXN0aW9uYWJsZS4gIFdoZW4gSSBhbmQgY29s bGVhZ3VlcyBkaXNjdXNzZWQgd2hldGhlciBQQkItVEUgKGFsc28gYSBjby1wcyBtb2RlIG5ldHdv cmspIHNob3VsZCBoYXZlIEZESS9BSVMgd2UgY29uY2x1ZGVkIHRoYXQgb24gYmFsYW5jZSBpdCB3 YXMgbm90IGEgZ29vZCBpZGVhLi4uLi5hbmQgbm90ZSB0aGF0IGluaXRpYWxseSBJIHdhcyBpbiBm YXZvdXIgb2YgaGF2aW5nIEFJUywgYnV0IG15IGNvbGxlYWd1ZXMgcHJvdmlkZWQgc3Ryb25nIHRl Y2huaWNhbCBhcmd1bWVudHMgdGhhdCBjb252aW5jZWQgbWUgb3RoZXJ3aXNlLiANCgkJCSAgDQoJ CQlBSVMvRkRJIGlzIGhpc3RvcmljYWxseSBsaW5rZWQgdG8gdGhlIGVhcmx5IFBESCBjby1jcyBt b2RlIGxheWVyIG5ldHdvcmtzIHRoYXQgdXNlZCBUVEwgbG9naWMuICBXaGVuIHRoaXMgZGllZCBp dCBwdXQgb3V0IGEgKzVWIChhbGwgMXMpIHNpZ25hbCBieSBkZWZhdWx0LCBpZSBpdCByZXF1aXJl ZCBubyBjb25zY2lvdXMgZWZmb3J0IHRvIGdlbmVyYXRlIGl0Li4uLi50aGlzIGlzIGtleSBwb2lu dC4gIEZ1cnRoZXIsIGluIHRoZXNlIG5ldHdvcmtzIHRoZXJlIGlzIGEgZmFpcmx5IHN0YXRpYy9s b25nLWhvbGRpbmcgY2xpZW50IHNlcnZlciByZWxhdGlvbnNoaXAuICBDbGVhcmx5IHRoaXMgaXMg bm90IHRydWUgaW4gdGhlIGNsLXBzIG1vZGUgYW5kIGl0J3Mgd2h5IElFVEYgaGF2ZSBuZXZlciBz cGVjaWZpZWQgQUlTIGZvciBJUCBhbmQgaXRzIHdoeSBJRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0 byB0aHJvdy1vdXQgQUlTIGluIDgwMi4xYWcgZm9yIEV0aGVybmV0ICh0aG91Z2ggSVRVIGhhdmUg dW53aXNlbHkgSU1PIHJldGFpbmVkIGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0IGFueSBv cGVyYXRvciBwbGFubmluZyB0byB1c2UgRXRoZXJuZXQgZXF1aXBtZW50IHdvdWxkIGFsd2F5cyBs b29rIHRvIElFRUUgc3RkcyBhbmQgbm90IElUVSBvbmVzKS4gDQoJCQkgIA0KCQkJQUlTL0ZESSBh bmQgdGhlIGNvLXBzIG1vZGUgaXMgZGViYXRhYmxlLiAgQXMgSSBub3RlZCBhYm92ZSwgb24gYmFs YW5jZSB3ZSBjb25zaWRlcmVkIG5vdCBhIGdvb2QgaWRlYSBmb3IgUEJCLVRFIE9BTSBiZWNhdXNl IGl0IHJlcXVpcmVzIGEgY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0ZSBpdCAodW5saWtlIHRo ZSBjby1jcyBtb2RlKSBzbyB0aGVyZSBhcmUgbGlrZWx5IHRvIGJlIHNjYWxpbmcgcHJvYmxlbXMg YW5kIGl0cyBvbmUgbW9yZSB0aGluZyB0byBnbyB3cm9uZy4gDQoJCQkgIA0KCQkJWW91IHNob3Vs ZCBhbHNvIGhhdmUgc2VlbiBtZSBtYWtlIHRoZSBwb2ludCBtYW55IHRpbWVzIGluIHRoZSBwYXN0 IHRoYXQgdGhlIGFsd2F5cy1vbiBkZWZlY3QgZGV0ZWN0aW9uL2hhbmRsaW5nIE9BTSBuZWVkcyB0 byBiZSBhcyBzaW1wbGUvc3BhcnNlIGFzIHBvc3NpYmxlIHdpdGggYXMgbGl0dGxlIGNvbmZpZyBh cyBwb3NzaWJsZSBiZWNhdXNlIHdlIG5lZWQgc3VwZXIgcmVsaWFiaWxpdHkuLi4uLi5UQ00gZ29l cyBjb21wbGV0ZWx5IGFnYWluc3QgdGhlIGdyYWluIGhlcmUuICBBbHNvIG5vdGUgdGhhdCB0aGUg T0FNIHJlcXVpcmVkIGZvciBlYWNoIG9mIHRoZSAzIG5ldHdvcmsgbW9kZXMgaXMgbm90IHRoZSBz YW1lLCBkZXNwaXRlIHdoYXQgc29tZSBjbGFpbS4gDQoJCQkgIA0KCQkJcmVnYXJkcywgTmVpbCAN CgkJCSAgDQoJCQkNCgkJCQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCQkJ RnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgbGl1Lmd1b21hbkB6dGUuY29tLmNuDQoJCQlTZW50OiAyMSBB cHJpbCAyMDA5IDAyOjU5DQoJCQlUbzogQlJVTkdBUkQsIERFQk9SQUggQSwgQVRUTEFCUw0KCQkJ Q2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCVN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KCQkJDQoJCQkNCgkJ CURlYm9yYWg6IA0KCQkJbWF5YmUgd2hhdCB5b3Ugc2FpZCBpcyByaWdodC4gYnV0IEkgY2FuJ3Qg Y29tcGxldGVseSBhZ3JlZSB5b3VyIG9waW5pb25zLiBJTU8uIG1wbHMtdHAgaXMgcmVnYXJkIGFz IHRyYW5zcG9ydCBuZXR3b3JrIGxpa2UgU0RIL1NPTkVULiBzbyBpdCBzaG91bGQgaGF2ZSBBSVMv RkRJIGZ1Y3Rpb25zIGFzIFNESC9TT05FVC4gDQoJCQkNCgkJCWRvIHlvdSB0aGluayBzby4gDQoJ CQkNCgkJCWJlc3QgcmVnYXJkcyANCgkJCWxpdSANCgkJCQ0KCQkJDQoiQlJVTkdBUkQsIERFQk9S QUggQSwgQVRUTEFCUyIgPGRicnVuZ2FyZEBhdHQuY29tPiANCuWPkeS7tuS6ujogIG1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZyANCg0KMjAwOS0wNC0yMCAyMzo0NyANCg0KDQoNCuaUtuS7tuS6ug0K Ik1hYXJ0ZW4gVmlzc2VycyIgPG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPiwgPG5laWwuMi5o YXJyaXNvbkBidC5jb20+IA0K5oqE6YCBDQptcGxzLXRwQGlldGYub3JnIA0K5Li76aKYDQpSZTog W21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJl bWVudHMJDQoNCg0KCQkNCg0KDQoJCQkNCgkJCQ0KCQkJDQoJCQlJIGFncmVlIHdpdGggTmVpbCwg aXQgaXMgdmVyeSBxdWVzdGlvbmFibGUgdGhlIHZhbHVlIG9mIEFJUy9GREkgaW4gYQ0KCQkJcGFj a2V0IG5ldHdvcmstIGFueSBtb2RlLiBJdCBjYW4gcmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBh biBvcGVyYXRvcg0KCQkJb24gdGhlbXNlbHZlcyBzbyBldmVuIFkxNzMxIHJlY29tbWVuZHMgbm90 IHRvIGJsb2NrIGRhdGEgZnJhbWVzOg0KCQkJIkEgTUVQIGNhbiBkZWNpZGUgd2hldGhlciBpdCBi bG9ja3MgZGF0YSBmcmFtZXMgd2hlbiBpdCBkZXRlY3RzIGRBSVMuDQoJCQlUaGUgcHJpbmNpcGxl IHJlcXVpcmVtZW50DQoJCQl0aGF0IGluZmx1ZW5jZXMgdGhpcyBkZWNpc2lvbiBpcyB0aGF0IGRh dGEgZnJhbWVzIG91Z2h0IHRvIGJlIGZvcndhcmRlZA0KCQkJYXMgbXVjaCBhcyBwb3NzaWJsZSwg d2l0aG91dA0KCQkJdGhlIHBvc3NpYmlsaXR5IG9mIGZvcndhcmRpbmcgd3JvbmcgZGF0YSBmcmFt ZXMgZG93bnN0cmVhbS4iDQoJCQlUYWJsZSBJLjctMiBzaG93cyBmb3IgQUlTLCBub3QgdG8gYmxv Y2suDQoJCQkNCgkJCUFuZCBhcyBZMTczMSBzdGF0ZXMsIEFJUyBjYW4gb25seSBiZSB1c2VkIHVu ZGVyIHZlcnkgY29uc3RyYWluZWQNCgkJCWFyY2hpdGVjdHVyZXMgLSBpZiByZXF1aXJlZCBmb3Ig TVBMUy1UUCwgaXQgbmVlZHMgdG8gaGF2ZSB0aGUgc2FtZQ0KCQkJZ3VpZGFuY2UgYXMgaW4gWTE3 MzEsIGkuZS4gcG9pbnQtdG8tcG9pbnQgYW5kIHNlcnZlci9jbGllbnQgb25lLXRvLW9uZToNCgkJ CSJmb3IgYSBwb2ludC10by1wb2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSBz aW5nbGUgcGVlciBNRVAuDQoJCQlUaGVyZWZvcmUsIHRoZXJlDQoJCQlpcyBubyBhbWJpZ3VpdHkg cmVnYXJkaW5nIHRoZSBwZWVyIE1FUCBmb3Igd2hpY2ggaXQgc2hvdWxkIHN1cHByZXNzDQoJCQlh bGFybXMgd2hlbiBpdCByZWNlaXZlcyB0aGUNCgkJCUVUSC1BSVMgaW5mb3JtYXRpb24uIg0KCQkJ U28gc2hvdWxkIG9ubHkgYmUgd2l0aGluIG9uZSBkb21haW4gLSB0aGVuIG5vIG5lZWQuDQoJCQkN CgkJCURlYm9yYWgNCgkJCQ0KCQkJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJCUZyb206 IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9y Z10gT24NCgkJCUJlaGFsZiBPZiBNYWFydGVuIFZpc3NlcnMNCgkJCVNlbnQ6IE1vbmRheSwgQXBy aWwgMjAsIDIwMDkgMTA6MDUgQU0NCgkJCVRvOiBuZWlsLjIuaGFycmlzb25AYnQuY29tDQoJCQlD YzogbXBscy10cEBpZXRmLm9yZw0KCQkJU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCgkJCXJlcXVpcmVtZW50cw0KCQkJDQoJCQlO ZWlsLA0KCQkJDQoJCQk+IGJ1dCBBSVMvRkRJIGluIHRoZSBjbCBtb2RlPy4uLmRvIG1lIGEgZmF2 b3VyIQ0KCQkJDQoJCQlFdGhlcm5ldCBBSVMgaXMgaW5kZWVkIGEgcmVxdWlyZW1lbnQgYW5kIGEg bmVjZXNzaXR5LiBBbmQgeW91IHdpbGwgbm90DQoJCQliZQ0KCQkJYWJsZSB0byB1bmRlcnN0YW5k IHRoYXQgYXMgbG9uZyBhcyB5b3UgcmVmdXNlIHRvIGFjY2VwdCB0aGF0ICJjbC1tb2RlIg0KCQkJ aXMgYQ0KCQkJZm9yd2FyZGluZyBtb2RlIHdpdGhpbiBhICoqdHJhbnNwb3J0IGVudGl0eSoqLiBH LjgwMCBhbWVuZG1lbnQgMSBoYXMNCgkJCWZpbmFsbHkNCgkJCXJlaW50cm9kdWNlZCB0aGlzIHRy YW5zcG9ydCBlbnRpdHkgaW50byBHLjgwMC4gQmVzaWRlcyB0aGF0LCBpdCBhbHNvDQoJCQlpbnRy b2R1Y2VkIHRoZSAqKmRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24qKjoNCgkJCQ0KCQkJW0cuODAw IGFtMV0gIkEgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBpcyBhIHRyYW5zcG9ydCBlbnRpdHkg dGhhdA0KCQkJdHJhbnNmZXJzIGluZm9ybWF0aW9uIGJlbG9uZ2luZyB0byBtdWx0aXBsZSBjb21t dW5pY2F0aW9ucyBiZXR3ZWVuIHBvcnRzDQoJCQlhY3Jvc3MgYSBzdWJuZXR3b3JrLiA8Li4+IElu IGEgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBtZXNzYWdlDQoJCQljb250ZW50cw0KCQkJYXJl IGludGVycHJldGVkIHRvIGlkZW50aWZ5IChzZXRzIG9mKSBjb21tdW5pY2F0aW9ucyB3aGljaCBy ZWNlaXZlDQoJCQlkaWZmZXJlbnQNCgkJCXRyZWF0bWVudC4gIFRoZSBzZXRzIG9mIGNvbW11bmlj YXRpb25zIG1heSBiZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZQ0KCQkJZm9yd2FyZGluZyBpZGVudGlm aWVyIG9yIG90aGVyIGxheWVyIGluZm9ybWF0aW9uLiAgT3JkZXIgaXMgbm90DQoJCQluZWNlc3Nh cmlseQ0KCQkJcHJlc2VydmVkIGJldHdlZW4gbWVzc2FnZXMgYmVsb25naW5nIHRvIHNldHMgb2Yg Y29tbXVuaWNhdGlvbnMgcmVjZWl2aW5nDQoJCQlkaWZmZXJlbnQgdHJlYXRtZW50LiAgU2V0cyBv ZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgaWRlbnRpZmllZCBmb3INCgkJCXB1cnBvc2VzDQoJCQlz dWNoIGFzIHRyYWZmaWMgY29uZGl0aW9uaW5nIG9yIHByZXNlcnZpbmcgY29tbXVuaWNhdGlvbiBt ZXNzYWdlIG9yZGVyLiINCgkJCQ0KCQkJDQoJCQlFdGhlcm5ldCBWTEFOcyBhcmUgaW4gdGVybXMg b2YgRy44MDAgImRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb25zIi4NCgkJCUV0aGVybmV0DQoJCQlB SVMgcHJvdmlkZXMgQUlTIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc3VjaCAiZGlmZmVyZW50aWF0ZWQg Y29ubmVjdGlvbiIuDQoJCQlJZg0KCQkJeW91IGFwcGx5IHRoaXMgdG8gbXkgcHJvcG9zZWQgUFRO IGxheWVyIHN0YWNrLCB0aGVuIHRoZSBFVkMgbGF5ZXINCgkJCXRvcG9sb2d5DQoJCQl3aWxsIGNv bnNpc3RzIG9mIEVWQyBsaW5rcyBzdXBwb3J0ZWQgYnkgTVBMUy1UUCwgRXRoZXJuZXQsIFBCQi1U RSBhbmQNCgkJCVAtT1RODQoJCQlWUCB0cmFpbHMgaW5zaWRlIG1ldHJvIGFuZCBjb3JlIGRvbWFp bnMgaW50ZXJjb25uZWN0aW5nIEVWQyBtYXRyaWNlcy4NCgkJCVdoZW4NCgkJCW9uZSBvZiB0aG9z ZSBFVkMgbGlua3MgaXMgaW50ZXJydXB0ZWQsIGUuZy4gaW4gdGhlIGNvcmUgYmV0d2VlbiBtZXRy byAxDQoJCQlhbmQNCgkJCW1ldHJvIDQgKHNlZSBhdHRhY2hlZCBzbGlkZSksIHRoZW4gdGhlIEVW QyBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uDQoJCQl0aGF0IGlzDQoJCQlwcmVzZW50IG9uIHRo aXMgbGluayB3aWxsIGJlIGludGVycnVwdGVkLiBBdCB0aGUgRVZDIHN3aXRjaC9icmlkZ2Ugbm9k ZQ0KCQkJaW4NCgkJCW1ldHJvIDQgdGhpcyBpbnRlcnJ1cHRpb24gaXMgbm90aWNlZCBhbmQgRVZD LUFJUyBpcyBpbnNlcnRlZCBpbiB0aGUNCgkJCWRvd25zdHJlYW0gZGlyZWN0aW9uIHRvIHN1cHBy ZXNzIHRoZSBFVkMtTE9DIGFsYXJtcyBhdCBFVkMgZW5kcG9pbnRzIEQ0DQoJCQlhbmQNCgkJCUQ1 Lg0KCQkJDQoJCQlUaGUgRVZDLUFJUyAoaS5lLiBFdGhlcm5ldCBBSVMpIGZyYW1lIGhhcyBhIHJl c2VydmVkIG11bHRpY2FzdCBhZGRyZXNzLA0KCQkJd2hpY2ggZ3VhcmFudGVlcyB0aGF0IHRoZSBB SVMgaXMgYnJvYWRjYXN0IHRvIHRoZSBlbmRwb2ludHMgb2YgdGhlIEVWQy4NCgkJCQ0KCQkJSSBi ZWxpZXZlIHRoYXQgaXQgaXMgdGltZSBmb3IgeW91IHRvIGFkYXB0IHlvdXIgdmlldyBvbiBjbyBh bmQgY2wgbW9kZXMNCgkJCWFuZA0KCQkJcmVsYXRlIGl0IHRvIHRoZSBmb3J3YXJkaW5nIG1vZGUg KipJTlNJREUqKiBhIHRyYW5zcG9ydCBlbnRpdHkuIA0KCQkJDQoJCQlXaGF0IHdlIGtub3cgYXMg dGhlIGludGVybmV0IGlzIGVzc2VudGlhbGx5IGFuICJJUCBkaWZmZXJlbnRpYXRlZA0KCQkJY29u bmVjdGlvbiIgd2l0aCBhIGJpbGxpb24gb3IgbW9yZSBwb3J0cy4NCgkJCVdoYXQgd2Uga25vdyBh cyBhbiBJUCBWUE4gaXMgZXNzZW50aWFsbHkgYW4gIklQIGRpZmZlcmVudGlhdGVkDQoJCQljb25u ZWN0aW9uIg0KCQkJd2l0aCBlLmcuIG4gcG9ydHMgKG4gaW4gdGhlIHJhbmdlIG9mIGUuZy4gMiB0 byAxMDAwKS4NCgkJCVdoYXQgd2Uga25vdyBhcyBhbiBFdGhlcm5ldCBWTEFOIGlzIGVzc2VudGlh bGx5IGFuICJFdGhlcm5ldA0KCQkJZGlmZmVyZW50aWF0ZWQNCgkJCWNvbm5lY3Rpb24iIHdpdGgg biBwb3J0cyAobiBpbiB0aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEwMDApLg0KCQkJV2hhdCB3ZSBr bm93IGFzIGEgcDJwIE1QTFMgRS1MU1AgaXMgZXNzZW50aWFsbHkgYW4gIk1QTFMgZGlmZmVyZW50 aWF0ZWQNCgkJCWNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy4NCgkJCVdoYXQgd2Uga25vdyBhcyBh IHAycCBTREggVkMtbiBpcyBhICJTREggVkMtbiBjb25uZWN0aW9uIiB3aXRoIDIgcG9ydHMuDQoJ CQkNCgkJCVRyYW5zcG9ydCBuZXR3b3JrIE9BTSBhcHBsaWVzIHRvIHRyYW5zcG9ydCBlbnRpdGll cywgd2hpY2ggYXJlIChpbiB0ZXJtcw0KCQkJb2YNCgkJCUcuODAwIGFtMSkgY29ubmVjdGlvbnMg YW5kIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb25zLg0KCQkJDQoJCQlSZWdhcmRzLA0KCQkJTWFh cnRlbg0KCQkJDQoJCQktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCQkJRnJvbTogbmVpbC4y LmhhcnJpc29uQGJ0LmNvbSBbbWFpbHRvOm5laWwuMi5oYXJyaXNvbkBidC5jb21dIA0KCQkJU2Vu dDogdnJpamRhZyAxNyBhcHJpbCAyMDA5IDIyOjAwDQoJCQlUbzogSm9obi5FLkRyYWtlMkBib2Vp bmcuY29tOyBJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0Ow0KCQkJQWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb207IG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tDQoJCQlDYzogbXBs cy10cEBpZXRmLm9yZw0KCQkJU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCgkJCXJlcXVpcmVtZW50cw0KCQkJDQoJCQlKb2huLCAg VGhhbmtzIHRoaXMgaXMgYSBncmVhdCBwbGF0Zm9ybSB0byBleHBsYWluIHdoeSBPQU0gZm9yIHRo ZSAzDQoJCQluZXR3b3JrDQoJCQltb2RlcyBuZWVkcyB0byBiZSBkaWZmZXJlbnQuICBJIGFtIGdl dHRpbmcgYSB3ZWUgYml0IHRpcmVkIG9mIGZvbGtzDQoJCQl0cnlpbmcNCgkJCXRvIG1ha2UgYWxs IDMgbmV0d29yayBtb2RlcyBsb29rIGFsaWtlIChhbmQgdGhlbiwgZXZlbiB3b3JzZSwgaW50ZXJ3 b3JrDQoJCQl0aGVtDQoJCQlhcyBhcyBwZWVycy4uLmVzcCB3aGVuIG5vdCBub3QgdG9wLW9mLXN0 YWNrDQoJCQluZXR3b3Jrcy4uLkkgbWVhbiBob3cgc2lsbHkgY2FuIHdlIGdldD8pLiAgIEkgYW0g ZXZlbiBtb3JlIGZydXN0cmF0ZWQgYnkNCgkJCXRoZSBmYWN0IHRob3NlIHBlZGRsaW5nIHRoaXMg RlVEIG9ubHkgZXZlciBzZWVtIHRvIGNvbnNpZGVyIE9BTSBhbmQNCgkJCWZvcmdldA0KCQkJYWxs IG90aGVyIERQL0NQL01QIGNvbXBvbmVudHMgKGVzcCB0b3Atb2Ytc3RhY2sgbWVzc2FnZS9maWxl L3N0cmVhbQ0KCQkJYXBwbGljYXRpb24gYWRhcHRhdGlvbnMpLiAgSG93IHdyb25nIGNhbiB0aGlz IGdldCEgDQoJCQkNCgkJCUluIHRoZSBjbyBtb2RlcyBhICpjb25uZWN0aW9uKiBpcyBhIHZlcnkg c3BlY2lmaWMgYW5kICpjb25zdHJhaW5pbmcqDQoJCQljb25zdHJ1Y3QuLi4uLkkgYW0gYXNzdW1p bmcgaGVyZSB3ZSByZXNwZWN0IHRoZSBydWxlcyBvZiBhIGNvbm5lY3Rpb24NCgkJCShpZQ0KCQkJ c2luZ2xlIHNvdXJjZSkgdGhvdWdoIHNvbWUgZm9sa3MgZG9uJ3QgZXZlbiBib3RoZXIgdG8gcmVz cGVjdCB0aGlzLCBhbmQNCgkJCXRoaXMNCgkJCWlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBh bGwga25vdyB3aGF0IHByb2JsZW1zIG11bHRpcGxlLXNvdXJjZQ0KCQkJY29uc3RydWN0cyBjYW4g Y2F1c2UgKGZyb20gTERQL1BIUC4uLi5lcmdvIE1QTFMtVFApLg0KCQkJDQoJCQlXaGVuIHdlIGhh dmUgYSBjb25uZWN0aW9uIHRoaXMgcmVzdHJpY3RzICphbGwqIERQIChpZSB0cmFmZmljIGFuZCBP QU0pDQoJCQl0bw0KCQkJc3RheSB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgY29ubmVjdGlvbi4g IFdoaWNoIGlzIGZpbmUgdW5kZXINCgkJCWRlZmVjdC1mcmVlDQoJCQljb25kaXRpb25zLCBidXQg aWYgd2UgaGF2ZSBsZWFraW5nIHRyYWZmaWMgdGhlbiB0aGUgY29uc3RyYWluaW5nIG5hdHVyZQ0K CQkJb2YNCgkJCXRoZSBjb25uZWN0aW9uIGNvbnN0cnVjdCBpcyBicm9rZW4uICBJbiBhIG51dHNo ZWxsIHdoYXQgdGhpcyBtZWFucyBpcw0KCQkJdGhhdA0KCQkJT0FNIHRoYXQgaXMgb2YgYSByZXF1 ZXN0L3Jlc3BvbnNlIG5hdHVyZSBjYW5ub3QgYmUgdHJ1c3RlZCBpbiBjbyBtb2RlDQoJCQluZXR3 b3JrcyB1bmRlciBtaXNjb25uZWN0aXZpdHkgZGVmZWN0cy4uLi4uaW5kZWVkLCB3aHkgc2hvdWxk IGEgbGVha2luZw0KCQkJRFANCgkJCWhhdmUgYSBzeW1tZXRyaWMgZ28vcmV0dXJuIGRlZmVjdCBi ZWhhdmlvdXI/Li4uLnZlcnkgbGlrZWx5IGl0IHdvbid0Lg0KCQkJU28NCgkJCXdoaWxzdCByZXF1 ZXN0L3Jlc3BvbnNlIE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1vZGUgaXQgaXMgbm90IHJpZ2h0 IGZvcg0KCQkJdGhlDQoJCQljbyBtb2RlIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3QgY29u ZGl0aW9ucy4NCgkJCQ0KCQkJTW9yZSBnZW5lcmFsbHkgdGhlIDMgbW9kZXMgYXJlIGRpZmZlcmVu dCBhbmQgbm90IGp1c3QgaW4gT0FNDQoJCQlyZXF1aXJlbWVudHMuLi4uYnV0IEFJUy9GREkgaW4g dGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZvdXIhLi4uYXQgbGVhc3QNCgkJCUlFRUUgaGFkIHRo ZSBnb29kIHNlbnNlIHRvIGJpbiB0aGlzIGZvciBFdGhlcm5ldCBldmVuIHRob3VnaCBpdCByZW1h aW5zDQoJCQlpbg0KCQkJWS4xNzMxLiAgQW5kIHdoaWNoIGlzIHdoeSBJIG9mdGVuIHRyb3Qtb3V0 IHRoZSByYXRoZXIgc2lsbHkgKHRvIGhhdmUgdG8NCgkJCXNheQ0KCQkJdGhpcykgb2JzZXJ2YXRp b24gdGhhdCBpZiBJUCAoY2wgbW9kZSkgY291bGQgZG8gaXQgYWxsIHRoZW4gd2h5IGhhdmUNCgkJ CUlFVEYNCgkJCWZvdW5kIGl0IG5lY2Vzc2FyeSB0byBjcmVhdGUgTVBMUyAoY28tcHMpIGFuZCBH TVBMUyAoQ1AgZm9yIGNvLWNzKS4gIFRoZQ0KCQkJYW5zd2VyIGxpZXMgaW4gdGhlIHBoeXNpY3Mu Li5hbmQgRy44MDAgYXR0ZW1wdHMgdG8gZXhwbGFpbiB0aGF0DQoJCQlwaHlzaWNzLi4uLkcuODA1 IGRvZXMgbm90Lg0KCQkJDQoJCQlTbywgdGhlIDMgbW9kZXMgYXJlIGRpZmZlcmVudC4uLnBsZWFz ZSBhY2NlcHQvcmVqb2ljZSBpbiB0aGlzIGZhY3QgYXMNCgkJCXRoZXkNCgkJCWFsbCBvZmZlciBz b21ldGhpbmcgZGlmZmVyZW50L2ltcG9ydGFudC4gIEJ1dCBkbyBub3QgYmUgaG9vZHdpbmtlZCBi eQ0KCQkJdGhvc2UNCgkJCXdobyBwZWRkbGUgYSBzdG9yeSB0aGF0IHRoYXQgdHJpZXMgdG8gbWFr ZSB0aGUgT0FNIG9mIHRoZSAzIG1vZGVzIHRoZQ0KCQkJc2FtZS4gDQoJCQkNCgkJCXJlZ2FyZHMs IE5laWwgDQoJCQkNCgkJCT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJCT4gRnJvbTog bXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoJCQk+IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4gRQ0KCQkJPiBTZW50OiAxNyBBcHJpbCAy MDA5IDIwOjAyDQoJCQk+IFRvOiBCVVNJIElUQUxPOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFh cnRlbiBWaXNzZXJzDQoJCQk+IENjOiBtcGxzLXRwQGlldGYub3JnDQoJCQk+IFN1YmplY3Q6IFJl OiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCQkJ PiByZXF1aXJlbWVudHMNCgkJCT4gDQoJCQk+IEl0YWxvLA0KCQkJPiANCgkJCT4gQXMgZGVzY3Jp YmVkIGluIHRoZSBNUExTIFRQIE9BTSBSZXF1aXJlbWVudHMgSS1ELCB2aXJ0dWFsbHkgYWxsIG9m IHRoZQ0KCQkJDQoJCQk+IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJldHVybiBwYXRoLCBhbmQg aW4gdGhlIGFic2VuY2Ugb2YgYSByZXR1cm4gDQoJCQk+IHBhdGggdGhleSBhcmUgZGlzYWJsZWQu DQoJCQk+IA0KCQkJPiBBcyBkZXNjcmliZWQgaW4gRGF2aWQgU2luaWNyb3BlJ3MgbWVldGluZyBt aW51dGVzIA0KCQkJPiAoaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvbWlzYy9tcGxzLWludGVy b3AvYXR0YWNobWVudC93aWtpLw0KCQkJPiBtZWV0aW5nLW5vDQoJCQk+IHRlcy8yMDA4MTAxNS5t cGxzLWludGVyb3AtZHQtbm90ZXMuemlwKSwgaWYgSVAgYWRkcmVzc2luZyBpcyB1c2VkLCBhbiAN CgkJCT4gTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgZ2V0dGluZyBJUCBw YWNrZXRzIGZyb20gDQoJCQk+IGRlc3RpbmF0aW9uIHRvIHNvdXJjZTsgbmVpdGhlciB0aGUgbWlu dXRlcyBub3IgSSBzdGlwdWxhdGUgdGhhdCBhIA0KCQkJPiBjb250cm9sIHBsYW5lIG5lZWRzIHRv IGJlIHVzZWQgdG8gaW5zdGFudGlhdGUgdGhpcyBmb3J3YXJkaW5nLg0KCQkJPiANCgkJCT4gQXMg YW4gYXNpZGUsIHRoZSBpc3N1ZSBvZiByZXR1cm4gcGF0aCBmb3IgdW5pZGlyZWN0aW9uYWwgTFNQ cyBjb3VsZCBiZQ0KCQkJDQoJCQk+IGNoYXJhdGVyaXplZCBhcyB0aGUgZWxlcGhhbnQgaW4gdGhl IHJvb20uICBJbiB0aGUgTVBMUyBUUCBPQU0gDQoJCQk+IEZyYW1ld29yayBJLUQsIHVuaWNhc3Qg TFNQcyBhcmUgb25seSBtZW50aW9uZWQgdGhyZWUgdGltZXMgYW5kIHJldHVybiANCgkJCT4gcGF0 aHMgbm90IGF0IGFsbC4NCgkJCT4gDQoJCQk+IFRoYW5rcywNCgkJCT4gDQoJCQk+IEpvaG4NCgkJ CT4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCQkJPiA+IEZyb206IEJVU0kgSVRBTE8g W21haWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0XQ0KCQkJPiA+IFNlbnQ6IEZyaWRh eSwgQXByaWwgMTcsIDIwMDkgMTo1OSBBTQ0KCQkJPiA+IFRvOiBEcmFrZSwgSm9obiBFOyBBbGV4 YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzDQoJCQk+ID4gQ2M6IG1wbHMtdHBAaWV0 Zi5vcmcNCgkJCT4gPiBTdWJqZWN0OiBSRTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCB0cmFuc3BvcnQgcGF0aCANCgkJCT4gPiByZXF1aXJlbWVudHMNCgkJCT4gPiANCgkJCT4g PiBKb2huLA0KCQkJPiA+IA0KCQkJPiA+IEkgbWlnaHQgaGF2ZSBtaXNzZWQgdGhlIGFncmVlbWVu dCBvZiBNUExTLVRQIGJlaW5nIGNhcGFibGUgb2YgDQoJCQk+ID4gc2VuZGluZyByZXBsaWVzIHRv IE9BTSByZXF1ZXN0cyBzZW50IG9uIHVuaS1kaXJlY3Rpb25hbCBMU1BzLg0KCQkJPiA+IA0KCQkJ PiA+IFRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3QgYmVsb25nIHRvIHRoZSBmaXJzdCBzZXQgb2Yg cmVxdWlyZW1lbnRzIA0KCQkJPiA+IElUVS1UIGlzIGV4cGVjdGluZyB0byBiZSBtZXQgYnkgT2N0 b2Jlci4NCgkJCT4gPiANCgkJCT4gPiBIb3dldmVyLCBJIHRoaW5rIHRoaXMgaW4gYSBwb3RlbnRp YWwgaW50ZXJlc3RpbmcgYWRkaXRpb25hbCANCgkJCT4gPiByZXF1aXJlbWVudCB0byBiZSB0YWtl biBpbnRvIGFjY291bnQgKGF0IHdvcnN0IGluIGENCgkJCT4gc3Vic2VxdWVudCBwaGFzZSkuDQoJ CQk+ID4gDQoJCQk+ID4gSSB0aGluayB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgbmVlZHMgdG8gYmUg ZXZhbHVhdGVkIHZlcnN1cyBvdGhlciANCgkJCT4gPiBtb3JlIGltcG9ydGFudCByZXF1aXJlbWVu dHMgKGUuZy4gdGhlIHBvc3NpYmlsaXR5IHRvIHdvcmsgdy9vIElQIA0KCQkJPiA+IGZvcndhcmRp bmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8gY29udGludWUgdG8gbW9uaXRvciB0aGUgZGF0YSAN CgkJCT4gPiBwbGFuZSBhbHNvIGluIGNhc2Ugb2YgZmFpbHVyZXMgYWZmZWN0aW5nIHRoZSBjb250 cm9sIG9yIG1hbmFnZW1lbnQgDQoJCQk+ID4gcGxhbmUpLg0KCQkJPiA+IA0KCQkJPiA+IEkgYW0g b3BlbiB0byBkaXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdodCB0aW1lIGJl Y2F1c2UgDQoJCQk+ID4gSSB3aXNoIHRvIGF2b2lkIGRlbGF5aW5nIHRoZSBmaXJzdCBwaGFzZSBv ZiB0aGUgZGVzaWduIHNvbHV0aW9uLg0KCQkJPiA+IA0KCQkJPiA+IFRoYW5rcywgSXRhbG8NCgkJ CT4gPiANCgkJCT4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJCQk+ID4gPiBGcm9t OiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCgkJCT4gPiA+IFttYWlsdG86bXBscy10cC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4gRQ0KCQkJPiA+ID4gU2VudDog VGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDg6MDAgUE0NCgkJCT4gPiA+IFRvOiBBbGV4YW5kZXIg VmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzDQoJCQk+ID4gPiBDYzogbXBscy10cEBpZXRmLm9y Zw0KCQkJPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgdHJhbnNwb3J0IHBhdGggDQoJCQk+ID4gPiByZXF1aXJlbWVudHMNCgkJCT4gPiA+IA0KCQkJ PiA+ID4gQXQgdGhlIG1lZXRpbmcgbGFzdCBmYWxsIGF0IEp1bmlwZXIgaW4gTWFzc2FjaHVzZXR0 cywgSQ0KCQkJPiA+IHRoaW5rIGl0IHdhcw0KCQkJPiA+ID4gYWdyZWVkIHRoYXQgYW4gTVBMUyBU UCBuZXR3b3JrIG5lZWRzIHRvIGhhdmUgYSBmb3J3YXJkaW5nDQoJCQk+ID4gY2FwYWJpbGl0eQ0K CQkJPiA+ID4gZm9yIG1hbmFnZW1lbnQsIGNvbnRyb2wsIGFuZCBPQU0gcGFja2V0cyAoZS5nLiwg c2VuZGluZw0KCQkJPiA+IHJlcGxpZXMgdG8gT0FNDQoJCQk+ID4gPiByZXF1ZXN0cyBzZW50IG9u IHVuaS1kaXJlY3Rpb25hbCBMU1BzKSBldmVuIGlmIGl0IGRvZXMgbm90DQoJCQk+ID4gaGF2ZSBh biBJUA0KCQkJPiA+ID4gZm9yd2FyZGluZyBkYXRhIHBsYW5lLg0KCQkJPiA+ID4gDQoJCQk+ID4g PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJCQk+ID4gPiA+IEZyb206IEFsZXhhbmRl ciBWYWluc2h0ZWluDQoJCQk+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tXQ0KCQkJPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgOTo1NyBB TQ0KCQkJPiA+ID4gPiBUbzogTWFhcnRlbiBWaXNzZXJzDQoJCQk+ID4gPiA+IENjOiBtcGxzLXRw QGlldGYub3JnDQoJCQk+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCQkJPiA+ID4gPiByZXF1aXJlbWVudHMNCgkJ CT4gPiA+ID4gDQoJCQk+ID4gPiA+IE1hYXJ0ZW4sDQoJCQk+ID4gPiA+IEl0IHNlZW1zIHRoYXQg eW91J3ZlIGp1c3QgKGltcGxpY2l0bHkgYW5kLCBwcm9iYWJseSwNCgkJCT4gPiA+ID4gaW5hZHZl cnRlbnRseSkgc3RhdGVkIHRoZSBmb2xsb3dpbmc6DQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiAg ICAgICAgICAgICAgICAgIE1QTFMtVFAgT0FNIHdpbGwgbm90IGV2ZXIgc3VwcG9ydCBNSVAgbG9v cGJhY2sgZnVuY3Rpb24NCgkJCT4gPiAoYW5kIGZhdWx0DQoJCQk+ID4gPiA+IGxvY2FsaXphdGlv biB3aGljaCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uICkgZm9yDQoJCQk+ID4gdW5pZGlyZWN0aW9u YWwgUDJNUA0KCQkJPiA+ID4gPiBhbmQgUDJQIHBhdGhzLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ ID4gSWYgdGhpcyBzdGF0ZW1lbnQgaXMgY29ycmVjdCwgdGhpcyAoSU1ITyBhbmQgRldJVykNCgkJ CT4gcmFpc2VzIGEgdmFsaWQNCgkJCT4gPiA+ID4gcXVlc3Rpb246DQoJCQk+ID4gPiA+IA0KCQkJ PiA+ID4gPiAgICAgICAgICAgICAgICAgIElzIE1QTFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRp b24gZm9yIHRoZXNlDQoJCQk+IHR5cGVzIG9mIHRyYW5zcG9ydA0KCQkJPiA+ID4gPiBwYXRocz8N CgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IEZvciB0aGUgcmVmZXJlbmNlLCBJUC9NUExTIHByb3Zp ZGVzIHRoaXMga2luZCBvZg0KCQkJPiA+IGZ1bmN0aW9uYWxpdHkgdG9kYXkNCgkJCT4gPiA+ID4g Zm9yICh1bmlkaXJlY3Rpb25hbCAtIGJ1dCBpdCBkb2VzIG5vdCBrbm93IGFueSBvdGhlcg0KCQkJ PiA+IHR5cGUpIFAyUCBMU1BzDQoJCQk+ID4gPiA+IGFzIGRlc2NyaWJlZCBpbiBSRkMgNDM3OS4g QW5kIGl0cyBleHRlbnNpb24gdG8gUDJNUCBMU1BzIHNlZW1zIA0KCQkJPiA+ID4gPiBlYXN5Li4u DQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiAgDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBSZWdh cmRzLA0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gICAgICBTYXNoYQ0KCQkJPiA+ID4gPiANCgkJ CT4gPiA+ID4gDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoJCQk+ID4gPiA+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0KCQkJPiA+IE9uIEJlaGFsZg0KCQkJPiA+ ID4gPiBPZiBNYWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXQ0KCQkJ PiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzoyNCBQTQ0KCQkJPiA+ID4g PiBUbzogJ0FkcmlhbiBGYXJyZWwnDQoJCQk+ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQoJ CQk+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydCBwYXRoIA0KCQkJPiA+ID4gPiByZXF1aXJlbWVudHMNCgkJCT4gPiA+ID4gDQoJ CQk+ID4gPiA+IEFkcmlhbiwNCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4+IDxxdW90ZT4NCgkJ CT4gPiA+ID4gPj4gICAgICBUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNsdWRpbmcgTUVQcywg TUlQcyBhbmQNCgkJCT4gPiA+ID4gb3RoZXIgaW50ZXJuYWwNCgkJCT4gPiA+ID4gPj4gICAgICAg ZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZA0KCQkJPiA+ID4gPiBiaWRp cmVjdGlvbmFsIHRyYW5zcG9ydA0KCQkJPiA+ID4gPiA+PiAgICAgICBwYXRoIGF0IGVhY2ggKHN1 Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KCQkJPiA+ID4gPiA+PiAgICAg ICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZA0KCQkJPiA+ID4g PiBkaXJlY3Rpb25zIG9mIHRoYXQNCgkJCT4gPiA+ID4gPj4gICAgICAgdHJhbnNwb3J0IHBhdGgu DQoJCQk+ID4gPiA+ID4+IDxlbmQgcXVvdGU+DQoJCQk+ID4gPiA+ID4NCgkJCT4gPiA+ID4gPiBU aGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCgkJ CT4gPiA+IGlzLCB0aGVyZSBpcw0KCQkJPiA+ID4gPiA+ICpub3RoaW5nKiB0aGF0IGNhbiBiZSBv YnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mDQoJCQk+ID4gPiB2aWV3IHRoYXQNCgkJ CT4gPiA+ID4gPiByZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC4NCgkJ CT4gPiA+ID4gDQoJCQk+ID4gPiA+IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4g SXQgaXMgdmVyeSBtdWNoDQoJCQk+IG9ic2VydmFibGUgaWYNCgkJCT4gPiA+ID4gdGhpcyByZXF1 aXJlbWVudCBpcyBtZXQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZiB2aWV3Lg0KCQkJPiA+ID4g PiBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBMb29wYmFjayB3aGVuIHRo ZXJlIGlzIGEgDQoJCQk+ID4gPiA+IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBw YXRoLiBUaGUgTVBMUy1UUCBMQk0gcGFja2V0IA0KCQkJPiA+ID4gPiByZWNlaXZlZCBhdCBhIE1J UCBuZWVkcyB0byBiZSByZXR1cm5lZCAoYXMgTEJSDQoJCQk+ID4gPiA+IHBhY2tldCkgdG8gdGhl IG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhlIG90aGVyDQoJCQk+ID4gZGlyZWN0aW9u IG9mDQoJCQk+ID4gPiA+IHRoZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0 aC4gVGhpcyBvdGhlcg0KCQkJPiBkaXJlY3Rpb24NCgkJCT4gPiA+ID4gd291bGQgbm90IGJlIGF2 YWlsYWJsZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IA0KCQkJPiA+ ID4gPiBwYXRoLi4uIGFuZCB0aHVzIHRoZSBsb29wYmFjayB0ZXN0DQoJCQk+ID4gPiB3b3VsZCBm YWlsLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gU2ltaWxhcmx5LCB3aGVuIHdlIGhhdmUgdG8g YXBwbHkgVENNIE1FUHMgdG8gbW9uaXRvciBhDQoJCQk+ID4gc2VnbWVudCwgdGhlbg0KCQkJPiA+ ID4gPiB0aGlzIGlzIHBvc3NpYmxlIGluIGEgY28tcm91dGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRo DQoJCQk+IGJ1dCBub3QgaW4gYQ0KCQkJPiA+ID4gPiBhc3NvY2lhdGVkIGJpZGlyIHRyYW5zcG9y dCBwYXRoLiBJbiB0aGUgZmlyc3QgY2FzZSB0aGUgVENNIE1FUCANCgkJCT4gPiA+ID4gU291cmNl IGFuZCBTaW5rIGZ1bmN0aW9ucyBhcmUgY28tbG9jYXRlZCBhbmQgY2FuDQoJCQk+IGV4Y2hhbmdl IHdoYXQgaXMNCgkJCT4gPiA+ID4gY2FsbGVkICJyZW1vdGUgaW5mb3JtYXRpb24iIHdoaWNoIGlz IG5lY2Vzc2FyeSBmb3IgcGVyZm9ybWFuY2UgDQoJCQk+ID4gPiA+IG1vbml0b3JpbmcuDQoJCQk+ ID4gPiA+IEluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgVENNIE1FUCBTb3VyY2UgYW5kIFNpbmsgZnVu Y3Rpb25zDQoJCQk+ID4gYXJlIGluIGUuZy4gDQoJCQk+ID4gPiA+IGRpZmZlcmVudCBub2RlcyBp biB0aGUgbmV0d29yayBhbmQgVENNIHdvdWxkIG5vdCBiZSBhYmxlDQoJCQk+ID4gdG8gcHJvdmlk ZQ0KCQkJPiA+ID4gPiBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLg0KCQkJPiA+ID4gPiANCgkJCT4g PiA+ID4gPiBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBN RVBzLA0KCQkJPiA+ID4gTUlQcyBhbmQgb3RoZXINCgkJCT4gPiA+ID4gaW50ZXJuYWwNCgkJCT4g PiA+ID4gPiBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4gSXQg ZG9lcyBub3QNCgkJCT4gPiA+ID4gYWRkIHRvICJUaGUNCgkJCT4gPiA+ID4gPiBpbnRlcm1lZGlh dGUgbm9kZXMuIg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gWW91ciB1bmRlcnN0YW5kaW5nIGlz IG5vdCBjb3JyZWN0LiBUaGlzIHRleHQgbXVzdCBub3QgYmUNCgkJCT4gPiBkZWxldGVkIGF0DQoJ CQk+ID4gPiA+IGFsbC4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4gQWN0dWFsbHksIEkgYW0g cXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudA0KCQkJPiA+ID4gaW5zaXN0ZW5jZSBv biB0aGUNCgkJCT4gPiA+ID4gaW5jbHVzaW9uDQoJCQk+ID4gPiA+ID4gb2YgIlRhbmRlbSBDb25u ZWN0aW9uLiIgVGhlIGRlZmluaXRpb24gd2l0aGluIHRoZSBJVFUtVCBvZg0KCQkJPiA+ID4gPiB0 aGlzIHRlcm0NCgkJCT4gPiA+ID4gPiBpcw0KCQkJPiA+ID4gPiBwb29ybHkNCgkJCT4gPiA+ID4g PiBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlIG1vbml0b3Jpbmcgb2YgYSBwYXRoIHRoYXQg aXMNCgkJCT4gPiA+ID4gcGFyYWxsZWwgKGkuZS4NCgkJCT4gPiA+ID4gdGFuZGVtKQ0KCQkJPiA+ ID4gPiA+IHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24g b2YgVEMNCgkJCT4gPiA+ID4gc2VlbXMgdG8gYmUgYXQNCgkJCT4gPiA+ID4gdmFyaWFuY2UsDQoJ CQk+ID4gPiA+ID4gYW5kIHdvdWxkIGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQu DQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgeW91ciBp bnRlcnByZXRhdGlvbiBvZiB0YW5kZW0NCgkJCT4gPiBjb25uZWN0aW9uIGlzDQoJCQk+ID4gPiA+ IGRlc2NyaWJlZCBpbiBJVFUtVCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gImZyb20gdGhlDQoJCQk+ ID4gbW9uaXRvcmluZyBvZiBhDQoJCQk+ID4gPiA+IHBhdGggdGhhdCBpcyBwYXJhbGxlbCAoaS5l LiB0YW5kZW0pIHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgDQoJCQk+ID4gPiA+IG1vbml0b3JlZC4i Pw0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gVGhlcmUgaXMgYSAibmV0d29yayBjb25uZWN0aW9u IiBhbmQgdGhpcyBuZXR3b3JrDQoJCQk+ID4gY29ubmVjdGlvbiBpcyBhIHNldA0KCQkJPiA+ID4g PiBvZiBpbnRlcmNvbm5lY3RlZCAibGluayBjb25uZWN0aW9ucyIgYW5kICJtYXRyaXgNCgkJCT4g Y29ubmVjdGlvbnMiLiBBDQoJCQk+ID4gPiA+IHN1YnNldCBvZiB0aG9zZSBpbnRlcmNvbm5lY3Rl ZCBsaW5rIGNvbm5lY3Rpb25zIGFuZCBtYXRyaXggDQoJCQk+ID4gPiA+IGNvbm5lY3Rpb25zIGNh biBiZSBtb25pdG9yZWQgYW5kIGlzIHRoZW4gcmVmZXJyZWQgdG8gYXMNCgkJCT4gYSAidGFuZGVt DQoJCQk+ID4gPiA+IGNvbm5lY3Rpb24iLiBUaGVyZSBpcyBubyAicGF0aCB0aGF0IGlzIHBhcmFs bGVsIHRvIHRoZQ0KCQkJPiA+IGRhdGEgcGF0aCIuIA0KCQkJPiA+ID4gPiBUaGVyZSBpcyBvbmx5 IGFkZGl0aW9uYWwgT0FNIGluc2VydGVkIGluc2lkZSB0aGUgZGF0YQ0KCQkJPiBwYXRoIGJ5IHRo ZQ0KCQkJPiA+ID4gPiBUQ00gTUVQX1NvIGZ1bmN0aW9uIGFuZCB0aGlzIE9BTSBpcyBleHRyYWN0 ZWQgZnJvbSB0aGUNCgkJCT4gPiBkYXRhIHBhdGggYnkNCgkJCT4gPiA+ID4gdGhlIFRDTSBNRVBf U2sgZnVuY3Rpb24uDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBSZWdhcmRzLA0KCQkJPiA+ID4g PiBNYWFydGVuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCgkJCT4gPiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYu b3JnDQoJCQk+ID4gPiA+IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWRyaWFuIEZhcnJlbA0KCQkJPiA+ID4gPiBTZW50OiBkb25kZXJkYWcgMTYgYXByaWwg MjAwOSAxMTo1OQ0KCQkJPiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IGJlbmphbWlu Lm5pdmVuLWplbmtpbnNAYnQuY29tDQoJCQk+ID4gPiA+IENjOiBCVVNJIElUQUxPOyBtcGxzLXRw QGlldGYub3JnDQoJCQk+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCQkJPiA+ID4gPiByZXF1aXJlbWVudHMNCgkJ CT4gPiA+ID4gDQoJCQk+ID4gPiA+IEhpIFNhc2hhLA0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4g PiBVbmZvcnR1bmF0ZWx5IEkgY2Fubm90IGZ1bGx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQ6 DQoJCQk+ID4gPiA+ID4NCgkJCT4gPiA+ID4gPiA8cXVvdGU+DQoJCQk+ID4gPiA+ID4gICAgIEZy b20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZA0KCQkJPiA+ID4gYmlk aXJlY3Rpb25hbCBMU1BzDQoJCQk+ID4gPiA+ID4gICAgIGFyZSBhIHNwZWNpYWwgY2FzZSBvZiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCgkJCT4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0K CQkJPiA+ID4gPiA+DQoJCQk+ID4gPiA+ID4gVGhpcyBzdGF0ZW1lbnQgd291bGQgYmUgb2J2aW91 c2x5IGNvcnJlY3QsIHdlcmUgaXQgbm90IGZvcg0KCQkJPiA+ID4gPiBSZXF1aXJlbWVudA0KCQkJ PiA+ID4gPiA+IDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQNCgkJ CT4gPiA+ID4gDQoJCQk+ID4gPiA+IE9LLiBHb3QgaXQuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4g PiBCdXQgd2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cyBz ZWN0aW9uPw0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gSW4gZmFjdCwgd2hhdCBpcyB0aGlzIHJl cXVpcmVtZW50IGFjdHVhbGx5IHNheWluZz8NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4gPHF1 b3RlPg0KCQkJPiA+ID4gPiA+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5n IE1FUHMsIE1JUHMgYW5kDQoJCQk+ID4gPiBvdGhlciBpbnRlcm5hbA0KCQkJPiA+ID4gPiA+ICAg ICAgIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQNCgkJCT4gPiA+ID4g YmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCgkJCT4gPiA+ID4gPiAgICAgICBwYXRoIGF0IGVhY2gg KHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KCQkJPiA+ID4gPiA+ICAg ICAgIHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkDQoJCQk+ID4g PiA+IGRpcmVjdGlvbnMgb2YgdGhhdA0KCQkJPiA+ID4gPiA+ICAgICAgIHRyYW5zcG9ydCBwYXRo Lg0KCQkJPiA+ID4gPiA+IDxlbmQgcXVvdGU+DQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBUaGVy ZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQNCgkJCT4g PiBpcywgdGhlcmUgaXMNCgkJCT4gPiA+ID4gKm5vdGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVk IGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCgkJCT4gPiB2aWV3IHRoYXQNCgkJCT4gPiA+ID4g cmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuDQoJCQk+ID4gPiA+IA0K CQkJPiA+ID4gPiBUaGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0aGF0IHRoaXMgcmVxdWly ZW1lbnQgaXMgbWV0IGJ5IA0KCQkJPiA+ID4gPiBjb25maWd1cmluZyBzb21lIGRhdGEgcGxhbmUg ZGF0YWJhc2UgY29tcG9uZW50IHRocm91Z2ggdGhlIA0KCQkJPiA+ID4gPiBtYW5hZ2VtZW50IHBs YW5lLiBUaGUgZGF0YWJhc2UgY29tcG9uZW50IGlzIG5vdCB1c2VkDQoJCQk+IGZvciBhbnl0aGlu Zw0KCQkJPiA+ID4gPiBleGNlcHQgdG8gc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAiYXdh cmVuZXNzIi4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IEJlbiEgQ2FuIHdlIHBsZWFzZSB0cnkg dG8gcmV3cml0ZSB0aGlzIHJlcXVpcmVtZW50IGluIHRlcm1zIG9mIA0KCQkJPiA+ID4gPiBiZWhh dmlvcj8NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4gUGxlYXNlIG5vdGUgdGhhdCBSZXF1aXJl bWVudCAzNCBpcyB0aGUgT05MWSBpdGVtIGluIHRoZQ0KCQkJPiA+ID4gPiBsaXN0IHRoYXQgaXMN CgkJCT4gPiA+ID4gPiBzcGVjaWZpYyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4g KFRoZSBwYWlyaW5nDQoJCQk+ID4gPiA+IHJlcXVpcmVtZW50cw0KCQkJPiA+ID4gPiA+IGF0IGVu ZCBwb2ludHMgZm9yIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQoJCQk+ ID4gPiBwYXRocyBhcmUNCgkJCT4gPiA+ID4gPiBleGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhl eSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudA0KCQkJPiA+ID4gaXRlbXMgaW4gdGhlDQoJCQk+ID4g PiA+ID4gcmVxdWlyZW1lbnRzJyBsaXN0KS4NCgkJCT4gPiA+ID4gPiBJbiBvdGhlciB3b3Jkcywg d2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mDQoJCQk+IGNvLXJvdXRlZA0KCQkJ PiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBw bGFuZSBjb250ZW50Lg0KCQkJPiA+ID4gPiA+DQoJCQk+ID4gPiA+ID4gVGhlIHNvbWV3aGF0IHZh Z3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbCANCgkJCT4gPiA+ ID4gPiBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQg SFcNCgkJCT4gPiA+ID4gc3VwcG9ydCBvZiB0aGUNCgkJCT4gPiA+ID4gPiBwYWlyaW5nIGF3YXJl bmVzcyBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIgdG8gY29tcGx5IHdpdGggaXQuDQoJCQk+ID4g PiA+IA0KCQkJPiA+ID4gPiBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGlu Y2x1ZGluZyBNRVBzLA0KCQkJPiA+IE1JUHMgYW5kIG90aGVyDQoJCQk+ID4gPiA+IGludGVybmFs IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkiIHNob3VsZCBiZSBkZWxldGVkLiBJdA0KCQkJPiA+ IGRvZXMgbm90DQoJCQk+ID4gPiA+IGFkZCB0byAiVGhlIGludGVybWVkaWF0ZSBub2Rlcy4iDQoJ CQk+ID4gPiA+IA0KCQkJPiA+ID4gPiA+IFRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQg aW5jcmVhc2VzIHRoaXMgc3VzcGljaW9uOg0KCQkJPiA+ID4gPiA+DQoJCQk+ID4gPiA+ID4gPHF1 b3RlPg0KCQkJPiA+ID4gPiA+ICAgVGFuZGVtIENvbm5lY3Rpb246IEEgdGFuZGVtIGNvbm5lY3Rp b24gaXMgYW4NCgkJCT4gPiBhcmJpdHJhcnkgcGFydCBvZiBhDQoJCQk+ID4gPiA+ID4gICB0cmFu c3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pDQoJCQk+ID4gPiA+IGlu ZGVwZW5kZW50bHkgZnJvbSB0aGUNCgkJCT4gPiA+ID4gPiAgIGVuZC10by1lbmQgbW9uaXRvcmlu ZyAoT0FNKS4gIEl0IG1heSBiZSBhIG1vbml0b3JlZA0KCQkJPiA+IHNlZ21lbnQgb3IgYQ0KCQkJ PiA+ID4gPiA+ICAgbW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0 IHBhdGguICANCgkJCT4gPiBUaGUgdGFuZGVtDQoJCQk+ID4gPiA+ID4gICBjb25uZWN0aW9uIG1h eSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRpbmcgZW5naW5lKHMpIG9mDQoJCQk+ID4gPiA+IHRo ZSBub2RlKHMpDQoJCQk+ID4gPiA+ID4gICBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVudCBv ciBjb25jYXRlbmF0ZWQgc2VnbWVudC4NCgkJCT4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KCQkJPiA+ ID4gPiANCgkJCT4gPiA+ID4gQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMg cGVyc2lzdGVudA0KCQkJPiA+IGluc2lzdGVuY2Ugb24gdGhlDQoJCQk+ID4gPiA+IGluY2x1c2lv biBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3aXRoaW4NCgkJCT4gPiB0 aGUgSVRVLVQgb2YNCgkJCT4gPiA+ID4gdGhpcyB0ZXJtIGlzIHBvb3JseSBzcGVjaWZpZWQgYW5k IGNvbWVzIGZyb20gdGhlDQoJCQk+IG1vbml0b3Jpbmcgb2YgYQ0KCQkJPiA+ID4gPiBwYXRoIHRo YXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIA0KCQkJ PiA+ID4gPiBtb25pdG9yZWQuIFRoaXMgZGVmaW5pdGlvbiBvZiBUQyBzZWVtcyB0byBiZSBhdCB2 YXJpYW5jZSwNCgkJCT4gPiBhbmQgd291bGQNCgkJCT4gPiA+ID4gYmUgaWYgdGhlIEFDSCB3YXMg YWN0dWFsbHkgaW4gYmFuZC4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4gRG9lc24ndCAiZm9y d2FyZGluZyBlbmdpbmUiIHNvdW5kIGxpa2UgaGFyZHdhcmUgdG8geW91Pw0KCQkJPiA+ID4gPiAN CgkJCT4gPiA+ID4gWWVzLCBidXQgc28gd2hhdD8NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4g SU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBuZWl0aGVyIHRoZSBNUExTLVRQDQoJCQk+ID4g PiBSZXF1aXJlbWVudHMgZHJhZnQNCgkJCT4gPiA+ID4gPiBub3IgdGhlIE1QTFMtVFAgT0FNIHJl cXVpcmVtZW50cyBvbmUNCgkJCT4gPiA+ID4gPiANCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiANCgkJ CT4gPiANCgkJCT4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtbXBscy10cC1vYW0tcmVxdWlyZW1lbg0KCQkJPiA+ID4gPiA+IHRzLTAxLnR4dCkgY29udGFp biBhbnkgcmVxdWlyZW1lbnRzIGRlYWxpbmcgd2l0aCB0YW5kZW0NCgkJCT4gPiA+IGNvbm5lY3Rp b25zLg0KCQkJPiA+ID4gPiA+DQoJCQk+ID4gPiA+ID4gQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBh cmUgZGlzY3Vzc2VkIGluIHRoZSBNUExTLVRQIE9BTQ0KCQkJPiA+IEZyYW1ld29yaw0KCQkJPiA+ ID4gPiA+IGRyYWZ0DQoJCQk+ID4gPiA+IChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWZyDQoJCQk+ID4gPiA+IGFtZXdvcmstMDAudHh0 DQoJCQk+ID4gPiA+ICkuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBSaWdodC4NCgkJCT4gPiA+ ID4gTGV0J3MganVzdCBnZXQgcmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nIGFs bA0KCQkJPiB0aGUgSS1Ecw0KCQkJPiA+ID4gPiBpbnRvIGxpbmUuDQoJCQk+ID4gPiA+IA0KCQkJ PiA+ID4gPiA+IFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhhdCBzb21lIGNsYXJpdHkgcmVn YXJkaW5nDQoJCQk+ID4gPiBjby1yb3V0ZWQgdnMuDQoJCQk+ID4gPiA+ID4gYXNzb2NpYXRlZA0K CQkJPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMgaXMgc3RpbGwgcmVxdWlyZWQuIE9uZSB3 YXkgdG8gcHJvdmlkZQ0KCQkJPiA+ID4gPiB0aGF0IGNvdWxkDQoJCQk+ID4gPiA+ID4gYmUgYnkg ZXhwbGljaXRseSBsaW1pdGluZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYw0KCQkJPiA+ID4g ZnVuY3Rpb25hbGl0eS4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IEFncmVlZC4NCgkJCT4gPiA+ ID4gDQoJCQk+ID4gPiA+IEFkcmlhbg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gDQoJCQk+ID4g PiA+IA0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KCQkJPiA+ID4gPiBGcm9tOiBBZHJpYW4gRmFycmVsIFthZHJpYW5Ab2xk ZG9nLmNvLnVrXQ0KCQkJPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMTI6 MTMgQU0NCgkJCT4gPiA+ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBC VVNJIElUQUxPDQoJCQk+ID4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQoJCQk+ID4gPiA+IFN1 YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBw YXRoIA0KCQkJPiA+ID4gPiByZXF1aXJlbWVudHMNCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IEhp IFNhc2hhLA0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gTm90IHJlYWxseSBzdXJlIHdoZXRoZXIg eW91IGFyZSBtaXNyZXByZXNlbnRpbmcgYW55b25lLCBidXQuLi4NCgkJCT4gPiA+ID4gDQoJCQk+ ID4gPiA+ID4gMS4gTXkgcmVhZGluZyBvZiAgb25lIG9mIEJlbidzICBtZXNzYWdlcyBpcyB0aGF0 IGFzc29jaWF0ZWQgDQoJCQk+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyBhcmUgdGhlIG9u bHkgdHlwZXMgb2YgcGF0aHMgdGhhdCBjYW4gYmUNCgkJCT4gPiA+ID4gY3JlYXRlZCBpbg0KCQkJ PiA+ID4gPiA+IHRoZSBleGlzdGluZyBuZXR3b3JrczsgInRydWUiIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIHBhdGhzDQoJCQk+ID4gPiA+IHdpbGwgaGF2ZQ0KCQkJPiA+ID4gPiA+IHRvIHdhaXQg dW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgYmVjb21lcyBhdmFpbGFibGUuDQoJCQk+ID4g PiA+IA0KCQkJPiA+ID4gPiBUaGlzIGlzIGNsZWFybHkgbm9uc2Vuc2UhDQoJCQk+ID4gPiA+IEZy b20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZA0KCQkJPiA+IGJpZGly ZWN0aW9uYWwgTFNQcyBhcmUNCgkJCT4gPiA+ID4gYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIExTUHMuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBJZiB5b3UgY2Fu IHNldCB1cCB0d28gdW5pZGlyZWN0aW9uYWwgTFNQcyAoZS5nLiB1c2luZyB0aGUNCgkJCT4gPiBt YW5hZ2VtZW50DQoJCQk+ID4gPiA+IHBsYW5lKSB5b3UgY2FuIHN1cmVseSBzZXQgdXAgYSBjby1y b3V0ZWQNCgkJCT4gPiA+IGJpZGlyZWN0aW9uYWwgTFNQLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ ID4gVGhlcmUgYXJlIHNoaXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkDQoJ CQk+IGJpZGlyZWN0aW9uYWwNCgkJCT4gPiA+ID4gTFNQcyB1c2luZyB0aGUgY29udHJvbCBwbGFu ZS4gVGhlc2UgZWl0aGVyIHVzZSB0aGUgR01QTFMNCgkJCT4gPiAod2hpY2ggaXMNCgkJCT4gPiA+ ID4gY2xlYW5lcikgb3Igbm9uLXN0YW5kYXJkIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyAod2hpY2gg aXMNCgkJCT4gPiBtZXNzeSBidXQNCgkJCT4gPiA+ID4gZnVuY3Rpb25hbCkuDQoJCQk+ID4gPiA+ IA0KCQkJPiA+ID4gPiBCdXQgKG9mIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29u dHJvbCBwbGFuZQ0KCQkJPiA+IHNvbHV0aW9ucyBoYXZlDQoJCQk+ID4gPiA+IG5vdGhpbmcgdG8g ZG8gd2l0aCBhdmFpbGFiaWxpdHkgb2YgZXF1aXBtZW50IGFzIHRoZXkgDQoJCQk+IGFyZSBzb2Z0 d2FyZQ0KCQkJPiA+ID4gPiBzb2x1dGlvbnMuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiA+IDIu IE15IHJlYWRpbmcgb2Ygb25lIG9mIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWwN CgkJCT4gPiA+ID4gZHJpdmVyIGZvcg0KCQkJPiA+ID4gPiA+IGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcgDQoJCQk+ID4gPiA+ID4g dHJhbnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFuIGFueSBzcGVjaWZpYyBiZW5lZml0Lg0KCQkJ PiA+ID4gPiANCgkJCT4gPiA+ID4gSXNuJ3QgdGhhdCB0aGUgY2FzZSB3aXRoIDc1JSBvZiB0aGUg TVBMUy1UUCByZXF1aXJlbWVudHM/DQoJCQk+ID4gPiA+IFdoaWNoIGlzIG5vdCB0byBzYXkgaXQg aXMgYSBiYWQgdGhpbmcuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBBIGxhcmdlIGRyaXZlciBm b3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNrZXQgbmV0d29yaw0KCQkJPiA+IHRoZSBsb29r LA0KCQkJPiA+ID4gPiBmZWVsLCBhbmQgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSAi bGVnYWN5Ig0KCQkJPiA+ID4gPiB0cmFuc3BvcnQgbmV0d29yay4NCgkJCT4gPiA+ID4gDQoJCQk+ ID4gPiA+ID4gQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRo YXQ6DQoJCQk+ID4gPiA+ID4gKiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlLCBh dCBsZWFzdCBmb3IgdGhlIHRpbWUNCgkJCT4gPiA+ID4gPiAgICBiZWluZywgdGhlIG1vc3QgaW1w b3J0YW50IHR5cGUgb2YgYmlkaXJlY3Rpb25hbCBwYXRocyBpbg0KCQkJPiA+ID4gPiA+ICAgIE1Q TFMtVFANCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IEkgdGhpbmsgdGhhdCBpcyB3cm9uZyBib3Ro IGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5kDQoJCQk+ID4gZ2l2ZW4gdGhhdA0KCQkJPiA+ ID4gPiBvdGhlciB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9ucyB3aWxsIGJlDQoJ CQk+IG5lZWRlZCB0byByZWFjaA0KCQkJPiA+ID4gPiB0aGUgZnVsbCBmdW5jdGlvbiBsZXZlbCBv ZiBNUExTLVRQLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gPiAqIHRoZXkgaGFkIGEgZ29vZCBj aGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUgb2YNCgkJCT4gPiBiaWRpcmVjdGlvbmFsDQoJ CQk+ID4gPiA+ID4gICBwYXRocyBpbiAgcmVhbCBkZXBsb3ltZW50cy4NCgkJCT4gPiA+ID4gDQoJ CQk+ID4gPiA+IEkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBmb2xsb3dzIGZyb20uDQoJCQk+ID4gPiA+ IA0KCQkJPiA+ID4gPiBDaGVlcnMsDQoJCQk+ID4gPiA+IEFkcmlhbg0KCQkJPiA+ID4gPiANCgkJ CT4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CgkJCT4gPiA+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCgkJCT4gPiA+ID4gbXBscy10cEBpZXRm Lm9yZw0KCQkJPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMtdHANCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoJCQk+ID4gPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQoJ CQk+ID4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCT4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiANCgkJ CT4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJ CQk+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KCQkJPiA+ID4gbXBscy10cEBpZXRmLm9yZw0K CQkJPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoJ CQk+ID4gPiANCgkJCT4gPiANCgkJCT4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCgkJCT4gbXBscy10cCBtYWlsaW5nIGxpc3QNCgkJCT4gbXBscy10cEBp ZXRmLm9yZw0KCQkJPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMt dHANCgkJCT4gDQoJCQlfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCQkJbXBscy10cCBtYWlsaW5nIGxpc3QNCgkJCW1wbHMtdHBAaWV0Zi5vcmcNCgkJCWh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQkJDQoJCQkNCgkJ CS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoJCQlaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQoJCQlUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJCQlUaGlzIG1l c3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1T cGFtIHN5c3RlbS4NCgkJCQ0KCQkJDQoJCQkNCgkJCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJCQlaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xl bHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11 bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xv c2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoJCQlUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuDQoJCQlUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg0K ------_=_NextPart_001_01C9C34C.5F5BF353 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wMjgzMzMxMTAtMjIwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5UaGFua3MgdG8gYm90aCBBbmR5 IGFuZCBTYXNoYSANCmhlcmUuJm5ic3A7IEV4YWN0bHkgcmlnaHQgU2FzaGEuLi4uYW5kIHRoaXMg aXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSBPQU0gaXMgbm90IA0KdGhlIHNhbWUgZm9yIGFsbCAz IG1vZGVzLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BB TiBjbGFzcz0wMjgzMzMxMTAtMjIwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBj b2xvcj0jODAwMDAwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDI4MzMzMTEwLTIyMDQyMDA5PjxGT05UIA0KZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+SSBhbSBlc3BlY2lhbGx5IGRl bGlnaHRlZCB0byBzZWUgDQpBbmR5J3MgY29tbWVudHMgdGhhdCBhbXBsaWZ5IHdoeSB3ZSBkb24n dCB0aGluayBBSVMmbmJzcDtpcyBhIGdyZWF0IGlkZWEgDQpvcGVyYXRpb25hbGx5IGluIHBhY2tl dC1uZXR3b3Jrcy4mbmJzcDsmbmJzcDsgPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTAyODMzMzExMC0yMjA0MjAwOT48Rk9OVCANCmZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4g DQpjbGFzcz0wMjgzMzMxMTAtMjIwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29s b3I9IzgwMDAwMCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDI4MzMzMTEwLTIyMDQyMDA5PjxGT05UIA0KZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+cmVnYXJkcywgTmVpbDwvRk9O VD4mbmJzcDs8L1NQQU4+PFNQQU4gDQpjbGFzcz0wMjgzMzMxMTAtMjIwNDIwMDk+PEZPTlQgZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDI4MzMzMTEwLTIyMDQy MDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+Jm5i c3A7Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj48QlI+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0K c3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDog IzgwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRs b29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRh YkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IEFsZXhh bmRlciBWYWluc2h0ZWluIA0KICBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tXSA8QlI+PEI+U2VudDo8L0I+IDIyIEFwcmlsIDIwMDkgDQogIDExOjMwPEJSPjxCPlRvOjwv Qj4gUmVpZCxBQkQsQW5keSxDWE0gUjxCUj48Qj5DYzo8L0I+IG1wbHMtdHBAaWV0Zi5vcmc7IA0K ICBsaXUuZ3VvbWFuQHp0ZS5jb20uY247IEhhcnJpc29uLE4sTmVpbCxDWE0gUjxCUj48Qj5TdWJq ZWN0OjwvQj4gUkU6IFttcGxzLXRwXSANCiAgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoIHJlcXVpcmVtZW50czxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KICA8RElWPjwvRElW Pg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQog IGNsYXNzPTI0ODE1MjMxMC0yMjA0MjAwOT5BbmR5LDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz0yNDgx NTIzMTAtMjIwNDIwMDk+SSANCiAgY2Fubm90IGFncmVlIG1vcmUuPC9TUEFOPjwvRk9OVD48L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0K ICBjbGFzcz0yNDgxNTIzMTAtMjIwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz0yNDgxNTIzMTAtMjIwNDIwMDk+SW5kZWVkLCBpbiB0aGUgVERNIHdvcmxkIHlvdSBoYWQgdG8g ZmlsbCB0aGUgY2xpZW50IA0KICBiaXQgc3RyZWFtIHdpdGggc29tZXRoaW5nIHByZWRpY3RhYmxl IEFORCBkaXN0aW5ndWlzaGFibGUgZnJvbSB2YWxpZCBjbGllbnQgDQogIHRyYWZmaWMuPC9TUEFO PjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIGNsYXNzPTI0ODE1MjMxMC0yMjA0MjAwOT5JbiANCiAgdGhlIHBhY2tldCB3b3Js ZCwgbG9zcyBvZiBzZXJ2ZXIgY29ubmVjdGl2aXR5Jm5ic3A7bWVhbnMgdGhhdCB0aGUgY2xpZW50 IA0KICBhcHBsaWNhdGlvbiA8RU0+ZG9lcyBub3QgcmVjZWl2ZSBhbnkgcGFja2V0czwvRU0+LCBz byB0aGVyZSBpcyBub3RoaW5nIHRvIA0KICBtaXNpbnRlcnByZXQgYXMgY2xpZW50IHRyYWZmaWMu PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yNDgxNTIzMTAtMjIwNDIwMDk+SGVuY2Ugbm8gbmVl ZCB0byAiZmlsbCBpbiIgDQogIEFJUy9GREkuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yNDgx NTIzMTAtMjIwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yNDgxNTIzMTAt MjIwNDIwMDk+UmVnYXJkcyw8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI0ODE1MjMxMC0yMjA0 MjAwOT4mbmJzcDsmbmJzcDsmbmJzcDsgU2FzaGE8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI0 ODE1MjMxMC0yMjA0MjAwOT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI0ODE1MjMx MC0yMjA0MjAwOT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI0ODE1MjMxMC0yMjA0 MjAwOT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI0ODE1MjMxMC0yMjA0MjAwOT48 L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPjxCUj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAg c3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDog IzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWIGNsYXNzPU91 dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICAgIDxI UiB0YWJJbmRleD0tMT4NCiAgICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+ IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgICBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0Bp ZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIA0KICAgIDwvQj5hbmR5LmJkLnJlaWRAYnQuY29tPEJS PjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIEFwcmlsIDIyLCAyMDA5IDE6MTQgDQogICAgUE08QlI+ PEI+VG86PC9CPiBsaXUuZ3VvbWFuQHp0ZS5jb20uY247IG5laWwuMi5oYXJyaXNvbkBidC5jb208 QlI+PEI+Q2M6PC9CPiANCiAgICBtcGxzLXRwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBS ZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCANCiAgICB0cmFuc3BvcnQgcGF0 aCByZXF1aXJlbWVudHM8QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgICA8RElWPjwvRElWPg0KICAg IDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48 Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkxpdSw8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMw MjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29s b3I9IzAwMDBmZiBzaXplPTI+QWxsb3cgbWUgdG8ganVtcCBpbi4gWW91IGFyZSBicmluZ2luZyB0 b2dldGhlciB0d28gDQogICAgdGhpbmdzIHdoaWNoIGFyZSBzZXBhcmF0ZSBhbmQgZm9yIHdoaWNo IEFJUy9GREkgaXMgbm8gaGVscC4gTWFpbnRlbmFuY2UgDQogICAgb3BlcmF0aW9ucyBhcmUgY29u Y2VybmVkIHdpdGggdHdvIHNlcGFyYXRlIHRoaW5ncy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAg IDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48 Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0 MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXpl PTI+MSkmbmJzcDsgSWRlbnRpZnlpbmcgZmF1bHRzIGluIGVxdWlwbWVudCwgbGluZSBwbGFudCwg DQogICAgYW5kIG90aGVyIHN5c3RlbXMgKGVnIG1pc2NvbmZpZ3VyYXRpb25zKSBhbmQgZml4aW5n IHRoZW0gKGVxdWlwbWVudCANCiAgICBtYWludGVuYW5jZSkuPC9GT05UPjwvU1BBTj48L0RJVj4N CiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIw MDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4yKSZuYnNwOyBJ ZGVudGlmeWluZyB0aGUgaGVhbHRoIG9mIGVuZCB0byBlbmQgDQogICAgY29ubmVjdGlvbnMsIGVz cGVjaWFsbHkgd2hlbiB0aGV5IGFyZSBkaXJlY3RseSBzdXBwb3J0aW5nIGN1c3RvbWVyIHNlcnZp Y2VzIA0KICAgIChzZXJ2aWNlIG1haW50ZW5hbmNlKS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAg IDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48 Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0 MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXpl PTI+VGhlIHByb2JsZW0gaXMgKm5vdCogYWJvdXQgYSBsYWNrIG9mIGFsYXJtIHN1cHByZXNzaW9u IA0KICAgIGluIHRoZSBkYXRhIHBsYW5lIC0gdGhhdCBpbmZvcm1hdGlvbiBpcyByZWFkaWx5IGF2 YWlsYWJsZS4gSWYsIGF0IGFuIGVuZCANCiAgICBlcXVpcG1lbnQsIEkgaGF2ZSBhIGdvb2Qgc2Vy dmVyL3NlY3Rpb24gbGF5ZXIgYW5kIGEgbG9zcyBvZiBDQyBhdCB0aGUgY2xpZW50IA0KICAgIGxh eWVyLCBJICprbm93KiB0aGUgZmF1bHQgaXMgZWxzZXdoZXJlIC0gSSBkb24ndCBuZWVkIEFJUy9G REkgdG8gdGVsbCBtZS4gDQogICAgKEluZGVlZCwgaWYgeW91IHRoaW5rIGFib3V0LCBpZiB0aGUg ZmF1bHQgaXMgaW4gdGhlIGVuZCBlcXVpcG1lbnQsIGl0IGlzIA0KICAgIHF1aXRlIGxpa2VseSB0 aGF0IHRoZSBmYXVsdCBtZWFucyBpdCBjYW5ub3QgcmVwb3J0IHRoZSB0cmFmZmljIGxvc3MgdG8g dGhlIA0KICAgIG1hbmFnZW1lbnQgc3lzdGVtISk8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9O VCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAy MzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+ VGhlIGlzc3VlIGFyaXNlcyBiZWNhdXNlIHRoZSB0d28gc2lkZXMgb2YgbWFpbnRlbmFuY2UgDQog ICAgd2FudCBkaWZmZXJlbnQgdGhpbmdzLiBUaGUgZmF1bHQgZml4aW5nIGd1eXMgd2FudCB0byBs b2NhdGUgdGhlIGZhdWx0IGFuZCANCiAgICBkb24ndCB3YW50IGFueSBvdGhlciBpbmZvcm1hdGlv bi4gVGhlIHNlcnZpY2UgbWFpbnRlbmFuY2UgZ3V5cyB3YW50IHRvIGtub3cgDQogICAgd2hldGhl ciB0aGVpciBjdXN0b21lciBzZXJ2aWNlIGlzIHdvcmtpbmcuPC9GT05UPjwvU1BBTj48L0RJVj4N CiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIw MDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9T UEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPlRoaXMgYXJvc2UgaW4gdGhlIGVhcmx5IGRheXMgb2YgU09ORVQvU0RILCB3aGVuIHRo ZSANCiAgICBvcGVyYXRpb25zIGd1eXMgZGVtYW5kZWQgdGhhdCB0aGUgZXF1aXBtZW50IGRpZCAq bm90KiBzdXBwcmVzcyB0aGUgdHJhZmZpYyANCiAgICBhbGFybSBldmVuIHdoZW4gQUlTIHdhcyBi ZWluZyByZWNlaXZlZCBhcyB0aGUgc2VydmljZSBndXlzIHdhbnQgdG8ga25vdyANCiAgICBhYm91 dCB0aGUgYWxhcm1zLiBUaGUgbm9ybWFsIHByYWN0aWNlIGlzIGZvciB0aGUgZXF1aXBtZW50IHRv Jm5ic3A7cmVwb3J0IA0KICAgIHRoZSBhbGFybXMgKmluY2x1ZGluZyogQUlTIGFuZCB0aGVuIGEg ZmlsdGVyIGlzIGFwcGxpZWQgaW4gdGhlIG1hbmFnZW1lbnQgDQogICAgc3lzdGVtJm5ic3A7dG8g c3VwcHJlc3MgYWxhcm1zIHRvIHRoZSBmYXVsdCBmaXhpbmcgZ3V5cy4gQXMgSSdtIGF3YXJlLCB0 aGVyZSANCiAgICBhcmUgbWFueSBkaWZmZXJlbnQgdGVjaG5pcXVlcyBhcHBsaWVkIGZvciB0aGUg ZmlsdGVyaW5nIGFsZ29yaXRobXMsIA0KICAgIGVzcGVjaWFsbHkgd2hlbiB5b3UgY29uc2lkZXIg bXVsdGlwbGUgY29uY3VycmVudCBmYXVsdHMgaW4gYSBuZXR3b3JrLCANCiAgICBob3dldmVyLCB0 aGUgZXhpc3RhbmNlIG9mIEFJUy9GREkgZG9lc24ndCBhZGQgYW55dGhpbmcgdG8gdGhlc2UgdGhh dCdzIG5vdCANCiAgICBhbHJlYWR5IGtub3duLiBJbiBmYWN0LCBJIGJlbGlldmUgc2ltcGxlJm5i c3A7dGltZS1zdGFtcCBjb3JyZWxhdGlvbiBpcyBvbmUgDQogICAgb2YgdGhlIG1vc3QgcG93ZXJm dWwgYW5kIHdpZGVseSB1c2VkIHRlY2huaXF1ZXMuIEFuZCBpZiB0aGUgZXF1aXBtZW50IHN0YXJ0 cyANCiAgICBtZXNzaW5nIHVwIHRoZSByZXBvcnRpbmcgb2YgbG9zcyBvZiBDQyBiZWNhdXNlIGl0 IHdhaXRpbmcgZm9yL3BlcnNpc3RlbmNlIA0KICAgIGNoZWNraW5nJm5ic3A7QUlTL0ZESSwgaXQg Y291bGQgZW5kIHVwIG1lc3NpbmcgdXAgc2ltcGxlIHRpbWUtc3RhbXAgDQogICAgY29ycmVsYXRp b24hJm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBj b2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBm YWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkluIHByYWN0aWNlLCBpdCBpcyBv ZnRlbiBub3QgcXVpdGUgYSBzaW1wbGUgYXMgdGhpcywgYXMgDQogICAgdGhlIHNlcnZpY2UgZ3V5 cyBsaWtlIHRvIGJlIGFibGUgdG8gJ2xvY2FsaXNlJyB0aGUgZmF1bHQuIEhvd2V2ZXIsIHVuZGVy IA0KICAgIG1vc3QgY2lyY3Vtc3RhbmNlcywmbmJzcDt0aGUgZmlsdGVyIGhhcyBhdXRvbWF0aWNh bGx5IGRvbmUgdGhpcy4gDQogICAgU28mbmJzcDtsb2NhbGlzYXRpb24mbmJzcDt5b3UgZGVzY3Jp YmUgaXMgb25seSB3aGVuIHRoZSBmaWx0ZXIgaGFzbid0IHdvcmtlZCANCiAgICBmb3Igc29tZSBy ZWFzb24uPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9O VCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkJ1dCB0aGUgYm90dG9tIGxp bmUgaXMsIHdoYXRldmVyIG9wZXJhdGlvbnMgcHJvY2VzcyB5b3UgDQogICAgd2FudCB0byB1c2Us Jm5ic3A7QUlTL0ZESSBkb2Vzbid0IGFkZCBhbnl0aGluZyBvdGhlciB0aGFuIGNvbXBsZXhpdHkg YW5kIA0KICAgIGZhdWx0IGxpYWJpbGl0eSB0byB0aGUgZXF1aXBtZW50LiBSZW1lbWJlciZuYnNw O0FJUyBnb2VzIGJhY2sgdG8gdGhlIFRETSANCiAgICB3b3JsZCB3aGVyZSB5b3UgKmhhdmUgdG8g ZmlsbCB0aGUgYml0IHN0cmVhbSB3aXRoIA0KICAgIHNvbWV0aGluZyouPC9GT05UPjwvU1BBTj48 L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDkt MjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJp YWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N CiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIw MDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5BbmR5PC9GT05U PjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9ydGYgZm9y bWF0IC0tPg0KICAgIDxQPjxCPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jODA4MDgwIHNpemU9Mj5BbmR5IA0KICAgIFJlaWQ8L0ZPTlQ+PC9TUEFOPjwvQj4gPEJSPjxT UEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Q2hpZWYgDQogICAgTmV0d29y ayBTZXJ2aWNlcyBTdHJhdGVnaXN0PC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+ PEZPTlQgDQogICAgZmFjZT1BcmlhbCBzaXplPTI+QlQgSW5ub3ZhdGU8L0ZPTlQ+PC9TUEFOPiA8 QlI+PFNQQU4gbGFuZz1lbi11cz48VT48Rk9OVCANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IA0KICAgIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9VPjwvU1BB Tj4gDQogICAgPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+T2Zm aWNlOiArNDQgKDApMTI3NyANCiAgICAzMjIwMzg8L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4gbGFu Zz1lbi11cz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Nb2JpbGU6IA0KICAgICs0NCAoMCk3OTE3 IDAyNTQ1MTwvRk9OVD48L1NQQU4+IDxCUj48U1BBTiBsYW5nPWVuLWdiPjxGT05UIGZhY2U9QXJp YWwgDQogICAgc2l6ZT0yPkZheCZuYnNwOzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgKzQ0ICgwKTEyNzcgDQogICAgMzI0MDE1PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgDQogICAgZmFjZT1BcmlhbCBz aXplPTI+RW1haWw6Jm5ic3A7IGFuZHkuYmQucmVpZEBidC5jb208L0ZPTlQ+PC9TUEFOPiA8L1A+ DQogICAgPFA+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDgwODAg DQogICAgc2l6ZT0xPjwvRk9OVD48L1NQQU4+PEJSPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jODA4MDgwIA0KICAgIHNpemU9MT5Ccml0aXNoIFRlbGVjb21tdW5pY2F0 aW9ucyBwbGM8QlI+UmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgDQogICAgU3RyZWV0IExv bmRvbiBFQzFBIDdBSjxCUj5SZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm8uIDE4MDAwMDA8L0ZPTlQ+ IA0KICAgIDwvU1BBTj48QlI+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSM4MDgwODAgc2l6ZT0xPlRoaXMgDQogICAgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGlu Zm9ybWF0aW9uIGZyb20gQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjIA0KICAgIHdoaWNo IG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGlu dGVuZGVkIHRvIGJlIA0KICAgIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVu dGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIA0KICAgIGludGVuZGVkIHJlY2lw aWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24g b3IgDQogICAgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hp Yml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KICAgIHRoaXMgZWxlY3Ryb25pYyBtZXNzYWdl IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHRlbGVwaG9uZSBvciBlbWFpbCAodG8gDQog ICAgdGhlIG51bWJlcnMgb3IgYWRkcmVzcyBhYm92ZSkgaW1tZWRpYXRlbHkuPC9GT05UPjwvU1BB Tj48L1A+DQogICAgPFA+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4 MDgwODAgc2l6ZT0xPkFjdGl2aXR5IGFuZCB1c2UgDQogICAgb2YgdGhlIEJyaXRpc2ggVGVsZWNv bW11bmljYXRpb25zIHBsYyBlbWFpbCBzeXN0ZW0gaXMgbW9uaXRvcmVkIHRvIHNlY3VyZSANCiAg ICBpdHMgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBidXNpbmVzcyBw dXJwb3Nlcy4gDQogICAgQ29tbXVuaWNhdGlvbnMgdXNpbmcgdGhpcyBzeXN0ZW0gd2lsbCBhbHNv IGJlIG1vbml0b3JlZCBhbmQgbWF5IGJlIHJlY29yZGVkIA0KICAgIHRvIHNlY3VyZSBlZmZlY3Rp dmUgb3BlcmF0aW9uIGFuZCBmb3Igb3RoZXIgbGF3ZnVsIGJ1c2luZXNzIA0KICAgIHB1cnBvc2Vz LjwvRk9OVD48L1NQQU4+PC9QPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+PEJSPg0KICAgIDxCTE9D S1FVT1RFIGRpcj1sdHIgDQogICAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVG VDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4 Ij4NCiAgICAgIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9 bHRyIGFsaWduPWxlZnQ+DQogICAgICA8SFIgdGFiSW5kZXg9LTE+DQogICAgICA8Rk9OVCBmYWNl PVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAg ICAgIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgDQog ICAgICA8L0I+bGl1Lmd1b21hbkB6dGUuY29tLmNuPEJSPjxCPlNlbnQ6PC9CPiAyMiBBcHJpbCAy MDA5IA0KICAgICAgMDk6MTU8QlI+PEI+VG86PC9CPiBIYXJyaXNvbixOLE5laWwsQ1hNIFI8QlI+ PEI+Q2M6PC9CPiANCiAgICAgIG1wbHMtdHBAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJl OiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIA0KICAgICAgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogICAgICA8RElWPjwvRElWPjxC Uj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0zPk5laWw6PC9GT05UPiA8QlI+PEZPTlQgDQog ICAgICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0zPiZuYnNwOyB0aGFuayB5b3UgZm9yIHdhc3Rpbmcg bW9yZSB0aW1lIGluIA0KICAgICAgZGVzY3JpYmxpbmcgdGhlIHByb2JsZW1zLiBidXQgSSB0aGlu ayBzb21lIG9mIHdoYXQgeW91IHNhaWQgaXMgbm8gDQogICAgICByZWxhdGlvbnMgd2l0aCBvdXIg cHJvYmxlbS5mb3IgbWUsIG1heWJlIEFJUy9GREkgZnVuY3Rpb25zIGlzIG5vIHNlbnNlIGluIA0K ICAgICAgY2wtcHMgLGVnLiBJUC4gYnV0IGZvciBDTy1QUyBuZXR3b3Jrcy5pZiB0aGVyZSBpcyBu byBBSVMvRkRJIGZ1bmN0aW9ucywgDQogICAgICB3aGVuIHRoZXJlIGlzIGEgZGVmZWN0cyBpbiBh IGdpdmVuIGxheWVyIG5ldHdvcmssIGl0IGNhbiBjYXVzZSBtdWx0aXBsZSANCiAgICAgIGFsYXJt IGV2ZW50cyB0byBiZSByYWlzZWQuIGl0IGlzIGRpZmZjdWx0ICZuYnNwO2ZvciBvcGVyYXRvcnMg dG8gbG9jYXRlIA0KICAgICAgYW5kIGRpYWdub3NlIHRoZSBmYXVsdHMuPC9GT05UPiA8QlI+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgc2l6ZT0zPiZuYnNwO3Rob3VnaCBJIGNvbXBsZXRl bHkgYWdyZWUgeW91IG9uICZuYnNwO2FkZGluZyBuZXcgdGhpbmdzIGFuZCANCiAgICAgIGZ1bmN0 aW9ucyB3aWxsIGJyaW5nIHNvbWUgY29tcGxleGl0eSAuIGJ1dCBpZiB3ZSBoYXZlIG5vIGZ1bmN0 aW9ucywgaXQgaXMgDQogICAgICBtb3JlIGNvbXBsZXggYW5kIGRpZmN1bHQgZm9yIG9wZXJhdG9y cyB0byBtYWludGVuY2UgYW5kIGFkbWluaXN0cmF0b3IgdGhlIA0KICAgICAgbmV0d29yay4gc28g SSB0aGluayBldmVyeSBuZXcgZnVuY3Rpb25zIGFuZCB0aGluZ3MgbWF5IGhhdmUgcG9zaXRpdmUg YW5kIA0KICAgICAgbmVnYXRpdmUgZWZmZWN0cy4gYnV0IHdlIHNob3VsZCBjb25zaWRlciBpdCB2 ZXJ5IG11Y2gsIGRvbid0IGRlbGV0ZSBzb21lIA0KICAgICAgZnVuY3Rpb25zIGF0IHJhbmRvbS48 L0ZPTlQ+IDxCUj48QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTM+YmVzdCANCiAg ICAgIHJlZ2FyZHM8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0zPmxpdTwv Rk9OVD4gPEJSPjxCUj48QlI+DQogICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICAgICAgICA8 VEJPRFk+DQogICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgIDxURCB3aWR0aD0iMjYl Ij48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQogICAgICAgICAgICBzaXplPTE+PEI+Jmx0O25laWwu Mi5oYXJyaXNvbkBidC5jb20mZ3Q7PC9CPiA8L0ZPTlQ+DQogICAgICAgICAgICA8UD48Rk9OVCBm YWNlPXNhbnMtc2VyaWYgc2l6ZT0xPjIwMDktMDQtMjEgMjA6MzA8L0ZPTlQ+IDwvUD4NCiAgICAg ICAgICA8VEQgd2lkdGg9IjczJSI+DQogICAgICAgICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0K ICAgICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAg ICAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7mlLbku7bkuro8L0ZPTlQ+PC9ESVY+DQogICAgICAg ICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCiAgICAgICAgICAgICAgICAgIHNp emU9MT4mbHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0OywgDQogICAgICAgICAgICAgICAgICAm bHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9GT05UPiANCiAgICAgICAgICAgICAgPFRSIHZBbGln bj10b3A+DQogICAgICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICAgICAgPERJViBhbGln bj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuaKhOmAgTwvRk9OVD48L0RJVj4N CiAgICAgICAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgICAgICAg ICAgICAgc2l6ZT0xPiZsdDttcGxzLXRwQGlldGYub3JnJmd0OzwvRk9OVD4gDQogICAgICAgICAg ICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAg ICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7kuLvpopg8 L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTE+UkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIA0KICAgICAgICAgICAgICAgICAgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCiAgICAgICAgICAgIHJlcXVpcmVtZW50czwvRk9OVD48 L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj4NCiAgICAgICAgICAgIDxUQUJMRT4NCiAgICAg ICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAg ICAgICAgICA8VEQ+DQogICAgICAgICAgICAgICAgPFREPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFC TEU+PEJSPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjxCUj48QlI+PEZPTlQgDQogICAg ICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5MaXUsPC9GT05UPiA8 QlI+PEZPTlQgDQogICAgICBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29t aWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgICAgIHNpemU9Mj5JZiBNUExTLVRQIGlzIGdv aW5nIHRvIGJlIHRha2VuIHNlcmlvdXNseSBhcyBhIHRyYW5zcG9ydCBuZXR3b3JrIA0KICAgICAg KGxpa2UgU0RIL1NPTkVUKSB0aGVuIHRoZSAyIGtleSBNVVNUIEhBVkUgcmVxdWlyZW1lbnRzIGFy ZSB0aGVzZS48L0ZPTlQ+IA0KICAgICAgPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxC Uj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgICAgIGNvbG9yPSM4MDAwMDAgc2l6ZT0y PjEgJm5ic3A7ICZuYnNwO1Byb3ZpZGUgYSB0cmFuc3BhcmVudCBjbGllbnQvc2VydmVyIA0KICAg ICAgcmVsYXRpb25zaGlwLi4ud2hpY2ggbWVhbnM6PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29t aWMgU2FucyBNUyIgDQogICAgICBjb2xvcj0jODAwMDAwIHNpemU9Mj4tICZuYnNwOyAmbmJzcDth bGwgY2xpZW50IGJpdHMgdHJlYXRlZCBlcXVhbGx5PC9GT05UPiANCiAgICAgIDxCUj48Rk9OVCBm YWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj4tICZuYnNwOyAmbmJzcDtj bGllbnQgDQogICAgICBiaXQgb3JkZXJpbmcgcHJlc2VydmVkPC9GT05UPiA8QlI+PEZPTlQgZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgICAgIHNpemU9Mj4tICZuYnNwOyAm bmJzcDtubyBhdHRlbXB0IHRvIGluZmVyIGNsaWVudCBzeW1ib2wgKGllIHNlcXVlbmNlIG9mIA0K ICAgICAgY2xpZW50IGJpdHMpIG1lYW5pbmcgYW5kIG5vIGF0dGVtcHQgdG8gY2hhbmdlIGNsaWVu dCBzeW1ib2xzPC9GT05UPiANCiAgICAgIDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBj b2xvcj0jODAwMDAwIHNpemU9Mj4tICZuYnNwOyAmbmJzcDt0aGUgDQogICAgICB0cmFmZmljIGJl aGF2aW91ciBvZiBjbGllbnQgWCBtdXN0IG5vdCBpbXBhY3QgdGhlIHBlcmZvcm1hbmNlIGV4cGVy aWVuY2VkIA0KICAgICAgYnkgY2xpZW50IFk8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7 PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAw MDAwIHNpemU9Mj5BIGtleSBjb3JvbGxhcnkgb2YgdGhlIGFib3ZlIGlzIA0KICAgICAgdGhhdCBN UExTLVRQIG11c3Qgb25seSBzdXBwb3J0IHByb3BlciBjb25uZWN0aW9ucyAoaWUgc2luZ2xlIHNv dXJjZSANCiAgICAgIGNvbnN0cnVjdHMpPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwv Rk9OVD4gPEJSPjxGT05UIA0KICAgICAgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIGZh Y2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjIgDQogICAgICAmbmJzcDsg U2luY2UgTVBMUy1UUCBpcyBhIHRyYW5zcG9ydCBuZXR3b3JrIGl0IGlzIG5vdCBhIHRvcC1vZi1z dGFjayANCiAgICAgIG5ldHdvcmsgKGllIGl0IGRvZXMgbm90IHN1cHBvcnQgZGlyZWN0bHkgZXh0 ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSANCiAgICAgIGFwcGxpY2F0aW9ucykuICZuYnNwO01Q TFMtVFAgdGhlcmVmb3JlIGRvZXMgbm90IHJlcXVpcmUgYW4gRS1OTkkgDQogICAgICBzcGVjaWZp Y2F0aW9uLiAmbmJzcDtBIGtleSBjb3JvbGxhcnkgb2YgdGhpcyBpcyB0aGF0IE1QTFMtVFAgd2ls bCBub3QgaGF2ZSANCiAgICAgIGFueSBwZWVyIGludGVyd29ya2luZyByZWxhdGlvbnNoaXAgd2l0 aCBhbnkgb3RoZXIgbmV0d29yayANCiAgICAgIG1vZGUvdGVjaG5vbG9neS48L0ZPTlQ+IDxCUj48 Rk9OVCBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICBzaXplPTM+Jm5ic3A7 PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAg ICAgIHNpemU9Mj5Ob3cgd3J0IE9BTSBNUExTLVRQIGlzIGEgY28tcHMgbW9kZSBuZXR3b3JrLiAm bmJzcDtZb3UgY291bGQgYXJndWUgDQogICAgICB0aGlzIHNob3VsZCBoYXZlIEZESS9BSVMuLi4u aG93ZXZlciwgdGhlIG1lcml0IG9mIHRoaXMgaXMgaGlnaGx5IA0KICAgICAgcXVlc3Rpb25hYmxl LiAmbmJzcDtXaGVuIEkgYW5kIGNvbGxlYWd1ZXMgZGlzY3Vzc2VkIHdoZXRoZXIgUEJCLVRFIChh bHNvIGEgDQogICAgICBjby1wcyBtb2RlIG5ldHdvcmspIHNob3VsZCBoYXZlIEZESS9BSVMgd2Ug Y29uY2x1ZGVkIHRoYXQgb24gYmFsYW5jZSBpdCANCiAgICAgIHdhcyBub3QgYSBnb29kIGlkZWEu Li4uLmFuZCBub3RlIHRoYXQgaW5pdGlhbGx5IEkgd2FzIGluIGZhdm91ciBvZiBoYXZpbmcgDQog ICAgICBBSVMsIGJ1dCBteSBjb2xsZWFndWVzIHByb3ZpZGVkIHN0cm9uZyB0ZWNobmljYWwgYXJn dW1lbnRzIHRoYXQgY29udmluY2VkIA0KICAgICAgbWUgb3RoZXJ3aXNlLjwvRk9OVD4gPEJSPjxG T05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgIGZhY2U9IkNvbWljIFNh bnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPkFJUy9GREkgaXMgaGlzdG9yaWNhbGx5IGxpbmtl ZCANCiAgICAgIHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXllciBuZXR3b3JrcyB0aGF0 IHVzZWQgVFRMIGxvZ2ljLiAmbmJzcDtXaGVuIA0KICAgICAgdGhpcyBkaWVkIGl0IHB1dCBvdXQg YSArNVYgKGFsbCAxcykgc2lnbmFsIGJ5IGRlZmF1bHQsIGllIGl0IHJlcXVpcmVkIG5vIA0KICAg ICAgY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0ZSBpdC4uLi4udGhpcyBpcyBrZXkgcG9pbnQu ICZuYnNwO0Z1cnRoZXIsIGluIA0KICAgICAgdGhlc2UgbmV0d29ya3MgdGhlcmUgaXMgYSBmYWly bHkgc3RhdGljL2xvbmctaG9sZGluZyBjbGllbnQgc2VydmVyIA0KICAgICAgcmVsYXRpb25zaGlw LiAmbmJzcDtDbGVhcmx5IHRoaXMgaXMgbm90IHRydWUgaW4gdGhlIGNsLXBzIG1vZGUgYW5kIGl0 J3MgDQogICAgICB3aHkgSUVURiBoYXZlIG5ldmVyIHNwZWNpZmllZCBBSVMgZm9yIElQIGFuZCBp dHMgd2h5IElFRUUgaGFkIHRoZSBnb29kIA0KICAgICAgc2Vuc2UgdG8gdGhyb3ctb3V0IEFJUyBp biA4MDIuMWFnIGZvciBFdGhlcm5ldCAodGhvdWdoIElUVSBoYXZlIHVud2lzZWx5IA0KICAgICAg SU1PIHJldGFpbmVkIGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0IGFueSBvcGVyYXRvciBw bGFubmluZyB0byB1c2UgDQogICAgICBFdGhlcm5ldCBlcXVpcG1lbnQgd291bGQgYWx3YXlzIGxv b2sgdG8gSUVFRSBzdGRzIGFuZCBub3QgSVRVIA0KICAgICAgb25lcykuPC9GT05UPiA8QlI+PEZP TlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIA0KICAgICAgZmFjZT0iQ29taWMgU2Fu cyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+QUlTL0ZESSBhbmQgdGhlIGNvLXBzIG1vZGUgaXMg DQogICAgICBkZWJhdGFibGUuICZuYnNwO0FzIEkgbm90ZWQgYWJvdmUsIG9uIGJhbGFuY2Ugd2Ug Y29uc2lkZXJlZCBub3QgYSBnb29kIA0KICAgICAgaWRlYSBmb3IgUEJCLVRFIE9BTSBiZWNhdXNl IGl0IHJlcXVpcmVzIGEgY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0ZSBpdCANCiAgICAgICh1 bmxpa2UgdGhlIGNvLWNzIG1vZGUpIHNvIHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUgc2NhbGluZyBw cm9ibGVtcyBhbmQgaXRzIA0KICAgICAgb25lIG1vcmUgdGhpbmcgdG8gZ28gd3JvbmcuPC9GT05U PiA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gDQogICAgICA8QlI+PEZPTlQgZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+WW91IHNob3VsZCBhbHNvIGhhdmUg DQogICAgICBzZWVuIG1lIG1ha2UgdGhlIHBvaW50IG1hbnkgdGltZXMgaW4gdGhlIHBhc3QgdGhh dCB0aGUgYWx3YXlzLW9uIGRlZmVjdCANCiAgICAgIGRldGVjdGlvbi9oYW5kbGluZyBPQU0gbmVl ZHMgdG8gYmUgYXMgc2ltcGxlL3NwYXJzZSBhcyBwb3NzaWJsZSB3aXRoIGFzIA0KICAgICAgbGl0 dGxlIGNvbmZpZyBhcyBwb3NzaWJsZSBiZWNhdXNlIHdlIG5lZWQgc3VwZXIgcmVsaWFiaWxpdHku Li4uLi5UQ00gZ29lcyANCiAgICAgIGNvbXBsZXRlbHkgYWdhaW5zdCB0aGUgZ3JhaW4gaGVyZS4g Jm5ic3A7QWxzbyBub3RlIHRoYXQgdGhlIE9BTSByZXF1aXJlZCANCiAgICAgIGZvciBlYWNoIG9m IHRoZSAzIG5ldHdvcmsgbW9kZXMgaXMgbm90IHRoZSBzYW1lLCBkZXNwaXRlIHdoYXQgc29tZSAN CiAgICAgIGNsYWltLjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48 Rk9OVCANCiAgICAgIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPnJl Z2FyZHMsIE5laWw8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+ IDxCUj48QlI+DQogICAgICA8SFI+DQogICAgICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+ RnJvbTo8L0I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgICAgIFttYWlsdG86bXBscy10 cC1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgDQogICAgICA8L0I+bGl1Lmd1b21h bkB6dGUuY29tLmNuPEI+PEJSPlNlbnQ6PC9CPiAyMSBBcHJpbCAyMDA5IA0KICAgICAgMDI6NTk8 Qj48QlI+VG86PC9CPiBCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTPEI+PEJSPkNjOjwvQj4g DQogICAgICBtcGxzLXRwQGlldGYub3JnPEI+PEJSPlN1YmplY3Q6PC9CPiBSZTogW21wbHMtdHBd IEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCANCiAgICAgIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVt ZW50czwvRk9OVD48Rk9OVCBzaXplPTM+PEJSPjwvRk9OVD48QlI+PEZPTlQgDQogICAgICBzaXpl PTI+PFRUPjxCUj5EZWJvcmFoPC9UVD48L0ZPTlQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAg ICAgc2l6ZT0yPjo8L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48QlI+bWF5YmUgDQogICAgICB3aGF0IHlvdSBzYWlkIGlzIHJpZ2h0LiBidXQg SSBjYW4ndCBjb21wbGV0ZWx5IGFncmVlIHlvdXIgb3BpbmlvbnMuIElNTy4gDQogICAgICBtcGxz LXRwIGlzIHJlZ2FyZCBhcyB0cmFuc3BvcnQgbmV0d29yayBsaWtlIFNESC9TT05FVC4gc28gaXQg c2hvdWxkIGhhdmUgDQogICAgICBBSVMvRkRJIGZ1Y3Rpb25zIGFzIFNESC9TT05FVC48L0ZPTlQ+ PEZPTlQgc2l6ZT0zPiA8QlI+PC9GT05UPjxGT05UIA0KICAgICAgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj48QlI+ZG8geW91IHRoaW5rIHNvLjwvRk9OVD48Rk9OVCBzaXplPTM+IA0KICAgICAgPEJS PjwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5iZXN0IHJlZ2FyZHM8L0ZP TlQ+PEZPTlQgDQogICAgICBzaXplPTM+IDwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxCUj5saXUgPC9GT05UPjxGT05UIA0KICAgICAgc2l6ZT0zPjxCUj48QlI+PC9GT05UPg0K ICAgICAgPFRBQkxFIHdpZHRoPSIxMDAlIj4NCiAgICAgICAgPFRCT0RZPg0KICAgICAgICA8VFIg dkFsaWduPXRvcD4NCiAgICAgICAgICA8VEQgd2lkdGg9IjQyJSI+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9MT48Qj4iQlJVTkdBUkQsIERFQk9SQUggDQogICAgICAgICAgICBBLCBBVFRMQUJT IiAmbHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9CPiA8QlI+5Y+R5Lu25Lq6OiANCiAgICAgICAg ICAgICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzwvRk9OVD48Rk9OVCBzaXplPTM+IDwv Rk9OVD4NCiAgICAgICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+MjAwOS0w NC0yMCAyMzo0NzwvRk9OVD48Rk9OVCBzaXplPTM+IA0KICAgICAgICAgICAgPC9GT05UPjwvUD4N CiAgICAgICAgICA8VEQgd2lkdGg9IjU3JSI+PEJSPg0KICAgICAgICAgICAgPFRBQkxFIHdpZHRo PSIxMDAlIj4NCiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFIgdkFsaWdu PXRvcD4NCiAgICAgICAgICAgICAgICA8VEQgd2lkdGg9IjclIj4NCiAgICAgICAgICAgICAgICAg IDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7mlLbku7bkuro8 L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI5MiUiPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTE+Ik1hYXJ0ZW4gVmlzc2VycyIgDQogICAgICAgICAgICAgICAgICAm bHQ7bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20mZ3Q7LCANCiAgICAgICAgICAgICAgICAgICZs dDtuZWlsLjIuaGFycmlzb25AYnQuY29tJmd0OzwvRk9OVD48Rk9OVCBzaXplPTM+IDwvRk9OVD4N CiAgICAgICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgICAgICAgPFREPg0KICAg ICAgICAgICAgICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0xPuaKhOmAgTwvRk9OVD48L0RJVj4NCiAgICAgICAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1z YW5zLXNlcmlmIHNpemU9MT5tcGxzLXRwQGlldGYub3JnPC9GT05UPjxGT05UIA0KICAgICAgICAg ICAgICAgICAgc2l6ZT0zPiA8L0ZPTlQ+DQogICAgICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0K ICAgICAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7kuLvpopg8L0ZPTlQ+PC9ESVY+DQogICAgICAg ICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+UmU6IFttcGxzLXRwXSBB c3NvY2lhdGVkIA0KICAgICAgICAgICAgICAgICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0 aCANCiAgICAgICAgICAgIHJlcXVpcmVtZW50czwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48L1RB QkxFPjxCUj48QlI+DQogICAgICAgICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICAgICAgICAg ICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAg ICAgIDxURCB3aWR0aD0iNTAlIj4NCiAgICAgICAgICAgICAgICA8VEQgDQogICAgICB3aWR0aD0i NTAlIj48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48L1REPjwvVFI+PC9UQk9EWT48L1RB QkxFPjxCUj48Rk9OVCANCiAgICAgIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTI+ PFRUPjxCUj5JIGFncmVlIHdpdGggTmVpbCwgaXQgaXMgdmVyeSANCiAgICAgIHF1ZXN0aW9uYWJs ZSB0aGUgdmFsdWUgb2YgQUlTL0ZESSBpbiBhPEJSPnBhY2tldCBuZXR3b3JrLSBhbnkgbW9kZS4g SXQgY2FuIA0KICAgICAgcmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBhbiBvcGVyYXRvcjxCUj5v biB0aGVtc2VsdmVzIHNvIGV2ZW4gWTE3MzEgDQogICAgICByZWNvbW1lbmRzIG5vdCB0byBibG9j ayBkYXRhIGZyYW1lczo8QlI+IkEgTUVQIGNhbiBkZWNpZGUgd2hldGhlciBpdCANCiAgICAgIGJs b2NrcyBkYXRhIGZyYW1lcyB3aGVuIGl0IGRldGVjdHMgZEFJUy48QlI+VGhlIHByaW5jaXBsZSAN CiAgICAgIHJlcXVpcmVtZW50PEJSPnRoYXQgaW5mbHVlbmNlcyB0aGlzIGRlY2lzaW9uIGlzIHRo YXQgZGF0YSBmcmFtZXMgb3VnaHQgdG8gDQogICAgICBiZSBmb3J3YXJkZWQ8QlI+YXMgbXVjaCBh cyBwb3NzaWJsZSwgd2l0aG91dDxCUj50aGUgcG9zc2liaWxpdHkgb2YgDQogICAgICBmb3J3YXJk aW5nIHdyb25nIGRhdGEgZnJhbWVzIGRvd25zdHJlYW0uIjxCUj5UYWJsZSBJLjctMiBzaG93cyBm b3IgQUlTLCANCiAgICAgIG5vdCB0byBibG9jay48QlI+PEJSPkFuZCBhcyBZMTczMSBzdGF0ZXMs IEFJUyBjYW4gb25seSBiZSB1c2VkIHVuZGVyIHZlcnkgDQogICAgICBjb25zdHJhaW5lZDxCUj5h cmNoaXRlY3R1cmVzIC0gaWYgcmVxdWlyZWQgZm9yIE1QTFMtVFAsIGl0IG5lZWRzIHRvIGhhdmUg DQogICAgICB0aGUgc2FtZTxCUj5ndWlkYW5jZSBhcyBpbiBZMTczMSwgaS5lLiBwb2ludC10by1w b2ludCBhbmQgc2VydmVyL2NsaWVudCANCiAgICAgIG9uZS10by1vbmU6PEJSPiJmb3IgYSBwb2lu dC10by1wb2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSANCiAgICAgIHNpbmds ZSBwZWVyIE1FUC48QlI+VGhlcmVmb3JlLCB0aGVyZTxCUj5pcyBubyBhbWJpZ3VpdHkgcmVnYXJk aW5nIHRoZSBwZWVyIA0KICAgICAgTUVQIGZvciB3aGljaCBpdCBzaG91bGQgc3VwcHJlc3M8QlI+ YWxhcm1zIHdoZW4gaXQgcmVjZWl2ZXMgdGhlPEJSPkVUSC1BSVMgDQogICAgICBpbmZvcm1hdGlv bi4iPEJSPlNvIHNob3VsZCBvbmx5IGJlIHdpdGhpbiBvbmUgZG9tYWluIC0gdGhlbiBubyANCiAg ICAgIG5lZWQuPEJSPjxCUj5EZWJvcmFoPEJSPjxCUj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxCUj5Gcm9tOiANCiAgICAgIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMt dHAtYm91bmNlc0BpZXRmLm9yZ10gT248QlI+QmVoYWxmIE9mIA0KICAgICAgTWFhcnRlbiBWaXNz ZXJzPEJSPlNlbnQ6IE1vbmRheSwgQXByaWwgMjAsIDIwMDkgMTA6MDUgQU08QlI+VG86IA0KICAg ICAgbmVpbC4yLmhhcnJpc29uQGJ0LmNvbTxCUj5DYzogbXBscy10cEBpZXRmLm9yZzxCUj5TdWJq ZWN0OiBSZTogW21wbHMtdHBdIA0KICAgICAgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCANCiAgICAgIHBhdGg8QlI+cmVxdWlyZW1lbnRzPEJSPjxCUj5OZWlsLDxCUj48QlI+Jmd0 OyBidXQgQUlTL0ZESSBpbiB0aGUgY2wgDQogICAgICBtb2RlPy4uLmRvIG1lIGEgZmF2b3VyITxC Uj48QlI+RXRoZXJuZXQgQUlTIGlzIGluZGVlZCBhIHJlcXVpcmVtZW50IGFuZCBhIA0KICAgICAg bmVjZXNzaXR5LiBBbmQgeW91IHdpbGwgbm90PEJSPmJlPEJSPmFibGUgdG8gdW5kZXJzdGFuZCB0 aGF0IGFzIGxvbmcgYXMgDQogICAgICB5b3UgcmVmdXNlIHRvIGFjY2VwdCB0aGF0ICJjbC1tb2Rl IjxCUj5pcyBhPEJSPmZvcndhcmRpbmcgbW9kZSB3aXRoaW4gYSANCiAgICAgICoqdHJhbnNwb3J0 IGVudGl0eSoqLiBHLjgwMCBhbWVuZG1lbnQgMSBoYXM8QlI+ZmluYWxseTxCUj5yZWludHJvZHVj ZWQgDQogICAgICB0aGlzIHRyYW5zcG9ydCBlbnRpdHkgaW50byBHLjgwMC4gQmVzaWRlcyB0aGF0 LCBpdCBhbHNvPEJSPmludHJvZHVjZWQgdGhlIA0KICAgICAgKipkaWZmZXJlbnRpYXRlZCBjb25u ZWN0aW9uKio6PEJSPjxCUj5bRy44MDAgYW0xXSAiQSBkaWZmZXJlbnRpYXRlZCANCiAgICAgIGNv bm5lY3Rpb24gaXMgYSB0cmFuc3BvcnQgZW50aXR5IHRoYXQ8QlI+dHJhbnNmZXJzIGluZm9ybWF0 aW9uIGJlbG9uZ2luZyANCiAgICAgIHRvIG11bHRpcGxlIGNvbW11bmljYXRpb25zIGJldHdlZW4g cG9ydHM8QlI+YWNyb3NzIGEgc3VibmV0d29yay4gDQogICAgICAmbHQ7Li4mZ3Q7IEluIGEgZGlm ZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBtZXNzYWdlPEJSPmNvbnRlbnRzPEJSPmFyZSANCiAgICAg IGludGVycHJldGVkIHRvIGlkZW50aWZ5IChzZXRzIG9mKSBjb21tdW5pY2F0aW9ucyB3aGljaCAN CiAgICAgIHJlY2VpdmU8QlI+ZGlmZmVyZW50PEJSPnRyZWF0bWVudC4gJm5ic3A7VGhlIHNldHMg b2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIA0KICAgICAgZGlzdGluZ3Vpc2hlZCBieSB0aGU8QlI+ Zm9yd2FyZGluZyBpZGVudGlmaWVyIG9yIG90aGVyIGxheWVyIGluZm9ybWF0aW9uLiANCiAgICAg ICZuYnNwO09yZGVyIGlzIG5vdDxCUj5uZWNlc3NhcmlseTxCUj5wcmVzZXJ2ZWQgYmV0d2VlbiBt ZXNzYWdlcyBiZWxvbmdpbmcgDQogICAgICB0byBzZXRzIG9mIGNvbW11bmljYXRpb25zIHJlY2Vp dmluZzxCUj5kaWZmZXJlbnQgdHJlYXRtZW50LiAmbmJzcDtTZXRzIG9mIA0KICAgICAgY29tbXVu aWNhdGlvbnMgbWF5IGJlIGlkZW50aWZpZWQgZm9yPEJSPnB1cnBvc2VzPEJSPnN1Y2ggYXMgdHJh ZmZpYyANCiAgICAgIGNvbmRpdGlvbmluZyBvciBwcmVzZXJ2aW5nIGNvbW11bmljYXRpb24gbWVz c2FnZSANCiAgICAgIG9yZGVyLiI8QlI+PEJSPjxCUj5FdGhlcm5ldCBWTEFOcyBhcmUgaW4gdGVy bXMgb2YgRy44MDAgImRpZmZlcmVudGlhdGVkIA0KICAgICAgY29ubmVjdGlvbnMiLjxCUj5FdGhl cm5ldDxCUj5BSVMgcHJvdmlkZXMgQUlTIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc3VjaCANCiAgICAg ICJkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIi48QlI+SWY8QlI+eW91IGFwcGx5IHRoaXMgdG8g bXkgcHJvcG9zZWQgUFROIA0KICAgICAgbGF5ZXIgc3RhY2ssIHRoZW4gdGhlIEVWQyBsYXllcjxC Uj50b3BvbG9neTxCUj53aWxsIGNvbnNpc3RzIG9mIEVWQyBsaW5rcyANCiAgICAgIHN1cHBvcnRl ZCBieSBNUExTLVRQLCBFdGhlcm5ldCwgUEJCLVRFIGFuZDxCUj5QLU9UTjxCUj5WUCB0cmFpbHMg aW5zaWRlIA0KICAgICAgbWV0cm8gYW5kIGNvcmUgZG9tYWlucyBpbnRlcmNvbm5lY3RpbmcgRVZD IG1hdHJpY2VzLjxCUj5XaGVuPEJSPm9uZSBvZiANCiAgICAgIHRob3NlIEVWQyBsaW5rcyBpcyBp bnRlcnJ1cHRlZCwgZS5nLiBpbiB0aGUgY29yZSBiZXR3ZWVuIG1ldHJvIA0KICAgICAgMTxCUj5h bmQ8QlI+bWV0cm8gNCAoc2VlIGF0dGFjaGVkIHNsaWRlKSwgdGhlbiB0aGUgRVZDIGRpZmZlcmVu dGlhdGVkIA0KICAgICAgY29ubmVjdGlvbjxCUj50aGF0IGlzPEJSPnByZXNlbnQgb24gdGhpcyBs aW5rIHdpbGwgYmUgaW50ZXJydXB0ZWQuIEF0IHRoZSANCiAgICAgIEVWQyBzd2l0Y2gvYnJpZGdl IG5vZGU8QlI+aW48QlI+bWV0cm8gNCB0aGlzIGludGVycnVwdGlvbiBpcyBub3RpY2VkIGFuZCAN CiAgICAgIEVWQy1BSVMgaXMgaW5zZXJ0ZWQgaW4gdGhlPEJSPmRvd25zdHJlYW0gZGlyZWN0aW9u IHRvIHN1cHByZXNzIHRoZSBFVkMtTE9DIA0KICAgICAgYWxhcm1zIGF0IEVWQyBlbmRwb2ludHMg RDQ8QlI+YW5kPEJSPkQ1LjxCUj48QlI+VGhlIEVWQy1BSVMgKGkuZS4gRXRoZXJuZXQgDQogICAg ICBBSVMpIGZyYW1lIGhhcyBhIHJlc2VydmVkIG11bHRpY2FzdCBhZGRyZXNzLDxCUj53aGljaCBn dWFyYW50ZWVzIHRoYXQgdGhlIA0KICAgICAgQUlTIGlzIGJyb2FkY2FzdCB0byB0aGUgZW5kcG9p bnRzIG9mIHRoZSBFVkMuPEJSPjxCUj5JIGJlbGlldmUgdGhhdCBpdCBpcyANCiAgICAgIHRpbWUg Zm9yIHlvdSB0byBhZGFwdCB5b3VyIHZpZXcgb24gY28gYW5kIGNsIG1vZGVzPEJSPmFuZDxCUj5y ZWxhdGUgaXQgdG8gDQogICAgICB0aGUgZm9yd2FyZGluZyBtb2RlICoqSU5TSURFKiogYSB0cmFu c3BvcnQgZW50aXR5LiA8QlI+PEJSPldoYXQgd2Uga25vdyBhcyANCiAgICAgIHRoZSBpbnRlcm5l dCBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQ8QlI+Y29ubmVjdGlvbiIgd2l0 aCBhIA0KICAgICAgYmlsbGlvbiBvciBtb3JlIHBvcnRzLjxCUj5XaGF0IHdlIGtub3cgYXMgYW4g SVAgVlBOIGlzIGVzc2VudGlhbGx5IGFuICJJUCANCiAgICAgIGRpZmZlcmVudGlhdGVkPEJSPmNv bm5lY3Rpb24iPEJSPndpdGggZS5nLiBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIA0K ICAgICAgMiB0byAxMDAwKS48QlI+V2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMg ZXNzZW50aWFsbHkgYW4gDQogICAgICAiRXRoZXJuZXQ8QlI+ZGlmZmVyZW50aWF0ZWQ8QlI+Y29u bmVjdGlvbiIgd2l0aCBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiANCiAgICAgIGUuZy4gMiB0 byAxMDAwKS48QlI+V2hhdCB3ZSBrbm93IGFzIGEgcDJwIE1QTFMgRS1MU1AgaXMgZXNzZW50aWFs bHkgYW4gDQogICAgICAiTVBMUyBkaWZmZXJlbnRpYXRlZDxCUj5jb25uZWN0aW9uIiB3aXRoIDIg cG9ydHMuPEJSPldoYXQgd2Uga25vdyBhcyBhIHAycCANCiAgICAgIFNESCBWQy1uIGlzIGEgIlNE SCBWQy1uIGNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy48QlI+PEJSPlRyYW5zcG9ydCBuZXR3b3Jr IA0KICAgICAgT0FNIGFwcGxpZXMgdG8gdHJhbnNwb3J0IGVudGl0aWVzLCB3aGljaCBhcmUgKGlu IHRlcm1zPEJSPm9mPEJSPkcuODAwIGFtMSkgDQogICAgICBjb25uZWN0aW9ucyBhbmQgZGlmZmVy ZW50aWF0ZWQgDQogICAgICBjb25uZWN0aW9ucy48QlI+PEJSPlJlZ2FyZHMsPEJSPk1hYXJ0ZW48 QlI+PEJSPi0tLS0tT3JpZ2luYWwgDQogICAgICBNZXNzYWdlLS0tLS08QlI+RnJvbTogbmVpbC4y LmhhcnJpc29uQGJ0LmNvbSANCiAgICAgIFttYWlsdG86bmVpbC4yLmhhcnJpc29uQGJ0LmNvbV0g PEJSPlNlbnQ6IHZyaWpkYWcgMTcgYXByaWwgMjAwOSANCiAgICAgIDIyOjAwPEJSPlRvOiBKb2hu LkUuRHJha2UyQGJvZWluZy5jb207IA0KICAgICAgSXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5p dDs8QlI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IA0KICAgICAgbWFhcnRlbi52 aXNzZXJzQGh1YXdlaS5jb208QlI+Q2M6IG1wbHMtdHBAaWV0Zi5vcmc8QlI+U3ViamVjdDogUkU6 IA0KICAgICAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgDQog ICAgICBwYXRoPEJSPnJlcXVpcmVtZW50czxCUj48QlI+Sm9obiwgJm5ic3A7VGhhbmtzIHRoaXMg aXMgYSBncmVhdCBwbGF0Zm9ybSB0byANCiAgICAgIGV4cGxhaW4gd2h5IE9BTSBmb3IgdGhlIDM8 QlI+bmV0d29yazxCUj5tb2RlcyBuZWVkcyB0byBiZSBkaWZmZXJlbnQuIA0KICAgICAgJm5ic3A7 SSBhbSBnZXR0aW5nIGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xrczxCUj50cnlpbmc8QlI+dG8gbWFr ZSBhbGwgMyANCiAgICAgIG5ldHdvcmsgbW9kZXMgbG9vayBhbGlrZSAoYW5kIHRoZW4sIGV2ZW4g d29yc2UsIGludGVyd29yazxCUj50aGVtPEJSPmFzIGFzIA0KICAgICAgcGVlcnMuLi5lc3Agd2hl biBub3Qgbm90IHRvcC1vZi1zdGFjazxCUj5uZXR3b3Jrcy4uLkkgbWVhbiBob3cgc2lsbHkgY2Fu IA0KICAgICAgd2UgZ2V0PykuICZuYnNwOyBJIGFtIGV2ZW4gbW9yZSBmcnVzdHJhdGVkIGJ5PEJS PnRoZSBmYWN0IHRob3NlIHBlZGRsaW5nIA0KICAgICAgdGhpcyBGVUQgb25seSBldmVyIHNlZW0g dG8gY29uc2lkZXIgT0FNIGFuZDxCUj5mb3JnZXQ8QlI+YWxsIG90aGVyIA0KICAgICAgRFAvQ1Av TVAgY29tcG9uZW50cyAoZXNwIHRvcC1vZi1zdGFjayBtZXNzYWdlL2ZpbGUvc3RyZWFtPEJSPmFw cGxpY2F0aW9uIA0KICAgICAgYWRhcHRhdGlvbnMpLiAmbmJzcDtIb3cgd3JvbmcgY2FuIHRoaXMg Z2V0ISA8QlI+PEJSPkluIHRoZSBjbyBtb2RlcyBhIA0KICAgICAgKmNvbm5lY3Rpb24qIGlzIGEg dmVyeSBzcGVjaWZpYyBhbmQgKmNvbnN0cmFpbmluZyo8QlI+Y29uc3RydWN0Li4uLi5JIGFtIA0K ICAgICAgYXNzdW1pbmcgaGVyZSB3ZSByZXNwZWN0IHRoZSBydWxlcyBvZiBhIGNvbm5lY3Rpb248 QlI+KGllPEJSPnNpbmdsZSANCiAgICAgIHNvdXJjZSkgdGhvdWdoIHNvbWUgZm9sa3MgZG9uJ3Qg ZXZlbiBib3RoZXIgdG8gcmVzcGVjdCB0aGlzLCANCiAgICAgIGFuZDxCUj50aGlzPEJSPmlzIGRl c3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBhbGwga25vdyB3aGF0IHByb2JsZW1zIA0KICAgICAgbXVs dGlwbGUtc291cmNlPEJSPmNvbnN0cnVjdHMgY2FuIGNhdXNlIChmcm9tIExEUC9QSFAuLi4uZXJn byANCiAgICAgIE1QTFMtVFApLjxCUj48QlI+V2hlbiB3ZSBoYXZlIGEgY29ubmVjdGlvbiB0aGlz IHJlc3RyaWN0cyAqYWxsKiBEUCAoaWUgDQogICAgICB0cmFmZmljIGFuZCBPQU0pPEJSPnRvPEJS PnN0YXkgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIGNvbm5lY3Rpb24uIA0KICAgICAgJm5ic3A7 V2hpY2ggaXMgZmluZSB1bmRlcjxCUj5kZWZlY3QtZnJlZTxCUj5jb25kaXRpb25zLCBidXQgaWYg d2UgaGF2ZSANCiAgICAgIGxlYWtpbmcgdHJhZmZpYyB0aGVuIHRoZSBjb25zdHJhaW5pbmcgbmF0 dXJlPEJSPm9mPEJSPnRoZSBjb25uZWN0aW9uIA0KICAgICAgY29uc3RydWN0IGlzIGJyb2tlbi4g Jm5ic3A7SW4gYSBudXRzaGVsbCB3aGF0IHRoaXMgbWVhbnMgaXM8QlI+dGhhdDxCUj5PQU0gDQog ICAgICB0aGF0IGlzIG9mIGEgcmVxdWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fubm90IGJlIHRydXN0 ZWQgaW4gY28gDQogICAgICBtb2RlPEJSPm5ldHdvcmtzIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBk ZWZlY3RzLi4uLi5pbmRlZWQsIHdoeSBzaG91bGQgYSANCiAgICAgIGxlYWtpbmc8QlI+RFA8QlI+ aGF2ZSBhIHN5bW1ldHJpYyBnby9yZXR1cm4gZGVmZWN0IGJlaGF2aW91cj8uLi4udmVyeSANCiAg ICAgIGxpa2VseSBpdCB3b24ndC48QlI+U288QlI+d2hpbHN0IHJlcXVlc3QvcmVzcG9uc2UgT0FN IGlzIHJpZ2h0IGZvciB0aGUgY2wgDQogICAgICBtb2RlIGl0IGlzIG5vdCByaWdodCBmb3I8QlI+ dGhlPEJSPmNvIG1vZGUgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCANCiAgICAgIGNvbmRp dGlvbnMuPEJSPjxCUj5Nb3JlIGdlbmVyYWxseSB0aGUgMyBtb2RlcyBhcmUgZGlmZmVyZW50IGFu ZCBub3QganVzdCANCiAgICAgIGluIE9BTTxCUj5yZXF1aXJlbWVudHMuLi4uYnV0IEFJUy9GREkg aW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSANCiAgICAgIGZhdm91ciEuLi5hdCBsZWFzdDxCUj5J RUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRoZXJuZXQgDQogICAgICBl dmVuIHRob3VnaCBpdCByZW1haW5zPEJSPmluPEJSPlkuMTczMS4gJm5ic3A7QW5kIHdoaWNoIGlz IHdoeSBJIG9mdGVuIA0KICAgICAgdHJvdC1vdXQgdGhlIHJhdGhlciBzaWxseSAodG8gaGF2ZSB0 bzxCUj5zYXk8QlI+dGhpcykgb2JzZXJ2YXRpb24gdGhhdCBpZiANCiAgICAgIElQIChjbCBtb2Rl KSBjb3VsZCBkbyBpdCBhbGwgdGhlbiB3aHkgaGF2ZTxCUj5JRVRGPEJSPmZvdW5kIGl0IG5lY2Vz c2FyeSANCiAgICAgIHRvIGNyZWF0ZSBNUExTIChjby1wcykgYW5kIEdNUExTIChDUCBmb3IgY28t Y3MpLiAmbmJzcDtUaGU8QlI+YW5zd2VyIGxpZXMgDQogICAgICBpbiB0aGUgcGh5c2ljcy4uLmFu ZCBHLjgwMCBhdHRlbXB0cyB0byBleHBsYWluIHRoYXQ8QlI+cGh5c2ljcy4uLi5HLjgwNSANCiAg ICAgIGRvZXMgbm90LjxCUj48QlI+U28sIHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQuLi5wbGVh c2UgYWNjZXB0L3Jlam9pY2UgaW4gDQogICAgICB0aGlzIGZhY3QgYXM8QlI+dGhleTxCUj5hbGwg b2ZmZXIgc29tZXRoaW5nIGRpZmZlcmVudC9pbXBvcnRhbnQuICZuYnNwO0J1dCANCiAgICAgIGRv IG5vdCBiZSBob29kd2lua2VkIGJ5PEJSPnRob3NlPEJSPndobyBwZWRkbGUgYSBzdG9yeSB0aGF0 IHRoYXQgdHJpZXMgdG8gDQogICAgICBtYWtlIHRoZSBPQU0gb2YgdGhlIDMgbW9kZXMgdGhlPEJS PnNhbWUuIDxCUj48QlI+cmVnYXJkcywgTmVpbCANCiAgICAgIDxCUj48QlI+Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7IEZyb206IA0KICAgICAgbXBscy10cC1ib3VuY2Vz QGlldGYub3JnPEJSPiZndDsgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0K ICAgICAgQmVoYWxmIE9mIERyYWtlLCBKb2huIEU8QlI+Jmd0OyBTZW50OiAxNyBBcHJpbCAyMDA5 IDIwOjAyPEJSPiZndDsgVG86IEJVU0kgDQogICAgICBJVEFMTzsgQWxleGFuZGVyIFZhaW5zaHRl aW47IE1hYXJ0ZW4gVmlzc2VyczxCUj4mZ3Q7IENjOiANCiAgICAgIG1wbHMtdHBAaWV0Zi5vcmc8 QlI+Jmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCAN CiAgICAgIHRyYW5zcG9ydCBwYXRoIDxCUj4mZ3Q7IHJlcXVpcmVtZW50czxCUj4mZ3Q7IDxCUj4m Z3Q7IEl0YWxvLDxCUj4mZ3Q7IA0KICAgICAgPEJSPiZndDsgQXMgZGVzY3JpYmVkIGluIHRoZSBN UExTIFRQIE9BTSBSZXF1aXJlbWVudHMgSS1ELCB2aXJ0dWFsbHkgYWxsIA0KICAgICAgb2YgdGhl PEJSPjxCUj4mZ3Q7IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJldHVybiBwYXRoLCBhbmQgaW4g dGhlIGFic2VuY2UgDQogICAgICBvZiBhIHJldHVybiA8QlI+Jmd0OyBwYXRoIHRoZXkgYXJlIGRp c2FibGVkLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEFzIGRlc2NyaWJlZCANCiAgICAgIGluIERhdmlkIFNp bmljcm9wZSdzIG1lZXRpbmcgbWludXRlcyA8QlI+Jmd0OyANCiAgICAgIChodHRwOi8vd2lraS50 b29scy5pZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9hdHRhY2htZW50L3dpa2kvPEJSPiZndDsg DQogICAgICBtZWV0aW5nLW5vPEJSPiZndDsgdGVzLzIwMDgxMDE1Lm1wbHMtaW50ZXJvcC1kdC1u b3Rlcy56aXApLCBpZiBJUCANCiAgICAgIGFkZHJlc3NpbmcgaXMgdXNlZCwgYW4gPEJSPiZndDsg TVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgDQogICAgICBnZXR0aW5nIElQ IHBhY2tldHMgZnJvbSA8QlI+Jmd0OyBkZXN0aW5hdGlvbiB0byBzb3VyY2U7IG5laXRoZXIgdGhl IA0KICAgICAgbWludXRlcyBub3IgSSBzdGlwdWxhdGUgdGhhdCBhIDxCUj4mZ3Q7IGNvbnRyb2wg cGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byANCiAgICAgIGluc3RhbnRpYXRlIHRoaXMgZm9yd2Fy ZGluZy48QlI+Jmd0OyA8QlI+Jmd0OyBBcyBhbiBhc2lkZSwgdGhlIGlzc3VlIG9mIA0KICAgICAg cmV0dXJuIHBhdGggZm9yIHVuaWRpcmVjdGlvbmFsIExTUHMgY291bGQgYmU8QlI+PEJSPiZndDsg Y2hhcmF0ZXJpemVkIGFzIA0KICAgICAgdGhlIGVsZXBoYW50IGluIHRoZSByb29tLiAmbmJzcDtJ biB0aGUgTVBMUyBUUCBPQU0gPEJSPiZndDsgRnJhbWV3b3JrIEktRCwgDQogICAgICB1bmljYXN0 IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRpbWVzIGFuZCByZXR1cm4gPEJSPiZndDsg cGF0aHMgbm90IA0KICAgICAgYXQgYWxsLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoYW5rcyw8QlI+Jmd0 OyA8QlI+Jmd0OyBKb2huPEJSPiZndDsgJmd0OyANCiAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPEJSPiZndDsgJmd0OyBGcm9tOiBCVVNJIElUQUxPIA0KICAgICAgW21haWx0bzpJdGFs by5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0XTxCUj4mZ3Q7ICZndDsgU2VudDogRnJpZGF5LCBBcHJp bCAxNywgDQogICAgICAyMDA5IDE6NTkgQU08QlI+Jmd0OyAmZ3Q7IFRvOiBEcmFrZSwgSm9obiBF OyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiANCiAgICAgIFZpc3NlcnM8QlI+Jmd0OyAm Z3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyBTdWJqZWN0OiBSRTogDQogICAg ICBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIDxCUj4m Z3Q7ICZndDsgDQogICAgICByZXF1aXJlbWVudHM8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg Sm9obiw8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgSSANCiAgICAgIG1pZ2h0IGhhdmUgbWlz c2VkIHRoZSBhZ3JlZW1lbnQgb2YgTVBMUy1UUCBiZWluZyBjYXBhYmxlIG9mIDxCUj4mZ3Q7ICZn dDsgDQogICAgICBzZW5kaW5nIHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNlbnQgb24gdW5pLWRp cmVjdGlvbmFsIExTUHMuPEJSPiZndDsgJmd0OyANCiAgICAgIDxCUj4mZ3Q7ICZndDsgVGhpcyBy ZXF1aXJlbWVudCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlIGZpcnN0IHNldCBvZiANCiAgICAgIHJl cXVpcmVtZW50cyA8QlI+Jmd0OyAmZ3Q7IElUVS1UIGlzIGV4cGVjdGluZyB0byBiZSBtZXQgYnkg DQogICAgICBPY3RvYmVyLjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBIb3dldmVyLCBJIHRo aW5rIHRoaXMgaW4gYSBwb3RlbnRpYWwgDQogICAgICBpbnRlcmVzdGluZyBhZGRpdGlvbmFsIDxC Uj4mZ3Q7ICZndDsgcmVxdWlyZW1lbnQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IA0KICAgICAg KGF0IHdvcnN0IGluIGE8QlI+Jmd0OyBzdWJzZXF1ZW50IHBoYXNlKS48QlI+Jmd0OyAmZ3Q7IDxC Uj4mZ3Q7ICZndDsgSSANCiAgICAgIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVudCBuZWVkcyB0 byBiZSBldmFsdWF0ZWQgdmVyc3VzIG90aGVyIDxCUj4mZ3Q7IA0KICAgICAgJmd0OyBtb3JlIGlt cG9ydGFudCByZXF1aXJlbWVudHMgKGUuZy4gdGhlIHBvc3NpYmlsaXR5IHRvIHdvcmsgdy9vIElQ IA0KICAgICAgPEJSPiZndDsgJmd0OyBmb3J3YXJkaW5nIGFuZCB0aGUgbmVlZCBmb3IgT0FNIHRv IGNvbnRpbnVlIHRvIG1vbml0b3IgdGhlIA0KICAgICAgZGF0YSA8QlI+Jmd0OyAmZ3Q7IHBsYW5l IGFsc28gaW4gY2FzZSBvZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wgb3IgDQogICAg ICBtYW5hZ2VtZW50IDxCUj4mZ3Q7ICZndDsgcGxhbmUpLjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsg Jmd0OyBJIGFtIG9wZW4gdG8gDQogICAgICBkaXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlz IHRoZSByaWdodCB0aW1lIGJlY2F1c2UgPEJSPiZndDsgJmd0OyBJIA0KICAgICAgd2lzaCB0byBh dm9pZCBkZWxheWluZyB0aGUgZmlyc3QgcGhhc2Ugb2YgdGhlIGRlc2lnbiBzb2x1dGlvbi48QlI+ Jmd0OyANCiAgICAgICZndDsgPEJSPiZndDsgJmd0OyBUaGFua3MsIEl0YWxvPEJSPiZndDsgJmd0 OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxC Uj4mZ3Q7ICZndDsgJmd0OyBGcm9tOiANCiAgICAgIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzxC Uj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4gRTxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA4OjAwIFBNPEJSPiZndDsgJmd0OyAmZ3Q7IFRv OiANCiAgICAgIEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnM8QlI+Jmd0OyAm Z3Q7ICZndDsgQ2M6IA0KICAgICAgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyBT dWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgDQogICAgICBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIDxCUj4mZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8QlI+Jmd0OyAmZ3Q7 IA0KICAgICAgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgQXQgdGhlIG1lZXRpbmcgbGFzdCBmYWxs IGF0IEp1bmlwZXIgaW4gDQogICAgICBNYXNzYWNodXNldHRzLCBJPEJSPiZndDsgJmd0OyB0aGlu ayBpdCB3YXM8QlI+Jmd0OyAmZ3Q7ICZndDsgYWdyZWVkIHRoYXQgDQogICAgICBhbiBNUExTIFRQ IG5ldHdvcmsgbmVlZHMgdG8gaGF2ZSBhIGZvcndhcmRpbmc8QlI+Jmd0OyAmZ3Q7IA0KICAgICAg Y2FwYWJpbGl0eTxCUj4mZ3Q7ICZndDsgJmd0OyBmb3IgbWFuYWdlbWVudCwgY29udHJvbCwgYW5k IE9BTSBwYWNrZXRzIA0KICAgICAgKGUuZy4sIHNlbmRpbmc8QlI+Jmd0OyAmZ3Q7IHJlcGxpZXMg dG8gT0FNPEJSPiZndDsgJmd0OyAmZ3Q7IHJlcXVlc3RzIHNlbnQgDQogICAgICBvbiB1bmktZGly ZWN0aW9uYWwgTFNQcykgZXZlbiBpZiBpdCBkb2VzIG5vdDxCUj4mZ3Q7ICZndDsgaGF2ZSBhbiAN CiAgICAgIElQPEJSPiZndDsgJmd0OyAmZ3Q7IGZvcndhcmRpbmcgZGF0YSBwbGFuZS48QlI+Jmd0 OyAmZ3Q7ICZndDsgPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb206IA0KICAgICAgQWxleGFu ZGVyIFZhaW5zaHRlaW48QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICBbbWFpbHRvOkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IA0K ICAgICAgVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDk6NTcgQU08QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBUbzogTWFhcnRlbiANCiAgICAgIFZpc3NlcnM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBD YzogbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgU3ViamVj dDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgg PEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIE1hYXJ0ZW4sPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgSXQgc2VlbXMgdGhhdCB5b3UndmUganVzdCAoaW1wbGljaXRseSBh bmQsIA0KICAgICAgcHJvYmFibHksPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5hZHZlcnRlbnRs eSkgc3RhdGVkIHRoZSANCiAgICAgIGZvbGxvd2luZzo8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IA0KICAgICAgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TVBMUy1UUCBPQU0gd2lsbCBub3Qg ZXZlciANCiAgICAgIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0aW9uPEJSPiZndDsgJmd0OyAo YW5kIGZhdWx0PEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyBsb2NhbGl6YXRpb24gd2hp Y2ggcmVxdWlyZXMgdGhpcyBmdW5jdGlvbiApIGZvcjxCUj4mZ3Q7ICZndDsgDQogICAgICB1bmlk aXJlY3Rpb25hbCBQMk1QPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYW5kIFAyUCBwYXRocy48QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHRo aXMgc3RhdGVtZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8gDQogICAgICBhbmQgRldJVyk8QlI+ Jmd0OyByYWlzZXMgYSB2YWxpZDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHF1ZXN0aW9uOjxCUj4m Z3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0lzIE1QTFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIA0KICAgICAgdGhl c2U8QlI+Jmd0OyB0eXBlcyBvZiB0cmFuc3BvcnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRo cz88QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IEZvciB0aGUgcmVmZXJlbmNlLCBJUC9NUExTIHByb3ZpZGVzIA0KICAgICAgdGhpcyBraW5kIG9m PEJSPiZndDsgJmd0OyBmdW5jdGlvbmFsaXR5IHRvZGF5PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg Zm9yIA0KICAgICAgKHVuaWRpcmVjdGlvbmFsIC0gYnV0IGl0IGRvZXMgbm90IGtub3cgYW55IG90 aGVyPEJSPiZndDsgJmd0OyB0eXBlKSBQMlAgDQogICAgICBMU1BzPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgYXMgZGVzY3JpYmVkIGluIFJGQyA0Mzc5LiBBbmQgaXRzIGV4dGVuc2lvbiB0byANCiAg ICAgIFAyTVAgTFNQcyBzZWVtcyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBlYXN5Li4uPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDs8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IFJl Z2FyZHMsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyANCiAgICAgICZuYnNwO1Nhc2hhPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tOiANCiAgICAgIG1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXTxCUj4mZ3Q7ICZndDsg T24gDQogICAgICBCZWhhbGY8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBPZiBNYWFydGVuIFZpc3Nl cnMgDQogICAgICBbbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIA0KICAgICAgMTYsIDIwMDkgMzoyNCBQTTxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiAnQWRyaWFuIEZhcnJlbCc8QlI+Jmd0OyAmZ3Q7IA0KICAg ICAgJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg U3ViamVjdDogUmU6IA0KICAgICAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0 cmFuc3BvcnQgcGF0aCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIHJlcXVpcmVtZW50 czxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAg QWRyaWFuLDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7IA0KICAgICAgJmx0O3F1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIA0KICAgICAgaW50ZXJtZWRpYXRlIG5vZGVzIChp bmNsdWRpbmcgTUVQcywgTUlQcyBhbmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBvdGhlciANCiAg ICAgIGludGVybmFsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgZnVuY3Rpb25zIGFzIA0KICAgICAgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVk PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCANCiAgICAgIHRyYW5zcG9ydDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBhdGgg YXQgDQogICAgICBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmc8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIA0KICAgICAgYmFja3dhcmQ8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyANCiAgICAgICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCBw YXRoLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyZndDsgJmx0O2VuZCBxdW90 ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlzIGEgZnVuY3Rpb25hbCByZXF1aXJl bWVudC4gVGhhdDxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IGlzLCB0aGVyZSBpczxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRoYXQgY2FuIGJlIA0KICAgICAgb2JzZXJ2 ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZjxCUj4mZ3Q7ICZndDsgJmd0OyB2aWV3IHRoYXQ8 QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVzdWx0cyBmcm9tIGFkaGVyaW5n IHRvIHRoaXMgcmVxdWlyZW1lbnQuPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIA0K ICAgICAgSXQgaXMgdmVyeSBtdWNoPEJSPiZndDsgb2JzZXJ2YWJsZSBpZjxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHRoaXMgDQogICAgICByZXF1aXJlbWVudCBpcyBtZXQgZnJvbSBhIGJsYWNrIGJv eCBwb2ludCBvZiB2aWV3LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgVGhlIE1JUCBm dW5jdGlvbnMgY2FuIG9ubHkgcGVyZm9ybSB0aGUgTG9vcGJhY2sgd2hlbiB0aGVyZSBpcyBhIDxC Uj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGguIFRoZSBNUExTLVRQIExCTSANCiAgICAgIHBhY2tldCA8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyByZWNlaXZlZCBhdCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5lZCAoYXMgDQog ICAgICBMQlI8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYWNrZXQpIHRvIHRoZSBvcmlnaW5hdGlu ZyBNRVAgZnVuY3Rpb24gdmlhIHRoZSANCiAgICAgIG90aGVyPEJSPiZndDsgJmd0OyBkaXJlY3Rp b24gb2Y8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgY28tcm91dGVkIA0KICAgICAgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4gVGhpcyBvdGhlcjxCUj4mZ3Q7IGRpcmVjdGlvbjxCUj4m Z3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgd291bGQgbm90IGJlIGF2YWlsYWJsZSBpbiBhbiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IA0KICAgICAgPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgcGF0aC4uLiBhbmQgdGh1cyB0aGUgbG9vcGJhY2sgdGVzdDxCUj4mZ3Q7ICZndDsg DQogICAgICAmZ3Q7IHdvdWxkIGZhaWwuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgU2ltaWxhcmx5LCANCiAgICAgIHdoZW4gd2UgaGF2ZSB0byBhcHBseSBU Q00gTUVQcyB0byBtb25pdG9yIGE8QlI+Jmd0OyAmZ3Q7IHNlZ21lbnQsIA0KICAgICAgdGhlbjxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgaXMgcG9zc2libGUgaW4gYSBjby1yb3V0ZWQgYmlk aXIgDQogICAgICB0cmFuc3BvcnQgcGF0aDxCUj4mZ3Q7IGJ1dCBub3QgaW4gYTxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGFzc29jaWF0ZWQgDQogICAgICBiaWRpciB0cmFuc3BvcnQgcGF0aC4gSW4g dGhlIGZpcnN0IGNhc2UgdGhlIFRDTSBNRVAgPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0 OyBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zIGFyZSBjby1sb2NhdGVkIGFuZCBjYW48QlI+Jmd0 OyBleGNoYW5nZSANCiAgICAgIHdoYXQgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBjYWxsZWQg InJlbW90ZSBpbmZvcm1hdGlvbiIgd2hpY2ggaXMgDQogICAgICBuZWNlc3NhcnkgZm9yIHBlcmZv cm1hbmNlIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JpbmcuPEJSPiZndDsgJmd0OyAN CiAgICAgICZndDsgJmd0OyBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBNRVAgU291cmNlIGFu ZCBTaW5rIGZ1bmN0aW9uczxCUj4mZ3Q7IA0KICAgICAgJmd0OyBhcmUgaW4gZS5nLiA8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgDQogICAgICBh bmQgVENNIHdvdWxkIG5vdCBiZSBhYmxlPEJSPiZndDsgJmd0OyB0byBwcm92aWRlPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgDQogICAgICBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLjxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyBUaGUgZW50 aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBzLDxCUj4mZ3Q7ICZn dDsgDQogICAgICAmZ3Q7IE1JUHMgYW5kIG90aGVyPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50 ZXJuYWw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsgZnVuY3Rpb25zIGFzIGFw cHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90PEJSPiZndDsgDQogICAg ICAmZ3Q7ICZndDsgJmd0OyBhZGQgdG8gIlRoZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg aW50ZXJtZWRpYXRlIA0KICAgICAgbm9kZXMuIjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IFlvdXIgdW5kZXJzdGFuZGluZyANCiAgICAgIGlzIG5vdCBjb3Jy ZWN0LiBUaGlzIHRleHQgbXVzdCBub3QgYmU8QlI+Jmd0OyAmZ3Q7IGRlbGV0ZWQgYXQ8QlI+Jmd0 OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IGFsbC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVk IHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgIGluc2lz dGVuY2Ugb24gdGhlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5jbHVzaW9uPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IG9mICJUYW5kZW0gQ29ubmVjdGlvbi4iIFRoZSBkZWZp bml0aW9uIHdpdGhpbiB0aGUgSVRVLVQgb2Y8QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7 IHRoaXMgdGVybTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaXM8QlI+Jmd0OyAmZ3Q7ICZn dDsgDQogICAgICAmZ3Q7IHBvb3JseTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgc3BlY2lm aWVkIGFuZCBjb21lcyBmcm9tIHRoZSANCiAgICAgIG1vbml0b3Jpbmcgb2YgYSBwYXRoIHRoYXQg aXM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXJhbGxlbCAoaS5lLjxCUj4mZ3Q7IA0KICAgICAg Jmd0OyAmZ3Q7ICZndDsgdGFuZGVtKTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdG8gdGhl IGRhdGEgcGF0aCBiZWluZyANCiAgICAgIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRD PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgc2VlbXMgdG8gYmUgDQogICAgICBhdDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHZhcmlhbmNlLDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYW5kIHdv dWxkIA0KICAgICAgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC48QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IEkgZG9uJ3QgdW5k ZXJzdGFuZCB3aGVyZSB5b3VyIGludGVycHJldGF0aW9uIG9mIHRhbmRlbTxCUj4mZ3Q7IA0KICAg ICAgJmd0OyBjb25uZWN0aW9uIGlzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgZGVzY3JpYmVkIGlu IElUVS1UIA0KICAgICAgcmVjb21tZW5kYXRpb25zLiBJLmUuICJmcm9tIHRoZTxCUj4mZ3Q7ICZn dDsgbW9uaXRvcmluZyBvZiBhPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBwYXRoIHRo YXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIA0KICAg ICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbW9uaXRvcmVkLiI/PEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBUaGVyZSBpcyBhICJuZXR3b3Jr IGNvbm5lY3Rpb24iIGFuZCB0aGlzIG5ldHdvcms8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgY29ubmVj dGlvbiBpcyBhIHNldDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9mIGludGVyY29ubmVjdGVkICJs aW5rIA0KICAgICAgY29ubmVjdGlvbnMiIGFuZCAibWF0cml4PEJSPiZndDsgY29ubmVjdGlvbnMi LiBBPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBzdWJzZXQgb2YgdGhvc2UgaW50ZXJj b25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQgbWF0cml4IDxCUj4mZ3Q7ICZndDsgDQogICAg ICAmZ3Q7ICZndDsgY29ubmVjdGlvbnMgY2FuIGJlIG1vbml0b3JlZCBhbmQgaXMgdGhlbiByZWZl cnJlZCB0byBhczxCUj4mZ3Q7IA0KICAgICAgYSAidGFuZGVtPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgY29ubmVjdGlvbiIuIFRoZXJlIGlzIG5vICJwYXRoIHRoYXQgaXMgDQogICAgICBwYXJhbGxl bCB0byB0aGU8QlI+Jmd0OyAmZ3Q7IGRhdGEgcGF0aCIuIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFRoZXJlIGlzIA0KICAgICAgb25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBpbnNpZGUgdGhl IGRhdGE8QlI+Jmd0OyBwYXRoIGJ5IHRoZTxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsg VENNIE1FUF9TbyBmdW5jdGlvbiBhbmQgdGhpcyBPQU0gaXMgZXh0cmFjdGVkIGZyb20gDQogICAg ICB0aGU8QlI+Jmd0OyAmZ3Q7IGRhdGEgcGF0aCBieTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRo ZSBUQ00gTUVQX1NrIA0KICAgICAgZnVuY3Rpb24uPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgUmVnYXJkcyw8QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAm Z3Q7IE1hYXJ0ZW48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyANCiAgICAgIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBGcm9tOiBtcGxzLXRwLWJvdW5jZXNA aWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIFttYWlsdG86bXBscy10cC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbDxCUj4mZ3Q7ICZndDsg DQogICAgICAmZ3Q7ICZndDsgU2VudDogZG9uZGVyZGFnIDE2IGFwcmlsIDIwMDkgMTE6NTk8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogDQogICAgICBBbGV4YW5kZXIgVmFpbnNodGVpbjsgYmVu amFtaW4ubml2ZW4tamVua2luc0BidC5jb208QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAg IENjOiBCVVNJIElUQUxPOyBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg U3ViamVjdDogUmU6IA0KICAgICAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0 cmFuc3BvcnQgcGF0aCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIHJlcXVpcmVtZW50 czxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpIA0KICAg ICAgU2FzaGEsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBVbmZvcnR1bmF0ZWx5IEkgDQogICAgICBjYW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3Vy IHN0YXRlbWVudDo8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDs8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IA0KICAgICAgJm5ic3A7ICZuYnNwOyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3 YXJlLCBjby1yb3V0ZWQ8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyBiaWRpcmVjdGlvbmFsIExT UHM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgYXJlIGEgDQogICAg ICBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZsdDtlbmQgcXVvdGUmZ3Q7PEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBUaGlz IHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZSBpdCBub3QgZm9yPEJS PiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBSZXF1aXJlbWVudDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgMzQgaW4gdGhlIGxhdGVzdCBNUExTLVRQIA0KICAgICAgcmVxdWlyZW1lbnRz IGRyYWZ0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgT0su IEdvdCANCiAgICAgIGl0LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEJ1dCB3aGF0IGlzIHRoaXMgZG9pbmcgDQogICAgICBpbiB0aGUgZGF0YSBwbGFuZSBy ZXF1aXJlbWVudHMgc2VjdGlvbj88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyANCiAg ICAgICZndDsgJmd0OyAmZ3Q7IEluIGZhY3QsIHdoYXQgaXMgdGhpcyByZXF1aXJlbWVudCBhY3R1 YWxseSBzYXlpbmc/PEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNs dWRpbmcgTUVQcywgDQogICAgICBNSVBzIGFuZDxCUj4mZ3Q7ICZndDsgJmd0OyBvdGhlciBpbnRl cm5hbDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAmbmJzcDsgJm5ic3A7ICZu YnNwOyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkPEJSPiZndDsgJmd0 OyANCiAgICAgICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7IA0KICAgICAgJm5ic3A7ICZuYnNwOyBwYXRoIGF0IGVhY2gg KHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgDQogICAgICBwYWlyaW5nPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGlvbnNoaXAgb2Yg DQogICAgICB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgZGlyZWN0aW9ucyBvZiANCiAgICAgIHRoYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCANCiAgICAgIHBhdGguPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IA0KICAgICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8gd2F5IHRoaXMgaXMg YSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiANCiAgICAgIFRoYXQ8QlI+Jmd0OyAmZ3Q7IGlzLCB0 aGVyZSBpczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICpub3RoaW5nKiB0aGF0IGNhbiANCiAgICAg IGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2Y8QlI+Jmd0OyAmZ3Q7IHZpZXcg dGhhdDxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgcmVzdWx0cyBmcm9tIGFkaGVyaW5n IHRvIHRoaXMgcmVxdWlyZW1lbnQuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0aGF0IHRo aXMgDQogICAgICByZXF1aXJlbWVudCBpcyBtZXQgYnkgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg Y29uZmlndXJpbmcgc29tZSBkYXRhIHBsYW5lIA0KICAgICAgZGF0YWJhc2UgY29tcG9uZW50IHRo cm91Z2ggdGhlIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1hbmFnZW1lbnQgcGxhbmUuIA0KICAg ICAgVGhlIGRhdGFiYXNlIGNvbXBvbmVudCBpcyBub3QgdXNlZDxCUj4mZ3Q7IGZvciBhbnl0aGlu ZzxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsgZXhjZXB0IHRvIHNhdGlzZnkgdGhpcyBy ZXF1aXJlbWVudCBmb3IgImF3YXJlbmVzcyIuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0 OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBCZW4hIENhbiB3ZSBwbGVhc2UgdHJ5IHRvIHJld3Jp dGUgdGhpcyANCiAgICAgIHJlcXVpcmVtZW50IGluIHRlcm1zIG9mIDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGJlaGF2aW9yPzxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlzIA0K ICAgICAgdGhlIE9OTFkgaXRlbSBpbiB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBsaXN0IHRo YXQgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgc3BlY2lmaWMgZm9yIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChUaGUgcGFpcmluZzxCUj4mZ3Q7IA0KICAgICAg Jmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBh dCBlbmQgcG9pbnRzIGZvciANCiAgICAgIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsPEJSPiZndDsgJmd0OyAmZ3Q7IHBhdGhzIGFyZTxCUj4mZ3Q7IA0KICAgICAgJmd0OyAm Z3Q7ICZndDsgJmd0OyBleGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhleSBhcHBlYXIgaW4gdHdv IA0KICAgICAgZGlmZmVyZW50PEJSPiZndDsgJmd0OyAmZ3Q7IGl0ZW1zIGluIHRoZTxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICByZXF1aXJlbWVudHMnIGxpc3QpLjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgDQogICAgICBSZXF1 aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mPEJSPiZndDsgY28tcm91dGVkPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyANCiAgICAgIGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBv ZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50LjxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsg Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIHNvbWV3aGF0IHZhZ3VlIHNjb3Bl IG9mIA0KICAgICAgdGhpcyByZXF1aXJlbWVudCAoIm90aGVyIGludGVybmFsIDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgZnVuY3Rpb25zIA0KICAgICAgYXMgYXBwcm9wcmlhdGUiKSBjcmVh dGVzIGEgc3VzcGljaW9uIHRoYXQgSFc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIHN1 cHBvcnQgb2YgdGhlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYWlyaW5nIGF3YXJlbmVz cyBtYXkgYmUgDQogICAgICByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC48QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IFRoZSBl bnRpcmV0eSBvZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICIoaW5jbHVkaW5nIE1FUHMsPEJSPiZndDsg DQogICAgICAmZ3Q7IE1JUHMgYW5kIG90aGVyPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50ZXJu YWwgZnVuY3Rpb25zIGFzIA0KICAgICAgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVsZXRlZC4g SXQ8QlI+Jmd0OyAmZ3Q7IGRvZXMgbm90PEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBh ZGQgdG8gIlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxC Uj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZm9sbG93aW5nIHRleHQgaW4g dGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzIA0KICAgICAgc3VzcGljaW9uOjxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmx0O3F1 b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IFRhbmRlbSBDb25uZWN0 aW9uOiBBIA0KICAgICAgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW48QlI+Jmd0OyAmZ3Q7IGFyYml0 cmFyeSBwYXJ0IG9mIGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgJm5ic3A7 IHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSk8QlI+Jmd0OyAN CiAgICAgICZndDsgJmd0OyAmZ3Q7IGluZGVwZW5kZW50bHkgZnJvbSB0aGU8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgIGVuZC10by1lbmQgbW9uaXRvcmluZyAoT0FN KS4gJm5ic3A7SXQgbWF5IGJlIGEgbW9uaXRvcmVkPEJSPiZndDsgJmd0OyANCiAgICAgIHNlZ21l bnQgb3IgYTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IG1vbml0b3JlZCBjb25j YXRlbmF0ZWQgDQogICAgICBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguICZuYnNwOzxCUj4m Z3Q7ICZndDsgVGhlIHRhbmRlbTxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVuZ2luZShz KSANCiAgICAgIG9mPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIG5vZGUocyk8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgIGF0IHRoZSBlZGdlKHMpIG9mIHRoZSBz ZWdtZW50IG9yIGNvbmNhdGVuYXRlZCBzZWdtZW50LjxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAg ICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFi b3V0IHRoaXMgcGVyc2lzdGVudDxCUj4mZ3Q7ICZndDsgaW5zaXN0ZW5jZSANCiAgICAgIG9uIHRo ZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluY2x1c2lvbiBvZiAiVGFuZGVtIENvbm5lY3Rpb24u IiBUaGUgDQogICAgICBkZWZpbml0aW9uIHdpdGhpbjxCUj4mZ3Q7ICZndDsgdGhlIElUVS1UIG9m PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyANCiAgICAgIHRlcm0gaXMgcG9vcmx5IHNwZWNp ZmllZCBhbmQgY29tZXMgZnJvbSB0aGU8QlI+Jmd0OyBtb25pdG9yaW5nIG9mIA0KICAgICAgYTxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhdGggdGhhdCBpcyBwYXJhbGxlbCAoaS5lLiB0YW5kZW0p IHRvIHRoZSBkYXRhIA0KICAgICAgcGF0aCBiZWluZyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBt b25pdG9yZWQuIFRoaXMgZGVmaW5pdGlvbiBvZiBUQyBzZWVtcyANCiAgICAgIHRvIGJlIGF0IHZh cmlhbmNlLDxCUj4mZ3Q7ICZndDsgYW5kIHdvdWxkPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYmUg aWYgdGhlIA0KICAgICAgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLjxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyBEb2Vzbid0ICJmb3J3 YXJkaW5nIGVuZ2luZSIgc291bmQgbGlrZSBoYXJkd2FyZSB0byB5b3U/PEJSPiZndDsgJmd0OyAN CiAgICAgICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZZXMsIGJ1dCBzbyB3aGF0 PzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBJTUhPIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IG5laXRoZXIgdGhlIA0KICAgICAgTVBM Uy1UUDxCUj4mZ3Q7ICZndDsgJmd0OyBSZXF1aXJlbWVudHMgZHJhZnQ8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IA0KICAgICAgbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25l PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAm Z3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgKGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0t cmVxdWlyZW1lbjxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0cy0wMS50eHQp IGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGggDQogICAgICB0YW5kZW08QlI+ Jmd0OyAmZ3Q7ICZndDsgY29ubmVjdGlvbnMuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzxC Uj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyBCdXQgdGFuZGVtIGNvbm5lY3Rpb25z IGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgDQogICAgICBPQU08QlI+Jmd0OyAmZ3Q7IEZy YW1ld29yazxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZHJhZnQ8QlI+Jmd0OyAmZ3Q7IA0K ICAgICAgJmd0OyAmZ3Q7IA0KICAgICAgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tZnI8QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAm Z3Q7IGFtZXdvcmstMDAudHh0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgKS48QlI+Jmd0OyAmZ3Q7 ICZndDsgDQogICAgICAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJpZ2h0LjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IExldCdzIGp1c3QgZ2V0IA0KICAgICAgcmlkIG9mIGFuIHVubmVjZXNz YXJ5IHRlcm0gYW5kIGJyaW5nIGFsbDxCUj4mZ3Q7IHRoZSBJLURzPEJSPiZndDsgJmd0OyANCiAg ICAgICZndDsgJmd0OyBpbnRvIGxpbmUuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIFRoZSBib3R0b20gbGluZSwgSU1ITywgaXMgdGhh dCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgY28tcm91 dGVkIHZzLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXNzb2NpYXRlZDxCUj4mZ3Q7ICZn dDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGlzIHN0aWxsIHJl cXVpcmVkLiBPbmUgd2F5IHRvIA0KICAgICAgcHJvdmlkZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHRoYXQgY291bGQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlIA0KICAgICAgYnkgZXhw bGljaXRseSBsaW1pdGluZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYzxCUj4mZ3Q7ICZndDsg Jmd0OyANCiAgICAgIGZ1bmN0aW9uYWxpdHkuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBBZ3JlZWQuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRyaWFuPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IEZyb206IA0KICAgICAgQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51 a108QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgDQogICAgICBBcHJpbCAx NiwgMjAwOSAxMjoxMyBBTTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgVmFp bnNodGVpbjsgDQogICAgICBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7 IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCANCiAgICAgIHBhdGggPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyBIaSBTYXNo YSw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAg IE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwg YnV0Li4uPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDEuIE15IHJlYWRpbmcgb2YgJm5ic3A7b25lIG9mIA0KICAgICAgQmVuJ3MgJm5i c3A7bWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgDQogICAgICBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBvZiBwYXRo cyB0aGF0IGNhbiBiZTxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgY3JlYXRlZCBpbjxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIGV4aXN0aW5nIG5ldHdvcmtzOyANCiAgICAg ICJ0cnVlIiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRoczxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IHdpbGwgDQogICAgICBoYXZlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0byB3YWl0 IHVudGlsIChpZiBldmVyKSBuZXcgZXF1aXBtZW50IA0KICAgICAgYmVjb21lcyBhdmFpbGFibGUu PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyAN CiAgICAgIGNsZWFybHkgbm9uc2Vuc2UhPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbSB0aGUg cG9pbnQgb2YgdmlldyBvZiANCiAgICAgIGhhcmR3YXJlLCBjby1yb3V0ZWQ8QlI+Jmd0OyAmZ3Q7 IGJpZGlyZWN0aW9uYWwgTFNQcyBhcmU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IGEg c3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLjxCUj4mZ3Q7ICZn dDsgJmd0OyANCiAgICAgICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYgeW91IGNhbiBz ZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgDQogICAgICAoZS5nLiB1c2luZyB0aGU8QlI+ Jmd0OyAmZ3Q7IG1hbmFnZW1lbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwbGFuZSkgeW91IA0K ICAgICAgY2FuIHN1cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQ8QlI+Jmd0OyAmZ3Q7ICZndDsgYmlk aXJlY3Rpb25hbCBMU1AuPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgc2hpcHBpbmcgc29sdXRpb25zIHRoYXQgDQogICAgICBh Y2hpZXZlIGNvLXJvdXRlZDxCUj4mZ3Q7IGJpZGlyZWN0aW9uYWw8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBMU1BzIHVzaW5nIA0KICAgICAgdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVpdGhlciB1 c2UgdGhlIEdNUExTPEJSPiZndDsgJmd0OyAod2hpY2ggDQogICAgICBpczxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGNsZWFuZXIpIG9yIG5vbi1zdGFuZGFyZCBwcm9wcmlldGFyeSBzb2x1dGlvbnMg DQogICAgICAod2hpY2ggaXM8QlI+Jmd0OyAmZ3Q7IG1lc3N5IGJ1dDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IA0KICAgICAgZnVuY3Rpb25hbCkuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgQnV0IChvZiANCiAgICAgIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQg cGxhbmUgb3IgY29udHJvbCBwbGFuZTxCUj4mZ3Q7ICZndDsgc29sdXRpb25zIA0KICAgICAgaGF2 ZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5vdGhpbmcgdG8gZG8gd2l0aCBhdmFpbGFiaWxpdHkg b2YgZXF1aXBtZW50IA0KICAgICAgYXMgdGhleTwvVFQ+PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0y PjxUVD4mZ3Q7IGFyZSBzb2Z0d2FyZTxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgc29s dXRpb25zLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgDQogICAgICAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMgaXMgdGhh dCB0aGUgYWN0dWFsPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBkcml2ZXIgZm9yPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCANCiAgICAg IHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyANCiAgICAgIHRyYW5zcG9ydCBuZXR3b3JrcyByYXRoZXIgdGhhbiBhbnkgc3Bl Y2lmaWMgYmVuZWZpdC48QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAg DQogICAgICByZXF1aXJlbWVudHM/PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgV2hpY2ggaXMgbm90 IHRvIHNheSBpdCBpcyBhIGJhZCANCiAgICAgIHRoaW5nLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEEgbGFyZ2UgZHJpdmVyIGZvciANCiAgICAgIE1QTFMt VFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcms8QlI+Jmd0OyAmZ3Q7IHRoZSBsb29rLDxC Uj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgZmVlbCwgYW5kIGJlaGF2aW9yYWwgY2hhcmFj dGVyaXN0aWNzIG9mIGEgImxlZ2FjeSI8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IHRy YW5zcG9ydCBuZXR3b3JrLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyANCiAgICAgICZndDsgJmd0OyBCYXNlZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMsIEknZCBndWVz cyAoRldJVykgdGhhdDo8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgKiBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlLCBhdCBsZWFzdCBmb3IgdGhlIA0KICAgICAg dGltZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2JlaW5nLCB0aGUg bW9zdCBpbXBvcnRhbnQgDQogICAgICB0eXBlIG9mIGJpZGlyZWN0aW9uYWwgcGF0aHMgaW48QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgICZuYnNwO01QTFMtVFA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIHRoYXQg DQogICAgICBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwgYW5kPEJSPiZn dDsgJmd0OyBnaXZlbiANCiAgICAgIHRoYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBvdGhlciB1 cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9ucyB3aWxsIA0KICAgICAgYmU8QlI+Jmd0 OyBuZWVkZWQgdG8gcmVhY2g8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZnVsbCBmdW5jdGlv biBsZXZlbCANCiAgICAgIG9mIE1QTFMtVFAuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqIHRoZXkgaGFkIA0KICAgICAgYSBnb29kIGNoYW5jZSB0 byByZW1haW4gdGhlIG9ubHkgdHlwZSBvZjxCUj4mZ3Q7ICZndDsgDQogICAgICBiaWRpcmVjdGlv bmFsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgcGF0aHMgaW4gJm5ic3A7cmVh bCANCiAgICAgIGRlcGxveW1lbnRzLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IEkgZG9uJ3Qgc2VlIA0KICAgICAgd2hhdCB0aGF0IGZvbGxvd3MgZnJvbS48 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIENo ZWVycyw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBZHJpYW48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBt cGxzLXRwIG1haWxpbmcgbGlzdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgbXBscy10 cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQog ICAgICA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAg ICBtcGxzLXRwIG1haWxpbmcgbGlzdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1wbHMtdHBAaWV0 Zi5vcmc8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscy10cDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7ICZn dDsgbXBscy10cCANCiAgICAgIG1haWxpbmcgbGlzdDxCUj4mZ3Q7ICZndDsgJmd0OyBtcGxzLXRw QGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPEJSPiZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAg ICAgJmd0OyA8QlI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj4mZ3Q7IA0KICAgICAgbXBscy10cCBtYWlsaW5nIGxpc3Q8QlI+Jmd0OyBtcGxz LXRwQGlldGYub3JnPEJSPiZndDsgDQogICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMtdHA8QlI+Jmd0OyANCiAgICAgIDxCUj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5tcGxzLXRwIG1haWxpbmcgDQogICAgICBs aXN0PEJSPm1wbHMtdHBAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzLXRwPC9UVD48L0ZPTlQ+PEZPTlQgDQogICAgICBzaXplPTM+PEJSPjxCUj48 L0ZPTlQ+PEJSPjxGT05UIA0KICAgICAgc2l6ZT0zPjxUVD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5aVEUgDQogICAgICBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIA0KICAgICAgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRp b24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KICAgICAgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg DQogICAgICBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIA0KICAgICAgb3RoZXJzLjxCUj5UaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIA0KICAgICAgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IA0KICAgICAgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCiAgICAgIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSANCiAgICAgIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48QlI+VGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIA0KICAgICAgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS48QlI+PC9UVD48L0ZPTlQ+PEJSPjxCUj48UFJFPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlv biZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5i c3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29s ZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3Jn YW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lz Jm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3Zl Jm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3Jl Y3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNw O2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDth bmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0 Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtz b2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkm bmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7 cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxl YXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7 aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5k Jm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0K PC9QUkU+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRN TD4NCg== ------_=_NextPart_001_01C9C34C.5F5BF353-- From nurit.sprecher@nsn.com Wed Apr 22 06:18:34 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5CE28C519 for ; Wed, 22 Apr 2009 06:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-3.071, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scYKDpVKQYb7 for ; Wed, 22 Apr 2009 06:18:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F3F7328C52E for ; Wed, 22 Apr 2009 06:17:40 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3MDIJ9m010213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Apr 2009 15:18:19 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3MDIEwr026768; Wed, 22 Apr 2009 15:18:15 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 15:18:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Apr 2009 15:18:13 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532649DD4BB@DEMUEXC014.nsn-intra.net> In-Reply-To: <200904222050402508137@fiberhome.com.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectionaltransport path requirements) Thread-Index: AcnDSQXpuVrK+TmlQlmzBztKkzNXMgAAWhrA References: <200904222050402508137@fiberhome.com.cn> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , "liu.guoman" X-OriginalArrivalTime: 22 Apr 2009 13:18:14.0815 (UTC) FILETIME=[CB0A4AF0:01C9C34C] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectionaltransport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:18:34 -0000 Dear all, We are discussing the requirement of monitoring, managing and protecting = the network at different nested levels (i.e. end-to-end LSP, end-to-end = PW, segment of LSP, one or more consecutive segments of PWs, links = layers). This is the requirement. Any thing else (like TCM, etc.) is a solution = or architectural elements! So, please, can we conclude and go forward with the requirement draft?=20 I think the requirement draft is in a good shape and can move forward.=20 It looks like endless looping discussions! We have been there many times = and agreed on the correct requirement.=20 Best regards, Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of ext Xueqin WEI (Shuetsing WEI) Sent: Wednesday, April 22, 2009 3:51 PM To: liu.guoman Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP = (wasRE:Associatedbidirectionaltransport path requirements) Guoman: Correct: we are discussing requirements of segment monitoring of an End = to End LSP. Sincerely Yours Xueqin Wei (Shuetsing Wei) Development & Planning Department, Fiberhome Telecommunication Technologies Co.,Ltd., No.88 Youkeyuan Road,Hongshan Dist.,Wuhan,Hubei,P.R.China,430074 Tel: +86 27 87691310 Fax: +86 27 87694362 Email: xqwei@fiberhome.com.cn 2009-04-22 20:47:38 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Following = is your = email=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was = RE:Associatedbidirectionaltransport path requirements) Sent=A3=BA2009-04-22 17:02:13 From:liu.guoman To:xqwei CC to:mpls-tp >I support huanfeng's opinions, here we only disscuss the requirements = of=20 >TCM. how to realize the functions of TCM will be disscussed in the = future.=20 >I wish that xueqin consider it very well. > >thank you >liu > > > >"Xueqin WEI (Shuetsing WEI)" =20 >=B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org >2009-04-22 16:22 >=C7=EB=B4=F0=B8=B4 =B8=F8 >xqwei@fiberhome.com.cn > > >=CA=D5=BC=FE=C8=CB >"HUANG Feng F" >=B3=AD=CB=CD >MPLS-TP >=D6=F7=CC=E2 >Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 >RE:Associatedbidirectional transport path requirements) > > > > > > >Feng: > >The function of TCM can be provided by nested LSP (Which is the basic=20 >function of MPLS-TP), we needn't to define TCM. > > >Sincerely Yours >Xueqin Wei (Shuetsing Wei) >2009-04-22 16:20:10 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Following = is your = email=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Subject:RE: [mpls-tp] Tandem Connections in MPLS-TP (was=20 >RE:Associatedbidirectional transport path requirements) >Sent=A3=BA2009-04-20 21:58:18 >From:HUANG Feng F >To:xqwei@fiberhome.com.cn; Ben Niven-Jenkins; Busi Italo >CC to:MPLS-TP > >>Dear Xueqin, >> We are discussing requirement of TCM, not for function and = method=20 >in details. >>B.R. >>Feng=20 >> >>-----Original Message----- >>From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 >Behalf Of Xueqin WEI (Shuetsing WEI) >>Sent: 2009=C4=EA4=D4=C218=C8=D5 14:52 >>To: Ben Niven-Jenkins >>Cc: MPLS-TP >>Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was=20 >RE:Associatedbidirectional transport path requirements) >> >>Support, I think the nested LSP will be great! Until now, I didn't see = >any difference between the nested LSP and TCM on performance = monitoring.=20 >But the nested LSP will make the things more easy. I would like select = a=20 >simple way to resolve the problem. >> >>Sincerely Yours >>Xueqin Wei (Shuetsing Wei) >> >>Fiberhome Telecommunication Technologies Co.,Ltd., >>2009-04-18 14:48:51 >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Following = is your = email=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:=20 >Associatedbidirectional transport path requirements) >>Sent=A3=BA2009-04-17 17:17:31 >>From:Ben Niven-Jenkins >>To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp >> >>>Italo, >>> >>>On 17/04/2009 09:34, "BUSI ITALO" = wrote: >>>> The JWT agreement is to bring the ITU-T transport requirements in=20 >>>> IETF to extend the MPLS architecture to meet them in a way that is=20 >>>> compatible, consistent and coherent with existing IETF = architecture. >>> >>>So I took a look at the JWT report. It says (slide 16) >>> >>>" Service Providers want LSPs/PWEs to be able to be managed at the=20 >>>different nested levels seamlessly (path, segment, multiple segments) >>> aka Tandem Connection Monitoring (TCM), this is used for example=20 >>>when a LSP/PWE crosses multiple administrations" >>> >>>IMO the requirement is to be able to monitor parts of a path as well = as=20 >>>the end to end path. There are many ways to solve that requirement, = one=20 >>>of which is the creation of nested LSPs, one per level of monitoring=20 >>>required (my understanding of how TCM works). >>> >>>I think the real discussion is therefore is the requirement to = monitor=20 >>>different components of an end to end path or is the requirement that = >>>such monitoring MUST be achieved using nested LSPs? >>> >>>As an example PW technology today allows end to end and per segment=20 >>>monitoring but it does not achieve it using nested PWs or PW levels. >>> >>>Ben >>> >>>_______________________________________________ >>>mpls-tp mailing list >>>mpls-tp@ietf.org >>>https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>_______________________________________________ >>mpls-tp mailing list >>mpls-tp@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls-tp >> > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >_______________________________________________ >mpls-tp mailing list >mpls-tp@ietf.org >https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >-------------------------------------------------------- >ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. >This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. >This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Wed Apr 22 06:21:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3139A3A6C20 for ; Wed, 22 Apr 2009 06:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejGehGg-MC2C for ; Wed, 22 Apr 2009 06:21:17 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id AC7C23A67B5 for ; Wed, 22 Apr 2009 06:21:17 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042206223302070 ; Wed, 22 Apr 2009 06:22:33 -0700 Received: from M00900002 ([10.84.2.164]) by s-utl01-sjpop.stsn.net; Wed, 22 Apr 2009 06:22:30 -0700 From: "Maarten Vissers" To: "'BRUNGARD, DEBORAH A, ATTLABS'" Date: Wed, 22 Apr 2009 15:22:24 +0200 Message-ID: <005701c9c34d$65cbe850$a402540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWgABQg5yAAAjIJkACKNDywAARnRGAAAeO4IA== In-reply-to: Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:21:20 -0000 Deborah, See inline... -----Original Message----- From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] Sent: maandag 20 april 2009 17:47 To: Maarten Vissers; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. [mv] I thought that one of the characteristics of a transport network is that DoS attacks are not possible. AIS/FDI definitely does not result in any DoS attack. [mv] With the development of Ethernet OAM two main elements were fixed: 1) AIS was used solely as an alarm suppression mechanism; i.e. AIS would not longer be used to trigger for protection switching, nor would it be used as an input condition for trail signal fail when LOC defect detection is activated 2) LOC defect detection would not longer block traffic. [mv] These fixes made sure that there would no longer be an extension of traffic interruption that could result in the detection of unavailable time at a downstream point due to a short interruption (e.g. 50 ms). Such could occur in ATM. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. [mv] The full text in Y.1731 reads: "For multipoint ETH connectivity, a MEP cannot determine the specific server (sub) layer entity that has encountered defect conditions upon receiving a frame with ETH-AIS information. More importantly, it cannot determine the associated subset of its peer MEPs for which it should suppress alarms since the received ETH-AIS information does not contain that information. Therefore, upon reception of a frame with ETH-AIS information, the MEP will suppress alarms for all peer MEPs whether there is still connectivity or not. However, for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information. " [mv] Y.1731 thus states that AIS is used in all VLAN cases, being VLANs with 2 ports (p2p) and VLANs with more then 2 ports (p2mp, rmp, mp2mp). I.e. there are no constrains in using AIS. [mv] What the text in Y.1731 describes is that it is possible in a n-port (n>2) VLAN to have two fault conditions; one is a server layer fault and the other is a continuity/connectivity fault. If both faults appear in different branches of the n-port VLAN then a MEP Sink function will detect one or more LOC defects due to the interruption of one of its link connections, plus it will detect either one or more LOC defects or MMG defect due to a configuration fault in one of the matrices within the VLAN. The AIS inserted due to the server layer fault (link connection interruption) should essentially only suppress the first set of LOC defects and should not suppress the second (set of) LOC defect(s/MMG defect. But after a very detailed analysis (many contributions) it was concluded that selective alarm suppression was not necessary; i.e. suppression of all alarms (including the one associated with a connection fault) was sufficient. The main rationale was that in e.g. a p2p VC12 connection today we can also have two faults, i.e. a misconnection or open connection and a server layer fault. If the server layer fault is downstream of the connection fault then also in a VC-12 connection the server layer fault suppresses awareness of the connection fault. Regards, Maarten Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity. What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get! In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Italo, > > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return > path they are disabled. > > As described in David Sinicrope's meeting minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an > MPLS TP network needs to be capable of getting IP packets from > destination to source; neither the minutes nor I stipulate that a > control plane needs to be used to instantiate this forwarding. > > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM > Framework I-D, unicast LSPs are only mentioned three times and return > paths not at all. > > Thanks, > > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path > > requirements > > > > John, > > > > I might have missed the agreement of MPLS-TP being capable of > > sending replies to OAM requests sent on uni-directional LSPs. > > > > This requirement does not belong to the first set of requirements > > ITU-T is expecting to be met by October. > > > > However, I think this in a potential interesting additional > > requirement to be taken into account (at worst in a > subsequent phase). > > > > I think that this requirement needs to be evaluated versus other > > more important requirements (e.g. the possibility to work w/o IP > > forwarding and the need for OAM to continue to monitor the data > > plane also in case of failures affecting the control or management > > plane). > > > > I am open to discuss it but not sure this is the right time because > > I wish to avoid delaying the first phase of the design solution. > > > > Thanks, Italo > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > requirements > > > > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > > > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > > > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > > > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > > > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > > > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems > > > > easy... > > > > > > > > > > > > > > > > Regards, > > > > > > > > Sasha > > > > > > > > > > > > > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Adrian, > > > > > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > > > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport > > > > path... and thus the loopback test > > > would fail. > > > > > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g. > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > > > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > > > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > > > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > > > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being > > > > monitored."? > > > > > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path". > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > > > > > > Regards, > > > > Maarten > > > > > > > > > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Hi Sasha, > > > > > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > > > > > > OK. Got it. > > > > > > > > But what is this doing in the data plane requirements section? > > > > > > > > In fact, what is this requirement actually saying? > > > > > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > > > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > > > > > > Therefore it could be assumed that this requirement is met by > > > > configuring some data plane database component through the > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > > > > > > Ben! Can we please try to rewrite this requirement in terms of > > > > behavior? > > > > > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > > > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > > > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > > > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > > > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > > > > > > Yes, but so what? > > > > > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > > > > > > > > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > > > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > > > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > > > > > > Agreed. > > > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > Hi Sasha, > > > > > > > > Not really sure whether you are misrepresenting anyone, but... > > > > > > > > > 1. My reading of one of Ben's messages is that associated > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > > > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > > > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > > > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > > > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > > > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing > > > > > transport networks rather than any specific benefit. > > > > > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > > > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > > > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > > > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > > > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > > > > > > I don't see what that follows from. > > > > > > > > Cheers, > > > > Adrian > > > > > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From xqwei@fiberhome.com.cn Wed Apr 22 06:28:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08323A6CA9 for ; Wed, 22 Apr 2009 06:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.416 X-Spam-Level: **** X-Spam-Status: No, score=4.416 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_20=-0.74, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxSOTVsf89Xc for ; Wed, 22 Apr 2009 06:28:30 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id C885D3A6C20 for ; Wed, 22 Apr 2009 06:28:29 -0700 (PDT) Received: from xqwei ([58.49.48.98]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Apr 2009 21:25:04 +0800 Date: Wed, 22 Apr 2009 21:29:41 +0800 From: "Xueqin WEI (Shuetsing WEI)" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" References: , <200904222050402508137@fiberhome.com.cn>, <077E41CFFD002C4CAB7DFA4386A532649DD4BB@DEMUEXC014.nsn-intra.net> Message-ID: <200904222129408432956@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 22 Apr 2009 13:25:04.0408 (UTC) FILETIME=[BF2D3980:01C9C34D] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectionaltransport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:28:31 -0000 R3JlYXSjoUkgYWdyZWUuDQoNClNpbmNlcmVseSBZb3Vycw0KWHVlcWluIFdlaSAoU2h1ZXRzaW5n IFdlaSkNCjIwMDktMDQtMjIgIDIxOjI4OjE1DQoNCj09PT09PT09PT09PT09PT09PT09IEZvbGxv d2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09PT09PT09PT09PT09DQpTdWJqZWN0OlJFOiBbbXBs cy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhc1JFOkFzc29jaWF0ZWRiaWRp cmVjdGlvbmFsdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KU2VudKO6MjAwOS0wNC0yMiAy MToxNDoyNQ0KRnJvbTpTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikNClRv Onhxd2VpQGZpYmVyaG9tZS5jb20uY247IGxpdS5ndW9tYW4NCkNDIHRvOk1QTFMtVFANCg0KPkRl YXIgYWxsLA0KPldlIGFyZSBkaXNjdXNzaW5nIHRoZSByZXF1aXJlbWVudCBvZiBtb25pdG9yaW5n LCBtYW5hZ2luZyBhbmQgcHJvdGVjdGluZyB0aGUgbmV0d29yayBhdCBkaWZmZXJlbnQgbmVzdGVk IGxldmVscyAoaS5lLiBlbmQtdG8tZW5kIExTUCwgZW5kLXRvLWVuZCBQVywgc2VnbWVudCBvZiBM U1AsIG9uZSBvciBtb3JlIGNvbnNlY3V0aXZlIHNlZ21lbnRzIG9mIFBXcywgbGlua3MgbGF5ZXJz KS4NCj5UaGlzIGlzIHRoZSByZXF1aXJlbWVudC4gQW55IHRoaW5nIGVsc2UgKGxpa2UgVENNLCBl dGMuKSBpcyBhIHNvbHV0aW9uIG9yIGFyY2hpdGVjdHVyYWwgZWxlbWVudHMhDQo+U28sIHBsZWFz ZSwgY2FuIHdlIGNvbmNsdWRlIGFuZCBnbyBmb3J3YXJkIHdpdGggdGhlIHJlcXVpcmVtZW50IGRy YWZ0PyANCj5JIHRoaW5rIHRoZSByZXF1aXJlbWVudCBkcmFmdCBpcyBpbiBhIGdvb2Qgc2hhcGUg YW5kIGNhbiBtb3ZlIGZvcndhcmQuIA0KPkl0IGxvb2tzIGxpa2UgZW5kbGVzcyBsb29waW5nIGRp c2N1c3Npb25zISBXZSBoYXZlIGJlZW4gdGhlcmUgbWFueSB0aW1lcyBhbmQgYWdyZWVkIG9uIHRo ZSBjb3JyZWN0IHJlcXVpcmVtZW50LiANCj5CZXN0IHJlZ2FyZHMsDQo+TnVyaXQNCj4NCj4NCj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBYdWVx aW4gV0VJIChTaHVldHNpbmcgV0VJKQ0KPlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjIsIDIwMDkg Mzo1MSBQTQ0KPlRvOiBsaXUuZ3VvbWFuDQo+Q2M6IE1QTFMtVFANCj5TdWJqZWN0OiBSZTogW21w bHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXNSRTpBc3NvY2lhdGVkYmlk aXJlY3Rpb25hbHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj4NCj5HdW9tYW46DQo+DQo+ Q29ycmVjdDogd2UgYXJlIGRpc2N1c3NpbmcgcmVxdWlyZW1lbnRzIG9mIHNlZ21lbnQgbW9uaXRv cmluZyBvZiBhbiBFbmQgdG8gRW5kIExTUC4NCj4NCj5TaW5jZXJlbHkgWW91cnMNCj5YdWVxaW4g V2VpIChTaHVldHNpbmcgV2VpKQ0KPg0KPkRldmVsb3BtZW50ICYgUGxhbm5pbmcgRGVwYXJ0bWVu dCwNCj5GaWJlcmhvbWUgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9naWVzIENvLixMdGQuLA0K Pk5vLjg4IFlvdWtleXVhbiBSb2FkLEhvbmdzaGFuIERpc3QuLFd1aGFuLEh1YmVpLFAuUi5DaGlu YSw0MzAwNzQNCj5UZWw6ICAgICs4NiAyNyA4NzY5MTMxMA0KPkZheDogICAgKzg2IDI3IDg3Njk0 MzYyDQo+RW1haWw6ICB4cXdlaUBmaWJlcmhvbWUuY29tLmNuDQo+MjAwOS0wNC0yMiAgMjA6NDc6 MzgNCj4NCj49PT09PT09PT09PT09PT09PT09PSBGb2xsb3dpbmcgaXMgeW91ciBlbWFpbD09PT09 PT09PT09PT09PT09PT09PQ0KPlN1YmplY3Q6UmU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlv bnMgaW4gTVBMUy1UUCAod2FzIFJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzKQ0KPlNlbnSjujIwMDktMDQtMjIgMTc6MDI6MTMNCj5Gcm9tOmxpdS5n dW9tYW4NCj5Ubzp4cXdlaQ0KPkNDIHRvOm1wbHMtdHANCj4NCj4+SSBzdXBwb3J0IGh1YW5mZW5n J3Mgb3BpbmlvbnMsIGhlcmUgd2Ugb25seSBkaXNzY3VzcyB0aGUgcmVxdWlyZW1lbnRzIG9mIA0K Pj5UQ00uIGhvdyB0byByZWFsaXplIHRoZSBmdW5jdGlvbnMgb2YgVENNIHdpbGwgYmUgZGlzc2N1 c3NlZCBpbiB0aGUgZnV0dXJlLiANCj4+SSB3aXNoIHRoYXQgeHVlcWluIGNvbnNpZGVyIGl0IHZl cnkgd2VsbC4NCj4+DQo+PnRoYW5rIHlvdQ0KPj5saXUNCj4+DQo+Pg0KPj4NCj4+Ilh1ZXFpbiBX RUkgKFNodWV0c2luZyBXRUkpIiA8eHF3ZWlAZmliZXJob21lLmNvbS5jbj4gDQo+PreivP7Iyzog IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KPj4yMDA5LTA0LTIyIDE2OjIyDQo+PsfrtPC4tCC4 +A0KPj54cXdlaUBmaWJlcmhvbWUuY29tLmNuDQo+Pg0KPj4NCj4+ytW8/sjLDQo+PiJIVUFORyBG ZW5nIEYiIDxGZW5nLmYuSHVhbmdAYWxjYXRlbC1zYmVsbC5jb20uY24+DQo+PrOty80NCj4+TVBM Uy1UUCA8bXBscy10cEBpZXRmLm9yZz4NCj4+1vfM4g0KPj5SZTogW21wbHMtdHBdIFRhbmRlbSBD b25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgDQo+PlJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ RmVuZzoNCj4+DQo+PlRoZSBmdW5jdGlvbiBvZiBUQ00gY2FuIGJlIHByb3ZpZGVkIGJ5IG5lc3Rl ZCBMU1AgKFdoaWNoIGlzIHRoZSBiYXNpYyANCj4+ZnVuY3Rpb24gb2YgTVBMUy1UUCksIHdlIG5l ZWRuJ3QgdG8gZGVmaW5lIFRDTS4NCj4+DQo+Pg0KPj5TaW5jZXJlbHkgWW91cnMNCj4+WHVlcWlu IFdlaSAoU2h1ZXRzaW5nIFdlaSkNCj4+MjAwOS0wNC0yMiAgMTY6MjA6MTANCj4+DQo+Pj09PT09 PT09PT09PT09PT09PT09IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09PT09PT09PT09 PT09DQo+PlN1YmplY3Q6UkU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1U UCAod2FzIA0KPj5SRTpBc3NvY2lhdGVkYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1 aXJlbWVudHMpDQo+PlNlbnSjujIwMDktMDQtMjAgMjE6NTg6MTgNCj4+RnJvbTpIVUFORyBGZW5n IEYNCj4+VG86eHF3ZWlAZmliZXJob21lLmNvbS5jbjsgQmVuIE5pdmVuLUplbmtpbnM7IEJ1c2kg SXRhbG8NCj4+Q0MgdG86TVBMUy1UUA0KPj4NCj4+PkRlYXIgWHVlcWluLA0KPj4+ICAgICBXZSBh cmUgZGlzY3Vzc2luZyByZXF1aXJlbWVudCBvZiBUQ00sIG5vdCBmb3IgIGZ1bmN0aW9uIGFuZCBt ZXRob2QgDQo+PmluIGRldGFpbHMuDQo+Pj5CLlIuDQo+Pj5GZW5nIA0KPj4+DQo+Pj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4+QmVoYWxmIE9mIFh1ZXFpbiBX RUkgKFNodWV0c2luZyBXRUkpDQo+Pj5TZW50OiAyMDA5xOo01MIxOMjVIDE0OjUyDQo+Pj5Ubzog QmVuIE5pdmVuLUplbmtpbnMNCj4+PkNjOiBNUExTLVRQDQo+Pj5TdWJqZWN0OiBSZTogW21wbHMt dHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgDQo+PlJFOkFzc29jaWF0ZWRi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj4+Pg0KPj4+U3VwcG9y dCwgSSB0aGluayB0aGUgbmVzdGVkIExTUCB3aWxsIGJlIGdyZWF0ISBVbnRpbCBub3csIEkgZGlk bid0IHNlZSANCj4+YW55IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmVzdGVkIExTUCBhbmQgVENN IG9uIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcuIA0KPj5CdXQgdGhlIG5lc3RlZCBMU1Agd2lsbCBt YWtlIHRoZSB0aGluZ3MgbW9yZSBlYXN5LiBJIHdvdWxkIGxpa2Ugc2VsZWN0IGEgDQo+PnNpbXBs ZSB3YXkgdG8gcmVzb2x2ZSB0aGUgcHJvYmxlbS4NCj4+Pg0KPj4+U2luY2VyZWx5IFlvdXJzDQo+ Pj5YdWVxaW4gV2VpIChTaHVldHNpbmcgV2VpKQ0KPj4+DQo+Pj5GaWJlcmhvbWUgVGVsZWNvbW11 bmljYXRpb24gVGVjaG5vbG9naWVzIENvLixMdGQuLA0KPj4+MjAwOS0wNC0xOCAgMTQ6NDg6NTEN Cj4+Pg0KPj4+PT09PT09PT09PT09PT09PT09PT0gRm9sbG93aW5nIGlzIHlvdXIgZW1haWw9PT09 PT09PT09PT09PT09PT09PT0NCj4+PlN1YmplY3Q6UmU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVj dGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOiANCj4+QXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KPj4+U2VudKO6MjAwOS0wNC0xNyAxNzoxNzozMQ0K Pj4+RnJvbTpCZW4gTml2ZW4tSmVua2lucw0KPj4+VG86QlVTSSBJVEFMTzsgQWRyaWFuIEZhcnJl bDsgQWxleGFuZGVyIFZhaW5zaHRlaW4gQ0MgdG86bXBscy10cA0KPj4+DQo+Pj4+SXRhbG8sDQo+ Pj4+DQo+Pj4+T24gMTcvMDQvMjAwOSAwOTozNCwgIkJVU0kgSVRBTE8iIDxJdGFsby5CdXNpQGFs Y2F0ZWwtbHVjZW50Lml0PiB3cm90ZToNCj4+Pj4+IFRoZSBKV1QgYWdyZWVtZW50IGlzIHRvIGJy aW5nIHRoZSBJVFUtVCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGluIA0KPj4+Pj4gSUVURiB0byBl eHRlbmQgdGhlIE1QTFMgYXJjaGl0ZWN0dXJlIHRvIG1lZXQgdGhlbSBpbiBhIHdheSB0aGF0IGlz IA0KPj4+Pj4gY29tcGF0aWJsZSwgY29uc2lzdGVudCBhbmQgY29oZXJlbnQgd2l0aCBleGlzdGlu ZyBJRVRGIGFyY2hpdGVjdHVyZS4NCj4+Pj4NCj4+Pj5TbyBJIHRvb2sgYSBsb29rIGF0IHRoZSBK V1QgcmVwb3J0LiBJdCBzYXlzIChzbGlkZSAxNikNCj4+Pj4NCj4+Pj4iIFNlcnZpY2UgUHJvdmlk ZXJzIHdhbnQgTFNQcy9QV0VzIHRvIGJlIGFibGUgdG8gYmUgbWFuYWdlZCBhdCB0aGUgDQo+Pj4+ ZGlmZmVyZW50IG5lc3RlZCBsZXZlbHMgc2VhbWxlc3NseSAocGF0aCwgc2VnbWVudCwgbXVsdGlw bGUgc2VnbWVudHMpDQo+Pj4+ICAgIGFrYSBUYW5kZW0gQ29ubmVjdGlvbiBNb25pdG9yaW5nIChU Q00pLCB0aGlzIGlzIHVzZWQgZm9yIGV4YW1wbGUgDQo+Pj4+d2hlbiBhIExTUC9QV0UgY3Jvc3Nl cyBtdWx0aXBsZSBhZG1pbmlzdHJhdGlvbnMiDQo+Pj4+DQo+Pj4+SU1PIHRoZSByZXF1aXJlbWVu dCBpcyB0byBiZSBhYmxlIHRvIG1vbml0b3IgcGFydHMgb2YgYSBwYXRoIGFzIHdlbGwgYXMgDQo+ Pj4+dGhlIGVuZCB0byBlbmQgcGF0aC4gVGhlcmUgYXJlIG1hbnkgd2F5cyB0byBzb2x2ZSB0aGF0 IHJlcXVpcmVtZW50LCBvbmUgDQo+Pj4+b2Ygd2hpY2ggaXMgdGhlIGNyZWF0aW9uIG9mIG5lc3Rl ZCBMU1BzLCBvbmUgcGVyIGxldmVsIG9mIG1vbml0b3JpbmcgDQo+Pj4+cmVxdWlyZWQgKG15IHVu ZGVyc3RhbmRpbmcgb2YgaG93IFRDTSB3b3JrcykuDQo+Pj4+DQo+Pj4+SSB0aGluayB0aGUgcmVh bCBkaXNjdXNzaW9uIGlzIHRoZXJlZm9yZSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gbW9uaXRvciAN Cj4+Pj5kaWZmZXJlbnQgY29tcG9uZW50cyBvZiBhbiBlbmQgdG8gZW5kIHBhdGggb3IgaXMgdGhl IHJlcXVpcmVtZW50IHRoYXQgDQo+Pj4+c3VjaCBtb25pdG9yaW5nIE1VU1QgYmUgYWNoaWV2ZWQg dXNpbmcgbmVzdGVkIExTUHM/DQo+Pj4+DQo+Pj4+QXMgYW4gZXhhbXBsZSBQVyB0ZWNobm9sb2d5 IHRvZGF5IGFsbG93cyBlbmQgdG8gZW5kIGFuZCBwZXIgc2VnbWVudCANCj4+Pj5tb25pdG9yaW5n IGJ1dCBpdCBkb2VzIG5vdCBhY2hpZXZlIGl0IHVzaW5nIG5lc3RlZCBQV3Mgb3IgUFcgbGV2ZWxz Lg0KPj4+Pg0KPj4+PkJlbg0KPj4+Pg0KPj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+bXBscy10cCBtYWlsaW5nIGxpc3QNCj4+Pj5tcGxzLXRw QGlldGYub3JnDQo+Pj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz LXRwDQo+Pj4+DQo+Pj4NCj4+Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+bXBscy10cCBtYWlsaW5nIGxpc3QNCj4+Pm1wbHMt dHBAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cA0KPj4+DQo+Pg0KPj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj5tcGxzLXRwIG1haWxpbmcgbGlzdA0KPj5tcGxzLXRwQGll dGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0K Pj4NCj4+DQo+Pg0KPj4NCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KPj5UaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhl eSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5k ZXIuDQo+PlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KPg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tcGxzLXRwIG1haWxpbmcgbGlzdA0K Pm1wbHMtdHBAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtdHANCj4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCg== From dbrungard@att.com Wed Apr 22 06:48:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F233A6803 for ; Wed, 22 Apr 2009 06:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUEjLCCcMzGW for ; Wed, 22 Apr 2009 06:48:09 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id A4E093A6CA9 for ; Wed, 22 Apr 2009 06:48:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-5.tower-129.messagelabs.com!1240408162!13494235!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23338 invoked from network); 22 Apr 2009 13:49:23 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Apr 2009 13:49:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3MDnLUD010577 for ; Wed, 22 Apr 2009 09:49:22 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3MDnIY1010559 for ; Wed, 22 Apr 2009 09:49:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {1C81D94C-E849-418C-9A5D-13B73023D0E6} x-cr-hashedpuzzle: Bm+4 B6UQ CLTg ClK9 DHMk EVey GJ1L G4lZ IRqB IoXa Khzx K9eg L205 Qc3a Tw5+ Ucza; 2; bQBhAGEAcgB0AGUAbgAuAHYAaQBzAHMAZQByAHMAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAbQBwAGwAcwAtAHQAcABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {1C81D94C-E849-418C-9A5D-13B73023D0E6}; ZABiAHIAdQBuAGcAYQByAGQAQABhAHQAdAAuAGMAbwBtAA==; Wed, 22 Apr 2009 13:49:13 GMT; UgBFADoAIABbAG0AcABsAHMALQB0AHAAXQAgAEEAcwBzAG8AYwBpAGEAdABlAGQAIABiAGkAZABpAHIAZQBjAHQAaQBvAG4AYQBsACAAdAByAGEAbgBzAHAAbwByAHQAIABwAGEAdABoACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMA Content-class: urn:content-classes:message Date: Wed, 22 Apr 2009 09:49:13 -0400 Message-ID: In-Reply-To: <005701c9c34d$65cbe850$a402540a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: Acm+fHhIBMISwA5VQbizQB+F6hpX8gADjVhAAAnjfmYAArH+kAAfMvWgABQg5yAAAjIJkACKNDywAARnRGAAAeO4IABee5aA References: <005701c9c34d$65cbe850$a402540a@china.huawei.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Maarten Vissers" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:48:11 -0000 Maarten, It denies the operator from providing service: - if configured for no traffic interruption for the customer, while the customer can claim based on OAM, a lack of service, is a denial of service for the operator - if block traffic (which is allowed), depending on the client/server architecture or a wrong equipment default or a mis-provisioning is also a denial of service as the traffic may be fine What you are now supporting is similar to path trace mismatch in the US standards. Don't block traffic for what may be a possible indication error. But if an OAM indicator is so questionable on its application, then it is of no use. Deborah -----Original Message----- From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: Wednesday, April 22, 2009 9:22 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements Deborah, See inline... -----Original Message----- From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: maandag 20 april 2009 17:47 To: Maarten Vissers; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. [mv] I thought that one of the characteristics of a transport network is that DoS attacks are not possible. AIS/FDI definitely does not result in any DoS attack. [mv] With the development of Ethernet OAM two main elements were fixed:=20 1) AIS was used solely as an alarm suppression mechanism; i.e. AIS would not longer be used to trigger for protection switching, nor would it be used as an input condition for trail signal fail when LOC defect detection is activated 2) LOC defect detection would not longer block traffic. [mv] These fixes made sure that there would no longer be an extension of traffic interruption that could result in the detection of unavailable time at a downstream point due to a short interruption (e.g. 50 ms). Such could occur in ATM. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. [mv] The full text in Y.1731 reads: "For multipoint ETH connectivity, a MEP cannot determine the specific server (sub) layer entity that has encountered defect conditions upon receiving a frame with ETH-AIS information. More importantly, it cannot determine the associated subset of its peer MEPs for which it should suppress alarms since the received ETH-AIS information does not contain that information. Therefore, upon reception of a frame with ETH-AIS information, the MEP will suppress alarms for all peer MEPs whether there is still connectivity or not. However, for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information. " [mv] Y.1731 thus states that AIS is used in all VLAN cases, being VLANs with 2 ports (p2p) and VLANs with more then 2 ports (p2mp, rmp, mp2mp). I.e. there are no constrains in using AIS. [mv] What the text in Y.1731 describes is that it is possible in a n-port (n>2) VLAN to have two fault conditions; one is a server layer fault and the other is a continuity/connectivity fault. If both faults appear in different branches of the n-port VLAN then a MEP Sink function will detect one or more LOC defects due to the interruption of one of its link connections, plus it will detect either one or more LOC defects or MMG defect due to a configuration fault in one of the matrices within the VLAN. The AIS inserted due to the server layer fault (link connection interruption) should essentially only suppress the first set of LOC defects and should not suppress the second (set of) LOC defect(s/MMG defect. But after a very detailed analysis (many contributions) it was concluded that selective alarm suppression was not necessary; i.e. suppression of all alarms (including the one associated with a connection fault) was sufficient. The main rationale was that in e.g. a p2p VC12 connection today we can also have two faults, i.e. a misconnection or open connection and a server layer fault. If the server layer fault is downstream of the connection fault then also in a VC-12 connection the server layer fault suppresses awareness of the connection fault. Regards, Maarten Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From gregimirsky@gmail.com Wed Apr 22 09:24:09 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C36B28C5CC for ; Wed, 22 Apr 2009 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-eKmYQXtWP5 for ; Wed, 22 Apr 2009 09:24:05 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0421B3A6927 for ; Wed, 22 Apr 2009 09:23:13 -0700 (PDT) Received: by fxm2 with SMTP id 2so56909fxm.37 for ; Wed, 22 Apr 2009 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4Cm57qccaggZQV2/rZpEYdtgwYHlW3f+WakkjInMm+Q=; b=QrsXLDGHuUeNCrJrd/ZzbYHEvDnMCuP97sd17CF+nkf/Lxl9gwCMWD2moCHa+2JyWD kqW7JUIo1HZG6WlWwEFmLKk13N7swkjeJO/dUM6zqHIFkInxuTB6Z6Qlerh4zOXgfF+b UfwvJB4rquyuOlv1/O+0sbEHAWg8gYfIxaddY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VkeQ7mazvbpJ4fO4Ui9YZ/B9h2M68W9pBrsH6DKAyR+0kckZ0gPpggvDiMMEpEsyDb /FgnBFxcFpM3msluJVq7q8Ryy2HKB3Lr3Bjxmxawr7A2WfMV9Y842qsd1B7gUKYUb4AL NFOLTClE9ZGQy7k52HVX5/4+0qQaibGiaGGSo= MIME-Version: 1.0 Received: by 10.103.102.18 with SMTP id e18mr4664368mum.44.1240417470241; Wed, 22 Apr 2009 09:24:30 -0700 (PDT) In-Reply-To: <004101c9c348$3950d470$a402540a@china.huawei.com> References: <2ECAA42C79676B42AEBAC11229CA7D0C04756097@E03MVB2-UKBR.domain1.systemhost.net> <004101c9c348$3950d470$a402540a@china.huawei.com> Date: Wed, 22 Apr 2009 09:24:30 -0700 Message-ID: <787be2780904220924x6de8f364j58f03416f57d8f72@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=0016363ba7d6afdba5046827321f Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 16:24:09 -0000 --0016363ba7d6afdba5046827321f Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, I believe that it is not a requirement for MPLS-TP to support any specific service, including ones you've listed in your message. On the other hand, support of listed services is a requirement for a client layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers > Neil, > > I expect that the main requirement for a packet transport network > technology like MPLS-TP is that it is able to support at least the follow= ing > services: > - E-Line > - E-Tree > - E-LAN > - PDH CES > in a traffic engineered and managed manner. > > Another main requirement is that it must be able to support those service= s > in a scalable manner between points anywhere in the world. > > The E-Line, E-Tree and E-LAN services allow to reorder client frames that > belong to different priorities and to drop client frames that are drop > eligible. > > The E-Tree and E-LAN services require that client bits are read to delive= r > the frames to the appropriate output port or ports of the E-Tree or E-LAN > supporting transport entity/differentiated connection. > > The packet transport network technology must as such support traffic > engineered transport entities (differentiated connections) with n input > ports (i.e. multi source constructs). This in addition of traffic enginee= red > transport entities with 1 input port. > > Regards, > Maarten > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *neil.2.harrison@bt.com > *Sent:* dinsdag 21 april 2009 14:31 > *To:* liu.guoman@zte.com.cn; dbrungard@att.com > > *Cc:* mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] Associated bidirectional transport path > requirements > > Liu, > > If MPLS-TP is going to be taken seriously as a transport network (like > SDH/SONET) then the 2 key MUST HAVE requirements are these. > > 1 Provide a transparent client/server relationship...which means: > - all client bits treated equally > - client bit ordering preserved > - no attempt to infer client symbol (ie sequence of client bits) meani= ng > and no attempt to change client symbols > - the traffic behaviour of client X must not impact the performance > experienced by client Y > > A key corollary of the above is that MPLS-TP must only support proper > connections (ie single source constructs) > > > 2 Since MPLS-TP is a transport network it is not a top-of-stack network > (ie it does not support directly external message/file/stream > applications). MPLS-TP therefore does not require an E-NNI specification= . > A key corollary of this is that MPLS-TP will not have any peer interworki= ng > relationship with any other network mode/technology. > > > Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this should > have FDI/AIS....however, the merit of this is highly questionable. When = I > and colleagues discussed whether PBB-TE (also a co-ps mode network) shoul= d > have FDI/AIS we concluded that on balance it was not a good idea.....and > note that initially I was in favour of having AIS, but my colleagues > provided strong technical arguments that convinced me otherwise. > > AIS/FDI is historically linked to the early PDH co-cs mode layer networks > that used TTL logic. When this died it put out a +5V (all 1s) signal by > default, ie it required no conscious effort to generate it.....this is ke= y > point. Further, in these networks there is a fairly static/long-holding > client server relationship. Clearly this is not true in the cl-ps mode a= nd > it's why IETF have never specified AIS for IP and its why IEEE had the go= od > sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO > retained it in Y.1731....but I suspect any operator planning to use Ether= net > equipment would always look to IEEE stds and not ITU ones). > > AIS/FDI and the co-ps mode is debatable. As I noted above, on balance we > considered not a good idea for PBB-TE OAM because it requires a conscious > effort to generate it (unlike the co-cs mode) so there are likely to be > scaling problems and its one more thing to go wrong. > > You should also have seen me make the point many times in the past that t= he > always-on defect detection/handling OAM needs to be as simple/sparse as > possible with as little config as possible because we need super > reliability......TCM goes completely against the grain here. Also note t= hat > the OAM required for each of the 3 network modes is not the same, despite > what some claim. > > regards, Neil > > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *liu.guoman@zte.com.cn > *Sent:* 21 April 2009 02:59 > *To:* BRUNGARD, DEBORAH A, ATTLABS > *Cc:* mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] Associated bidirectional transport path > requirements > > > Deborah: > maybe what you said is right. but I can't completely agree your opinions= . > IMO. mpls-tp is regard as transport network like SDH/SONET. so it should > have AIS/FDI fuctions as SDH/SONET. > > do you think so. > > best regards > liu > > > *"BRUNGARD, DEBORAH A, ATTLABS" * > =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org > > 2009-04-20 23:47 > =CA=D5=BC=FE=C8=CB > "Maarten Vissers" , > =B3=AD=CB=CD > mpls-tp@ietf.org =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > I agree with Neil, it is very questionable the value of AIS/FDI in a > packet network- any mode. It can result in a DoS attack by an operator > on themselves so even Y1731 recommends not to block data frames: > "A MEP can decide whether it blocks data frames when it detects dAIS. > The principle requirement > that influences this decision is that data frames ought to be forwarded > as much as possible, without > the possibility of forwarding wrong data frames downstream." > Table I.7-2 shows for AIS, not to block. > > And as Y1731 states, AIS can only be used under very constrained > architectures - if required for MPLS-TP, it needs to have the same > guidance as in Y1731, i.e. point-to-point and server/client one-to-one: > "for a point-to-point ETH connection, a MEP has only a single peer MEP. > Therefore, there > is no ambiguity regarding the peer MEP for which it should suppress > alarms when it receives the > ETH-AIS information." > So should only be within one domain - then no need. > > Deborah > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Maarten Vissers > Sent: Monday, April 20, 2009 10:05 AM > To: neil.2.harrison@bt.com > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements > > Neil, > > > but AIS/FDI in the cl mode?...do me a favour! > > Ethernet AIS is indeed a requirement and a necessity. And you will not > be > able to understand that as long as you refuse to accept that "cl-mode" > is a > forwarding mode within a **transport entity**. G.800 amendment 1 has > finally > reintroduced this transport entity into G.800. Besides that, it also > introduced the **differentiated connection**: > > [G.800 am1] "A differentiated connection is a transport entity that > transfers information belonging to multiple communications between ports > across a subnetwork. <..> In a differentiated connection message > contents > are interpreted to identify (sets of) communications which receive > different > treatment. The sets of communications may be distinguished by the > forwarding identifier or other layer information. Order is not > necessarily > preserved between messages belonging to sets of communications receiving > different treatment. Sets of communications may be identified for > purposes > such as traffic conditioning or preserving communication message order." > > > Ethernet VLANs are in terms of G.800 "differentiated connections". > Ethernet > AIS provides AIS within the scope of such "differentiated connection". > If > you apply this to my proposed PTN layer stack, then the EVC layer > topology > will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and > P-OTN > VP trails inside metro and core domains interconnecting EVC matrices. > When > one of those EVC links is interrupted, e.g. in the core between metro 1 > and > metro 4 (see attached slide), then the EVC differentiated connection > that is > present on this link will be interrupted. At the EVC switch/bridge node > in > metro 4 this interruption is noticed and EVC-AIS is inserted in the > downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 > and > D5. > > The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, > which guarantees that the AIS is broadcast to the endpoints of the EVC. > > I believe that it is time for you to adapt your view on co and cl modes > and > relate it to the forwarding mode **INSIDE** a transport entity. > > What we know as the internet is essentially an "IP differentiated > connection" with a billion or more ports. > What we know as an IP VPN is essentially an "IP differentiated > connection" > with e.g. n ports (n in the range of e.g. 2 to 1000). > What we know as an Ethernet VLAN is essentially an "Ethernet > differentiated > connection" with n ports (n in the range of e.g. 2 to 1000). > What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated > connection" with 2 ports. > What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. > > Transport network OAM applies to transport entities, which are (in terms > of > G.800 am1) connections and differentiated connections. > > Regards, > Maarten > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: vrijdag 17 april 2009 22:00 > To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; > Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport path > requirements > > John, Thanks this is a great platform to explain why OAM for the 3 > network > modes needs to be different. I am getting a wee bit tired of folks > trying > to make all 3 network modes look alike (and then, even worse, interwork > them > as as peers...esp when not not top-of-stack > networks...I mean how silly can we get?). I am even more frustrated by > the fact those peddling this FUD only ever seem to consider OAM and > forget > all other DP/CP/MP components (esp top-of-stack message/file/stream > application adaptations). How wrong can this get! > > In the co modes a *connection* is a very specific and *constraining* > construct.....I am assuming here we respect the rules of a connection > (ie > single source) though some folks don't even bother to respect this, and > this > is despite the fact that we all know what problems multiple-source > constructs can cause (from LDP/PHP....ergo MPLS-TP). > > When we have a connection this restricts *all* DP (ie traffic and OAM) > to > stay within the bounds of the connection. Which is fine under > defect-free > conditions, but if we have leaking traffic then the constraining nature > of > the connection construct is broken. In a nutshell what this means is > that > OAM that is of a request/response nature cannot be trusted in co mode > networks under misconnectivity defects.....indeed, why should a leaking > DP > have a symmetric go/return defect behaviour?....very likely it won't. > So > whilst request/response OAM is right for the cl mode it is not right for > the > co mode under misconnectivity defect conditions. > > More generally the 3 modes are different and not just in OAM > requirements....but AIS/FDI in the cl mode?...do me a favour!...at least > IEEE had the good sense to bin this for Ethernet even though it remains > in > Y.1731. And which is why I often trot-out the rather silly (to have to > say > this) observation that if IP (cl mode) could do it all then why have > IETF > found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The > answer lies in the physics...and G.800 attempts to explain that > physics....G.805 does not. > > So, the 3 modes are different...please accept/rejoice in this fact as > they > all offer something different/important. But do not be hoodwinked by > those > who peddle a story that that tries to make the OAM of the 3 modes the > same. > > regards, Neil > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > Sent: 17 April 2009 20:02 > > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > requirements > > > > Italo, > > > > As described in the MPLS TP OAM Requirements I-D, virtually all of the > > > OAM functions require a return path, and in the absence of a return > > path they are disabled. > > > > As described in David Sinicrope's meeting minutes > > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > > meeting-no > > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an > > MPLS TP network needs to be capable of getting IP packets from > > destination to source; neither the minutes nor I stipulate that a > > control plane needs to be used to instantiate this forwarding. > > > > As an aside, the issue of return path for unidirectional LSPs could be > > > charaterized as the elephant in the room. In the MPLS TP OAM > > Framework I-D, unicast LSPs are only mentioned three times and return > > paths not at all. > > > > Thanks, > > > > John > > > -----Original Message----- > > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > > Sent: Friday, April 17, 2009 1:59 AM > > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] Associated bidirectional transport path > > > requirements > > > > > > John, > > > > > > I might have missed the agreement of MPLS-TP being capable of > > > sending replies to OAM requests sent on uni-directional LSPs. > > > > > > This requirement does not belong to the first set of requirements > > > ITU-T is expecting to be met by October. > > > > > > However, I think this in a potential interesting additional > > > requirement to be taken into account (at worst in a > > subsequent phase). > > > > > > I think that this requirement needs to be evaluated versus other > > > more important requirements (e.g. the possibility to work w/o IP > > > forwarding and the need for OAM to continue to monitor the data > > > plane also in case of failures affecting the control or management > > > plane). > > > > > > I am open to discuss it but not sure this is the right time because > > > I wish to avoid delaying the first phase of the design solution. > > > > > > Thanks, Italo > > > > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > > Sent: Thursday, April 16, 2009 8:00 PM > > > > To: Alexander Vainshtein; Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > requirements > > > > > > > > At the meeting last fall at Juniper in Massachusetts, I > > > think it was > > > > agreed that an MPLS TP network needs to have a forwarding > > > capability > > > > for management, control, and OAM packets (e.g., sending > > > replies to OAM > > > > requests sent on uni-directional LSPs) even if it does not > > > have an IP > > > > forwarding data plane. > > > > > > > > > -----Original Message----- > > > > > From: Alexander Vainshtein > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > > To: Maarten Vissers > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > > requirements > > > > > > > > > > Maarten, > > > > > It seems that you've just (implicitly and, probably, > > > > > inadvertently) stated the following: > > > > > > > > > > MPLS-TP OAM will not ever support MIP loopback > function > > > (and fault > > > > > localization which requires this function ) for > > > unidirectional P2MP > > > > > and P2P paths. > > > > > > > > > > If this statement is correct, this (IMHO and FWIW) > > raises a valid > > > > > question: > > > > > > > > > > Is MPLS-TP an appropriate solution for these > > types of transport > > > > > paths? > > > > > > > > > > For the reference, IP/MPLS provides this kind of > > > functionality today > > > > > for (unidirectional - but it does not know any other > > > type) P2P LSPs > > > > > as described in RFC 4379. And its extension to P2MP LSPs seems > > > > > easy... > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > > On Behalf > > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > > To: 'Adrian Farrel' > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > > requirements > > > > > > > > > > Adrian, > > > > > > > > > > >> > > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > > other internal > > > > > >> functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > > >> relationship of the forward and the backward > > > > > directions of that > > > > > >> transport path. > > > > > >> > > > > > > > > > > > > There is no way this is a functional requirement. That > > > > is, there is > > > > > > *nothing* that can be observed from a black box point of > > > > view that > > > > > > results from adhering to this requirement. > > > > > > > > > > Your understanding is not correct. It is very much > > observable if > > > > > this requirement is met from a black box point of view. > > > > > The MIP functions can only perform the Loopback when there is a > > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet > > > > > received at a MIP needs to be returned (as LBR > > > > > packet) to the originating MEP function via the other > > > direction of > > > > > the co-routed bidirectional transport path. This other > > direction > > > > > would not be available in an associated bidirectional transport > > > > > path... and thus the loopback test > > > > would fail. > > > > > > > > > > Similarly, when we have to apply TCM MEPs to monitor a > > > segment, then > > > > > this is possible in a co-routed bidir transport path > > but not in a > > > > > associated bidir transport path. In the first case the TCM MEP > > > > > Source and Sink functions are co-located and can > > exchange what is > > > > > called "remote information" which is necessary for performance > > > > > monitoring. > > > > > In the latter case the TCM MEP Source and Sink functions > > > are in e.g. > > > > > different nodes in the network and TCM would not be able > > > to provide > > > > > performance monitoring. > > > > > > > > > > > The entirety of the bracketted text "(including MEPs, > > > > MIPs and other > > > > > internal > > > > > > functions as appropriate)" should be deleted. It does not > > > > > add to "The > > > > > > intermediate nodes." > > > > > > > > > > Your understanding is not correct. This text must not be > > > deleted at > > > > > all. > > > > > > > > > > > Actually, I am quite fed up about this persistent > > > > insistence on the > > > > > inclusion > > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > > this term > > > > > > is > > > > > poorly > > > > > > specified and comes from the monitoring of a path that is > > > > > parallel (i.e. > > > > > tandem) > > > > > > to the data path being monitored. This definition of TC > > > > > seems to be at > > > > > variance, > > > > > > and would be if the ACH was actually in band. > > > > > > > > > > I don't understand where your interpretation of tandem > > > connection is > > > > > described in ITU-T recommendations. I.e. "from the > > > monitoring of a > > > > > path that is parallel (i.e. tandem) to the data path being > > > > > monitored."? > > > > > > > > > > There is a "network connection" and this network > > > connection is a set > > > > > of interconnected "link connections" and "matrix > > connections". A > > > > > subset of those interconnected link connections and matrix > > > > > connections can be monitored and is then referred to as > > a "tandem > > > > > connection". There is no "path that is parallel to the > > > data path". > > > > > There is only additional OAM inserted inside the data > > path by the > > > > > TCM MEP_So function and this OAM is extracted from the > > > data path by > > > > > the TCM MEP_Sk function. > > > > > > > > > > Regards, > > > > > Maarten > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > > Sent: donderdag 16 april 2009 11:59 > > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > > requirements > > > > > > > > > > Hi Sasha, > > > > > > > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > > bidirectional LSPs > > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > > Requirement > > > > > > 34 in the latest MPLS-TP requirements draft > > > > > > > > > > OK. Got it. > > > > > > > > > > But what is this doing in the data plane requirements section? > > > > > > > > > > In fact, what is this requirement actually saying? > > > > > > > > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > > > functions as appropriate) of a co-routed > > > > > bidirectional transport > > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > > relationship of the forward and the backward > > > > > directions of that > > > > > > transport path. > > > > > > > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > > > > > > > > Therefore it could be assumed that this requirement is met by > > > > > configuring some data plane database component through the > > > > > management plane. The database component is not used > > for anything > > > > > except to satisfy this requirement for "awareness". > > > > > > > > > > Ben! Can we please try to rewrite this requirement in terms of > > > > > behavior? > > > > > > > > > > > Please note that Requirement 34 is the ONLY item in the > > > > > list that is > > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > > requirements > > > > > > at end points for co-routed and associated bidirectional > > > > paths are > > > > > > exactly the same even if they appear in two different > > > > items in the > > > > > > requirements' list). > > > > > > In other words, without Requirement 34 the notion of > > co-routed > > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > > > The somewhat vague scope of this requirement ("other internal > > > > > > functions as appropriate") creates a suspicion that HW > > > > > support of the > > > > > > pairing awareness may be required in order to comply with it. > > > > > > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > > internal functions as appropriate)" should be deleted. It > > > does not > > > > > add to "The intermediate nodes." > > > > > > > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > > arbitrary part of a > > > > > > transport path that can be monitored (via OAM) > > > > > independently from the > > > > > > end-to-end monitoring (OAM). It may be a monitored > > > segment or a > > > > > > monitored concatenated segment of a transport path. > > > The tandem > > > > > > connection may also include the forwarding engine(s) of > > > > > the node(s) > > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > > > > > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > > inclusion of "Tandem Connection." The definition within > > > the ITU-T of > > > > > this term is poorly specified and comes from the > > monitoring of a > > > > > path that is parallel (i.e. tandem) to the data path being > > > > > monitored. This definition of TC seems to be at variance, > > > and would > > > > > be if the ACH was actually in band. > > > > > > > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > > > > > > > > Yes, but so what? > > > > > > > > > > > IMHO it is worth noting that neither the MPLS-TP > > > > Requirements draft > > > > > > nor the MPLS-TP OAM requirements one > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > > ts-01.txt) contain any requirements dealing with tandem > > > > connections. > > > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > > Framework > > > > > > draft > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > > amework-00.txt > > > > > ). > > > > > > > > > > Right. > > > > > Let's just get rid of an unnecessary term and bring all > > the I-Ds > > > > > into line. > > > > > > > > > > > The bottom line, IMHO, is that some clarity regarding > > > > co-routed vs. > > > > > > associated > > > > > > bidirectional paths is still required. One way to provide > > > > > that could > > > > > > be by explicitly limiting Requirement 34 to specific > > > > functionality. > > > > > > > > > > Agreed. > > > > > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path > > > > > requirements > > > > > > > > > > Hi Sasha, > > > > > > > > > > Not really sure whether you are misrepresenting anyone, but... > > > > > > > > > > > 1. My reading of one of Ben's messages is that associated > > > > > > bidirectional paths are the only types of paths that can be > > > > > created in > > > > > > the existing networks; "true" co-routed bidirectional paths > > > > > will have > > > > > > to wait until (if ever) new equipment becomes available. > > > > > > > > > > This is clearly nonsense! > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs are > > > > > a special case of associated bidirectional LSPs. > > > > > > > > > > If you can set up two unidirectional LSPs (e.g. using the > > > management > > > > > plane) you can surely set up a co-routed > > > > bidirectional LSP. > > > > > > > > > > There are shipping solutions that achieve co-routed > > bidirectional > > > > > LSPs using the control plane. These either use the GMPLS > > > (which is > > > > > cleaner) or non-standard proprietary solutions (which is > > > messy but > > > > > functional). > > > > > > > > > > But (of course) the management plane or control plane > > > solutions have > > > > > nothing to do with availability of equipment as they > > are software > > > > > solutions. > > > > > > > > > > > 2. My reading of one of Neil's messages is that the actual > > > > > driver for > > > > > > co-routed bidirectional paths may be experience with existing > > > > > > transport networks rather than any specific benefit. > > > > > > > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > > Which is not to say it is a bad thing. > > > > > > > > > > A large driver for MPLS-TP is to give the packet network > > > the look, > > > > > feel, and behavioral characteristics of a "legacy" > > > > > transport network. > > > > > > > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > > * associated bidirectional paths are, at least for the time > > > > > > being, the most important type of bidirectional paths in > > > > > > MPLS-TP > > > > > > > > > > I think that is wrong both given my statement above, and > > > given that > > > > > other upgrades to existing MPLS solutions will be > > needed to reach > > > > > the full function level of MPLS-TP. > > > > > > > > > > > * they had a good chance to remain the only type of > > > bidirectional > > > > > > paths in real deployments. > > > > > > > > > > I don't see what that follows from. > > > > > > > > > > Cheers, > > > > > Adrian > > > > > > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > > > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > --0016363ba7d6afdba5046827321f Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, I believe that it is not a requirement for MPLS-TP to supp= ort any specific service, including ones you've listed in your message.= On the other hand, support of listed services is a requirement for a clien= t layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maa= rten Vissers <maarten.vissers@huawei.com> Neil, I expect that the main requirement for a packet=20 transport network technology like MPLS-TP is that it is able to suppor= t at=20 least the following services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed=20 manner. Another main requirement is that it must be able to support=20 those services in a scalable manner between points anywhere in the=20 world. The E-Line, E-Tree and E-LAN services allow to reorder=20 client frames that belong to different priorities and to drop=20 client frames that are drop eligible. The E-Tree and E-LAN services require that client bits are=20 read to deliver the frames to the appropriate output port or ports of = the=20 E-Tree or E-LAN supporting transport entity/differentiated=20 connection. The packet transport network technology must as such=20 support traffic engineered transport entities (differentiated connecti= ons)=20 with n input ports (i.e. multi source constructs). This in addition of traf= fic=20 engineered transport entities with 1 input port. Regards, Maarten From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-= tp-bounces@ietf.org] On Behalf Of=20 neil.2.harr= ison@bt.com Sent: dinsdag 21 april 2009=20 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com C= c:=20 mpls-tp@ietf.org<= br>Subject: Re: [mpls-tp] Associated bidirectional=20 transport path requirements Liu, If MPLS-TP is going to be taken=20 seriously as a transport network (like SDH/SONET) then the 2 key MUST = HAVE=20 requirements are these. 1    Provide a=20 transparent client/server relationship...which means: -    all client bits=20 treated equally -    client bit=20 ordering preserved -    no attempt to=20 infer client symbol (ie sequence of client bits) meaning and no attempt to= =20 change client symbols -    the traffic=20 behaviour of client X must not impact the performance experienced by client= =20 Y A key corollary of the above is that=20 MPLS-TP must only support proper connections (ie single source=20 constructs) 2   Since MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does not support= =20 directly external message/file/stream applications). MPLS-TP therefor= e=20 does not require an E-NNI specification. A key corollary of this is t= hat=20 MPLS-TP will not have any peer interworking relationship with any other net= work=20 mode/technology. Now wrt OAM MPLS-TP is a co-ps mode=20 network. You could argue this should have FDI/AIS....however, the mer= it of=20 this is highly questionable. When I and colleagues discussed whether= =20 PBB-TE (also a co-ps mode network) should have FDI/AIS we concluded that on= =20 balance it was not a good idea.....and note that initially I was in favour = of=20 having AIS, but my colleagues provided strong technical arguments that conv= inced=20 me otherwise. AIS/FDI is historically linked to=20 the early PDH co-cs mode layer networks that used TTL logic. When thi= s=20 died it put out a +5V (all 1s) signal by default, ie it required no conscio= us=20 effort to generate it.....this is key point. Further, in these networ= ks=20 there is a fairly static/long-holding client server relationship. Cle= arly=20 this is not true in the cl-ps mode and it's why IETF have never specifi= ed AIS=20 for IP and its why IEEE had the good sense to throw-out AIS in 802.1ag for= =20 Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I suspe= ct=20 any operator planning to use Ethernet equipment would always look to IEEE s= tds=20 and not ITU ones). AIS/FDI and the co-ps mode is=20 debatable. As I noted above, on balance we considered not a good idea= for=20 PBB-TE OAM because it requires a conscious effort to generate it (unlike th= e=20 co-cs mode) so there are likely to be scaling problems and its one more thi= ng to=20 go wrong. You should also have seen me make=20 the point many times in the past that the always-on defect detection/handli= ng=20 OAM needs to be as simple/sparse as possible with as little config as possi= ble=20 because we need super reliability......TCM goes completely against the grai= n=20 here. Also note that the OAM required for each of the 3 network modes= is=20 not the same, despite what some claim. regards,=20 Neil From: mpls-tp-bounces@ietf.org=20 [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman= @zte.com.cn Sent: 21 April 2009 02:59 To:=20 BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Deborah: = maybe what you said is=20 right. but I can't completely agree your opinions. IMO. mpls-tp is re= gard as=20 transport network like SDH/SONET. so it should have AIS/FDI fuctions as= =20 SDH/SONET. do you thi= nk so.=20 best regards liu I agree with Neil, it is very questionab= le the value of AIS/FDI in=20 a packet network- any mode. It can result in a DoS attack by an=20 operator on themselves so even Y1731 recommends not to block data=20 frames: "A MEP can decide whether it blocks data frames when it d= etects=20 dAIS. The principle requirement that influences this decision is th= at=20 data frames ought to be forwarded as much as possible, without the= =20 possibility of forwarding wrong data frames downstream." Table I.= 7-2 shows=20 for AIS, not to block. And as Y1731 states, AIS can only be used u= nder=20 very constrained architectures - if required for MPLS-TP, it needs to = have=20 the same guidance as in Y1731, i.e. point-to-point and server/client= =20 one-to-one: "for a point-to-point ETH connection, a MEP has only = a single=20 peer MEP. Therefore, there is no ambiguity regarding the peer MEP f= or=20 which it should suppress alarms when it receives the ETH-AIS=20 information." So should only be within one domain - then no=20 need. Deborah -----Original Message----- From:=20 mpls-tp-bou= nces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harris= on@bt.com Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the cl mode?= ...do=20 me a favour! Ethernet AIS is indeed a requirement and a necessity.= And=20 you will not be able to understand that as long as you refuse to ac= cept=20 that "cl-mode" is a forwarding mode within a **transport = entity**. G.800=20 amendment 1 has finally reintroduced this transport entity into G.8= 00.=20 Besides that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is a t= ransport=20 entity that transfers information belonging to multiple communications= =20 between ports across a subnetwork. <..> In a differentiated=20 connection message contents are interpreted to identify (sets of)= =20 communications which receive different treatment. The sets of= =20 communications may be distinguished by the forwarding identifier or ot= her=20 layer information. Order is not necessarily preserved between= =20 messages belonging to sets of communications receiving different treat= ment.=20 Sets of communications may be identified for purposes such as= =20 traffic conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 "differ= entiated=20 connections". Ethernet AIS provides AIS within the scope of su= ch=20 "differentiated connection". If you apply this to my prop= osed PTN layer=20 stack, then the EVC layer topology will consists of EVC links suppo= rted=20 by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and c= ore=20 domains interconnecting EVC matrices. When one of those EVC links i= s=20 interrupted, e.g. in the core between metro 1 and metro 4 (see atta= ched=20 slide), then the EVC differentiated connection that is present on t= his=20 link will be interrupted. At the EVC switch/bridge node in metro 4 = this=20 interruption is noticed and EVC-AIS is inserted in the downstream dire= ction=20 to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. T= he=20 EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, wh= ich=20 guarantees that the AIS is broadcast to the endpoints of the EVC. = I=20 believe that it is time for you to adapt your view on co and cl=20 modes and relate it to the forwarding mode **INSIDE** a transport= =20 entity. What we know as the internet is essentially an "IP= =20 differentiated connection" with a billion or more ports. What = we know as=20 an IP VPN is essentially an "IP differentiated connection"with e.g. n=20 ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN=20 is essentially an "Ethernet differentiated connection" wi= th n ports (n=20 in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is= =20 essentially an "MPLS differentiated connection" with 2 ports= . What we=20 know as a p2p SDH VC-n is a "SDH VC-n connection" with 2=20 ports. Transport network OAM applies to transport entities, which = are=20 (in terms of G.800 am1) connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com;=20 Italo.B= usi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.v= issers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting a wee bit= =20 tired of folks trying to make all 3 network modes look alike (and t= hen,=20 even worse, interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I am eve= n=20 more frustrated by the fact those peddling this FUD only ever seem to= =20 consider OAM and forget all other DP/CP/MP components (esp top-of-s= tack=20 message/file/stream application adaptations). How wrong can this= get!=20 In the co modes a *connection* is a very specific and=20 *constraining* construct.....I am assuming here we respect the rules o= f a=20 connection (ie single source) though some folks don't even both= er to=20 respect this, and this is despite the fact that we all know what=20 problems multiple-source constructs can cause (from LDP/PHP....ergo=20 MPLS-TP). When we have a connection this restricts *all* DP (ie tr= affic=20 and OAM) to stay within the bounds of the connection. Which i= s=20 fine under defect-free conditions, but if we have leaking traffic t= hen=20 the constraining nature of the connection construct is broken. &nbs= p;In=20 a nutshell what this means is that OAM that is of a request/respons= e=20 nature cannot be trusted in co mode networks under misconnectivity=20 defects.....indeed, why should a leaking DP have a symmetric go/ret= urn=20 defect behaviour?....very likely it won't. So whilst request/re= sponse=20 OAM is right for the cl mode it is not right for the co mode under= =20 misconnectivity defect conditions. More generally the 3 modes are= =20 different and not just in OAM requirements....but AIS/FDI in the cl=20 mode?...do me a favour!...at least IEEE had the good sense to bin this= for=20 Ethernet even though it remains in Y.1731. And which is why I= =20 often trot-out the rather silly (to have to say this) observation t= hat=20 if IP (cl mode) could do it all then why have IETF found it necessa= ry to=20 create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in= the=20 physics...and G.800 attempts to explain that physics....G.805 does=20 not. So, the 3 modes are different...please accept/rejoice in this= fact=20 as they all offer something different/important. But do not b= e=20 hoodwinked by those who peddle a story that that tries to make the = OAM=20 of the 3 modes the same. regards, Neil > -----Origi= nal=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17=20 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten=20 Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated=20 bidirectional transport path > requirements > >=20 Italo, > > As described in the MPLS TP OAM Requirements I-D,= =20 virtually all of the > OAM functions require a return path, and= in=20 the absence of a return > path they are disabled. > >= As=20 described in David Sinicrope's meeting minutes >=20 (http://wiki.tools.ietf.org/misc/mpls-interop/attachment= /wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP address= ing=20 is used, an > MPLS TP network needs to be capable of getting IP pa= ckets=20 from > destination to source; neither the minutes nor I stipulate = that=20 a > control plane needs to be used to instantiate this=20 forwarding. > > As an aside, the issue of return path for=20 unidirectional LSPs could be > charaterized as the elephant in = the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs are o= nly=20 mentioned three times and return > paths not at all. > &= gt;=20 Thanks, > > John > > -----Original Message----- = >=20 > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent:= =20 Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander= =20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > >=20 Subject: RE: [mpls-tp] Associated bidirectional transport path > &= gt;=20 requirements > > > > John, > > > > = I=20 might have missed the agreement of MPLS-TP being capable of > >= =20 sending replies to OAM requests sent on uni-directional LSPs. > >= ;=20 > > This requirement does not belong to the first set of=20 requirements > > ITU-T is expecting to be met by October. &g= t;=20 > > > However, I think this in a potential interesting addit= ional=20 > > requirement to be taken into account (at worst in a >= =20 subsequent phase). > > > > I think that this requireme= nt=20 needs to be evaluated versus other > > more important requireme= nts=20 (e.g. the possibility to work w/o IP > > forwarding and the nee= d for=20 OAM to continue to monitor the data > > plane also in case of= =20 failures affecting the control or management > > plane). >= ;=20 > > > I am open to discuss it but not sure this is the right= time=20 because > > I wish to avoid delaying the first phase of the des= ign=20 solution. > > > > Thanks, Italo > > > = >=20 > -----Original Message----- > > > From:=20 mpls-tp-bou= nces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 20= 09=20 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers &g= t;=20 > > Cc: mpls-= tp@ietf.org > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > >=20 requirements > > > > > > At the meeting last fal= l at=20 Juniper in Massachusetts, I > > think it was > > > a= greed=20 that an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM packets (e.= g.,=20 sending > > replies to OAM > > > requests sent on=20 uni-directional LSPs) even if it does not > > have an IP >= >=20 > forwarding data plane. > > > > > > >=20 -----Original Message----- > > > > From: Alexander=20 Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] = >=20 > > > Sent: Thursday, April 16, 2009 9:57 AM > > > &= gt;=20 To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport path= =20 > > > > requirements > > > > > >= >=20 > Maarten, > > > > It seems that you've just (impli= citly=20 and, probably, > > > > inadvertently) stated the=20 following: > > > > > > > > &= nbsp;=20 MPLS-TP OAM will not ever suppor= t MIP=20 loopback function > > (and fault > > > > localiza= tion=20 which requires this function ) for > > unidirectional P2MP &g= t;=20 > > > and P2P paths. > > > > > > > &= gt;=20 If this statement is correct, this (IMHO and FWIW) > raises a=20 valid > > > > question: > > > > > &g= t;=20 > > I= s=20 MPLS-TP an appropriate solution for these > types of transport &= gt;=20 > > > paths? > > > > > > > > For = the=20 reference, IP/MPLS provides this kind of > > functionality=20 today > > > > for (unidirectional - but it does not know a= ny=20 other > > type) P2P LSPs > > > > as described in = RFC=20 4379. And its extension to P2MP LSPs seems > > > >=20 easy... > > > > > > > > > >= ;=20 > > > > > > Regards, > > > > >= ;=20 > > > Sasha > > > > > = >=20 > > > > > > > > > >=20 ________________________________________ > > > > From:=20 mpls-tp-bou= nces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.= vissers@huawei.com] > > > > Sent: Thursday, April 16,=20 2009 3:24 PM > > > > To: 'Adrian Farrel' > &= gt; > >=20 Cc: mpls-tp@ietf.or= g > > > > Subject: Re: [mpls-tp] Associated=20 bidirectional transport path > > > > requirements >= >=20 > > > > > > Adrian, > > > > >= >=20 > > >> <quote> > > > > >> &= nbsp;=20 The intermediate nodes (including MEPs, MIPs and > > > = >=20 other internal > > > > >> funct= ions=20 as appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> path at ea= ch=20 (sub-)layer MUST be aware of the pairing > > > > >>= =20 relationship of the forward and the backward >= >=20 > > directions of that > > > > >> = ;=20 transport path. > > > > >> <end=20 quote> > > > > > > > > > > There i= s no=20 way this is a functional requirement. That > > > is, there=20 is > > > > > *nothing* that can be observed from a blac= k box=20 point of > > > view that > > > > > results = from=20 adhering to this requirement. > > > > > > > &= gt;=20 Your understanding is not correct. It is very much > observable=20 if > > > > this requirement is met from a black box point = of=20 view. > > > > The MIP functions can only perform the Loopb= ack=20 when there is a > > > > co-routed bidirectional transport= =20 path. The MPLS-TP LBM packet > > > > received at a MIP ne= eds=20 to be returned (as LBR > > > > packet) to the originating = MEP=20 function via the other > > direction of > > > > t= he=20 co-routed bidirectional transport path. This other > direction &= gt;=20 > > > would not be available in an associated bidirectional tran= sport=20 > > > > path... and thus the loopback test > > &= gt;=20 would fail. > > > > > > > > Similarly, whe= n we=20 have to apply TCM MEPs to monitor a > > segment, then > &g= t;=20 > > this is possible in a co-routed bidir transport path > bu= t not=20 in a > > > > associated bidir transport path. In the first= case=20 the TCM MEP > > > > Source and Sink functions are co-loca= ted=20 and can > exchange what is > > > > called "remo= te=20 information" which is necessary for performance > > > &= gt;=20 monitoring. > > > > In the latter case the TCM MEP Source = and=20 Sink functions > > are in e.g. > > > > different= =20 nodes in the network and TCM would not be able > > to provide>=20 > > > performance monitoring. > > > > > &g= t;=20 > > > The entirety of the bracketted text "(including MEPs,= >=20 > > MIPs and other > > > > internal > > >= ;=20 > > functions as appropriate)" should be deleted. It does not<= br>>=20 > > > add to "The > > > > > intermediate= =20 nodes." > > > > > > > > Your understa= nding is=20 not correct. This text must not be > > deleted at > > &= gt;=20 > all. > > > > > > > > > Actually, I= am=20 quite fed up about this persistent > > > insistence on the>=20 > > > inclusion > > > > > of "Tandem Conn= ection."=20 The definition within the ITU-T of > > > > this term &g= t;=20 > > > > is > > > > poorly > > > &g= t;=20 > specified and comes from the monitoring of a path that is > &g= t;=20 > > parallel (i.e. > > > > tandem) > > >= >=20 > to the data path being monitored. This definition of TC > >= >=20 > seems to be at > > > > variance, > > > &g= t;=20 > and would be if the ACH was actually in band. > > > >= =20 > > > > I don't understand where your interpretation = of=20 tandem > > connection is > > > > described in ITU= -T=20 recommendations. I.e. "from the > > monitoring of a >= > >=20 > path that is parallel (i.e. tandem) to the data path being > = >=20 > > monitored."? > > > > > > > >= ; There is=20 a "network connection" and this network > > connection= is a=20 set > > > > of interconnected "link connections"= and=20 "matrix > connections". A > > > > subset o= f those=20 interconnected link connections and matrix > > > > connec= tions=20 can be monitored and is then referred to as > a "tandem >= ; >=20 > > connection". There is no "path that is parallel to th= e > >=20 data path". > > > > There is only additional OAM ins= erted=20 inside the data > path by the > > > > TCM MEP_So fun= ction=20 and this OAM is extracted from the > > data path by > >= >=20 > the TCM MEP_Sk function. > > > > > > > &= gt;=20 Regards, > > > > Maarten > > > > > &= gt;=20 > > > > > > -----Original Message----- > >= >=20 > From: = mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > >=20 > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexa= nder=20 Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI=20 ITALO; mpls-tp@ietf= .org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi Sasha, = >=20 > > > > > > > > Unfortunately I cannot fully = agree=20 with your statement: > > > > > > > > > &= gt;=20 <quote> > > > > > From the point of= view=20 of hardware, co-routed > > > bidirectional LSPs > > = >=20 > > are a special case of associated bidirectional=20 LSPs. > > > > > <end quote> > > > >= ;=20 > > > > > > This statement would be obviously correc= t,=20 were it not for > > > > Requirement > > > >= >=20 34 in the latest MPLS-TP requirements draft > > > > &g= t;=20 > > > OK. Got it. > > > > > > > >= But=20 what is this doing in the data plane requirements section? > > &= gt;=20 > > > > > In fact, what is this requirement actually= =20 saying? > > > > > > > > >=20 <quote> > > > > > The interme= diate=20 nodes (including MEPs, MIPs and > > > other internal > = >=20 > > > functions as appropriate) of a=20 co-routed > > > > bidirectional transport > > >= ;=20 > > path at each (sub-)layer MUST be aware of = the=20 pairing > > > > > relationship of = the=20 forward and the backward > > > > directions of that >= ;=20 > > > > transport path. > > >= ;=20 > > <end quote> > > > > > > > >= ;=20 There is no way this is a functional requirement. That > > is, t= here=20 is > > > > *nothing* that can be observed from a black box= =20 point of > > view that > > > > results from adher= ing=20 to this requirement. > > > > > > > > There= fore=20 it could be assumed that this requirement is met by > > > &g= t;=20 configuring some data plane database component through the > > = >=20 > management plane. The database component is not used > for=20 anything > > > > except to satisfy this requirement for=20 "awareness". > > > > > > > > Ben= ! Can we please=20 try to rewrite this requirement in terms of > > > >=20 behavior? > > > > > > > > > Please note= that=20 Requirement 34 is the ONLY item in the > > > > list that= =20 is > > > > > specific for co-routed bidirectional LSPs.= (The=20 pairing > > > > requirements > > > > > a= t end=20 points for co-routed and associated bidirectional > > > paths= =20 are > > > > > exactly the same even if they appear in t= wo=20 different > > > items in the > > > > >=20 requirements' list). > > > > > In other words, with= out=20 Requirement 34 the notion of > co-routed > > > > >= ;=20 bidirectional paths would be void of any data plane content. > >= >=20 > > > > > > > The somewhat vague scope of this=20 requirement ("other internal > > > > > functions = as=20 appropriate") creates a suspicion that HW > > > > sup= port of=20 the > > > > > pairing awareness may be required in orde= r to=20 comply with it. > > > > > > > > The entire= ty of=20 the bracketted text "(including MEPs, > > MIPs and other> >=20 > > internal functions as appropriate)" should be deleted. It<= br>>=20 > does not > > > > add to "The intermediate nodes.= " >=20 > > > > > > > > The following text in the dra= ft=20 increases this suspicion: > > > > > > > > &= gt;=20 > <quote> > > > > > Tandem Connection: = A=20 tandem connection is an > > arbitrary part of a > > >= ;=20 > > transport path that can be monitored (via OAM) > &= gt;=20 > > independently from the > > > > > end-t= o-end=20 monitoring (OAM). It may be a monitored > > segment or=20 a > > > > > monitored concatenated segment of a= =20 transport path. > > The tandem > > > > >= ;=20 connection may also include the forwarding engine(s) of > &g= t;=20 > > the node(s) > > > > > at the edge(s) o= f the=20 segment or concatenated segment. > > > > > <end=20 quote> > > > > > > > > Actually, I am q= uite=20 fed up about this persistent > > insistence on the > > = >=20 > inclusion of "Tandem Connection." The definition within> > the=20 ITU-T of > > > > this term is poorly specified and comes f= rom=20 the > monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > monitored. This=20 definition of TC seems to be at variance, > > and would > = >=20 > > be if the ACH was actually in band. > > > > = >=20 > > > > Doesn't "forwarding engine" sound like = hardware to=20 you? > > > > > > > > Yes, but so what? = >=20 > > > > > > > > IMHO it is worth noting that= =20 neither the MPLS-TP > > > Requirements draft > > >= ;=20 > > nor the MPLS-TP OAM requirements one > > > > >= ;=20 > > > > > > > > > >=20 (http://www.ietf.org/internet-drafts/draft-ietf-= mpls-tp-oam-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing with=20 tandem > > > connections. > > > > > >= >=20 > > > But tandem connections are discussed in the MPLS-TP OAM>=20 > Framework > > > > > draft > > > >= =20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-= oam-fr > >=20 > > amework-00.txt > > > > ). > > > >= =20 > > > > Right. > > > > Let's just get = rid of an=20 unnecessary term and bring all > the I-Ds > > > > in= to=20 line. > > > > > > > > > The bottom line= ,=20 IMHO, is that some clarity regarding > > > co-routed vs. &= gt;=20 > > > > associated > > > > > bidirectional = paths=20 is still required. One way to provide > > > > that=20 could > > > > > be by explicitly limiting Requirement 3= 4 to=20 specific > > > functionality. > > > > >= >=20 > > Agreed. > > > > > > > >=20 Adrian > > > > > > > > > > > = >=20 > > > > > > > >=20 ________________________________________ > > > > From: Adr= ian=20 Farrel [adrian@o= lddog.co.uk] > > > > Sent: Thursday, April 16,=20 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger= ;=20 BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path > &= gt;=20 > > requirements > > > > > > > > Hi= =20 Sasha, > > > > > > > > Not really sure whe= ther=20 you are misrepresenting anyone, but... > > > > > &g= t;=20 > > > 1. My reading of one of Ben's messages is = that=20 associated > > > > > bidirectional paths are the only = types=20 of paths that can be > > > > created in > > > = >=20 > the existing networks; "true" co-routed bidirectional path= s > >=20 > > will have > > > > > to wait until (if ever) n= ew=20 equipment becomes available. > > > > > > > &g= t;=20 This is clearly nonsense! > > > > From the point of view o= f=20 hardware, co-routed > > bidirectional LSPs are > > >= >=20 a special case of associated bidirectional LSPs. > > > >= =20 > > > > If you can set up two unidirectional LSPs (e.g. u= sing=20 the > > management > > > > plane) you can surely = set=20 up a co-routed > > > bidirectional LSP. > > > >= ;=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using the con= trol=20 plane. These either use the GMPLS > > (which is > > >= ;=20 > cleaner) or non-standard proprietary solutions (which is > >= ;=20 messy but > > > > functional). > > > > = >=20 > > > But (of course) the management plane or control plane &= gt;=20 > solutions have > > > > nothing to do with availabilit= y of=20 equipment as they > are software > > > >=20 solutions. > > > > &g= t; >=20 > > > 2. My reading of one of Neil's messages is that the=20 actual > > > > driver for > > > > > co-r= outed=20 bidirectional paths may be experience with existing > > > &g= t;=20 > transport networks rather than any specific benefit. > > &g= t;=20 > > > > > Isn't that the case with 75% of the MPLS= -TP=20 requirements? > > > > Which is not to say it is a bad=20 thing. > > > > > > > > A large driver for= =20 MPLS-TP is to give the packet network > > the look, > >= >=20 > feel, and behavioral characteristics of a "legacy" >= > > >=20 transport network. > > > > > > > > > Ba= sed=20 on these observations, I'd guess (FWIW) that: > > > > = > *=20 associated bidirectional paths are, at least for the time > > &g= t;=20 > > being, the most important type of bidirectional pa= ths=20 in > > > > > MPLS-TP > > > >= ;=20 > > > > I think that is wrong both given my statement abo= ve,=20 and > > given that > > > > other upgrades to exis= ting=20 MPLS solutions will be > needed to reach > > > > the= full=20 function level of MPLS-TP. > > > > > > > >= >=20 * they had a good chance to remain the only type of > >=20 bidirectional > > > > > paths in real=20 deployments. > > > > > > > > I don't s= ee what=20 that follows from. > > > > > > > >=20 Cheers, > > > > Adrian > > > > > >= ;=20 > > _______________________________________________ > > &g= t;=20 > mpls-tp mailing list > > > > mpls-tp@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > >= > >=20 > > > >=20 _______________________________________________ > > > > mp= ls-tp=20 mailing list > > > > mpls-tp@ietf.org > > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > >= >=20 > > > > > >=20 _______________________________________________ > > > mpls-tp= =20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = > >=20 > _______________________________________________ > mpls-tp= =20 mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing=20 list mpls-tp@iet= f.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information&n= bsp;contained in this mail is solely property= of the sender's organization. This mail&= nbsp;communication is confidential. Recipients named&nb= sp;above are obligated to maintain secrecy an= d are not permitted to disclose the cont= ents of this communication to others. This email and any files transmitted with&nbs= p;it are confidential and intended solely for= the use of the individual or entity&nbs= p;to whom they are addressed. If you hav= e received this email in error please no= tify the originator of the message. Any = views expressed in this message are those&nbs= p;of the individual sender. This message has been scanned for viruses&nbs= p;and Spam by ZTE Anti-Spam system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --0016363ba7d6afdba5046827321f-- From maarten.vissers@huawei.com Wed Apr 22 13:49:10 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8865528C0DD for ; Wed, 22 Apr 2009 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzKTLR9SHqpf for ; Wed, 22 Apr 2009 13:49:05 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id DE0EF3A679C for ; Wed, 22 Apr 2009 13:49:05 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042213502105719 ; Wed, 22 Apr 2009 13:50:21 -0700 Received: from M00900002 ([10.84.2.164]) by s-utl01-sjpop.stsn.net; Wed, 22 Apr 2009 13:50:13 -0700 From: "Maarten Vissers" To: "'Greg Mirsky'" Date: Wed, 22 Apr 2009 22:50:05 +0200 Message-ID: <000001c9c38b$f0da0420$a402540a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C9C39C.B462D420" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <787be2780904220924x6de8f364j58f03416f57d8f72@mail.gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnDaGVH5lgSH93mS5aIaxGZn3sGEwAIv0Eg Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:49:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C9C39C.B462D420 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Greg, =20 Do you mean that there is a layer network above MPLS-TP that will = support these services from UNI-N port to UNI-N port, and that MPLS-TP will = support this service layer network? =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I believe that it is not a requirement for MPLS-TP to support any = specific service, including ones you've listed in your message. On the other = hand, support of listed services is a requirement for a client layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers Neil, =20 I expect that the main requirement for a packet transport network = technology like MPLS-TP is that it is able to support at least the following = services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed manner. =20 Another main requirement is that it must be able to support those = services in a scalable manner between points anywhere in the world. =20 The E-Line, E-Tree and E-LAN services allow to reorder client frames = that belong to different priorities and to drop client frames that are drop eligible. =20 The E-Tree and E-LAN services require that client bits are read to = deliver the frames to the appropriate output port or ports of the E-Tree or = E-LAN supporting transport entity/differentiated connection. =20 The packet transport network technology must as such support traffic engineered transport entities (differentiated connections) with n input ports (i.e. multi source constructs). This in addition of traffic = engineered transport entities with 1 input port. =20 Regards, Maarten _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these. =20 1 Provide a transparent client/server relationship...which means: - all client bits treated equally - client bit ordering preserved - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols - the traffic behaviour of client X must not impact the performance experienced by client Y =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs) =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology. =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise. =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones). =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong. =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim. =20 regards, Neil =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , =B3=AD=CB=CD mpls-tp@ietf.org =09 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ------=_NextPart_000_0001_01C9C39C.B462D420 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Greg, Do you mean that there is a layer network above = MPLS-TP=20 that will support these services from UNI-N port to UNI-N port, and that = MPLS-TP=20 will support this service layer network? Regards, Maarten From: Greg Mirsky = [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten=20 Vissers Cc: neil.2.harrison@bt.com;=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Dear Maarten, I believe that it is not a requirement for = MPLS-TP=20 to support any specific service, including ones you've listed in your = message.=20 On the other hand, support of listed services is a requirement for a = client=20 layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com= > Neil, I expect=20 that the main requirement for a packet transport network = technology like=20 MPLS-TP is that it is able to support at least the following=20 services: -=20 E-Line -=20 E-Tree -=20 E-LAN - PDH=20 CES in a=20 traffic engineered and managed manner. Another=20 main requirement is that it must be able to support those services in = a=20 scalable manner between points anywhere in the = world. The=20 E-Line, E-Tree and E-LAN services allow to reorder client frames = that=20 belong to different priorities and to drop client frames that are = drop=20 eligible. The E-Tree=20 and E-LAN services require that client bits are read to deliver the = frames to=20 the appropriate output port or ports of the E-Tree or E-LAN = supporting=20 transport entity/differentiated connection. The packet=20 transport network technology must as such support traffic=20 engineered transport entities (differentiated connections) with n = input=20 ports (i.e. multi source constructs). This in addition of traffic = engineered=20 transport entities with 1 input port. Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 = april 2009=20 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path = requirements Liu, If MPLS-TP is going to be taken seriously as a transport = network (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. 1    Provide a transparent client/server=20 relationship...which means: -    all client bits treated = equally -    client bit ordering = preserved -    no attempt to infer client symbol (ie = sequence of=20 client bits) meaning and no attempt to change client=20 symbols -    the traffic behaviour of client X must = not impact=20 the performance experienced by client Y A key corollary of the above is that MPLS-TP must only = support proper=20 connections (ie single source constructs) 2   Since MPLS-TP is a transport network it is not = a=20 top-of-stack network (ie it does not support directly external=20 message/file/stream applications). MPLS-TP therefore does not = require an=20 E-NNI specification. A key corollary of this is that MPLS-TP = will not=20 have any peer interworking relationship with any other network=20 mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. You could = argue this=20 should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE = (also a=20 co-ps mode network) should have FDI/AIS we concluded that on balance = it was=20 not a good idea.....and note that initially I was in favour of having = AIS, but=20 my colleagues provided strong technical arguments that convinced me=20 otherwise. AIS/FDI is historically linked to the early PDH = co-cs mode=20 layer networks that used TTL logic. When this died it put out a = +5V (all=20 1s) signal by default, ie it required no conscious effort to generate=20 it.....this is key point. Further, in these networks there is a = fairly=20 static/long-holding client server relationship. Clearly this is = not true=20 in the cl-ps mode and it's why IETF have never specified AIS for IP = and its=20 why IEEE had the good sense to throw-out AIS in 802.1ag for Ethernet = (though=20 ITU have unwisely IMO retained it in Y.1731....but I suspect any = operator=20 planning to use Ethernet equipment would always look to IEEE stds and = not ITU=20 ones). AIS/FDI and the co-ps mode is debatable. = As I noted=20 above, on balance we considered not a good idea for PBB-TE OAM because = it=20 requires a conscious effort to generate it (unlike the co-cs mode) so = there=20 are likely to be scaling problems and its one more thing to go=20 wrong. You should also have seen me make the point many = times in=20 the past that the always-on defect detection/handling OAM needs to be = as=20 simple/sparse as possible with as little config as possible because we = need=20 super reliability......TCM goes completely against the grain = here. Also=20 note that the OAM required for each of the 3 network modes is not the = same,=20 despite what some claim. regards, Neil From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of liu.guoman@zte.com.cn Sent: 21 April = 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path = requirements Deborah: maybe = what you said=20 is right. but I can't completely agree your opinions. IMO. mpls-tp = is regard=20 as transport network like SDH/SONET. so it should have AIS/FDI = fuctions as=20 SDH/SONET. do you = think=20 so. best = regards=20 liu "BRUNG= ARD, DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47 =CA= =D5=BC=FE=C8=CB "Maarten Vis= sers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com>=20 =B3= =AD=CB=CD mpls-tp@ietf.org=20 =D6= =F7=CC=E2 Re: [mpls-tp] Ass= ociated=20 bidirectional transport path=20 requirements "BRUNGARD, = DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47 = =CA=D5=BC=FE=C8=CB "Maarten Vissers" = <maarten.vissers@huawei.com>, = <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 size=3D2>I agree with Neil, it is very questionable the value of = AIS/FDI=20 in a packet network- any mode. It can result in a DoS attack by = an=20 operator on themselves so even Y1731 recommends not to block data = frames: "A MEP can decide whether it blocks data frames when it = detects=20 dAIS. The principle requirement that influences this decision = is that=20 data frames ought to be forwarded as much as possible, = without the=20 possibility of forwarding wrong data frames downstream." Table = I.7-2=20 shows for AIS, not to block. And as Y1731 states, AIS can = only be=20 used under very constrained architectures - if required for = MPLS-TP, it=20 needs to have the same guidance as in Y1731, i.e. point-to-point = and=20 server/client one-to-one: "for a point-to-point ETH connection, a = MEP has=20 only a single peer MEP. Therefore, there is no ambiguity = regarding the=20 peer MEP for which it should suppress alarms when it receives=20 the ETH-AIS information." So should only be within one domain = - then=20 no need. Deborah -----Original Message----- From: = mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport = path requirements Neil, > but=20 AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is = indeed a=20 requirement and a necessity. And you will not be able to = understand=20 that as long as you refuse to accept that "cl-mode" is = a forwarding=20 mode within a **transport entity**. G.800 amendment 1=20 has finally reintroduced this transport entity into G.800. = Besides=20 that, it also introduced the **differentiated = connection**: [G.800=20 am1] "A differentiated connection is a transport entity = that transfers=20 information belonging to multiple communications between = ports across a=20 subnetwork. <..> In a differentiated connection=20 message contents are interpreted to identify (sets of) = communications=20 which receive different treatment. The sets of = communications=20 may be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved between = messages=20 belonging to sets of communications receiving different = treatment.=20 Sets of communications may be identified = for purposes such as=20 traffic conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 = "differentiated=20 connections". Ethernet AIS provides AIS within the scope of = such=20 "differentiated connection". If you apply this to my proposed = PTN=20 layer stack, then the EVC layer topology will consists of EVC = links=20 supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails = inside=20 metro and core domains interconnecting EVC matrices. When one = of those=20 EVC links is interrupted, e.g. in the core between metro = 1 and metro 4=20 (see attached slide), then the EVC differentiated connection that = is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS is = inserted=20 in the downstream direction to suppress the EVC-LOC alarms at EVC = endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) = frame has=20 a reserved multicast address, which guarantees that the AIS is = broadcast=20 to the endpoints of the EVC. I believe that it is time for = you to=20 adapt your view on co and cl modes and relate it to the = forwarding=20 mode **INSIDE** a transport entity. What we know as the = internet is=20 essentially an "IP differentiated connection" with a billion or = more=20 ports. What we know as an IP VPN is essentially an "IP=20 differentiated connection" with e.g. n ports (n in the range = of e.g. 2=20 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in the = range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially = an "MPLS=20 differentiated connection" with 2 ports. What we know as a p2p = SDH=20 VC-n is a "SDH VC-n connection" with 2 ports. Transport = network OAM=20 applies to transport entities, which are (in terms of G.800 = am1)=20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 = april 2009=20 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements John, = Thanks this=20 is a great platform to explain why OAM for the 3 network modes = needs=20 to be different. I am getting a wee bit tired of = folks trying to=20 make all 3 network modes look alike (and then, even worse,=20 interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I = am even=20 more frustrated by the fact those peddling this FUD only ever = seem to=20 consider OAM and forget all other DP/CP/MP components (esp=20 top-of-stack message/file/stream application adaptations). = How=20 wrong can this get! In the co modes a *connection* is a very = specific and *constraining* construct.....I am assuming here we = respect=20 the rules of a connection (ie single source) though some folks = don't=20 even bother to respect this, and this is despite the fact that = we all=20 know what problems multiple-source constructs can cause (from=20 LDP/PHP....ergo MPLS-TP). When we have a connection this = restricts=20 *all* DP (ie traffic and OAM) to stay within the bounds of the = connection. Which is fine under defect-free conditions, = but if=20 we have leaking traffic then the constraining nature of the = connection=20 construct is broken. In a nutshell what this means = is that OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity defects.....indeed, why = should a=20 leaking DP have a symmetric go/return defect = behaviour?....very likely=20 it won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and not = just in=20 OAM requirements....but AIS/FDI in the cl mode?...do me a = favour!...at=20 least IEEE had the good sense to bin this for Ethernet even = though it=20 remains in Y.1731. And which is why I often trot-out the = rather=20 silly (to have to say this) observation that if IP (cl mode) = could do=20 it all then why have IETF found it necessary to create MPLS = (co-ps)=20 and GMPLS (CP for co-cs). The answer lies in the = physics...and=20 G.800 attempts to explain that physics....G.805 does = not. So, the=20 3 modes are different...please accept/rejoice in this fact = as they all=20 offer something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the OAM of = the 3=20 modes the same. regards, Neil > -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, = John=20 E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; = Alexander=20 Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > requirements > >=20 Italo, > > As described in the MPLS TP OAM Requirements = I-D,=20 virtually all of the > OAM functions require a return = path, and in=20 the absence of a return > path they are disabled. > = > As=20 described in David Sinicrope's meeting minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/w= iki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP = addressing=20 is used, an > MPLS TP network needs to be capable of getting = IP=20 packets from > destination to source; neither the minutes nor = I=20 stipulate that a > control plane needs to be used to = instantiate this=20 forwarding. > > As an aside, the issue of return path = for=20 unidirectional LSPs could be > charaterized as the = elephant in the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs = are only=20 mentioned three times and return > paths not at all. > = >=20 Thanks, > > John > > -----Original=20 Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: = Friday,=20 April 17, 2009 1:59 AM > > To: Drake, John E; Alexander = Vainshtein;=20 Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path > > = requirements >=20 > > > John, > > > > I might have = missed the=20 agreement of MPLS-TP being capable of > > sending replies = to OAM=20 requests sent on uni-directional LSPs. > > > > = This=20 requirement does not belong to the first set of requirements = > >=20 ITU-T is expecting to be met by October. > > > > = However,=20 I think this in a potential interesting additional > > = requirement=20 to be taken into account (at worst in a > subsequent = phase). >=20 > > > I think that this requirement needs to be = evaluated=20 versus other > > more important requirements (e.g. the = possibility=20 to work w/o IP > > forwarding and the need for OAM to = continue to=20 monitor the data > > plane also in case of failures = affecting the=20 control or management > > plane). > > > = > I am=20 open to discuss it but not sure this is the right time because = > >=20 I wish to avoid delaying the first phase of the design = solution. >=20 > > > Thanks, Italo > > > > >=20 -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, = John=20 E > > > Sent: Thursday, April 16, 2009 8:00 PM > = > >=20 To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > requirements > > > > > > = At the=20 meeting last fall at Juniper in Massachusetts, I > > think = it=20 was > > > agreed that an MPLS TP network needs to have a = forwarding > > capability > > > for management, = control, and OAM packets (e.g., sending > > replies to = OAM >=20 > > requests sent on uni-directional LSPs) even if it does = not >=20 > have an IP > > > forwarding data plane. > = > >=20 > > > > -----Original Message----- > > > = >=20 From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > = > >=20 Sent: Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > > = Maarten, >=20 > > > It seems that you've just (implicitly and, = probably, >=20 > > > inadvertently) stated the following: > > = > >=20 > > > > = =20 MPLS-TP OAM will not ever support MIP loopback = function >=20 > (and fault > > > > localization which requires = this=20 function ) for > > unidirectional P2MP > > > = > and=20 P2P paths. > > > > > > > > If this = statement=20 is correct, this (IMHO and FWIW) > raises a valid > > = >=20 > question: > > > > > > > > = =20 Is MPLS-TP an = appropriate=20 solution for these > types of transport > > > > = paths? > > > > > > > > For the = reference,=20 IP/MPLS provides this kind of > > functionality = today > >=20 > > for (unidirectional - but it does not know any = other > >=20 type) P2P LSPs > > > > as described in RFC 4379. And = its=20 extension to P2MP LSPs seems > > > > easy... > = >=20 > > > > > > > > > > = >=20 > > > Regards, > > > > > > > = >=20 Sasha > > > > > > > = >=20 > > > > > > > >=20 ________________________________________ > > > > = From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On = Behalf >=20 > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > = > Sent:=20 Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian=20 Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > > = Adrian, >=20 > > > > > > > >> = <quote> > >=20 > > >> The intermediate nodes = (including=20 MEPs, MIPs and > > > > other internal > > = > >=20 >> functions as appropriate) of a=20 co-routed > > > > bidirectional transport > = > >=20 > >> path at each (sub-)layer MUST be = aware of=20 the pairing > > > > >> =20 relationship of the forward and the backward > > > >=20 directions of that > > > > >> = =20 transport path. > > > > >> <end = quote> >=20 > > > > > > > > > There is no way this = is a=20 functional requirement. That > > > is, there is > = >=20 > > > *nothing* that can be observed from a black box point = of > > > view that > > > > > results = from=20 adhering to this requirement. > > > > > > = > >=20 Your understanding is not correct. It is very much > = observable=20 if > > > > this requirement is met from a black box = point of=20 view. > > > > The MIP functions can only perform the = Loopback=20 when there is a > > > > co-routed bidirectional = transport=20 path. The MPLS-TP LBM packet > > > > received at a = MIP needs=20 to be returned (as LBR > > > > packet) to the = originating MEP=20 function via the other > > direction of > > > = > the=20 co-routed bidirectional transport path. This other > = direction >=20 > > > would not be available in an associated bidirectional = transport > > > > path... and thus the loopback = test >=20 > > would fail. > > > > > > > > = Similarly, when we have to apply TCM MEPs to monitor a > > = segment,=20 then > > > > this is possible in a co-routed bidir = transport=20 path > but not in a > > > > associated bidir = transport=20 path. In the first case the TCM MEP > > > > Source = and Sink=20 functions are co-located and can > exchange what is > = > >=20 > called "remote information" which is necessary for performance = >=20 > > > monitoring. > > > > In the latter case = the TCM=20 MEP Source and Sink functions > > are in e.g. > > = >=20 > different nodes in the network and TCM would not be = able > >=20 to provide > > > > performance monitoring. > = > >=20 > > > > > > The entirety of the bracketted = text=20 "(including MEPs, > > > MIPs and other > > > = >=20 internal > > > > > functions as appropriate)" = should be=20 deleted. It does not > > > > add to "The > > = >=20 > > intermediate nodes." > > > > > > = >=20 > Your understanding is not correct. This text must not = be > >=20 deleted at > > > > all. > > > > = > >=20 > > > Actually, I am quite fed up about this = persistent >=20 > > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > > = is >=20 > > > poorly > > > > > specified and = comes from=20 the monitoring of a path that is > > > > parallel=20 (i.e. > > > > tandem) > > > > > to = the data=20 path being monitored. This definition of TC > > > > = seems to=20 be at > > > > variance, > > > > > = and would=20 be if the ACH was actually in band. > > > > > = >=20 > > I don't understand where your interpretation of = tandem >=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of a > = >=20 > > path that is parallel (i.e. tandem) to the data path being = > > > > monitored."? > > > > > = >=20 > > There is a "network connection" and this network > = >=20 connection is a set > > > > of interconnected "link=20 connections" and "matrix > connections". A > > > = >=20 subset of those interconnected link connections and matrix > = >=20 > > connections can be monitored and is then referred to = as > a=20 "tandem > > > > connection". There is no "path that = is=20 parallel to the > > data path". > > > > = There is=20 only additional OAM inserted inside the data > path by = the >=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM MEP_Sk=20 function. > > > > > > > > = Regards, >=20 > > > Maarten > > > > > > > = >=20 > > > > -----Original Message----- > > > = >=20 From: mpls-tp-bounces@ietf.org > > > > = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian=20 Farrel > > > > Sent: donderdag 16 april 2009 = 11:59 >=20 > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > = > Cc:=20 BUSI ITALO; mpls-tp@ietf.org > > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > = Unfortunately I=20 cannot fully agree with your statement: > > > > = > >=20 > > > > <quote> > > > > > = =20 From the point of view of hardware, co-routed > > >=20 bidirectional LSPs > > > > > are a = special=20 case of associated bidirectional LSPs. > > > > > = <end=20 quote> > > > > > > > > > > = This=20 statement would be obviously correct, were it not for > > = > >=20 Requirement > > > > > 34 in the latest MPLS-TP=20 requirements draft > > > > > > > > = OK. Got=20 it. > > > > > > > > But what is this = doing in=20 the data plane requirements section? > > > > > = >=20 > > In fact, what is this requirement actually saying? > = >=20 > > > > > > > <quote> > > = > >=20 > The intermediate nodes (including MEPs, = MIPs=20 and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > > = >=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > = >=20 > > > relationship of the forward and = the=20 backward > > > > directions of that > > > = >=20 > transport path. > > > > = >=20 <end quote> > > > > > > > > = There is no=20 way this is a functional requirement. That > > is, there = is >=20 > > > *nothing* that can be observed from a black box point = of > > view that > > > > results from = adhering to=20 this requirement. > > > > > > > > = Therefore=20 it could be assumed that this requirement is met by > > = > >=20 configuring some data plane database component through the > = >=20 > > management plane. The database component is not = used > for=20 anything > > > > except to satisfy this requirement = for=20 "awareness". > > > > > > > > Ben! Can = we=20 please try to rewrite this requirement in terms of > > = > >=20 behavior? > > > > > > > > > Please = note=20 that Requirement 34 is the ONLY item in the > > > > = list that=20 is > > > > > specific for co-routed bidirectional = LSPs.=20 (The pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = > >=20 paths are > > > > > exactly the same even if they = appear=20 in two different > > > items in the > > > = > >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > = > >=20 bidirectional paths would be void of any data plane content. > = >=20 > > > > > > > > The somewhat vague scope = of this=20 requirement ("other internal > > > > > functions = as=20 appropriate") creates a suspicion that HW > > > > = support of=20 the > > > > > pairing awareness may be required in = order=20 to comply with it. > > > > > > > > = The=20 entirety of the bracketted text "(including MEPs, > > MIPs = and=20 other > > > > internal functions as appropriate)" = should be=20 deleted. It > > does not > > > > add to "The = intermediate nodes." > > > > > > > > = > The=20 following text in the draft increases this suspicion: > > = > >=20 > > > > > > <quote> > > > = > >=20 Tandem Connection: A tandem connection is an > > = arbitrary=20 part of a > > > > > transport path that can = be=20 monitored (via OAM) > > > > independently from = the >=20 > > > > end-to-end monitoring (OAM). It may = be a=20 monitored > > segment or a > > > > > = =20 monitored concatenated segment of a transport path. > = > The=20 tandem > > > > > connection may also = include the=20 forwarding engine(s) of > > > > the node(s) > = > >=20 > > at the edge(s) of the segment or concatenated=20 segment. > > > > > <end quote> > > = >=20 > > > > > Actually, I am quite fed up about this=20 persistent > > insistence on the > > > > = inclusion=20 of "Tandem Connection." The definition within > > the ITU-T = of > > > > this term is poorly specified and comes = from=20 the > monitoring of a > > > > path that is = parallel=20 (i.e. tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > > = >=20 > > > > > Doesn't "forwarding engine" sound like = hardware=20 to you? > > > > > > > > Yes, but so=20 what? > > > > > > > > > IMHO it is = worth=20 noting that neither the MPLS-TP > > > Requirements = draft >=20 > > > > nor the MPLS-TP OAM requirements one > = > >=20 > > > > > > > > > > > = >=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing with = tandem > > > connections. > > > > = > >=20 > > > > But tandem connections are discussed in the = MPLS-TP=20 OAM > > Framework > > > > > draft > = >=20 > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-fr >=20 > > > amework-00.txt > > > > ). > > = >=20 > > > > > Right. > > > > Let's = just get=20 rid of an unnecessary term and bring all > the I-Ds > = > >=20 > into line. > > > > > > > > > = The=20 bottom line, IMHO, is that some clarity regarding > > >=20 co-routed vs. > > > > > associated > > = > >=20 > bidirectional paths is still required. One way to = provide > >=20 > > that could > > > > > be by explicitly = limiting=20 Requirement 34 to specific > > > functionality. > = >=20 > > > > > > Agreed. > > > > = >=20 > > > Adrian > > > > > > > > = > > > > > > > > > > > = >=20 ________________________________________ > > > > = From: Adrian=20 Farrel [adrian@olddog.co.uk] > > > > = Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org >=20 > > > Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path > > > > requirements > > > > = >=20 > > > Hi Sasha, > > > > > > > = > Not=20 really sure whether you are misrepresenting anyone, but... > = > >=20 > > > > > > 1. My reading of one of = Ben's=20 messages is that associated > > > > > = bidirectional=20 paths are the only types of paths that can be > > > > = created=20 in > > > > > the existing networks; "true" = co-routed=20 bidirectional paths > > > > will have > > = > >=20 > to wait until (if ever) new equipment becomes = available. > >=20 > > > > > > This is clearly nonsense! > = >=20 > > From the point of view of hardware, co-routed > > = bidirectional LSPs are > > > > a special case of = associated=20 bidirectional LSPs. > > > > > > > > = If you=20 can set up two unidirectional LSPs (e.g. using the > >=20 management > > > > plane) you can surely set up a=20 co-routed > > > bidirectional LSP. > > > = >=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using = the=20 control plane. These either use the GMPLS > > (which = is >=20 > > > cleaner) or non-standard proprietary solutions (which = is > > messy but > > > > = functional). > >=20 > > > > > > But (of course) the management = plane or=20 control plane > > solutions have > > > > = nothing to=20 do with availability of equipment as they > are = software > >=20 > > solutions. > > > > > > > > > 2. My reading of one of Neil's = messages=20 is that the actual > > > > driver for > > = > >=20 > co-routed bidirectional paths may be experience with existing = >=20 > > > > transport networks rather than any specific=20 benefit. > > > > > > > > Isn't that = the case=20 with 75% of the MPLS-TP requirements? > > > > Which = is not to=20 say it is a bad thing. > > > > > > > = > A=20 large driver for MPLS-TP is to give the packet network > > = the=20 look, > > > > feel, and behavioral characteristics of = a=20 "legacy" > > > > transport network. > > > = >=20 > > > > > Based on these observations, I'd guess = (FWIW)=20 that: > > > > > * associated bidirectional paths = are, at=20 least for the time > > > > > being, = the most=20 important type of bidirectional paths in > > > > > = =20 MPLS-TP > > > > > > > > I think = that is=20 wrong both given my statement above, and > > given = that >=20 > > > other upgrades to existing MPLS solutions will = be >=20 needed to reach > > > > the full function level of=20 MPLS-TP. > > > > > > > > > * they = had a=20 good chance to remain the only type of > > = bidirectional >=20 > > > > paths in real deployments. > = >=20 > > > > > > I don't see what that follows=20 from. > > > > > > > > Cheers, > = >=20 > > Adrian > > > > > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= >=20 > > > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= >=20 > > > > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= >=20 > > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 _______________________________________________ mpls-tp = mailing=20 list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ----------------------------------------------------= ---- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ________________________________= _______________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp = ------=_NextPart_000_0001_01C9C39C.B462D420-- From gregimirsky@gmail.com Wed Apr 22 13:59:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6253A6AF3 for ; Wed, 22 Apr 2009 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZvOivtdaKm7 for ; Wed, 22 Apr 2009 13:59:09 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 43CA23A6D5A for ; Wed, 22 Apr 2009 13:59:07 -0700 (PDT) Received: by bwz7 with SMTP id 7so197733bwz.37 for ; Wed, 22 Apr 2009 14:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=r9jAlealvpRcgzjuDeWHmDZADYT8nIl+dSS7+r4fyIA=; b=xxn5ffKMYo79Yz+dkUqebcUNRdG+agxXR/B8wyM+nEkaQQebtSkd86rLwIXuJO97yi TajHtwFM8du0QXZisAMc+VFNtTa8lJW4w1ID5iTz7kuHXhk8vUg4W4SYClPB/UcfGuf2 CmJv82FQKYeK3Cpi585cM6OisfjI5Rcaa4/kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G9VFKQNqZa1xHNlfUGhSRtgsMLVviWeMshlgtoO2RDq48Q8sHee3nj2t5x3f2LY9OX hGK5uSSf7vsgz/xYTVYgRehYTeGgRf1IgGtA0vJTtP72YNmXvjpef5xvAul1ZAcc5rNo O5jdLWhfWO+bWh6RFMCOFDojqci0Gseb8M/bQ= MIME-Version: 1.0 Received: by 10.103.223.2 with SMTP id a2mr123708mur.88.1240434024471; Wed, 22 Apr 2009 14:00:24 -0700 (PDT) In-Reply-To: <000001c9c38b$f0da0420$a402540a@china.huawei.com> References: <787be2780904220924x6de8f364j58f03416f57d8f72@mail.gmail.com> <000001c9c38b$f0da0420$a402540a@china.huawei.com> Date: Wed, 22 Apr 2009 14:00:24 -0700 Message-ID: <787be2780904221400j14cdf9c6gfa562548dd808516@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=00163642702b655db604682b0d63 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:59:14 -0000 --00163642702b655db604682b0d63 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, I think you've captured my view pretty accurately. Since MPLS-TP supports only p2p and p2mp transports it would be responsibility of another layer to support specific services among UNI-Ns. Interesting thing that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP LSP since by MEF's definition E-Tree is a bidirectional service. (Just a note). Kind regards, Greg 2009/4/22 Maarten Vissers > Dear Greg, > > Do you mean that there is a layer network above MPLS-TP that will support > these services from UNI-N port to UNI-N port, and that MPLS-TP will suppo= rt > this service layer network? > > Regards, > Maarten > > ------------------------------ > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* woensdag 22 april 2009 18:25 > *To:* Maarten Vissers > *Cc:* neil.2.harrison@bt.com; mpls-tp@ietf.org > > *Subject:* Re: [mpls-tp] Associated bidirectional transport path > requirements > > Dear Maarten, > I believe that it is not a requirement for MPLS-TP to support any specifi= c > service, including ones you've listed in your message. On the other hand, > support of listed services is a requirement for a client layer that uses > MPLS-TP services. > > Regards, > Greg Mirsky > > 2009/4/22 Maarten Vissers > >> Neil, >> >> I expect that the main requirement for a packet transport network >> technology like MPLS-TP is that it is able to support at least the follo= wing >> services: >> - E-Line >> - E-Tree >> - E-LAN >> - PDH CES >> in a traffic engineered and managed manner. >> >> Another main requirement is that it must be able to support those servic= es >> in a scalable manner between points anywhere in the world. >> >> The E-Line, E-Tree and E-LAN services allow to reorder client frames tha= t >> belong to different priorities and to drop client frames that are drop >> eligible. >> >> The E-Tree and E-LAN services require that client bits are read to deliv= er >> the frames to the appropriate output port or ports of the E-Tree or E-LA= N >> supporting transport entity/differentiated connection. >> >> The packet transport network technology must as such support traffic >> engineered transport entities (differentiated connections) with n input >> ports (i.e. multi source constructs). This in addition of traffic engine= ered >> transport entities with 1 input port. >> >> Regards, >> Maarten >> >> ------------------------------ >> *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On >> Behalf Of *neil.2.harrison@bt.com >> *Sent:* dinsdag 21 april 2009 14:31 >> *To:* liu.guoman@zte.com.cn; dbrungard@att.com >> >> *Cc:* mpls-tp@ietf.org >> *Subject:* Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Liu, >> >> If MPLS-TP is going to be taken seriously as a transport network (like >> SDH/SONET) then the 2 key MUST HAVE requirements are these. >> >> 1 Provide a transparent client/server relationship...which means: >> - all client bits treated equally >> - client bit ordering preserved >> - no attempt to infer client symbol (ie sequence of client bits) >> meaning and no attempt to change client symbols >> - the traffic behaviour of client X must not impact the performance >> experienced by client Y >> >> A key corollary of the above is that MPLS-TP must only support proper >> connections (ie single source constructs) >> >> >> 2 Since MPLS-TP is a transport network it is not a top-of-stack networ= k >> (ie it does not support directly external message/file/stream >> applications). MPLS-TP therefore does not require an E-NNI specificatio= n. >> A key corollary of this is that MPLS-TP will not have any peer interwork= ing >> relationship with any other network mode/technology. >> >> >> Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this shoul= d >> have FDI/AIS....however, the merit of this is highly questionable. When= I >> and colleagues discussed whether PBB-TE (also a co-ps mode network) shou= ld >> have FDI/AIS we concluded that on balance it was not a good idea.....and >> note that initially I was in favour of having AIS, but my colleagues >> provided strong technical arguments that convinced me otherwise. >> >> AIS/FDI is historically linked to the early PDH co-cs mode layer network= s >> that used TTL logic. When this died it put out a +5V (all 1s) signal by >> default, ie it required no conscious effort to generate it.....this is k= ey >> point. Further, in these networks there is a fairly static/long-holding >> client server relationship. Clearly this is not true in the cl-ps mode = and >> it's why IETF have never specified AIS for IP and its why IEEE had the g= ood >> sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely= IMO >> retained it in Y.1731....but I suspect any operator planning to use Ethe= rnet >> equipment would always look to IEEE stds and not ITU ones). >> >> AIS/FDI and the co-ps mode is debatable. As I noted above, on balance w= e >> considered not a good idea for PBB-TE OAM because it requires a consciou= s >> effort to generate it (unlike the co-cs mode) so there are likely to be >> scaling problems and its one more thing to go wrong. >> >> You should also have seen me make the point many times in the past that >> the always-on defect detection/handling OAM needs to be as simple/sparse= as >> possible with as little config as possible because we need super >> reliability......TCM goes completely against the grain here. Also note = that >> the OAM required for each of the 3 network modes is not the same, despit= e >> what some claim. >> >> regards, Neil >> >> >> ------------------------------ >> *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On >> Behalf Of *liu.guoman@zte.com.cn >> *Sent:* 21 April 2009 02:59 >> *To:* BRUNGARD, DEBORAH A, ATTLABS >> *Cc:* mpls-tp@ietf.org >> *Subject:* Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> >> Deborah: >> maybe what you said is right. but I can't completely agree your opinion= s. >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it should >> have AIS/FDI fuctions as SDH/SONET. >> >> do you think so. >> >> best regards >> liu >> >> >> *"BRUNGARD, DEBORAH A, ATTLABS" * >> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org >> >> 2009-04-20 23:47 >> =CA=D5=BC=FE=C8=CB >> "Maarten Vissers" , >> =B3=AD=CB=CD >> mpls-tp@ietf.org =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> I agree with Neil, it is very questionable the value of AIS/FDI in a >> packet network- any mode. It can result in a DoS attack by an operator >> on themselves so even Y1731 recommends not to block data frames: >> "A MEP can decide whether it blocks data frames when it detects dAIS. >> The principle requirement >> that influences this decision is that data frames ought to be forwarded >> as much as possible, without >> the possibility of forwarding wrong data frames downstream." >> Table I.7-2 shows for AIS, not to block. >> >> And as Y1731 states, AIS can only be used under very constrained >> architectures - if required for MPLS-TP, it needs to have the same >> guidance as in Y1731, i.e. point-to-point and server/client one-to-one: >> "for a point-to-point ETH connection, a MEP has only a single peer MEP. >> Therefore, there >> is no ambiguity regarding the peer MEP for which it should suppress >> alarms when it receives the >> ETH-AIS information." >> So should only be within one domain - then no need. >> >> Deborah >> >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of Maarten Vissers >> Sent: Monday, April 20, 2009 10:05 AM >> To: neil.2.harrison@bt.com >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Neil, >> >> > but AIS/FDI in the cl mode?...do me a favour! >> >> Ethernet AIS is indeed a requirement and a necessity. And you will not >> be >> able to understand that as long as you refuse to accept that "cl-mode" >> is a >> forwarding mode within a **transport entity**. G.800 amendment 1 has >> finally >> reintroduced this transport entity into G.800. Besides that, it also >> introduced the **differentiated connection**: >> >> [G.800 am1] "A differentiated connection is a transport entity that >> transfers information belonging to multiple communications between ports >> across a subnetwork. <..> In a differentiated connection message >> contents >> are interpreted to identify (sets of) communications which receive >> different >> treatment. The sets of communications may be distinguished by the >> forwarding identifier or other layer information. Order is not >> necessarily >> preserved between messages belonging to sets of communications receiving >> different treatment. Sets of communications may be identified for >> purposes >> such as traffic conditioning or preserving communication message order." >> >> >> Ethernet VLANs are in terms of G.800 "differentiated connections". >> Ethernet >> AIS provides AIS within the scope of such "differentiated connection". >> If >> you apply this to my proposed PTN layer stack, then the EVC layer >> topology >> will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and >> P-OTN >> VP trails inside metro and core domains interconnecting EVC matrices. >> When >> one of those EVC links is interrupted, e.g. in the core between metro 1 >> and >> metro 4 (see attached slide), then the EVC differentiated connection >> that is >> present on this link will be interrupted. At the EVC switch/bridge node >> in >> metro 4 this interruption is noticed and EVC-AIS is inserted in the >> downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 >> and >> D5. >> >> The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, >> which guarantees that the AIS is broadcast to the endpoints of the EVC. >> >> I believe that it is time for you to adapt your view on co and cl modes >> and >> relate it to the forwarding mode **INSIDE** a transport entity. >> >> What we know as the internet is essentially an "IP differentiated >> connection" with a billion or more ports. >> What we know as an IP VPN is essentially an "IP differentiated >> connection" >> with e.g. n ports (n in the range of e.g. 2 to 1000). >> What we know as an Ethernet VLAN is essentially an "Ethernet >> differentiated >> connection" with n ports (n in the range of e.g. 2 to 1000). >> What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated >> connection" with 2 ports. >> What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. >> >> Transport network OAM applies to transport entities, which are (in terms >> of >> G.800 am1) connections and differentiated connections. >> >> Regards, >> Maarten >> >> -----Original Message----- >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: vrijdag 17 april 2009 22:00 >> To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; >> Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] Associated bidirectional transport path >> requirements >> >> John, Thanks this is a great platform to explain why OAM for the 3 >> network >> modes needs to be different. I am getting a wee bit tired of folks >> trying >> to make all 3 network modes look alike (and then, even worse, interwork >> them >> as as peers...esp when not not top-of-stack >> networks...I mean how silly can we get?). I am even more frustrated by >> the fact those peddling this FUD only ever seem to consider OAM and >> forget >> all other DP/CP/MP components (esp top-of-stack message/file/stream >> application adaptations). How wrong can this get! >> >> In the co modes a *connection* is a very specific and *constraining* >> construct.....I am assuming here we respect the rules of a connection >> (ie >> single source) though some folks don't even bother to respect this, and >> this >> is despite the fact that we all know what problems multiple-source >> constructs can cause (from LDP/PHP....ergo MPLS-TP). >> >> When we have a connection this restricts *all* DP (ie traffic and OAM) >> to >> stay within the bounds of the connection. Which is fine under >> defect-free >> conditions, but if we have leaking traffic then the constraining nature >> of >> the connection construct is broken. In a nutshell what this means is >> that >> OAM that is of a request/response nature cannot be trusted in co mode >> networks under misconnectivity defects.....indeed, why should a leaking >> DP >> have a symmetric go/return defect behaviour?....very likely it won't. >> So >> whilst request/response OAM is right for the cl mode it is not right for >> the >> co mode under misconnectivity defect conditions. >> >> More generally the 3 modes are different and not just in OAM >> requirements....but AIS/FDI in the cl mode?...do me a favour!...at least >> IEEE had the good sense to bin this for Ethernet even though it remains >> in >> Y.1731. And which is why I often trot-out the rather silly (to have to >> say >> this) observation that if IP (cl mode) could do it all then why have >> IETF >> found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The >> answer lies in the physics...and G.800 attempts to explain that >> physics....G.805 does not. >> >> So, the 3 modes are different...please accept/rejoice in this fact as >> they >> all offer something different/important. But do not be hoodwinked by >> those >> who peddle a story that that tries to make the OAM of the 3 modes the >> same. >> >> regards, Neil >> >> > -----Original Message----- >> > From: mpls-tp-bounces@ietf.org >> > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >> > Sent: 17 April 2009 20:02 >> > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers >> > Cc: mpls-tp@ietf.org >> > Subject: Re: [mpls-tp] Associated bidirectional transport path >> > requirements >> > >> > Italo, >> > >> > As described in the MPLS TP OAM Requirements I-D, virtually all of the >> >> > OAM functions require a return path, and in the absence of a return >> > path they are disabled. >> > >> > As described in David Sinicrope's meeting minutes >> > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >> > meeting-no >> > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an >> > MPLS TP network needs to be capable of getting IP packets from >> > destination to source; neither the minutes nor I stipulate that a >> > control plane needs to be used to instantiate this forwarding. >> > >> > As an aside, the issue of return path for unidirectional LSPs could be >> >> > charaterized as the elephant in the room. In the MPLS TP OAM >> > Framework I-D, unicast LSPs are only mentioned three times and return >> > paths not at all. >> > >> > Thanks, >> > >> > John >> > > -----Original Message----- >> > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >> > > Sent: Friday, April 17, 2009 1:59 AM >> > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers >> > > Cc: mpls-tp@ietf.org >> > > Subject: RE: [mpls-tp] Associated bidirectional transport path >> > > requirements >> > > >> > > John, >> > > >> > > I might have missed the agreement of MPLS-TP being capable of >> > > sending replies to OAM requests sent on uni-directional LSPs. >> > > >> > > This requirement does not belong to the first set of requirements >> > > ITU-T is expecting to be met by October. >> > > >> > > However, I think this in a potential interesting additional >> > > requirement to be taken into account (at worst in a >> > subsequent phase). >> > > >> > > I think that this requirement needs to be evaluated versus other >> > > more important requirements (e.g. the possibility to work w/o IP >> > > forwarding and the need for OAM to continue to monitor the data >> > > plane also in case of failures affecting the control or management >> > > plane). >> > > >> > > I am open to discuss it but not sure this is the right time because >> > > I wish to avoid delaying the first phase of the design solution. >> > > >> > > Thanks, Italo >> > > >> > > > -----Original Message----- >> > > > From: mpls-tp-bounces@ietf.org >> > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >> > > > Sent: Thursday, April 16, 2009 8:00 PM >> > > > To: Alexander Vainshtein; Maarten Vissers >> > > > Cc: mpls-tp@ietf.org >> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >> > > > requirements >> > > > >> > > > At the meeting last fall at Juniper in Massachusetts, I >> > > think it was >> > > > agreed that an MPLS TP network needs to have a forwarding >> > > capability >> > > > for management, control, and OAM packets (e.g., sending >> > > replies to OAM >> > > > requests sent on uni-directional LSPs) even if it does not >> > > have an IP >> > > > forwarding data plane. >> > > > >> > > > > -----Original Message----- >> > > > > From: Alexander Vainshtein >> > > > [mailto:Alexander.Vainshtein@ecitele.com] >> > > > > Sent: Thursday, April 16, 2009 9:57 AM >> > > > > To: Maarten Vissers >> > > > > Cc: mpls-tp@ietf.org >> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >> > > > > requirements >> > > > > >> > > > > Maarten, >> > > > > It seems that you've just (implicitly and, probably, >> > > > > inadvertently) stated the following: >> > > > > >> > > > > MPLS-TP OAM will not ever support MIP loopback >> function >> > > (and fault >> > > > > localization which requires this function ) for >> > > unidirectional P2MP >> > > > > and P2P paths. >> > > > > >> > > > > If this statement is correct, this (IMHO and FWIW) >> > raises a valid >> > > > > question: >> > > > > >> > > > > Is MPLS-TP an appropriate solution for these >> > types of transport >> > > > > paths? >> > > > > >> > > > > For the reference, IP/MPLS provides this kind of >> > > functionality today >> > > > > for (unidirectional - but it does not know any other >> > > type) P2P LSPs >> > > > > as described in RFC 4379. And its extension to P2MP LSPs seems >> > > > > easy... >> > > > > >> > > > > >> > > > > >> > > > > Regards, >> > > > > >> > > > > Sasha >> > > > > >> > > > > >> > > > > >> > > > > ________________________________________ >> > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] >> > > On Behalf >> > > > > Of Maarten Vissers [maarten.vissers@huawei.com] >> > > > > Sent: Thursday, April 16, 2009 3:24 PM >> > > > > To: 'Adrian Farrel' >> > > > > Cc: mpls-tp@ietf.org >> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >> > > > > requirements >> > > > > >> > > > > Adrian, >> > > > > >> > > > > >> >> > > > > >> The intermediate nodes (including MEPs, MIPs and >> > > > > other internal >> > > > > >> functions as appropriate) of a co-routed >> > > > > bidirectional transport >> > > > > >> path at each (sub-)layer MUST be aware of the pairing >> > > > > >> relationship of the forward and the backward >> > > > > directions of that >> > > > > >> transport path. >> > > > > >> >> > > > > > >> > > > > > There is no way this is a functional requirement. That >> > > > is, there is >> > > > > > *nothing* that can be observed from a black box point of >> > > > view that >> > > > > > results from adhering to this requirement. >> > > > > >> > > > > Your understanding is not correct. It is very much >> > observable if >> > > > > this requirement is met from a black box point of view. >> > > > > The MIP functions can only perform the Loopback when there is a >> > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet >> > > > > received at a MIP needs to be returned (as LBR >> > > > > packet) to the originating MEP function via the other >> > > direction of >> > > > > the co-routed bidirectional transport path. This other >> > direction >> > > > > would not be available in an associated bidirectional transport >> > > > > path... and thus the loopback test >> > > > would fail. >> > > > > >> > > > > Similarly, when we have to apply TCM MEPs to monitor a >> > > segment, then >> > > > > this is possible in a co-routed bidir transport path >> > but not in a >> > > > > associated bidir transport path. In the first case the TCM MEP >> > > > > Source and Sink functions are co-located and can >> > exchange what is >> > > > > called "remote information" which is necessary for performance >> > > > > monitoring. >> > > > > In the latter case the TCM MEP Source and Sink functions >> > > are in e.g. >> > > > > different nodes in the network and TCM would not be able >> > > to provide >> > > > > performance monitoring. >> > > > > >> > > > > > The entirety of the bracketted text "(including MEPs, >> > > > MIPs and other >> > > > > internal >> > > > > > functions as appropriate)" should be deleted. It does not >> > > > > add to "The >> > > > > > intermediate nodes." >> > > > > >> > > > > Your understanding is not correct. This text must not be >> > > deleted at >> > > > > all. >> > > > > >> > > > > > Actually, I am quite fed up about this persistent >> > > > insistence on the >> > > > > inclusion >> > > > > > of "Tandem Connection." The definition within the ITU-T of >> > > > > this term >> > > > > > is >> > > > > poorly >> > > > > > specified and comes from the monitoring of a path that is >> > > > > parallel (i.e. >> > > > > tandem) >> > > > > > to the data path being monitored. This definition of TC >> > > > > seems to be at >> > > > > variance, >> > > > > > and would be if the ACH was actually in band. >> > > > > >> > > > > I don't understand where your interpretation of tandem >> > > connection is >> > > > > described in ITU-T recommendations. I.e. "from the >> > > monitoring of a >> > > > > path that is parallel (i.e. tandem) to the data path being >> > > > > monitored."? >> > > > > >> > > > > There is a "network connection" and this network >> > > connection is a set >> > > > > of interconnected "link connections" and "matrix >> > connections". A >> > > > > subset of those interconnected link connections and matrix >> > > > > connections can be monitored and is then referred to as >> > a "tandem >> > > > > connection". There is no "path that is parallel to the >> > > data path". >> > > > > There is only additional OAM inserted inside the data >> > path by the >> > > > > TCM MEP_So function and this OAM is extracted from the >> > > data path by >> > > > > the TCM MEP_Sk function. >> > > > > >> > > > > Regards, >> > > > > Maarten >> > > > > >> > > > > >> > > > > -----Original Message----- >> > > > > From: mpls-tp-bounces@ietf.org >> > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel >> > > > > Sent: donderdag 16 april 2009 11:59 >> > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com >> > > > > Cc: BUSI ITALO; mpls-tp@ietf.org >> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >> > > > > requirements >> > > > > >> > > > > Hi Sasha, >> > > > > >> > > > > > Unfortunately I cannot fully agree with your statement: >> > > > > > >> > > > > > >> > > > > > From the point of view of hardware, co-routed >> > > > bidirectional LSPs >> > > > > > are a special case of associated bidirectional LSPs. >> > > > > > >> > > > > > >> > > > > > This statement would be obviously correct, were it not for >> > > > > Requirement >> > > > > > 34 in the latest MPLS-TP requirements draft >> > > > > >> > > > > OK. Got it. >> > > > > >> > > > > But what is this doing in the data plane requirements section? >> > > > > >> > > > > In fact, what is this requirement actually saying? >> > > > > >> > > > > > >> > > > > > The intermediate nodes (including MEPs, MIPs and >> > > > other internal >> > > > > > functions as appropriate) of a co-routed >> > > > > bidirectional transport >> > > > > > path at each (sub-)layer MUST be aware of the pairing >> > > > > > relationship of the forward and the backward >> > > > > directions of that >> > > > > > transport path. >> > > > > > >> > > > > >> > > > > There is no way this is a functional requirement. That >> > > is, there is >> > > > > *nothing* that can be observed from a black box point of >> > > view that >> > > > > results from adhering to this requirement. >> > > > > >> > > > > Therefore it could be assumed that this requirement is met by >> > > > > configuring some data plane database component through the >> > > > > management plane. The database component is not used >> > for anything >> > > > > except to satisfy this requirement for "awareness". >> > > > > >> > > > > Ben! Can we please try to rewrite this requirement in terms of >> > > > > behavior? >> > > > > >> > > > > > Please note that Requirement 34 is the ONLY item in the >> > > > > list that is >> > > > > > specific for co-routed bidirectional LSPs. (The pairing >> > > > > requirements >> > > > > > at end points for co-routed and associated bidirectional >> > > > paths are >> > > > > > exactly the same even if they appear in two different >> > > > items in the >> > > > > > requirements' list). >> > > > > > In other words, without Requirement 34 the notion of >> > co-routed >> > > > > > bidirectional paths would be void of any data plane content. >> > > > > > >> > > > > > The somewhat vague scope of this requirement ("other internal >> > > > > > functions as appropriate") creates a suspicion that HW >> > > > > support of the >> > > > > > pairing awareness may be required in order to comply with it. >> > > > > >> > > > > The entirety of the bracketted text "(including MEPs, >> > > MIPs and other >> > > > > internal functions as appropriate)" should be deleted. It >> > > does not >> > > > > add to "The intermediate nodes." >> > > > > >> > > > > > The following text in the draft increases this suspicion: >> > > > > > >> > > > > > >> > > > > > Tandem Connection: A tandem connection is an >> > > arbitrary part of a >> > > > > > transport path that can be monitored (via OAM) >> > > > > independently from the >> > > > > > end-to-end monitoring (OAM). It may be a monitored >> > > segment or a >> > > > > > monitored concatenated segment of a transport path. >> > > The tandem >> > > > > > connection may also include the forwarding engine(s) of >> > > > > the node(s) >> > > > > > at the edge(s) of the segment or concatenated segment. >> > > > > > >> > > > > >> > > > > Actually, I am quite fed up about this persistent >> > > insistence on the >> > > > > inclusion of "Tandem Connection." The definition within >> > > the ITU-T of >> > > > > this term is poorly specified and comes from the >> > monitoring of a >> > > > > path that is parallel (i.e. tandem) to the data path being >> > > > > monitored. This definition of TC seems to be at variance, >> > > and would >> > > > > be if the ACH was actually in band. >> > > > > >> > > > > > Doesn't "forwarding engine" sound like hardware to you? >> > > > > >> > > > > Yes, but so what? >> > > > > >> > > > > > IMHO it is worth noting that neither the MPLS-TP >> > > > Requirements draft >> > > > > > nor the MPLS-TP OAM requirements one >> > > > > > >> > > > > >> > > > >> > > >> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen >> > > > > > ts-01.txt) contain any requirements dealing with tandem >> > > > connections. >> > > > > > >> > > > > > But tandem connections are discussed in the MPLS-TP OAM >> > > Framework >> > > > > > draft >> > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >> > > > > amework-00.txt >> > > > > ). >> > > > > >> > > > > Right. >> > > > > Let's just get rid of an unnecessary term and bring all >> > the I-Ds >> > > > > into line. >> > > > > >> > > > > > The bottom line, IMHO, is that some clarity regarding >> > > > co-routed vs. >> > > > > > associated >> > > > > > bidirectional paths is still required. One way to provide >> > > > > that could >> > > > > > be by explicitly limiting Requirement 34 to specific >> > > > functionality. >> > > > > >> > > > > Agreed. >> > > > > >> > > > > Adrian >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > ________________________________________ >> > > > > From: Adrian Farrel [adrian@olddog.co.uk] >> > > > > Sent: Thursday, April 16, 2009 12:13 AM >> > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO >> > > > > Cc: mpls-tp@ietf.org >> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >> > > > > requirements >> > > > > >> > > > > Hi Sasha, >> > > > > >> > > > > Not really sure whether you are misrepresenting anyone, but... >> > > > > >> > > > > > 1. My reading of one of Ben's messages is that associated >> > > > > > bidirectional paths are the only types of paths that can be >> > > > > created in >> > > > > > the existing networks; "true" co-routed bidirectional paths >> > > > > will have >> > > > > > to wait until (if ever) new equipment becomes available. >> > > > > >> > > > > This is clearly nonsense! >> > > > > From the point of view of hardware, co-routed >> > > bidirectional LSPs are >> > > > > a special case of associated bidirectional LSPs. >> > > > > >> > > > > If you can set up two unidirectional LSPs (e.g. using the >> > > management >> > > > > plane) you can surely set up a co-routed >> > > > bidirectional LSP. >> > > > > >> > > > > There are shipping solutions that achieve co-routed >> > bidirectional >> > > > > LSPs using the control plane. These either use the GMPLS >> > > (which is >> > > > > cleaner) or non-standard proprietary solutions (which is >> > > messy but >> > > > > functional). >> > > > > >> > > > > But (of course) the management plane or control plane >> > > solutions have >> > > > > nothing to do with availability of equipment as they >> > are software >> > > > > solutions. >> > > > > >> > > > > > 2. My reading of one of Neil's messages is that the actual >> > > > > driver for >> > > > > > co-routed bidirectional paths may be experience with existing >> > > > > > transport networks rather than any specific benefit. >> > > > > >> > > > > Isn't that the case with 75% of the MPLS-TP requirements? >> > > > > Which is not to say it is a bad thing. >> > > > > >> > > > > A large driver for MPLS-TP is to give the packet network >> > > the look, >> > > > > feel, and behavioral characteristics of a "legacy" >> > > > > transport network. >> > > > > >> > > > > > Based on these observations, I'd guess (FWIW) that: >> > > > > > * associated bidirectional paths are, at least for the time >> > > > > > being, the most important type of bidirectional paths in >> > > > > > MPLS-TP >> > > > > >> > > > > I think that is wrong both given my statement above, and >> > > given that >> > > > > other upgrades to existing MPLS solutions will be >> > needed to reach >> > > > > the full function level of MPLS-TP. >> > > > > >> > > > > > * they had a good chance to remain the only type of >> > > bidirectional >> > > > > > paths in real deployments. >> > > > > >> > > > > I don't see what that follows from. >> > > > > >> > > > > Cheers, >> > > > > Adrian >> > > > > >> > > > > _______________________________________________ >> > > > > mpls-tp mailing list >> > > > > mpls-tp@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >> > > > > >> > > > > _______________________________________________ >> > > > > mpls-tp mailing list >> > > > > mpls-tp@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >> > > > > >> > > > > >> > > > _______________________________________________ >> > > > mpls-tp mailing list >> > > > mpls-tp@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/mpls-tp >> > > > >> > > >> > _______________________________________________ >> > mpls-tp mailing list >> > mpls-tp@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls-tp >> > >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is= confidential. Recipients named above are obligated to maintain secrecy and= are not permitted to disclose the contents of this communication to others= . >> This email and any files transmitted with it are confidential and intend= ed solely for the use of the individual or entity to whom they are addresse= d. If you have received this email in error please notify the originator of= the message. Any views expressed in this message are those of the individu= al sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam syst= em. >> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> > --00163642702b655db604682b0d63 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, I think you've captured my view pretty accurately. Sin= ce MPLS-TP supports only p2p and p2mp transports it would be responsibility= of another layer to support specific services among UNI-Ns. Interesting th= ing that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP L= SP since by MEF's definition E-Tree is a bidirectional service. (Just a= note). Kind regards, Greg 2009/4/22 Maart= en Vissers <maarten.vissers@huawei.com> Dear Greg, Do you mean that there is a layer network above MPLS-TP=20 that will support these services from UNI-N port to UNI-N port, and that MP= LS-TP=20 will support this service layer network? Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten=20 Vissers Cc: neil.2.harrison@bt.com;=20 mpls-tp@ietf.org<= div> Subject: Re: [mpls-tp] Associat= ed bidirectional=20 transport path requirements Dear Maarten, I believe that it is not a requirement for MPLS= -TP=20 to support any specific service, including ones you've listed in your m= essage.=20 On the other hand, support of listed services is a requirement for a client= =20 layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers <= maarten.vis= sers@huawei.com> Neil, I expect=20 that the main requirement for a packet transport network technology = like=20 MPLS-TP is that it is able to support at least the following=20 services: -=20 E-Line -=20 E-Tree -=20 E-LAN - PDH=20 CES in a=20 traffic engineered and managed manner. Another=20 main requirement is that it must be able to support those services in a= =20 scalable manner between points anywhere in the world. The=20 E-Line, E-Tree and E-LAN services allow to reorder client frames tha= t=20 belong to different priorities and to drop client frames that are dr= op=20 eligible. The E-Tree=20 and E-LAN services require that client bits are read to deliver the frame= s to=20 the appropriate output port or ports of the E-Tree or E-LAN supporti= ng=20 transport entity/differentiated connection. The packet=20 transport network technology must as such support traffic=20 engineered transport entities (differentiated connections) with n in= put=20 ports (i.e. multi source constructs). This in addition of traffic enginee= red=20 transport entities with 1 input port. Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@= ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april 2009=20 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Liu, If MPLS-TP is going to be taken seriously as a trans= port network (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. 1    Provide a transparent client/ser= ver=20 relationship...which means: -    all client bits treated equally<= /font> -    client bit ordering preserved -    no attempt to infer client symbo= l (ie sequence of=20 client bits) meaning and no attempt to change client=20 symbols -    the traffic behaviour of client = X must not impact=20 the performance experienced by client Y A key corollary of the above is that MPLS-TP must on= ly support proper=20 connections (ie single source constructs) 2   Since MPLS-TP is a transport network i= t is not a=20 top-of-stack network (ie it does not support directly external=20 message/file/stream applications). MPLS-TP therefore does not requi= re an=20 E-NNI specification. A key corollary of this is that MPLS-TP will n= ot=20 have any peer interworking relationship with any other network=20 mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. Y= ou could argue this=20 should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE (also = a=20 co-ps mode network) should have FDI/AIS we concluded that on balance it w= as=20 not a good idea.....and note that initially I was in favour of having AIS= , but=20 my colleagues provided strong technical arguments that convinced me=20 otherwise. AIS/FDI is historically linked to the = early PDH co-cs mode=20 layer networks that used TTL logic. When this died it put out a +5V= (all=20 1s) signal by default, ie it required no conscious effort to generate=20 it.....this is key point. Further, in these networks there is a fai= rly=20 static/long-holding client server relationship. Clearly this is not= true=20 in the cl-ps mode and it's why IETF have never specified AIS for IP a= nd its=20 why IEEE had the good sense to throw-out AIS in 802.1ag for Ethernet (tho= ugh=20 ITU have unwisely IMO retained it in Y.1731....but I suspect any operator= =20 planning to use Ethernet equipment would always look to IEEE stds and not= ITU=20 ones). AIS/FDI and the co-ps mode is debatabl= e. As I noted=20 above, on balance we considered not a good idea for PBB-TE OAM because it= =20 requires a conscious effort to generate it (unlike the co-cs mode) so the= re=20 are likely to be scaling problems and its one more thing to go=20 wrong. You should also have seen me make the = point many times in=20 the past that the always-on defect detection/handling OAM needs to be as= =20 simple/sparse as possible with as little config as possible because we ne= ed=20 super reliability......TCM goes completely against the grain here. = Also=20 note that the OAM required for each of the 3 network modes is not the sam= e,=20 despite what some claim. regards, Neil From: mpls-tp-bounces@ietf.org [mailto:<= a href=3D"mailto:mpls-tp-bounces@ietf.org" target=3D"_blank">mpls-tp-bounce= s@ietf.org] On Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org S= ubject: Re: [mpls-tp]=20 Associated bidirectional transport path requirements Deborah: &nbs= p;maybe what you said=20 is right. but I can't completely agree your opinions. IMO. mpls-tp = is regard=20 as transport network like SDH/SONET. so it should have AIS/FDI fuctions= as=20 SDH/SONET. do you t= hink=20 so. best regards=20 liu "BRU= NGARD, DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47 <= /p> = =CA=D5=BC=FE=C8=CB "Maarten Visser= s" <maarten.vissers@huawei.com>, <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] Associ= ated=20 bidirectional transport path=20 requirements <= br> I agree with Neil, it is very questionable = the value of AIS/FDI=20 in a packet network- any mode. It can result in a DoS attack by an= =20 operator on themselves so even Y1731 recommends not to block data=20 frames: "A MEP can decide whether it blocks data frames when it= detects=20 dAIS. The principle requirement that influences this decision is = that=20 data frames ought to be forwarded as much as possible, without th= e=20 possibility of forwarding wrong data frames downstream." Table = I.7-2=20 shows for AIS, not to block. And as Y1731 states, AIS can only b= e=20 used under very constrained architectures - if required for MPLS-TP,= it=20 needs to have the same guidance as in Y1731, i.e. point-to-point and= =20 server/client one-to-one: "for a point-to-point ETH connection,= a MEP has=20 only a single peer MEP. Therefore, there is no ambiguity regardin= g the=20 peer MEP for which it should suppress alarms when it receives=20 the ETH-AIS information." So should only be within one domai= n - then=20 no need. Deborah -----Original Message----- From: mpls-tp-bounces@i= etf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com = Cc: mpls-tp@ietf.org<= /a> Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil, > b= ut=20 AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed= a=20 requirement and a necessity. And you will not be able to understa= nd=20 that as long as you refuse to accept that "cl-mode" is aforwarding=20 mode within a **transport entity**. G.800 amendment 1=20 has finally reintroduced this transport entity into G.800. Beside= s=20 that, it also introduced the **differentiated connection**: [= G.800=20 am1] "A differentiated connection is a transport entity that tr= ansfers=20 information belonging to multiple communications between ports acros= s a=20 subnetwork. <..> In a differentiated connection=20 message contents are interpreted to identify (sets of) communicat= ions=20 which receive different treatment. The sets of communicatio= ns=20 may be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved between mes= sages=20 belonging to sets of communications receiving different treatment.= =20 Sets of communications may be identified for purposes such = as=20 traffic conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 "diff= erentiated=20 connections". Ethernet AIS provides AIS within the scope of = such=20 "differentiated connection". If you apply this to my pr= oposed PTN=20 layer stack, then the EVC layer topology will consists of EVC lin= ks=20 supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside= =20 metro and core domains interconnecting EVC matrices. When one of = those=20 EVC links is interrupted, e.g. in the core between metro 1 and me= tro 4=20 (see attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC switch/bridg= e=20 node in metro 4 this interruption is noticed and EVC-AIS is inser= ted=20 in the downstream direction to suppress the EVC-LOC alarms at EVC=20 endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame= has=20 a reserved multicast address, which guarantees that the AIS is broad= cast=20 to the endpoints of the EVC. I believe that it is time for you t= o=20 adapt your view on co and cl modes and relate it to the forwardin= g=20 mode **INSIDE** a transport entity. What we know as the interne= t is=20 essentially an "IP differentiated connection" with a billi= on or more=20 ports. What we know as an IP VPN is essentially an "IP=20 differentiated connection" with e.g. n ports (n in the range= of e.g. 2=20 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in= the range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an = "MPLS=20 differentiated connection" with 2 ports. What we know as a p= 2p SDH=20 VC-n is a "SDH VC-n connection" with 2 ports. Transpor= t network OAM=20 applies to transport entities, which are (in terms of G.800 am1)= =20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijd= ag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshte= in@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org<= /a> Subject: RE: [mpls-tp] Associated=20 bidirectional transport path requirements John, Thanks = this=20 is a great platform to explain why OAM for the 3 network modes ne= eds=20 to be different. I am getting a wee bit tired of folks trying<= br>to=20 make all 3 network modes look alike (and then, even worse,=20 interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I am e= ven=20 more frustrated by the fact those peddling this FUD only ever seem t= o=20 consider OAM and forget all other DP/CP/MP components (esp=20 top-of-stack message/file/stream application adaptations). How= =20 wrong can this get! In the co modes a *connection* is a very=20 specific and *constraining* construct.....I am assuming here we resp= ect=20 the rules of a connection (ie single source) though some folks do= n't=20 even bother to respect this, and this is despite the fact that we= all=20 know what problems multiple-source constructs can cause (from=20 LDP/PHP....ergo MPLS-TP). When we have a connection this restric= ts=20 *all* DP (ie traffic and OAM) to stay within the bounds of the=20 connection. Which is fine under defect-free conditions, but= if=20 we have leaking traffic then the constraining nature of the conne= ction=20 construct is broken. In a nutshell what this means is that = OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity defects.....indeed, why should a= =20 leaking DP have a symmetric go/return defect behaviour?....very l= ikely=20 it won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and not jus= t in=20 OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...= at=20 least IEEE had the good sense to bin this for Ethernet even though i= t=20 remains in Y.1731. And which is why I often trot-out the ra= ther=20 silly (to have to say this) observation that if IP (cl mode) coul= d do=20 it all then why have IETF found it necessary to create MPLS (co-p= s)=20 and GMPLS (CP for co-cs). The answer lies in the physics...and= =20 G.800 attempts to explain that physics....G.805 does not. So,= the=20 3 modes are different...please accept/rejoice in this fact as theyall=20 offer something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the OAM of th= e 3=20 modes the same. regards, Neil > -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org<= /a>] On Behalf Of Drake, John=20 E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander= =20 Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > requirements > >=20 Italo, > > As described in the MPLS TP OAM Requirements I-= D,=20 virtually all of the > OAM functions require a return path, a= nd in=20 the absence of a return > path they are disabled. > &g= t; As=20 described in David Sinicrope's meeting minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addre= ssing=20 is used, an > MPLS TP network needs to be capable of getting IP= =20 packets from > destination to source; neither the minutes nor I= =20 stipulate that a > control plane needs to be used to instantiate= this=20 forwarding. > > As an aside, the issue of return path for= =20 unidirectional LSPs could be > charaterized as the elephant i= n the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs are= only=20 mentioned three times and return > paths not at all. > >=20 Thanks, > > John > > -----Original=20 Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it<= /a>] > > Sent: Friday,=20 April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainsh= tein;=20 Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp]=20 Associated bidirectional transport path > > requirements &= gt;=20 > > > John, > > > > I might have missed= the=20 agreement of MPLS-TP being capable of > > sending replies to = OAM=20 requests sent on uni-directional LSPs. > > > > This= =20 requirement does not belong to the first set of requirements > &= gt;=20 ITU-T is expecting to be met by October. > > > > How= ever,=20 I think this in a potential interesting additional > > requir= ement=20 to be taken into account (at worst in a > subsequent phase). &= gt;=20 > > > I think that this requirement needs to be evaluated= =20 versus other > > more important requirements (e.g. the possib= ility=20 to work w/o IP > > forwarding and the need for OAM to continu= e to=20 monitor the data > > plane also in case of failures affecting= the=20 control or management > > plane). > > > > = I am=20 open to discuss it but not sure this is the right time because >= >=20 I wish to avoid delaying the first phase of the design solution. >= ;=20 > > > Thanks, Italo > > > > >=20 -----Original Message----- > > > From: mpls-tp-bounces@ietf.org &= gt; > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > > > Sent: Thursday, April 16, 2009 8:00 PM > >= >=20 To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org >= =20 > > Subject: Re: [mpls-tp] Associated bidirectional transport pat= h=20 > > > requirements > > > > > > At= the=20 meeting last fall at Juniper in Massachusetts, I > > think it= =20 was > > > agreed that an MPLS TP network needs to have a=20 forwarding > > capability > > > for management,=20 control, and OAM packets (e.g., sending > > replies to OAM = >=20 > > requests sent on uni-directional LSPs) even if it does not>=20 > have an IP > > > forwarding data plane. > > &= gt;=20 > > > > -----Original Message----- > > > &g= t;=20 From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ec= itele.com] > > > >=20 Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maart= en=20 Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re:= =20 [mpls-tp] Associated bidirectional transport path > > > &g= t;=20 requirements > > > > > > > > Maarten,>=20 > > > It seems that you've just (implicitly and, probably,= >=20 > > > inadvertently) stated the following: > > > &= gt;=20 > > > > = ;=20 MPLS-TP OAM will not ever support MIP loopback function>=20 > (and fault > > > > localization which requires this= =20 function ) for > > unidirectional P2MP > > > > = and=20 P2P paths. > > > > > > > > If this state= ment=20 is correct, this (IMHO and FWIW) > raises a valid > > &g= t;=20 > question: > > > > > > > > &n= bsp;=20 Is MPLS-TP an appropria= te=20 solution for these > types of transport > > > >=20 paths? > > > > > > > > For the reference= ,=20 IP/MPLS provides this kind of > > functionality today > = >=20 > > for (unidirectional - but it does not know any other > = >=20 type) P2P LSPs > > > > as described in RFC 4379. And its= =20 extension to P2MP LSPs seems > > > > easy... > &g= t;=20 > > > > > > > > > > >= ;=20 > > > Regards, > > > > > > > >= =20 Sasha > > > > > > > >= ;=20 > > > > > > > >=20 ________________________________________ > > > > From: <= a href=3D"mailto:mpls-tp-bounces@ietf.org" target=3D"_blank">mpls-tp-bounce= s@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf >=20 > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > &g= t; > Sent:=20 Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian= =20 Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > > &g= t;=20 requirements > > > > > > > > Adrian, = >=20 > > > > > > > >> <quote> > &= gt;=20 > > >> The intermediate nodes (includin= g=20 MEPs, MIPs and > > > > other internal > > > = >=20 >> functions as appropriate) of a=20 co-routed > > > > bidirectional transport > > &= gt;=20 > >> path at each (sub-)layer MUST be awa= re of=20 the pairing > > > > >> =20 relationship of the forward and the backward > > > >=20 directions of that > > > > >> = =20 transport path. > > > > >> <end quote> &g= t;=20 > > > > > > > > > There is no way this is= a=20 functional requirement. That > > > is, there is > >= ;=20 > > > *nothing* that can be observed from a black box point=20 of > > > view that > > > > > results from= =20 adhering to this requirement. > > > > > > >= >=20 Your understanding is not correct. It is very much > observable= =20 if > > > > this requirement is met from a black box poin= t of=20 view. > > > > The MIP functions can only perform the Loo= pback=20 when there is a > > > > co-routed bidirectional transpo= rt=20 path. The MPLS-TP LBM packet > > > > received at a MIP = needs=20 to be returned (as LBR > > > > packet) to the originatin= g MEP=20 function via the other > > direction of > > > >= the=20 co-routed bidirectional transport path. This other > direction>=20 > > > would not be available in an associated bidirectional=20 transport > > > > path... and thus the loopback test>=20 > > would fail. > > > > > > > >=20 Similarly, when we have to apply TCM MEPs to monitor a > > seg= ment,=20 then > > > > this is possible in a co-routed bidir trans= port=20 path > but not in a > > > > associated bidir trans= port=20 path. In the first case the TCM MEP > > > > Source and = Sink=20 functions are co-located and can > exchange what is > > = >=20 > called "remote information" which is necessary for perfo= rmance >=20 > > > monitoring. > > > > In the latter case th= e TCM=20 MEP Source and Sink functions > > are in e.g. > > &g= t;=20 > different nodes in the network and TCM would not be able > &= gt;=20 to provide > > > > performance monitoring. > > = >=20 > > > > > > The entirety of the bracketted text= =20 "(including MEPs, > > > MIPs and other > > &g= t; >=20 internal > > > > > functions as appropriate)" sh= ould be=20 deleted. It does not > > > > add to "The > &g= t; >=20 > > intermediate nodes." > > > > > >= ; >=20 > Your understanding is not correct. This text must not be > &= gt;=20 deleted at > > > > all. > > > > > = >=20 > > > Actually, I am quite fed up about this persistent >= ;=20 > > insistence on the > > > > inclusion > &g= t;=20 > > > of "Tandem Connection." The definition within = the ITU-T=20 of > > > > this term > > > > > is &= gt;=20 > > > poorly > > > > > specified and comes f= rom=20 the monitoring of a path that is > > > > parallel=20 (i.e. > > > > tandem) > > > > > to the= data=20 path being monitored. This definition of TC > > > > seem= s to=20 be at > > > > variance, > > > > > and = would=20 be if the ACH was actually in band. > > > > > >= ;=20 > > I don't understand where your interpretation of tandem>=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of a &g= t; >=20 > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > > &g= t; >=20 > > There is a "network connection" and this network> >=20 connection is a set > > > > of interconnected "link= =20 connections" and "matrix > connections". A >= > > >=20 subset of those interconnected link connections and matrix > >= ;=20 > > connections can be monitored and is then referred to as &g= t; a=20 "tandem > > > > connection". There is no "= ;path that is=20 parallel to the > > data path". > > > > T= here is=20 only additional OAM inserted inside the data > path by the >= ;=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM MEP_Sk=20 function. > > > > > > > > Regards, &g= t;=20 > > > Maarten > > > > > > > >= =20 > > > > -----Original Message----- > > > &g= t;=20 From: mpl= s-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] O= n Behalf Of Adrian=20 Farrel > > > > Sent: donderdag 16 april 2009 11:59 &g= t;=20 > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com &= gt; > > > Cc:=20 BUSI ITALO; mpls-= tp@ietf.org > > > > Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > > &g= t;=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > Unfortunatel= y I=20 cannot fully agree with your statement: > > > > > = >=20 > > > > <quote> > > > > > &n= bsp;=20 From the point of view of hardware, co-routed > > >=20 bidirectional LSPs > > > > > are a spec= ial=20 case of associated bidirectional LSPs. > > > > > <= end=20 quote> > > > > > > > > > > This= =20 statement would be obviously correct, were it not for > > >= >=20 Requirement > > > > > 34 in the latest MPLS-TP=20 requirements draft > > > > > > > > OK. G= ot=20 it. > > > > > > > > But what is this doi= ng in=20 the data plane requirements section? > > > > > &g= t;=20 > > In fact, what is this requirement actually saying? > &g= t;=20 > > > > > > > <quote> > > > = >=20 > The intermediate nodes (including MEPs, MIPs= =20 and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > > >= ;=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > &g= t;=20 > > > relationship of the forward and the= =20 backward > > > > directions of that > > > &g= t;=20 > transport path. > > > > >= =20 <end quote> > > > > > > > > There = is no=20 way this is a functional requirement. That > > is, there is>=20 > > > *nothing* that can be observed from a black box point=20 of > > view that > > > > results from adhering = to=20 this requirement. > > > > > > > > Theref= ore=20 it could be assumed that this requirement is met by > > > = >=20 configuring some data plane database component through the > >= ;=20 > > management plane. The database component is not used > = for=20 anything > > > > except to satisfy this requirement for= =20 "awareness". > > > > > > > > B= en! Can we=20 please try to rewrite this requirement in terms of > > > &= gt;=20 behavior? > > > > > > > > > Please no= te=20 that Requirement 34 is the ONLY item in the > > > > list= that=20 is > > > > > specific for co-routed bidirectional LSP= s.=20 (The pairing > > > > requirements > > > >= >=20 at end points for co-routed and associated bidirectional > > &= gt;=20 paths are > > > > > exactly the same even if they app= ear=20 in two different > > > items in the > > > > = >=20 requirements' list). > > > > > In other words, wi= thout=20 Requirement 34 the notion of > co-routed > > > > &= gt;=20 bidirectional paths would be void of any data plane content. > &g= t;=20 > > > > > > > > The somewhat vague scope of = this=20 requirement ("other internal > > > > > function= s as=20 appropriate") creates a suspicion that HW > > > > s= upport of=20 the > > > > > pairing awareness may be required in or= der=20 to comply with it. > > > > > > > > The= =20 entirety of the bracketted text "(including MEPs, > > MIP= s and=20 other > > > > internal functions as appropriate)" s= hould be=20 deleted. It > > does not > > > > add to "T= he=20 intermediate nodes." > > > > > > > >= ; > The=20 following text in the draft increases this suspicion: > > >= >=20 > > > > > > <quote> > > > > &= gt;=20 Tandem Connection: A tandem connection is an > > arbitr= ary=20 part of a > > > > > transport path that can be= =20 monitored (via OAM) > > > > independently from the &g= t;=20 > > > > end-to-end monitoring (OAM). It may be= a=20 monitored > > segment or a > > > > > = =20 monitored concatenated segment of a transport path. > >= The=20 tandem > > > > > connection may also include t= he=20 forwarding engine(s) of > > > > the node(s) > >= >=20 > > at the edge(s) of the segment or concatenated=20 segment. > > > > > <end quote> > > >= ;=20 > > > > > Actually, I am quite fed up about this=20 persistent > > insistence on the > > > > inclus= ion=20 of "Tandem Connection." The definition within > > th= e ITU-T=20 of > > > > this term is poorly specified and comes from= =20 the > monitoring of a > > > > path that is paralle= l=20 (i.e. tandem) to the data path being > > > > monitored.= This=20 definition of TC seems to be at variance, > > and would >= ;=20 > > > be if the ACH was actually in band. > > > &g= t;=20 > > > > > Doesn't "forwarding engine" = sound like hardware=20 to you? > > > > > > > > Yes, but so=20 what? > > > > > > > > > IMHO it is wo= rth=20 noting that neither the MPLS-TP > > > Requirements draft>=20 > > > > nor the MPLS-TP OAM requirements one > > &= gt;=20 > > > > > > > > > > > = >=20 (http://www.ietf.org/internet-drafts/draft-iet= f-mpls-tp-oam-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing with=20 tandem > > > connections. > > > > > &g= t;=20 > > > > But tandem connections are discussed in the MPLS-TP= =20 OAM > > Framework > > > > > draft > &g= t;=20 > > (http://www.ietf.org/internet-drafts/draft-i= etf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > > &g= t;=20 > > > > > Right. > > > > Let's ju= st get=20 rid of an unnecessary term and bring all > the I-Ds > > = >=20 > into line. > > > > > > > > > The= =20 bottom line, IMHO, is that some clarity regarding > > >=20 co-routed vs. > > > > > associated > > > = >=20 > bidirectional paths is still required. One way to provide > = >=20 > > that could > > > > > be by explicitly limit= ing=20 Requirement 34 to specific > > > functionality. > >= ;=20 > > > > > > Agreed. > > > > &g= t;=20 > > > Adrian > > > > > > > >=20 > > > > > > > > > > > >= =20 ________________________________________ > > > > From: A= drian=20 Farrel [adrian= @olddog.co.uk] > > > > Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: Alexander= =20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org >= =20 > > > Subject: Re: [mpls-tp] Associated bidirectional transpor= t=20 path > > > > requirements > > > > &g= t;=20 > > > Hi Sasha, > > > > > > > >= Not=20 really sure whether you are misrepresenting anyone, but... > >= >=20 > > > > > > 1. My reading of one of Ben'= ;s=20 messages is that associated > > > > > bidirect= ional=20 paths are the only types of paths that can be > > > > cr= eated=20 in > > > > > the existing networks; "true" = co-routed=20 bidirectional paths > > > > will have > > > = >=20 > to wait until (if ever) new equipment becomes available. > &= gt;=20 > > > > > > This is clearly nonsense! > >= ;=20 > > From the point of view of hardware, co-routed > >=20 bidirectional LSPs are > > > > a special case of associa= ted=20 bidirectional LSPs. > > > > > > > > If y= ou=20 can set up two unidirectional LSPs (e.g. using the > >=20 management > > > > plane) you can surely set up a=20 co-routed > > > bidirectional LSP. > > > >= =20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using the= =20 control plane. These either use the GMPLS > > (which is >= ;=20 > > > cleaner) or non-standard proprietary solutions (which=20 is > > messy but > > > > functional). > &= gt;=20 > > > > > > But (of course) the management plane = or=20 control plane > > solutions have > > > > nothin= g to=20 do with availability of equipment as they > are software > = >=20 > > solutions. > > > > > > > > > 2. My reading of one of Neil's mess= ages=20 is that the actual > > > > driver for > > > = >=20 > co-routed bidirectional paths may be experience with existing = >=20 > > > > transport networks rather than any specific=20 benefit. > > > > > > > > Isn't that = the case=20 with 75% of the MPLS-TP requirements? > > > > Which is n= ot to=20 say it is a bad thing. > > > > > > > > A= =20 large driver for MPLS-TP is to give the packet network > > the= =20 look, > > > > feel, and behavioral characteristics of a= =20 "legacy" > > > > transport network. > &g= t; > >=20 > > > > > Based on these observations, I'd guess= (FWIW)=20 that: > > > > > * associated bidirectional paths are,= at=20 least for the time > > > > > being, the = most=20 important type of bidirectional paths in > > > > > &n= bsp;=20 MPLS-TP > > > > > > > > I think th= at is=20 wrong both given my statement above, and > > given that >= ;=20 > > > other upgrades to existing MPLS solutions will be >= ;=20 needed to reach > > > > the full function level of=20 MPLS-TP. > > > > > > > > > * they had= a=20 good chance to remain the only type of > > bidirectional &g= t;=20 > > > > paths in real deployments. > >= ;=20 > > > > > > I don't see what that follows=20 from. > > > > > > > > Cheers, > &g= t;=20 > > Adrian > > > > > > > >=20 _______________________________________________ > > > >= =20 mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp &g= t; >=20 > > > > > >=20 _______________________________________________ > > > >= =20 mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp &g= t; >=20 > > > > > > > > >=20 _______________________________________________ > > > mpls-= tp=20 mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/= mailman/listinfo/mpls-tp > >=20 > > > >=20 _______________________________________________ > mpls-tp mailing= =20 list > mpls= -tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp= >=20 _______________________________________________ mpls-tp mailing= =20 list mpls-tp@i= etf.org https://www.ietf.org/mailman/listinfo/mpls-tp <= /font> -------------------------------------------------------- ZTE Information Security Notice: The information&n= bsp;contained in this mail is solely property= of the sender's organization. This mail&= nbsp;communication is confidential. Recipients named&nb= sp;above are obligated to maintain secrecy an= d are not permitted to disclose the cont= ents of this communication to others. This email and any files transmitted with&nbs= p;it are confidential and intended solely for= the use of the individual or entity&nbs= p;to whom they are addressed. If you hav= e received this email in error please no= tify the originator of the message. Any = views expressed in this message are those&nbs= p;of the individual sender. This message has been scanned for viruses&nbs= p;and Spam by ZTE Anti-Spam system. __________________________________= _____________ mpls-tp=20 mailing list mpl= s-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp = --00163642702b655db604682b0d63-- From maarten.vissers@huawei.com Wed Apr 22 14:01:19 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A6C3A6E31 for ; Wed, 22 Apr 2009 14:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4m53rE3ryiu for ; Wed, 22 Apr 2009 14:01:18 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id EAE573A6902 for ; Wed, 22 Apr 2009 14:01:15 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042214023305779 ; Wed, 22 Apr 2009 14:02:33 -0700 Received: from M00900002 ([10.84.2.164]) by s-utl01-sjpop.stsn.net; Wed, 22 Apr 2009 14:02:31 -0700 From: "Maarten Vissers" To: Date: Wed, 22 Apr 2009 23:02:21 +0200 Message-ID: <000b01c9c38d$a8662000$a402540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200904221518293285128@fiberhome.com.cn> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnDGvokU36ZbO0KT163pKD9snbuqQAccxlg Cc: 'MPLS-TP' Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:01:19 -0000 Xueqin, TCM as designed in Ethernet, ATM and T-MPLS does not require the provisioning of a TCM label along the monitored segment. The T-MPLS TCM design just required the activation of some MEPs, one at each end of the segment to monitor. I..e. no changes to the existing LSP. MPLS-TP segment monitoring on the basis of a nested LSP requires much more provisioning, as you need to set up the new LSP and modify the existing LSP. Regards, Maarten -----Original Message----- From: Xueqin WEI (Shuetsing WEI) [mailto:xqwei@fiberhome.com.cn] Sent: woensdag 22 april 2009 9:18 To: Maarten Vissers Cc: MPLS-TP Subject: Re: RE: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Maarten: Sorry reply you later because I have a trip on Monday and Tuesday. IMO, nested LSP is a already exist mechanism but TCM is a new added one. Addtion of TCM will make the thing more complicate. Second, TCM need to provision the TCM label along the monitored segmant too, I didn't see any provision difference between nested LSP and TCM. Sincerely Yours Xueqin Wei (Shuetsing Wei) 2009-04-22 15:12:35 ==================== Following is your email===================== Subject:RE: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Sent：2009-04-19 01:16:02 From:Maarten Vissers To:xqwei CC to:'MPLS-TP' >Xueqin, > >The nested LSP is a more complex solution then TCM. TCM just requires >the activation of some MEPs in the LSP. Nested LSP requires to set up >the same MEP functions plus set up an additional LSP and change the existing LSP. > >Regards, >Maarten > >-----Original Message----- >From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >Behalf Of Xueqin WEI (Shuetsing WEI) >Sent: zaterdag 18 april 2009 8:52 >To: Ben Niven-Jenkins >Cc: MPLS-TP >Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was >RE:Associatedbidirectional transport path requirements) > >Support, I think the nested LSP will be great! Until now, I didn't see >any difference between the nested LSP and TCM on performance >monitoring. But the nested LSP will make the things more easy. I would >like select a simple way to resolve the problem. > >Sincerely Yours >Xueqin Wei (Shuetsing Wei) > >Fiberhome Telecommunication Technologies Co.,Ltd., >2009-04-18 14:48:51 > >==================== Following is your email===================== >Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: >Associatedbidirectional transport path requirements) >Sent：2009-04-17 17:17:31 >From:Ben Niven-Jenkins >To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp > >>Italo, >> >>On 17/04/2009 09:34, "BUSI ITALO" wrote: >>> The JWT agreement is to bring the ITU-T transport requirements in >>> IETF to extend the MPLS architecture to meet them in a way that is >>> compatible, consistent and coherent with existing IETF architecture. >> >>So I took a look at the JWT report. It says (slide 16) >> >>" Service Providers want LSPs/PWEs to be able to be managed at the >>different nested levels seamlessly (path, segment, multiple segments) >> aka Tandem Connection Monitoring (TCM), this is used for example >>when a LSP/PWE crosses multiple administrations" >> >>IMO the requirement is to be able to monitor parts of a path as well >>as the end to end path. There are many ways to solve that requirement, >>one of which is the creation of nested LSPs, one per level of >>monitoring required (my understanding of how TCM works). >> >>I think the real discussion is therefore is the requirement to monitor >>different components of an end to end path or is the requirement that >>such monitoring MUST be achieved using nested LSPs? >> >>As an example PW technology today allows end to end and per segment >>monitoring but it does not achieve it using nested PWs or PW levels. >> >>Ben >> >>_______________________________________________ >>mpls-tp mailing list >>mpls-tp@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls-tp >> > >================================================================= >_______________________________________________ >mpls-tp mailing list >mpls-tp@ietf.org >https://www.ietf.org/mailman/listinfo/mpls-tp > > ================================================================= From maarten.vissers@huawei.com Wed Apr 22 16:22:22 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2ED13A6DAC for ; Wed, 22 Apr 2009 16:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLTQcSVwSYE4 for ; Wed, 22 Apr 2009 16:22:16 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id CCFE428C147 for ; Wed, 22 Apr 2009 16:22:16 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042216233222461 ; Wed, 22 Apr 2009 16:23:32 -0700 Received: from M00900002 ([10.84.2.164]) by s-utl02-sjpop.stsn.net; Wed, 22 Apr 2009 16:23:24 -0700 From: "Maarten Vissers" To: "'Greg Mirsky'" Date: Thu, 23 Apr 2009 01:23:17 +0200 Message-ID: <001c01c9c3a1$5764e1f0$a402540a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C9C3B2.1AEDB1F0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnDjWF6WlDop9y9RZiFCZDktpQ2ogAECc8g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-reply-to: <787be2780904221400j14cdf9c6gfa562548dd808516@mail.gmail.com> Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:22:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C9C3B2.1AEDB1F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Greg, =20 Thank you for this confirmation.=20 This other layer is that the EVC layer as illustrated in the figure = below? =20 UNI UNI --||------- ---------||----- | | UNI ------------------------------------------------- UNI --||----| EVC layer |-----||----- ------------------------------------------------- | MPLS-TP layer | | other layer | ----------------- ---------------- =20 MEF's E-Tree is a bidirectional rooted-multipoint connection, in which frames are forwarded on the basis of the value in their DA field. Such selective forwarding is not supported in an LSP connection. An LSP connection will as such just support one EVC link connection, i.e. a = part of the EVC between two adjacent EVC switch/bridge functions. Those p2p EVC = link connections simply require non-selective forwarding, something that an = LSP connection can provide. =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I think you've captured my view pretty accurately. Since MPLS-TP = supports only p2p and p2mp transports it would be responsibility of another layer = to support specific services among UNI-Ns. Interesting thing that E-Tree = can not be directly mapped to p2mp unidirectional MPLS-TP LSP since by MEF's definition E-Tree is a bidirectional service. (Just a note). Kind regards, Greg 2009/4/22 Maarten Vissers Dear Greg, =20 Do you mean that there is a layer network above MPLS-TP that will = support these services from UNI-N port to UNI-N port, and that MPLS-TP will = support this service layer network? =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I believe that it is not a requirement for MPLS-TP to support any = specific service, including ones you've listed in your message. On the other = hand, support of listed services is a requirement for a client layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers Neil, =20 I expect that the main requirement for a packet transport network = technology like MPLS-TP is that it is able to support at least the following = services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed manner. =20 Another main requirement is that it must be able to support those = services in a scalable manner between points anywhere in the world. =20 The E-Line, E-Tree and E-LAN services allow to reorder client frames = that belong to different priorities and to drop client frames that are drop eligible. =20 The E-Tree and E-LAN services require that client bits are read to = deliver the frames to the appropriate output port or ports of the E-Tree or = E-LAN supporting transport entity/differentiated connection. =20 The packet transport network technology must as such support traffic engineered transport entities (differentiated connections) with n input ports (i.e. multi source constructs). This in addition of traffic = engineered transport entities with 1 input port. =20 Regards, Maarten _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these. =20 1 Provide a transparent client/server relationship...which means: - all client bits treated equally - client bit ordering preserved - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols - the traffic behaviour of client X must not impact the performance experienced by client Y =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs) =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology. =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise. =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones). =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong. =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim. =20 regards, Neil =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , =B3=AD=CB=CD mpls-tp@ietf.org =09 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ------=_NextPart_000_001D_01C9C3B2.1AEDB1F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Greg, Thank you for this confirmation. = This other layer is that the EVC layer as = illustrated=20 in the figure below? =20 UNI           &nbs= p;            = ;            =             &= nbsp;       =20 UNI --||-------         = ;            =             &= nbsp;     =20    ---------||-----          =20 |            =             &= nbsp;           &n= bsp;  =20    | UNI  =20 -------------------------------------------------   =20 UNI --||----|         &= nbsp;      =20 EVC=20 layer           &n= bsp;        =20 |-----||-----        =20 -------------------------------------------------           &nbs= p;  | MPLS-TP=20 layer |    |  other layer = |           &nbs= p;  -----------------   =20 ---------------- MEF's E-Tree is = a bidirectional rooted-multipoint=20 connection, in which frames are forwarded on the basis of the value in = their DA=20 field. Such selective forwarding is not supported in an LSP connection. = An LSP=20 connection will as such just support one EVC link connection, = i.e. a=20 part of the EVC between two adjacent EVC switch/bridge functions. Those = p2p EVC=20 link connections simply require non-selective forwarding, something that = an LSP=20 connection can provide. Regards, Maarten From: Greg Mirsky = [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00 To: Maarten=20 Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path = requirements Dear Maarten, I think you've captured my view pretty = accurately.=20 Since MPLS-TP supports only p2p and p2mp transports it would be = responsibility=20 of another layer to support specific services among UNI-Ns. Interesting = thing=20 that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP = LSP since=20 by MEF's definition E-Tree is a bidirectional service. (Just a=20 note). Kind regards, Greg 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com= > Dear=20 Greg, Do you=20 mean that there is a layer network above MPLS-TP that will support = these=20 services from UNI-N port to UNI-N port, and that MPLS-TP will support = this=20 service layer network? Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten=20 Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Dear Maarten, I believe that it is not a requirement for = MPLS-TP=20 to support any specific service, including ones you've listed in your = message.=20 On the other hand, support of listed services is a requirement for a = client=20 layer that uses MPLS-TP services. Regards, Greg = Mirsky 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com> Neil, I expect=20 that the main requirement for a packet transport network = technology=20 like MPLS-TP is that it is able to support at least the following=20 services: -=20 E-Line -=20 E-Tree -=20 E-LAN - PDH=20 CES in a=20 traffic engineered and managed manner. Another=20 main requirement is that it must be able to support those services = in a=20 scalable manner between points anywhere in the = world. The=20 E-Line, E-Tree and E-LAN services allow to reorder = client frames that=20 belong to different priorities and to drop client frames that = are drop=20 eligible. The=20 E-Tree and E-LAN services require that client bits are read to = deliver the=20 frames to the appropriate output port or ports of the E-Tree or = E-LAN=20 supporting transport entity/differentiated = connection. The=20 packet transport network technology must as such support traffic=20 engineered transport entities (differentiated connections) with = n input=20 ports (i.e. multi source constructs). This in addition of traffic = engineered=20 transport entities with 1 input port. Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag = 21 april=20 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path=20 requirements Liu, If MPLS-TP is going to be taken seriously as a transport = network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. 1    Provide a transparent client/server=20 relationship...which means: -    all client bits treated=20 equally -    client bit ordering = preserved -    no attempt to infer client symbol (ie = sequence of=20 client bits) meaning and no attempt to change client=20 symbols -    the traffic behaviour of client X must = not impact=20 the performance experienced by client Y A key corollary of the above is that MPLS-TP must only = support proper=20 connections (ie single source constructs) 2   Since MPLS-TP is a transport network it is = not a=20 top-of-stack network (ie it does not support directly external=20 message/file/stream applications). MPLS-TP therefore does not = require=20 an E-NNI specification. A key corollary of this is that = MPLS-TP will=20 not have any peer interworking relationship with any other network=20 mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. You = could argue=20 this should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE = (also a=20 co-ps mode network) should have FDI/AIS we concluded that on balance = it was=20 not a good idea.....and note that initially I was in favour of = having AIS,=20 but my colleagues provided strong technical arguments that convinced = me=20 otherwise. AIS/FDI is historically linked to the early = PDH co-cs=20 mode layer networks that used TTL logic. When this died it put = out a=20 +5V (all 1s) signal by default, ie it required no conscious effort = to=20 generate it.....this is key point. Further, in these networks = there is=20 a fairly static/long-holding client server relationship. = Clearly this=20 is not true in the cl-ps mode and it's why IETF have never specified = AIS for=20 IP and its why IEEE had the good sense to throw-out AIS in 802.1ag = for=20 Ethernet (though ITU have unwisely IMO retained it in Y.1731....but = I=20 suspect any operator planning to use Ethernet equipment would always = look to=20 IEEE stds and not ITU ones). AIS/FDI and the co-ps mode is debatable. = As I=20 noted above, on balance we considered not a good idea for PBB-TE OAM = because=20 it requires a conscious effort to generate it (unlike the co-cs = mode) so=20 there are likely to be scaling problems and its one more thing to go = wrong. You should also have seen me make the point = many times=20 in the past that the always-on defect detection/handling OAM needs = to be as=20 simple/sparse as possible with as little config as possible because = we need=20 super reliability......TCM goes completely against the grain = here. =20 Also note that the OAM required for each of the 3 network modes is = not the=20 same, despite what some claim. regards, = Neil From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = liu.guoman@zte.com.cn Sent: 21 April = 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path = requirements Deborah: maybe = what you said=20 is right. but I can't completely agree your opinions. IMO. mpls-tp = is=20 regard as transport network like SDH/SONET. so it should have = AIS/FDI=20 fuctions as SDH/SONET. do you=20 think so. best = regards=20 liu "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47 = =CA=D5=BC=FE=C8=CB "Maarten Vissers" = <maarten.vissers@huawei.com>, = <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 size=3D2>I agree with Neil, it is very questionable the value = of AIS/FDI=20 in a packet network- any mode. It can result in a DoS attack by = an=20 operator on themselves so even Y1731 recommends not to block = data=20 frames: "A MEP can decide whether it blocks data frames when it = detects=20 dAIS. The principle requirement that influences this = decision is=20 that data frames ought to be forwarded as much as possible,=20 without the possibility of forwarding wrong data frames=20 downstream." Table I.7-2 shows for AIS, not to = block. And as=20 Y1731 states, AIS can only be used under very = constrained architectures=20 - if required for MPLS-TP, it needs to have the same guidance = as in=20 Y1731, i.e. point-to-point and server/client one-to-one: "for a = point-to-point ETH connection, a MEP has only a single peer=20 MEP. Therefore, there is no ambiguity regarding the peer MEP = for=20 which it should suppress alarms when it receives the ETH-AIS = information." So should only be within one domain - then no=20 need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport = path requirements Neil, > but=20 AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is = indeed a=20 requirement and a necessity. And you will not be able to = understand=20 that as long as you refuse to accept that "cl-mode" is = a forwarding=20 mode within a **transport entity**. G.800 amendment 1=20 has finally reintroduced this transport entity into G.800. = Besides=20 that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is a = transport entity that transfers information belonging to = multiple=20 communications between ports across a subnetwork. <..> In = a=20 differentiated connection message contents are interpreted = to=20 identify (sets of) communications which = receive different treatment.=20 The sets of communications may be distinguished by = the forwarding=20 identifier or other layer information. Order is=20 not necessarily preserved between messages belonging to sets = of=20 communications receiving different treatment. Sets of=20 communications may be identified for purposes such as = traffic=20 conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 = "differentiated=20 connections". Ethernet AIS provides AIS within the scope of = such=20 "differentiated connection". If you apply this to my = proposed PTN=20 layer stack, then the EVC layer topology will consists of = EVC links=20 supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails = inside=20 metro and core domains interconnecting EVC = matrices. When one of=20 those EVC links is interrupted, e.g. in the core between metro=20 1 and metro 4 (see attached slide), then the EVC = differentiated=20 connection that is present on this link will be interrupted. = At the=20 EVC switch/bridge node in metro 4 this interruption is = noticed and=20 EVC-AIS is inserted in the downstream direction to suppress the = EVC-LOC=20 alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet=20 AIS) frame has a reserved multicast address, which guarantees = that the=20 AIS is broadcast to the endpoints of the EVC. I believe = that it is=20 time for you to adapt your view on co and cl = modes and relate it to=20 the forwarding mode **INSIDE** a transport entity. What we = know as=20 the internet is essentially an "IP differentiated connection" = with a=20 billion or more ports. What we know as an IP VPN is essentially = an "IP=20 differentiated connection" with e.g. n ports (n in the range = of e.g.=20 2 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in the = range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is = essentially an=20 "MPLS differentiated connection" with 2 ports. What we know = as a p2p=20 SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport = network=20 OAM applies to transport entities, which are (in = terms of G.800 am1)=20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 = april 2009=20 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements John, = Thanks=20 this is a great platform to explain why OAM for the = 3 network modes=20 needs to be different. I am getting a wee bit tired of=20 folks trying to make all 3 network modes look alike (and = then, even=20 worse, interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I = am even=20 more frustrated by the fact those peddling this FUD only ever = seem to=20 consider OAM and forget all other DP/CP/MP components (esp=20 top-of-stack message/file/stream application adaptations). = How=20 wrong can this get! In the co modes a *connection* is a = very=20 specific and *constraining* construct.....I am assuming here we = respect=20 the rules of a connection (ie single source) though some = folks don't=20 even bother to respect this, and this is despite the fact = that we=20 all know what problems multiple-source constructs can cause = (from=20 LDP/PHP....ergo MPLS-TP). When we have a connection this = restricts=20 *all* DP (ie traffic and OAM) to stay within the bounds of = the=20 connection. Which is fine = under defect-free conditions, but if=20 we have leaking traffic then the constraining nature of the=20 connection construct is broken. In a nutshell what this = means=20 is that OAM that is of a request/response nature cannot be = trusted=20 in co mode networks under misconnectivity defects.....indeed, = why=20 should a leaking DP have a symmetric go/return defect=20 behaviour?....very likely it won't. So whilst = request/response OAM=20 is right for the cl mode it is not right for the co mode = under=20 misconnectivity defect conditions. More generally the 3 = modes are=20 different and not just in OAM requirements....but AIS/FDI in = the cl=20 mode?...do me a favour!...at least IEEE had the good sense to = bin this=20 for Ethernet even though it remains in Y.1731. And = which is=20 why I often trot-out the rather silly (to have to say this)=20 observation that if IP (cl mode) could do it all then why=20 have IETF found it necessary to create MPLS (co-ps) and = GMPLS (CP=20 for co-cs). The answer lies in the physics...and G.800 = attempts=20 to explain that physics....G.805 does not. So, the 3 = modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the OAM = of the 3=20 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, = John=20 E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; = Alexander=20 Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > = requirements >=20 > Italo, > > As described in the MPLS TP OAM=20 Requirements I-D, virtually all of the > OAM functions = require a=20 return path, and in the absence of a return > path they are = disabled. > > As described in David Sinicrope's = meeting=20 minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/w= iki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to be = used to=20 instantiate this forwarding. > > As an aside, the = issue of=20 return path for unidirectional LSPs could be > = charaterized as=20 the elephant in the room. In the MPLS TP OAM > = Framework I-D,=20 unicast LSPs are only mentioned three times and return > = paths not=20 at all. > > Thanks, > > John > = >=20 -----Original Message----- > > From: BUSI ITALO = [mailto:Italo.Busi@alcatel-lucent.it] > > = Sent: Friday,=20 April 17, 2009 1:59 AM > > To: Drake, John E; Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org >=20 > Subject: RE: [mpls-tp] Associated bidirectional transport = path=20 > > requirements > > > > = John, > >=20 > > I might have missed the agreement of MPLS-TP being = capable=20 of > > sending replies to OAM requests sent on = uni-directional=20 LSPs. > > > > This requirement does not belong = to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken into = account=20 (at worst in a > subsequent phase). > > > = > I=20 think that this requirement needs to be evaluated versus other = >=20 > more important requirements (e.g. the possibility to work w/o = IP=20 > > forwarding and the need for OAM to continue to = monitor the=20 data > > plane also in case of failures affecting the = control or=20 management > > plane). > > > > I am = open to=20 discuss it but not sure this is the right time because > = > I=20 wish to avoid delaying the first phase of the design = solution. >=20 > > > Thanks, Italo > > > > >=20 -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, = John=20 E > > > Sent: Thursday, April 16, 2009 8:00 PM > = >=20 > To: Alexander Vainshtein; Maarten Vissers > > > = Cc: mpls-tp@ietf.org >=20 > > Subject: Re: [mpls-tp] Associated bidirectional = transport path=20 > > > requirements > > > > > = > At=20 the meeting last fall at Juniper in Massachusetts, I > > = think it=20 was > > > agreed that an MPLS TP network needs to have = a=20 forwarding > > capability > > > for = management,=20 control, and OAM packets (e.g., sending > > replies to=20 OAM > > > requests sent on uni-directional LSPs) even = if it=20 does not > > have an IP > > > forwarding data = plane. > > > > > > > -----Original=20 Message----- > > > > From: Alexander = Vainshtein >=20 > > [mailto:Alexander.Vainshtein@ecitele.com] > > = > >=20 Sent: Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = > >=20 requirements > > > > > > > >=20 Maarten, > > > > It seems that you've just = (implicitly and,=20 probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will = not ever=20 support MIP loopback function > > (and fault > > = >=20 > localization which requires this function ) for > >=20 unidirectional P2MP > > > > and P2P paths. > = >=20 > > > > > > If this statement is correct, = this (IMHO=20 and FWIW) > raises a valid > > > > = question: >=20 > > > > > > > = =20 Is MPLS-TP an appropriate solution for=20 these > types of transport > > > > = paths? >=20 > > > > > > > For the reference, IP/MPLS = provides=20 this kind of > > functionality today > > > = > for=20 (unidirectional - but it does not know any other > > = type) P2P=20 LSPs > > > > as described in RFC 4379. And its = extension to=20 P2MP LSPs seems > > > > easy... > > > = >=20 > > > > > > > > > = > >=20 > Regards, > > > > > > > > = =20 Sasha > > > > > > > > = > >=20 > > > > > >=20 ________________________________________ > > > > = From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On = Behalf >=20 > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > = > Sent:=20 Thursday, April 16, 2009 3:24 PM > > > > To: = 'Adrian=20 Farrel' > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = > >=20 requirements > > > > > > > >=20 Adrian, > > > > > > > > >>=20 <quote> > > > > >> = The=20 intermediate nodes (including MEPs, MIPs and > > > = > other=20 internal > > > > >> = functions as=20 appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> = path at=20 each (sub-)layer MUST be aware of the pairing > > > = >=20 >> relationship of the forward and the=20 backward > > > > directions of that > > = > >=20 >> transport path. > > > = >=20 >> <end quote> > > > > > > = > >=20 > > There is no way this is a functional requirement. = That >=20 > > is, there is > > > > > *nothing* that = can be=20 observed from a black box point of > > > view = that >=20 > > > > results from adhering to this = requirement. >=20 > > > > > > > Your understanding is not = correct.=20 It is very much > observable if > > > > this=20 requirement is met from a black box point of view. > > = > >=20 The MIP functions can only perform the Loopback when there is a = >=20 > > > co-routed bidirectional transport path. The MPLS-TP = LBM=20 packet > > > > received at a MIP needs to be = returned (as=20 LBR > > > > packet) to the originating MEP function = via the=20 other > > direction of > > > > the = co-routed=20 bidirectional transport path. This other > direction > = >=20 > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > = >=20 > would fail. > > > > > > > > = Similarly,=20 when we have to apply TCM MEPs to monitor a > > segment,=20 then > > > > this is possible in a co-routed bidir=20 transport path > but not in a > > > > = associated=20 bidir transport path. In the first case the TCM MEP > > = >=20 > Source and Sink functions are co-located and can > = exchange=20 what is > > > > called "remote information" which = is=20 necessary for performance > > > > = monitoring. > >=20 > > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > > = >=20 > The entirety of the bracketted text "(including MEPs, > = >=20 > MIPs and other > > > > internal > > = > >=20 > functions as appropriate)" should be deleted. It does = not >=20 > > > add to "The > > > > > = intermediate=20 nodes." > > > > > > > > Your = understanding=20 is not correct. This text must not be > > deleted = at > >=20 > > all. > > > > > > > > > = Actually, I am quite fed up about this persistent > > = >=20 insistence on the > > > > inclusion > > = > >=20 > of "Tandem Connection." The definition within the ITU-T = of >=20 > > > this term > > > > > is > = > >=20 > poorly > > > > > specified and comes from = the=20 monitoring of a path that is > > > > parallel = (i.e. >=20 > > > tandem) > > > > > to the data = path being=20 monitored. This definition of TC > > > > seems to = be=20 at > > > > variance, > > > > > = and would=20 be if the ACH was actually in band. > > > > = > >=20 > > I don't understand where your interpretation of = tandem >=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of = a > >=20 > > path that is parallel (i.e. tandem) to the data path = being=20 > > > > monitored."? > > > > = > >=20 > > There is a "network connection" and this network > = >=20 connection is a set > > > > of interconnected "link = connections" and "matrix > connections". A > > > = >=20 subset of those interconnected link connections and matrix = > >=20 > > connections can be monitored and is then referred to = as >=20 a "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There is=20 only additional OAM inserted inside the data > path by = the >=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM = MEP_Sk=20 function. > > > > > > > > = Regards, >=20 > > > Maarten > > > > > > > = >=20 > > > > -----Original Message----- > > = > >=20 From: mpls-tp-bounces@ietf.org > > > = >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian=20 Farrel > > > > Sent: donderdag 16 april 2009 = 11:59 >=20 > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > > Cc:=20 BUSI ITALO; mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = > >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > = Unfortunately I=20 cannot fully agree with your statement: > > > >=20 > > > > > > <quote> > > > = > >=20 From the point of view of hardware, = co-routed > >=20 > bidirectional LSPs > > > > > = are a=20 special case of associated bidirectional LSPs. > > > = > >=20 <end quote> > > > > > > > > = > >=20 This statement would be obviously correct, were it not for > = >=20 > > Requirement > > > > > 34 in the latest = MPLS-TP=20 requirements draft > > > > > > > > = OK. Got=20 it. > > > > > > > > But what is = this doing=20 in the data plane requirements section? > > > > = >=20 > > > In fact, what is this requirement actually = saying? >=20 > > > > > > > > <quote> > = >=20 > > > The intermediate nodes = (including MEPs,=20 MIPs and > > > other internal > > > > = >=20 functions as appropriate) of a = co-routed > >=20 > > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the=20 pairing > > > > > = relationship of=20 the forward and the backward > > > > directions of=20 that > > > > > transport=20 path. > > > > > <end quote> > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > is, there is > > > > *nothing* = that can=20 be observed from a black box point of > > view = that > >=20 > > results from adhering to this requirement. > > = >=20 > > > > > Therefore it could be assumed that = this=20 requirement is met by > > > > configuring some = data plane=20 database component through the > > > > management = plane.=20 The database component is not used > for anything > = > >=20 > except to satisfy this requirement for "awareness". > = > >=20 > > > > > Ben! Can we please try to rewrite = this=20 requirement in terms of > > > > behavior? > = >=20 > > > > > > > Please note that = Requirement 34 is=20 the ONLY item in the > > > > list that is > = > >=20 > > specific for co-routed bidirectional LSPs. (The = pairing >=20 > > > requirements > > > > > at end = points for=20 co-routed and associated bidirectional > > > paths = are >=20 > > > > exactly the same even if they appear in two=20 different > > > items in the > > > > = >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > = > >=20 bidirectional paths would be void of any data plane = content. > >=20 > > > > > > > > The somewhat vague = scope of=20 this requirement ("other internal > > > > > = functions=20 as appropriate") creates a suspicion that HW > > > = >=20 support of the > > > > > pairing awareness may = be=20 required in order to comply with it. > > > > = > >=20 > > The entirety of the bracketted text "(including = MEPs, >=20 > MIPs and other > > > > internal functions as=20 appropriate)" should be deleted. It > > does not > = >=20 > > add to "The intermediate nodes." > > > > = >=20 > > > > The following text in the draft increases this = suspicion: > > > > > > > > > > = <quote> > > > > > Tandem = Connection: A=20 tandem connection is an > > arbitrary part of a > = > >=20 > > transport path that can be monitored (via = OAM) >=20 > > > independently from the > > > > > = =20 end-to-end monitoring (OAM). It may be a monitored > = >=20 segment or a > > > > > monitored = concatenated=20 segment of a transport path. > > The = tandem > >=20 > > > connection may also include the forwarding = engine(s)=20 of > > > > the node(s) > > > > > = =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = > >=20 Actually, I am quite fed up about this persistent > > = insistence=20 on the > > > > inclusion of "Tandem Connection." = The=20 definition within > > the ITU-T of > > > > = this=20 term is poorly specified and comes from the > monitoring of=20 a > > > > path that is parallel (i.e. tandem) to = the data=20 path being > > > > monitored. This definition of = TC seems=20 to be at variance, > > and would > > > > = be if the=20 ACH was actually in band. > > > > > > = > >=20 > Doesn't "forwarding engine" sound like hardware to = you? > >=20 > > > > > > Yes, but so what? > > = > >=20 > > > > > IMHO it is worth noting that neither = the=20 MPLS-TP > > > Requirements draft > > > = > >=20 nor the MPLS-TP OAM requirements one > > > > > = >=20 > > > > > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > > = > >=20 > > > > But tandem connections are discussed in the = MPLS-TP=20 OAM > > Framework > > > > > = draft > >=20 > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-fr >=20 > > > amework-00.txt > > > > ). > = > >=20 > > > > > Right. > > > > Let's = just get=20 rid of an unnecessary term and bring all > the I-Ds > = >=20 > > into line. > > > > > > > = > >=20 The bottom line, IMHO, is that some clarity regarding > > = >=20 co-routed vs. > > > > > associated > > = >=20 > > bidirectional paths is still required. One way to=20 provide > > > > that could > > > > = > be=20 by explicitly limiting Requirement 34 to specific > > = >=20 functionality. > > > > > > > >=20 Agreed. > > > > > > > > = Adrian > >=20 > > > > > > > > > > > = >=20 > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > = Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org >=20 > > > Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path > > > > requirements > > > > = >=20 > > > Hi Sasha, > > > > > > > = >=20 Not really sure whether you are misrepresenting anyone, = but... >=20 > > > > > > > > 1. My reading of = one of=20 Ben's messages is that associated > > > > = >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will=20 have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > > = This is=20 clearly nonsense! > > > > From the point of view of = hardware, co-routed > > bidirectional LSPs are > = > >=20 > a special case of associated bidirectional LSPs. > > = >=20 > > > > > If you can set up two unidirectional = LSPs=20 (e.g. using the > > management > > > > = plane) you=20 can surely set up a co-routed > > > bidirectional = LSP. >=20 > > > > > > > There are shipping = solutions that=20 achieve co-routed > bidirectional > > > > = LSPs using=20 the control plane. These either use the GMPLS > > (which=20 is > > > > cleaner) or non-standard proprietary = solutions=20 (which is > > messy but > > > >=20 functional). > > > > > > > > But = (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are software > > > > = solutions. >=20 > > > > > > = > >=20 2. My reading of one of Neil's messages is that the actual > = >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > > = transport networks rather than any specific benefit. > > = >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, > >=20 > > feel, and behavioral characteristics of a = "legacy" > >=20 > > transport network. > > > > > > = >=20 > > Based on these observations, I'd guess (FWIW) = that: > >=20 > > > * associated bidirectional paths are, at least for = the=20 time > > > > > being, the most = important=20 type of bidirectional paths in > > > > > =20 MPLS-TP > > > > > > > > I = think that=20 is wrong both given my statement above, and > > given=20 that > > > > other upgrades to existing MPLS = solutions will=20 be > needed to reach > > > > the full = function level=20 of MPLS-TP. > > > > > > > > > * = they had=20 a good chance to remain the only type of > >=20 bidirectional > > > > > paths in = real=20 deployments. > > > > > > > > I = don't see=20 what that follows from. > > > > > > > = >=20 Cheers, > > > > Adrian > > > > = > >=20 > > _______________________________________________ > = >=20 > > mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 _______________________________________________ mpls-tp = mailing=20 list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ----------------------------------------------------= ---- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ________________________________= _______________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp = ------=_NextPart_000_001D_01C9C3B2.1AEDB1F0-- From benjamin.niven-jenkins@bt.com Wed Apr 22 16:59:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAECD3A6934 for ; Wed, 22 Apr 2009 16:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8kfphkr06Hr for ; Wed, 22 Apr 2009 16:59:08 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C5DAF28C52A for ; Wed, 22 Apr 2009 16:57:38 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 00:58:55 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Apr 2009 23:58:54 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 23 Apr 2009 00:58:52 +0100 From: Ben Niven-Jenkins To: , "BRUNGARD, DEBORAH A, ATTLABS" Message-ID: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDpkljnFPJ53FoTkiYXmmzxV4tpA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Apr 2009 23:58:55.0022 (UTC) FILETIME=[4B3064E0:01C9C3A6] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:59:08 -0000 On 21/04/2009 02:59, "liu.guoman@zte.com.cn" wrote: > Deborah: > maybe what you said is right. but I can't completely agree your opinions. > IMO. mpls-tp is regard as transport network like SDH/SONET. so it should > have AIS/FDI fuctions as SDH/SONET. > > do you think so. No we must assess the requirements for packet transport networks supporting the needs of operators today and in the future. We must not blindly recreate SDH/SONET. If we do so without consideration to how operators' needs and requirements may have evolved (and continue to evolve in future) we will have failed IMO and I would severely question the value of the work we will have produced. If we just recreate SDH/SONET then what is the purpose of the work an operator would be better off just deploying existing SDH/SONET equipment. Ben From gregimirsky@gmail.com Wed Apr 22 17:13:24 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC493A69BC for ; Wed, 22 Apr 2009 17:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD13Tcac0Ff3 for ; Wed, 22 Apr 2009 17:13:19 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0FB803A68C0 for ; Wed, 22 Apr 2009 17:13:17 -0700 (PDT) Received: by fxm2 with SMTP id 2so270842fxm.37 for ; Wed, 22 Apr 2009 17:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MXLzTiHax6DSe0hWxLeaUgKZoZnt7XlsypsMnC2UeOY=; b=dXOK+ToDuIidbEfEPREUXs92uBuWVnQHuB25MTir5LvQc1YYBDkFwEKTT87EM8nOBO 2UVLWWv5E05jXcoI4js2z+4nTT3M52iXaLX8JYIIqasC4F7wd6dlYDn8EZTpGwPFkUGG tbwjD18Eu298jIyaq7ANxLgAaISSUsD2ESk18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bf+2Ug/WO33VfYdEyLDWtMH0SLjfNAJMbSKogXSkGQLg2C+PL1/0gMmWN53IBm3MfB J2isDCL+fELp7HWhpHWWsqBes5pSh9RMv7mUgair2LYLTq7atk7qhiEOoBK+aYGlRwBg 8PudWlS1BDn9HwIUm5QM4sMeivTS/dZQfDF/U= MIME-Version: 1.0 Received: by 10.103.223.2 with SMTP id a2mr226992mur.88.1240445674744; Wed, 22 Apr 2009 17:14:34 -0700 (PDT) In-Reply-To: <001c01c9c3a1$5764e1f0$a402540a@china.huawei.com> References: <787be2780904221400j14cdf9c6gfa562548dd808516@mail.gmail.com> <001c01c9c3a1$5764e1f0$a402540a@china.huawei.com> Date: Wed, 22 Apr 2009 17:14:34 -0700 Message-ID: <787be2780904221714l4e3c5fffv6db3cf2ebae4c40a@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=00163642702bce6fd704682dc35a Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 00:13:24 -0000 --00163642702bce6fd704682dc35a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, I agree with your presentation of layers but only wonder why you've placed UNIs both as clients of EVC layer as well as its peers. I'd leave UNIs only as clients of EVC layer. Would you agree? Regards, Greg 2009/4/22 Maarten Vissers > Dear Greg, > > Thank you for this confirmation. > This other layer is that the EVC layer as illustrated in the figure below= ? > > UNI UNI > --||------- ---------||----- > | | > UNI ------------------------------------------------- UNI > --||----| EVC layer |-----||----- > ------------------------------------------------- > | MPLS-TP layer | | other layer | > ----------------- ---------------- > > MEF's E-Tree is a bidirectional rooted-multipoint connection, in which > frames are forwarded on the basis of the value in their DA field. Such > selective forwarding is not supported in an LSP connection. An LSP > connection will as such just support one EVC link connection, i.e. a part= of > the EVC between two adjacent EVC switch/bridge functions. Those p2p EVC l= ink > connections simply require non-selective forwarding, something that an LS= P > connection can provide. > > Regards, > Maarten > > ------------------------------ > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* woensdag 22 april 2009 23:00 > > *To:* Maarten Vissers > *Cc:* mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] Associated bidirectional transport path > requirements > > Dear Maarten, > I think you've captured my view pretty accurately. Since MPLS-TP supports > only p2p and p2mp transports it would be responsibility of another layer = to > support specific services among UNI-Ns. Interesting thing that E-Tree can > not be directly mapped to p2mp unidirectional MPLS-TP LSP since by MEF's > definition E-Tree is a bidirectional service. (Just a note). > > Kind regards, > Greg > > 2009/4/22 Maarten Vissers > >> Dear Greg, >> >> Do you mean that there is a layer network above MPLS-TP that will suppor= t >> these services from UNI-N port to UNI-N port, and that MPLS-TP will supp= ort >> this service layer network? >> >> Regards, >> Maarten >> >> ------------------------------ >> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >> *Sent:* woensdag 22 april 2009 18:25 >> *To:* Maarten Vissers >> *Cc:* neil.2.harrison@bt.com; mpls-tp@ietf.org >> >> *Subject:* Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Dear Maarten, >> I believe that it is not a requirement for MPLS-TP to support any specif= ic >> service, including ones you've listed in your message. On the other hand= , >> support of listed services is a requirement for a client layer that uses >> MPLS-TP services. >> >> Regards, >> Greg Mirsky >> >> 2009/4/22 Maarten Vissers >> >>> Neil, >>> >>> I expect that the main requirement for a packet transport network >>> technology like MPLS-TP is that it is able to support at least the foll= owing >>> services: >>> - E-Line >>> - E-Tree >>> - E-LAN >>> - PDH CES >>> in a traffic engineered and managed manner. >>> >>> Another main requirement is that it must be able to support those >>> services in a scalable manner between points anywhere in the world. >>> >>> The E-Line, E-Tree and E-LAN services allow to reorder client frames th= at >>> belong to different priorities and to drop client frames that are drop >>> eligible. >>> >>> The E-Tree and E-LAN services require that client bits are read to >>> deliver the frames to the appropriate output port or ports of the E-Tre= e or >>> E-LAN supporting transport entity/differentiated connection. >>> >>> The packet transport network technology must as such support traffic >>> engineered transport entities (differentiated connections) with n input >>> ports (i.e. multi source constructs). This in addition of traffic engin= eered >>> transport entities with 1 input port. >>> >>> Regards, >>> Maarten >>> >>> ------------------------------ >>> *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On >>> Behalf Of *neil.2.harrison@bt.com >>> *Sent:* dinsdag 21 april 2009 14:31 >>> *To:* liu.guoman@zte.com.cn; dbrungard@att.com >>> >>> *Cc:* mpls-tp@ietf.org >>> *Subject:* Re: [mpls-tp] Associated bidirectional transport path >>> requirements >>> >>> Liu, >>> >>> If MPLS-TP is going to be taken seriously as a transport network (like >>> SDH/SONET) then the 2 key MUST HAVE requirements are these. >>> >>> 1 Provide a transparent client/server relationship...which means: >>> - all client bits treated equally >>> - client bit ordering preserved >>> - no attempt to infer client symbol (ie sequence of client bits) >>> meaning and no attempt to change client symbols >>> - the traffic behaviour of client X must not impact the performance >>> experienced by client Y >>> >>> A key corollary of the above is that MPLS-TP must only support proper >>> connections (ie single source constructs) >>> >>> >>> 2 Since MPLS-TP is a transport network it is not a top-of-stack netwo= rk >>> (ie it does not support directly external message/file/stream >>> applications). MPLS-TP therefore does not require an E-NNI specificati= on. >>> A key corollary of this is that MPLS-TP will not have any peer interwor= king >>> relationship with any other network mode/technology. >>> >>> >>> Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this shou= ld >>> have FDI/AIS....however, the merit of this is highly questionable. Whe= n I >>> and colleagues discussed whether PBB-TE (also a co-ps mode network) sho= uld >>> have FDI/AIS we concluded that on balance it was not a good idea.....an= d >>> note that initially I was in favour of having AIS, but my colleagues >>> provided strong technical arguments that convinced me otherwise. >>> >>> AIS/FDI is historically linked to the early PDH co-cs mode layer networ= ks >>> that used TTL logic. When this died it put out a +5V (all 1s) signal b= y >>> default, ie it required no conscious effort to generate it.....this is = key >>> point. Further, in these networks there is a fairly static/long-holdin= g >>> client server relationship. Clearly this is not true in the cl-ps mode= and >>> it's why IETF have never specified AIS for IP and its why IEEE had the = good >>> sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisel= y IMO >>> retained it in Y.1731....but I suspect any operator planning to use Eth= ernet >>> equipment would always look to IEEE stds and not ITU ones). >>> >>> AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we >>> considered not a good idea for PBB-TE OAM because it requires a conscio= us >>> effort to generate it (unlike the co-cs mode) so there are likely to be >>> scaling problems and its one more thing to go wrong. >>> >>> You should also have seen me make the point many times in the past that >>> the always-on defect detection/handling OAM needs to be as simple/spars= e as >>> possible with as little config as possible because we need super >>> reliability......TCM goes completely against the grain here. Also note= that >>> the OAM required for each of the 3 network modes is not the same, despi= te >>> what some claim. >>> >>> regards, Neil >>> >>> >>> ------------------------------ >>> *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On >>> Behalf Of *liu.guoman@zte.com.cn >>> *Sent:* 21 April 2009 02:59 >>> *To:* BRUNGARD, DEBORAH A, ATTLABS >>> *Cc:* mpls-tp@ietf.org >>> *Subject:* Re: [mpls-tp] Associated bidirectional transport path >>> requirements >>> >>> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >>> opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. s= o it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >>> >>> best regards >>> liu >>> >>> >>> *"BRUNGARD, DEBORAH A, ATTLABS" * >>> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org >>> >>> 2009-04-20 23:47 >>> =CA=D5=BC=FE=C8=CB >>> "Maarten Vissers" , >>> =B3=AD=CB=CD >>> mpls-tp@ietf.org =D6=F7=CC=E2 >>> Re: [mpls-tp] Associated bidirectional transport path requirements >>> >>> >>> >>> >>> I agree with Neil, it is very questionable the value of AIS/FDI in a >>> packet network- any mode. It can result in a DoS attack by an operator >>> on themselves so even Y1731 recommends not to block data frames: >>> "A MEP can decide whether it blocks data frames when it detects dAIS. >>> The principle requirement >>> that influences this decision is that data frames ought to be forwarded >>> as much as possible, without >>> the possibility of forwarding wrong data frames downstream." >>> Table I.7-2 shows for AIS, not to block. >>> >>> And as Y1731 states, AIS can only be used under very constrained >>> architectures - if required for MPLS-TP, it needs to have the same >>> guidance as in Y1731, i.e. point-to-point and server/client one-to-one: >>> "for a point-to-point ETH connection, a MEP has only a single peer MEP. >>> Therefore, there >>> is no ambiguity regarding the peer MEP for which it should suppress >>> alarms when it receives the >>> ETH-AIS information." >>> So should only be within one domain - then no need. >>> >>> Deborah >>> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>> Behalf Of Maarten Vissers >>> Sent: Monday, April 20, 2009 10:05 AM >>> To: neil.2.harrison@bt.com >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>> requirements >>> >>> Neil, >>> >>> > but AIS/FDI in the cl mode?...do me a favour! >>> >>> Ethernet AIS is indeed a requirement and a necessity. And you will not >>> be >>> able to understand that as long as you refuse to accept that "cl-mode" >>> is a >>> forwarding mode within a **transport entity**. G.800 amendment 1 has >>> finally >>> reintroduced this transport entity into G.800. Besides that, it also >>> introduced the **differentiated connection**: >>> >>> [G.800 am1] "A differentiated connection is a transport entity that >>> transfers information belonging to multiple communications between port= s >>> across a subnetwork. <..> In a differentiated connection message >>> contents >>> are interpreted to identify (sets of) communications which receive >>> different >>> treatment. The sets of communications may be distinguished by the >>> forwarding identifier or other layer information. Order is not >>> necessarily >>> preserved between messages belonging to sets of communications receivin= g >>> different treatment. Sets of communications may be identified for >>> purposes >>> such as traffic conditioning or preserving communication message order.= " >>> >>> >>> Ethernet VLANs are in terms of G.800 "differentiated connections". >>> Ethernet >>> AIS provides AIS within the scope of such "differentiated connection". >>> If >>> you apply this to my proposed PTN layer stack, then the EVC layer >>> topology >>> will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and >>> P-OTN >>> VP trails inside metro and core domains interconnecting EVC matrices. >>> When >>> one of those EVC links is interrupted, e.g. in the core between metro 1 >>> and >>> metro 4 (see attached slide), then the EVC differentiated connection >>> that is >>> present on this link will be interrupted. At the EVC switch/bridge node >>> in >>> metro 4 this interruption is noticed and EVC-AIS is inserted in the >>> downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 >>> and >>> D5. >>> >>> The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, >>> which guarantees that the AIS is broadcast to the endpoints of the EVC. >>> >>> I believe that it is time for you to adapt your view on co and cl modes >>> and >>> relate it to the forwarding mode **INSIDE** a transport entity. >>> >>> What we know as the internet is essentially an "IP differentiated >>> connection" with a billion or more ports. >>> What we know as an IP VPN is essentially an "IP differentiated >>> connection" >>> with e.g. n ports (n in the range of e.g. 2 to 1000). >>> What we know as an Ethernet VLAN is essentially an "Ethernet >>> differentiated >>> connection" with n ports (n in the range of e.g. 2 to 1000). >>> What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated >>> connection" with 2 ports. >>> What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. >>> >>> Transport network OAM applies to transport entities, which are (in term= s >>> of >>> G.800 am1) connections and differentiated connections. >>> >>> Regards, >>> Maarten >>> >>> -----Original Message----- >>> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>> Sent: vrijdag 17 april 2009 22:00 >>> To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; >>> Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com >>> Cc: mpls-tp@ietf.org >>> Subject: RE: [mpls-tp] Associated bidirectional transport path >>> requirements >>> >>> John, Thanks this is a great platform to explain why OAM for the 3 >>> network >>> modes needs to be different. I am getting a wee bit tired of folks >>> trying >>> to make all 3 network modes look alike (and then, even worse, interwork >>> them >>> as as peers...esp when not not top-of-stack >>> networks...I mean how silly can we get?). I am even more frustrated b= y >>> the fact those peddling this FUD only ever seem to consider OAM and >>> forget >>> all other DP/CP/MP components (esp top-of-stack message/file/stream >>> application adaptations). How wrong can this get! >>> >>> In the co modes a *connection* is a very specific and *constraining* >>> construct.....I am assuming here we respect the rules of a connection >>> (ie >>> single source) though some folks don't even bother to respect this, and >>> this >>> is despite the fact that we all know what problems multiple-source >>> constructs can cause (from LDP/PHP....ergo MPLS-TP). >>> >>> When we have a connection this restricts *all* DP (ie traffic and OAM) >>> to >>> stay within the bounds of the connection. Which is fine under >>> defect-free >>> conditions, but if we have leaking traffic then the constraining nature >>> of >>> the connection construct is broken. In a nutshell what this means is >>> that >>> OAM that is of a request/response nature cannot be trusted in co mode >>> networks under misconnectivity defects.....indeed, why should a leaking >>> DP >>> have a symmetric go/return defect behaviour?....very likely it won't. >>> So >>> whilst request/response OAM is right for the cl mode it is not right fo= r >>> the >>> co mode under misconnectivity defect conditions. >>> >>> More generally the 3 modes are different and not just in OAM >>> requirements....but AIS/FDI in the cl mode?...do me a favour!...at leas= t >>> IEEE had the good sense to bin this for Ethernet even though it remains >>> in >>> Y.1731. And which is why I often trot-out the rather silly (to have to >>> say >>> this) observation that if IP (cl mode) could do it all then why have >>> IETF >>> found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). Th= e >>> answer lies in the physics...and G.800 attempts to explain that >>> physics....G.805 does not. >>> >>> So, the 3 modes are different...please accept/rejoice in this fact as >>> they >>> all offer something different/important. But do not be hoodwinked by >>> those >>> who peddle a story that that tries to make the OAM of the 3 modes the >>> same. >>> >>> regards, Neil >>> >>> > -----Original Message----- >>> > From: mpls-tp-bounces@ietf.org >>> > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >>> > Sent: 17 April 2009 20:02 >>> > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers >>> > Cc: mpls-tp@ietf.org >>> > Subject: Re: [mpls-tp] Associated bidirectional transport path >>> > requirements >>> > >>> > Italo, >>> > >>> > As described in the MPLS TP OAM Requirements I-D, virtually all of th= e >>> >>> > OAM functions require a return path, and in the absence of a return >>> > path they are disabled. >>> > >>> > As described in David Sinicrope's meeting minutes >>> > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >>> > meeting-no >>> > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an >>> > MPLS TP network needs to be capable of getting IP packets from >>> > destination to source; neither the minutes nor I stipulate that a >>> > control plane needs to be used to instantiate this forwarding. >>> > >>> > As an aside, the issue of return path for unidirectional LSPs could b= e >>> >>> > charaterized as the elephant in the room. In the MPLS TP OAM >>> > Framework I-D, unicast LSPs are only mentioned three times and return >>> > paths not at all. >>> > >>> > Thanks, >>> > >>> > John >>> > > -----Original Message----- >>> > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >>> > > Sent: Friday, April 17, 2009 1:59 AM >>> > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers >>> > > Cc: mpls-tp@ietf.org >>> > > Subject: RE: [mpls-tp] Associated bidirectional transport path >>> > > requirements >>> > > >>> > > John, >>> > > >>> > > I might have missed the agreement of MPLS-TP being capable of >>> > > sending replies to OAM requests sent on uni-directional LSPs. >>> > > >>> > > This requirement does not belong to the first set of requirements >>> > > ITU-T is expecting to be met by October. >>> > > >>> > > However, I think this in a potential interesting additional >>> > > requirement to be taken into account (at worst in a >>> > subsequent phase). >>> > > >>> > > I think that this requirement needs to be evaluated versus other >>> > > more important requirements (e.g. the possibility to work w/o IP >>> > > forwarding and the need for OAM to continue to monitor the data >>> > > plane also in case of failures affecting the control or management >>> > > plane). >>> > > >>> > > I am open to discuss it but not sure this is the right time because >>> > > I wish to avoid delaying the first phase of the design solution. >>> > > >>> > > Thanks, Italo >>> > > >>> > > > -----Original Message----- >>> > > > From: mpls-tp-bounces@ietf.org >>> > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >>> > > > Sent: Thursday, April 16, 2009 8:00 PM >>> > > > To: Alexander Vainshtein; Maarten Vissers >>> > > > Cc: mpls-tp@ietf.org >>> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >>> > > > requirements >>> > > > >>> > > > At the meeting last fall at Juniper in Massachusetts, I >>> > > think it was >>> > > > agreed that an MPLS TP network needs to have a forwarding >>> > > capability >>> > > > for management, control, and OAM packets (e.g., sending >>> > > replies to OAM >>> > > > requests sent on uni-directional LSPs) even if it does not >>> > > have an IP >>> > > > forwarding data plane. >>> > > > >>> > > > > -----Original Message----- >>> > > > > From: Alexander Vainshtein >>> > > > [mailto:Alexander.Vainshtein@ecitele.com] >>> > > > > Sent: Thursday, April 16, 2009 9:57 AM >>> > > > > To: Maarten Vissers >>> > > > > Cc: mpls-tp@ietf.org >>> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >>> > > > > requirements >>> > > > > >>> > > > > Maarten, >>> > > > > It seems that you've just (implicitly and, probably, >>> > > > > inadvertently) stated the following: >>> > > > > >>> > > > > MPLS-TP OAM will not ever support MIP loopback >>> function >>> > > (and fault >>> > > > > localization which requires this function ) for >>> > > unidirectional P2MP >>> > > > > and P2P paths. >>> > > > > >>> > > > > If this statement is correct, this (IMHO and FWIW) >>> > raises a valid >>> > > > > question: >>> > > > > >>> > > > > Is MPLS-TP an appropriate solution for these >>> > types of transport >>> > > > > paths? >>> > > > > >>> > > > > For the reference, IP/MPLS provides this kind of >>> > > functionality today >>> > > > > for (unidirectional - but it does not know any other >>> > > type) P2P LSPs >>> > > > > as described in RFC 4379. And its extension to P2MP LSPs seems >>> > > > > easy... >>> > > > > >>> > > > > >>> > > > > >>> > > > > Regards, >>> > > > > >>> > > > > Sasha >>> > > > > >>> > > > > >>> > > > > >>> > > > > ________________________________________ >>> > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] >>> > > On Behalf >>> > > > > Of Maarten Vissers [maarten.vissers@huawei.com] >>> > > > > Sent: Thursday, April 16, 2009 3:24 PM >>> > > > > To: 'Adrian Farrel' >>> > > > > Cc: mpls-tp@ietf.org >>> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >>> > > > > requirements >>> > > > > >>> > > > > Adrian, >>> > > > > >>> > > > > >> >>> > > > > >> The intermediate nodes (including MEPs, MIPs and >>> > > > > other internal >>> > > > > >> functions as appropriate) of a co-routed >>> > > > > bidirectional transport >>> > > > > >> path at each (sub-)layer MUST be aware of the pairing >>> > > > > >> relationship of the forward and the backward >>> > > > > directions of that >>> > > > > >> transport path. >>> > > > > >> >>> > > > > > >>> > > > > > There is no way this is a functional requirement. That >>> > > > is, there is >>> > > > > > *nothing* that can be observed from a black box point of >>> > > > view that >>> > > > > > results from adhering to this requirement. >>> > > > > >>> > > > > Your understanding is not correct. It is very much >>> > observable if >>> > > > > this requirement is met from a black box point of view. >>> > > > > The MIP functions can only perform the Loopback when there is a >>> > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet >>> > > > > received at a MIP needs to be returned (as LBR >>> > > > > packet) to the originating MEP function via the other >>> > > direction of >>> > > > > the co-routed bidirectional transport path. This other >>> > direction >>> > > > > would not be available in an associated bidirectional transport >>> > > > > path... and thus the loopback test >>> > > > would fail. >>> > > > > >>> > > > > Similarly, when we have to apply TCM MEPs to monitor a >>> > > segment, then >>> > > > > this is possible in a co-routed bidir transport path >>> > but not in a >>> > > > > associated bidir transport path. In the first case the TCM MEP >>> > > > > Source and Sink functions are co-located and can >>> > exchange what is >>> > > > > called "remote information" which is necessary for performance >>> > > > > monitoring. >>> > > > > In the latter case the TCM MEP Source and Sink functions >>> > > are in e.g. >>> > > > > different nodes in the network and TCM would not be able >>> > > to provide >>> > > > > performance monitoring. >>> > > > > >>> > > > > > The entirety of the bracketted text "(including MEPs, >>> > > > MIPs and other >>> > > > > internal >>> > > > > > functions as appropriate)" should be deleted. It does not >>> > > > > add to "The >>> > > > > > intermediate nodes." >>> > > > > >>> > > > > Your understanding is not correct. This text must not be >>> > > deleted at >>> > > > > all. >>> > > > > >>> > > > > > Actually, I am quite fed up about this persistent >>> > > > insistence on the >>> > > > > inclusion >>> > > > > > of "Tandem Connection." The definition within the ITU-T of >>> > > > > this term >>> > > > > > is >>> > > > > poorly >>> > > > > > specified and comes from the monitoring of a path that is >>> > > > > parallel (i.e. >>> > > > > tandem) >>> > > > > > to the data path being monitored. This definition of TC >>> > > > > seems to be at >>> > > > > variance, >>> > > > > > and would be if the ACH was actually in band. >>> > > > > >>> > > > > I don't understand where your interpretation of tandem >>> > > connection is >>> > > > > described in ITU-T recommendations. I.e. "from the >>> > > monitoring of a >>> > > > > path that is parallel (i.e. tandem) to the data path being >>> > > > > monitored."? >>> > > > > >>> > > > > There is a "network connection" and this network >>> > > connection is a set >>> > > > > of interconnected "link connections" and "matrix >>> > connections". A >>> > > > > subset of those interconnected link connections and matrix >>> > > > > connections can be monitored and is then referred to as >>> > a "tandem >>> > > > > connection". There is no "path that is parallel to the >>> > > data path". >>> > > > > There is only additional OAM inserted inside the data >>> > path by the >>> > > > > TCM MEP_So function and this OAM is extracted from the >>> > > data path by >>> > > > > the TCM MEP_Sk function. >>> > > > > >>> > > > > Regards, >>> > > > > Maarten >>> > > > > >>> > > > > >>> > > > > -----Original Message----- >>> > > > > From: mpls-tp-bounces@ietf.org >>> > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel >>> > > > > Sent: donderdag 16 april 2009 11:59 >>> > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com >>> > > > > Cc: BUSI ITALO; mpls-tp@ietf.org >>> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >>> > > > > requirements >>> > > > > >>> > > > > Hi Sasha, >>> > > > > >>> > > > > > Unfortunately I cannot fully agree with your statement: >>> > > > > > >>> > > > > > >>> > > > > > From the point of view of hardware, co-routed >>> > > > bidirectional LSPs >>> > > > > > are a special case of associated bidirectional LSPs. >>> > > > > > >>> > > > > > >>> > > > > > This statement would be obviously correct, were it not for >>> > > > > Requirement >>> > > > > > 34 in the latest MPLS-TP requirements draft >>> > > > > >>> > > > > OK. Got it. >>> > > > > >>> > > > > But what is this doing in the data plane requirements section? >>> > > > > >>> > > > > In fact, what is this requirement actually saying? >>> > > > > >>> > > > > > >>> > > > > > The intermediate nodes (including MEPs, MIPs and >>> > > > other internal >>> > > > > > functions as appropriate) of a co-routed >>> > > > > bidirectional transport >>> > > > > > path at each (sub-)layer MUST be aware of the pairing >>> > > > > > relationship of the forward and the backward >>> > > > > directions of that >>> > > > > > transport path. >>> > > > > > >>> > > > > >>> > > > > There is no way this is a functional requirement. That >>> > > is, there is >>> > > > > *nothing* that can be observed from a black box point of >>> > > view that >>> > > > > results from adhering to this requirement. >>> > > > > >>> > > > > Therefore it could be assumed that this requirement is met by >>> > > > > configuring some data plane database component through the >>> > > > > management plane. The database component is not used >>> > for anything >>> > > > > except to satisfy this requirement for "awareness". >>> > > > > >>> > > > > Ben! Can we please try to rewrite this requirement in terms of >>> > > > > behavior? >>> > > > > >>> > > > > > Please note that Requirement 34 is the ONLY item in the >>> > > > > list that is >>> > > > > > specific for co-routed bidirectional LSPs. (The pairing >>> > > > > requirements >>> > > > > > at end points for co-routed and associated bidirectional >>> > > > paths are >>> > > > > > exactly the same even if they appear in two different >>> > > > items in the >>> > > > > > requirements' list). >>> > > > > > In other words, without Requirement 34 the notion of >>> > co-routed >>> > > > > > bidirectional paths would be void of any data plane content. >>> > > > > > >>> > > > > > The somewhat vague scope of this requirement ("other internal >>> > > > > > functions as appropriate") creates a suspicion that HW >>> > > > > support of the >>> > > > > > pairing awareness may be required in order to comply with it. >>> > > > > >>> > > > > The entirety of the bracketted text "(including MEPs, >>> > > MIPs and other >>> > > > > internal functions as appropriate)" should be deleted. It >>> > > does not >>> > > > > add to "The intermediate nodes." >>> > > > > >>> > > > > > The following text in the draft increases this suspicion: >>> > > > > > >>> > > > > > >>> > > > > > Tandem Connection: A tandem connection is an >>> > > arbitrary part of a >>> > > > > > transport path that can be monitored (via OAM) >>> > > > > independently from the >>> > > > > > end-to-end monitoring (OAM). It may be a monitored >>> > > segment or a >>> > > > > > monitored concatenated segment of a transport path. >>> > > The tandem >>> > > > > > connection may also include the forwarding engine(s) of >>> > > > > the node(s) >>> > > > > > at the edge(s) of the segment or concatenated segment. >>> > > > > > >>> > > > > >>> > > > > Actually, I am quite fed up about this persistent >>> > > insistence on the >>> > > > > inclusion of "Tandem Connection." The definition within >>> > > the ITU-T of >>> > > > > this term is poorly specified and comes from the >>> > monitoring of a >>> > > > > path that is parallel (i.e. tandem) to the data path being >>> > > > > monitored. This definition of TC seems to be at variance, >>> > > and would >>> > > > > be if the ACH was actually in band. >>> > > > > >>> > > > > > Doesn't "forwarding engine" sound like hardware to you? >>> > > > > >>> > > > > Yes, but so what? >>> > > > > >>> > > > > > IMHO it is worth noting that neither the MPLS-TP >>> > > > Requirements draft >>> > > > > > nor the MPLS-TP OAM requirements one >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requireme= n >>> > > > > > ts-01.txt) contain any requirements dealing with tandem >>> > > > connections. >>> > > > > > >>> > > > > > But tandem connections are discussed in the MPLS-TP OAM >>> > > Framework >>> > > > > > draft >>> > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >>> > > > > amework-00.txt >>> > > > > ). >>> > > > > >>> > > > > Right. >>> > > > > Let's just get rid of an unnecessary term and bring all >>> > the I-Ds >>> > > > > into line. >>> > > > > >>> > > > > > The bottom line, IMHO, is that some clarity regarding >>> > > > co-routed vs. >>> > > > > > associated >>> > > > > > bidirectional paths is still required. One way to provide >>> > > > > that could >>> > > > > > be by explicitly limiting Requirement 34 to specific >>> > > > functionality. >>> > > > > >>> > > > > Agreed. >>> > > > > >>> > > > > Adrian >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > ________________________________________ >>> > > > > From: Adrian Farrel [adrian@olddog.co.uk] >>> > > > > Sent: Thursday, April 16, 2009 12:13 AM >>> > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO >>> > > > > Cc: mpls-tp@ietf.org >>> > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path >>> > > > > requirements >>> > > > > >>> > > > > Hi Sasha, >>> > > > > >>> > > > > Not really sure whether you are misrepresenting anyone, but... >>> > > > > >>> > > > > > 1. My reading of one of Ben's messages is that associated >>> > > > > > bidirectional paths are the only types of paths that can be >>> > > > > created in >>> > > > > > the existing networks; "true" co-routed bidirectional paths >>> > > > > will have >>> > > > > > to wait until (if ever) new equipment becomes available. >>> > > > > >>> > > > > This is clearly nonsense! >>> > > > > From the point of view of hardware, co-routed >>> > > bidirectional LSPs are >>> > > > > a special case of associated bidirectional LSPs. >>> > > > > >>> > > > > If you can set up two unidirectional LSPs (e.g. using the >>> > > management >>> > > > > plane) you can surely set up a co-routed >>> > > > bidirectional LSP. >>> > > > > >>> > > > > There are shipping solutions that achieve co-routed >>> > bidirectional >>> > > > > LSPs using the control plane. These either use the GMPLS >>> > > (which is >>> > > > > cleaner) or non-standard proprietary solutions (which is >>> > > messy but >>> > > > > functional). >>> > > > > >>> > > > > But (of course) the management plane or control plane >>> > > solutions have >>> > > > > nothing to do with availability of equipment as they >>> > are software >>> > > > > solutions. >>> > > > > >>> > > > > > 2. My reading of one of Neil's messages is that the actual >>> > > > > driver for >>> > > > > > co-routed bidirectional paths may be experience with existing >>> > > > > > transport networks rather than any specific benefit. >>> > > > > >>> > > > > Isn't that the case with 75% of the MPLS-TP requirements? >>> > > > > Which is not to say it is a bad thing. >>> > > > > >>> > > > > A large driver for MPLS-TP is to give the packet network >>> > > the look, >>> > > > > feel, and behavioral characteristics of a "legacy" >>> > > > > transport network. >>> > > > > >>> > > > > > Based on these observations, I'd guess (FWIW) that: >>> > > > > > * associated bidirectional paths are, at least for the time >>> > > > > > being, the most important type of bidirectional paths in >>> > > > > > MPLS-TP >>> > > > > >>> > > > > I think that is wrong both given my statement above, and >>> > > given that >>> > > > > other upgrades to existing MPLS solutions will be >>> > needed to reach >>> > > > > the full function level of MPLS-TP. >>> > > > > >>> > > > > > * they had a good chance to remain the only type of >>> > > bidirectional >>> > > > > > paths in real deployments. >>> > > > > >>> > > > > I don't see what that follows from. >>> > > > > >>> > > > > Cheers, >>> > > > > Adrian >>> > > > > >>> > > > > _______________________________________________ >>> > > > > mpls-tp mailing list >>> > > > > mpls-tp@ietf.org >>> > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >>> > > > > >>> > > > > _______________________________________________ >>> > > > > mpls-tp mailing list >>> > > > > mpls-tp@ietf.org >>> > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >>> > > > > >>> > > > > >>> > > > _______________________________________________ >>> > > > mpls-tp mailing list >>> > > > mpls-tp@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/mpls-tp >>> > > > >>> > > >>> > _______________________________________________ >>> > mpls-tp mailing list >>> > mpls-tp@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mpls-tp >>> > >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >>> >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained in this mail= is solely property of the sender's organization. This mail communication i= s confidential. Recipients named above are obligated to maintain secrecy an= d are not permitted to disclose the contents of this communication to other= s. >>> This email and any files transmitted with it are confidential and inten= ded solely for the use of the individual or entity to whom they are address= ed. If you have received this email in error please notify the originator o= f the message. Any views expressed in this message are those of the individ= ual sender. >>> This message has been scanned for viruses and Spam by ZTE Anti-Spam sys= tem. >>> >>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >>> >> > --00163642702bce6fd704682dc35a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, I agree with your presentation of layers but only wonder w= hy you've placed UNIs both as clients of EVC layer as well as its peers= . I'd leave UNIs only as clients of EVC layer. Would you agree? Regards, Greg 2009/4/22 Maarten Visser= s <maart= en.vissers@huawei.com> Dear Greg, Thank you for this confirmation. This other layer is that the EVC layer as illustrated=20 in the figure below? =20 UNI            =             &nb= sp;            =             &nb= sp;      =20 UNI --||-------       &nb= sp;            =             &nb= sp;      =20    ---------||-----          = =20 |            &n= bsp;            = ;            &n= bsp; =20    | UNI  =20 -------------------------------------------------   =20 UNI --||----|        = ;        =20 EVC=20 layer           &nbs= p;        =20 |-----||-----        =20 -------------------------------------------------          &n= bsp;   | MPLS-TP=20 layer |    |  other layer |          &n= bsp;   -----------------   =20 ---------------- MEF's E-Tree is a bidirectional rooted-multipoin= t=20 connection, in which frames are forwarded on the basis of the value in thei= r DA=20 field. Such selective forwarding is not supported in an LSP connection. An = LSP=20 connection will as such just support one EVC link connection, i.e= . a=20 part of the EVC between two adjacent EVC switch/bridge functions. Those p2p= EVC=20 link connections simply require non-selective forwarding, something that an= LSP=20 connection can provide. Regards, Maarten From: Greg Mirsky= [mailto:gregimi= rsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00 To: Maarten=20 Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path requirements = Dear Maarten, I think you've captured my view pretty accu= rately.=20 Since MPLS-TP supports only p2p and p2mp transports it would be responsibil= ity=20 of another layer to support specific services among UNI-Ns. Interesting thi= ng=20 that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP LSP s= ince=20 by MEF's definition E-Tree is a bidirectional service. (Just a=20 note). Kind regards, Greg 2009/4/22 Maarten Vissers <= maarten.vis= sers@huawei.com> Dear=20 Greg, Do you=20 mean that there is a layer network above MPLS-TP that will support these= =20 services from UNI-N port to UNI-N port, and that MPLS-TP will support thi= s=20 service layer network? Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten=20 Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional=20 transport path requirements Dear Maarten, I believe that it is not a requirement for MP= LS-TP=20 to support any specific service, including ones you've listed in your= message.=20 On the other hand, support of listed services is a requirement for a clie= nt=20 layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers &l= t;maarten.v= issers@huawei.com> Neil, I expect=20 that the main requirement for a packet transport network technolog= y=20 like MPLS-TP is that it is able to support at least the following=20 services: -=20 E-Line -=20 E-Tree -=20 E-LAN - PDH=20 CES in a=20 traffic engineered and managed manner. Another=20 main requirement is that it must be able to support those services in a= =20 scalable manner between points anywhere in the world. The=20 E-Line, E-Tree and E-LAN services allow to reorder client frames t= hat=20 belong to different priorities and to drop client frames that are = drop=20 eligible. The=20 E-Tree and E-LAN services require that client bits are read to deliver = the=20 frames to the appropriate output port or ports of the E-Tree or E-= LAN=20 supporting transport entity/differentiated connection. The=20 packet transport network technology must as such support traffic=20 engineered transport entities (differentiated connections) with n = input=20 ports (i.e. multi source constructs). This in addition of traffic engin= eered=20 transport entities with 1 input port. Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:<= a href=3D"mailto:mpls-tp-bounces@ietf.org" target=3D"_blank">mpls-tp-bounce= s@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april=20 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path=20 requirements Liu, If MPLS-TP is going to be taken seriously as a tra= nsport network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. 1    Provide a transparent client/s= erver=20 relationship...which means: -    all client bits treated=20 equally -    client bit ordering preserved<= /font> -    no attempt to infer client sym= bol (ie sequence of=20 client bits) meaning and no attempt to change client=20 symbols -    the traffic behaviour of clien= t X must not impact=20 the performance experienced by client Y A key corollary of the above is that MPLS-TP must = only support proper=20 connections (ie single source constructs) 2   Since MPLS-TP is a transport network= it is not a=20 top-of-stack network (ie it does not support directly external=20 message/file/stream applications). MPLS-TP therefore does not req= uire=20 an E-NNI specification. A key corollary of this is that MPLS-TP w= ill=20 not have any peer interworking relationship with any other network=20 mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. = You could argue=20 this should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE (als= o a=20 co-ps mode network) should have FDI/AIS we concluded that on balance it= was=20 not a good idea.....and note that initially I was in favour of having A= IS,=20 but my colleagues provided strong technical arguments that convinced me= =20 otherwise. AIS/FDI is historically linked to the = early PDH co-cs=20 mode layer networks that used TTL logic. When this died it put ou= t a=20 +5V (all 1s) signal by default, ie it required no conscious effort to= =20 generate it.....this is key point. Further, in these networks the= re is=20 a fairly static/long-holding client server relationship. Clearly = this=20 is not true in the cl-ps mode and it's why IETF have never specifie= d AIS for=20 IP and its why IEEE had the good sense to throw-out AIS in 802.1ag for= =20 Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I= =20 suspect any operator planning to use Ethernet equipment would always lo= ok to=20 IEEE stds and not ITU ones). AIS/FDI and the co-ps mode is debatabl= e. As I=20 noted above, on balance we considered not a good idea for PBB-TE OAM be= cause=20 it requires a conscious effort to generate it (unlike the co-cs mode) s= o=20 there are likely to be scaling problems and its one more thing to go=20 wrong. You should also have seen me make the = point many times=20 in the past that the always-on defect detection/handling OAM needs to b= e as=20 simple/sparse as possible with as little config as possible because we = need=20 super reliability......TCM goes completely against the grain here. = ;=20 Also note that the OAM required for each of the 3 network modes is not = the=20 same, despite what some claim. regards, Neil From: mpls-tp-bounces@ietf.org [mailto= :mpls-tp-boun= ces@ietf.org] On Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org = Subject: Re: [mpls-tp]=20 Associated bidirectional transport path requirements Deborah: &n= bsp;maybe what you said=20 is right. but I can't completely agree your opinions. IMO. mpls-t= p is=20 regard as transport network like SDH/SONET. so it should have AIS/FDI= =20 fuctions as SDH/SONET. do you=20 think so. best re= gards=20 liu I agree with Neil, it is very questionabl= e the value of AIS/FDI=20 in a packet network- any mode. It can result in a DoS attack by an= =20 operator on themselves so even Y1731 recommends not to block data= =20 frames: "A MEP can decide whether it blocks data frames when = it detects=20 dAIS. The principle requirement that influences this decision i= s=20 that data frames ought to be forwarded as much as possible,=20 without the possibility of forwarding wrong data frames=20 downstream." Table I.7-2 shows for AIS, not to block. = And as=20 Y1731 states, AIS can only be used under very constrained architec= tures=20 - if required for MPLS-TP, it needs to have the same guidance as i= n=20 Y1731, i.e. point-to-point and server/client one-to-one: "for= a=20 point-to-point ETH connection, a MEP has only a single peer=20 MEP. Therefore, there is no ambiguity regarding the peer MEP fo= r=20 which it should suppress alarms when it receives the ETH-AIS=20 information." So should only be within one domain - then no= =20 need. Deborah -----Original Message----- From: mpls-tp-bounces@ie= tf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.comCc: mpls-tp@ietf.or= g Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil, >= but=20 AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is inde= ed a=20 requirement and a necessity. And you will not be able to unders= tand=20 that as long as you refuse to accept that "cl-mode" is a= forwarding=20 mode within a **transport entity**. G.800 amendment 1=20 has finally reintroduced this transport entity into G.800. Besi= des=20 that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is= a=20 transport entity that transfers information belonging to multiple= =20 communications between ports across a subnetwork. <..> In a= =20 differentiated connection message contents are interpreted to= =20 identify (sets of) communications which receive different treat= ment.=20 The sets of communications may be distinguished by the forwa= rding=20 identifier or other layer information. Order is=20 not necessarily preserved between messages belonging to sets of= =20 communications receiving different treatment. Sets of=20 communications may be identified for purposes such as traffic= =20 conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 "di= fferentiated=20 connections". Ethernet AIS provides AIS within the scope o= f such=20 "differentiated connection". If you apply this to my = proposed PTN=20 layer stack, then the EVC layer topology will consists of EVC l= inks=20 supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails insi= de=20 metro and core domains interconnecting EVC matrices. When one o= f=20 those EVC links is interrupted, e.g. in the core between metro=20 1 and metro 4 (see attached slide), then the EVC differentiated= =20 connection that is present on this link will be interrupted. At= the=20 EVC switch/bridge node in metro 4 this interruption is noticed = and=20 EVC-AIS is inserted in the downstream direction to suppress the EV= C-LOC=20 alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Eth= ernet=20 AIS) frame has a reserved multicast address, which guarantees that= the=20 AIS is broadcast to the endpoints of the EVC. I believe that i= t is=20 time for you to adapt your view on co and cl modes and relate i= t to=20 the forwarding mode **INSIDE** a transport entity. What we kn= ow as=20 the internet is essentially an "IP differentiated connection&= quot; with a=20 billion or more ports. What we know as an IP VPN is essentially an= "IP=20 differentiated connection" with e.g. n ports (n in the ran= ge of e.g.=20 2 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n = in the range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially a= n=20 "MPLS differentiated connection" with 2 ports. What w= e know as a p2p=20 SDH VC-n is a "SDH VC-n connection" with 2 ports. Tr= ansport network=20 OAM applies to transport entities, which are (in terms of G.800= am1)=20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrij= dag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainsh= tein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org<= /a> Subject: RE: [mpls-tp] Associated=20 bidirectional transport path requirements John, Thank= s=20 this is a great platform to explain why OAM for the 3 network m= odes=20 needs to be different. I am getting a wee bit tired of=20 folks trying to make all 3 network modes look alike (and then, = even=20 worse, interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I am= even=20 more frustrated by the fact those peddling this FUD only ever seem= to=20 consider OAM and forget all other DP/CP/MP components (esp=20 top-of-stack message/file/stream application adaptations). H= ow=20 wrong can this get! In the co modes a *connection* is a very= =20 specific and *constraining* construct.....I am assuming here we re= spect=20 the rules of a connection (ie single source) though some folks = don't=20 even bother to respect this, and this is despite the fact that = we=20 all know what problems multiple-source constructs can cause (from= =20 LDP/PHP....ergo MPLS-TP). When we have a connection this restr= icts=20 *all* DP (ie traffic and OAM) to stay within the bounds of the= =20 connection. Which is fine under defect-free conditions, b= ut if=20 we have leaking traffic then the constraining nature of the=20 connection construct is broken. In a nutshell what this means= =20 is that OAM that is of a request/response nature cannot be trus= ted=20 in co mode networks under misconnectivity defects.....indeed, why= =20 should a leaking DP have a symmetric go/return defect=20 behaviour?....very likely it won't. So whilst request/respo= nse OAM=20 is right for the cl mode it is not right for the co mode under= =20 misconnectivity defect conditions. More generally the 3 modes = are=20 different and not just in OAM requirements....but AIS/FDI in the c= l=20 mode?...do me a favour!...at least IEEE had the good sense to bin = this=20 for Ethernet even though it remains in Y.1731. And which = is=20 why I often trot-out the rather silly (to have to say this)=20 observation that if IP (cl mode) could do it all then why=20 have IETF found it necessary to create MPLS (co-ps) and GMPLS (= CP=20 for co-cs). The answer lies in the physics...and G.800 attem= pts=20 to explain that physics....G.805 does not. So, the 3 modes = are=20 different...please accept/rejoice in this fact as they all offe= r=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the OAM of = the 3=20 modes the same. regards, Neil > -----Original= =20 Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.or= g] On Behalf Of Drake, John=20 E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander= =20 Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp= ]=20 Associated bidirectional transport path > requirements >= =20 > Italo, > > As described in the MPLS TP OAM=20 Requirements I-D, virtually all of the > OAM functions requ= ire a=20 return path, and in the absence of a return > path they are=20 disabled. > > As described in David Sinicrope's meet= ing=20 minutes > (http://wiki.tools.ietf.org/misc/mp= ls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP=20 addressing is used, an > MPLS TP network needs to be capable o= f=20 getting IP packets from > destination to source; neither the= =20 minutes nor I stipulate that a > control plane needs to be use= d to=20 instantiate this forwarding. > > As an aside, the issue = of=20 return path for unidirectional LSPs could be > charaterized= as=20 the elephant in the room. In the MPLS TP OAM > Framework= I-D,=20 unicast LSPs are only mentioned three times and return > paths= not=20 at all. > > Thanks, > > John > >= =20 -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@al= catel-lucent.it] > > Sent: Friday,=20 April 17, 2009 1:59 AM > > To: Drake, John E; Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org >=20 > Subject: RE: [mpls-tp] Associated bidirectional transport path= =20 > > requirements > > > > John, > &= gt;=20 > > I might have missed the agreement of MPLS-TP being capa= ble=20 of > > sending replies to OAM requests sent on uni-directio= nal=20 LSPs. > > > > This requirement does not belong to = the=20 first set of requirements > > ITU-T is expecting to be met = by=20 October. > > > > However, I think this in a potent= ial=20 interesting additional > > requirement to be taken into acc= ount=20 (at worst in a > subsequent phase). > > > > = I=20 think that this requirement needs to be evaluated versus other &g= t;=20 > more important requirements (e.g. the possibility to work w/o IP= =20 > > forwarding and the need for OAM to continue to monitor = the=20 data > > plane also in case of failures affecting the contr= ol or=20 management > > plane). > > > > I am open= to=20 discuss it but not sure this is the right time because > > = I=20 wish to avoid delaying the first phase of the design solution. >= ;=20 > > > Thanks, Italo > > > > >=20 -----Original Message----- > > > From: mpls-tp-bounces@ietf.org> > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > > > Sent: Thursday, April 16, 2009 8:00 PM > &g= t;=20 > To: Alexander Vainshtein; Maarten Vissers > > > Cc: = mpls-tp@ietf.org<= br>>=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport p= ath=20 > > > requirements > > > > > > = At=20 the meeting last fall at Juniper in Massachusetts, I > > thi= nk it=20 was > > > agreed that an MPLS TP network needs to have a= =20 forwarding > > capability > > > for management,= =20 control, and OAM packets (e.g., sending > > replies to=20 OAM > > > requests sent on uni-directional LSPs) even if = it=20 does not > > have an IP > > > forwarding data=20 plane. > > > > > > > -----Original=20 Message----- > > > > From: Alexander Vainshtein >= ;=20 > > [mailto:Alexander.Vainshtein@ecitele.com] > > > = >=20 Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maa= rten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re= :=20 [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > >=20 Maarten, > > > > It seems that you've just (implic= itly and,=20 probably, > > > > inadvertently) stated the=20 following: > > > > > > > > &nbs= p;=20 MPLS-TP OAM will not = ever=20 support MIP loopback function > > (and fault > > &g= t;=20 > localization which requires this function ) for > >=20 unidirectional P2MP > > > > and P2P paths. > >= ;=20 > > > > > > If this statement is correct, this = (IMHO=20 and FWIW) > raises a valid > > > > question: = >=20 > > > > > > > &n= bsp;=20 Is MPLS-TP an appropriate solution for=20 these > types of transport > > > > paths? >= ;=20 > > > > > > > For the reference, IP/MPLS pro= vides=20 this kind of > > functionality today > > > > = for=20 (unidirectional - but it does not know any other > > type) P= 2P=20 LSPs > > > > as described in RFC 4379. And its extensi= on to=20 P2MP LSPs seems > > > > easy... > > > >= ;=20 > > > > > > > > > > &= gt;=20 > Regards, > > > > > > > > &= nbsp;=20 Sasha > > > > > > > > > &= gt;=20 > > > > > >=20 ________________________________________ > > > > From:= mpls-tp-boun= ces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf >=20 > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > = > > Sent:=20 Thursday, April 16, 2009 3:24 PM > > > > To: 'Adri= an=20 Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject= : Re:=20 [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > >=20 Adrian, > > > > > > > > >>=20 <quote> > > > > >> The= =20 intermediate nodes (including MEPs, MIPs and > > > > o= ther=20 internal > > > > >> functio= ns as=20 appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> path a= t=20 each (sub-)layer MUST be aware of the pairing > > > >= =20 >> relationship of the forward and the=20 backward > > > > directions of that > > > = >=20 >> transport path. > > > >= =20 >> <end quote> > > > > > > > &= gt;=20 > > There is no way this is a functional requirement. That &= gt;=20 > > is, there is > > > > > *nothing* that can= be=20 observed from a black box point of > > > view that >= ;=20 > > > > results from adhering to this requirement. >= ;=20 > > > > > > > Your understanding is not corr= ect.=20 It is very much > observable if > > > > this=20 requirement is met from a black box point of view. > > > = >=20 The MIP functions can only perform the Loopback when there is a &= gt;=20 > > > co-routed bidirectional transport path. The MPLS-TP LB= M=20 packet > > > > received at a MIP needs to be returned= (as=20 LBR > > > > packet) to the originating MEP function vi= a the=20 other > > direction of > > > > the co-routed= =20 bidirectional transport path. This other > direction > &g= t;=20 > > would not be available in an associated bidirectional trans= port=20 > > > > path... and thus the loopback test > &g= t;=20 > would fail. > > > > > > > > Simil= arly,=20 when we have to apply TCM MEPs to monitor a > > segment,=20 then > > > > this is possible in a co-routed bidir=20 transport path > but not in a > > > > associated= =20 bidir transport path. In the first case the TCM MEP > > >= ;=20 > Source and Sink functions are co-located and can > exchang= e=20 what is > > > > called "remote information" = which is=20 necessary for performance > > > > monitoring. >= >=20 > > In the latter case the TCM MEP Source and Sink functions>=20 > are in e.g. > > > > different nodes in the netwo= rk=20 and TCM would not be able > > to provide > > > &= gt;=20 performance monitoring. > > > > > > > >= ;=20 > The entirety of the bracketted text "(including MEPs, &g= t; >=20 > MIPs and other > > > > internal > > >= >=20 > functions as appropriate)" should be deleted. It does not>=20 > > > add to "The > > > > > intermedi= ate=20 nodes." > > > > > > > > Your unde= rstanding=20 is not correct. This text must not be > > deleted at >= >=20 > > all. > > > > > > > > >=20 Actually, I am quite fed up about this persistent > > >= =20 insistence on the > > > > inclusion > > > = >=20 > of "Tandem Connection." The definition within the ITU-= T of >=20 > > > this term > > > > > is > > = >=20 > poorly > > > > > specified and comes from the= =20 monitoring of a path that is > > > > parallel (i.e.>=20 > > > tandem) > > > > > to the data path b= eing=20 monitored. This definition of TC > > > > seems to be= =20 at > > > > variance, > > > > > and w= ould=20 be if the ACH was actually in band. > > > > > &= gt;=20 > > I don't understand where your interpretation of tandem<= br>>=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of a = > >=20 > > path that is parallel (i.e. tandem) to the data path being= =20 > > > > monitored."? > > > > = > >=20 > > There is a "network connection" and this network<= br>> >=20 connection is a set > > > > of interconnected "li= nk=20 connections" and "matrix > connections". A &g= t; > > >=20 subset of those interconnected link connections and matrix > &= gt;=20 > > connections can be monitored and is then referred to as = >=20 a "tandem > > > > connection". There is no &= quot;path that is=20 parallel to the > > data path". > > > >= There is=20 only additional OAM inserted inside the data > path by the &= gt;=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM MEP_Sk= =20 function. > > > > > > > > Regards, = >=20 > > > Maarten > > > > > > > >= =20 > > > > -----Original Message----- > > > = >=20 From: m= pls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian=20 Farrel > > > > Sent: donderdag 16 april 2009 11:59 = >=20 > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com> > > > Cc:=20 BUSI ITALO; mpl= s-tp@ietf.org > > > > Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > Unfortunat= ely I=20 cannot fully agree with your statement: > > > >=20 > > > > > > <quote> > > > >= >=20 From the point of view of hardware, co-routed > &= gt;=20 > bidirectional LSPs > > > > > are= a=20 special case of associated bidirectional LSPs. > > > >= >=20 <end quote> > > > > > > > > > = >=20 This statement would be obviously correct, were it not for > &g= t;=20 > > Requirement > > > > > 34 in the latest MP= LS-TP=20 requirements draft > > > > > > > > OK.= Got=20 it. > > > > > > > > But what is this d= oing=20 in the data plane requirements section? > > > > &g= t;=20 > > > In fact, what is this requirement actually saying? = >=20 > > > > > > > > <quote> > >= ;=20 > > > The intermediate nodes (including = MEPs,=20 MIPs and > > > other internal > > > > >= =20 functions as appropriate) of a co-routed >= >=20 > > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the=20 pairing > > > > > relationship= of=20 the forward and the backward > > > > directions of=20 that > > > > > transport=20 path. > > > > > <end quote> > > >= >=20 > > > > There is no way this is a functional requirem= ent.=20 That > > is, there is > > > > *nothing* that = can=20 be observed from a black box point of > > view that > = >=20 > > results from adhering to this requirement. > > >= ;=20 > > > > > Therefore it could be assumed that this= =20 requirement is met by > > > > configuring some data p= lane=20 database component through the > > > > management pla= ne.=20 The database component is not used > for anything > > = >=20 > except to satisfy this requirement for "awareness".> > >=20 > > > > > Ben! Can we please try to rewrite this= =20 requirement in terms of > > > > behavior? > >= ;=20 > > > > > > > Please note that Requirement 3= 4 is=20 the ONLY item in the > > > > list that is > >= >=20 > > specific for co-routed bidirectional LSPs. (The pairing = >=20 > > > requirements > > > > > at end points= for=20 co-routed and associated bidirectional > > > paths are>=20 > > > > exactly the same even if they appear in two=20 different > > > items in the > > > > >= =20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > >= >=20 bidirectional paths would be void of any data plane content. > = >=20 > > > > > > > > The somewhat vague scope o= f=20 this requirement ("other internal > > > > > f= unctions=20 as appropriate") creates a suspicion that HW > > > &= gt;=20 support of the > > > > > pairing awareness may be= =20 required in order to comply with it. > > > > > = >=20 > > The entirety of the bracketted text "(including MEPs,<= br>>=20 > MIPs and other > > > > internal functions as=20 appropriate)" should be deleted. It > > does not >= ; >=20 > > add to "The intermediate nodes." > > >= ; > >=20 > > > > The following text in the draft increases this=20 suspicion: > > > > > > > > > >=20 <quote> > > > > > Tandem Connection: A= =20 tandem connection is an > > arbitrary part of a > >= >=20 > > transport path that can be monitored (via OAM) &g= t;=20 > > > independently from the > > > > > &nb= sp;=20 end-to-end monitoring (OAM). It may be a monitored > >= =20 segment or a > > > > > monitored concatenate= d=20 segment of a transport path. > > The tandem > &= gt;=20 > > > connection may also include the forwarding engi= ne(s)=20 of > > > > the node(s) > > > > > &nb= sp;=20 at the edge(s) of the segment or concatenated segment. > > &= gt;=20 > > <end quote> > > > > > > >= >=20 Actually, I am quite fed up about this persistent > > insist= ence=20 on the > > > > inclusion of "Tandem Connection.&q= uot; The=20 definition within > > the ITU-T of > > > > th= is=20 term is poorly specified and comes from the > monitoring of=20 a > > > > path that is parallel (i.e. tandem) to the d= ata=20 path being > > > > monitored. This definition of TC s= eems=20 to be at variance, > > and would > > > > be i= f the=20 ACH was actually in band. > > > > > > > &= gt;=20 > Doesn't "forwarding engine" sound like hardware to= you? > >=20 > > > > > > Yes, but so what? > > >= >=20 > > > > > IMHO it is worth noting that neither the= =20 MPLS-TP > > > Requirements draft > > > > &= gt;=20 nor the MPLS-TP OAM requirements one > > > > > = >=20 > > > > > > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-re= quiremen >=20 > > > > ts-01.txt) contain any requirements dealing with= =20 tandem > > > connections. > > > > > = >=20 > > > > But tandem connections are discussed in the MPLS-= TP=20 OAM > > Framework > > > > > draft > = >=20 > > (http://www.ietf.org/internet-drafts/draft= -ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > > = >=20 > > > > > Right. > > > > Let's = just get=20 rid of an unnecessary term and bring all > the I-Ds > >= ;=20 > > into line. > > > > > > > > &= gt;=20 The bottom line, IMHO, is that some clarity regarding > > &g= t;=20 co-routed vs. > > > > > associated > > >= ;=20 > > bidirectional paths is still required. One way to=20 provide > > > > that could > > > > >= be=20 by explicitly limiting Requirement 34 to specific > > >= =20 functionality. > > > > > > > >=20 Agreed. > > > > > > > > Adrian >= >=20 > > > > > > > > > > > &g= t;=20 > > > > > >=20 ________________________________________ > > > > From:= =20 Adrian Farrel [adrian@olddog.co.uk] > > > > Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: Alexande= r=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org >= =20 > > > Subject: Re: [mpls-tp] Associated bidirectional transp= ort=20 path > > > > requirements > > > > = >=20 > > > Hi Sasha, > > > > > > > &g= t;=20 Not really sure whether you are misrepresenting anyone, but... >= ;=20 > > > > > > > > 1. My reading of on= e of=20 Ben's messages is that associated > > > > &= gt;=20 bidirectional paths are the only types of paths that can be > &= gt;=20 > > created in > > > > > the existing network= s;=20 "true" co-routed bidirectional paths > > > >= will=20 have > > > > > to wait until (if ever) new equipmen= t=20 becomes available. > > > > > > > > Thi= s is=20 clearly nonsense! > > > > From the point of view of=20 hardware, co-routed > > bidirectional LSPs are > > = >=20 > a special case of associated bidirectional LSPs. > > &g= t;=20 > > > > > If you can set up two unidirectional LSP= s=20 (e.g. using the > > management > > > > plane)= you=20 can surely set up a co-routed > > > bidirectional LSP.>=20 > > > > > > > There are shipping solutions t= hat=20 achieve co-routed > bidirectional > > > > LSPs u= sing=20 the control plane. These either use the GMPLS > > (which=20 is > > > > cleaner) or non-standard proprietary soluti= ons=20 (which is > > messy but > > > >=20 functional). > > > > > > > > But (of= =20 course) the management plane or control plane > > solutions= =20 have > > > > nothing to do with availability of equipm= ent=20 as they > are software > > > > solutions. >= ;=20 > > > > > > &g= t; >=20 2. My reading of one of Neil's messages is that the actual >= ; >=20 > > driver for > > > > > co-routed bidirectio= nal=20 paths may be experience with existing > > > > >=20 transport networks rather than any specific benefit. > > >= ;=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a bad= =20 thing. > > > > > > > > A large driver = for=20 MPLS-TP is to give the packet network > > the look, > = >=20 > > feel, and behavioral characteristics of a "legacy"= ; > >=20 > > transport network. > > > > > > >= ;=20 > > Based on these observations, I'd guess (FWIW) that: = > >=20 > > > * associated bidirectional paths are, at least for the= =20 time > > > > > being, the most importa= nt=20 type of bidirectional paths in > > > > > =20 MPLS-TP > > > > > > > > I think = that=20 is wrong both given my statement above, and > > given=20 that > > > > other upgrades to existing MPLS solutions= will=20 be > needed to reach > > > > the full function l= evel=20 of MPLS-TP. > > > > > > > > > * the= y had=20 a good chance to remain the only type of > >=20 bidirectional > > > > > paths in real= =20 deployments. > > > > > > > > I don'= ;t see=20 what that follows from. > > > > > > > >= ;=20 Cheers, > > > > Adrian > > > > >= >=20 > > _______________________________________________ > >= ;=20 > > mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp = >=20 > > > > > > >=20 _______________________________________________ > > > >= ;=20 mpls-tp mailing list > > > > mpls-tp@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls-tp = >=20 > > > > > > > > > >=20 _______________________________________________ > > > mpl= s-tp=20 mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.or= g/mailman/listinfo/mpls-tp >=20 > > > > >=20 _______________________________________________ > mpls-tp maili= ng=20 list > mp= ls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailin= g=20 list mpls-tp= @ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information&n= bsp;contained in this mail is solely property= of the sender's organization. This mail&= nbsp;communication is confidential. Recipients named&nb= sp;above are obligated to maintain secrecy an= d are not permitted to disclose the cont= ents of this communication to others. This email and any files transmitted with&nbs= p;it are confidential and intended solely for= the use of the individual or entity&nbs= p;to whom they are addressed. If you hav= e received this email in error please no= tify the originator of the message. Any = views expressed in this message are those&nbs= p;of the individual sender. This message has been scanned for viruses&nbs= p;and Spam by ZTE Anti-Spam system. __________________________________= _____________ mpls-tp=20 mailing list m= pls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --00163642702bce6fd704682dc35a-- From liu.guoman@zte.com.cn Wed Apr 22 18:09:36 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E433A6D28 for ; Wed, 22 Apr 2009 18:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.705 X-Spam-Level: X-Spam-Status: No, score=-95.705 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIDpy0XlcvpB for ; Wed, 22 Apr 2009 18:09:35 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 8AE333A6DF7 for ; Wed, 22 Apr 2009 18:09:33 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 9110764009499; Thu, 23 Apr 2009 09:03:22 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 90033.2238491106; Thu, 23 Apr 2009 09:07:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3N1AlXv050230; Thu, 23 Apr 2009 09:10:47 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <200904222050402508137@fiberhome.com.cn> To: xqwei@fiberhome.com.cn MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Thu, 23 Apr 2009 09:08:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-23 09:10:45, Serialize complete at 2009-04-23 09:10:45 Content-Type: multipart/alternative; boundary="=_alternative 00067901482575A1_=" X-MAIL: mse1.zte.com.cn n3N1AlXv050230 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectionaltransport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 01:09:36 -0000 This is a multipart message in MIME format. --=_alternative 00067901482575A1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 eHVhbnFpbqO6DQogIEkga25vdyB3ZSBhcmUgZGlzY3Vzc2luZyByZXF1aXJlbWVudHMgb2YgVENN LiBidXQgdGhlcmUgbWF5YmUgYWxsIGtpbmRzIA0Kb2YgbWV0aG9kcyB0byByZWFsaXplIHNlZ21l bnQgbW9uaXRvcmluZyBleGNlcHQgbmVzdGVkIExTUCAuIHdoeSB3ZSBtdXN0IA0Kb25seSBzZWxl Y3QgdGhlIG1ldGhvZCBvZiBuZXN0ZWQgTFNQPyANCiBzbyBub3cgaXQgaXMga2V5IHByb2JsZW0g dG8gd2hldGhlciB0byBuZWVkIHRoZSByZXF1aXJlbWVudCBvZiBUQ00gDQpmdW5jdGlvbnMuIG5v dCBkaXNjdXNzaW5nIHRoZSBtZXRob2Qgb2YgcmVhbGl6aW5nIHRoZSBUQ00gZnVuY3Rpb25zLiAN CmRvIHlvdSB1bmRlcnN0YW5kIG1lLg0KDQpiZXN0IHJlZ2FyZHMNCmxpdQ0KDQoNCg0KIlh1ZXFp biBXRUkgKFNodWV0c2luZyBXRUkpIiA8eHF3ZWlAZmliZXJob21lLmNvbS5jbj4gDQoyMDA5LTA0 LTIyIDIwOjUwDQrH67TwuLQguPgNCnhxd2VpQGZpYmVyaG9tZS5jb20uY24NCg0KDQrK1bz+yMsN CiJsaXUuZ3VvbWFuIiA8bGl1Lmd1b21hbkB6dGUuY29tLmNuPg0Ks63LzQ0KIk1QTFMtVFAiIDxt cGxzLXRwQGlldGYub3JnPg0K1vfM4g0KUmU6IFJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rp b25zIGluIE1QTFMtVFAgKHdhcyANClJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsdHJhbnNwb3J0 IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQoNCg0KDQoNCg0KR3VvbWFuOg0KDQpDb3JyZWN0OiB3ZSBh cmUgZGlzY3Vzc2luZyByZXF1aXJlbWVudHMgb2Ygc2VnbWVudCBtb25pdG9yaW5nIG9mIGFuIEVu ZCB0byANCkVuZCBMU1AuDQoNClNpbmNlcmVseSBZb3Vycw0KWHVlcWluIFdlaSAoU2h1ZXRzaW5n IFdlaSkNCg0KRGV2ZWxvcG1lbnQgJiBQbGFubmluZyBEZXBhcnRtZW50LA0KRmliZXJob21lIFRl bGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ2llcyBDby4sTHRkLiwNCk5vLjg4IFlvdWtleXVhbiBS b2FkLEhvbmdzaGFuIERpc3QuLFd1aGFuLEh1YmVpLFAuUi5DaGluYSw0MzAwNzQNClRlbDogICAg Kzg2IDI3IDg3NjkxMzEwDQpGYXg6ICAgICs4NiAyNyA4NzY5NDM2Mg0KRW1haWw6ICB4cXdlaUBm aWJlcmhvbWUuY29tLmNuDQoyMDA5LTA0LTIyICAyMDo0NzozOA0KDQo9PT09PT09PT09PT09PT09 PT09PSBGb2xsb3dpbmcgaXMgeW91ciBlbWFpbD09PT09PT09PT09PT09PT09PT09PQ0KU3ViamVj dDpSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgDQpSRTpB c3NvY2lhdGVkYmlkaXJlY3Rpb25hbHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNClNlbnSj ujIwMDktMDQtMjIgMTc6MDI6MTMNCkZyb206bGl1Lmd1b21hbg0KVG86eHF3ZWkNCkNDIHRvOm1w bHMtdHANCg0KPkkgc3VwcG9ydCBodWFuZmVuZydzIG9waW5pb25zLCBoZXJlIHdlIG9ubHkgZGlz c2N1c3MgdGhlIHJlcXVpcmVtZW50cyBvZiANCj5UQ00uIGhvdyB0byByZWFsaXplIHRoZSBmdW5j dGlvbnMgb2YgVENNIHdpbGwgYmUgZGlzc2N1c3NlZCBpbiB0aGUgDQpmdXR1cmUuIA0KPkkgd2lz aCB0aGF0IHh1ZXFpbiBjb25zaWRlciBpdCB2ZXJ5IHdlbGwuDQo+DQo+dGhhbmsgeW91DQo+bGl1 DQo+DQo+DQo+DQo+Ilh1ZXFpbiBXRUkgKFNodWV0c2luZyBXRUkpIiA8eHF3ZWlAZmliZXJob21l LmNvbS5jbj4gDQo+t6K8/sjLOiAgbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQo+MjAwOS0wNC0y MiAxNjoyMg0KPsfrtPC4tCC4+A0KPnhxd2VpQGZpYmVyaG9tZS5jb20uY24NCj4NCj4NCj7K1bz+ yMsNCj4iSFVBTkcgRmVuZyBGIiA8RmVuZy5mLkh1YW5nQGFsY2F0ZWwtc2JlbGwuY29tLmNuPg0K PrOty80NCj5NUExTLVRQIDxtcGxzLXRwQGlldGYub3JnPg0KPtb3zOINCj5SZTogW21wbHMtdHBd IFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgDQo+UkU6QXNzb2NpYXRlZGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KPg0KPg0KPg0KPg0KPg0KPg0K PkZlbmc6DQo+DQo+VGhlIGZ1bmN0aW9uIG9mIFRDTSBjYW4gYmUgcHJvdmlkZWQgYnkgbmVzdGVk IExTUCAoV2hpY2ggaXMgdGhlIGJhc2ljIA0KPmZ1bmN0aW9uIG9mIE1QTFMtVFApLCB3ZSBuZWVk bid0IHRvIGRlZmluZSBUQ00uDQo+DQo+DQo+U2luY2VyZWx5IFlvdXJzDQo+WHVlcWluIFdlaSAo U2h1ZXRzaW5nIFdlaSkNCj4yMDA5LTA0LTIyICAxNjoyMDoxMA0KPg0KPj09PT09PT09PT09PT09 PT09PT09IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09PT09PT09PT09PT09DQo+U3Vi amVjdDpSRTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgDQo+ UkU6QXNzb2NpYXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0K PlNlbnSjujIwMDktMDQtMjAgMjE6NTg6MTgNCj5Gcm9tOkhVQU5HIEZlbmcgRg0KPlRvOnhxd2Vp QGZpYmVyaG9tZS5jb20uY247IEJlbiBOaXZlbi1KZW5raW5zOyBCdXNpIEl0YWxvDQo+Q0MgdG86 TVBMUy1UUA0KPg0KPj5EZWFyIFh1ZXFpbiwNCj4+ICAgICBXZSBhcmUgZGlzY3Vzc2luZyByZXF1 aXJlbWVudCBvZiBUQ00sIG5vdCBmb3IgIGZ1bmN0aW9uIGFuZCBtZXRob2QgDQo+aW4gZGV0YWls cy4NCj4+Qi5SLg0KPj5GZW5nIA0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ RnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGll dGYub3JnXSBPbiANCj5CZWhhbGYgT2YgWHVlcWluIFdFSSAoU2h1ZXRzaW5nIFdFSSkNCj4+U2Vu dDogMjAwOcTqNNTCMTjI1SAxNDo1Mg0KPj5UbzogQmVuIE5pdmVuLUplbmtpbnMNCj4+Q2M6IE1Q TFMtVFANCj4+U3ViamVjdDogUmU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBM Uy1UUCAod2FzIA0KPlJFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJl cXVpcmVtZW50cykNCj4+DQo+PlN1cHBvcnQsIEkgdGhpbmsgdGhlIG5lc3RlZCBMU1Agd2lsbCBi ZSBncmVhdCEgVW50aWwgbm93LCBJIGRpZG4ndCBzZWUgDQo+YW55IGRpZmZlcmVuY2UgYmV0d2Vl biB0aGUgbmVzdGVkIExTUCBhbmQgVENNIG9uIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcuIA0KPkJ1 dCB0aGUgbmVzdGVkIExTUCB3aWxsIG1ha2UgdGhlIHRoaW5ncyBtb3JlIGVhc3kuIEkgd291bGQg bGlrZSBzZWxlY3QgYSANCj5zaW1wbGUgd2F5IHRvIHJlc29sdmUgdGhlIHByb2JsZW0uDQo+Pg0K Pj5TaW5jZXJlbHkgWW91cnMNCj4+WHVlcWluIFdlaSAoU2h1ZXRzaW5nIFdlaSkNCj4+DQo+PkZp YmVyaG9tZSBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2dpZXMgQ28uLEx0ZC4sDQo+PjIwMDkt MDQtMTggIDE0OjQ4OjUxDQo+Pg0KPj49PT09PT09PT09PT09PT09PT09PSBGb2xsb3dpbmcgaXMg eW91ciBlbWFpbD09PT09PT09PT09PT09PT09PT09PQ0KPj5TdWJqZWN0OlJlOiBbbXBscy10cF0g VGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyBSRTogDQo+QXNzb2NpYXRlZGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KPj5TZW50o7oyMDA5LTA0LTE3 IDE3OjE3OjMxDQo+PkZyb206QmVuIE5pdmVuLUplbmtpbnMNCj4+VG86QlVTSSBJVEFMTzsgQWRy aWFuIEZhcnJlbDsgQWxleGFuZGVyIFZhaW5zaHRlaW4gQ0MgdG86bXBscy10cA0KPj4NCj4+Pkl0 YWxvLA0KPj4+DQo+Pj5PbiAxNy8wNC8yMDA5IDA5OjM0LCAiQlVTSSBJVEFMTyIgPEl0YWxvLkJ1 c2lAYWxjYXRlbC1sdWNlbnQuaXQ+IHdyb3RlOg0KPj4+PiBUaGUgSldUIGFncmVlbWVudCBpcyB0 byBicmluZyB0aGUgSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBpbiANCj4+Pj4gSUVURiB0 byBleHRlbmQgdGhlIE1QTFMgYXJjaGl0ZWN0dXJlIHRvIG1lZXQgdGhlbSBpbiBhIHdheSB0aGF0 IGlzIA0KPj4+PiBjb21wYXRpYmxlLCBjb25zaXN0ZW50IGFuZCBjb2hlcmVudCB3aXRoIGV4aXN0 aW5nIElFVEYgYXJjaGl0ZWN0dXJlLg0KPj4+DQo+Pj5TbyBJIHRvb2sgYSBsb29rIGF0IHRoZSBK V1QgcmVwb3J0LiBJdCBzYXlzIChzbGlkZSAxNikNCj4+Pg0KPj4+IiBTZXJ2aWNlIFByb3ZpZGVy cyB3YW50IExTUHMvUFdFcyB0byBiZSBhYmxlIHRvIGJlIG1hbmFnZWQgYXQgdGhlIA0KPj4+ZGlm ZmVyZW50IG5lc3RlZCBsZXZlbHMgc2VhbWxlc3NseSAocGF0aCwgc2VnbWVudCwgbXVsdGlwbGUg c2VnbWVudHMpDQo+Pj4gICAgYWthIFRhbmRlbSBDb25uZWN0aW9uIE1vbml0b3JpbmcgKFRDTSks IHRoaXMgaXMgdXNlZCBmb3IgZXhhbXBsZSANCj4+PndoZW4gYSBMU1AvUFdFIGNyb3NzZXMgbXVs dGlwbGUgYWRtaW5pc3RyYXRpb25zIg0KPj4+DQo+Pj5JTU8gdGhlIHJlcXVpcmVtZW50IGlzIHRv IGJlIGFibGUgdG8gbW9uaXRvciBwYXJ0cyBvZiBhIHBhdGggYXMgd2VsbCBhcyANCg0KPj4+dGhl IGVuZCB0byBlbmQgcGF0aC4gVGhlcmUgYXJlIG1hbnkgd2F5cyB0byBzb2x2ZSB0aGF0IHJlcXVp cmVtZW50LCBvbmUgDQoNCj4+Pm9mIHdoaWNoIGlzIHRoZSBjcmVhdGlvbiBvZiBuZXN0ZWQgTFNQ cywgb25lIHBlciBsZXZlbCBvZiBtb25pdG9yaW5nIA0KPj4+cmVxdWlyZWQgKG15IHVuZGVyc3Rh bmRpbmcgb2YgaG93IFRDTSB3b3JrcykuDQo+Pj4NCj4+PkkgdGhpbmsgdGhlIHJlYWwgZGlzY3Vz c2lvbiBpcyB0aGVyZWZvcmUgaXMgdGhlIHJlcXVpcmVtZW50IHRvIG1vbml0b3IgDQo+Pj5kaWZm ZXJlbnQgY29tcG9uZW50cyBvZiBhbiBlbmQgdG8gZW5kIHBhdGggb3IgaXMgdGhlIHJlcXVpcmVt ZW50IHRoYXQgDQo+Pj5zdWNoIG1vbml0b3JpbmcgTVVTVCBiZSBhY2hpZXZlZCB1c2luZyBuZXN0 ZWQgTFNQcz8NCj4+Pg0KPj4+QXMgYW4gZXhhbXBsZSBQVyB0ZWNobm9sb2d5IHRvZGF5IGFsbG93 cyBlbmQgdG8gZW5kIGFuZCBwZXIgc2VnbWVudCANCj4+Pm1vbml0b3JpbmcgYnV0IGl0IGRvZXMg bm90IGFjaGlldmUgaXQgdXNpbmcgbmVzdGVkIFBXcyBvciBQVyBsZXZlbHMuDQo+Pj4NCj4+PkJl bg0KPj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+bXBscy10cCBtYWlsaW5nIGxpc3QNCj4+Pm1wbHMtdHBAaWV0Zi5vcmcNCj4+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPj4+DQo+Pg0KPj49PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj5tcGxzLXRwIG1haWxpbmcgbGlzdA0KPj5tcGxzLXRwQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPj4NCj4NCj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscy10cCBt YWlsaW5nIGxpc3QNCj5tcGxzLXRwQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwDQo+DQo+DQo+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5aVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCmlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbiANCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBh cmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgDQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVy cy4NCj5UaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCANCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCm9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSANCm9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj5UaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVt Lg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00067901482575A1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnh1YW5xaW6jujwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEkga25vdyB3ZSBhcmUgZGlz Y3Vzc2luZyByZXF1aXJlbWVudHMNCm9mIFRDTS4gYnV0IHRoZXJlIG1heWJlIGFsbCBraW5kcyBv ZiBtZXRob2RzIHRvIHJlYWxpemUgc2VnbWVudCBtb25pdG9yaW5nDQpleGNlcHQgbmVzdGVkIExT UCAuIHdoeSB3ZSBtdXN0IG9ubHkgc2VsZWN0IHRoZSBtZXRob2Qgb2YgbmVzdGVkIExTUD8gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDtzbyBub3cgaXQg aXMga2V5IHByb2JsZW0gdG8gd2hldGhlcg0KdG8gbmVlZCB0aGUgcmVxdWlyZW1lbnQgb2YgVENN IGZ1bmN0aW9ucy4gbm90IGRpc2N1c3NpbmcgdGhlIG1ldGhvZCBvZg0KcmVhbGl6aW5nIHRoZSBU Q00gZnVuY3Rpb25zLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PmRvIHlvdSB1bmRlcnN0YW5kIG1lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+YmVzdCByZWdhcmRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5saXU8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+JnF1b3Q7WHVlcWluIFdFSSAoU2h1ZXRzaW5nDQpXRUkpJnF1b3Q7ICZs dDt4cXdlaUBmaWJlcmhvbWUuY29tLmNuJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDQtMjIgMjA6NTA8L2ZvbnQ+DQo8dGFibGUgYm9yZGVy Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgYmdjb2xvcj13aGl0ZT4NCjxkaXYgYWxpZ249Y2VudGVy Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7H67TwuLQguPg8YnI+DQp4cXdlaUBmaWJl cmhvbWUuY29tLmNuPC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NzMlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bGl1Lmd1b21hbiZxdW90OyAm bHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7TVBM Uy1UUCZxdW90OyAmbHQ7bXBscy10cEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucw0KaW4gTVBMUy1UUCAod2FzIFJFOkFz c29jaWF0ZWRiaWRpcmVjdGlvbmFsdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+R3VvbWFu Ojxicj4NCjxicj4NCkNvcnJlY3Q6IHdlIGFyZSBkaXNjdXNzaW5nIHJlcXVpcmVtZW50cyBvZiBz ZWdtZW50IG1vbml0b3Jpbmcgb2YgYW4gRW5kDQp0byBFbmQgTFNQLjxicj4NCjxicj4NClNpbmNl cmVseSBZb3Vyczxicj4NClh1ZXFpbiBXZWkgKFNodWV0c2luZyBXZWkpPGJyPg0KPGJyPg0KRGV2 ZWxvcG1lbnQgJmFtcDsgUGxhbm5pbmcgRGVwYXJ0bWVudCw8YnI+DQpGaWJlcmhvbWUgVGVsZWNv bW11bmljYXRpb24gVGVjaG5vbG9naWVzIENvLixMdGQuLDxicj4NCk5vLjg4IFlvdWtleXVhbiBS b2FkLEhvbmdzaGFuIERpc3QuLFd1aGFuLEh1YmVpLFAuUi5DaGluYSw0MzAwNzQ8YnI+DQpUZWw6 ICZuYnNwOyAmbmJzcDsrODYgMjcgODc2OTEzMTA8YnI+DQpGYXg6ICZuYnNwOyAmbmJzcDsrODYg MjcgODc2OTQzNjI8YnI+DQpFbWFpbDogJm5ic3A7eHF3ZWlAZmliZXJob21lLmNvbS5jbjxicj4N CjIwMDktMDQtMjIgJm5ic3A7MjA6NDc6Mzg8YnI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09 PSBGb2xsb3dpbmcgaXMgeW91ciBlbWFpbD09PT09PT09PT09PT09PT09PT09PTxicj4NClN1Ympl Y3Q6UmU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOkFz c29jaWF0ZWRiaWRpcmVjdGlvbmFsdHJhbnNwb3J0DQpwYXRoIHJlcXVpcmVtZW50cyk8YnI+DQpT ZW50o7oyMDA5LTA0LTIyIDE3OjAyOjEzPGJyPg0KRnJvbTpsaXUuZ3VvbWFuPGJyPg0KVG86eHF3 ZWk8YnI+DQpDQyB0bzptcGxzLXRwPGJyPg0KPGJyPg0KJmd0O0kgc3VwcG9ydCBodWFuZmVuZydz IG9waW5pb25zLCBoZXJlIHdlIG9ubHkgZGlzc2N1c3MgdGhlIHJlcXVpcmVtZW50cw0Kb2YgPGJy Pg0KJmd0O1RDTS4gaG93IHRvIHJlYWxpemUgdGhlIGZ1bmN0aW9ucyBvZiBUQ00gd2lsbCBiZSBk aXNzY3Vzc2VkIGluIHRoZQ0KZnV0dXJlLiA8YnI+DQomZ3Q7SSB3aXNoIHRoYXQgeHVlcWluIGNv bnNpZGVyIGl0IHZlcnkgd2VsbC48YnI+DQomZ3Q7PGJyPg0KJmd0O3RoYW5rIHlvdTxicj4NCiZn dDtsaXU8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7JnF1b3Q7WHVlcWlu IFdFSSAoU2h1ZXRzaW5nIFdFSSkmcXVvdDsgJmx0O3hxd2VpQGZpYmVyaG9tZS5jb20uY24mZ3Q7 DQo8YnI+DQomZ3Q7t6K8/sjLOiAmbmJzcDttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQom Z3Q7MjAwOS0wNC0yMiAxNjoyMjxicj4NCiZndDvH67TwuLQguPg8YnI+DQomZ3Q7eHF3ZWlAZmli ZXJob21lLmNvbS5jbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O8rVvP7Iyzxicj4NCiZn dDsmcXVvdDtIVUFORyBGZW5nIEYmcXVvdDsgJmx0O0ZlbmcuZi5IdWFuZ0BhbGNhdGVsLXNiZWxs LmNvbS5jbiZndDs8YnI+DQomZ3Q7s63LzTxicj4NCiZndDtNUExTLVRQICZsdDttcGxzLXRwQGll dGYub3JnJmd0Ozxicj4NCiZndDvW98ziPGJyPg0KJmd0O1JlOiBbbXBscy10cF0gVGFuZGVtIENv bm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyA8YnI+DQomZ3Q7UkU6QXNzb2NpYXRlZGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtGZW5nOjxicj4N CiZndDs8YnI+DQomZ3Q7VGhlIGZ1bmN0aW9uIG9mIFRDTSBjYW4gYmUgcHJvdmlkZWQgYnkgbmVz dGVkIExTUCAoV2hpY2ggaXMgdGhlIGJhc2ljDQo8YnI+DQomZ3Q7ZnVuY3Rpb24gb2YgTVBMUy1U UCksIHdlIG5lZWRuJ3QgdG8gZGVmaW5lIFRDTS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDtTaW5jZXJlbHkgWW91cnM8YnI+DQomZ3Q7WHVlcWluIFdlaSAoU2h1ZXRzaW5nIFdlaSk8YnI+ DQomZ3Q7MjAwOS0wNC0yMiAmbmJzcDsxNjoyMDoxMDxicj4NCiZndDs8YnI+DQomZ3Q7PT09PT09 PT09PT09PT09PT09PT0gRm9sbG93aW5nIGlzIHlvdXIgZW1haWw9PT09PT09PT09PT09PT09PT09 PT08YnI+DQomZ3Q7U3ViamVjdDpSRTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBN UExTLVRQICh3YXMgPGJyPg0KJmd0O1JFOkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dCBwYXRoIHJlcXVpcmVtZW50cyk8YnI+DQomZ3Q7U2VudKO6MjAwOS0wNC0yMCAyMTo1ODoxODxi cj4NCiZndDtGcm9tOkhVQU5HIEZlbmcgRjxicj4NCiZndDtUbzp4cXdlaUBmaWJlcmhvbWUuY29t LmNuOyBCZW4gTml2ZW4tSmVua2luczsgQnVzaSBJdGFsbzxicj4NCiZndDtDQyB0bzpNUExTLVRQ PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7RGVhciBYdWVxaW4sPGJyPg0KJmd0OyZndDsgJm5ic3A7 ICZuYnNwOyBXZSBhcmUgZGlzY3Vzc2luZyByZXF1aXJlbWVudCBvZiBUQ00sIG5vdCBmb3IgJm5i c3A7ZnVuY3Rpb24NCmFuZCBtZXRob2QgPGJyPg0KJmd0O2luIGRldGFpbHMuPGJyPg0KJmd0OyZn dDtCLlIuPGJyPg0KJmd0OyZndDtGZW5nIDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDstLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7RnJvbTogbXBscy10cC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXQ0KT24gPGJyPg0KJmd0 O0JlaGFsZiBPZiBYdWVxaW4gV0VJIChTaHVldHNpbmcgV0VJKTxicj4NCiZndDsmZ3Q7U2VudDog MjAwOcTqNNTCMTjI1SAxNDo1Mjxicj4NCiZndDsmZ3Q7VG86IEJlbiBOaXZlbi1KZW5raW5zPGJy Pg0KJmd0OyZndDtDYzogTVBMUy1UUDxicj4NCiZndDsmZ3Q7U3ViamVjdDogUmU6IFttcGxzLXRw XSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIDxicj4NCiZndDtSRTpBc3NvY2lh dGVkYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0O1N1cHBvcnQsIEkgdGhpbmsgdGhlIG5lc3RlZCBMU1Agd2lsbCBiZSBn cmVhdCEgVW50aWwgbm93LCBJIGRpZG4ndA0Kc2VlIDxicj4NCiZndDthbnkgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoZSBuZXN0ZWQgTFNQIGFuZCBUQ00gb24gcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4N Cjxicj4NCiZndDtCdXQgdGhlIG5lc3RlZCBMU1Agd2lsbCBtYWtlIHRoZSB0aGluZ3MgbW9yZSBl YXN5LiBJIHdvdWxkIGxpa2Ugc2VsZWN0DQphIDxicj4NCiZndDtzaW1wbGUgd2F5IHRvIHJlc29s dmUgdGhlIHByb2JsZW0uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O1NpbmNlcmVseSBZb3Vy czxicj4NCiZndDsmZ3Q7WHVlcWluIFdlaSAoU2h1ZXRzaW5nIFdlaSk8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7RmliZXJob21lIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ2llcyBDby4s THRkLiw8YnI+DQomZ3Q7Jmd0OzIwMDktMDQtMTggJm5ic3A7MTQ6NDg6NTE8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PT09PT09PT09PT09PT09PT09PT0gRm9sbG93aW5nIGlzIHlvdXIgZW1h aWw9PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7Jmd0O1N1YmplY3Q6UmU6IFttcGxzLXRw XSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1UUCAod2FzIFJFOiA8YnI+DQomZ3Q7QXNzb2Np YXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTxicj4NCiZndDsm Z3Q7U2VudKO6MjAwOS0wNC0xNyAxNzoxNzozMTxicj4NCiZndDsmZ3Q7RnJvbTpCZW4gTml2ZW4t SmVua2luczxicj4NCiZndDsmZ3Q7VG86QlVTSSBJVEFMTzsgQWRyaWFuIEZhcnJlbDsgQWxleGFu ZGVyIFZhaW5zaHRlaW4gQ0MgdG86bXBscy10cDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7SXRhbG8sPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7T24gMTcvMDQvMjAw OSAwOTozNCwgJnF1b3Q7QlVTSSBJVEFMTyZxdW90OyAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1 Y2VudC5pdCZndDsNCndyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhlIEpXVCBhZ3JlZW1l bnQgaXMgdG8gYnJpbmcgdGhlIElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCmluIDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgSUVURiB0byBleHRlbmQgdGhlIE1QTFMgYXJjaGl0ZWN0dXJlIHRv IG1lZXQgdGhlbSBpbiBhDQp3YXkgdGhhdCBpcyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvbXBh dGlibGUsIGNvbnNpc3RlbnQgYW5kIGNvaGVyZW50IHdpdGggZXhpc3RpbmcgSUVURg0KYXJjaGl0 ZWN0dXJlLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O1NvIEkgdG9vayBhIGxv b2sgYXQgdGhlIEpXVCByZXBvcnQuIEl0IHNheXMgKHNsaWRlIDE2KTxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZxdW90OyBTZXJ2aWNlIFByb3ZpZGVycyB3YW50IExTUHMvUFdF cyB0byBiZSBhYmxlIHRvIGJlIG1hbmFnZWQNCmF0IHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDtkaWZm ZXJlbnQgbmVzdGVkIGxldmVscyBzZWFtbGVzc2x5IChwYXRoLCBzZWdtZW50LCBtdWx0aXBsZQ0K c2VnbWVudHMpPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtha2EgVGFuZGVtIENvbm5l Y3Rpb24gTW9uaXRvcmluZyAoVENNKSwgdGhpcw0KaXMgdXNlZCBmb3IgZXhhbXBsZSA8YnI+DQom Z3Q7Jmd0OyZndDt3aGVuIGEgTFNQL1BXRSBjcm9zc2VzIG11bHRpcGxlIGFkbWluaXN0cmF0aW9u cyZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O0lNTyB0aGUgcmVxdWly ZW1lbnQgaXMgdG8gYmUgYWJsZSB0byBtb25pdG9yIHBhcnRzIG9mIGEgcGF0aA0KYXMgd2VsbCBh cyA8YnI+DQomZ3Q7Jmd0OyZndDt0aGUgZW5kIHRvIGVuZCBwYXRoLiBUaGVyZSBhcmUgbWFueSB3 YXlzIHRvIHNvbHZlIHRoYXQgcmVxdWlyZW1lbnQsDQpvbmUgPGJyPg0KJmd0OyZndDsmZ3Q7b2Yg d2hpY2ggaXMgdGhlIGNyZWF0aW9uIG9mIG5lc3RlZCBMU1BzLCBvbmUgcGVyIGxldmVsIG9mIG1v bml0b3JpbmcNCjxicj4NCiZndDsmZ3Q7Jmd0O3JlcXVpcmVkIChteSB1bmRlcnN0YW5kaW5nIG9m IGhvdyBUQ00gd29ya3MpLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O0kgdGhp bmsgdGhlIHJlYWwgZGlzY3Vzc2lvbiBpcyB0aGVyZWZvcmUgaXMgdGhlIHJlcXVpcmVtZW50DQp0 byBtb25pdG9yIDxicj4NCiZndDsmZ3Q7Jmd0O2RpZmZlcmVudCBjb21wb25lbnRzIG9mIGFuIGVu ZCB0byBlbmQgcGF0aCBvciBpcyB0aGUgcmVxdWlyZW1lbnQNCnRoYXQgPGJyPg0KJmd0OyZndDsm Z3Q7c3VjaCBtb25pdG9yaW5nIE1VU1QgYmUgYWNoaWV2ZWQgdXNpbmcgbmVzdGVkIExTUHM/PGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7QXMgYW4gZXhhbXBsZSBQVyB0ZWNobm9s b2d5IHRvZGF5IGFsbG93cyBlbmQgdG8gZW5kIGFuZCBwZXINCnNlZ21lbnQgPGJyPg0KJmd0OyZn dDsmZ3Q7bW9uaXRvcmluZyBidXQgaXQgZG9lcyBub3QgYWNoaWV2ZSBpdCB1c2luZyBuZXN0ZWQg UFdzIG9yIFBXDQpsZXZlbHMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7QmVu PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDttcGxzLXRwIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0O21wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZn dDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7Jmd0 O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDttcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7bXBscy10cEBpZXRmLm9yZzxi cj4NCiZndDsmZ3Q7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRw PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Oz09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0O19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O21wbHMt dHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0O21wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDtaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCm1haWwg aXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFp bCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJz Ljxicj4NCiZndDtUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NCiZndDtUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt DQpzeXN0ZW0uPGJyPg0KPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxi cj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6 Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3Ro aXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21h aWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVj aXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJz cDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25v dCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250 ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290 aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7 dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwm bmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNw O3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5 Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJz cDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFp bCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJz cDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNw O3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNw O2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2Vu ZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZu YnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUm bmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00067901482575A1_=-- From liu.guoman@zte.com.cn Wed Apr 22 18:35:25 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CE93A6ABF for ; Wed, 22 Apr 2009 18:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.191 X-Spam-Level: X-Spam-Status: No, score=-97.191 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD1Fbppw6AY0 for ; Wed, 22 Apr 2009 18:35:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1A0B93A6BDB for ; Wed, 22 Apr 2009 18:35:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 11164764009499; Thu, 23 Apr 2009 09:26:13 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 90033.1399649406; Thu, 23 Apr 2009 09:32:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3N1Zu1b084270; Thu, 23 Apr 2009 09:36:00 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <005701c9c34d$65cbe850$a402540a@china.huawei.com> To: "Maarten Vissers" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Thu, 23 Apr 2009 09:33:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-23 09:35:56, Serialize complete at 2009-04-23 09:35:56 Content-Type: multipart/alternative; boundary="=_alternative 0008C716482575A1_=" X-MAIL: mse2.zte.com.cn n3N1Zu1b084270 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 01:35:25 -0000 This is a multipart message in MIME format. --=_alternative 0008C716482575A1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IG1hYXJ0ZW4ncyBvcGluaW9ucyBjb21wbGV0ZWx5LCBoZXJlIHRoYW5rIE1BQVJU RU4gZm9yIGV4cGxhaW5pbmcgDQppdCBpbiBkZXRhaWxzLg0KDQpyZWdhcmRzDQpsaXUNCg0KDQoN CiJNYWFydGVuIFZpc3NlcnMiIDxtYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbT4gDQq3orz+yMs6 ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDQtMjIgMjE6MjINCg0KytW8/sjLDQoi J0JSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMnIiA8ZGJydW5nYXJkQGF0dC5jb20+DQqzrcvN DQptcGxzLXRwQGlldGYub3JnDQrW98ziDQpSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCg0KDQoNCg0KDQoNCkRlYm9yYWgs DQoNClNlZSBpbmxpbmUuLi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJS VU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMgW21haWx0bzpkYnJ1bmdhcmRAYXR0LmNvbV0gDQpT ZW50OiBtYWFuZGFnIDIwIGFwcmlsIDIwMDkgMTc6NDcNClRvOiBNYWFydGVuIFZpc3NlcnM7IG5l aWwuMi5oYXJyaXNvbkBidC5jb20NCkNjOiBtcGxzLXRwQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCnJlcXVp cmVtZW50cw0KDQpJIGFncmVlIHdpdGggTmVpbCwgaXQgaXMgdmVyeSBxdWVzdGlvbmFibGUgdGhl IHZhbHVlIG9mIEFJUy9GREkgaW4gYSANCnBhY2tldA0KbmV0d29yay0gYW55IG1vZGUuIEl0IGNh biByZXN1bHQgaW4gYSBEb1MgYXR0YWNrIGJ5IGFuIG9wZXJhdG9yIG9uDQp0aGVtc2VsdmVzIHNv IGV2ZW4gWTE3MzEgcmVjb21tZW5kcyBub3QgdG8gYmxvY2sgZGF0YSBmcmFtZXM6DQoiQSBNRVAg Y2FuIGRlY2lkZSB3aGV0aGVyIGl0IGJsb2NrcyBkYXRhIGZyYW1lcyB3aGVuIGl0IGRldGVjdHMg ZEFJUy4NClRoZSBwcmluY2lwbGUgcmVxdWlyZW1lbnQNCnRoYXQgaW5mbHVlbmNlcyB0aGlzIGRl Y2lzaW9uIGlzIHRoYXQgZGF0YSBmcmFtZXMgb3VnaHQgdG8gYmUgZm9yd2FyZGVkIGFzDQptdWNo IGFzIHBvc3NpYmxlLCB3aXRob3V0IHRoZSBwb3NzaWJpbGl0eSBvZiBmb3J3YXJkaW5nIHdyb25n IGRhdGEgZnJhbWVzDQpkb3duc3RyZWFtLiINClRhYmxlIEkuNy0yIHNob3dzIGZvciBBSVMsIG5v dCB0byBibG9jay4NCg0KW212XSBJIHRob3VnaHQgdGhhdCBvbmUgb2YgdGhlIGNoYXJhY3Rlcmlz dGljcyBvZiBhIHRyYW5zcG9ydCBuZXR3b3JrIGlzDQp0aGF0IERvUyBhdHRhY2tzIGFyZSBub3Qg cG9zc2libGUuIEFJUy9GREkgZGVmaW5pdGVseSBkb2VzIG5vdCByZXN1bHQgaW4gDQphbnkNCkRv UyBhdHRhY2suDQoNClttdl0gV2l0aCB0aGUgZGV2ZWxvcG1lbnQgb2YgRXRoZXJuZXQgT0FNIHR3 byBtYWluIGVsZW1lbnRzIHdlcmUgZml4ZWQ6IA0KMSkgQUlTIHdhcyB1c2VkIHNvbGVseSBhcyBh biBhbGFybSBzdXBwcmVzc2lvbiBtZWNoYW5pc207IGkuZS4gQUlTIHdvdWxkIA0Kbm90DQpsb25n ZXIgYmUgdXNlZCB0byB0cmlnZ2VyIGZvciBwcm90ZWN0aW9uIHN3aXRjaGluZywgbm9yIHdvdWxk IGl0IGJlIHVzZWQgDQphcw0KYW4gaW5wdXQgY29uZGl0aW9uIGZvciB0cmFpbCBzaWduYWwgZmFp bCB3aGVuIExPQyBkZWZlY3QgZGV0ZWN0aW9uIGlzDQphY3RpdmF0ZWQNCjIpIExPQyBkZWZlY3Qg ZGV0ZWN0aW9uIHdvdWxkIG5vdCBsb25nZXIgYmxvY2sgdHJhZmZpYy4NCg0KW212XSBUaGVzZSBm aXhlcyBtYWRlIHN1cmUgdGhhdCB0aGVyZSB3b3VsZCBubyBsb25nZXIgYmUgYW4gZXh0ZW5zaW9u IG9mDQp0cmFmZmljIGludGVycnVwdGlvbiB0aGF0IGNvdWxkIHJlc3VsdCBpbiB0aGUgZGV0ZWN0 aW9uIG9mIHVuYXZhaWxhYmxlIA0KdGltZQ0KYXQgYSBkb3duc3RyZWFtIHBvaW50IGR1ZSB0byBh IHNob3J0IGludGVycnVwdGlvbiAoZS5nLiA1MCBtcykuIFN1Y2ggY291bGQNCm9jY3VyIGluIEFU TS4NCg0KDQpBbmQgYXMgWTE3MzEgc3RhdGVzLCBBSVMgY2FuIG9ubHkgYmUgdXNlZCB1bmRlciB2 ZXJ5IGNvbnN0cmFpbmVkDQphcmNoaXRlY3R1cmVzIC0gaWYgcmVxdWlyZWQgZm9yIE1QTFMtVFAs IGl0IG5lZWRzIHRvIGhhdmUgdGhlIHNhbWUgDQpndWlkYW5jZQ0KYXMgaW4gWTE3MzEsIGkuZS4g cG9pbnQtdG8tcG9pbnQgYW5kIHNlcnZlci9jbGllbnQgb25lLXRvLW9uZToNCiJmb3IgYSBwb2lu dC10by1wb2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSBzaW5nbGUgcGVlciBN RVAuDQpUaGVyZWZvcmUsIHRoZXJlDQppcyBubyBhbWJpZ3VpdHkgcmVnYXJkaW5nIHRoZSBwZWVy IE1FUCBmb3Igd2hpY2ggaXQgc2hvdWxkIHN1cHByZXNzIGFsYXJtcw0Kd2hlbiBpdCByZWNlaXZl cyB0aGUgRVRILUFJUyBpbmZvcm1hdGlvbi4iDQpTbyBzaG91bGQgb25seSBiZSB3aXRoaW4gb25l IGRvbWFpbiAtIHRoZW4gbm8gbmVlZC4NCg0KW212XSBUaGUgZnVsbCB0ZXh0IGluIFkuMTczMSBy ZWFkczogIkZvciBtdWx0aXBvaW50IEVUSCBjb25uZWN0aXZpdHksIGEgDQpNRVANCmNhbm5vdCBk ZXRlcm1pbmUgdGhlIHNwZWNpZmljIHNlcnZlciAoc3ViKSBsYXllciBlbnRpdHkgdGhhdCBoYXMg DQplbmNvdW50ZXJlZA0KZGVmZWN0IGNvbmRpdGlvbnMgdXBvbiByZWNlaXZpbmcgYSBmcmFtZSB3 aXRoIEVUSC1BSVMgaW5mb3JtYXRpb24uIE1vcmUNCmltcG9ydGFudGx5LCBpdCBjYW5ub3QgZGV0 ZXJtaW5lIHRoZSBhc3NvY2lhdGVkIHN1YnNldCBvZiBpdHMgcGVlciBNRVBzIA0KZm9yDQp3aGlj aCBpdCBzaG91bGQgc3VwcHJlc3MgYWxhcm1zIHNpbmNlIHRoZSByZWNlaXZlZCBFVEgtQUlTIGlu Zm9ybWF0aW9uIA0KZG9lcw0Kbm90IGNvbnRhaW4gdGhhdCBpbmZvcm1hdGlvbi4gVGhlcmVmb3Jl LCB1cG9uIHJlY2VwdGlvbiBvZiBhIGZyYW1lIHdpdGgNCkVUSC1BSVMgaW5mb3JtYXRpb24sIHRo ZSBNRVAgd2lsbCBzdXBwcmVzcyBhbGFybXMgZm9yIGFsbCBwZWVyIE1FUHMgDQp3aGV0aGVyDQp0 aGVyZSBpcyBzdGlsbCBjb25uZWN0aXZpdHkgb3Igbm90Lg0KSG93ZXZlciwgZm9yIGEgcG9pbnQt dG8tcG9pbnQgRVRIIGNvbm5lY3Rpb24sIGEgTUVQIGhhcyBvbmx5IGEgc2luZ2xlIHBlZXINCk1F UC4gVGhlcmVmb3JlLCB0aGVyZSBpcyBubyBhbWJpZ3VpdHkgcmVnYXJkaW5nIHRoZSBwZWVyIE1F UCBmb3Igd2hpY2ggaXQNCnNob3VsZCBzdXBwcmVzcyBhbGFybXMgd2hlbiBpdCByZWNlaXZlcyB0 aGUgRVRILUFJUyBpbmZvcm1hdGlvbi4gIg0KDQpbbXZdIFkuMTczMSB0aHVzIHN0YXRlcyB0aGF0 IEFJUyBpcyB1c2VkIGluIGFsbCBWTEFOIGNhc2VzLCBiZWluZyBWTEFOcyANCndpdGgNCjIgcG9y dHMgKHAycCkgYW5kIFZMQU5zIHdpdGggbW9yZSB0aGVuIDIgcG9ydHMgKHAybXAsIHJtcCwgbXAy bXApLiBJLmUuDQp0aGVyZSBhcmUgbm8gY29uc3RyYWlucyBpbiB1c2luZyBBSVMuDQoNClttdl0g V2hhdCB0aGUgdGV4dCBpbiBZLjE3MzEgZGVzY3JpYmVzIGlzIHRoYXQgaXQgaXMgcG9zc2libGUg aW4gYSBuLXBvcnQNCihuPjIpIFZMQU4gdG8gaGF2ZSB0d28gZmF1bHQgY29uZGl0aW9uczsgb25l IGlzIGEgc2VydmVyIGxheWVyIGZhdWx0IGFuZCANCnRoZQ0Kb3RoZXIgaXMgYSBjb250aW51aXR5 L2Nvbm5lY3Rpdml0eSBmYXVsdC4gSWYgYm90aCBmYXVsdHMgYXBwZWFyIGluIA0KZGlmZmVyZW50 DQpicmFuY2hlcyBvZiB0aGUgbi1wb3J0IFZMQU4gdGhlbiBhIE1FUCBTaW5rIGZ1bmN0aW9uIHdp bGwgZGV0ZWN0IG9uZSBvciANCm1vcmUNCkxPQyBkZWZlY3RzIGR1ZSB0byB0aGUgaW50ZXJydXB0 aW9uIG9mIG9uZSBvZiBpdHMgbGluayBjb25uZWN0aW9ucywgcGx1cyANCml0DQp3aWxsIGRldGVj dCBlaXRoZXIgb25lIG9yIG1vcmUgTE9DIGRlZmVjdHMgb3IgTU1HIGRlZmVjdCBkdWUgdG8gYQ0K Y29uZmlndXJhdGlvbiBmYXVsdCBpbiBvbmUgb2YgdGhlIG1hdHJpY2VzIHdpdGhpbiB0aGUgVkxB Ti4gVGhlIEFJUyANCmluc2VydGVkDQpkdWUgdG8gdGhlIHNlcnZlciBsYXllciBmYXVsdCAobGlu ayBjb25uZWN0aW9uIGludGVycnVwdGlvbikgc2hvdWxkDQplc3NlbnRpYWxseSBvbmx5IHN1cHBy ZXNzIHRoZSBmaXJzdCBzZXQgb2YgTE9DIGRlZmVjdHMgYW5kIHNob3VsZCBub3QNCnN1cHByZXNz IHRoZSBzZWNvbmQgKHNldCBvZikgTE9DIGRlZmVjdChzL01NRyBkZWZlY3QuIEJ1dCBhZnRlciBh IHZlcnkNCmRldGFpbGVkIGFuYWx5c2lzIChtYW55IGNvbnRyaWJ1dGlvbnMpIGl0IHdhcyBjb25j bHVkZWQgdGhhdCBzZWxlY3RpdmUgDQphbGFybQ0Kc3VwcHJlc3Npb24gd2FzIG5vdCBuZWNlc3Nh cnk7IGkuZS4gc3VwcHJlc3Npb24gb2YgYWxsIGFsYXJtcyAoaW5jbHVkaW5nIA0KdGhlDQpvbmUg YXNzb2NpYXRlZCB3aXRoIGEgY29ubmVjdGlvbiBmYXVsdCkgd2FzIHN1ZmZpY2llbnQuIFRoZSBt YWluIHJhdGlvbmFsZQ0Kd2FzIHRoYXQgaW4gZS5nLiBhIHAycCBWQzEyIGNvbm5lY3Rpb24gdG9k YXkgd2UgY2FuIGFsc28gaGF2ZSB0d28gZmF1bHRzLA0KaS5lLiBhIG1pc2Nvbm5lY3Rpb24gb3Ig b3BlbiBjb25uZWN0aW9uIGFuZCBhIHNlcnZlciBsYXllciBmYXVsdC4gSWYgdGhlDQpzZXJ2ZXIg bGF5ZXIgZmF1bHQgaXMgZG93bnN0cmVhbSBvZiB0aGUgY29ubmVjdGlvbiBmYXVsdCB0aGVuIGFs c28gaW4gYQ0KVkMtMTIgY29ubmVjdGlvbiB0aGUgc2VydmVyIGxheWVyIGZhdWx0IHN1cHByZXNz ZXMgYXdhcmVuZXNzIG9mIHRoZQ0KY29ubmVjdGlvbiBmYXVsdC4NCg0KUmVnYXJkcywNCk1hYXJ0 ZW4NCg0KDQpEZWJvcmFoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxz LXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZg0KT2YgTWFhcnRlbiBWaXNzZXJzDQpTZW50OiBNb25kYXksIEFwcmlsIDIwLCAyMDA5 IDEwOjA1IEFNDQpUbzogbmVpbC4yLmhhcnJpc29uQGJ0LmNvbQ0KQ2M6IG1wbHMtdHBAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoIA0KcmVxdWlyZW1lbnRzDQoNCk5laWwsDQoNCj4gYnV0IEFJUy9GREkgaW4gdGhl IGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZvdXIhDQoNCkV0aGVybmV0IEFJUyBpcyBpbmRlZWQgYSBy ZXF1aXJlbWVudCBhbmQgYSBuZWNlc3NpdHkuIEFuZCB5b3Ugd2lsbCBub3QgYmUNCmFibGUgdG8g dW5kZXJzdGFuZCB0aGF0IGFzIGxvbmcgYXMgeW91IHJlZnVzZSB0byBhY2NlcHQgdGhhdCAiY2wt bW9kZSINCmlzIGENCmZvcndhcmRpbmcgbW9kZSB3aXRoaW4gYSAqKnRyYW5zcG9ydCBlbnRpdHkq Ki4gRy44MDAgYW1lbmRtZW50IDEgaGFzIA0KZmluYWxseQ0KcmVpbnRyb2R1Y2VkIHRoaXMgdHJh bnNwb3J0IGVudGl0eSBpbnRvIEcuODAwLiBCZXNpZGVzIHRoYXQsIGl0IGFsc28NCmludHJvZHVj ZWQgdGhlICoqZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbioqOg0KDQpbRy44MDAgYW0xXSAiQSBk aWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIGlzIGEgdHJhbnNwb3J0IGVudGl0eSB0aGF0DQp0cmFu c2ZlcnMgaW5mb3JtYXRpb24gYmVsb25naW5nIHRvIG11bHRpcGxlIGNvbW11bmljYXRpb25zIGJl dHdlZW4gcG9ydHMNCmFjcm9zcyBhIHN1Ym5ldHdvcmsuIDwuLj4gSW4gYSBkaWZmZXJlbnRpYXRl ZCBjb25uZWN0aW9uIG1lc3NhZ2UgY29udGVudHMNCmFyZSBpbnRlcnByZXRlZCB0byBpZGVudGlm eSAoc2V0cyBvZikgY29tbXVuaWNhdGlvbnMgd2hpY2ggcmVjZWl2ZSANCmRpZmZlcmVudA0KdHJl YXRtZW50LiAgVGhlIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIGRpc3Rpbmd1aXNoZWQg YnkgdGhlDQpmb3J3YXJkaW5nIGlkZW50aWZpZXIgb3Igb3RoZXIgbGF5ZXIgaW5mb3JtYXRpb24u ICBPcmRlciBpcyBub3QgDQpuZWNlc3NhcmlseQ0KcHJlc2VydmVkIGJldHdlZW4gbWVzc2FnZXMg YmVsb25naW5nIHRvIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgcmVjZWl2aW5nDQpkaWZmZXJlbnQg dHJlYXRtZW50LiAgU2V0cyBvZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgaWRlbnRpZmllZCBmb3Ig DQpwdXJwb3Nlcw0Kc3VjaCBhcyB0cmFmZmljIGNvbmRpdGlvbmluZyBvciBwcmVzZXJ2aW5nIGNv bW11bmljYXRpb24gbWVzc2FnZSBvcmRlci4iDQoNCg0KRXRoZXJuZXQgVkxBTnMgYXJlIGluIHRl cm1zIG9mIEcuODAwICJkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9ucyIuDQpFdGhlcm5ldA0KQUlT IHByb3ZpZGVzIEFJUyB3aXRoaW4gdGhlIHNjb3BlIG9mIHN1Y2ggImRpZmZlcmVudGlhdGVkIGNv bm5lY3Rpb24iLg0KSWYNCnlvdSBhcHBseSB0aGlzIHRvIG15IHByb3Bvc2VkIFBUTiBsYXllciBz dGFjaywgdGhlbiB0aGUgRVZDIGxheWVyIHRvcG9sb2d5DQp3aWxsIGNvbnNpc3RzIG9mIEVWQyBs aW5rcyBzdXBwb3J0ZWQgYnkgTVBMUy1UUCwgRXRoZXJuZXQsIFBCQi1URSBhbmQgDQpQLU9UTg0K VlAgdHJhaWxzIGluc2lkZSBtZXRybyBhbmQgY29yZSBkb21haW5zIGludGVyY29ubmVjdGluZyBF VkMgbWF0cmljZXMuDQpXaGVuDQpvbmUgb2YgdGhvc2UgRVZDIGxpbmtzIGlzIGludGVycnVwdGVk LCBlLmcuIGluIHRoZSBjb3JlIGJldHdlZW4gbWV0cm8gMSANCmFuZA0KbWV0cm8gNCAoc2VlIGF0 dGFjaGVkIHNsaWRlKSwgdGhlbiB0aGUgRVZDIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24gdGhh dCANCmlzDQpwcmVzZW50IG9uIHRoaXMgbGluayB3aWxsIGJlIGludGVycnVwdGVkLiBBdCB0aGUg RVZDIHN3aXRjaC9icmlkZ2Ugbm9kZSBpbg0KbWV0cm8gNCB0aGlzIGludGVycnVwdGlvbiBpcyBu b3RpY2VkIGFuZCBFVkMtQUlTIGlzIGluc2VydGVkIGluIHRoZQ0KZG93bnN0cmVhbSBkaXJlY3Rp b24gdG8gc3VwcHJlc3MgdGhlIEVWQy1MT0MgYWxhcm1zIGF0IEVWQyBlbmRwb2ludHMgRDQgDQph bmQNCkQ1Lg0KDQpUaGUgRVZDLUFJUyAoaS5lLiBFdGhlcm5ldCBBSVMpIGZyYW1lIGhhcyBhIHJl c2VydmVkIG11bHRpY2FzdCBhZGRyZXNzLA0Kd2hpY2ggZ3VhcmFudGVlcyB0aGF0IHRoZSBBSVMg aXMgYnJvYWRjYXN0IHRvIHRoZSBlbmRwb2ludHMgb2YgdGhlIEVWQy4NCg0KSSBiZWxpZXZlIHRo YXQgaXQgaXMgdGltZSBmb3IgeW91IHRvIGFkYXB0IHlvdXIgdmlldyBvbiBjbyBhbmQgY2wgbW9k ZXMgDQphbmQNCnJlbGF0ZSBpdCB0byB0aGUgZm9yd2FyZGluZyBtb2RlICoqSU5TSURFKiogYSB0 cmFuc3BvcnQgZW50aXR5LiANCg0KV2hhdCB3ZSBrbm93IGFzIHRoZSBpbnRlcm5ldCBpcyBlc3Nl bnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQNCmNvbm5lY3Rpb24iIHdpdGggYSBiaWxsaW9u IG9yIG1vcmUgcG9ydHMuDQpXaGF0IHdlIGtub3cgYXMgYW4gSVAgVlBOIGlzIGVzc2VudGlhbGx5 IGFuICJJUCBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIg0Kd2l0aCBlLmcuIG4gcG9ydHMgKG4g aW4gdGhlIHJhbmdlIG9mIGUuZy4gMiB0byAxMDAwKS4NCldoYXQgd2Uga25vdyBhcyBhbiBFdGhl cm5ldCBWTEFOIGlzIGVzc2VudGlhbGx5IGFuICJFdGhlcm5ldCANCmRpZmZlcmVudGlhdGVkDQpj b25uZWN0aW9uIiB3aXRoIG4gcG9ydHMgKG4gaW4gdGhlIHJhbmdlIG9mIGUuZy4gMiB0byAxMDAw KS4NCldoYXQgd2Uga25vdyBhcyBhIHAycCBNUExTIEUtTFNQIGlzIGVzc2VudGlhbGx5IGFuICJN UExTIGRpZmZlcmVudGlhdGVkDQpjb25uZWN0aW9uIiB3aXRoIDIgcG9ydHMuDQpXaGF0IHdlIGtu b3cgYXMgYSBwMnAgU0RIIFZDLW4gaXMgYSAiU0RIIFZDLW4gY29ubmVjdGlvbiIgd2l0aCAyIHBv cnRzLg0KDQpUcmFuc3BvcnQgbmV0d29yayBPQU0gYXBwbGllcyB0byB0cmFuc3BvcnQgZW50aXRp ZXMsIHdoaWNoIGFyZSAoaW4gdGVybXMgDQpvZg0KRy44MDAgYW0xKSBjb25uZWN0aW9ucyBhbmQg ZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbnMuDQoNClJlZ2FyZHMsDQpNYWFydGVuDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZWlsLjIuaGFycmlzb25AYnQuY29tIFttYWls dG86bmVpbC4yLmhhcnJpc29uQGJ0LmNvbV0NClNlbnQ6IHZyaWpkYWcgMTcgYXByaWwgMjAwOSAy MjowMA0KVG86IEpvaG4uRS5EcmFrZTJAYm9laW5nLmNvbTsgSXRhbG8uQnVzaUBhbGNhdGVsLWx1 Y2VudC5pdDsNCkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBtYWFydGVuLnZpc3Nl cnNAaHVhd2VpLmNvbQ0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KcmVxdWlyZW1lbnRz DQoNCkpvaG4sICBUaGFua3MgdGhpcyBpcyBhIGdyZWF0IHBsYXRmb3JtIHRvIGV4cGxhaW4gd2h5 IE9BTSBmb3IgdGhlIDMgDQpuZXR3b3JrDQptb2RlcyBuZWVkcyB0byBiZSBkaWZmZXJlbnQuICBJ IGFtIGdldHRpbmcgYSB3ZWUgYml0IHRpcmVkIG9mIGZvbGtzIHRyeWluZw0KdG8gbWFrZSBhbGwg MyBuZXR3b3JrIG1vZGVzIGxvb2sgYWxpa2UgKGFuZCB0aGVuLCBldmVuIHdvcnNlLCBpbnRlcndv cmsgDQp0aGVtDQphcyBhcyBwZWVycy4uLmVzcCB3aGVuIG5vdCBub3QgdG9wLW9mLXN0YWNrDQpu ZXR3b3Jrcy4uLkkgbWVhbiBob3cgc2lsbHkgY2FuIHdlIGdldD8pLiAgIEkgYW0gZXZlbiBtb3Jl IGZydXN0cmF0ZWQgYnkNCnRoZSBmYWN0IHRob3NlIHBlZGRsaW5nIHRoaXMgRlVEIG9ubHkgZXZl ciBzZWVtIHRvIGNvbnNpZGVyIE9BTSBhbmQgZm9yZ2V0DQphbGwgb3RoZXIgRFAvQ1AvTVAgY29t cG9uZW50cyAoZXNwIHRvcC1vZi1zdGFjayBtZXNzYWdlL2ZpbGUvc3RyZWFtDQphcHBsaWNhdGlv biBhZGFwdGF0aW9ucykuICBIb3cgd3JvbmcgY2FuIHRoaXMgZ2V0ISANCg0KSW4gdGhlIGNvIG1v ZGVzIGEgKmNvbm5lY3Rpb24qIGlzIGEgdmVyeSBzcGVjaWZpYyBhbmQgKmNvbnN0cmFpbmluZyoN CmNvbnN0cnVjdC4uLi4uSSBhbSBhc3N1bWluZyBoZXJlIHdlIHJlc3BlY3QgdGhlIHJ1bGVzIG9m IGEgY29ubmVjdGlvbiAoaWUNCnNpbmdsZSBzb3VyY2UpIHRob3VnaCBzb21lIGZvbGtzIGRvbid0 IGV2ZW4gYm90aGVyIHRvIHJlc3BlY3QgdGhpcywgYW5kIA0KdGhpcw0KaXMgZGVzcGl0ZSB0aGUg ZmFjdCB0aGF0IHdlIGFsbCBrbm93IHdoYXQgcHJvYmxlbXMgbXVsdGlwbGUtc291cmNlDQpjb25z dHJ1Y3RzIGNhbiBjYXVzZSAoZnJvbSBMRFAvUEhQLi4uLmVyZ28gTVBMUy1UUCkuDQoNCldoZW4g d2UgaGF2ZSBhIGNvbm5lY3Rpb24gdGhpcyByZXN0cmljdHMgKmFsbCogRFAgKGllIHRyYWZmaWMg YW5kIE9BTSkgdG8NCnN0YXkgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIGNvbm5lY3Rpb24uICBX aGljaCBpcyBmaW5lIHVuZGVyIGRlZmVjdC1mcmVlDQpjb25kaXRpb25zLCBidXQgaWYgd2UgaGF2 ZSBsZWFraW5nIHRyYWZmaWMgdGhlbiB0aGUgY29uc3RyYWluaW5nIG5hdHVyZSBvZg0KdGhlIGNv bm5lY3Rpb24gY29uc3RydWN0IGlzIGJyb2tlbi4gIEluIGEgbnV0c2hlbGwgd2hhdCB0aGlzIG1l YW5zIGlzIHRoYXQNCk9BTSB0aGF0IGlzIG9mIGEgcmVxdWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fu bm90IGJlIHRydXN0ZWQgaW4gY28gbW9kZQ0KbmV0d29ya3MgdW5kZXIgbWlzY29ubmVjdGl2aXR5 IGRlZmVjdHMuLi4uLmluZGVlZCwgd2h5IHNob3VsZCBhIGxlYWtpbmcgRFANCmhhdmUgYSBzeW1t ZXRyaWMgZ28vcmV0dXJuIGRlZmVjdCBiZWhhdmlvdXI/Li4uLnZlcnkgbGlrZWx5IGl0IHdvbid0 Lg0KU28NCndoaWxzdCByZXF1ZXN0L3Jlc3BvbnNlIE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1v ZGUgaXQgaXMgbm90IHJpZ2h0IGZvciANCnRoZQ0KY28gbW9kZSB1bmRlciBtaXNjb25uZWN0aXZp dHkgZGVmZWN0IGNvbmRpdGlvbnMuDQoNCk1vcmUgZ2VuZXJhbGx5IHRoZSAzIG1vZGVzIGFyZSBk aWZmZXJlbnQgYW5kIG5vdCBqdXN0IGluIE9BTQ0KcmVxdWlyZW1lbnRzLi4uLmJ1dCBBSVMvRkRJ IGluIHRoZSBjbCBtb2RlPy4uLmRvIG1lIGEgZmF2b3VyIS4uLmF0IGxlYXN0DQpJRUVFIGhhZCB0 aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRoZXJuZXQgZXZlbiB0aG91Z2ggaXQgcmVt YWlucyBpbg0KWS4xNzMxLiAgQW5kIHdoaWNoIGlzIHdoeSBJIG9mdGVuIHRyb3Qtb3V0IHRoZSBy YXRoZXIgc2lsbHkgKHRvIGhhdmUgdG8gDQpzYXkNCnRoaXMpIG9ic2VydmF0aW9uIHRoYXQgaWYg SVAgKGNsIG1vZGUpIGNvdWxkIGRvIGl0IGFsbCB0aGVuIHdoeSBoYXZlIElFVEYNCmZvdW5kIGl0 IG5lY2Vzc2FyeSB0byBjcmVhdGUgTVBMUyAoY28tcHMpIGFuZCBHTVBMUyAoQ1AgZm9yIGNvLWNz KS4gIFRoZQ0KYW5zd2VyIGxpZXMgaW4gdGhlIHBoeXNpY3MuLi5hbmQgRy44MDAgYXR0ZW1wdHMg dG8gZXhwbGFpbiB0aGF0DQpwaHlzaWNzLi4uLkcuODA1IGRvZXMgbm90Lg0KDQpTbywgdGhlIDMg bW9kZXMgYXJlIGRpZmZlcmVudC4uLnBsZWFzZSBhY2NlcHQvcmVqb2ljZSBpbiB0aGlzIGZhY3Qg YXMgdGhleQ0KYWxsIG9mZmVyIHNvbWV0aGluZyBkaWZmZXJlbnQvaW1wb3J0YW50LiAgQnV0IGRv IG5vdCBiZSBob29kd2lua2VkIGJ5IA0KdGhvc2UNCndobyBwZWRkbGUgYSBzdG9yeSB0aGF0IHRo YXQgdHJpZXMgdG8gbWFrZSB0aGUgT0FNIG9mIHRoZSAzIG1vZGVzIHRoZSANCnNhbWUuIA0KDQpy ZWdhcmRzLCBOZWlsIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIERyYWtlLCBKb2huIEUNCj4gU2VudDogMTcgQXByaWwgMjAwOSAyMDow Mg0KPiBUbzogQlVTSSBJVEFMTzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vy cw0KPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCj4gcmVxdWlyZW1lbnRzDQo+IA0K PiBJdGFsbywNCj4gDQo+IEFzIGRlc2NyaWJlZCBpbiB0aGUgTVBMUyBUUCBPQU0gUmVxdWlyZW1l bnRzIEktRCwgdmlydHVhbGx5IGFsbCBvZiB0aGUNCg0KPiBPQU0gZnVuY3Rpb25zIHJlcXVpcmUg YSByZXR1cm4gcGF0aCwgYW5kIGluIHRoZSBhYnNlbmNlIG9mIGEgcmV0dXJuIA0KPiBwYXRoIHRo ZXkgYXJlIGRpc2FibGVkLg0KPiANCj4gQXMgZGVzY3JpYmVkIGluIERhdmlkIFNpbmljcm9wZSdz IG1lZXRpbmcgbWludXRlcyANCj4gKGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL21pc2MvbXBs cy1pbnRlcm9wL2F0dGFjaG1lbnQvd2lraS8NCj4gbWVldGluZy1ubw0KPiB0ZXMvMjAwODEwMTUu bXBscy1pbnRlcm9wLWR0LW5vdGVzLnppcCksIGlmIElQIGFkZHJlc3NpbmcgaXMgdXNlZCwgYW4g DQo+IE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBiZSBjYXBhYmxlIG9mIGdldHRpbmcgSVAgcGFj a2V0cyBmcm9tIA0KPiBkZXN0aW5hdGlvbiB0byBzb3VyY2U7IG5laXRoZXIgdGhlIG1pbnV0ZXMg bm9yIEkgc3RpcHVsYXRlIHRoYXQgYSANCj4gY29udHJvbCBwbGFuZSBuZWVkcyB0byBiZSB1c2Vk IHRvIGluc3RhbnRpYXRlIHRoaXMgZm9yd2FyZGluZy4NCj4gDQo+IEFzIGFuIGFzaWRlLCB0aGUg aXNzdWUgb2YgcmV0dXJuIHBhdGggZm9yIHVuaWRpcmVjdGlvbmFsIExTUHMgY291bGQgYmUNCg0K PiBjaGFyYXRlcml6ZWQgYXMgdGhlIGVsZXBoYW50IGluIHRoZSByb29tLiAgSW4gdGhlIE1QTFMg VFAgT0FNIA0KPiBGcmFtZXdvcmsgSS1ELCB1bmljYXN0IExTUHMgYXJlIG9ubHkgbWVudGlvbmVk IHRocmVlIHRpbWVzIGFuZCByZXR1cm4gDQo+IHBhdGhzIG5vdCBhdCBhbGwuDQo+IA0KPiBUaGFu a3MsDQo+IA0KPiBKb2huDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9t OiBCVVNJIElUQUxPIFttYWlsdG86SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdF0NCj4gPiBT ZW50OiBGcmlkYXksIEFwcmlsIDE3LCAyMDA5IDE6NTkgQU0NCj4gPiBUbzogRHJha2UsIEpvaG4g RTsgQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KPiA+IENjOiBtcGxzLXRw QGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gcmVxdWlyZW1lbnRzDQo+ID4gDQo+ID4gSm9obiwN Cj4gPiANCj4gPiBJIG1pZ2h0IGhhdmUgbWlzc2VkIHRoZSBhZ3JlZW1lbnQgb2YgTVBMUy1UUCBi ZWluZyBjYXBhYmxlIG9mIA0KPiA+IHNlbmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2Vu dCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQcy4NCj4gPiANCj4gPiBUaGlzIHJlcXVpcmVtZW50IGRv ZXMgbm90IGJlbG9uZyB0byB0aGUgZmlyc3Qgc2V0IG9mIHJlcXVpcmVtZW50cyANCj4gPiBJVFUt VCBpcyBleHBlY3RpbmcgdG8gYmUgbWV0IGJ5IE9jdG9iZXIuDQo+ID4gDQo+ID4gSG93ZXZlciwg SSB0aGluayB0aGlzIGluIGEgcG90ZW50aWFsIGludGVyZXN0aW5nIGFkZGl0aW9uYWwgDQo+ID4g cmVxdWlyZW1lbnQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IChhdCB3b3JzdCBpbiBhDQo+IHN1 YnNlcXVlbnQgcGhhc2UpLg0KPiA+IA0KPiA+IEkgdGhpbmsgdGhhdCB0aGlzIHJlcXVpcmVtZW50 IG5lZWRzIHRvIGJlIGV2YWx1YXRlZCB2ZXJzdXMgb3RoZXIgDQo+ID4gbW9yZSBpbXBvcnRhbnQg cmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJpbGl0eSB0byB3b3JrIHcvbyBJUCANCj4gPiBm b3J3YXJkaW5nIGFuZCB0aGUgbmVlZCBmb3IgT0FNIHRvIGNvbnRpbnVlIHRvIG1vbml0b3IgdGhl IGRhdGEgDQo+ID4gcGxhbmUgYWxzbyBpbiBjYXNlIG9mIGZhaWx1cmVzIGFmZmVjdGluZyB0aGUg Y29udHJvbCBvciBtYW5hZ2VtZW50IA0KPiA+IHBsYW5lKS4NCj4gPiANCj4gPiBJIGFtIG9wZW4g dG8gZGlzY3VzcyBpdCBidXQgbm90IHN1cmUgdGhpcyBpcyB0aGUgcmlnaHQgdGltZSBiZWNhdXNl IA0KPiA+IEkgd2lzaCB0byBhdm9pZCBkZWxheWluZyB0aGUgZmlyc3QgcGhhc2Ugb2YgdGhlIGRl c2lnbiBzb2x1dGlvbi4NCj4gPiANCj4gPiBUaGFua3MsIEl0YWxvDQo+ID4gDQo+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYu b3JnDQo+ID4gPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERyYWtlLCBKb2huIEUNCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA4OjAw IFBNDQo+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KPiA+ ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KPiA+ID4gcmVxdWlyZW1lbnRz DQo+ID4gPiANCj4gPiA+IEF0IHRoZSBtZWV0aW5nIGxhc3QgZmFsbCBhdCBKdW5pcGVyIGluIE1h c3NhY2h1c2V0dHMsIEkNCj4gPiB0aGluayBpdCB3YXMNCj4gPiA+IGFncmVlZCB0aGF0IGFuIE1Q TFMgVFAgbmV0d29yayBuZWVkcyB0byBoYXZlIGEgZm9yd2FyZGluZw0KPiA+IGNhcGFiaWxpdHkN Cj4gPiA+IGZvciBtYW5hZ2VtZW50LCBjb250cm9sLCBhbmQgT0FNIHBhY2tldHMgKGUuZy4sIHNl bmRpbmcNCj4gPiByZXBsaWVzIHRvIE9BTQ0KPiA+ID4gcmVxdWVzdHMgc2VudCBvbiB1bmktZGly ZWN0aW9uYWwgTFNQcykgZXZlbiBpZiBpdCBkb2VzIG5vdA0KPiA+IGhhdmUgYW4gSVANCj4gPiA+ IGZvcndhcmRpbmcgZGF0YSBwbGFuZS4NCj4gPiA+IA0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiA+ID4gW21h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gPiA+ID4gU2VudDogVGh1 cnNkYXksIEFwcmlsIDE2LCAyMDA5IDk6NTcgQU0NCj4gPiA+ID4gVG86IE1hYXJ0ZW4gVmlzc2Vy cw0KPiA+ID4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW21w bHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCj4gPiA+ID4g cmVxdWlyZW1lbnRzDQo+ID4gPiA+IA0KPiA+ID4gPiBNYWFydGVuLA0KPiA+ID4gPiBJdCBzZWVt cyB0aGF0IHlvdSd2ZSBqdXN0IChpbXBsaWNpdGx5IGFuZCwgcHJvYmFibHksDQo+ID4gPiA+IGlu YWR2ZXJ0ZW50bHkpIHN0YXRlZCB0aGUgZm9sbG93aW5nOg0KPiA+ID4gPiANCj4gPiA+ID4gICAg ICAgICAgICAgICAgICBNUExTLVRQIE9BTSB3aWxsIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3Bi YWNrIA0KZnVuY3Rpb24NCj4gPiAoYW5kIGZhdWx0DQo+ID4gPiA+IGxvY2FsaXphdGlvbiB3aGlj aCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uICkgZm9yDQo+ID4gdW5pZGlyZWN0aW9uYWwgUDJNUA0K PiA+ID4gPiBhbmQgUDJQIHBhdGhzLg0KPiA+ID4gPiANCj4gPiA+ID4gSWYgdGhpcyBzdGF0ZW1l bnQgaXMgY29ycmVjdCwgdGhpcyAoSU1ITyBhbmQgRldJVykNCj4gcmFpc2VzIGEgdmFsaWQNCj4g PiA+ID4gcXVlc3Rpb246DQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgIElzIE1Q TFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIHRoZXNlDQo+IHR5cGVzIG9mIHRyYW5z cG9ydA0KPiA+ID4gPiBwYXRocz8NCj4gPiA+ID4gDQo+ID4gPiA+IEZvciB0aGUgcmVmZXJlbmNl LCBJUC9NUExTIHByb3ZpZGVzIHRoaXMga2luZCBvZg0KPiA+IGZ1bmN0aW9uYWxpdHkgdG9kYXkN Cj4gPiA+ID4gZm9yICh1bmlkaXJlY3Rpb25hbCAtIGJ1dCBpdCBkb2VzIG5vdCBrbm93IGFueSBv dGhlcg0KPiA+IHR5cGUpIFAyUCBMU1BzDQo+ID4gPiA+IGFzIGRlc2NyaWJlZCBpbiBSRkMgNDM3 OS4gQW5kIGl0cyBleHRlbnNpb24gdG8gUDJNUCBMU1BzIHNlZW1zIA0KPiA+ID4gPiBlYXN5Li4u DQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IFJlZ2FyZHMsDQo+ID4gPiA+ IA0KPiA+ID4gPiAgICAgIFNhc2hhDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJv bTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddDQo+ ID4gT24gQmVoYWxmDQo+ID4gPiA+IE9mIE1hYXJ0ZW4gVmlzc2VycyBbbWFhcnRlbi52aXNzZXJz QGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAzOjI0 IFBNDQo+ID4gPiA+IFRvOiAnQWRyaWFuIEZhcnJlbCcNCj4gPiA+ID4gQ2M6IG1wbHMtdHBAaWV0 Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiANCj4g PiA+ID4gQWRyaWFuLA0KPiA+ID4gPiANCj4gPiA+ID4gPj4gPHF1b3RlPg0KPiA+ID4gPiA+PiAg ICAgIFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZyBNRVBzLCBNSVBzIGFuZA0KPiA+ ID4gPiBvdGhlciBpbnRlcm5hbA0KPiA+ID4gPiA+PiAgICAgICBmdW5jdGlvbnMgYXMgYXBwcm9w cmlhdGUpIG9mIGEgY28tcm91dGVkDQo+ID4gPiA+IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQo+ ID4gPiA+ID4+ICAgICAgIHBhdGggYXQgZWFjaCAoc3ViLSlsYXllciBNVVNUIGJlIGF3YXJlIG9m IHRoZSBwYWlyaW5nDQo+ID4gPiA+ID4+ICAgICAgIHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2Fy ZCBhbmQgdGhlIGJhY2t3YXJkDQo+ID4gPiA+IGRpcmVjdGlvbnMgb2YgdGhhdA0KPiA+ID4gPiA+ PiAgICAgICB0cmFuc3BvcnQgcGF0aC4NCj4gPiA+ID4gPj4gPGVuZCBxdW90ZT4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlzIGEgZnVuY3Rpb25hbCByZXF1aXJl bWVudC4gVGhhdA0KPiA+ID4gaXMsIHRoZXJlIGlzDQo+ID4gPiA+ID4gKm5vdGhpbmcqIHRoYXQg Y2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCj4gPiA+IHZpZXcgdGhh dA0KPiA+ID4gPiA+IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVtZW50Lg0K PiA+ID4gPiANCj4gPiA+ID4gWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBjb3JyZWN0LiBJdCBp cyB2ZXJ5IG11Y2gNCj4gb2JzZXJ2YWJsZSBpZg0KPiA+ID4gPiB0aGlzIHJlcXVpcmVtZW50IGlz IG1ldCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZpZXcuDQo+ID4gPiA+IFRoZSBNSVAgZnVu Y3Rpb25zIGNhbiBvbmx5IHBlcmZvcm0gdGhlIExvb3BiYWNrIHdoZW4gdGhlcmUgaXMgYSANCj4g PiA+ID4gY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoZSBNUExTLVRQ IExCTSBwYWNrZXQgDQo+ID4gPiA+IHJlY2VpdmVkIGF0IGEgTUlQIG5lZWRzIHRvIGJlIHJldHVy bmVkIChhcyBMQlINCj4gPiA+ID4gcGFja2V0KSB0byB0aGUgb3JpZ2luYXRpbmcgTUVQIGZ1bmN0 aW9uIHZpYSB0aGUgb3RoZXINCj4gPiBkaXJlY3Rpb24gb2YNCj4gPiA+ID4gdGhlIGNvLXJvdXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoLiBUaGlzIG90aGVyDQo+IGRpcmVjdGlvbg0K PiA+ID4gPiB3b3VsZCBub3QgYmUgYXZhaWxhYmxlIGluIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCB0cmFuc3BvcnQgDQo+ID4gPiA+IHBhdGguLi4gYW5kIHRodXMgdGhlIGxvb3BiYWNrIHRl c3QNCj4gPiA+IHdvdWxkIGZhaWwuDQo+ID4gPiA+IA0KPiA+ID4gPiBTaW1pbGFybHksIHdoZW4g d2UgaGF2ZSB0byBhcHBseSBUQ00gTUVQcyB0byBtb25pdG9yIGENCj4gPiBzZWdtZW50LCB0aGVu DQo+ID4gPiA+IHRoaXMgaXMgcG9zc2libGUgaW4gYSBjby1yb3V0ZWQgYmlkaXIgdHJhbnNwb3J0 IHBhdGgNCj4gYnV0IG5vdCBpbiBhDQo+ID4gPiA+IGFzc29jaWF0ZWQgYmlkaXIgdHJhbnNwb3J0 IHBhdGguIEluIHRoZSBmaXJzdCBjYXNlIHRoZSBUQ00gTUVQIA0KPiA+ID4gPiBTb3VyY2UgYW5k IFNpbmsgZnVuY3Rpb25zIGFyZSBjby1sb2NhdGVkIGFuZCBjYW4NCj4gZXhjaGFuZ2Ugd2hhdCBp cw0KPiA+ID4gPiBjYWxsZWQgInJlbW90ZSBpbmZvcm1hdGlvbiIgd2hpY2ggaXMgbmVjZXNzYXJ5 IGZvciBwZXJmb3JtYW5jZSANCj4gPiA+ID4gbW9uaXRvcmluZy4NCj4gPiA+ID4gSW4gdGhlIGxh dHRlciBjYXNlIHRoZSBUQ00gTUVQIFNvdXJjZSBhbmQgU2luayBmdW5jdGlvbnMNCj4gPiBhcmUg aW4gZS5nLiANCj4gPiA+ID4gZGlmZmVyZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIGFuZCBUQ00g d291bGQgbm90IGJlIGFibGUNCj4gPiB0byBwcm92aWRlDQo+ID4gPiA+IHBlcmZvcm1hbmNlIG1v bml0b3JpbmcuDQo+ID4gPiA+IA0KPiA+ID4gPiA+IFRoZSBlbnRpcmV0eSBvZiB0aGUgYnJhY2tl dHRlZCB0ZXh0ICIoaW5jbHVkaW5nIE1FUHMsDQo+ID4gPiBNSVBzIGFuZCBvdGhlcg0KPiA+ID4g PiBpbnRlcm5hbA0KPiA+ID4gPiA+IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkiIHNob3VsZCBi ZSBkZWxldGVkLiBJdCBkb2VzIG5vdA0KPiA+ID4gPiBhZGQgdG8gIlRoZQ0KPiA+ID4gPiA+IGlu dGVybWVkaWF0ZSBub2Rlcy4iDQo+ID4gPiA+IA0KPiA+ID4gPiBZb3VyIHVuZGVyc3RhbmRpbmcg aXMgbm90IGNvcnJlY3QuIFRoaXMgdGV4dCBtdXN0IG5vdCBiZQ0KPiA+IGRlbGV0ZWQgYXQNCj4g PiA+ID4gYWxsLg0KPiA+ID4gPiANCj4gPiA+ID4gPiBBY3R1YWxseSwgSSBhbSBxdWl0ZSBmZWQg dXAgYWJvdXQgdGhpcyBwZXJzaXN0ZW50DQo+ID4gPiBpbnNpc3RlbmNlIG9uIHRoZQ0KPiA+ID4g PiBpbmNsdXNpb24NCj4gPiA+ID4gPiBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5p dGlvbiB3aXRoaW4gdGhlIElUVS1UIG9mDQo+ID4gPiA+IHRoaXMgdGVybQ0KPiA+ID4gPiA+IGlz DQo+ID4gPiA+IHBvb3JseQ0KPiA+ID4gPiA+IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUg bW9uaXRvcmluZyBvZiBhIHBhdGggdGhhdCBpcw0KPiA+ID4gPiBwYXJhbGxlbCAoaS5lLg0KPiA+ ID4gPiB0YW5kZW0pDQo+ID4gPiA+ID4gdG8gdGhlIGRhdGEgcGF0aCBiZWluZyBtb25pdG9yZWQu IFRoaXMgZGVmaW5pdGlvbiBvZiBUQw0KPiA+ID4gPiBzZWVtcyB0byBiZSBhdA0KPiA+ID4gPiB2 YXJpYW5jZSwNCj4gPiA+ID4gPiBhbmQgd291bGQgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkg aW4gYmFuZC4NCj4gPiA+ID4gDQo+ID4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGVyZSB5b3Vy IGludGVycHJldGF0aW9uIG9mIHRhbmRlbQ0KPiA+IGNvbm5lY3Rpb24gaXMNCj4gPiA+ID4gZGVz Y3JpYmVkIGluIElUVS1UIHJlY29tbWVuZGF0aW9ucy4gSS5lLiAiZnJvbSB0aGUNCj4gPiBtb25p dG9yaW5nIG9mIGENCj4gPiA+ID4gcGF0aCB0aGF0IGlzIHBhcmFsbGVsIChpLmUuIHRhbmRlbSkg dG8gdGhlIGRhdGEgcGF0aCBiZWluZyANCj4gPiA+ID4gbW9uaXRvcmVkLiI/DQo+ID4gPiA+IA0K PiA+ID4gPiBUaGVyZSBpcyBhICJuZXR3b3JrIGNvbm5lY3Rpb24iIGFuZCB0aGlzIG5ldHdvcmsN Cj4gPiBjb25uZWN0aW9uIGlzIGEgc2V0DQo+ID4gPiA+IG9mIGludGVyY29ubmVjdGVkICJsaW5r IGNvbm5lY3Rpb25zIiBhbmQgIm1hdHJpeA0KPiBjb25uZWN0aW9ucyIuIEENCj4gPiA+ID4gc3Vi c2V0IG9mIHRob3NlIGludGVyY29ubmVjdGVkIGxpbmsgY29ubmVjdGlvbnMgYW5kIG1hdHJpeCAN Cj4gPiA+ID4gY29ubmVjdGlvbnMgY2FuIGJlIG1vbml0b3JlZCBhbmQgaXMgdGhlbiByZWZlcnJl ZCB0byBhcw0KPiBhICJ0YW5kZW0NCj4gPiA+ID4gY29ubmVjdGlvbiIuIFRoZXJlIGlzIG5vICJw YXRoIHRoYXQgaXMgcGFyYWxsZWwgdG8gdGhlDQo+ID4gZGF0YSBwYXRoIi4gDQo+ID4gPiA+IFRo ZXJlIGlzIG9ubHkgYWRkaXRpb25hbCBPQU0gaW5zZXJ0ZWQgaW5zaWRlIHRoZSBkYXRhDQo+IHBh dGggYnkgdGhlDQo+ID4gPiA+IFRDTSBNRVBfU28gZnVuY3Rpb24gYW5kIHRoaXMgT0FNIGlzIGV4 dHJhY3RlZCBmcm9tIHRoZQ0KPiA+IGRhdGEgcGF0aCBieQ0KPiA+ID4gPiB0aGUgVENNIE1FUF9T ayBmdW5jdGlvbi4NCj4gPiA+ID4gDQo+ID4gPiA+IFJlZ2FyZHMsDQo+ID4gPiA+IE1hYXJ0ZW4N Cj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4gPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+ID4gW21haWx0bzpt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQo+ID4g PiA+IFNlbnQ6IGRvbmRlcmRhZyAxNiBhcHJpbCAyMDA5IDExOjU5DQo+ID4gPiA+IFRvOiBBbGV4 YW5kZXIgVmFpbnNodGVpbjsgYmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20NCj4gPiA+ID4g Q2M6IEJVU0kgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQo+ID4gPiA+ IHJlcXVpcmVtZW50cw0KPiA+ID4gPiANCj4gPiA+ID4gSGkgU2FzaGEsDQo+ID4gPiA+IA0KPiA+ ID4gPiA+IFVuZm9ydHVuYXRlbHkgSSBjYW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRl bWVudDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDxxdW90ZT4NCj4gPiA+ID4gPiAgICAgRnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkDQo+ID4gPiBiaWRpcmVjdGlv bmFsIExTUHMNCj4gPiA+ID4gPiAgICAgYXJlIGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbCBMU1BzLg0KPiA+ID4gPiA+IDxlbmQgcXVvdGU+DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBUaGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZSBp dCBub3QgZm9yDQo+ID4gPiA+IFJlcXVpcmVtZW50DQo+ID4gPiA+ID4gMzQgaW4gdGhlIGxhdGVz dCBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdA0KPiA+ID4gPiANCj4gPiA+ID4gT0suIEdvdCBp dC4NCj4gPiA+ID4gDQo+ID4gPiA+IEJ1dCB3aGF0IGlzIHRoaXMgZG9pbmcgaW4gdGhlIGRhdGEg cGxhbmUgcmVxdWlyZW1lbnRzIHNlY3Rpb24/DQo+ID4gPiA+IA0KPiA+ID4gPiBJbiBmYWN0LCB3 aGF0IGlzIHRoaXMgcmVxdWlyZW1lbnQgYWN0dWFsbHkgc2F5aW5nPw0KPiA+ID4gPiANCj4gPiA+ ID4gPiA8cXVvdGU+DQo+ID4gPiA+ID4gICAgICBUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIChpbmNs dWRpbmcgTUVQcywgTUlQcyBhbmQNCj4gPiA+IG90aGVyIGludGVybmFsDQo+ID4gPiA+ID4gICAg ICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZA0KPiA+ID4gPiBiaWRp cmVjdGlvbmFsIHRyYW5zcG9ydA0KPiA+ID4gPiA+ICAgICAgIHBhdGggYXQgZWFjaCAoc3ViLSls YXllciBNVVNUIGJlIGF3YXJlIG9mIHRoZSBwYWlyaW5nDQo+ID4gPiA+ID4gICAgICAgcmVsYXRp b25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQNCj4gPiA+ID4gZGlyZWN0aW9u cyBvZiB0aGF0DQo+ID4gPiA+ID4gICAgICAgdHJhbnNwb3J0IHBhdGguDQo+ID4gPiA+ID4gPGVu ZCBxdW90ZT4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlzIGEgZnVu Y3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdA0KPiA+IGlzLCB0aGVyZSBpcw0KPiA+ID4gPiAqbm90 aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZg0KPiA+ IHZpZXcgdGhhdA0KPiA+ID4gPiByZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJl bWVudC4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXJlZm9yZSBpdCBjb3VsZCBiZSBhc3N1bWVkIHRo YXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgYnkgDQo+ID4gPiA+IGNvbmZpZ3VyaW5nIHNvbWUg ZGF0YSBwbGFuZSBkYXRhYmFzZSBjb21wb25lbnQgdGhyb3VnaCB0aGUgDQo+ID4gPiA+IG1hbmFn ZW1lbnQgcGxhbmUuIFRoZSBkYXRhYmFzZSBjb21wb25lbnQgaXMgbm90IHVzZWQNCj4gZm9yIGFu eXRoaW5nDQo+ID4gPiA+IGV4Y2VwdCB0byBzYXRpc2Z5IHRoaXMgcmVxdWlyZW1lbnQgZm9yICJh d2FyZW5lc3MiLg0KPiA+ID4gPiANCj4gPiA+ID4gQmVuISBDYW4gd2UgcGxlYXNlIHRyeSB0byBy ZXdyaXRlIHRoaXMgcmVxdWlyZW1lbnQgaW4gdGVybXMgb2YgDQo+ID4gPiA+IGJlaGF2aW9yPw0K PiA+ID4gPiANCj4gPiA+ID4gPiBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IGlzIHRo ZSBPTkxZIGl0ZW0gaW4gdGhlDQo+ID4gPiA+IGxpc3QgdGhhdCBpcw0KPiA+ID4gPiA+IHNwZWNp ZmljIGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiAoVGhlIHBhaXJpbmcNCj4gPiA+ ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4gYXQgZW5kIHBvaW50cyBmb3IgY28tcm91dGVkIGFu ZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCj4gPiA+IHBhdGhzIGFyZQ0KPiA+ID4gPiA+IGV4 YWN0bHkgdGhlIHNhbWUgZXZlbiBpZiB0aGV5IGFwcGVhciBpbiB0d28gZGlmZmVyZW50DQo+ID4g PiBpdGVtcyBpbiB0aGUNCj4gPiA+ID4gPiByZXF1aXJlbWVudHMnIGxpc3QpLg0KPiA+ID4gPiA+ IEluIG90aGVyIHdvcmRzLCB3aXRob3V0IFJlcXVpcmVtZW50IDM0IHRoZSBub3Rpb24gb2YNCj4g Y28tcm91dGVkDQo+ID4gPiA+ID4gYmlkaXJlY3Rpb25hbCBwYXRocyB3b3VsZCBiZSB2b2lkIG9m IGFueSBkYXRhIHBsYW5lIGNvbnRlbnQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGUgc29tZXdo YXQgdmFndWUgc2NvcGUgb2YgdGhpcyByZXF1aXJlbWVudCAoIm90aGVyIGludGVybmFsIA0KPiA+ ID4gPiA+IGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSIpIGNyZWF0ZXMgYSBzdXNwaWNpb24gdGhh dCBIVw0KPiA+ID4gPiBzdXBwb3J0IG9mIHRoZQ0KPiA+ID4gPiA+IHBhaXJpbmcgYXdhcmVuZXNz IG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC4NCj4gPiA+ID4gDQo+ ID4gPiA+IFRoZSBlbnRpcmV0eSBvZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICIoaW5jbHVkaW5nIE1F UHMsDQo+ID4gTUlQcyBhbmQgb3RoZXINCj4gPiA+ID4gaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFw cHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0DQo+ID4gZG9lcyBub3QNCj4gPiA+ID4g YWRkIHRvICJUaGUgaW50ZXJtZWRpYXRlIG5vZGVzLiINCj4gPiA+ID4gDQo+ID4gPiA+ID4gVGhl IGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkcmFmdCBpbmNyZWFzZXMgdGhpcyBzdXNwaWNpb246DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiA8cXVvdGU+DQo+ID4gPiA+ID4gICBUYW5kZW0gQ29ubmVjdGlv bjogQSB0YW5kZW0gY29ubmVjdGlvbiBpcyBhbg0KPiA+IGFyYml0cmFyeSBwYXJ0IG9mIGENCj4g PiA+ID4gPiAgIHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSkN Cj4gPiA+ID4gaW5kZXBlbmRlbnRseSBmcm9tIHRoZQ0KPiA+ID4gPiA+ICAgZW5kLXRvLWVuZCBt b25pdG9yaW5nIChPQU0pLiAgSXQgbWF5IGJlIGEgbW9uaXRvcmVkDQo+ID4gc2VnbWVudCBvciBh DQo+ID4gPiA+ID4gICBtb25pdG9yZWQgY29uY2F0ZW5hdGVkIHNlZ21lbnQgb2YgYSB0cmFuc3Bv cnQgcGF0aC4gDQo+ID4gVGhlIHRhbmRlbQ0KPiA+ID4gPiA+ICAgY29ubmVjdGlvbiBtYXkgYWxz byBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVuZ2luZShzKSBvZg0KPiA+ID4gPiB0aGUgbm9kZShz KQ0KPiA+ID4gPiA+ICAgYXQgdGhlIGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5h dGVkIHNlZ21lbnQuDQo+ID4gPiA+ID4gPGVuZCBxdW90ZT4NCj4gPiA+ID4gDQo+ID4gPiA+IEFj dHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQNCj4gPiBpbnNp c3RlbmNlIG9uIHRoZQ0KPiA+ID4gPiBpbmNsdXNpb24gb2YgIlRhbmRlbSBDb25uZWN0aW9uLiIg VGhlIGRlZmluaXRpb24gd2l0aGluDQo+ID4gdGhlIElUVS1UIG9mDQo+ID4gPiA+IHRoaXMgdGVy bSBpcyBwb29ybHkgc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZQ0KPiBtb25pdG9yaW5nIG9m IGENCj4gPiA+ID4gcGF0aCB0aGF0IGlzIHBhcmFsbGVsIChpLmUuIHRhbmRlbSkgdG8gdGhlIGRh dGEgcGF0aCBiZWluZyANCj4gPiA+ID4gbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24gb2YgVEMg c2VlbXMgdG8gYmUgYXQgdmFyaWFuY2UsDQo+ID4gYW5kIHdvdWxkDQo+ID4gPiA+IGJlIGlmIHRo ZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQo+ID4gPiA+IA0KPiA+ID4gPiA+IERvZXNuJ3Qg ImZvcndhcmRpbmcgZW5naW5lIiBzb3VuZCBsaWtlIGhhcmR3YXJlIHRvIHlvdT8NCj4gPiA+ID4g DQo+ID4gPiA+IFllcywgYnV0IHNvIHdoYXQ/DQo+ID4gPiA+IA0KPiA+ID4gPiA+IElNSE8gaXQg aXMgd29ydGggbm90aW5nIHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUA0KPiA+ID4gUmVxdWlyZW1l bnRzIGRyYWZ0DQo+ID4gPiA+ID4gbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25l DQo+ID4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gDQo+ID4gDQo+IChodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVtZW4NCj4g PiA+ID4gPiB0cy0wMS50eHQpIGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGgg dGFuZGVtDQo+ID4gPiBjb25uZWN0aW9ucy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJ1dCB0YW5k ZW0gY29ubmVjdGlvbnMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgTVBMUy1UUCBPQU0NCj4gPiBGcmFt ZXdvcmsNCj4gPiA+ID4gPiBkcmFmdA0KPiA+ID4gPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcg0KPiA+ID4gPiBhbWV3b3JrLTAw LnR4dA0KPiA+ID4gPiApLg0KPiA+ID4gPiANCj4gPiA+ID4gUmlnaHQuDQo+ID4gPiA+IExldCdz IGp1c3QgZ2V0IHJpZCBvZiBhbiB1bm5lY2Vzc2FyeSB0ZXJtIGFuZCBicmluZyBhbGwNCj4gdGhl IEktRHMNCj4gPiA+ID4gaW50byBsaW5lLg0KPiA+ID4gPiANCj4gPiA+ID4gPiBUaGUgYm90dG9t IGxpbmUsIElNSE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZw0KPiA+ID4gY28tcm91 dGVkIHZzLg0KPiA+ID4gPiA+IGFzc29jaWF0ZWQNCj4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBh dGhzIGlzIHN0aWxsIHJlcXVpcmVkLiBPbmUgd2F5IHRvIHByb3ZpZGUNCj4gPiA+ID4gdGhhdCBj b3VsZA0KPiA+ID4gPiA+IGJlIGJ5IGV4cGxpY2l0bHkgbGltaXRpbmcgUmVxdWlyZW1lbnQgMzQg dG8gc3BlY2lmaWMNCj4gPiA+IGZ1bmN0aW9uYWxpdHkuDQo+ID4gPiA+IA0KPiA+ID4gPiBBZ3Jl ZWQuDQo+ID4gPiA+IA0KPiA+ID4gPiBBZHJpYW4NCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4g PiANCj4gPiA+ID4gDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+ID4gRnJvbTogQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a10N Cj4gPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjEzIEFNDQo+ID4gPiA+ IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTw0KPiA+ID4g PiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCj4gPiA+ID4gcmVxdWlyZW1l bnRzDQo+ID4gPiA+IA0KPiA+ID4gPiBIaSBTYXNoYSwNCj4gPiA+ID4gDQo+ID4gPiA+IE5vdCBy ZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwgYnV0Li4u DQo+ID4gPiA+IA0KPiA+ID4gPiA+IDEuIE15IHJlYWRpbmcgb2YgIG9uZSBvZiBCZW4ncyAgbWVz c2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkIA0KPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgcGF0aHMg YXJlIHRoZSBvbmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQgY2FuIGJlDQo+ID4gPiA+IGNyZWF0ZWQg aW4NCj4gPiA+ID4gPiB0aGUgZXhpc3RpbmcgbmV0d29ya3M7ICJ0cnVlIiBjby1yb3V0ZWQgYmlk aXJlY3Rpb25hbCBwYXRocw0KPiA+ID4gPiB3aWxsIGhhdmUNCj4gPiA+ID4gPiB0byB3YWl0IHVu dGlsIChpZiBldmVyKSBuZXcgZXF1aXBtZW50IGJlY29tZXMgYXZhaWxhYmxlLg0KPiA+ID4gPiAN Cj4gPiA+ID4gVGhpcyBpcyBjbGVhcmx5IG5vbnNlbnNlIQ0KPiA+ID4gPiBGcm9tIHRoZSBwb2lu dCBvZiB2aWV3IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQNCj4gPiBiaWRpcmVjdGlvbmFsIExTUHMg YXJlDQo+ID4gPiA+IGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1BzLg0KPiA+ID4gPiANCj4gPiA+ID4gSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlv bmFsIExTUHMgKGUuZy4gdXNpbmcgdGhlDQo+ID4gbWFuYWdlbWVudA0KPiA+ID4gPiBwbGFuZSkg eW91IGNhbiBzdXJlbHkgc2V0IHVwIGEgY28tcm91dGVkDQo+ID4gPiBiaWRpcmVjdGlvbmFsIExT UC4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXJlIGFyZSBzaGlwcGluZyBzb2x1dGlvbnMgdGhhdCBh Y2hpZXZlIGNvLXJvdXRlZA0KPiBiaWRpcmVjdGlvbmFsDQo+ID4gPiA+IExTUHMgdXNpbmcgdGhl IGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVpdGhlciB1c2UgdGhlIEdNUExTDQo+ID4gKHdoaWNoIGlz DQo+ID4gPiA+IGNsZWFuZXIpIG9yIG5vbi1zdGFuZGFyZCBwcm9wcmlldGFyeSBzb2x1dGlvbnMg KHdoaWNoIGlzDQo+ID4gbWVzc3kgYnV0DQo+ID4gPiA+IGZ1bmN0aW9uYWwpLg0KPiA+ID4gPiAN Cj4gPiA+ID4gQnV0IChvZiBjb3Vyc2UpIHRoZSBtYW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wg cGxhbmUNCj4gPiBzb2x1dGlvbnMgaGF2ZQ0KPiA+ID4gPiBub3RoaW5nIHRvIGRvIHdpdGggYXZh aWxhYmlsaXR5IG9mIGVxdWlwbWVudCBhcyB0aGV5DQo+IGFyZSBzb2Z0d2FyZQ0KPiA+ID4gPiBz b2x1dGlvbnMuDQo+ID4gPiA+IA0KPiA+ID4gPiA+IDIuIE15IHJlYWRpbmcgb2Ygb25lIG9mIE5l aWwncyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWwNCj4gPiA+ID4gZHJpdmVyIGZvcg0KPiA+ ID4gPiA+IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdp dGggZXhpc3RpbmcgDQo+ID4gPiA+ID4gdHJhbnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFuIGFu eSBzcGVjaWZpYyBiZW5lZml0Lg0KPiA+ID4gPiANCj4gPiA+ID4gSXNuJ3QgdGhhdCB0aGUgY2Fz ZSB3aXRoIDc1JSBvZiB0aGUgTVBMUy1UUCByZXF1aXJlbWVudHM/DQo+ID4gPiA+IFdoaWNoIGlz IG5vdCB0byBzYXkgaXQgaXMgYSBiYWQgdGhpbmcuDQo+ID4gPiA+IA0KPiA+ID4gPiBBIGxhcmdl IGRyaXZlciBmb3IgTVBMUy1UUCBpcyB0byBnaXZlIHRoZSBwYWNrZXQgbmV0d29yaw0KPiA+IHRo ZSBsb29rLA0KPiA+ID4gPiBmZWVsLCBhbmQgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3RpY3Mgb2Yg YSAibGVnYWN5Ig0KPiA+ID4gPiB0cmFuc3BvcnQgbmV0d29yay4NCj4gPiA+ID4gDQo+ID4gPiA+ ID4gQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3MgKEZXSVcpIHRoYXQ6DQo+ ID4gPiA+ID4gKiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlLCBhdCBsZWFzdCBm b3IgdGhlIHRpbWUNCj4gPiA+ID4gPiAgICBiZWluZywgdGhlIG1vc3QgaW1wb3J0YW50IHR5cGUg b2YgYmlkaXJlY3Rpb25hbCBwYXRocyBpbg0KPiA+ID4gPiA+ICAgIE1QTFMtVFANCj4gPiA+ID4g DQo+ID4gPiA+IEkgdGhpbmsgdGhhdCBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBh Ym92ZSwgYW5kDQo+ID4gZ2l2ZW4gdGhhdA0KPiA+ID4gPiBvdGhlciB1cGdyYWRlcyB0byBleGlz dGluZyBNUExTIHNvbHV0aW9ucyB3aWxsIGJlDQo+IG5lZWRlZCB0byByZWFjaA0KPiA+ID4gPiB0 aGUgZnVsbCBmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLg0KPiA+ID4gPiANCj4gPiA+ID4gPiAq IHRoZXkgaGFkIGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IHR5cGUgb2YNCj4gPiBi aWRpcmVjdGlvbmFsDQo+ID4gPiA+ID4gICBwYXRocyBpbiAgcmVhbCBkZXBsb3ltZW50cy4NCj4g PiA+ID4gDQo+ID4gPiA+IEkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCBmb2xsb3dzIGZyb20uDQo+ID4g PiA+IA0KPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+IEFkcmlhbg0KPiA+ID4gPiANCj4gPiA+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4g bXBscy10cCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KPiA+ID4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPiA+ID4gDQo+ ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+ID4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCj4g PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ID4g PiA+IA0KPiA+ID4gPiANCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+ID4gbXBscy10cEBp ZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz LXRwDQo+ID4gPiANCj4gPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gbXBscy10cEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAg bWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0008C716482575A1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgc3VwcG9ydCBtYWFydGVuJ3Mg b3BpbmlvbnMgY29tcGxldGVseSwNCmhlcmUgdGhhbmsgTUFBUlRFTiBmb3IgZXhwbGFpbmluZyBp dCBpbiBkZXRhaWxzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+cmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ bGl1PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PiZxdW90O01hYXJ0ZW4gVmlzc2VycyZxdW90Ow0KJmx0O21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWku Y29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63 orz+yMs6ICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTIyIDIxOjIyPC9mb250Pg0KPHRkIHdpZHRo PTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OydCUlVOR0FSRCwg REVCT1JBSCBBLCBBVFRMQUJTJyZxdW90Ow0KJmx0O2RicnVuZ2FyZEBhdHQuY29tJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+bXBscy10cEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVt ZW50czwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+RGVib3JhaCw8YnI+DQo8YnI+DQpTZWUgaW5saW5lLi4uPGJyPg0KPGJyPg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRM QUJTIFttYWlsdG86ZGJydW5nYXJkQGF0dC5jb21dIDxicj4NClNlbnQ6IG1hYW5kYWcgMjAgYXBy aWwgMjAwOSAxNzo0Nzxicj4NClRvOiBNYWFydGVuIFZpc3NlcnM7IG5laWwuMi5oYXJyaXNvbkBi dC5jb208YnI+DQpDYzogbXBscy10cEBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFJFOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxi cj4NCjxicj4NCkkgYWdyZWUgd2l0aCBOZWlsLCBpdCBpcyB2ZXJ5IHF1ZXN0aW9uYWJsZSB0aGUg dmFsdWUgb2YgQUlTL0ZESSBpbiBhIHBhY2tldDxicj4NCm5ldHdvcmstIGFueSBtb2RlLiBJdCBj YW4gcmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBhbiBvcGVyYXRvciBvbjxicj4NCnRoZW1zZWx2 ZXMgc28gZXZlbiBZMTczMSByZWNvbW1lbmRzIG5vdCB0byBibG9jayBkYXRhIGZyYW1lczo8YnI+ DQomcXVvdDtBIE1FUCBjYW4gZGVjaWRlIHdoZXRoZXIgaXQgYmxvY2tzIGRhdGEgZnJhbWVzIHdo ZW4gaXQgZGV0ZWN0cyBkQUlTLjxicj4NClRoZSBwcmluY2lwbGUgcmVxdWlyZW1lbnQ8YnI+DQp0 aGF0IGluZmx1ZW5jZXMgdGhpcyBkZWNpc2lvbiBpcyB0aGF0IGRhdGEgZnJhbWVzIG91Z2h0IHRv IGJlIGZvcndhcmRlZA0KYXM8YnI+DQptdWNoIGFzIHBvc3NpYmxlLCB3aXRob3V0IHRoZSBwb3Nz aWJpbGl0eSBvZiBmb3J3YXJkaW5nIHdyb25nIGRhdGEgZnJhbWVzPGJyPg0KZG93bnN0cmVhbS4m cXVvdDs8YnI+DQpUYWJsZSBJLjctMiBzaG93cyBmb3IgQUlTLCBub3QgdG8gYmxvY2suPGJyPg0K PGJyPg0KW212XSBJIHRob3VnaHQgdGhhdCBvbmUgb2YgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiBh IHRyYW5zcG9ydCBuZXR3b3JrIGlzPGJyPg0KdGhhdCBEb1MgYXR0YWNrcyBhcmUgbm90IHBvc3Np YmxlLiBBSVMvRkRJIGRlZmluaXRlbHkgZG9lcyBub3QgcmVzdWx0IGluDQphbnk8YnI+DQpEb1Mg YXR0YWNrLjxicj4NCjxicj4NClttdl0gV2l0aCB0aGUgZGV2ZWxvcG1lbnQgb2YgRXRoZXJuZXQg T0FNIHR3byBtYWluIGVsZW1lbnRzIHdlcmUgZml4ZWQ6DQo8YnI+DQoxKSBBSVMgd2FzIHVzZWQg c29sZWx5IGFzIGFuIGFsYXJtIHN1cHByZXNzaW9uIG1lY2hhbmlzbTsgaS5lLiBBSVMgd291bGQN Cm5vdDxicj4NCmxvbmdlciBiZSB1c2VkIHRvIHRyaWdnZXIgZm9yIHByb3RlY3Rpb24gc3dpdGNo aW5nLCBub3Igd291bGQgaXQgYmUgdXNlZA0KYXM8YnI+DQphbiBpbnB1dCBjb25kaXRpb24gZm9y IHRyYWlsIHNpZ25hbCBmYWlsIHdoZW4gTE9DIGRlZmVjdCBkZXRlY3Rpb24gaXM8YnI+DQphY3Rp dmF0ZWQ8YnI+DQoyKSBMT0MgZGVmZWN0IGRldGVjdGlvbiB3b3VsZCBub3QgbG9uZ2VyIGJsb2Nr IHRyYWZmaWMuPGJyPg0KPGJyPg0KW212XSBUaGVzZSBmaXhlcyBtYWRlIHN1cmUgdGhhdCB0aGVy ZSB3b3VsZCBubyBsb25nZXIgYmUgYW4gZXh0ZW5zaW9uIG9mPGJyPg0KdHJhZmZpYyBpbnRlcnJ1 cHRpb24gdGhhdCBjb3VsZCByZXN1bHQgaW4gdGhlIGRldGVjdGlvbiBvZiB1bmF2YWlsYWJsZQ0K dGltZTxicj4NCmF0IGEgZG93bnN0cmVhbSBwb2ludCBkdWUgdG8gYSBzaG9ydCBpbnRlcnJ1cHRp b24gKGUuZy4gNTAgbXMpLiBTdWNoIGNvdWxkPGJyPg0Kb2NjdXIgaW4gQVRNLjxicj4NCjxicj4N Cjxicj4NCkFuZCBhcyBZMTczMSBzdGF0ZXMsIEFJUyBjYW4gb25seSBiZSB1c2VkIHVuZGVyIHZl cnkgY29uc3RyYWluZWQ8YnI+DQphcmNoaXRlY3R1cmVzIC0gaWYgcmVxdWlyZWQgZm9yIE1QTFMt VFAsIGl0IG5lZWRzIHRvIGhhdmUgdGhlIHNhbWUgZ3VpZGFuY2U8YnI+DQphcyBpbiBZMTczMSwg aS5lLiBwb2ludC10by1wb2ludCBhbmQgc2VydmVyL2NsaWVudCBvbmUtdG8tb25lOjxicj4NCiZx dW90O2ZvciBhIHBvaW50LXRvLXBvaW50IEVUSCBjb25uZWN0aW9uLCBhIE1FUCBoYXMgb25seSBh IHNpbmdsZSBwZWVyDQpNRVAuPGJyPg0KVGhlcmVmb3JlLCB0aGVyZTxicj4NCmlzIG5vIGFtYmln dWl0eSByZWdhcmRpbmcgdGhlIHBlZXIgTUVQIGZvciB3aGljaCBpdCBzaG91bGQgc3VwcHJlc3Mg YWxhcm1zPGJyPg0Kd2hlbiBpdCByZWNlaXZlcyB0aGUgRVRILUFJUyBpbmZvcm1hdGlvbi4mcXVv dDs8YnI+DQpTbyBzaG91bGQgb25seSBiZSB3aXRoaW4gb25lIGRvbWFpbiAtIHRoZW4gbm8gbmVl ZC48YnI+DQo8YnI+DQpbbXZdIFRoZSBmdWxsIHRleHQgaW4gWS4xNzMxIHJlYWRzOiAmcXVvdDtG b3IgbXVsdGlwb2ludCBFVEggY29ubmVjdGl2aXR5LA0KYSBNRVA8YnI+DQpjYW5ub3QgZGV0ZXJt aW5lIHRoZSBzcGVjaWZpYyBzZXJ2ZXIgKHN1YikgbGF5ZXIgZW50aXR5IHRoYXQgaGFzIGVuY291 bnRlcmVkPGJyPg0KZGVmZWN0IGNvbmRpdGlvbnMgdXBvbiByZWNlaXZpbmcgYSBmcmFtZSB3aXRo IEVUSC1BSVMgaW5mb3JtYXRpb24uIE1vcmU8YnI+DQppbXBvcnRhbnRseSwgaXQgY2Fubm90IGRl dGVybWluZSB0aGUgYXNzb2NpYXRlZCBzdWJzZXQgb2YgaXRzIHBlZXIgTUVQcw0KZm9yPGJyPg0K d2hpY2ggaXQgc2hvdWxkIHN1cHByZXNzIGFsYXJtcyBzaW5jZSB0aGUgcmVjZWl2ZWQgRVRILUFJ UyBpbmZvcm1hdGlvbg0KZG9lczxicj4NCm5vdCBjb250YWluIHRoYXQgaW5mb3JtYXRpb24uIFRo ZXJlZm9yZSwgdXBvbiByZWNlcHRpb24gb2YgYSBmcmFtZSB3aXRoPGJyPg0KRVRILUFJUyBpbmZv cm1hdGlvbiwgdGhlIE1FUCB3aWxsIHN1cHByZXNzIGFsYXJtcyBmb3IgYWxsIHBlZXIgTUVQcyB3 aGV0aGVyPGJyPg0KdGhlcmUgaXMgc3RpbGwgY29ubmVjdGl2aXR5IG9yIG5vdC48YnI+DQpIb3dl dmVyLCBmb3IgYSBwb2ludC10by1wb2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkg YSBzaW5nbGUgcGVlcjxicj4NCk1FUC4gVGhlcmVmb3JlLCB0aGVyZSBpcyBubyBhbWJpZ3VpdHkg cmVnYXJkaW5nIHRoZSBwZWVyIE1FUCBmb3Igd2hpY2gNCml0PGJyPg0Kc2hvdWxkIHN1cHByZXNz IGFsYXJtcyB3aGVuIGl0IHJlY2VpdmVzIHRoZSBFVEgtQUlTIGluZm9ybWF0aW9uLiAmcXVvdDs8 YnI+DQo8YnI+DQpbbXZdIFkuMTczMSB0aHVzIHN0YXRlcyB0aGF0IEFJUyBpcyB1c2VkIGluIGFs bCBWTEFOIGNhc2VzLCBiZWluZyBWTEFOcw0Kd2l0aDxicj4NCjIgcG9ydHMgKHAycCkgYW5kIFZM QU5zIHdpdGggbW9yZSB0aGVuIDIgcG9ydHMgKHAybXAsIHJtcCwgbXAybXApLiBJLmUuPGJyPg0K dGhlcmUgYXJlIG5vIGNvbnN0cmFpbnMgaW4gdXNpbmcgQUlTLjxicj4NCjxicj4NClttdl0gV2hh dCB0aGUgdGV4dCBpbiBZLjE3MzEgZGVzY3JpYmVzIGlzIHRoYXQgaXQgaXMgcG9zc2libGUgaW4g YSBuLXBvcnQ8YnI+DQoobiZndDsyKSBWTEFOIHRvIGhhdmUgdHdvIGZhdWx0IGNvbmRpdGlvbnM7 IG9uZSBpcyBhIHNlcnZlciBsYXllciBmYXVsdA0KYW5kIHRoZTxicj4NCm90aGVyIGlzIGEgY29u dGludWl0eS9jb25uZWN0aXZpdHkgZmF1bHQuIElmIGJvdGggZmF1bHRzIGFwcGVhciBpbiBkaWZm ZXJlbnQ8YnI+DQpicmFuY2hlcyBvZiB0aGUgbi1wb3J0IFZMQU4gdGhlbiBhIE1FUCBTaW5rIGZ1 bmN0aW9uIHdpbGwgZGV0ZWN0IG9uZSBvcg0KbW9yZTxicj4NCkxPQyBkZWZlY3RzIGR1ZSB0byB0 aGUgaW50ZXJydXB0aW9uIG9mIG9uZSBvZiBpdHMgbGluayBjb25uZWN0aW9ucywgcGx1cw0KaXQ8 YnI+DQp3aWxsIGRldGVjdCBlaXRoZXIgb25lIG9yIG1vcmUgTE9DIGRlZmVjdHMgb3IgTU1HIGRl ZmVjdCBkdWUgdG8gYTxicj4NCmNvbmZpZ3VyYXRpb24gZmF1bHQgaW4gb25lIG9mIHRoZSBtYXRy aWNlcyB3aXRoaW4gdGhlIFZMQU4uIFRoZSBBSVMgaW5zZXJ0ZWQ8YnI+DQpkdWUgdG8gdGhlIHNl cnZlciBsYXllciBmYXVsdCAobGluayBjb25uZWN0aW9uIGludGVycnVwdGlvbikgc2hvdWxkPGJy Pg0KZXNzZW50aWFsbHkgb25seSBzdXBwcmVzcyB0aGUgZmlyc3Qgc2V0IG9mIExPQyBkZWZlY3Rz IGFuZCBzaG91bGQgbm90PGJyPg0Kc3VwcHJlc3MgdGhlIHNlY29uZCAoc2V0IG9mKSBMT0MgZGVm ZWN0KHMvTU1HIGRlZmVjdC4gQnV0IGFmdGVyIGEgdmVyeTxicj4NCmRldGFpbGVkIGFuYWx5c2lz IChtYW55IGNvbnRyaWJ1dGlvbnMpIGl0IHdhcyBjb25jbHVkZWQgdGhhdCBzZWxlY3RpdmUNCmFs YXJtPGJyPg0Kc3VwcHJlc3Npb24gd2FzIG5vdCBuZWNlc3Nhcnk7IGkuZS4gc3VwcHJlc3Npb24g b2YgYWxsIGFsYXJtcyAoaW5jbHVkaW5nDQp0aGU8YnI+DQpvbmUgYXNzb2NpYXRlZCB3aXRoIGEg Y29ubmVjdGlvbiBmYXVsdCkgd2FzIHN1ZmZpY2llbnQuIFRoZSBtYWluIHJhdGlvbmFsZTxicj4N CndhcyB0aGF0IGluIGUuZy4gYSBwMnAgVkMxMiBjb25uZWN0aW9uIHRvZGF5IHdlIGNhbiBhbHNv IGhhdmUgdHdvIGZhdWx0cyw8YnI+DQppLmUuIGEgbWlzY29ubmVjdGlvbiBvciBvcGVuIGNvbm5l Y3Rpb24gYW5kIGEgc2VydmVyIGxheWVyIGZhdWx0LiBJZiB0aGU8YnI+DQpzZXJ2ZXIgbGF5ZXIg ZmF1bHQgaXMgZG93bnN0cmVhbSBvZiB0aGUgY29ubmVjdGlvbiBmYXVsdCB0aGVuIGFsc28gaW4g YTxicj4NClZDLTEyIGNvbm5lY3Rpb24gdGhlIHNlcnZlciBsYXllciBmYXVsdCBzdXBwcmVzc2Vz IGF3YXJlbmVzcyBvZiB0aGU8YnI+DQpjb25uZWN0aW9uIGZhdWx0Ljxicj4NCjxicj4NClJlZ2Fy ZHMsPGJyPg0KTWFhcnRlbjxicj4NCjxicj4NCjxicj4NCkRlYm9yYWg8YnI+DQo8YnI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmPGJyPg0KT2YgTWFh cnRlbiBWaXNzZXJzPGJyPg0KU2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSAxMDowNSBBTTxi cj4NClRvOiBuZWlsLjIuaGFycmlzb25AYnQuY29tPGJyPg0KQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8 YnI+DQpTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCByZXF1aXJlbWVudHM8YnI+DQo8YnI+DQpOZWlsLDxicj4NCjxicj4NCiZndDsg YnV0IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZvdXIhPGJyPg0KPGJyPg0K RXRoZXJuZXQgQUlTIGlzIGluZGVlZCBhIHJlcXVpcmVtZW50IGFuZCBhIG5lY2Vzc2l0eS4gQW5k IHlvdSB3aWxsIG5vdA0KYmU8YnI+DQphYmxlIHRvIHVuZGVyc3RhbmQgdGhhdCBhcyBsb25nIGFz IHlvdSByZWZ1c2UgdG8gYWNjZXB0IHRoYXQgJnF1b3Q7Y2wtbW9kZSZxdW90Ozxicj4NCmlzIGE8 YnI+DQpmb3J3YXJkaW5nIG1vZGUgd2l0aGluIGEgKip0cmFuc3BvcnQgZW50aXR5KiouIEcuODAw IGFtZW5kbWVudCAxIGhhcyBmaW5hbGx5PGJyPg0KcmVpbnRyb2R1Y2VkIHRoaXMgdHJhbnNwb3J0 IGVudGl0eSBpbnRvIEcuODAwLiBCZXNpZGVzIHRoYXQsIGl0IGFsc288YnI+DQppbnRyb2R1Y2Vk IHRoZSAqKmRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24qKjo8YnI+DQo8YnI+DQpbRy44MDAgYW0x XSAmcXVvdDtBIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24gaXMgYSB0cmFuc3BvcnQgZW50aXR5 IHRoYXQ8YnI+DQp0cmFuc2ZlcnMgaW5mb3JtYXRpb24gYmVsb25naW5nIHRvIG11bHRpcGxlIGNv bW11bmljYXRpb25zIGJldHdlZW4gcG9ydHM8YnI+DQphY3Jvc3MgYSBzdWJuZXR3b3JrLiAmbHQ7 Li4mZ3Q7IEluIGEgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBtZXNzYWdlDQpjb250ZW50czxi cj4NCmFyZSBpbnRlcnByZXRlZCB0byBpZGVudGlmeSAoc2V0cyBvZikgY29tbXVuaWNhdGlvbnMg d2hpY2ggcmVjZWl2ZSBkaWZmZXJlbnQ8YnI+DQp0cmVhdG1lbnQuICZuYnNwO1RoZSBzZXRzIG9m IGNvbW11bmljYXRpb25zIG1heSBiZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZTxicj4NCmZvcndhcmRp bmcgaWRlbnRpZmllciBvciBvdGhlciBsYXllciBpbmZvcm1hdGlvbi4gJm5ic3A7T3JkZXIgaXMg bm90IG5lY2Vzc2FyaWx5PGJyPg0KcHJlc2VydmVkIGJldHdlZW4gbWVzc2FnZXMgYmVsb25naW5n IHRvIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgcmVjZWl2aW5nPGJyPg0KZGlmZmVyZW50IHRyZWF0 bWVudC4gJm5ic3A7U2V0cyBvZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgaWRlbnRpZmllZCBmb3IN CnB1cnBvc2VzPGJyPg0Kc3VjaCBhcyB0cmFmZmljIGNvbmRpdGlvbmluZyBvciBwcmVzZXJ2aW5n IGNvbW11bmljYXRpb24gbWVzc2FnZSBvcmRlci4mcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQpFdGhl cm5ldCBWTEFOcyBhcmUgaW4gdGVybXMgb2YgRy44MDAgJnF1b3Q7ZGlmZmVyZW50aWF0ZWQgY29u bmVjdGlvbnMmcXVvdDsuPGJyPg0KRXRoZXJuZXQ8YnI+DQpBSVMgcHJvdmlkZXMgQUlTIHdpdGhp biB0aGUgc2NvcGUgb2Ygc3VjaCAmcXVvdDtkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uJnF1b3Q7 Ljxicj4NCklmPGJyPg0KeW91IGFwcGx5IHRoaXMgdG8gbXkgcHJvcG9zZWQgUFROIGxheWVyIHN0 YWNrLCB0aGVuIHRoZSBFVkMgbGF5ZXIgdG9wb2xvZ3k8YnI+DQp3aWxsIGNvbnNpc3RzIG9mIEVW QyBsaW5rcyBzdXBwb3J0ZWQgYnkgTVBMUy1UUCwgRXRoZXJuZXQsIFBCQi1URSBhbmQgUC1PVE48 YnI+DQpWUCB0cmFpbHMgaW5zaWRlIG1ldHJvIGFuZCBjb3JlIGRvbWFpbnMgaW50ZXJjb25uZWN0 aW5nIEVWQyBtYXRyaWNlcy48YnI+DQpXaGVuPGJyPg0Kb25lIG9mIHRob3NlIEVWQyBsaW5rcyBp cyBpbnRlcnJ1cHRlZCwgZS5nLiBpbiB0aGUgY29yZSBiZXR3ZWVuIG1ldHJvIDENCmFuZDxicj4N Cm1ldHJvIDQgKHNlZSBhdHRhY2hlZCBzbGlkZSksIHRoZW4gdGhlIEVWQyBkaWZmZXJlbnRpYXRl ZCBjb25uZWN0aW9uIHRoYXQNCmlzPGJyPg0KcHJlc2VudCBvbiB0aGlzIGxpbmsgd2lsbCBiZSBp bnRlcnJ1cHRlZC4gQXQgdGhlIEVWQyBzd2l0Y2gvYnJpZGdlIG5vZGUNCmluPGJyPg0KbWV0cm8g NCB0aGlzIGludGVycnVwdGlvbiBpcyBub3RpY2VkIGFuZCBFVkMtQUlTIGlzIGluc2VydGVkIGlu IHRoZTxicj4NCmRvd25zdHJlYW0gZGlyZWN0aW9uIHRvIHN1cHByZXNzIHRoZSBFVkMtTE9DIGFs YXJtcyBhdCBFVkMgZW5kcG9pbnRzIEQ0DQphbmQ8YnI+DQpENS48YnI+DQo8YnI+DQpUaGUgRVZD LUFJUyAoaS5lLiBFdGhlcm5ldCBBSVMpIGZyYW1lIGhhcyBhIHJlc2VydmVkIG11bHRpY2FzdCBh ZGRyZXNzLDxicj4NCndoaWNoIGd1YXJhbnRlZXMgdGhhdCB0aGUgQUlTIGlzIGJyb2FkY2FzdCB0 byB0aGUgZW5kcG9pbnRzIG9mIHRoZSBFVkMuPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHRoYXQgaXQg aXMgdGltZSBmb3IgeW91IHRvIGFkYXB0IHlvdXIgdmlldyBvbiBjbyBhbmQgY2wgbW9kZXMNCmFu ZDxicj4NCnJlbGF0ZSBpdCB0byB0aGUgZm9yd2FyZGluZyBtb2RlICoqSU5TSURFKiogYSB0cmFu c3BvcnQgZW50aXR5LiA8YnI+DQo8YnI+DQpXaGF0IHdlIGtub3cgYXMgdGhlIGludGVybmV0IGlz IGVzc2VudGlhbGx5IGFuICZxdW90O0lQIGRpZmZlcmVudGlhdGVkPGJyPg0KY29ubmVjdGlvbiZx dW90OyB3aXRoIGEgYmlsbGlvbiBvciBtb3JlIHBvcnRzLjxicj4NCldoYXQgd2Uga25vdyBhcyBh biBJUCBWUE4gaXMgZXNzZW50aWFsbHkgYW4gJnF1b3Q7SVAgZGlmZmVyZW50aWF0ZWQgY29ubmVj dGlvbiZxdW90Ozxicj4NCndpdGggZS5nLiBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiBlLmcu IDIgdG8gMTAwMCkuPGJyPg0KV2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMgZXNz ZW50aWFsbHkgYW4gJnF1b3Q7RXRoZXJuZXQgZGlmZmVyZW50aWF0ZWQ8YnI+DQpjb25uZWN0aW9u JnF1b3Q7IHdpdGggbiBwb3J0cyAobiBpbiB0aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEwMDApLjxi cj4NCldoYXQgd2Uga25vdyBhcyBhIHAycCBNUExTIEUtTFNQIGlzIGVzc2VudGlhbGx5IGFuICZx dW90O01QTFMgZGlmZmVyZW50aWF0ZWQ8YnI+DQpjb25uZWN0aW9uJnF1b3Q7IHdpdGggMiBwb3J0 cy48YnI+DQpXaGF0IHdlIGtub3cgYXMgYSBwMnAgU0RIIFZDLW4gaXMgYSAmcXVvdDtTREggVkMt biBjb25uZWN0aW9uJnF1b3Q7IHdpdGgNCjIgcG9ydHMuPGJyPg0KPGJyPg0KVHJhbnNwb3J0IG5l dHdvcmsgT0FNIGFwcGxpZXMgdG8gdHJhbnNwb3J0IGVudGl0aWVzLCB3aGljaCBhcmUgKGluIHRl cm1zDQpvZjxicj4NCkcuODAwIGFtMSkgY29ubmVjdGlvbnMgYW5kIGRpZmZlcmVudGlhdGVkIGNv bm5lY3Rpb25zLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KTWFhcnRlbjxicj4NCjxicj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbmVpbC4yLmhhcnJpc29uQGJ0LmNv bSBbbWFpbHRvOm5laWwuMi5oYXJyaXNvbkBidC5jb21dPGJyPg0KU2VudDogdnJpamRhZyAxNyBh cHJpbCAyMDA5IDIyOjAwPGJyPg0KVG86IEpvaG4uRS5EcmFrZTJAYm9laW5nLmNvbTsgSXRhbG8u QnVzaUBhbGNhdGVsLWx1Y2VudC5pdDs8YnI+DQpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTsgbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb208YnI+DQpDYzogbXBscy10cEBpZXRmLm9y Zzxicj4NClN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxicj4NCjxicj4NCkpvaG4sICZuYnNwO1RoYW5rcyB0 aGlzIGlzIGEgZ3JlYXQgcGxhdGZvcm0gdG8gZXhwbGFpbiB3aHkgT0FNIGZvciB0aGUNCjMgbmV0 d29yazxicj4NCm1vZGVzIG5lZWRzIHRvIGJlIGRpZmZlcmVudC4gJm5ic3A7SSBhbSBnZXR0aW5n IGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xrcw0KdHJ5aW5nPGJyPg0KdG8gbWFrZSBhbGwgMyBuZXR3 b3JrIG1vZGVzIGxvb2sgYWxpa2UgKGFuZCB0aGVuLCBldmVuIHdvcnNlLCBpbnRlcndvcmsNCnRo ZW08YnI+DQphcyBhcyBwZWVycy4uLmVzcCB3aGVuIG5vdCBub3QgdG9wLW9mLXN0YWNrPGJyPg0K bmV0d29ya3MuLi5JIG1lYW4gaG93IHNpbGx5IGNhbiB3ZSBnZXQ/KS4gJm5ic3A7IEkgYW0gZXZl biBtb3JlIGZydXN0cmF0ZWQNCmJ5PGJyPg0KdGhlIGZhY3QgdGhvc2UgcGVkZGxpbmcgdGhpcyBG VUQgb25seSBldmVyIHNlZW0gdG8gY29uc2lkZXIgT0FNIGFuZCBmb3JnZXQ8YnI+DQphbGwgb3Ro ZXIgRFAvQ1AvTVAgY29tcG9uZW50cyAoZXNwIHRvcC1vZi1zdGFjayBtZXNzYWdlL2ZpbGUvc3Ry ZWFtPGJyPg0KYXBwbGljYXRpb24gYWRhcHRhdGlvbnMpLiAmbmJzcDtIb3cgd3JvbmcgY2FuIHRo aXMgZ2V0ISA8YnI+DQo8YnI+DQpJbiB0aGUgY28gbW9kZXMgYSAqY29ubmVjdGlvbiogaXMgYSB2 ZXJ5IHNwZWNpZmljIGFuZCAqY29uc3RyYWluaW5nKjxicj4NCmNvbnN0cnVjdC4uLi4uSSBhbSBh c3N1bWluZyBoZXJlIHdlIHJlc3BlY3QgdGhlIHJ1bGVzIG9mIGEgY29ubmVjdGlvbiAoaWU8YnI+ DQpzaW5nbGUgc291cmNlKSB0aG91Z2ggc29tZSBmb2xrcyBkb24ndCBldmVuIGJvdGhlciB0byBy ZXNwZWN0IHRoaXMsIGFuZA0KdGhpczxicj4NCmlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBh bGwga25vdyB3aGF0IHByb2JsZW1zIG11bHRpcGxlLXNvdXJjZTxicj4NCmNvbnN0cnVjdHMgY2Fu IGNhdXNlIChmcm9tIExEUC9QSFAuLi4uZXJnbyBNUExTLVRQKS48YnI+DQo8YnI+DQpXaGVuIHdl IGhhdmUgYSBjb25uZWN0aW9uIHRoaXMgcmVzdHJpY3RzICphbGwqIERQIChpZSB0cmFmZmljIGFu ZCBPQU0pDQp0bzxicj4NCnN0YXkgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIGNvbm5lY3Rpb24u ICZuYnNwO1doaWNoIGlzIGZpbmUgdW5kZXIgZGVmZWN0LWZyZWU8YnI+DQpjb25kaXRpb25zLCBi dXQgaWYgd2UgaGF2ZSBsZWFraW5nIHRyYWZmaWMgdGhlbiB0aGUgY29uc3RyYWluaW5nIG5hdHVy ZQ0Kb2Y8YnI+DQp0aGUgY29ubmVjdGlvbiBjb25zdHJ1Y3QgaXMgYnJva2VuLiAmbmJzcDtJbiBh IG51dHNoZWxsIHdoYXQgdGhpcyBtZWFucw0KaXMgdGhhdDxicj4NCk9BTSB0aGF0IGlzIG9mIGEg cmVxdWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fubm90IGJlIHRydXN0ZWQgaW4gY28gbW9kZTxicj4N Cm5ldHdvcmtzIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3RzLi4uLi5pbmRlZWQsIHdoeSBz aG91bGQgYSBsZWFraW5nDQpEUDxicj4NCmhhdmUgYSBzeW1tZXRyaWMgZ28vcmV0dXJuIGRlZmVj dCBiZWhhdmlvdXI/Li4uLnZlcnkgbGlrZWx5IGl0IHdvbid0Ljxicj4NClNvPGJyPg0Kd2hpbHN0 IHJlcXVlc3QvcmVzcG9uc2UgT0FNIGlzIHJpZ2h0IGZvciB0aGUgY2wgbW9kZSBpdCBpcyBub3Qg cmlnaHQgZm9yDQp0aGU8YnI+DQpjbyBtb2RlIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZlY3Qg Y29uZGl0aW9ucy48YnI+DQo8YnI+DQpNb3JlIGdlbmVyYWxseSB0aGUgMyBtb2RlcyBhcmUgZGlm ZmVyZW50IGFuZCBub3QganVzdCBpbiBPQU08YnI+DQpyZXF1aXJlbWVudHMuLi4uYnV0IEFJUy9G REkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZvdXIhLi4uYXQgbGVhc3Q8YnI+DQpJRUVF IGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRoZXJuZXQgZXZlbiB0aG91Z2gg aXQgcmVtYWlucw0KaW48YnI+DQpZLjE3MzEuICZuYnNwO0FuZCB3aGljaCBpcyB3aHkgSSBvZnRl biB0cm90LW91dCB0aGUgcmF0aGVyIHNpbGx5ICh0byBoYXZlDQp0byBzYXk8YnI+DQp0aGlzKSBv YnNlcnZhdGlvbiB0aGF0IGlmIElQIChjbCBtb2RlKSBjb3VsZCBkbyBpdCBhbGwgdGhlbiB3aHkg aGF2ZSBJRVRGPGJyPg0KZm91bmQgaXQgbmVjZXNzYXJ5IHRvIGNyZWF0ZSBNUExTIChjby1wcykg YW5kIEdNUExTIChDUCBmb3IgY28tY3MpLiAmbmJzcDtUaGU8YnI+DQphbnN3ZXIgbGllcyBpbiB0 aGUgcGh5c2ljcy4uLmFuZCBHLjgwMCBhdHRlbXB0cyB0byBleHBsYWluIHRoYXQ8YnI+DQpwaHlz aWNzLi4uLkcuODA1IGRvZXMgbm90Ljxicj4NCjxicj4NClNvLCB0aGUgMyBtb2RlcyBhcmUgZGlm ZmVyZW50Li4ucGxlYXNlIGFjY2VwdC9yZWpvaWNlIGluIHRoaXMgZmFjdCBhcyB0aGV5PGJyPg0K YWxsIG9mZmVyIHNvbWV0aGluZyBkaWZmZXJlbnQvaW1wb3J0YW50LiAmbmJzcDtCdXQgZG8gbm90 IGJlIGhvb2R3aW5rZWQNCmJ5IHRob3NlPGJyPg0Kd2hvIHBlZGRsZSBhIHN0b3J5IHRoYXQgdGhh dCB0cmllcyB0byBtYWtlIHRoZSBPQU0gb2YgdGhlIDMgbW9kZXMgdGhlIHNhbWUuDQo8YnI+DQo8 YnI+DQpyZWdhcmRzLCBOZWlsIDxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsg W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9o biBFPGJyPg0KJmd0OyBTZW50OiAxNyBBcHJpbCAyMDA5IDIwOjAyPGJyPg0KJmd0OyBUbzogQlVT SSBJVEFMTzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vyczxicj4NCiZndDsg Q2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIDxicj4NCiZndDsgcmVxdWlyZW1l bnRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0YWxvLDxicj4NCiZndDsgPGJyPg0KJmd0OyBBcyBk ZXNjcmliZWQgaW4gdGhlIE1QTFMgVFAgT0FNIFJlcXVpcmVtZW50cyBJLUQsIHZpcnR1YWxseSBh bGwgb2YNCnRoZTxicj4NCjxicj4NCiZndDsgT0FNIGZ1bmN0aW9ucyByZXF1aXJlIGEgcmV0dXJu IHBhdGgsIGFuZCBpbiB0aGUgYWJzZW5jZSBvZiBhIHJldHVybg0KPGJyPg0KJmd0OyBwYXRoIHRo ZXkgYXJlIGRpc2FibGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBcyBkZXNjcmliZWQgaW4gRGF2 aWQgU2luaWNyb3BlJ3MgbWVldGluZyBtaW51dGVzIDxicj4NCiZndDsgKGh0dHA6Ly93aWtpLnRv b2xzLmlldGYub3JnL21pc2MvbXBscy1pbnRlcm9wL2F0dGFjaG1lbnQvd2lraS88YnI+DQomZ3Q7 IG1lZXRpbmctbm88YnI+DQomZ3Q7IHRlcy8yMDA4MTAxNS5tcGxzLWludGVyb3AtZHQtbm90ZXMu emlwKSwgaWYgSVAgYWRkcmVzc2luZyBpcyB1c2VkLA0KYW4gPGJyPg0KJmd0OyBNUExTIFRQIG5l dHdvcmsgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBnZXR0aW5nIElQIHBhY2tldHMgZnJvbSA8YnI+ DQomZ3Q7IGRlc3RpbmF0aW9uIHRvIHNvdXJjZTsgbmVpdGhlciB0aGUgbWludXRlcyBub3IgSSBz dGlwdWxhdGUgdGhhdCBhDQo8YnI+DQomZ3Q7IGNvbnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNl ZCB0byBpbnN0YW50aWF0ZSB0aGlzIGZvcndhcmRpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFz IGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgcmV0dXJuIHBhdGggZm9yIHVuaWRpcmVjdGlvbmFsIExT UHMgY291bGQNCmJlPGJyPg0KPGJyPg0KJmd0OyBjaGFyYXRlcml6ZWQgYXMgdGhlIGVsZXBoYW50 IGluIHRoZSByb29tLiAmbmJzcDtJbiB0aGUgTVBMUyBUUCBPQU0NCjxicj4NCiZndDsgRnJhbWV3 b3JrIEktRCwgdW5pY2FzdCBMU1BzIGFyZSBvbmx5IG1lbnRpb25lZCB0aHJlZSB0aW1lcyBhbmQg cmV0dXJuDQo8YnI+DQomZ3Q7IHBhdGhzIG5vdCBhdCBhbGwuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoYW5rcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSm9objxicj4NCiZndDsgJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBCVVNJIElUQUxPIFttYWls dG86SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdF08YnI+DQomZ3Q7ICZndDsgU2VudDogRnJp ZGF5LCBBcHJpbCAxNywgMjAwOSAxOjU5IEFNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBEcmFrZSwgSm9o biBFOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzPGJyPg0KJmd0OyAmZ3Q7 IENjOiBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQo8YnI+DQomZ3Q7ICZn dDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBKb2huLDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBtaWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVt ZW50IG9mIE1QTFMtVFAgYmVpbmcgY2FwYWJsZSBvZg0KPGJyPg0KJmd0OyAmZ3Q7IHNlbmRpbmcg cmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQcy48YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3QgYmVs b25nIHRvIHRoZSBmaXJzdCBzZXQgb2YgcmVxdWlyZW1lbnRzDQo8YnI+DQomZ3Q7ICZndDsgSVRV LVQgaXMgZXhwZWN0aW5nIHRvIGJlIG1ldCBieSBPY3RvYmVyLjxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgSG93ZXZlciwgSSB0aGluayB0aGlzIGluIGEgcG90ZW50aWFsIGludGVyZXN0 aW5nIGFkZGl0aW9uYWwgPGJyPg0KJmd0OyAmZ3Q7IHJlcXVpcmVtZW50IHRvIGJlIHRha2VuIGlu dG8gYWNjb3VudCAoYXQgd29yc3QgaW4gYTxicj4NCiZndDsgc3Vic2VxdWVudCBwaGFzZSkuPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVu dCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVyc3VzIG90aGVyDQo8YnI+DQomZ3Q7ICZndDsgbW9y ZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJpbGl0eSB0byB3b3JrIHcv bw0KSVAgPGJyPg0KJmd0OyAmZ3Q7IGZvcndhcmRpbmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8g Y29udGludWUgdG8gbW9uaXRvciB0aGUgZGF0YQ0KPGJyPg0KJmd0OyAmZ3Q7IHBsYW5lIGFsc28g aW4gY2FzZSBvZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wgb3IgbWFuYWdlbWVudA0K PGJyPg0KJmd0OyAmZ3Q7IHBsYW5lKS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkg YW0gb3BlbiB0byBkaXNjdXNzIGl0IGJ1dCBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdodCB0aW1l IGJlY2F1c2UNCjxicj4NCiZndDsgJmd0OyBJIHdpc2ggdG8gYXZvaWQgZGVsYXlpbmcgdGhlIGZp cnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24gc29sdXRpb24uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBUaGFua3MsIEl0YWxvPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogbXBs cy10cC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgW21haWx0bzptcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9obg0KRTxicj4NCiZndDsg Jmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA4OjAwIFBNPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnM8YnI+ DQomZ3Q7ICZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7 IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9y dA0KcGF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBdCB0aGUgbWVldGluZyBsYXN0IGZhbGwgYXQgSnVu aXBlciBpbiBNYXNzYWNodXNldHRzLCBJPGJyPg0KJmd0OyAmZ3Q7IHRoaW5rIGl0IHdhczxicj4N CiZndDsgJmd0OyAmZ3Q7IGFncmVlZCB0aGF0IGFuIE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBo YXZlIGEgZm9yd2FyZGluZzxicj4NCiZndDsgJmd0OyBjYXBhYmlsaXR5PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgZm9yIG1hbmFnZW1lbnQsIGNvbnRyb2wsIGFuZCBPQU0gcGFja2V0cyAoZS5nLiwgc2Vu ZGluZzxicj4NCiZndDsgJmd0OyByZXBsaWVzIHRvIE9BTTxicj4NCiZndDsgJmd0OyAmZ3Q7IHJl cXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMpIGV2ZW4gaWYgaXQgZG9lcyBub3Q8 YnI+DQomZ3Q7ICZndDsgaGF2ZSBhbiBJUDxicj4NCiZndDsgJmd0OyAmZ3Q7IGZvcndhcmRpbmcg ZGF0YSBwbGFuZS48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9t OiBBbGV4YW5kZXIgVmFpbnNodGVpbjxicj4NCiZndDsgJmd0OyAmZ3Q7IFttYWlsdG86QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50 OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgOTo1NyBBTTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgVG86IE1hYXJ0ZW4gVmlzc2Vyczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2M6IG1wbHMt dHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydA0KcGF0aCA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBNYWFydGVuLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSXQg c2VlbXMgdGhhdCB5b3UndmUganVzdCAoaW1wbGljaXRseSBhbmQsIHByb2JhYmx5LDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgaW5hZHZlcnRlbnRseSkgc3RhdGVkIHRoZSBmb2xsb3dpbmc6PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO01Q TFMtVFAgT0FNIHdpbGwgbm90IGV2ZXIgc3VwcG9ydCBNSVAgbG9vcGJhY2sgZnVuY3Rpb248YnI+ DQomZ3Q7ICZndDsgKGFuZCBmYXVsdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbG9jYWxpemF0 aW9uIHdoaWNoIHJlcXVpcmVzIHRoaXMgZnVuY3Rpb24gKSBmb3I8YnI+DQomZ3Q7ICZndDsgdW5p ZGlyZWN0aW9uYWwgUDJNUDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYW5kIFAyUCBwYXRocy48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYgdGhp cyBzdGF0ZW1lbnQgaXMgY29ycmVjdCwgdGhpcyAoSU1ITyBhbmQgRldJVyk8YnI+DQomZ3Q7IHJh aXNlcyBhIHZhbGlkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBxdWVzdGlvbjo8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7SXMgTVBMUy1U UCBhbiBhcHByb3ByaWF0ZSBzb2x1dGlvbiBmb3IgdGhlc2U8YnI+DQomZ3Q7IHR5cGVzIG9mIHRy YW5zcG9ydDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcGF0aHM/PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZvciB0aGUgcmVmZXJlbmNlLCBJUC9N UExTIHByb3ZpZGVzIHRoaXMga2luZCBvZjxicj4NCiZndDsgJmd0OyBmdW5jdGlvbmFsaXR5IHRv ZGF5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBmb3IgKHVuaWRpcmVjdGlvbmFsIC0gYnV0IGl0 IGRvZXMgbm90IGtub3cgYW55IG90aGVyPGJyPg0KJmd0OyAmZ3Q7IHR5cGUpIFAyUCBMU1BzPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhcyBkZXNjcmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMg ZXh0ZW5zaW9uIHRvIFAyTVANCkxTUHMgc2VlbXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBl YXN5Li4uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Nhc2hhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmcgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ108YnI+DQomZ3Q7ICZndDsgT24gQmVoYWxmPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPZiBNYWFydGVuIFZpc3NlcnMgW21hYXJ0ZW4udmlzc2Vy c0BodWF3ZWkuY29tXTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFw cmlsIDE2LCAyMDA5IDM6MjQgUE08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiAnQWRyaWFu IEZhcnJlbCc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCnBhdGggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBy ZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgQWRyaWFuLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7Jmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBpbnRlcm1lZGlhdGUgbm9kZXMNCihpbmNs dWRpbmcgTUVQcywgTUlQcyBhbmQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG90aGVyIGludGVy bmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpDQpvZiBhIGNvLXJvdXRlZDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBhdGggYXQgZWFjaCAoc3ViLSlsYXll cg0KTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJk DQphbmQgdGhlIGJhY2t3YXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9m IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHRyYW5zcG9ydCBwYXRoLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmx0 O2VuZCBxdW90ZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8gd2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJl cXVpcmVtZW50Lg0KVGhhdDxicj4NCiZndDsgJmd0OyAmZ3Q7IGlzLCB0aGVyZSBpczxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJv bSBhIGJsYWNrIGJveA0KcG9pbnQgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyB2aWV3IHRoYXQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMg cmVxdWlyZW1lbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gSXQgaXMgdmVyeSBtdWNo PGJyPg0KJmd0OyBvYnNlcnZhYmxlIGlmPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIHJl cXVpcmVtZW50IGlzIG1ldCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZpZXcuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBM b29wYmFjayB3aGVuDQp0aGVyZSBpcyBhIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoZSBNUExTLVRQDQpMQk0gcGFja2V0 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVjZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUg cmV0dXJuZWQgKGFzIExCUjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcGFja2V0KSB0byB0aGUg b3JpZ2luYXRpbmcgTUVQIGZ1bmN0aW9uIHZpYSB0aGUgb3RoZXI8YnI+DQomZ3Q7ICZndDsgZGly ZWN0aW9uIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoaXMgb3RoZXI8YnI+DQomZ3Q7IGRpcmVjdGlvbjxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgd291bGQgbm90IGJlIGF2YWlsYWJsZSBpbiBhbiBhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBh dGguLi4gYW5kIHRodXMgdGhlIGxvb3BiYWNrIHRlc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyB3b3Vs ZCBmYWlsLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBTaW1pbGFybHksIHdoZW4gd2UgaGF2ZSB0byBhcHBseSBUQ00gTUVQcyB0byBtb25pdG9yDQph PGJyPg0KJmd0OyAmZ3Q7IHNlZ21lbnQsIHRoZW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRo aXMgaXMgcG9zc2libGUgaW4gYSBjby1yb3V0ZWQgYmlkaXIgdHJhbnNwb3J0IHBhdGg8YnI+DQom Z3Q7IGJ1dCBub3QgaW4gYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYXNzb2NpYXRlZCBiaWRp ciB0cmFuc3BvcnQgcGF0aC4gSW4gdGhlIGZpcnN0IGNhc2UNCnRoZSBUQ00gTUVQIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucyBhcmUgY28tbG9jYXRl ZCBhbmQgY2FuPGJyPg0KJmd0OyBleGNoYW5nZSB3aGF0IGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBjYWxsZWQgJnF1b3Q7cmVtb3RlIGluZm9ybWF0aW9uJnF1b3Q7IHdoaWNoIGlzIG5lY2Vz c2FyeQ0KZm9yIHBlcmZvcm1hbmNlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbW9uaXRvcmlu Zy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgVENNIE1F UCBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zPGJyPg0KJmd0OyAmZ3Q7IGFyZSBpbiBlLmcuIDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZGlmZmVyZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIGFu ZCBUQ00gd291bGQgbm90IGJlDQphYmxlPGJyPg0KJmd0OyAmZ3Q7IHRvIHByb3ZpZGU8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IHBlcmZvcm1hbmNlIG1vbml0b3JpbmcuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGVudGlyZXR5IG9m IHRoZSBicmFja2V0dGVkIHRleHQgJnF1b3Q7KGluY2x1ZGluZw0KTUVQcyw8YnI+DQomZ3Q7ICZn dDsgJmd0OyBNSVBzIGFuZCBvdGhlcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50ZXJuYWw8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSZx dW90OyBzaG91bGQgYmUgZGVsZXRlZC4NCkl0IGRvZXMgbm90PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBhZGQgdG8gJnF1b3Q7VGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGludGVy bWVkaWF0ZSBub2Rlcy4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBjb3JyZWN0LiBUaGlzIHRl eHQgbXVzdCBub3QNCmJlPGJyPg0KJmd0OyAmZ3Q7IGRlbGV0ZWQgYXQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGFsbC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSBhbSBxdWl0ZSBmZWQgdXAgYWJvdXQgdGhpcyBwZXJz aXN0ZW50PGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW5zaXN0ZW5jZSBvbiB0aGU8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGluY2x1c2lvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBvZiAm cXVvdDtUYW5kZW0gQ29ubmVjdGlvbi4mcXVvdDsgVGhlIGRlZmluaXRpb24NCndpdGhpbiB0aGUg SVRVLVQgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgdGVybTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcG9vcmx5PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUgbW9u aXRvcmluZyBvZiBhIHBhdGgNCnRoYXQgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhcmFs bGVsIChpLmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0YW5kZW0pPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRl ZmluaXRpb24NCm9mIFRDPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzZWVtcyB0byBiZSBhdDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdmFyaWFuY2UsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGFuZCB3b3VsZCBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLjxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIGRvbid0IHVu ZGVyc3RhbmQgd2hlcmUgeW91ciBpbnRlcnByZXRhdGlvbiBvZiB0YW5kZW08YnI+DQomZ3Q7ICZn dDsgY29ubmVjdGlvbiBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZGVzY3JpYmVkIGluIElU VS1UIHJlY29tbWVuZGF0aW9ucy4gSS5lLiAmcXVvdDtmcm9tDQp0aGU8YnI+DQomZ3Q7ICZndDsg bW9uaXRvcmluZyBvZiBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRoIHRoYXQgaXMgcGFy YWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoDQpiZWluZyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IG1vbml0b3JlZC4mcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIGEgJnF1b3Q7bmV0d29yayBjb25uZWN0 aW9uJnF1b3Q7IGFuZCB0aGlzDQpuZXR3b3JrPGJyPg0KJmd0OyAmZ3Q7IGNvbm5lY3Rpb24gaXMg YSBzZXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9mIGludGVyY29ubmVjdGVkICZxdW90O2xp bmsgY29ubmVjdGlvbnMmcXVvdDsgYW5kDQomcXVvdDttYXRyaXg8YnI+DQomZ3Q7IGNvbm5lY3Rp b25zJnF1b3Q7LiBBPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzdWJzZXQgb2YgdGhvc2UgaW50 ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQNCm1hdHJpeCA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGNvbm5lY3Rpb25zIGNhbiBiZSBtb25pdG9yZWQgYW5kIGlzIHRoZW4gcmVmZXJy ZWQgdG8NCmFzPGJyPg0KJmd0OyBhICZxdW90O3RhbmRlbTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgY29ubmVjdGlvbiZxdW90Oy4gVGhlcmUgaXMgbm8gJnF1b3Q7cGF0aCB0aGF0IGlzIHBhcmFs bGVsDQp0byB0aGU8YnI+DQomZ3Q7ICZndDsgZGF0YSBwYXRoJnF1b3Q7LiA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG9ubHkgYWRkaXRpb25hbCBPQU0gaW5zZXJ0ZWQgaW5zaWRl IHRoZSBkYXRhPGJyPg0KJmd0OyBwYXRoIGJ5IHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg VENNIE1FUF9TbyBmdW5jdGlvbiBhbmQgdGhpcyBPQU0gaXMgZXh0cmFjdGVkIGZyb20NCnRoZTxi cj4NCiZndDsgJmd0OyBkYXRhIHBhdGggYnk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBU Q00gTUVQX1NrIGZ1bmN0aW9uLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgTWFhcnRlbjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWRyaWFuDQpGYXJyZWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IGRvbmRlcmRh ZyAxNiBhcHJpbCAyMDA5IDExOjU5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW47IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBDYzogQlVTSSBJVEFMTzsgbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1l bnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhp IFNhc2hhLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFVuZm9ydHVuYXRlbHkgSSBjYW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRl bWVudDo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJmx0O3F1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsgJm5ic3A7IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgaGFyZHdhcmUsDQpjby1yb3V0ZWQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIExTUHM8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRl ZA0KYmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7 ZW5kIHF1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBUaGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVj dCwgd2VyZQ0KaXQgbm90IGZvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgUmVxdWlyZW1lbnQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMzQgaW4gdGhlIGxhdGVzdCBNUExTLVRQIHJl cXVpcmVtZW50cyBkcmFmdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBPSy4gR290IGl0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBCdXQgd2hhdCBpcyB0aGlzIGRvaW5nIGluIHRoZSBkYXRhIHBsYW5l IHJlcXVpcmVtZW50cw0Kc2VjdGlvbj88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgSW4gZmFjdCwgd2hhdCBpcyB0aGlzIHJlcXVpcmVtZW50IGFjdHVh bGx5IHNheWluZz88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbHQ7cXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7VGhlIGludGVybWVkaWF0ZSBub2RlcyAoaW5jbHVkaW5nDQpNRVBz LCBNSVBzIGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7IG90aGVyIGludGVybmFsPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZ1bmN0aW9ucyBhcyBhcHBy b3ByaWF0ZSkNCm9mIGEgY28tcm91dGVkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXINCk1VU1QgYmUgYXdhcmUgb2YgdGhl IHBhaXJpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkDQphbmQgdGhlIGJhY2t3YXJkPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0IHBhdGguPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlzIGEg ZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gVGhhdDxicj4NCiZndDsgJmd0OyBpcywgdGhlcmUgaXM8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICpub3RoaW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBm cm9tIGEgYmxhY2sgYm94IHBvaW50DQpvZjxicj4NCiZndDsgJmd0OyB2aWV3IHRoYXQ8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlzIHJlcXVpcmVt ZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBU aGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1lZCB0aGF0IHRoaXMgcmVxdWlyZW1lbnQNCmlzIG1l dCBieSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZ3VyaW5nIHNvbWUgZGF0YSBwbGFu ZSBkYXRhYmFzZSBjb21wb25lbnQgdGhyb3VnaA0KdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgbWFuYWdlbWVudCBwbGFuZS4gVGhlIGRhdGFiYXNlIGNvbXBvbmVudCBpcyBub3QgdXNlZDxi cj4NCiZndDsgZm9yIGFueXRoaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBleGNlcHQgdG8g c2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50IGZvciAmcXVvdDthd2FyZW5lc3MmcXVvdDsuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJlbiEgQ2FuIHdl IHBsZWFzZSB0cnkgdG8gcmV3cml0ZSB0aGlzIHJlcXVpcmVtZW50DQppbiB0ZXJtcyBvZiA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlaGF2aW9yPzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgUmVxdWlyZW1l bnQgMzQgaXMgdGhlIE9OTFkgaXRlbQ0KaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBs aXN0IHRoYXQgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgc3BlY2lmaWMgZm9yIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChUaGUNCnBhaXJpbmc8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhdCBl bmQgcG9pbnRzIGZvciBjby1yb3V0ZWQgYW5kIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbDxicj4N CiZndDsgJmd0OyAmZ3Q7IHBhdGhzIGFyZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBl eGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhleSBhcHBlYXIgaW4gdHdvIGRpZmZlcmVudDxicj4N CiZndDsgJmd0OyAmZ3Q7IGl0ZW1zIGluIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyByZXF1aXJlbWVudHMnIGxpc3QpLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbiBv dGhlciB3b3Jkcywgd2l0aG91dCBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uDQpvZjxicj4NCiZn dDsgY28tcm91dGVkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwg cGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YQ0KcGxhbmUgY29udGVudC48YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIHNv bWV3aGF0IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCZxdW90O290aGVyDQppbnRl cm5hbCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZnVuY3Rpb25zIGFzIGFwcHJvcHJp YXRlJnF1b3Q7KSBjcmVhdGVzIGEgc3VzcGljaW9uDQp0aGF0IEhXPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBzdXBwb3J0IG9mIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYWly aW5nIGF3YXJlbmVzcyBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIgdG8NCmNvbXBseSB3aXRoIGl0 Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUg ZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAmcXVvdDsoaW5jbHVkaW5nDQpNRVBzLDxi cj4NCiZndDsgJmd0OyBNSVBzIGFuZCBvdGhlcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50 ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSZxdW90OyBzaG91bGQgYmUNCmRlbGV0ZWQu IEl0PGJyPg0KJmd0OyAmZ3Q7IGRvZXMgbm90PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhZGQg dG8gJnF1b3Q7VGhlIGludGVybWVkaWF0ZSBub2Rlcy4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZm9sbG93aW5nIHRleHQg aW4gdGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzDQpzdXNwaWNpb246PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IFRhbmRlbSBDb25uZWN0aW9uOiBB IHRhbmRlbSBjb25uZWN0aW9uDQppcyBhbjxicj4NCiZndDsgJmd0OyBhcmJpdHJhcnkgcGFydCBv ZiBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyB0cmFuc3BvcnQgcGF0aCB0 aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYQ0KT0FNKTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg aW5kZXBlbmRlbnRseSBmcm9tIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsgZW5kLXRvLWVuZCBtb25pdG9yaW5nIChPQU0pLiAmbmJzcDtJdCBtYXkNCmJlIGEgbW9uaXRv cmVkPGJyPg0KJmd0OyAmZ3Q7IHNlZ21lbnQgb3IgYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgbW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBzZWdtZW50IG9mIGEgdHJhbnNwb3J0 DQpwYXRoLiAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgVGhlIHRhbmRlbTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3 YXJkaW5nDQplbmdpbmUocykgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBub2RlKHMp PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBhdCB0aGUgZWRnZShzKSBvZiB0 aGUgc2VnbWVudCBvciBjb25jYXRlbmF0ZWQNCnNlZ21lbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFjdHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0 aGlzIHBlcnNpc3RlbnQ8YnI+DQomZ3Q7ICZndDsgaW5zaXN0ZW5jZSBvbiB0aGU8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGluY2x1c2lvbiBvZiAmcXVvdDtUYW5kZW0gQ29ubmVjdGlvbi4mcXVv dDsgVGhlIGRlZmluaXRpb24NCndpdGhpbjxicj4NCiZndDsgJmd0OyB0aGUgSVRVLVQgb2Y8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgdGVybSBpcyBwb29ybHkgc3BlY2lmaWVkIGFuZCBj b21lcyBmcm9tIHRoZTxicj4NCiZndDsgbW9uaXRvcmluZyBvZiBhPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBw YXRoDQpiZWluZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JlZC4gVGhpcyBkZWZp bml0aW9uIG9mIFRDIHNlZW1zIHRvIGJlIGF0IHZhcmlhbmNlLDxicj4NCiZndDsgJmd0OyBhbmQg d291bGQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5 IGluIGJhbmQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgRG9lc24ndCAmcXVvdDtmb3J3YXJkaW5nIGVuZ2luZSZxdW90OyBzb3VuZCBsaWtl DQpoYXJkd2FyZSB0byB5b3U/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IFllcywgYnV0IHNvIHdoYXQ/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSU1ITyBpdCBpcyB3b3J0aCBub3RpbmcgdGhh dCBuZWl0aGVyIHRoZSBNUExTLVRQPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVxdWlyZW1lbnRzIGRy YWZ0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5vciB0aGUgTVBMUy1UUCBPQU0gcmVx dWlyZW1lbnRzIG9uZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7IChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMt dHAtb2FtLXJlcXVpcmVtZW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdHMtMDEudHh0 KSBjb250YWluIGFueSByZXF1aXJlbWVudHMgZGVhbGluZyB3aXRoDQp0YW5kZW08YnI+DQomZ3Q7 ICZndDsgJmd0OyBjb25uZWN0aW9ucy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlz Y3Vzc2VkIGluIHRoZSBNUExTLVRQDQpPQU08YnI+DQomZ3Q7ICZndDsgRnJhbWV3b3JrPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRyYWZ0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAo aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9h bS1mcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYW1ld29yay0wMC50eHQ8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFJpZ2h0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgTGV0J3MganVzdCBnZXQg cmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nDQphbGw8YnI+DQomZ3Q7IHRoZSBJ LURzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRvIGxpbmUuPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGJvdHRvbSBsaW5lLCBJ TUhPLCBpcyB0aGF0IHNvbWUgY2xhcml0eSByZWdhcmRpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBj by1yb3V0ZWQgdnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFzc29jaWF0ZWQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBwYXRocyBpcyBzdGlsbCBy ZXF1aXJlZC4gT25lIHdheQ0KdG8gcHJvdmlkZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhh dCBjb3VsZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiZSBieSBleHBsaWNpdGx5IGxp bWl0aW5nIFJlcXVpcmVtZW50IDM0IHRvIHNwZWNpZmljPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZnVu Y3Rpb25hbGl0eS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgQWdyZWVkLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBBZHJpYW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogQWRyaWFuIEZhcnJl bCBbYWRyaWFuQG9sZGRvZy5jby51a108YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg VG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0DQpwYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpIFNhc2hhLDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBOb3QgcmVh bGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3JlcHJlc2VudGluZyBhbnlvbmUsDQpidXQuLi48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAx LiBNeSByZWFkaW5nIG9mICZuYnNwO29uZSBvZiBCZW4ncyAmbmJzcDttZXNzYWdlcw0KaXMgdGhh dCBhc3NvY2lhdGVkIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZQ0Kb25seSB0eXBlcyBv ZiBwYXRocyB0aGF0IGNhbiBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY3JlYXRlZCBpbjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZXhpc3RpbmcgbmV0d29ya3M7ICZxdW90 O3RydWUmcXVvdDsgY28tcm91dGVkDQpiaWRpcmVjdGlvbmFsIHBhdGhzPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyB3aWxsIGhhdmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdG8gd2Fp dCB1bnRpbCAoaWYgZXZlcikgbmV3IGVxdWlwbWVudCBiZWNvbWVzDQphdmFpbGFibGUuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoaXMgaXMgY2xl YXJseSBub25zZW5zZSE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb20gdGhlIHBvaW50IG9m IHZpZXcgb2YgaGFyZHdhcmUsIGNvLXJvdXRlZDxicj4NCiZndDsgJmd0OyBiaWRpcmVjdGlvbmFs IExTUHMgYXJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhIHNwZWNpYWwgY2FzZSBvZiBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFs IExTUHMgKGUuZy4gdXNpbmcNCnRoZTxicj4NCiZndDsgJmd0OyBtYW5hZ2VtZW50PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBwbGFuZSkgeW91IGNhbiBzdXJlbHkgc2V0IHVwIGEgY28tcm91dGVk PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCBMU1AuPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGFyZSBzaGlwcGluZyBzb2x1 dGlvbnMgdGhhdCBhY2hpZXZlIGNvLXJvdXRlZDxicj4NCiZndDsgYmlkaXJlY3Rpb25hbDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgTFNQcyB1c2luZyB0aGUgY29udHJvbCBwbGFuZS4gVGhlc2Ug ZWl0aGVyIHVzZSB0aGUNCkdNUExTPGJyPg0KJmd0OyAmZ3Q7ICh3aGljaCBpczxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgY2xlYW5lcikgb3Igbm9uLXN0YW5kYXJkIHByb3ByaWV0YXJ5IHNvbHV0 aW9ucyAod2hpY2gNCmlzPGJyPg0KJmd0OyAmZ3Q7IG1lc3N5IGJ1dDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgZnVuY3Rpb25hbCkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IEJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBj b250cm9sIHBsYW5lPGJyPg0KJmd0OyAmZ3Q7IHNvbHV0aW9ucyBoYXZlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBub3RoaW5nIHRvIGRvIHdpdGggYXZhaWxhYmlsaXR5IG9mIGVxdWlwbWVudCBh cyB0aGV5PGJyPg0KJmd0OyBhcmUgc29mdHdhcmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNv bHV0aW9ucy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2FnZXMgaXMgdGhhdA0K dGhlIGFjdHVhbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZHJpdmVyIGZvcjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUg ZXhwZXJpZW5jZQ0Kd2l0aCBleGlzdGluZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg dHJhbnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFuIGFueSBzcGVjaWZpYyBiZW5lZml0Ljxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJc24ndCB0aGF0 IHRoZSBjYXNlIHdpdGggNzUlIG9mIHRoZSBNUExTLVRQIHJlcXVpcmVtZW50cz88YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IFdoaWNoIGlzIG5vdCB0byBzYXkgaXQgaXMgYSBiYWQgdGhpbmcuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEEgbGFyZ2Ug ZHJpdmVyIGZvciBNUExTLVRQIGlzIHRvIGdpdmUgdGhlIHBhY2tldCBuZXR3b3JrPGJyPg0KJmd0 OyAmZ3Q7IHRoZSBsb29rLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZmVlbCwgYW5kIGJlaGF2 aW9yYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgJnF1b3Q7bGVnYWN5JnF1b3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyB0cmFuc3BvcnQgbmV0d29yay48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBCYXNlZCBvbiB0aGVzZSBvYnNlcnZhdGlv bnMsIEknZCBndWVzcyAoRldJVykNCnRoYXQ6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICogYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSwgYXQgbGVhc3QNCmZvciB0aGUg dGltZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YmVpbmcsIHRo ZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mDQpiaWRpcmVjdGlvbmFsIHBhdGhzIGluPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtNUExTLVRQPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCBpcyB3cm9u ZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwNCmFuZDxicj4NCiZndDsgJmd0OyBnaXZl biB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBvdGhlciB1cGdyYWRlcyB0byBleGlzdGlu ZyBNUExTIHNvbHV0aW9ucyB3aWxsIGJlPGJyPg0KJmd0OyBuZWVkZWQgdG8gcmVhY2g8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBmdWxsIGZ1bmN0aW9uIGxldmVsIG9mIE1QTFMtVFAuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKiB0 aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBlDQpvZjxicj4NCiZn dDsgJmd0OyBiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyBwYXRocyBpbiAmbmJzcDtyZWFsIGRlcGxveW1lbnRzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIGRvbid0IHNlZSB3aGF0IHRoYXQgZm9sbG93 cyBmcm9tLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBDaGVlcnMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBZHJpYW48YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1wbHMt dHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtcGxzLXRwQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7ICZndDsgJmd0OyBtcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1w bHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG1wbHMtdHBAaWV0 Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cDxicj4NCiZndDsgPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCm1w bHMtdHBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtdHA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0lu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3Jt YXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMm bmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3Mm bmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5i c3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNw O3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhp cyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFp bCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRo Jm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRl ZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5i c3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hh dmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3Im bmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2Vk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMm bmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtz eXN0ZW0uDQo8L3ByZT4= --=_alternative 0008C716482575A1_=-- From xqwei@fiberhome.com.cn Wed Apr 22 19:09:19 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1273A68D9 for ; Wed, 22 Apr 2009 19:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.72 X-Spam-Level: *** X-Spam-Status: No, score=3.72 tagged_above=-999 required=5 tests=[AWL=-1.725, BAYES_50=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0UIKX2NJERj for ; Wed, 22 Apr 2009 19:09:18 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id 4EB343A6C65 for ; Wed, 22 Apr 2009 19:09:16 -0700 (PDT) Received: from xqwei ([10.82.25.4]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Apr 2009 10:05:59 +0800 Date: Thu, 23 Apr 2009 10:10:37 +0800 From: "Xueqin WEI (Shuetsing WEI)" To: "liu.guoman" Message-ID: <200904231010375314646@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 23 Apr 2009 02:05:59.0319 (UTC) FILETIME=[0B9FCA70:01C9C3B8] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectionaltransportpath requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 02:09:19 -0000 R3VvbWFuOg0KSSB0aGluayBOdXJpdCBlbWFpbCBoYXMgYSBnb29kIGFuc3dlciB0byB0aGlzIChJ dCBhbHJlYWR5IGNsZWFyIHRvIHVzKSBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byBjb250aW51ZSB0 byBhcmd1bWVudCB0aGlzIGFnYWluLg0KSWYgeW91IGNhbiBjb3JyZWN0bHkgdW5kZXJzdGFuZCBt eSBvcGlub24gb24gVENNLCBJIHdpbGwgZmVlbCBoYXBweS4gQnV0IEkgYW0gYWZyYWlkIGl0IHNl ZW1zIHlvdSBkaWRuJ3QuDQoNClNpbmNlcmVseSBZb3Vycw0KWHVlcWluIFdlaSAoU2h1ZXRzaW5n IFdlaSkNCg0KRGV2ZWxvcG1lbnQgJiBQbGFubmluZyBEZXBhcnRtZW50LA0KRmliZXJob21lIFRl bGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ2llcyBDby4sTHRkLiwNCk5vLjg4IFlvdWtleXVhbiBS b2FkLEhvbmdzaGFuIERpc3QuLFd1aGFuLEh1YmVpLFAuUi5DaGluYSw0MzAwNzQNClRlbDogICAg Kzg2IDI3IDg3NjkxMzEwDQpGYXg6ICAgICs4NiAyNyA4NzY5NDM2Mg0KRW1haWw6ICB4cXdlaUBm aWJlcmhvbWUuY29tLmNuDQoyMDA5LTA0LTIzICAxMDowNDoxNA0KDQo9PT09PT09PT09PT09PT09 PT09PSBGb2xsb3dpbmcgaXMgeW91ciBlbWFpbD09PT09PT09PT09PT09PT09PT09PQ0KU3ViamVj dDpSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgUkU6QXNz b2NpYXRlZGJpZGlyZWN0aW9uYWx0cmFuc3BvcnRwYXRoIHJlcXVpcmVtZW50cykNClNlbnSjujIw MDktMDQtMjMgMDk6MDc6MDgNCkZyb206bGl1Lmd1b21hbg0KVG86eHF3ZWkNCkNDIHRvOm1wbHMt dHANCg0KPnh1YW5xaW6jug0KPiAgSSBrbm93IHdlIGFyZSBkaXNjdXNzaW5nIHJlcXVpcmVtZW50 cyBvZiBUQ00uIGJ1dCB0aGVyZSBtYXliZSBhbGwga2luZHMgDQo+b2YgbWV0aG9kcyB0byByZWFs aXplIHNlZ21lbnQgbW9uaXRvcmluZyBleGNlcHQgbmVzdGVkIExTUCAuIHdoeSB3ZSBtdXN0IA0K Pm9ubHkgc2VsZWN0IHRoZSBtZXRob2Qgb2YgbmVzdGVkIExTUD8gDQo+IHNvIG5vdyBpdCBpcyBr ZXkgcHJvYmxlbSB0byB3aGV0aGVyIHRvIG5lZWQgdGhlIHJlcXVpcmVtZW50IG9mIFRDTSANCj5m dW5jdGlvbnMuIG5vdCBkaXNjdXNzaW5nIHRoZSBtZXRob2Qgb2YgcmVhbGl6aW5nIHRoZSBUQ00g ZnVuY3Rpb25zLiANCj5kbyB5b3UgdW5kZXJzdGFuZCBtZS4NCj4NCj5iZXN0IHJlZ2FyZHMNCj5s aXUNCj4NCj4NCj4NCj4iWHVlcWluIFdFSSAoU2h1ZXRzaW5nIFdFSSkiIDx4cXdlaUBmaWJlcmhv bWUuY29tLmNuPiANCj4yMDA5LTA0LTIyIDIwOjUwDQo+x+u08Li0ILj4DQo+eHF3ZWlAZmliZXJo b21lLmNvbS5jbg0KPg0KPg0KPsrVvP7Iyw0KPiJsaXUuZ3VvbWFuIiA8bGl1Lmd1b21hbkB6dGUu Y29tLmNuPg0KPrOty80NCj4iTVBMUy1UUCIgPG1wbHMtdHBAaWV0Zi5vcmc+DQo+1vfM4g0KPlJl OiBSZTogW21wbHMtdHBdIFRhbmRlbSBDb25uZWN0aW9ucyBpbiBNUExTLVRQICh3YXMgDQo+UkU6 QXNzb2NpYXRlZGJpZGlyZWN0aW9uYWx0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQo+DQo+ DQo+DQo+DQo+DQo+DQo+R3VvbWFuOg0KPg0KPkNvcnJlY3Q6IHdlIGFyZSBkaXNjdXNzaW5nIHJl cXVpcmVtZW50cyBvZiBzZWdtZW50IG1vbml0b3Jpbmcgb2YgYW4gRW5kIHRvIA0KPkVuZCBMU1Au DQo+DQo+U2luY2VyZWx5IFlvdXJzDQo+WHVlcWluIFdlaSAoU2h1ZXRzaW5nIFdlaSkNCj4NCj5E ZXZlbG9wbWVudCAmIFBsYW5uaW5nIERlcGFydG1lbnQsDQo+RmliZXJob21lIFRlbGVjb21tdW5p Y2F0aW9uIFRlY2hub2xvZ2llcyBDby4sTHRkLiwNCj5Oby44OCBZb3VrZXl1YW4gUm9hZCxIb25n c2hhbiBEaXN0LixXdWhhbixIdWJlaSxQLlIuQ2hpbmEsNDMwMDc0DQo+VGVsOiAgICArODYgMjcg ODc2OTEzMTANCj5GYXg6ICAgICs4NiAyNyA4NzY5NDM2Mg0KPkVtYWlsOiAgeHF3ZWlAZmliZXJo b21lLmNvbS5jbg0KPjIwMDktMDQtMjIgIDIwOjQ3OjM4DQo+DQo+PT09PT09PT09PT09PT09PT09 PT0gRm9sbG93aW5nIGlzIHlvdXIgZW1haWw9PT09PT09PT09PT09PT09PT09PT0NCj5TdWJqZWN0 OlJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyANCj5SRTpB c3NvY2lhdGVkYmlkaXJlY3Rpb25hbHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCj5TZW50 o7oyMDA5LTA0LTIyIDE3OjAyOjEzDQo+RnJvbTpsaXUuZ3VvbWFuDQo+VG86eHF3ZWkNCj5DQyB0 bzptcGxzLXRwDQo+DQo+Pkkgc3VwcG9ydCBodWFuZmVuZydzIG9waW5pb25zLCBoZXJlIHdlIG9u bHkgZGlzc2N1c3MgdGhlIHJlcXVpcmVtZW50cyBvZiANCj4+VENNLiBob3cgdG8gcmVhbGl6ZSB0 aGUgZnVuY3Rpb25zIG9mIFRDTSB3aWxsIGJlIGRpc3NjdXNzZWQgaW4gdGhlIA0KPmZ1dHVyZS4g DQo+Pkkgd2lzaCB0aGF0IHh1ZXFpbiBjb25zaWRlciBpdCB2ZXJ5IHdlbGwuDQo+Pg0KPj50aGFu ayB5b3UNCj4+bGl1DQo+Pg0KPj4NCj4+DQo+PiJYdWVxaW4gV0VJIChTaHVldHNpbmcgV0VJKSIg PHhxd2VpQGZpYmVyaG9tZS5jb20uY24+IA0KPj63orz+yMs6ICBtcGxzLXRwLWJvdW5jZXNAaWV0 Zi5vcmcNCj4+MjAwOS0wNC0yMiAxNjoyMg0KPj7H67TwuLQguPgNCj4+eHF3ZWlAZmliZXJob21l LmNvbS5jbg0KPj4NCj4+DQo+PsrVvP7Iyw0KPj4iSFVBTkcgRmVuZyBGIiA8RmVuZy5mLkh1YW5n QGFsY2F0ZWwtc2JlbGwuY29tLmNuPg0KPj6zrcvNDQo+Pk1QTFMtVFAgPG1wbHMtdHBAaWV0Zi5v cmc+DQo+Ptb3zOINCj4+UmU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlvbnMgaW4gTVBMUy1U UCAod2FzIA0KPj5SRTpBc3NvY2lhdGVkYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1 aXJlbWVudHMpDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PkZlbmc6DQo+Pg0KPj5UaGUgZnVu Y3Rpb24gb2YgVENNIGNhbiBiZSBwcm92aWRlZCBieSBuZXN0ZWQgTFNQIChXaGljaCBpcyB0aGUg YmFzaWMgDQo+PmZ1bmN0aW9uIG9mIE1QTFMtVFApLCB3ZSBuZWVkbid0IHRvIGRlZmluZSBUQ00u DQo+Pg0KPj4NCj4+U2luY2VyZWx5IFlvdXJzDQo+Plh1ZXFpbiBXZWkgKFNodWV0c2luZyBXZWkp DQo+PjIwMDktMDQtMjIgIDE2OjIwOjEwDQo+Pg0KPj49PT09PT09PT09PT09PT09PT09PSBGb2xs b3dpbmcgaXMgeW91ciBlbWFpbD09PT09PT09PT09PT09PT09PT09PQ0KPj5TdWJqZWN0OlJFOiBb bXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdhcyANCj4+UkU6QXNzb2Np YXRlZGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KPj5TZW50o7oy MDA5LTA0LTIwIDIxOjU4OjE4DQo+PkZyb206SFVBTkcgRmVuZyBGDQo+PlRvOnhxd2VpQGZpYmVy aG9tZS5jb20uY247IEJlbiBOaXZlbi1KZW5raW5zOyBCdXNpIEl0YWxvDQo+PkNDIHRvOk1QTFMt VFANCj4+DQo+Pj5EZWFyIFh1ZXFpbiwNCj4+PiAgICAgV2UgYXJlIGRpc2N1c3NpbmcgcmVxdWly ZW1lbnQgb2YgVENNLCBub3QgZm9yICBmdW5jdGlvbiBhbmQgbWV0aG9kIA0KPj5pbiBkZXRhaWxz Lg0KPj4+Qi5SLg0KPj4+RmVuZyANCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+PkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZ10gT24gDQo+PkJlaGFsZiBPZiBYdWVxaW4gV0VJIChTaHVldHNpbmcgV0VJKQ0K Pj4+U2VudDogMjAwOcTqNNTCMTjI1SAxNDo1Mg0KPj4+VG86IEJlbiBOaXZlbi1KZW5raW5zDQo+ Pj5DYzogTVBMUy1UUA0KPj4+U3ViamVjdDogUmU6IFttcGxzLXRwXSBUYW5kZW0gQ29ubmVjdGlv bnMgaW4gTVBMUy1UUCAod2FzIA0KPj5SRTpBc3NvY2lhdGVkYmlkaXJlY3Rpb25hbCB0cmFuc3Bv cnQgcGF0aCByZXF1aXJlbWVudHMpDQo+Pj4NCj4+PlN1cHBvcnQsIEkgdGhpbmsgdGhlIG5lc3Rl ZCBMU1Agd2lsbCBiZSBncmVhdCEgVW50aWwgbm93LCBJIGRpZG4ndCBzZWUgDQo+PmFueSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIG5lc3RlZCBMU1AgYW5kIFRDTSBvbiBwZXJmb3JtYW5jZSBtb25p dG9yaW5nLiANCj4+QnV0IHRoZSBuZXN0ZWQgTFNQIHdpbGwgbWFrZSB0aGUgdGhpbmdzIG1vcmUg ZWFzeS4gSSB3b3VsZCBsaWtlIHNlbGVjdCBhIA0KPj5zaW1wbGUgd2F5IHRvIHJlc29sdmUgdGhl IHByb2JsZW0uDQo+Pj4NCj4+PlNpbmNlcmVseSBZb3Vycw0KPj4+WHVlcWluIFdlaSAoU2h1ZXRz aW5nIFdlaSkNCj4+Pg0KPj4+RmliZXJob21lIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ2ll cyBDby4sTHRkLiwNCj4+PjIwMDktMDQtMTggIDE0OjQ4OjUxDQo+Pj4NCj4+Pj09PT09PT09PT09 PT09PT09PT09IEZvbGxvd2luZyBpcyB5b3VyIGVtYWlsPT09PT09PT09PT09PT09PT09PT09DQo+ Pj5TdWJqZWN0OlJlOiBbbXBscy10cF0gVGFuZGVtIENvbm5lY3Rpb25zIGluIE1QTFMtVFAgKHdh cyBSRTogDQo+PkFzc29jaWF0ZWRiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVt ZW50cykNCj4+PlNlbnSjujIwMDktMDQtMTcgMTc6MTc6MzENCj4+PkZyb206QmVuIE5pdmVuLUpl bmtpbnMNCj4+PlRvOkJVU0kgSVRBTE87IEFkcmlhbiBGYXJyZWw7IEFsZXhhbmRlciBWYWluc2h0 ZWluIENDIHRvOm1wbHMtdHANCj4+Pg0KPj4+Pkl0YWxvLA0KPj4+Pg0KPj4+Pk9uIDE3LzA0LzIw MDkgMDk6MzQsICJCVVNJIElUQUxPIiA8SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdD4gd3Jv dGU6DQo+Pj4+PiBUaGUgSldUIGFncmVlbWVudCBpcyB0byBicmluZyB0aGUgSVRVLVQgdHJhbnNw b3J0IHJlcXVpcmVtZW50cyBpbiANCj4+Pj4+IElFVEYgdG8gZXh0ZW5kIHRoZSBNUExTIGFyY2hp dGVjdHVyZSB0byBtZWV0IHRoZW0gaW4gYSB3YXkgdGhhdCBpcyANCj4+Pj4+IGNvbXBhdGlibGUs IGNvbnNpc3RlbnQgYW5kIGNvaGVyZW50IHdpdGggZXhpc3RpbmcgSUVURiBhcmNoaXRlY3R1cmUu DQo+Pj4+DQo+Pj4+U28gSSB0b29rIGEgbG9vayBhdCB0aGUgSldUIHJlcG9ydC4gSXQgc2F5cyAo c2xpZGUgMTYpDQo+Pj4+DQo+Pj4+IiBTZXJ2aWNlIFByb3ZpZGVycyB3YW50IExTUHMvUFdFcyB0 byBiZSBhYmxlIHRvIGJlIG1hbmFnZWQgYXQgdGhlIA0KPj4+PmRpZmZlcmVudCBuZXN0ZWQgbGV2 ZWxzIHNlYW1sZXNzbHkgKHBhdGgsIHNlZ21lbnQsIG11bHRpcGxlIHNlZ21lbnRzKQ0KPj4+PiAg ICBha2EgVGFuZGVtIENvbm5lY3Rpb24gTW9uaXRvcmluZyAoVENNKSwgdGhpcyBpcyB1c2VkIGZv ciBleGFtcGxlIA0KPj4+PndoZW4gYSBMU1AvUFdFIGNyb3NzZXMgbXVsdGlwbGUgYWRtaW5pc3Ry YXRpb25zIg0KPj4+Pg0KPj4+PklNTyB0aGUgcmVxdWlyZW1lbnQgaXMgdG8gYmUgYWJsZSB0byBt b25pdG9yIHBhcnRzIG9mIGEgcGF0aCBhcyB3ZWxsIGFzIA0KPg0KPj4+PnRoZSBlbmQgdG8gZW5k IHBhdGguIFRoZXJlIGFyZSBtYW55IHdheXMgdG8gc29sdmUgdGhhdCByZXF1aXJlbWVudCwgb25l IA0KPg0KPj4+Pm9mIHdoaWNoIGlzIHRoZSBjcmVhdGlvbiBvZiBuZXN0ZWQgTFNQcywgb25lIHBl ciBsZXZlbCBvZiBtb25pdG9yaW5nIA0KPj4+PnJlcXVpcmVkIChteSB1bmRlcnN0YW5kaW5nIG9m IGhvdyBUQ00gd29ya3MpLg0KPj4+Pg0KPj4+PkkgdGhpbmsgdGhlIHJlYWwgZGlzY3Vzc2lvbiBp cyB0aGVyZWZvcmUgaXMgdGhlIHJlcXVpcmVtZW50IHRvIG1vbml0b3IgDQo+Pj4+ZGlmZmVyZW50 IGNvbXBvbmVudHMgb2YgYW4gZW5kIHRvIGVuZCBwYXRoIG9yIGlzIHRoZSByZXF1aXJlbWVudCB0 aGF0IA0KPj4+PnN1Y2ggbW9uaXRvcmluZyBNVVNUIGJlIGFjaGlldmVkIHVzaW5nIG5lc3RlZCBM U1BzPw0KPj4+Pg0KPj4+PkFzIGFuIGV4YW1wbGUgUFcgdGVjaG5vbG9neSB0b2RheSBhbGxvd3Mg ZW5kIHRvIGVuZCBhbmQgcGVyIHNlZ21lbnQgDQo+Pj4+bW9uaXRvcmluZyBidXQgaXQgZG9lcyBu b3QgYWNoaWV2ZSBpdCB1c2luZyBuZXN0ZWQgUFdzIG9yIFBXIGxldmVscy4NCj4+Pj4NCj4+Pj5C ZW4NCj4+Pj4NCj4+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pm1wbHMtdHAgbWFpbGluZyBsaXN0DQo+Pj4+bXBscy10cEBpZXRmLm9yZw0KPj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPj4+Pg0KPj4+ DQo+Pj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pm1wbHMtdHAgbWFpbGluZyBsaXN0DQo+Pj5tcGxzLXRwQGlldGYub3JnDQo+ Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4+Pg0KPj4N Cj4+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+bXBscy10cCBtYWlsaW5nIGxpc3QNCj4+bXBscy10cEBpZXRmLm9yZw0KPj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4+DQo+Pg0KPj4NCj4+ DQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+PlpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIA0KPmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiANCj5pcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IA0KPmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIA0KPm90aGVycy4NCj4+VGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgDQo+aW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIA0KPmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCj5vcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkg dmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UgDQo+b2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KPj5UaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0KPnN5c3RlbS4NCj4NCj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0K Pg0KPg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5k ZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3Jl Y3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlz IGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KPlRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj5UaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50 aS1TcGFtIHN5c3RlbS4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg== From xqwei@fiberhome.com.cn Wed Apr 22 19:48:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D153A69AF for ; Wed, 22 Apr 2009 19:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[AWL=2.169, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4IFFM1I2JiI for ; Wed, 22 Apr 2009 19:48:30 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id 0E7CF3A6A68 for ; Wed, 22 Apr 2009 19:48:28 -0700 (PDT) Received: from xqwei ([10.82.25.4]) by mail.fiberhome.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Apr 2009 10:45:00 +0800 Date: Thu, 23 Apr 2009 10:49:39 +0800 From: "Xueqin WEI (Shuetsing WEI)" To: "Maarten Vissers" Message-ID: <200904231049389067998@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2009 02:45:00.0148 (UTC) FILETIME=[7EDDF340:01C9C3BD] Cc: MPLS-TP Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 02:48:31 -0000 Maarten: I think that segmengt monitoring of a end to end LSP is a useful function to network opreation. As to how to realize it (By nested LSP or TCM or sth else), I'd like we discuss later (After reauirements confirmed, I think some people expressed same opinon). >From my personal view, I like nested LSP more. But it's will be fine to me whatever ITU-T and IETF finally selected in the future. One shing I want to remind you is: the mechanism that was shown in "MPLS-TP_overview-22.ppt" is add a TCM label to the LSP which will be monitored. This is different with TCM mechanism defined in T-MPLS. Sincerely Yours Xueqin Wei (Shuetsing Wei) Development & Planning Department, Fiberhome Telecommunication Technologies Co.,Ltd., No.88 Youkeyuan Road,Hongshan Dist.,Wuhan,Hubei,P.R.China,430074 Tel: +86 27 87691310 Fax: +86 27 87694362 Email: xqwei@fiberhome.com.cn 2009-04-23 10:23:37 ==================== Following is your email===================== Subject:RE: RE: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements) Sent：2009-04-23 10:10:23 From:Maarten Vissers To:xqwei@fiberhome.com.cn CC to:'MPLS-TP' >Xueqin, > >TCM as designed in Ethernet, ATM and T-MPLS does not require the >provisioning of a TCM label along the monitored segment. The T-MPLS TCM >design just required the activation of some MEPs, one at each end of the >segment to monitor. I..e. no changes to the existing LSP. MPLS-TP segment >monitoring on the basis of a nested LSP requires much more provisioning, as >you need to set up the new LSP and modify the existing LSP. > >Regards, >Maarten > >-----Original Message----- >From: Xueqin WEI (Shuetsing WEI) [mailto:xqwei@fiberhome.com.cn] >Sent: woensdag 22 april 2009 9:18 >To: Maarten Vissers >Cc: MPLS-TP >Subject: Re: RE: [mpls-tp] Tandem Connections in MPLS-TP >(wasRE:Associatedbidirectional transport path requirements) > >Maarten: >Sorry reply you later because I have a trip on Monday and Tuesday. >IMO, nested LSP is a already exist mechanism but TCM is a new added one. >Addtion of TCM will make the thing more complicate. >Second, TCM need to provision the TCM label along the monitored segmant too, >I didn't see any provision difference between nested LSP and TCM. > >Sincerely Yours >Xueqin Wei (Shuetsing Wei) >2009-04-22 15:12:35 > >==================== Following is your email===================== >Subject:RE: [mpls-tp] Tandem Connections in MPLS-TP >(wasRE:Associatedbidirectional transport path requirements) >Sent：2009-04-19 01:16:02 >From:Maarten Vissers >To:xqwei >CC to:'MPLS-TP' > >>Xueqin, >> >>The nested LSP is a more complex solution then TCM. TCM just requires >>the activation of some MEPs in the LSP. Nested LSP requires to set up >>the same MEP functions plus set up an additional LSP and change the >existing LSP. >> >>Regards, >>Maarten >> >>-----Original Message----- >>From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>Behalf Of Xueqin WEI (Shuetsing WEI) >>Sent: zaterdag 18 april 2009 8:52 >>To: Ben Niven-Jenkins >>Cc: MPLS-TP >>Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was >>RE:Associatedbidirectional transport path requirements) >> >>Support, I think the nested LSP will be great! Until now, I didn't see >>any difference between the nested LSP and TCM on performance >>monitoring. But the nested LSP will make the things more easy. I would >>like select a simple way to resolve the problem. >> >>Sincerely Yours >>Xueqin Wei (Shuetsing Wei) >> >>Fiberhome Telecommunication Technologies Co.,Ltd., >>2009-04-18 14:48:51 >> >>==================== Following is your email===================== >>Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: >>Associatedbidirectional transport path requirements) >>Sent：2009-04-17 17:17:31 >>From:Ben Niven-Jenkins >>To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp >> >>>Italo, >>> >>>On 17/04/2009 09:34, "BUSI ITALO" wrote: >>>> The JWT agreement is to bring the ITU-T transport requirements in >>>> IETF to extend the MPLS architecture to meet them in a way that is >>>> compatible, consistent and coherent with existing IETF architecture. >>> >>>So I took a look at the JWT report. It says (slide 16) >>> >>>" Service Providers want LSPs/PWEs to be able to be managed at the >>>different nested levels seamlessly (path, segment, multiple segments) >>> aka Tandem Connection Monitoring (TCM), this is used for example >>>when a LSP/PWE crosses multiple administrations" >>> >>>IMO the requirement is to be able to monitor parts of a path as well >>>as the end to end path. There are many ways to solve that requirement, >>>one of which is the creation of nested LSPs, one per level of >>>monitoring required (my understanding of how TCM works). >>> >>>I think the real discussion is therefore is the requirement to monitor >>>different components of an end to end path or is the requirement that >>>such monitoring MUST be achieved using nested LSPs? >>> >>>As an example PW technology today allows end to end and per segment >>>monitoring but it does not achieve it using nested PWs or PW levels. >>> >>>Ben >>> >>>_______________________________________________ >>>mpls-tp mailing list >>>mpls-tp@ietf.org >>>https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >>================================================================= >>_______________________________________________ >>mpls-tp mailing list >>mpls-tp@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls-tp >> >> > >================================================================= > > > > ================================================================= From liu.guoman@zte.com.cn Wed Apr 22 23:25:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34133A68D7 for ; Wed, 22 Apr 2009 23:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.247 X-Spam-Level: X-Spam-Status: No, score=-97.247 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnNnZxvP2dtd for ; Wed, 22 Apr 2009 23:24:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1FF3D3A6E06 for ; Wed, 22 Apr 2009 23:24:57 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 11164764009499; Thu, 23 Apr 2009 14:15:58 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 90033.1746388837; Thu, 23 Apr 2009 14:22:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3N6PqU0011644; Thu, 23 Apr 2009 14:25:52 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: Ben Niven-Jenkins MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Thu, 23 Apr 2009 14:23:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-23 14:25:44, Serialize complete at 2009-04-23 14:25:44 Content-Type: multipart/alternative; boundary="=_alternative 00234FDF482575A1_=" X-MAIL: mse1.zte.com.cn n3N6PqU0011644 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 06:25:00 -0000 This is a multipart message in MIME format. --=_alternative 00234FDF482575A1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 YmVuOg0KIEkgdW5kZXJzdGFuZCB5b3VyIG1lYW5pbmcsIHlvdSBzdGlsbCB3aXNoIHRvIHJlc2ln biBhbmQgbWFrZSBhIG1vcmUgDQpyZWxpYWJsZSBhbmQgZWZmZWN0aXZlLCBlYXN5IHRvIG9wZXJh dG9yIGFuZCBlYXN5IHRvIG1hbmFnZSBwYWNrZXQgDQp0cmFuc3BvcnQgbmV0d29yayBsaWtlIG1l LiBidXQgd2h5IG5vdCBhcHBseSB0aGlzIFNESC9TT05FVCBpbiB0aGUgZnV0dXJlIA0KbWF5YmUg dGhlIGZvbGxvd2luZyBjYXVzZToNCiAgIDEgaXQgYWRvcHRlZCBjaXJjdWl0IHN3aXRjaGluZyB0 ZWNob25vZ3kgdG8gYnJpbmcgbG93ZXIgdXNlZnVsIG9mIHRoZSANCnJlc291cmNlIHRoYW4gUFRO IG5ldHdvcms7DQogICAyIGl0IGNhbid0IGJlYXIgYWxsIGtpbmRzIG9mIHRyYWZmaWNzIGxpa2Ug UFROIG5ldHdvcmtzDQppdCBub3RlZCB0aGF0IHdlIGNhbid0IGFwcGx5IFNESC9TT05FVCBuZXR3 b3JrIGluIHRoZSBmdXR1cmUgbm90IGJlY2F1c2UgDQppdCBoYXZlIGEgY29tcGxleCBPQU0gZnVu Y3Rpb25zLiB3aGlsZSBtb3JlIHBlb3BsZSBsaWtlIHRvIG1vdmUgdGhlIA0KYWR2YW50YWdlcyBv ZiAgdGhlIE9BTSBmdW5jdGlvbnMgaW4gU0RIL1NPTkVUIHRvIFBUTiBuZXR3b3Jrcy4gYW5kIEFJ Uy9GREkgDQpmdW5jdGlvbiBpcyBhIGtpbmQgb2YgT0FNIGZ1bmN0aW9ucyBvZiBTREgvU09ORVQg LiB3ZSBzaG91bGQgdXNlIGFuZCANCmV4dGVuZCB0aGUgQUlTL0ZESSBmdW5jdGlvbnMgdG8gTVBM Uy1UUCA7DQoNCmJlc3QgcmVnYXJkcw0KbGl1DQoNCg0KDQpCZW4gTml2ZW4tSmVua2lucyA8YmVu amFtaW4ubml2ZW4tamVua2luc0BidC5jb20+IA0KMjAwOS0wNC0yMyAwNzo1OA0KDQrK1bz+yMsN CjxsaXUuZ3VvbWFuQHp0ZS5jb20uY24+LCAiQlJVTkdBUkQsIERFQk9SQUggQSwgQVRUTEFCUyIg DQo8ZGJydW5nYXJkQGF0dC5jb20+DQqzrcvNDQo8bXBscy10cEBpZXRmLm9yZz4NCtb3zOINClJl OiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVp cmVtZW50cw0KDQoNCg0KDQoNCg0KT24gMjEvMDQvMjAwOSAwMjo1OSwgImxpdS5ndW9tYW5AenRl LmNvbS5jbiIgPGxpdS5ndW9tYW5AenRlLmNvbS5jbj4gDQp3cm90ZToNCg0KPiBEZWJvcmFoOg0K PiAgbWF5YmUgd2hhdCB5b3Ugc2FpZCBpcyByaWdodC4gYnV0IEkgY2FuJ3QgY29tcGxldGVseSBh Z3JlZSB5b3VyIA0Kb3BpbmlvbnMuDQo+IElNTy4gbXBscy10cCBpcyByZWdhcmQgYXMgdHJhbnNw b3J0IG5ldHdvcmsgbGlrZSBTREgvU09ORVQuIHNvIGl0IHNob3VsZA0KPiBoYXZlIEFJUy9GREkg ZnVjdGlvbnMgYXMgU0RIL1NPTkVULg0KPiANCj4gZG8geW91IHRoaW5rIHNvLg0KDQpObyB3ZSBt dXN0IGFzc2VzcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtz IA0Kc3VwcG9ydGluZw0KdGhlIG5lZWRzIG9mIG9wZXJhdG9ycyB0b2RheSBhbmQgaW4gdGhlIGZ1 dHVyZS4gV2UgbXVzdCBub3QgYmxpbmRseSANCnJlY3JlYXRlDQpTREgvU09ORVQuIElmIHdlIGRv IHNvIHdpdGhvdXQgY29uc2lkZXJhdGlvbiB0byBob3cgb3BlcmF0b3JzJyBuZWVkcyBhbmQNCnJl cXVpcmVtZW50cyBtYXkgaGF2ZSBldm9sdmVkIChhbmQgY29udGludWUgdG8gZXZvbHZlIGluIGZ1 dHVyZSkgd2Ugd2lsbA0KaGF2ZSBmYWlsZWQgSU1PIGFuZCBJIHdvdWxkIHNldmVyZWx5IHF1ZXN0 aW9uIHRoZSB2YWx1ZSBvZiB0aGUgd29yayB3ZSANCndpbGwNCmhhdmUgcHJvZHVjZWQuIElmIHdl IGp1c3QgcmVjcmVhdGUgU0RIL1NPTkVUIHRoZW4gd2hhdCBpcyB0aGUgcHVycG9zZSBvZiANCnRo ZQ0Kd29yayBhbiBvcGVyYXRvciB3b3VsZCBiZSBiZXR0ZXIgb2ZmIGp1c3QgZGVwbG95aW5nIGV4 aXN0aW5nIFNESC9TT05FVA0KZXF1aXBtZW50Lg0KDQoNCkJlbg0KDQoNCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00234FDF482575A1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmJlbjo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0kgdW5kZXJzdGFuZCB5b3VyIG1lYW5p bmcsIHlvdQ0Kc3RpbGwgd2lzaCB0byByZXNpZ24gYW5kIG1ha2UgYSBtb3JlIHJlbGlhYmxlIGFu ZCBlZmZlY3RpdmUsIGVhc3kgdG8gb3BlcmF0b3INCmFuZCBlYXN5IHRvIG1hbmFnZSBwYWNrZXQg dHJhbnNwb3J0IG5ldHdvcmsgbGlrZSBtZS4gYnV0IHdoeSBub3QgYXBwbHkNCnRoaXMgU0RIL1NP TkVUIGluIHRoZSBmdXR1cmUgbWF5YmUgdGhlIGZvbGxvd2luZyBjYXVzZTo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsxIGl0IGFkb3B0ZWQg Y2lyY3VpdCBzd2l0Y2hpbmcNCnRlY2hvbm9neSB0byBicmluZyBsb3dlciB1c2VmdWwgb2YgdGhl IHJlc291cmNlIHRoYW4gUFROIG5ldHdvcms7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7MiBpdCBjYW4ndCBiZWFyIGFsbCBraW5kcw0Kb2Yg dHJhZmZpY3MgbGlrZSBQVE4gbmV0d29ya3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPml0IG5vdGVkIHRoYXQgd2UgY2FuJ3QgYXBwbHkgU0RIL1NPTkVUDQpuZXR3 b3JrIGluIHRoZSBmdXR1cmUgbm90IGJlY2F1c2UgaXQgaGF2ZSBhIGNvbXBsZXggT0FNIGZ1bmN0 aW9ucy4gd2hpbGUNCm1vcmUgcGVvcGxlIGxpa2UgdG8gbW92ZSB0aGUgYWR2YW50YWdlcyBvZiAm bmJzcDt0aGUgT0FNIGZ1bmN0aW9ucyBpbiBTREgvU09ORVQNCnRvIFBUTiBuZXR3b3Jrcy4gYW5k IEFJUy9GREkgZnVuY3Rpb24gaXMgYSBraW5kIG9mIE9BTSBmdW5jdGlvbnMgb2YgU0RIL1NPTkVU DQouIHdlIHNob3VsZCB1c2UgYW5kIGV4dGVuZCB0aGUgQUlTL0ZESSBmdW5jdGlvbnMgdG8gTVBM Uy1UUCA7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5i ZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmxp dTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5C ZW4gTml2ZW4tSmVua2lucyAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7PC9i Pg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDQtMjMg MDc6NTg8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+Jmx0O2xpdS5ndW9tYW5AenRlLmNvbS5jbiZndDssICZxdW90O0JSVU5HQVJELA0KREVC T1JBSCBBLCBBVFRMQUJTJnF1b3Q7ICZsdDtkYnJ1bmdhcmRAYXR0LmNvbSZndDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZsdDttcGxzLXRwQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6 IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCBwYXRoIHJlcXVp cmVtZW50czwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNp emU9Mj48dHQ+T24gMjEvMDQvMjAwOSAwMjo1OSwgJnF1b3Q7bGl1Lmd1b21hbkB6dGUuY29tLmNu JnF1b3Q7DQombHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQom Z3Q7IERlYm9yYWg6PGJyPg0KJmd0OyAmbmJzcDttYXliZSB3aGF0IHlvdSBzYWlkIGlzIHJpZ2h0 LiBidXQgSSBjYW4ndCBjb21wbGV0ZWx5IGFncmVlIHlvdXINCm9waW5pb25zLjxicj4NCiZndDsg SU1PLiBtcGxzLXRwIGlzIHJlZ2FyZCBhcyB0cmFuc3BvcnQgbmV0d29yayBsaWtlIFNESC9TT05F VC4gc28gaXQNCnNob3VsZDxicj4NCiZndDsgaGF2ZSBBSVMvRkRJIGZ1Y3Rpb25zIGFzIFNESC9T T05FVC48YnI+DQomZ3Q7IDxicj4NCiZndDsgZG8geW91IHRoaW5rIHNvLjxicj4NCjxicj4NCk5v IHdlIG11c3QgYXNzZXNzIHRoZSByZXF1aXJlbWVudHMgZm9yIHBhY2tldCB0cmFuc3BvcnQgbmV0 d29ya3Mgc3VwcG9ydGluZzxicj4NCnRoZSBuZWVkcyBvZiBvcGVyYXRvcnMgdG9kYXkgYW5kIGlu IHRoZSBmdXR1cmUuIFdlIG11c3Qgbm90IGJsaW5kbHkgcmVjcmVhdGU8YnI+DQpTREgvU09ORVQu IElmIHdlIGRvIHNvIHdpdGhvdXQgY29uc2lkZXJhdGlvbiB0byBob3cgb3BlcmF0b3JzJyBuZWVk cyBhbmQ8YnI+DQpyZXF1aXJlbWVudHMgbWF5IGhhdmUgZXZvbHZlZCAoYW5kIGNvbnRpbnVlIHRv IGV2b2x2ZSBpbiBmdXR1cmUpIHdlIHdpbGw8YnI+DQpoYXZlIGZhaWxlZCBJTU8gYW5kIEkgd291 bGQgc2V2ZXJlbHkgcXVlc3Rpb24gdGhlIHZhbHVlIG9mIHRoZSB3b3JrIHdlDQp3aWxsPGJyPg0K aGF2ZSBwcm9kdWNlZC4gSWYgd2UganVzdCByZWNyZWF0ZSBTREgvU09ORVQgdGhlbiB3aGF0IGlz IHRoZSBwdXJwb3NlIG9mDQp0aGU8YnI+DQp3b3JrIGFuIG9wZXJhdG9yIHdvdWxkIGJlIGJldHRl ciBvZmYganVzdCBkZXBsb3lpbmcgZXhpc3RpbmcgU0RIL1NPTkVUPGJyPg0KZXF1aXBtZW50Ljxi cj4NCjxicj4NCjxicj4NCkJlbjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxw cmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJz cDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZu YnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGll bnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3Rv Jm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5i c3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRz Jm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJz Lg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFu c21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNw O2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJz cDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lm Jm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5i c3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29y aWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmll d3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJl Jm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIu DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7 Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNw O0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00234FDF482575A1_=-- From neil.2.harrison@bt.com Thu Apr 23 00:02:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8689F3A67EC for ; Thu, 23 Apr 2009 00:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDkz-JsK1afY for ; Thu, 23 Apr 2009 00:02:36 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id F140428C692 for ; Thu, 23 Apr 2009 00:02:34 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 08:03:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C3E1.A7DED6DC" Date: Thu, 23 Apr 2009 08:03:47 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0475697C@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: AcnD3GwfOEz8FG/aRAWqZjW4VIQeQgAAFbbQ From: To: , X-OriginalArrivalTime: 23 Apr 2009 07:03:51.0721 (UTC) FILETIME=[A867E990:01C9C3E1] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 07:02:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C3E1.A7DED6DC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGl1LA0KIA0KRGlkIHlvdSBub3QgdW5kZXJzdGFuZCB0aGUgY29tbWVudHMgdGhhdCBBbmR5IFJl aWQgb2YgQlQgd3JvdGUgaW4gcmVzcG9uc2UgdG8geW91IHdydCB0aGUgZWZmaWNhY3kgb2YgQUlT IGluIHBhY2tldC1zd2l0Y2hlZCBuZXR3b3Jrcz8gIEkgZmVhciB5b3UgbXVzdCBub3QgaGF2ZSB1 bmRlcnN0b29kIHRoZXNlIGZyb20gd2hhdCB5b3Ugc2F5IGJlbG93LiAgSSBoYXZlIHNvbWUgcmVz cG9uc2VzIGluLWxpbmU6DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K CUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpdS5ndW9tYW5AenRlLmNvbS5jbg0KCVNlbnQ6IDIzIEFw cmlsIDIwMDkgMDc6MjQNCglUbzogTml2ZW4tamVua2lucyxCLEJlbixETUYgUg0KCUNjOiBtcGxz LXRwQGlldGYub3JnDQoJU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoJDQoJDQoNCgliZW46IA0KCSBJIHVu ZGVyc3RhbmQgeW91ciBtZWFuaW5nLCB5b3Ugc3RpbGwgd2lzaCB0byByZXNpZ24gYW5kIG1ha2Ug YSBtb3JlIHJlbGlhYmxlIGFuZCBlZmZlY3RpdmUsIGVhc3kgdG8gb3BlcmF0b3IgYW5kIGVhc3kg dG8gbWFuYWdlIHBhY2tldCB0cmFuc3BvcnQgbmV0d29yayBsaWtlIG1lLiBidXQgd2h5IG5vdCBh cHBseSB0aGlzIFNESC9TT05FVCBpbiB0aGUgZnV0dXJlIG1heWJlIHRoZSBmb2xsb3dpbmcgY2F1 c2U6IA0KCSAgIDEgaXQgYWRvcHRlZCBjaXJjdWl0IHN3aXRjaGluZyB0ZWNob25vZ3kgdG8gYnJp bmcgbG93ZXIgdXNlZnVsIG9mIHRoZSByZXNvdXJjZSB0aGFuIFBUTiBuZXR3b3JrOyANCgkgICAy IGl0IGNhbid0IGJlYXIgYWxsIGtpbmRzIG9mIHRyYWZmaWNzIGxpa2UgUFROIG5ldHdvcmtzICAN CglOSD0+IFRoaXMgaXMgd3JvbmcuICBUaGUgY28tY3MgbW9kZSBpcyB0aGUgYmVzdCB0cmFuc3Bv cnQgc29sdXRpb24gZm9yIGFueSBsYXJnZSBtZXNzYWdlL2ZpbGUvc3RyZWFtIHRyYWZmaWMgYWdn cmVnYXRlcyBmb3IgdGhlIHJlYXNvbnMgSSBoYXZlIGV4cGxhaW5lZCBiZWZvcmUuICBQbGVhc2Ug cmVmZXIgYmFjayB0byBteSByZW1hcmtzIG9uIHdoYXQgdHJhbnNwYXJlbmN5IG1lYW5zIGFuZCB3 aHkgdGhpcyBtYWtlcyB0aGUgY28tY3MgbW9kZSB2ZXJ5IHNpbXBsZSAodG8gb3BlcmF0ZSkgaW4g Y2FycnlpbmcgYW55IHRlbXBvcmFsbHkgdmFyeWluZyBtaXggb2YgbWVzc2FnZS9maWxlL3N0cmVh bSBhcHBsaWNhdGlvbnMgaW4gc29tZSBoaWdoZXIgdG9wLW9mLXN0YWNrIGxheWVyIG5ldHdvcmsu IA0KCSANCglJZiB3ZSBhcmUgdG8gc3Vic3RpdHV0ZSBhIGNvLXBzIG1vZGUgdGVjaG5vbG9neSBm b3IgYSBjby1jcyBtb2RlIHRlY2hub2xvZ3kgaW4gYSB0cmFuc3BvcnQgcm9sZSB3ZSBuZWVkIHRv IHBheSBjYXJlZnVsIGF0dGVudGlvbiB0byB0aGVzZSB0cmFuc3BhcmVuY3kgcmVxdWlyZW1lbnRz LiAgV2h5PyAgQmVjYXVzZSBpbiB0aGUgY28tY3MgbW9kZSBvbmUgaXMgKmZvcmNlZCogdG8gYWJp ZGUgYnkgdGhlIHRyYW5zcGFyZW5jeSBydWxlcyBieSB0aGUgcGh5c2ljcyBvZiBob3cgcmVzb3Vy Y2VzIGFyZSBwYXJ0aXRpb25lZCBhbmQgbGFiZWxsZWQgaGVyZSAoaWUgb25lIGhhcyBubyBjaG9p Y2UgaGVyZSkgYnV0IHRoaXMgaXMgbm90IHRydWUgaW4gdGhlIGNvLXBzIG1vZGUuICBPbmUgY2Fu IHZpb2xhdGUgdGhlIHRyYW5zcGFyZW5jeSBydWxlcyBpbiBtYW55IHdheXMgaW4gdGhlIGNvLXBz IG1vZGUsIHNvIHdlIGhhdmUgdG8gYmUgY29uc2Npb3VzIG9mIHRoaXMuIA0KCSANCglUaGUgY29u c2VxdWVuY2Ugb2YgdmlvbGF0aW5nIHRoZXNlIHRyYW5zcGFyZW5jeSBydWxlcyBpcyB0byBpbmN1 ciBzb21lIGRlZ3JlZSBvZiBhZGRlZCBzeXN0ZW0gY29tcGxleGl0eS4uLi4uaW5jcmVhc2luZyBz eXN0ZW0gY29tcGxleGl0eSByZXN1bHRzIGluIGluY3JlYXNpbmcgbWFyZ2luYWwgKG9wZXJhdGlv bmFsKSBjb3N0cyB3aXRoIGluY3JlYXNpbmcgc2NhbGUvc2NvcGUsIGFuZCB0aHVzIG9uZSBnZW5l cmF0ZXMgZGlzZWNvbm9taWVzIG9mIHNjYWxlL3Njb3BlIChpbiBhbnkgc3lzdGVtLCBub3QganVz dCBuZXR3b3JraW5nIHN5c3RlbXMuLi4udGhpcyBpcyBhIHdlbGwta25vd24vdW5kZXJzdG9vZCBm YWN0IGZvciBFY29ub21pc3RzLCBidXQgaXQgaXMgbGVzcyB3ZWxsIHVuZGVyc3Rvb2QgYnkgRW5n aW5lZXJzKS4NCgkNCglpdCBub3RlZCB0aGF0IHdlIGNhbid0IGFwcGx5IFNESC9TT05FVCBuZXR3 b3JrIGluIHRoZSBmdXR1cmUgbm90IGJlY2F1c2UgaXQgaGF2ZSBhIGNvbXBsZXggT0FNIGZ1bmN0 aW9ucy4gd2hpbGUgbW9yZSBwZW9wbGUgbGlrZSB0byBtb3ZlIHRoZSBhZHZhbnRhZ2VzIG9mICB0 aGUgT0FNIGZ1bmN0aW9ucyBpbiBTREgvU09ORVQgdG8gUFROIG5ldHdvcmtzLiBhbmQgQUlTL0ZE SSBmdW5jdGlvbiBpcyBhIGtpbmQgb2YgT0FNIGZ1bmN0aW9ucyBvZiBTREgvU09ORVQgLiB3ZSBz aG91bGQgdXNlIGFuZCBleHRlbmQgdGhlIEFJUy9GREkgZnVuY3Rpb25zIHRvIE1QTFMtVFAgOyAg DQoJTkg9PiBXZWxsIEkga25vdyBpdHMgc291bmRzIHBsYXVzaWJsZSBidXQgeW91IGFyZSB3cm9u ZyBoZXJlLiAgV2hlbiBJIG9yaWdpbmFsbHkgc3RhcnRlZCBsb29raW5nIGF0IHdoYXQgdGhlIG9w dGltYWwgT0FNIHJlcXVpcmVtZW50cyB3ZXJlIGZvciB0aGUgY28tcHMgbW9kZSBtYW55IHllYXJz IGFnbyBJIHdhcyBpbiBmYXZvdXIgb2YgYXBwbHlpbmcgYSBGREkvQUlTIHR5cGUgb2YgZnVuY3Rp b24uICBIb3dldmVyLCBJIGhhdmUgc2luY2UgYmVlbiBjb252aW5jZWQgYnkgc3Ryb25nIHRlY2hu aWNhbCBhcmd1bWVudHMgYW5kIHJlYWwtd29ybGQgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB0aGF0 IEFJUyBpcyBub3QgYSBnb29kIGlkZWEgYXQgYWxsLi4uLml0IGhhcyBvYnZpb3VzbHkgbm8gcm9s ZSBpbiBhIGNsLXBzIG1vZGUgbmV0d29yayAod2h5IGRvIHlvdSB0aGluayBJRUVFIHJlbW92ZWQg aXQgZnJvbSBFdGhlcm5ldCBPQU0gaW4gODAyLjFhZz8gIHdoeSBoYXMgSUVURiBuZXZlciBzcGVj aWZpZWQgaXQgZm9yIElQdjQvNj8pIGFuZCB3aGVuIHlvdSByZWFsbHkgdW5kZXJzdGFuZCBPQU0g eW91IGFsc28gcmVhbGlzZSBpdCBpcyBub3QgYSBnb29kIGZ1bmN0aW9uIGV2ZW4gaW4gdGhlIGNv LXBzIG1vZGUgd2hlbiB3ZSBkbyBoYXZlIHByb3BlciBjb25uZWN0aW9ucy4gIEFJUyBvbmx5IHJl YWxseSBtYWtlcyBzZW5zZSBpbiB0aGUgY28tY3MgbW9kZS4NCgkgDQoJUGxlYXNlIHJlLXJlYWQg d2hhdCBBbmR5IFJlaWQgc2FpZCBpbiBoaXMgcmVzcG9uc2UgdG8geW91IHllc3RlcmRheSBvbiBB SVMuICANCgkgDQoJcmVnYXJkcywgTmVpbCANCgkNCgliZXN0IHJlZ2FyZHMgDQoJbGl1IA0KCQ0K CQ0KCQ0KQmVuIE5pdmVuLUplbmtpbnMgPGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPiAN Cg0KMjAwOS0wNC0yMyAwNzo1OCANCg0K5pS25Lu25Lq6DQo8bGl1Lmd1b21hbkB6dGUuY29tLmNu PiwgIkJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMiIDxkYnJ1bmdhcmRAYXR0LmNvbT4gDQrm ioTpgIENCjxtcGxzLXRwQGlldGYub3JnPiANCuS4u+mimA0KUmU6IFttcGxzLXRwXSBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzCQ0KDQoJCQ0KDQoN Cg0KDQoJT24gMjEvMDQvMjAwOSAwMjo1OSwgImxpdS5ndW9tYW5AenRlLmNvbS5jbiIgPGxpdS5n dW9tYW5AenRlLmNvbS5jbj4gd3JvdGU6DQoJDQoJPiBEZWJvcmFoOg0KCT4gIG1heWJlIHdoYXQg eW91IHNhaWQgaXMgcmlnaHQuIGJ1dCBJIGNhbid0IGNvbXBsZXRlbHkgYWdyZWUgeW91ciBvcGlu aW9ucy4NCgk+IElNTy4gbXBscy10cCBpcyByZWdhcmQgYXMgdHJhbnNwb3J0IG5ldHdvcmsgbGlr ZSBTREgvU09ORVQuIHNvIGl0IHNob3VsZA0KCT4gaGF2ZSBBSVMvRkRJIGZ1Y3Rpb25zIGFzIFNE SC9TT05FVC4NCgk+IA0KCT4gZG8geW91IHRoaW5rIHNvLg0KCQ0KCU5vIHdlIG11c3QgYXNzZXNz IHRoZSByZXF1aXJlbWVudHMgZm9yIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3Mgc3VwcG9ydGlu Zw0KCXRoZSBuZWVkcyBvZiBvcGVyYXRvcnMgdG9kYXkgYW5kIGluIHRoZSBmdXR1cmUuIFdlIG11 c3Qgbm90IGJsaW5kbHkgcmVjcmVhdGUNCglTREgvU09ORVQuIElmIHdlIGRvIHNvIHdpdGhvdXQg Y29uc2lkZXJhdGlvbiB0byBob3cgb3BlcmF0b3JzJyBuZWVkcyBhbmQNCglyZXF1aXJlbWVudHMg bWF5IGhhdmUgZXZvbHZlZCAoYW5kIGNvbnRpbnVlIHRvIGV2b2x2ZSBpbiBmdXR1cmUpIHdlIHdp bGwNCgloYXZlIGZhaWxlZCBJTU8gYW5kIEkgd291bGQgc2V2ZXJlbHkgcXVlc3Rpb24gdGhlIHZh bHVlIG9mIHRoZSB3b3JrIHdlIHdpbGwNCgloYXZlIHByb2R1Y2VkLiBJZiB3ZSBqdXN0IHJlY3Jl YXRlIFNESC9TT05FVCB0aGVuIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlDQoJd29yayBhbiBv cGVyYXRvciB3b3VsZCBiZSBiZXR0ZXIgb2ZmIGp1c3QgZGVwbG95aW5nIGV4aXN0aW5nIFNESC9T T05FVA0KCWVxdWlwbWVudC4NCgkNCgkNCglCZW4NCgkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NCglUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQoNCg== ------_=_NextPart_001_01C9C3E1.A7DED6DC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04Mjk0ODI4MDYtMjMwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5MaXUsPC9GT05UPjwvU1BBTj48 L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTgyOTQ4MjgwNi0yMzA0 MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz04Mjk0ODI4MDYtMjMwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj5EaWQgeW91IG5vdCB1bmRlcnN0YW5kIHRoZSBjb21tZW50cyANCnRo YXQgQW5keSBSZWlkIG9mIEJUIHdyb3RlIGluIHJlc3BvbnNlIHRvIHlvdSB3cnQgdGhlIGVmZmlj YWN5IG9mIEFJUyBpbiANCnBhY2tldC1zd2l0Y2hlZCBuZXR3b3Jrcz8mbmJzcDsgSSBmZWFyIHlv dSBtdXN0IG5vdCBoYXZlIHVuZGVyc3Rvb2QgdGhlc2UgZnJvbSANCndoYXQgeW91IHNheSBiZWxv dy4mbmJzcDsgSSBoYXZlIHNvbWUgcmVzcG9uc2VzIGluLWxpbmU6PC9GT05UPjwvU1BBTj48L0RJ Vj48QlI+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBN QVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzgwMDAwMCAycHggc29saWQ7IE1BUkdJTi1S SUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVz IGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRh aG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgW21h aWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAgPC9CPmxp dS5ndW9tYW5AenRlLmNvbS5jbjxCUj48Qj5TZW50OjwvQj4gMjMgQXByaWwgMjAwOSAwNzoyNDxC Uj48Qj5Ubzo8L0I+IA0KICBOaXZlbi1qZW5raW5zLEIsQmVuLERNRiBSPEJSPjxCPkNjOjwvQj4g bXBscy10cEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gDQogIFJlOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KICByZXF1aXJlbWVudHM8QlI+ PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj48QlI+PEZPTlQgZmFjZT1z YW5zLXNlcmlmIHNpemU9Mz5iZW46PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0K ICBzaXplPTM+Jm5ic3A7SSB1bmRlcnN0YW5kIHlvdXIgbWVhbmluZywgeW91IHN0aWxsIHdpc2gg dG8gcmVzaWduIGFuZCBtYWtlIGEgDQogIG1vcmUgcmVsaWFibGUgYW5kIGVmZmVjdGl2ZSwgZWFz eSB0byBvcGVyYXRvciBhbmQgZWFzeSB0byBtYW5hZ2UgcGFja2V0IA0KICB0cmFuc3BvcnQgbmV0 d29yayBsaWtlIG1lLiBidXQgd2h5IG5vdCBhcHBseSB0aGlzIFNESC9TT05FVCBpbiB0aGUgZnV0 dXJlIA0KICBtYXliZSB0aGUgZm9sbG93aW5nIGNhdXNlOjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTM+Jm5ic3A7IA0KICAmbmJzcDsxIGl0IGFkb3B0ZWQgY2lyY3VpdCBz d2l0Y2hpbmcgdGVjaG9ub2d5IHRvIGJyaW5nIGxvd2VyIHVzZWZ1bCBvZiB0aGUgDQogIHJlc291 cmNlIHRoYW4gUFROIG5ldHdvcms7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mz4mbmJzcDsgDQogICZuYnNwOzIgaXQgY2FuJ3QgYmVhciBhbGwga2luZHMgb2YgdHJhZmZp Y3MgbGlrZSBQVE4gDQogIG5ldHdvcmtzPC9GT05UPiZuYnNwOzxTUEFOIGNsYXNzPTgyOTQ4Mjgw Ni0yMzA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgY29sb3I9IzgwMDAwMCBz aXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz04Mjk0 ODI4MDYtMjMwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCAN CiAgc2l6ZT0yPk5IPSZndDsgVGhpcyBpcyB3cm9uZy4mbmJzcDsgVGhlIGNvLWNzIG1vZGUgaXMg dGhlIGJlc3QgdHJhbnNwb3J0IA0KICBzb2x1dGlvbiBmb3IgYW55IGxhcmdlIG1lc3NhZ2UvZmls ZS9zdHJlYW0gdHJhZmZpYyBhZ2dyZWdhdGVzIGZvciB0aGUgcmVhc29ucyANCiAgSSBoYXZlIGV4 cGxhaW5lZCBiZWZvcmUuJm5ic3A7IFBsZWFzZSByZWZlciBiYWNrIHRvIG15IHJlbWFya3Mgb24g d2hhdCANCiAgdHJhbnNwYXJlbmN5IG1lYW5zIGFuZCB3aHkgdGhpcyBtYWtlcyB0aGUgY28tY3Mg bW9kZSB2ZXJ5IHNpbXBsZSAodG8gDQogIG9wZXJhdGUpJm5ic3A7aW4gY2FycnlpbmcgYW55IHRl bXBvcmFsbHkgdmFyeWluZyBtaXggb2YgbWVzc2FnZS9maWxlL3N0cmVhbSANCiAgYXBwbGljYXRp b25zIGluIHNvbWUgaGlnaGVyIHRvcC1vZi1zdGFjayBsYXllciANCiAgbmV0d29yay4mbmJzcDs8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTgyOTQ4MjgwNi0yMzA0MjAw OT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz04Mjk0ODI4MDYtMjMw NDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0y PklmIHdlIGFyZSB0byBzdWJzdGl0dXRlIGEgY28tcHMgbW9kZSB0ZWNobm9sb2d5IGZvciBhIGNv LWNzIG1vZGUgDQogIHRlY2hub2xvZ3kgaW4gYSB0cmFuc3BvcnQgcm9sZSB3ZSBuZWVkIHRvIHBh eSBjYXJlZnVsIGF0dGVudGlvbiB0byB0aGVzZSANCiAgdHJhbnNwYXJlbmN5IHJlcXVpcmVtZW50 cy4mbmJzcDsgV2h5PyZuYnNwOyBCZWNhdXNlIGluIHRoZSBjby1jcyBtb2RlIG9uZSBpcyANCiAg KmZvcmNlZCogdG8gYWJpZGUgYnkgdGhlIHRyYW5zcGFyZW5jeSBydWxlcyBieSB0aGUgcGh5c2lj cyBvZiBob3cgcmVzb3VyY2VzIA0KICBhcmUgcGFydGl0aW9uZWQgYW5kIGxhYmVsbGVkIGhlcmUg KGllIG9uZSBoYXMgbm8gY2hvaWNlIGhlcmUpIGJ1dCB0aGlzIGlzIG5vdCANCiAgdHJ1ZSBpbiB0 aGUgY28tcHMgbW9kZS4mbmJzcDsgT25lIGNhbiB2aW9sYXRlIHRoZSB0cmFuc3BhcmVuY3kgcnVs ZXMgaW4gbWFueSANCiAgd2F5cyBpbiB0aGUgY28tcHMgbW9kZSwgc28gd2UgaGF2ZSB0byBiZSBj b25zY2lvdXMgb2YgDQogIHRoaXMuJm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48 U1BBTiBjbGFzcz04Mjk0ODI4MDYtMjMwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIg Y29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxE SVY+PFNQQU4gY2xhc3M9ODI5NDgyODA2LTIzMDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMg TVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj5UaGUgY29uc2VxdWVuY2Ugb2YgdmlvbGF0aW5n IHRoZXNlIHRyYW5zcGFyZW5jeSBydWxlcyBpcyB0byBpbmN1ciANCiAgc29tZSZuYnNwO2RlZ3Jl ZSBvZiBhZGRlZCBzeXN0ZW0gY29tcGxleGl0eS4uLi4uaW5jcmVhc2luZyBzeXN0ZW0gY29tcGxl eGl0eSANCiAgcmVzdWx0cyBpbiBpbmNyZWFzaW5nIG1hcmdpbmFsIChvcGVyYXRpb25hbCkgY29z dHMgd2l0aCBpbmNyZWFzaW5nIA0KICBzY2FsZS9zY29wZSwgYW5kIHRodXMgb25lIGdlbmVyYXRl cyBkaXNlY29ub21pZXMgb2Ygc2NhbGUvc2NvcGUgKGluIGFueSANCiAgc3lzdGVtLCBub3QganVz dCBuZXR3b3JraW5nIHN5c3RlbXMuLi4udGhpcyBpcyBhIHdlbGwta25vd24vdW5kZXJzdG9vZCBm YWN0IA0KICBmb3IgRWNvbm9taXN0cywgYnV0IGl0IGlzIGxlc3Mgd2VsbCB1bmRlcnN0b29kIGJ5 IA0KICBFbmdpbmVlcnMpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+PC9GT05UPjxCUj48Rk9OVCANCiAg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mz5pdCBub3RlZCB0aGF0IHdlIGNhbid0IGFwcGx5IFNESC9T T05FVCBuZXR3b3JrIGluIHRoZSANCiAgZnV0dXJlIG5vdCBiZWNhdXNlIGl0IGhhdmUgYSBjb21w bGV4IE9BTSBmdW5jdGlvbnMuIHdoaWxlIG1vcmUgcGVvcGxlIGxpa2UgdG8gDQogIG1vdmUgdGhl IGFkdmFudGFnZXMgb2YgJm5ic3A7dGhlIE9BTSBmdW5jdGlvbnMgaW4gU0RIL1NPTkVUIHRvIFBU TiBuZXR3b3Jrcy4gDQogIGFuZCBBSVMvRkRJIGZ1bmN0aW9uIGlzIGEga2luZCBvZiBPQU0gZnVu Y3Rpb25zIG9mIFNESC9TT05FVCAuIHdlIHNob3VsZCB1c2UgDQogIGFuZCBleHRlbmQgdGhlIEFJ Uy9GREkgZnVuY3Rpb25zIHRvIE1QTFMtVFAgOzwvRk9OVD4mbmJzcDs8U1BBTiANCiAgY2xhc3M9 ODI5NDgyODA2LTIzMDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgDQogIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNs YXNzPTgyOTQ4MjgwNi0yMzA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0j ODAwMDAwIA0KICBzaXplPTI+Tkg9Jmd0OyBXZWxsIEkga25vdyBpdHMgc291bmRzIHBsYXVzaWJs ZSBidXQgeW91IGFyZSB3cm9uZyBoZXJlLiZuYnNwOyANCiAgV2hlbiBJIG9yaWdpbmFsbHkgc3Rh cnRlZCBsb29raW5nIGF0IHdoYXQgdGhlIG9wdGltYWwgT0FNIHJlcXVpcmVtZW50cyB3ZXJlIA0K ICBmb3IgdGhlIGNvLXBzIG1vZGUgbWFueSB5ZWFycyBhZ28gSSB3YXMgaW4gZmF2b3VyIG9mIGFw cGx5aW5nIGEgRkRJL0FJUyB0eXBlIA0KICBvZiBmdW5jdGlvbi4mbmJzcDsgSG93ZXZlciwgSSBo YXZlIHNpbmNlIGJlZW4gY29udmluY2VkIGJ5IHN0cm9uZyB0ZWNobmljYWwgDQogIGFyZ3VtZW50 cyBhbmQgcmVhbC13b3JsZCBvcGVyYXRpb25hbCBleHBlcmllbmNlIHRoYXQgQUlTIGlzIG5vdCBh IGdvb2QgaWRlYSBhdCANCiAgYWxsLi4uLml0IGhhcyBvYnZpb3VzbHkgbm8gcm9sZSBpbiBhIGNs LXBzIG1vZGUgbmV0d29yayAod2h5IGRvIHlvdSB0aGluayBJRUVFIA0KICByZW1vdmVkIGl0IGZy b20gRXRoZXJuZXQgT0FNIGluIDgwMi4xYWc/Jm5ic3A7IHdoeSBoYXMgSUVURiBuZXZlciBzcGVj aWZpZWQgaXQgDQogIGZvciBJUHY0LzY/KSBhbmQgd2hlbiB5b3UgcmVhbGx5IHVuZGVyc3RhbmQg T0FNIHlvdSBhbHNvIHJlYWxpc2UgaXQgaXMgbm90IGEgDQogIGdvb2QgZnVuY3Rpb24gZXZlbiBp biB0aGUgY28tcHMgbW9kZSB3aGVuJm5ic3A7d2UgZG8gaGF2ZSBwcm9wZXIgDQogIGNvbm5lY3Rp b25zLiZuYnNwOyBBSVMgb25seSByZWFsbHkgbWFrZXMgc2Vuc2UgaW4gdGhlIGNvLWNzIA0KICBt b2RlLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9ODI5NDgyODA2LTIz MDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTgyOTQ4Mjgw Ni0yMzA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBz aXplPTI+UGxlYXNlIHJlLXJlYWQgd2hhdCBBbmR5IFJlaWQgc2FpZCBpbiBoaXMgcmVzcG9uc2Ug dG8geW91IHllc3RlcmRheSBvbiANCiAgQUlTLiZuYnNwOyA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0K ICA8RElWPjxTUEFOIGNsYXNzPTgyOTQ4MjgwNi0yMzA0MjAwOT48L1NQQU4+PFNQQU4gDQogIGNs YXNzPTgyOTQ4MjgwNi0yMzA0MjAwOT48L1NQQU4+PFNQQU4gY2xhc3M9ODI5NDgyODA2LTIzMDQy MDA5PjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTgyOTQ4MjgwNi0y MzA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXpl PTI+cmVnYXJkcywgTmVpbDwvRk9OVD4mbmJzcDs8L1NQQU4+PEJSPjxCUj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgDQogIHNpemU9Mz5iZXN0IHJlZ2FyZHM8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0zPmxpdTwvRk9OVD4gDQogIDxCUj48QlI+PEJSPjwvRElWPg0KICA8VEFC TEUgd2lkdGg9IjEwMCUiPg0KICAgIDxUQk9EWT4NCiAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAg IDxURCB3aWR0aD0iMjYlIj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPjxCPkJlbiBOaXZl bi1KZW5raW5zIA0KICAgICAgICAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7 PC9CPiA8L0ZPTlQ+DQogICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+MjAw OS0wNC0yMyAwNzo1ODwvRk9OVD4gPC9QPg0KICAgICAgPFREIHdpZHRoPSI3MyUiPg0KICAgICAg ICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICA8VFIg dkFsaWduPXRvcD4NCiAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgPERJViBhbGlnbj1y aWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuaUtuS7tuS6ujwvRk9OVD48L0RJVj4N CiAgICAgICAgICAgIDxURD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPiZsdDtsaXUuZ3Vv bWFuQHp0ZS5jb20uY24mZ3Q7LCANCiAgICAgICAgICAgICAgIkJSVU5HQVJELCBERUJPUkFIIEEs IEFUVExBQlMiICZsdDtkYnJ1bmdhcmRAYXR0LmNvbSZndDs8L0ZPTlQ+IA0KICAgICAgICAgIDxU UiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICA8RElWIGFsaWdu PXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+5oqE6YCBPC9GT05UPjwvRElWPg0K ICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+Jmx0O21wbHMtdHBA aWV0Zi5vcmcmZ3Q7PC9GT05UPiANCiAgICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAg ICAgIDxURD4NCiAgICAgICAgICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMt c2VyaWYgc2l6ZT0xPuS4u+mimDwvRk9OVD48L0RJVj4NCiAgICAgICAgICAgIDxURD48Rk9OVCBm YWNlPXNhbnMtc2VyaWYgc2l6ZT0xPlJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCANCiAgICAgICAg ICAgICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCiAgICAgICAgcmVxdWlyZW1lbnRz PC9GT05UPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPg0KICAgICAgICA8VEFCTEU+DQog ICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAg PFREPg0KICAgICAgICAgICAgPFREPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjwvVEQ+ PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjxCUj48QlI+PEZPTlQgDQogIHNpemU9Mj48VFQ+T24g MjEvMDQvMjAwOSAwMjo1OSwgImxpdS5ndW9tYW5AenRlLmNvbS5jbiIgDQogICZsdDtsaXUuZ3Vv bWFuQHp0ZS5jb20uY24mZ3Q7IHdyb3RlOjxCUj48QlI+Jmd0OyBEZWJvcmFoOjxCUj4mZ3Q7ICZu YnNwO21heWJlIA0KICB3aGF0IHlvdSBzYWlkIGlzIHJpZ2h0LiBidXQgSSBjYW4ndCBjb21wbGV0 ZWx5IGFncmVlIHlvdXIgb3BpbmlvbnMuPEJSPiZndDsgDQogIElNTy4gbXBscy10cCBpcyByZWdh cmQgYXMgdHJhbnNwb3J0IG5ldHdvcmsgbGlrZSBTREgvU09ORVQuIHNvIGl0IA0KICBzaG91bGQ8 QlI+Jmd0OyBoYXZlIEFJUy9GREkgZnVjdGlvbnMgYXMgU0RIL1NPTkVULjxCUj4mZ3Q7IDxCUj4m Z3Q7IGRvIHlvdSANCiAgdGhpbmsgc28uPEJSPjxCUj5ObyB3ZSBtdXN0IGFzc2VzcyB0aGUgcmVx dWlyZW1lbnRzIGZvciBwYWNrZXQgdHJhbnNwb3J0IA0KICBuZXR3b3JrcyBzdXBwb3J0aW5nPEJS PnRoZSBuZWVkcyBvZiBvcGVyYXRvcnMgdG9kYXkgYW5kIGluIHRoZSBmdXR1cmUuIFdlIG11c3Qg DQogIG5vdCBibGluZGx5IHJlY3JlYXRlPEJSPlNESC9TT05FVC4gSWYgd2UgZG8gc28gd2l0aG91 dCBjb25zaWRlcmF0aW9uIHRvIGhvdyANCiAgb3BlcmF0b3JzJyBuZWVkcyBhbmQ8QlI+cmVxdWly ZW1lbnRzIG1heSBoYXZlIGV2b2x2ZWQgKGFuZCBjb250aW51ZSB0byBldm9sdmUgDQogIGluIGZ1 dHVyZSkgd2Ugd2lsbDxCUj5oYXZlIGZhaWxlZCBJTU8gYW5kIEkgd291bGQgc2V2ZXJlbHkgcXVl c3Rpb24gdGhlIHZhbHVlIA0KICBvZiB0aGUgd29yayB3ZSB3aWxsPEJSPmhhdmUgcHJvZHVjZWQu IElmIHdlIGp1c3QgcmVjcmVhdGUgU0RIL1NPTkVUIHRoZW4gd2hhdCANCiAgaXMgdGhlIHB1cnBv c2Ugb2YgdGhlPEJSPndvcmsgYW4gb3BlcmF0b3Igd291bGQgYmUgYmV0dGVyIG9mZiBqdXN0IGRl cGxveWluZyANCiAgZXhpc3RpbmcgU0RIL1NPTkVUPEJSPmVxdWlwbWVudC48QlI+PEJSPjxCUj5C ZW48QlI+PEJSPjwvVFQ+PC9GT05UPjxCUj48QlI+PFBSRT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24m bmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVs eSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2Fu aXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZu YnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZu YnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5k Jm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZu YnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29s ZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5i c3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZu YnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZu YnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwv UFJFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C9C3E1.A7DED6DC-- From maarten.vissers@huawei.com Thu Apr 23 05:36:58 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206BE28C6F3 for ; Thu, 23 Apr 2009 05:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Ai7jB3V3I3 for ; Thu, 23 Apr 2009 05:36:57 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id 372EA28C73A for ; Thu, 23 Apr 2009 05:34:09 -0700 (PDT) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042305352424718 ; Thu, 23 Apr 2009 05:35:24 -0700 Received: from M00900002 ([10.84.0.8]) by s-utl02-sjpop.stsn.net; Thu, 23 Apr 2009 05:35:12 -0700 From: "Maarten Vissers" To: "'Greg Mirsky'" Date: Thu, 23 Apr 2009 14:35:04 +0200 Message-ID: <000001c9c40f$f3d42550$0800540a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C9C420.B75CF550" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnDqIM1poMBpMA1QHCY51t7wHwYNwABL+4g In-Reply-To: <787be2780904221714l4e3c5fffv6db3cf2ebae4c40a@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 12:36:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C9C420.B75CF550 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C9C420.B75CF550" ------=_NextPart_001_0002_01C9C420.B75CF550 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Greg, =20 The reason I have placed UNIs also as peers of the EVC is because many operators provide this type of service today.=20 E.g. when a packet transport network provides interconnection between an ISPs service edge router to a group of DSLAMs, then the service edge = router of such ISP is connected to the PTN of the network operator via a = rooted-mp EVC that has an endpoint in the service edge router and in the group of DSLAMs (case of ATM DSLAMs). With the introduction of VDSL2 and fiber = DSLAMs into the network, the EVC endpoints will be in the home gateways or in = the end-user terminal equipment (STB, PC, VoIP telephone, ...). I have illustrated these three cases in the attached slides 1 to 3. Slides 4 to = 6 illustrate some examples of EVC maintenance entity groups that could be defined for those three cases.=20 =20 Another case is carrier-carrier services. Carrier A wants to = interconnect with a number of remote network termination devices which are located = behind the network of a regional carrier B. E.g. 10 NT devices, each connected = with a fast ethernet interface to carrier B network. Carrier A network = connects via 1GE interface to carrier B network. Two scenarios are now possible: =20 1) each fast ethernet interface carries a single VLAN service, which is carried as an EVC through the network of carrier B towards the interface with carrier A. At this interface the 10 EVCs are multiplexed onto the = 1GE interface. The EVCs are now commonly owned by carrier A and B, and = possibly by the customer. Carrier B monitors those 10 EVCs via a TCM MEG level. =20 2) each fast ethernet interface carries a number of VLAN services, each identified by a C-Tag. This group of services is treated as a port based service in the network of carrier B. This port based service (section = VLAN (EVS)) is treated as EVC in carrier B's network and often identified by means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 EVSs of the customers) are multiplex into the 1GE interface and delivered to carrier = A's Virtual UNI-N port. Carrier A's V-UNI-N port treats those 10 EVCs of = carrier B as 10 EVPs, each EVP carrying multiple EVC signals. Each carrier A EVC signal is traffic conditioned, and gets EVC OAM in the EVC TCM MEP = functions located in this V-UNI-N port card. - The EVCs in carrier B's network have their endpoints in customer edge equipment and in the V-UNI-N port of carrier A. For the customer this is = an EVS endpoint, while for the carrier A this is an EVP endpoint. Carrier = B's EVC peers as such with carrier A and customer for this EVC and carrier B will monitor its EVC via a TCM MEG level. - The EVCs in carrier A network have their endpoints in the customer = network (e.g. customer edge equipments). Carrier A deploys a TCM MEG level to monitor this service.=20 =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: donderdag 23 april 2009 2:15 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I agree with your presentation of layers but only wonder why you've = placed UNIs both as clients of EVC layer as well as its peers. I'd leave UNIs = only as clients of EVC layer. Would you agree? Regards, Greg 2009/4/22 Maarten Vissers Dear Greg, =20 Thank you for this confirmation.=20 This other layer is that the EVC layer as illustrated in the figure = below? =20 UNI UNI --||------- ---------||----- | | UNI ------------------------------------------------- UNI --||----| EVC layer |-----||----- ------------------------------------------------- | MPLS-TP layer | | other layer | ----------------- ---------------- =20 MEF's E-Tree is a bidirectional rooted-multipoint connection, in which frames are forwarded on the basis of the value in their DA field. Such selective forwarding is not supported in an LSP connection. An LSP connection will as such just support one EVC link connection, i.e. a = part of the EVC between two adjacent EVC switch/bridge functions. Those p2p EVC = link connections simply require non-selective forwarding, something that an = LSP connection can provide. =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00=20 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I think you've captured my view pretty accurately. Since MPLS-TP = supports only p2p and p2mp transports it would be responsibility of another layer = to support specific services among UNI-Ns. Interesting thing that E-Tree = can not be directly mapped to p2mp unidirectional MPLS-TP LSP since by MEF's definition E-Tree is a bidirectional service. (Just a note). Kind regards, Greg 2009/4/22 Maarten Vissers Dear Greg, =20 Do you mean that there is a layer network above MPLS-TP that will = support these services from UNI-N port to UNI-N port, and that MPLS-TP will = support this service layer network? =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I believe that it is not a requirement for MPLS-TP to support any = specific service, including ones you've listed in your message. On the other = hand, support of listed services is a requirement for a client layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers Neil, =20 I expect that the main requirement for a packet transport network = technology like MPLS-TP is that it is able to support at least the following = services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed manner. =20 Another main requirement is that it must be able to support those = services in a scalable manner between points anywhere in the world. =20 The E-Line, E-Tree and E-LAN services allow to reorder client frames = that belong to different priorities and to drop client frames that are drop eligible. =20 The E-Tree and E-LAN services require that client bits are read to = deliver the frames to the appropriate output port or ports of the E-Tree or = E-LAN supporting transport entity/differentiated connection. =20 The packet transport network technology must as such support traffic engineered transport entities (differentiated connections) with n input ports (i.e. multi source constructs). This in addition of traffic = engineered transport entities with 1 input port. =20 Regards, Maarten _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these. =20 1 Provide a transparent client/server relationship...which means: - all client bits treated equally - client bit ordering preserved - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols - the traffic behaviour of client X must not impact the performance experienced by client Y =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs) =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology. =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise. =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones). =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong. =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim. =20 regards, Neil =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , =B3=AD=CB=CD mpls-tp@ietf.org =09 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ------=_NextPart_001_0002_01C9C420.B75CF550 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Greg, The reason I have placed UNIs also as peers of = the EVC is=20 because many operators provide this type of service today. = E.g. when a packet transport network provides=20 interconnection between an ISPs service edge router to a group of = DSLAMs, then=20 the service edge router of such ISP is connected to the PTN of the = network=20 operator via a rooted-mp EVC that has an endpoint in the service = edge=20 router and in the group of DSLAMs (case of ATM DSLAMs). With the=20 introduction of VDSL2 and fiber DSLAMs into the network, the EVC = endpoints will=20 be in the home gateways or in the end-user terminal equipment (STB, PC, = VoIP=20 telephone, ...). I have illustrated these three cases in the = attached=20 slides 1 to 3. Slides 4 to 6 illustrate some examples of EVC = maintenance=20 entity groups that could be defined for those three=20 cases. Another case is carrier-carrier services. = Carrier A wants=20 to interconnect with a number of remote network termination devices = which=20 are located behind the network of a regional carrier B. E.g. 10 NT = devices, each=20 connected with a fast ethernet interface to carrier B network. Carrier A = network=20 connects via 1GE interface to carrier B network. Two scenarios are now=20 possible: 1) each fast ethernet interface carries a = single VLAN=20 service, which is carried as an EVC through the network of carrier B = towards the=20 interface with carrier A. At this interface the 10 EVCs are multiplexed = onto the=20 1GE interface. The EVCs are now commonly owned by carrier A and B, and = possibly=20 by the customer. Carrier B monitors those 10 EVCs via a TCM MEG=20 level. 2) each fast ethernet interface carries a = number of VLAN=20 services, each identified by a C-Tag. This group of services is treated = as a=20 port based service in the network of carrier B. This port based service = (section=20 VLAN (EVS)) is treated as EVC in carrier B's network and often = identified by=20 means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 EVSs of the = customers)=20 are multiplex into the 1GE interface and delivered to carrier A's = Virtual UNI-N=20 port. Carrier A's V-UNI-N port treats those 10 EVCs of carrier B as 10 = EVPs,=20 each EVP carrying multiple EVC signals. Each carrier A EVC signal is = traffic=20 conditioned, and gets EVC OAM in the EVC TCM MEP functions located in = this=20 V-UNI-N port card. - The EVCs in carrier B's network have their = endpoints in=20 customer edge equipment and in the V-UNI-N port of carrier A. For the = customer=20 this is an EVS endpoint, while for the carrier A this is an EVP = endpoint.=20 Carrier B's EVC peers as such with carrier A and customer for this = EVC and=20 carrier B will monitor its EVC via a TCM MEG level. - The EVCs in carrier A network have their = endpoints in the=20 customer network (e.g. customer edge equipments). Carrier A deploys a = TCM MEG=20 level to monitor this service. Regards, Maarten From: Greg Mirsky = [mailto:gregimirsky@gmail.com]=20 Sent: donderdag 23 april 2009 2:15 To: Maarten=20 Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path = requirements Dear Maarten, I agree with your presentation of layers but = only=20 wonder why you've placed UNIs both as clients of EVC layer as well as = its peers.=20 I'd leave UNIs only as clients of EVC layer. Would you=20 agree? Regards, Greg 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com= > Dear=20 Greg, Thank you=20 for this confirmation. This other=20 layer is that the EVC layer as illustrated in the figure=20 below? =20 = UNI           &nbs= p;            = ;            =             &= nbsp;       =20 UNI --||-------         = ;            =             &= nbsp;     =20    ---------||-----          =20 = |            =             &= nbsp;           &n= bsp;  =20    | UNI  =20 -------------------------------------------------   =20 UNI --||----|         &= nbsp;      =20 EVC=20 = layer           &n= bsp;        =20 |-----||-----        =20 -------------------------------------------------           &nbs= p;  | MPLS-TP=20 layer |    |  other layer = |           &nbs= p;  -----------------   =20 ---------------- MEF's=20 E-Tree is a bidirectional rooted-multipoint connection, in = which=20 frames are forwarded on the basis of the value in their DA field. Such = selective forwarding is not supported in an LSP connection. An LSP = connection=20 will as such just support one EVC link connection, i.e. a = part of=20 the EVC between two adjacent EVC switch/bridge functions. Those p2p = EVC link=20 connections simply require non-selective forwarding, something that an = LSP=20 connection can provide. Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00=20 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path = requirements Dear Maarten, I think you've captured my view pretty = accurately.=20 Since MPLS-TP supports only p2p and p2mp transports it would be = responsibility=20 of another layer to support specific services among UNI-Ns. = Interesting thing=20 that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP = LSP=20 since by MEF's definition E-Tree is a bidirectional service. (Just a=20 note). Kind regards, Greg 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com> Dear=20 Greg, Do you=20 mean that there is a layer network above MPLS-TP that will support = these=20 services from UNI-N port to UNI-N port, and that MPLS-TP will = support this=20 service layer network? Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten=20 Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org=20 Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements Dear Maarten, I believe that it is not a requirement = for=20 MPLS-TP to support any specific service, including ones you've = listed in=20 your message. On the other hand, support of listed services is a = requirement=20 for a client layer that uses MPLS-TP = services. Regards, Greg=20 Mirsky 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com> Neil, I=20 expect that the main requirement for a packet = transport network=20 technology like MPLS-TP is that it is able to support at least the = following services: -=20 E-Line -=20 E-Tree -=20 E-LAN - PDH=20 CES in a=20 traffic engineered and managed manner. Another main requirement is that it must be able to = support those=20 services in a scalable manner between points anywhere in the=20 world. The=20 E-Line, E-Tree and E-LAN services allow to reorder = client frames that=20 belong to different priorities and to drop client frames that = are=20 drop eligible. The=20 E-Tree and E-LAN services require that client bits are read to = deliver the=20 frames to the appropriate output port or ports of the E-Tree = or E-LAN=20 supporting transport entity/differentiated = connection. The=20 packet transport network technology must as such support traffic=20 engineered transport entities (differentiated connections) = with n=20 input ports (i.e. multi source constructs). This in addition of = traffic=20 engineered transport entities with 1 input = port. Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = neil.2.harrison@bt.com Sent: dinsdag = 21 april=20 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path=20 requirements Liu, If MPLS-TP is going to be taken seriously as a transport = network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. 1    Provide a transparent client/server=20 relationship...which means: -    all client bits treated=20 equally -    client bit ordering=20 preserved -    no attempt to infer client symbol (ie = sequence=20 of client bits) meaning and no attempt to change client=20 symbols -    the traffic behaviour of client X = must not=20 impact the performance experienced by client Y A key corollary of the above is that MPLS-TP must only = support=20 proper connections (ie single source = constructs) 2   Since MPLS-TP is a transport network it is = not a=20 top-of-stack network (ie it does not support directly external=20 message/file/stream applications). MPLS-TP therefore does = not=20 require an E-NNI specification. A key corollary of this is = that=20 MPLS-TP will not have any peer interworking relationship with any = other=20 network mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. You = could argue=20 this should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE = (also a=20 co-ps mode network) should have FDI/AIS we concluded that on = balance it=20 was not a good idea.....and note that initially I was in favour of = having=20 AIS, but my colleagues provided strong technical arguments that = convinced=20 me otherwise. AIS/FDI is historically linked to the early = PDH co-cs=20 mode layer networks that used TTL logic. When this died it = put out a=20 +5V (all 1s) signal by default, ie it required no conscious effort = to=20 generate it.....this is key point. Further, in these = networks there=20 is a fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never = specified=20 AIS for IP and its why IEEE had the good sense to throw-out AIS in = 802.1ag=20 for Ethernet (though ITU have unwisely IMO retained it in = Y.1731....but I=20 suspect any operator planning to use Ethernet equipment would = always look=20 to IEEE stds and not ITU ones). AIS/FDI and the co-ps mode is = debatable. As I=20 noted above, on balance we considered not a good idea for PBB-TE = OAM=20 because it requires a conscious effort to generate it (unlike the = co-cs=20 mode) so there are likely to be scaling problems and its one more = thing to=20 go wrong. You should also have seen me make the point = many times=20 in the past that the always-on defect detection/handling OAM needs = to be=20 as simple/sparse as possible with as little config as possible = because we=20 need super reliability......TCM goes completely against the grain=20 here. Also note that the OAM required for each of the 3 = network=20 modes is not the same, despite what some=20 claim. regards, = Neil From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = liu.guoman@zte.com.cn Sent: 21 = April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: = mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path=20 requirements Deborah: maybe what you=20 said is right. but I can't completely agree your opinions. IMO. = mpls-tp=20 is regard as transport network like SDH/SONET. so it should have = AIS/FDI=20 fuctions as SDH/SONET. do=20 you think so. best=20 regards liu = "B= RUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47= =CA=D5=BC=FE=C8=CB "Maarten Viss= ers" <maarten.vissers@huawei.com>, <neil.2.harrison@bt.com> =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] Asso= ciated=20 bidirectional transport path=20 requirements "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten Vissers" = <maarten.vissers@huawei.com>, = <neil.2.harrison@bt.com> =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 size=3D2>I agree with Neil, it is very questionable the = value of=20 AIS/FDI in a packet network- any mode. It can result in a DoS = attack=20 by an operator on themselves so even Y1731 recommends not to = block=20 data frames: "A MEP can decide whether it blocks data frames = when it=20 detects dAIS. The principle requirement that influences = this=20 decision is that data frames ought to be forwarded as much as = possible, without the possibility of forwarding wrong data = frames=20 downstream." Table I.7-2 shows for AIS, not to = block. And as=20 Y1731 states, AIS can only be used under very=20 constrained architectures - if required for MPLS-TP, it needs = to have=20 the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a point-to-point ETH connection, a MEP has = only a=20 single peer MEP. Therefore, there is no ambiguity = regarding the=20 peer MEP for which it should suppress alarms when it receives = the ETH-AIS information." So should only be within one = domain -=20 then no need. Deborah -----Original = Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport = path requirements Neil, >=20 but AIS/FDI in the cl mode?...do me a favour! Ethernet = AIS is=20 indeed a requirement and a necessity. And you will = not be able to=20 understand that as long as you refuse to accept that = "cl-mode" is=20 a forwarding mode within a **transport entity**. G.800 = amendment 1=20 has finally reintroduced this transport entity into G.800. = Besides=20 that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is = a=20 transport entity that transfers information belonging to = multiple=20 communications between ports across a subnetwork. <..> = In a=20 differentiated connection message contents are interpreted = to=20 identify (sets of) communications which=20 receive different treatment. The sets of = communications may=20 be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms of=20 G.800 "differentiated connections". Ethernet AIS provides = AIS=20 within the scope of such "differentiated = connection". If you apply=20 this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and core = domains=20 interconnecting EVC matrices. When one of those EVC links = is=20 interrupted, e.g. in the core between metro 1 and metro 4 = (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS = is=20 inserted in the downstream direction to suppress the EVC-LOC = alarms=20 at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet AIS)=20 frame has a reserved multicast address, which guarantees that = the AIS=20 is broadcast to the endpoints of the EVC. I believe that = it is=20 time for you to adapt your view on co and cl = modes and relate it=20 to the forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP = differentiated connection"=20 with a billion or more ports. What we know as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN is=20 essentially an "Ethernet differentiated connection" with n = ports=20 (n in the range of e.g. 2 to 1000). What we know as a p2p = MPLS E-LSP=20 is essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection" with=20 2 ports. Transport network OAM applies to transport = entities,=20 which are (in terms of G.800 am1) connections and = differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 = april=20 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements John, = Thanks=20 this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting = a wee=20 bit tired of folks trying to make all 3 network modes look = alike=20 (and then, even worse, interwork them as as peers...esp = when not=20 not top-of-stack networks...I mean how silly can we get?). = I=20 am even more frustrated by the fact those peddling this FUD = only ever=20 seem to consider OAM and forget all other DP/CP/MP = components (esp=20 top-of-stack message/file/stream application adaptations). = How=20 wrong can this get! In the co modes a *connection* is a = very=20 specific and *constraining* construct.....I am assuming here = we=20 respect the rules of a connection (ie single source) = though some=20 folks don't even bother to respect this, and this is = despite the=20 fact that we all know what problems = multiple-source constructs can=20 cause (from LDP/PHP....ergo MPLS-TP). When we have a = connection=20 this restricts *all* DP (ie traffic and OAM) to stay = within the=20 bounds of the connection. Which is fine=20 under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is = broken.=20 In a nutshell what this means is that OAM that is of = a=20 request/response nature cannot be trusted in co mode networks = under=20 misconnectivity defects.....indeed, why should a = leaking DP have a=20 symmetric go/return defect behaviour?....very likely it=20 won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts to = explain=20 that physics....G.805 does not. So, the 3 modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the=20 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Drake, John=20 E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; = Alexander=20 Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > = requirements >=20 > Italo, > > As described in the MPLS TP OAM = Requirements I-D, virtually all of the > OAM functions = require=20 a return path, and in the absence of a return > path they = are=20 disabled. > > As described in David Sinicrope's = meeting=20 minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/w= iki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the issue=20 of return path for unidirectional LSPs could be > = charaterized=20 as the elephant in the room. In the MPLS TP OAM > = Framework=20 I-D, unicast LSPs are only mentioned three times and return = >=20 paths not at all. > > Thanks, > > = John >=20 > -----Original Message----- > > From: BUSI ITALO = [mailto:Italo.Busi@alcatel-lucent.it] > > = Sent:=20 Friday, April 17, 2009 1:59 AM > > To: Drake, John E; = Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path > >=20 requirements > > > > John, > > = > >=20 I might have missed the agreement of MPLS-TP being capable of = >=20 > sending replies to OAM requests sent on uni-directional=20 LSPs. > > > > This requirement does not = belong to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken = into=20 account (at worst in a > subsequent phase). > > = >=20 > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility = to work=20 w/o IP > > forwarding and the need for OAM to continue = to=20 monitor the data > > plane also in case of failures = affecting=20 the control or management > > plane). > > = >=20 > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = >=20 > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Drake, John=20 E > > > Sent: Thursday, April 16, 2009 8:00 = PM > >=20 > To: Alexander Vainshtein; Maarten Vissers > > > = Cc: mpls-tp@ietf.org > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 requirements > > > > > > At the meeting = last=20 fall at Juniper in Massachusetts, I > > think it = was >=20 > > agreed that an MPLS TP network needs to have a=20 forwarding > > capability > > > for = management,=20 control, and OAM packets (e.g., sending > > replies to=20 OAM > > > requests sent on uni-directional LSPs) = even if it=20 does not > > have an IP > > > forwarding = data=20 plane. > > > > > > > -----Original=20 Message----- > > > > From: Alexander = Vainshtein >=20 > > [mailto:Alexander.Vainshtein@ecitele.com] > = > >=20 > Sent: Thursday, April 16, 2009 9:57 AM > > > = > To:=20 Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Maarten, > > > > It seems that you've just = (implicitly=20 and, probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will = not=20 ever support MIP loopback function > > (and = fault > >=20 > > localization which requires this function ) = for > >=20 unidirectional P2MP > > > > and P2P = paths. > >=20 > > > > > > If this statement is correct, = this=20 (IMHO and FWIW) > raises a valid > > > >=20 question: > > > > > > > > = =20 Is MPLS-TP an=20 appropriate solution for these > types of = transport > >=20 > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > = functionality=20 today > > > > for (unidirectional - but it does = not know=20 any other > > type) P2P LSPs > > > > as=20 described in RFC 4379. And its extension to P2MP LSPs seems = >=20 > > > easy... > > > > > > > = >=20 > > > > > > > > = Regards, >=20 > > > > > > > = Sasha >=20 > > > > > > > > > > > = >=20 > > > ________________________________________ > = >=20 > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > = > >=20 Sent: Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Adrian, > > > > > > > > >>=20 <quote> > > > > >> = The=20 intermediate nodes (including MEPs, MIPs and > > > = >=20 other internal > > > > >> = =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of = that > >=20 > > >> transport path. > = >=20 > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > is, there is > > > > >=20 *nothing* that can be observed from a black box point of > = >=20 > view that > > > > > results from adhering = to this=20 requirement. > > > > > > > > Your = understanding is not correct. It is very much > observable = if > > > > this requirement is met from a black = box point=20 of view. > > > > The MIP functions can only = perform the=20 Loopback when there is a > > > > co-routed = bidirectional=20 transport path. The MPLS-TP LBM packet > > > > = received=20 at a MIP needs to be returned (as LBR > > > > = packet) to=20 the originating MEP function via the other > > = direction=20 of > > > > the co-routed bidirectional transport = path.=20 This other > direction > > > > would not be = available in an associated bidirectional transport > > = >=20 > path... and thus the loopback test > > > would=20 fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not in a > > > > associated = bidir=20 transport path. In the first case the TCM MEP > > > = >=20 Source and Sink functions are co-located and can > = exchange what=20 is > > > > called "remote information" which is = necessary=20 for performance > > > > monitoring. > > = >=20 > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, > >=20 > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = > Your=20 understanding is not correct. This text must not be > > = deleted=20 at > > > > all. > > > > > = > >=20 > > Actually, I am quite fed up about this = persistent > >=20 > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > >=20 is > > > > poorly > > > > > = specified=20 and comes from the monitoring of a path that is > > = > >=20 parallel (i.e. > > > > tandem) > > > = >=20 > to the data path being monitored. This definition of = TC >=20 > > > seems to be at > > > > = variance, >=20 > > > > and would be if the ACH was actually in=20 band. > > > > > > > > I don't = understand=20 where your interpretation of tandem > > connection = is >=20 > > > described in ITU-T recommendations. I.e. "from=20 the > > monitoring of a > > > > path = that is=20 parallel (i.e. tandem) to the data path being > > > = >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection is = a=20 set > > > > of interconnected "link connections" = and=20 "matrix > connections". A > > > > subset of = those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to as > = a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There=20 is only additional OAM inserted inside the data > path by=20 the > > > > TCM MEP_So function and this OAM is = extracted=20 from the > > data path by > > > > the = TCM MEP_Sk=20 function. > > > > > > > >=20 Regards, > > > > Maarten > > > > = >=20 > > > > > > > -----Original=20 Message----- > > > > From: mpls-tp-bounces@ietf.org > > > = >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Adrian=20 Farrel > > > > Sent: donderdag 16 april 2009=20 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > >=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > > = Unfortunately=20 I cannot fully agree with your statement: > > > > = > > > > > > <quote> > > > = >=20 > From the point of view of hardware, = co-routed >=20 > > bidirectional LSPs > > > > > = =20 are a special case of associated bidirectional LSPs. > = > >=20 > > <end quote> > > > > > > = >=20 > > > This statement would be obviously correct, were = it not=20 for > > > > Requirement > > > > = > 34 in=20 the latest MPLS-TP requirements draft > > > > = >=20 > > > OK. Got it. > > > > > > = >=20 > But what is this doing in the data plane requirements=20 section? > > > > > > > > In fact, = what is=20 this requirement actually saying? > > > > = > >=20 > > > <quote> > > > > > = =20 The intermediate nodes (including MEPs, MIPs and > = > >=20 other internal > > > > > =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > = > >=20 > > relationship of the forward and = the=20 backward > > > > directions of that > > = >=20 > > transport path. > > > = >=20 > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > = > is,=20 there is > > > > *nothing* that can be observed = from a=20 black box point of > > view that > > > > = results=20 from adhering to this requirement. > > > > = > >=20 > > Therefore it could be assumed that this requirement is = met by=20 > > > > configuring some data plane database = component=20 through the > > > > management plane. The = database=20 component is not used > for anything > > > = > except=20 to satisfy this requirement for "awareness". > > > = >=20 > > > > Ben! Can we please try to rewrite this=20 requirement in terms of > > > > = behavior? > >=20 > > > > > > > Please note that = Requirement 34=20 is the ONLY item in the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = >=20 > paths are > > > > > exactly the same even = if they=20 appear in two different > > > items in the > = > >=20 > > requirements' list). > > > > > In = other=20 words, without Requirement 34 the notion of > = co-routed >=20 > > > > bidirectional paths would be void of any = data plane=20 content. > > > > > > > > > > = The=20 somewhat vague scope of this requirement ("other internal = > >=20 > > > functions as appropriate") creates a suspicion = that=20 HW > > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with = it. >=20 > > > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > MIPs and other > > = >=20 > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate=20 nodes." > > > > > > > > > The=20 following text in the draft increases this suspicion: > = > >=20 > > > > > > > <quote> > > = >=20 > > Tandem Connection: A tandem connection is = an >=20 > arbitrary part of a > > > > > = transport=20 path that can be monitored (via OAM) > > > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of a=20 transport path. > > The tandem > > > = >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > > > > = > =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = >=20 > Actually, I am quite fed up about this persistent > = >=20 insistence on the > > > > inclusion of "Tandem=20 Connection." The definition within > > the ITU-T = of >=20 > > > this term is poorly specified and comes from = the >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > = >=20 > > > > > > Doesn't "forwarding engine" = sound like=20 hardware to you? > > > > > > > > = Yes, but=20 so what? > > > > > > > > > = IMHO it is=20 worth noting that neither the MPLS-TP > > > = Requirements=20 draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > > > > > > > > = >=20 > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed in=20 the MPLS-TP OAM > > Framework > > > > = >=20 draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-fr >=20 > > > amework-00.txt > > > > ). > = >=20 > > > > > > Right. > > > > = Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some clarity=20 regarding > > > co-routed vs. > > > > = >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 to=20 specific > > > functionality. > > > > = > > > > Agreed. > > > > > = >=20 > > Adrian > > > > > > > > = >=20 > > > > > > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > = Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > Not really = sure=20 whether you are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one of Ben's = messages is that associated > > > > >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will = have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > = > This=20 is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > = >=20 > > a special case of associated bidirectional = LSPs. > >=20 > > > > > > If you can set up two = unidirectional=20 LSPs (e.g. using the > > management > > > = >=20 plane) you can surely set up a co-routed > > > = bidirectional=20 LSP. > > > > > > > > There are = shipping=20 solutions that achieve co-routed > bidirectional > = > >=20 > LSPs using the control plane. These either use the = GMPLS >=20 > (which is > > > > cleaner) or non-standard=20 proprietary solutions (which is > > messy but > = > >=20 > functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are software > > > > = solutions. >=20 > > > > > > = > >=20 2. My reading of one of Neil's messages is that the = actual > >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > = >=20 transport networks rather than any specific benefit. > = > >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, >=20 > > > feel, and behavioral characteristics of a=20 "legacy" > > > > transport network. > > = >=20 > > > > > > Based on these observations, = I'd guess=20 (FWIW) that: > > > > > * associated = bidirectional=20 paths are, at least for the time > > > > > = =20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = >=20 > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other = upgrades to=20 existing MPLS solutions will be > needed to reach > = >=20 > > the full function level of MPLS-TP. > > > = >=20 > > > > > * they had a good chance to remain = the only=20 type of > > bidirectional > > > > > = =20 paths in real deployments. > > > > > = >=20 > > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 _______________________________________________ mpls-tp = mailing=20 list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ----------------------------------------------------= ---- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ________________________________= _______________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp = ------=_NextPart_001_0002_01C9C420.B75CF550-- ------=_NextPart_000_0001_01C9C420.B75CF550 Content-Type: application/vnd.ms-powerpoint; name="bb-backhaul-architecture-00.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bb-backhaul-architecture-00.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAXgEAAAAAAAAA EAAAYAEAAAEAAAD+////AAAAAFkBAABaAQAAXwEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////+A eh/wYQAAAC5IeV2+H1+Ve2COQKTt1lXWKAAAAAgAAAAIAAAAAQABAAAAAAAgAAAAiQsAAIkLAAAC AAAAAgAAAP///wAAAAAAZgAAAMwAAACZAAAAMwAAAGYAAADMAAAAmQAAADMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwDoA3VBAAAB AOkDKAAAAEIaAACwEwAA4BAAAIAWAAAFAAAACgAAAAUAAAAsAAAAAQAGAAAAAAEPAPIDkgIAAC8A yA8MAAAAMADSDwQAAAAAAAAADwDVB8gBAAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3ACAAUgBv AG0AYQBuAAAAVKkTAFSpEwBgPmAM3JYTAHg6CzDclhMAAAAAAA8A1QcAAAQiEAC3D0QAAABNAFMA IABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAFSpEwBUqRMAYD5gDNyWEwB4Ogsw3JYTAAAAAAAP ANUHgAAEIiAAtw9EAAAAi1tTTwAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABUqRMAVKkTAGA+ YAzclhMAeDoLMNyWEwAAAAAADwDVB4YABAIwALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAAABv AG0AYQBuAAAAVKkTAFSpEwBgPmAM3JYTAHg6CzDclhMAAAAAAA8A1QcCAAQCQAC3D0QAAABUAHIA ZQBiAHUAYwBoAGUAdAAgAE0AUwAAAGEAbgAAAFSpEwBUqRMAYD5gDNyWEwB4Ogsw3JYTAAAAAAAP ANUHAAAEIlAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMAVKkTAGA+ YAzclhMAeDoLMNyWEwAAAAAADwDVBwAABBIAAKQPCgAAAIEAQgABAAAAGQAAAKUPDAAAAAAAAAgu AAAAAgAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAA AAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJA AgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEIBsAAA8AAPAYGwAAAAAG8BgWAAA9BAsA wgIAAEABAAAJAAAAAAAAAA8AAAAAAAAAFgAAAAsAAAAIAAAAAAAAAAQAAAAAAAAAEAAAAAAAAAAE AAAAAAAAABMAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAADQAAAAAAAAAEAAAAAAAAAAoA AAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAA AAAAAAAEAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAeAAAA AAAAAAwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABQAAAAAAAAAHAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAA AAAGAAAAAAAAABEAAAAuAAAABgAAAC8AAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAAAAAAAAAEAAAAAAAAAGMAAAAAAAAA BAAAAAAAAACVAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAIAAAAAAAAAAcAAAAAAAAACAAAAAAAAAAH AAAAAAAAAAgAAAAAAAAAOwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAACAAA AAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAA AAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAACAAAAAAAAAAEAAAAXgAAAAwAAAAAAAAABwAAAAAAAAAHAAAAAAAAACMAAAAAAAAABwAAAAAA AAAGAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAALAAAAAAAA AAYAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAA CgAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAPwAAAAAAAAA9AAAAAAAAAG8AAAAAAAAABAAAAAAAAAAG AAAAAAAAAJkAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAAQAAAAAAAAAAIAAAAAAAAAAQA AAAAAAAABAAAAAAAAAA/AAAAAAAAAAYAAAAAAAAACAAAAAAAAAAFAAAAAAAAAIgAAAAAAAAABAAA AAAAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAHgAAAAAAAAAEAAAA AAAAADYAAAAAAAAABAAAAAAAAAA3AAAAAAAAAAQAAAAAAAAANwAAAAAAAAAEAAAAAAAAADwAAAAA AAAARgAAAAAAAAAzAAAAAAAAAEgAAAAAAAAAOAAAAAAAAABIAAAAAAAAAFkBAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAcAAAAAAAAACAAAAAAAAAAIAAAAAAAA AAYAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAAJAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAA EgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAF AAAAAAAAAAQAAAAAAAAAGgAAAAAAAAAdAAAAAAAAABEAAAAAAAAABAAAAAAAAABGAAAAAAAAABwA AAAAAAAAMAAAAAAAAAAwAAAAAAAAADIAAAAAAAAAMAAAAAAAAAAqAAAAAAAAADcAAAAAAAAAMwAA AAAAAABTAAAAAAAAAEgAAAAAAAAA7QAAAAAAAAA+AQAAAAAAAAUAAAAAAAAARwAAAAAAAAAEAAAA AAAAAIMAAAAAAAAABAAAAAAAAADYAQAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAJwAAAAA AAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAHAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAuAAAAAAAAAAQAAAAAAAAAkwAAAAAAAAB/AAAAAAAA AFYAAAAAAAAANgAAAAAAAACTAAAAAAAAAGQAAAAAAAAAHgAAAAAAAABQAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAFAAAAAAAAAAkAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAE AAAAAAAAAIwAAAAAAAAAOQAAAAAAAAAoAAAAAAAAACMAAAAAAAAACAAAAAAAAAAEAAAAAAAAAAwB AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAKQAAAAAAAAACAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAAawAAAAAAAABLAAAAAAAAAFUAAAAAAAAABgAAAAAAAAAIAAAA AAAAAAYAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAABoAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAUAAAAAAAAACEAAAAAAAAAAQAAAAAAAAABgAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAA AAYAAAAAAAAACAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAA HAAAAAAAAABLAAAAAAAAAFUAAAAAAAAATAAAAAAAAADEAAAAAAAAAAcAAAAAAAAACAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAAowAAAAAAAAAEAAAAAAAAADkAAAAAAAAABQAAAAAAAAAIAAAAAAAAAAcA AAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA8AAAAAAAAAC8AAAAAAAAALAAA AAAAAAAOAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAGAAAAAAAAAM8AAAAAAAAABAAAAAAAAAAEAAAA AAAAAAYAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA0QAAAAAAAAAEAAAAAAAAAAUAAAAA AAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAADgAAAAAAAAABAAAAAAA AAAEAAAAAAAAAHEAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAGAAAAAAAA AAgAAAAAAAAA9gAAAAAAAAAGAAAAAAAAAAQAAAAAAAAAPQAAAAAAAAAEAAAAAAAAAAUAAAAAAAAA BQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAALwAAAAAAAAABAAAAAAAAAAG AAAAAAAAAB0BAAAAAAAACAAAAAAAAAAEAAAAAAAAADkBAAAAAAAATQAAAAAAAAANAQAAAAAAAKYA AAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAABTAQAAAAAAAAQAAAAAAAAABQAA AAAAAAAIAAAAAAAAAM4AAAAAAAAAqwAAAAAAAADpAAAAAAAAAFoAAAAAAAAAWgAAAAAAAAByAAAA AAAAAAQAAAAAAAAABAAAAAAAAADFAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAA AAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAADgAQAAAAAAAAQAAAAAAAAABgAAAAAA AABsAAAAAAAAALYBAAAAAAAAagAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAACVAAAAAAAA AAQAAAAAAAAAowAAAAAAAACfAAAAAAAAAJ4AAAAAAAAAoQAAAAAAAAC/AAAAAAAAAAYAAAAAAAAA BQAAAAAAAAAEAAAAAAAAAKUAAAAAAAAABAAAAAAAAABXAAAAAAAAAJ0AAAAAAAAABAAAAAAAAACV AAAAAAAAAAQAAAAAAAAAewAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAABHAAAAAAAAAMoA AAAAAAAAggAAAAAAAABjAAAAAAAAAI8AAAAAAAAATwAAAAAAAABwAAAAAAAAAE0AAAAAAAAAOAAA AAAAAABvAAAAAAAAAKcAAAAAAAAABAAAAAAAAABpAAAAAAAAAMcAAAAAAAAAawAAAAAAAACVAAAA AAAAALEAAAAAAAAANQAAAAAAAAB7AAAAAAAAAJAAAAAAAAAASQAAAAAAAAAqAAAAAAAAAAQAAAAA AAAAMwAAAAAAAAAuAAAAAAAAADoAAAAAAAAAZQAAAAAAAABPAAAAAAAAAOEAAAAAAAAABwAAAAAA AAA7AAAAAAAAAEcAAAAAAAAAtAAAAAAAAABLAAAAAAAAAE4AAAAAAAAABgAAAAAAAAAGAAAAAAAA AEsAAAAAAAAAEgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAFAAAAAAAAABEAAAAAAAAA FgAAAAAAAAAFAAAAAAAAAAgAAAAAAAAALAAAAAAAAAAEAAAAAAAAADkAAAAAAAAABAAAAAAAAABd AAAAAAAAAFYAAAAAAAAABAAAAAAAAAAWAAAAAAAAAAQAAAAAAAAA1AAAAAAAAAAsAQAAAAAAABwA AAAAAAAAXAAAAAAAAAAEAAAAAAAAAFwAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAA AAAAAABtAAAAAAAAADgAAAAAAAAABAAAAAAAAAAWAAAAAAAAAAQAAAAAAAAABAAAAAAAAACBAAAA AAAAAFoAAAAAAAAAXQAAAAAAAACAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAXAAAAAAAAABYAAAAAAAAADgAAAAAAAAAXAAAAAAAAADwAAAAAAAAALAAAAAAA AAAcAAAAAAAAAEQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAGgAAAAAAAAAmAAAAAAAA ABoAAAAAAAAAKwAAAAAAAABkAAAAAAAAAAQAAAAAAAAAGgAAAAAAAAAnAAAAAAAAAEAAAAAAAAAA BAAAAAAAAABvAAAAAAAAAFoAAAAAAAAABAAAAAAAAABsAAAAAAAAAEAAAAAAAAAAjAAAAAAAAABa AAAAAAAAAEUAAAAAAAAAgwAAAAAAAABLAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAFsA AAAAAAAAdwAAAAAAAAAGAAAAAAAAAAgAAAAAAAAAYwAAAAAAAABXAAAAAAAAAAQAAAAAAAAAfQAA AAAAAAAxAAAAAAAAADIAAAAAAAAABAAAAAAAAABDAAAAAAAAAAQAAAAAAAAANAAAAAAAAAAEAAAA AAAAACUAAAAAAAAAKwAAAAAAAABFAAAAAAAAAAQAAAAAAAAANgAAAAAAAABBAAAAAAAAACQAAAAA AAAAJAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABgAAAAAAAABYAAAAAAAAAFgAAAAAAAAAfgAAAAAA AACAAAAAAAAAAEAAAAAAAAAAWAAAAAAAAABAAAAAAAAAAE4AAAAAAAAAaAAAAAAAAAAvAAAAAAAA AGQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAsAAAAAAAAARgAAAAAAAAA2AAAAAAAAAD4AAAAAAAAA PgAAAAAAAADWAAAAAAAAAAQAAAAAAAAAWgAAAAAAAACHAAAAAAAAAJkAAAAAAAAAsgAAAAAAAAAU AQAAAAAAAFYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAEEAAAAAAAAAVwAAAAAAAAAEAAAAAAAAAFEA AAAAAAAAXAAAAAAAAABiAAAAAAAAAFYAAAAAAAAAdwAAAAAAAAAxAAAAAAAAAEgAAAAAAAAAOQAA AAAAAAChAAAAAAAAALoAAAAAAAAArgAAAAAAAABDAAAAAAAAAD4AAAAAAAAAQAAAAAAAAAAEAAAA AAAAADgAAAAAAAAAOAAAAAAAAAAvAAAAAAAAADsAAAAAAAAAcQAAAAAAAAAEAAAAAAAAAF4AAAAA AAAAeAAAAAAAAACXAAAAAAAAAIoAAAAAAAAAegAAAAAAAACdAAAAAAAAACsBAAAAAAAAMwEAAAAA AAA+AAAAAAAAACYAAAAAAAAAJgAAAAAAAAAYAAAAAAAAAEsAAAAAAAAAQAAAAAAAAAA6AAAAAAAA ADsAAAAAAAAAVwAAAAAAAABDAAAAAAAAABwAAAAAAAAALQAAAAAAAAAhAAAAAAAAAEYAAAAAAAAA GwAAAAAAAAAYAAAAAAAAABgAAAAAAAAAHwAAAAAAAAA4AAAAAAAAADgAAAAAAAAAFgAAAAAAAAAq AAAAAAAAACcAAAAAAAAAIgAAAAAAAAAjAAAAAAAAACMAAAAAAAAABAAAAAAAAABQAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAFAAAAAAAAAFAAAAAAAAAABQAAAAAAAABfAAAAAAAAAC8AAAAAAAAAKAAA AAAAAAAuAAAAAAAAAAQAAAAAAAAAUQAAAAAAAABpAAAAAAAAAFgAAAAAAAAAWgAAAAAAAAAbAAAA AAAAAF0AAAAAAAAA9gAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAABAAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAXgAAAAAAAAAEAAAAAAAAAMwAAAAAAAAABAAAAAAA AAAHAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAA AAYAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAEIAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAHwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAACAAAAAAAAADL AAAAAAAAADgAAAAAAAAABwAAAAAAAABYAAAAAAAAAAQAAAAAAAAABAAAAI0CAABGAAAAAAAAACsA AAAAAAAABgAAAJACAAA1AAAAkQIAADQAAAAAAAAAMAAAAAAAAAAtAAAAkgIAADwAAACTAgAAPQAA AJQCAAA9AAAArwEB8HgEAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAA AAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAgAH8CQAAAAA AAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAA AAAAAP8AAAAAAAAAAAAAAAAAAAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAA AAAAAAAAAAAAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAACAAfw JAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAAIAB/AkAAAAAAAAAAAAAAAA AAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAA AAAAAAAAAAAAAAAAAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAA AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAgAH8CQAAAAAAAAA AAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAA AP8AAAAAAAAAAAAAAAAAAAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAA AAAAAAAAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAACAAfwJAAA AAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAA AAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAA AAAAAAAAAAAAAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAAIA B/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAgAH8CQAAAAAAAAAAAAA AAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8A AAAAAAAAAAAAAAAAAAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAA AAAAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAACAAfwJAAAAAAA AAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAHIAB/AkAAAABwcuSHldvh9flXtgjkCk 7dZV/wBpAAAAOAAAAAAAAAAAAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ARAAEADAAQEA AAjFQQAAAAD/AQgACAABAgIAAAiAABrxIAAAAAAAAAD//wAA//9mAMyZAACWlpYATU1NAGb/MwAA gAAAQAAe8RAAAAAAAAAA////////////////HwDwDxwAAAAAAPMDFAAAAEAAAAAAAAAAAAAAAAMA AIAAAAAADwDQB3ALAAAfABQEHAAAAAAAFQQUAAAAJPpKCQDKmjsFwN8jAMqaOwACAAAPAPoDZwAA AAAA/gMDAAAAAAEAAAD9AzQAAABDAAAAZAAAAEMAAABkAAAAAAAAAIzEYAz0lhMAeDoLMAAAAAAA AAAAxPz//47///8BABMAcAD7AwgAAAAAAAAA2AkAAHAA+wMIAAAAAQAAACENAAAfAP8DFAAAAAIA AAQMAAAAAAAAAAAAAAACAAAAHwD6A0cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQgAAAGQAAABCAAAA ZAAAAAEAAACoPGAM9JYTAHg6CzAAAAAAAAAAAAAAAAAAAAAAAQATAB8AEwQ8AAAAAAD9AzQAAABk AAAAZAAAAGQAAABkAAAAIJcTABL0CjBUqRMAPD5gDAAAAAAAAAAAAAAAAAAAAAAAARMAHwAIBDwA AAAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAAglxMAEvQKMFSpEwA8PmAMAAAAAAAAAAAAAAAAAAAA AAAAEwAPAIgT4gkAAA8AihNoAAAAAAC6DxQAAABfAF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAA DwCIFzwAAAAAAIkXNAAAAAAAAAAAAAAAAAAAAFgCAAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAA AAAAAAAAAIACAeAPAIoT+AgAAAAAug8WAAAAXwBfAF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAA QAAaEGYFAAAFAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoA QQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABv AGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoA AQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAE AAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQA AAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBs AAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAA aAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAA AAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAA AAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAA AQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAA AAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEG AAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwA AAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAA AQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFt ZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAA AAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAA AAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAA ACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAA AAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAAC AAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8A bgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAA AAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAHBAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAA IAAAAAEAAAABAAAAAAAAAAEAAADoAAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAA AAABAgAAAAEAAAAAAAABAwAAAAEAAAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIA AAAEAAAAAAAAAAMAAAAAAAAACgBBAHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBu AG8AdAB5AHAAZQAgAFQAeQBwAG8AZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAA AAAAAAAABAAAAA4ACQARAAAAGgABDwAbEEACAAAQAK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAI DAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAA AAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAA AAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAA CAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAA AAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIA AAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAA AAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAA aG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAAD AAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQA GAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEPAIoTMAAAAAAAug8QAAAAXwBfAF8A UABQAFQAMQAwAAAAixMQAAAAAAANBAgAAABwtQAAcLUAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQ AFAAVAA5AAAAixMUAAAALwDIDwwAAAAwANIPBAAAAAAAAAA/ANkPDAAAAAAA2g8EAAAAAAAlAE8A 2Q8MAAAAAADaDwQAAAANAD0ADwDwD68XAAAAAPMDFAAAAAICAAAEAAAAAgAAALgBAAAAAAAAAACf DwQAAAAAAAAAAACoDxYAAABXaG9sZXNhbGUgRVZDIE9wdGlvbiBJAACqDxQAAAAWAAAABgAAAAkI AAABAAAAAAAAABAAnw8EAAAAAQAAAAAAqA/OAAAAU2VydmljZSBFZGdlIHJvdXRlciBjb25uZWN0 cyB2aWEgRS1UcmVlIHNlcnZpY2Ugd2l0aCBlLmcuIDIwIEFUTSBEU0xBTXMgbG9jYXRlZCBpbiBv ZmZpY2VzDVJvb3RlZC1tcCBFVkMgc3RhcnRzIGluIHJvdXRlciBhbmQgZW5kcyBpbiBEU0xBTXMN UFROIGFuZCBJU1Agc2hhcmUgdGhlIEVWQw1GZXcgKGUuZy4gMjEpIE1BQyBhZGRyZXNzZXMgaW4g cm1wIEVWQw0AAKEPJgAAAFsAAAAAAAAAAAB0AAAAAQAAAAAAWwAAAAAAAAB0AAAAAAQAAAAEAACq D2IAAABBAAAABgAAAAkIAAAGAAAABwAAAAMACQgAAD8AAAAGAAAACQgAAAYAAAAHAAAAAwAJCAAA OgAAAAYAAAAJCAAAAwAAAAcAAAADAAkIAAAFAAAABgAAAAkIAAABAAAAAAAAAAAA8wMUAAAABAIA AAQAAAACAAAAuQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFwAAAFdob2xlc2FsZSBFVkMgT3B0aW9u IElJAACqDxQAAAAXAAAABgAAAAkIAAABAAAAAAAAABAAnw8EAAAAAQAAAAAAqA/NAQAAU2Vydmlj ZSBFZGdlIHJvdXRlciBjb25uZWN0cyB2aWEgRS1UcmVlIHNlcnZpY2Ugd2l0aCBlLmcuIDIwMDAw IHN1YnNjcmliZXJzIGNvbm5lY3RlZCB0byBlLmcuIDEwMCBWRFNMMiBvciBmaWJlciBEU0xBTXMg bG9jYXRlZCBpbiBzdHJlZXQgY2FiaW5ldHMNUm9vdGVkLW1wIEVWQyBzdGFydHMgaW4gcm91dGVy IGFuZCBlbmRzIGluIEhvbWUgR2F0ZXdheXMNUFROLCBJU1AgYW5kIEhHVyBzaGFyZSB0aGUgRVZD DU1hbnkgKHVwIHRvIGUuZy4gMjAwMDApIE1BQyBhZGRyZXNzZXMgaW4gcm1wIEVWQw1UcmFuc2xh dGUgQ3VzdG9tZXIgTUFDIGFkZHJlc3NlcyBpbnRvIFByb3ZpZGVyIENvbnRyb2xsZWQgQ3VzdG9t ZXIgTUFDIGFkZHJlc3NlcyB3aXRoIHN1Ym5ldCBzdHJ1Y3R1cmUgKE4gKGUuZy4gMzYpIE1TQiBp ZGVudGlmeSBEU0xBTSkgYW5kIGxlYXJuIDEwMCBzdWJuZXQgTUFDIGFkZHJlc3NlcyBpbiBQVE4A AKEPLgAAAJMAAAAAAAAQAABaADsBAAABAAAQAABLAJMAAAAAAAIAEwA7AQAAAAQCAAAEEgAAAKoP YgAAAGsAAAAGAAAACQgAAAUAAAAHAAAAAwAJCAAAAQAAAAYAAAAJCAAABgAAAAcAAAADAAkIAACd AAAABgAAAAkIAAADAAAABwAAAAMACQgAALYAAAAGAAAACQgAAAEAAAAAAAAAAADzAxQAAAAFAgAA BAAAAAIAAAC6AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8YAAAAV2hvbGVzYWxlIEVWQyBPcHRpb24g SUlJAACqDxQAAAAYAAAABgAAAAkIAAABAAAAAAAAABAAnw8EAAAAAQAAAAAAqA9MAgAAU2Vydmlj ZSBFZGdlIHJvdXRlciBjb25uZWN0cyB2aWEgRS1UcmVlIHNlcnZpY2Ugd2l0aCBlLmcuIDIwMDAw IHN1YnNjcmliZXJzLCAoZWFjaCB3aXRoIHVwIHRvIGUuZy4gMTYgZW5kIHRlcm1pbmFscykgY29u bmVjdGVkIHRvIGUuZy4gMTAwIFZEU0wyIG9yIGZpYmVyIERTTEFNcyBsb2NhdGVkIGluIHN0cmVl dCBjYWJpbmV0cw1Sb290ZWQtbXAgRVZDIHN0YXJ0cyBpbiByb3V0ZXIgYW5kIGVuZHMgaW4gRW5k IFRlcm1pbmFscw1QVE4sIElTUCBhbmQgRW5kIFRlcm1pbmFscyBzaGFyZSB0aGUgRVZDDU1hbnkg KHVwIHRvIGUuZy4gODAwMDApIE1BQyBhZGRyZXNzZXMgaW4gcm1wIEVWQw1UcmFuc2xhdGUgQ3Vz dG9tZXIgTUFDIGFkZHJlc3NlcyBpbnRvIFByb3ZpZGVyIENvbnRyb2xsZWQgQ3VzdG9tZXIgTUFD IGFkZHJlc3NlcyB3aXRoIHN1Ym5ldCBzdHJ1Y3R1cmUgKE4gKGUuZy4gMzYpIE1TQiBpZGVudGlm eSBEU0xBTSwgTSAoZS5nLiA0NCkgTVNCIGlkZW50aWZ5IHN1YnNjcmliZXIpIGFuZCBsZWFybiAx MDAgc3VibmV0IE1BQyBhZGRyZXNzZXMgaW4gUFROIGFuZCAyMDAgc3VibmV0IE1BQyBhZGRyZXNz ZXMgaW4gRFNMQU1zAAChDy4AAAC8AAAAAAAAEAAAUACRAQAAAQAAEAAAQQC8AAAAAAACABQAkQEA AAAEAgAABBEAAACqD3AAAACUAAAABgAAAAkIAAAFAAAABwAAAAMACQgAAAEAAAAGAAAACQgAAAYA AAAHAAAAAwAJCAAApwAAAAYAAAAJCAAAAwAAAAcAAAADAAkIAAD8AAAABgAAAAkIAAAGAAAABwAA AAMACQgAAAEAAAAAAAAAAADzAxQAAAAJAgAABAAAAAIAAAC8AQAAAAAAAAAAnw8EAAAAAAAAAAAA qA89AAAAV2hvbGVzYWxlIEVWQyBPcHRpb24gSQtNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAgKE1F RykgZXhhbXBsZQAAoQ8UAAAAPgAAAAAAAAAAAD4AAAAAAAIAHwAAAKoPFAAAAD0AAAAGAAAACQgA AAEAAAAAAAAAEACfDwQAAAABAAAAAACgD2oDAABUAGgAZQAgAHQAbwBwACAAbABlAHYAZQBsACAA RQBWAEMAIABNAEUARwAgAGgAYQBzACAAaQB0AHMAIABlAG4AZABwAG8AaQBuAHQAcwAgAGkAbgAg AHQAaABlACAAcgBvAHUAdABlAHIAIABhAG4AZAAgAEQAUwBMAEEATQBzAC4AIABJAHQAIABtAGEA eQAgAGgAYQB2AGUAIABNAEkAUABzACAAaQBuACAAdABoAGUAIAB3AGgAbwBsAGUAcwBhAGwAZQAg AGEAYwBjAGUAcwBzACAAbgBvAGQAZQAZIHMAIABVAE4ASQAtAE4AIABwAG8AcgB0ACAAYwBhAHIA ZAAuACAAUAByAG8ALQBhAGMAdABpAHYAZQAgAE8AQQBNACAAbQBhAHkAIAB1AHMAZQBkACAAdABv ACAAYwBoAGUAYwBrACAAcwB0AGEAdAB1AHMAIABvAGYAIAB0AGgAZQAgAEUAVgBDAC4ADQBUAGgA ZQAgAFAAVABOACAAaABhAHMAIABpAHQAcwAgAG8AdwBuACAARQBWAEMAIABNAEUARwAgAHcAaQB0 AGgAIABlAG4AZABwAG8AaQBuAHQAcwAgAGkAbgAgAHQAaABlACAAdwBoAG8AbABlAHMAYQBsAGUA IABhAGMAYwBlAHMAcwAgAG4AbwBkAGUAGSBzACAAVQBOAEkALQBOACAAcABvAHIAdAAgAGMAYQBy AGQAIABhAG4AZAAgAEQAUwBMAEEATQBzAC4AIABJAHQAIABtAGEAeQAgAGgAYQB2AGUAIABNAEkA UABzACAAaQBuACAAdABoAGUAIAB3AGgAbwBsAGUAcwBhAGwAZQAgAGEAYwBjAGUAcwBzACAAbgBv AGQAZQAZIHMAIABsAGkAbgBlACAAcABvAHIAdAAgAGMAYQByAGQALAAgAG0AZQB0AHIAbwAgAGMA bwByAGUAIABhAG4AZAAgAG0AZQB0AHIAbwAgAGUAZABnAGUAIABuAG8AZABlAHMALgAgAFAAcgBv AC0AYQBjAHQAaQB2AGUAIABPAEEATQAgAHcAaQBsAGwAIABjAGgAZQBjAGsAIABzAHQAYQB0AHUA cwAgAG8AZgAgAHQAaABlACAARQBWAEMAIABpAG4AIAB0AGgAZQAgAFAAVABOAC4AAAChDyAAAAC2 AQAAAAAAEAAAUAC1AQAAAAACABQAAQAAAAAAAgATAAAAqg98AAAAOgAAAAYAAAAJCAAABgAAAAcA AAADAAkIAAAOAAAABgAAAAkIAAAEAAAABwAAAAMACQgAAMMAAAAGAAAACQgAAAYAAAAHAAAAAwAJ CAAADgAAAAYAAAAJCAAABAAAAAcAAAADAAkIAACIAAAABgAAAAkIAAABAAAAAAAAAAAA8wMUAAAA CgIAAAQAAAACAAAAvQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPPgAAAFdob2xlc2FsZSBFVkMgT3B0 aW9uIElJC01haW50ZW5hbmNlIEVudGl0eSBHcm91cCAoTUVHKSBleGFtcGxlAAChDxQAAAA/AAAA AAAAAAAAPwAAAAAAAgAfAAAAqg8UAAAAPgAAAAYAAAAJCAAAAQAAAAAAAAAQAJ8PBAAAAAEAAAAA AKAP1gMAAFQAaABlACAAdABvAHAAIABsAGUAdgBlAGwAIABFAFYAQwAgAE0ARQBHACAAaABhAHMA IABpAHQAcwAgAGUAbgBkAHAAbwBpAG4AdABzACAAaQBuACAAdABoAGUAIAByAG8AdQB0AGUAcgAg AGEAbgBkACAAaABvAG0AZQAgAGcAYQB0AGUAdwBhAHkAcwAuACAASQB0ACAAbQBhAHkAIABoAGEA dgBlACAATQBJAFAAcwAgAGkAbgAgAHQAaABlACAAdwBoAG8AbABlAHMAYQBsAGUAIABhAGMAYwBl AHMAcwAgAG4AbwBkAGUAGSBzACAAVQBOAEkALQBOACAAcABvAHIAdAAgAGMAYQByAGQAIABhAG4A ZAAgAGkAbgAgAHQAaABlACAARABTAEwAQQBNAHMALgAgAE8AbgAtAGQAZQBtAGEAbgBkACAATwBB AE0AIABjAGEAbgAgAGIAZQAgAHUAcwBlAGQAIAB0AG8AIABjAGgAZQBjAGsAIABzAHQAYQB0AHUA cwAgAG8AZgAgAHQAaABlACAARQBWAEMAIABhAGYAdABlAHIAIABzAHUAYgBzAGMAcgBpAGIAZQBy ACAAYwBvAG0AcABsAGEAaQBuAHQALgANAFQAaABlACAAUABUAE4AIABoAGEAcwAgAGkAdABzACAA bwB3AG4AIABFAFYAQwAgAE0ARQBHACAAdwBpAHQAaAAgAGUAbgBkAHAAbwBpAG4AdABzACAAaQBu ACAAdABoAGUAIAB3AGgAbwBsAGUAcwBhAGwAZQAgAGEAYwBjAGUAcwBzACAAbgBvAGQAZQAZIHMA IABVAE4ASQAtAE4AIABwAG8AcgB0ACAAYwBhAHIAZAAgAGEAbgBkACAARABTAEwAQQBNAHMALgAg AEkAdAAgAG0AYQB5ACAAaABhAHYAZQAgAE0ASQBQAHMAIABpAG4AIAB0AGgAZQAgAHcAaABvAGwA ZQBzAGEAbABlACAAYQBjAGMAZQBzAHMAIABuAG8AZABlABkgcwAgAGwAaQBuAGUAIABwAG8AcgB0 ACAAYwBhAHIAZAAsACAAbQBlAHQAcgBvACAAYwBvAHIAZQAgAGEAbgBkACAAbQBlAHQAcgBvACAA ZQBkAGcAZQAgAG4AbwBkAGUAcwAuACAAUAByAG8ALQBhAGMAdABpAHYAZQAgAE8AQQBNACAAdwBp AGwAbAAgAGMAaABlAGMAawAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABFAFYAQwAgAGkA bgAgAHQAaABlACAAUABUAE4ALgAAAKEPFgAAAOwBAAAAAAAQAABQAOwBAAAAAAIAFAAAAKoPfAAA AFUAAAAGAAAACQgAAAQAAAAHAAAAAwAJCAAAOwAAAAYAAAAJCAAABgAAAAcAAAADAAkIAACxAAAA BgAAAAkIAAAGAAAABwAAAAMACQgAAA4AAAAGAAAACQgAAAQAAAAHAAAAAwAJCAAAiAAAAAYAAAAJ CAAAAQAAAAAAAAAAAPMDFAAAAAgCAAAEAAAAAgAAALsBAAAAAAAAAACfDwQAAAAAAAAAAACoD0QA AABXaG9sZXNhbGUgRVZDIE9wdGlvbiBJSUkgC0VWQyBNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAg KE1FRykgZXhhbXBsZQAAoQ8UAAAARQAAAAAAAAAAAEUAAAAAAAIAHwAAAKoPFAAAAEQAAAAGAAAA CQgAAAEAAAAAAAAAEACfDwQAAAABAAAAAACgDxAEAABUAGgAZQAgAHQAbwBwACAAbABlAHYAZQBs ACAARQBWAEMAIABNAEUARwAgAGgAYQBzACAAaQB0AHMAIABlAG4AZABwAG8AaQBuAHQAcwAgAGkA bgAgAHQAaABlACAAcgBvAHUAdABlAHIAIABhAG4AZAAgAGUAbgBkACAAdABlAHIAbQBpAG4AYQBs ACAAZABlAHYAaQBjAGUAcwAuACAASQB0ACAAbQBhAHkAIABoAGEAdgBlACAATQBJAFAAcwAgAGkA bgAgAHQAaABlACAAdwBoAG8AbABlAHMAYQBsAGUAIABhAGMAYwBlAHMAcwAgAG4AbwBkAGUAGSBz ACAAVQBOAEkALQBOACAAcABvAHIAdAAgAGMAYQByAGQALAAgAGkAbgAgAHQAaABlACAARABTAEwA QQBNAHMAIABhAG4AZAAgAGkAbgAgAHQAaABlACAAaABvAG0AZQAgAGcAYQB0AGUAdwBhAHkAcwAu ACAATwBuAC0AZABlAG0AYQBuAGQAIABPAEEATQAgAGMAYQBuACAAYgBlACAAdQBzAGUAZAAgAHQA bwAgAGMAaABlAGMAawAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABFAFYAQwAgAGEAZgB0 AGUAcgAgAHMAdQBiAHMAYwByAGkAYgBlAHIAIABjAG8AbQBwAGwAYQBpAG4AdAAuAA0AVABoAGUA IABQAFQATgAgAGgAYQBzACAAaQB0AHMAIABvAHcAbgAgAEUAVgBDACAATQBFAEcAIAB3AGkAdABo ACAAZQBuAGQAcABvAGkAbgB0AHMAIABpAG4AIAB0AGgAZQAgAHcAaABvAGwAZQBzAGEAbABlACAA YQBjAGMAZQBzAHMAIABuAG8AZABlABkgcwAgAFUATgBJAC0ATgAgAHAAbwByAHQAIABjAGEAcgBk ACAAYQBuAGQAIABEAFMATABBAE0AcwAuACAASQB0ACAAbQBhAHkAIABoAGEAdgBlACAATQBJAFAA cwAgAGkAbgAgAHQAaABlACAAdwBoAG8AbABlAHMAYQBsAGUAIABhAGMAYwBlAHMAcwAgAG4AbwBk AGUAGSBzACAAbABpAG4AZQAgAHAAbwByAHQAIABjAGEAcgBkACwAIABtAGUAdAByAG8AIABjAG8A cgBlACAAYQBuAGQAIABtAGUAdAByAG8AIABlAGQAZwBlACAAbgBvAGQAZQBzAC4AIABQAHIAbwAt AGEAYwB0AGkAdgBlACAATwBBAE0AIAB3AGkAbABsACAAYwBoAGUAYwBrACAAcwB0AGEAdAB1AHMA IABvAGYAIAB0AGgAZQAgAEUAVgBDACAAaQBuACAAdABoAGUAIABQAFQATgAuAAAAoQ8gAAAACQIA AAAAABAAAFAACAIAAAAAAgAUAAEAAAAAAAIAEgAAAKoPfAAAAFwAAAAGAAAACQgAAAQAAAAHAAAA AwAJCAAAOAAAAAYAAAAJCAAABgAAAAcAAAADAAkIAADKAAAABgAAAAkIAAAGAAAABwAAAAMACQgA AA4AAAAGAAAACQgAAAQAAAAHAAAAAwAJCAAAiAAAAAYAAAAJCAAAAQAAAAAAAAAAAOoDAAAAAA8A +ANBCAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAACzBgAPAHIAAAAP///wAAAAAAgICA AAAAAAC74OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAA mWYAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAA AAAAlpaWAAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPM zAD/UFAA/5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAA AIAAAAD///8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8A M2bMAACwAABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABg APAHIAAAAGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+ XAD///8AYFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQA AIyeoAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8A AQAAAAIAAAD//yMAmQAA/gAAEACjD5YAAAAFAP/9PwAAACIgAABkAAAAAP8AAGQARgAAAAAAAABA AgAAAAAHAAAA///vAAEAAAACAAAA//8ZAAAAAAEAALM1AAADAHEAAwAAAAABVQAjACcCIAEBAAIA AAAWAIA1AADYAGQAFABdA5ECAAACABQAsgUAAAEAEyAAAAAAAP+0BM4DAABAAP//gAUAALsACwYl BQAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAcAAAD//+8A AAAAAAIAAAD//wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUA AIAEgAQAAAAAUACjD04AAAAFAAAAAAgAAAEAAAAAAAEAAQkAAAIAAQAgAQAAAAACAAEJAAACAAEA kQIAAAAAAwABCQAAAAABAM4DAAAAAAQAAQkAAAAAAQAlBQAAAABgAKMPDAAAAAEAAAAAAAAAAAAA AHAAow8+AAAABQAAAAAAAAAAAAIAFgABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIA EgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABMAAQAAAAAAAAACABIAAgAAAAAAAAAC ABAAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBPACAAAPAALw6AIAAOAFCPAIAAAAAwAAAAt4 AQAPAAPwgAIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAeAEABQAA AA8ABPD+AAAAEgAK8AgAAAACeAEAAAoAAOMAC/BUAAAAfwABAAUAgAAgEmAMgQDyZAEAggB7sgAA gwDyZAEAhAB7sgAAhwABAAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIEwAi8QYAAAC/AwAAAAQAABDwCAAAABkAUAHyGJQCDwAR8BAAAAAAAMMLCAAAAAAAAAABAGAM DwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0 eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwQgEAABIACvAIAAAAA3gBAAAK AADTAAvwTgAAAH8AAQAFAIAAmLFgDIEA8mQBAIIAe7IAAIMA8mQBAIQAe7IAAL8AEAAfAIEBBAAA CIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACBMAIvEGAAAAvwMAAAAEAAAQ8AgAAACYBFAB 8hiWEQ8AEfAQAAAAAADDCwgAAAABAAAAAgBgDA8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IAAABD bGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwN Rm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAM AAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATwSAAAABIACvAIAAAAAXgBAAAMAACDAAvwMAAAAIEB AAAACIMBBQAACJMBFe2iAJQBti56AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTnQAAAA8AihOVAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLE3UAAAAAAOouBAAAAAEAAAAAAOsuCAAAAEvNyAHwmxKwAAAAKwQAAAAA AAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAACZDP////8SAAAADwA98Q0A AABAAULxBQAAAAEJAAAADwACKwAAAAAgALoPJAAAAGgAdQBhAHcAZQBpAC0AdABlAG0AcABsAGEA dABlAC0AbQB2AA8A8AMoBgAAAQDxAwgAAAADAACAAAALMA8ADASoBQAADwAC8KAFAACwAAjwCAAA AAcAAAAHDAAADwAD8DgFAAAPAATwKAAAAAEACfAQAAAAAQAAAAIAAAAAAAAAAAAAAAIACvAIAAAA AAwAAAUAAAAPAATw1AAAABIACvAIAAAAAgwAAAAKAABzAAvwKgAAAH8AAQABAIAAjDRbCYEBBAAA CIMBAAAACL8BAQARAMABAQAACP8BAQAJAAAAEPAIAAAAAAAAAFAHIAEPABHwEAAAAAAAwwsIAAAA AAAAAAoCYAwPAA3wYgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAAC AAAAAAACAAwAAAD5DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQI DwAE8NYAAAASAArwCAAAAAMMAAAACgAAcwAL8CoAAAB/AAEAAQCAAOA3WwmBAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAAAAkAngECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAFsJ DwAN8GQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAAC AAwAAAD4DwQAAAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQIDwAE8GQA AAASAArwCAAAAAQMAAAACgAAYwAL8CQAAAB/AAQABACHAAEAAAB/AQAAAQC/AREAEQD/AQgACQA/ AgEAAQAAABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAFsJDwAE8BQBAAASAArw CAAAAAUMAAAACgAAcwAL8CoAAAB/AAEAAQCAACR3WwmBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/ AQEACQAAABDwCAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAMAAAAGAlsJDwAN8KIAAAAAAJ8P BAAAAAIAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBs ZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0A AAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8OAAAAUwAAAAcAAAAAAAkEBAgPAATw2gAAABIACvAI AAAABgwAAAAKAACDAAvwMAAAAH8AAQABAIAAcC9bCYcAAgAAAIEBBAAACIMBAAAACL8BAQARAMAB AQAACP8BAQAJAAAAEPAIAAAAYBUAAFAHgBYPABHwEAAAAAAAwwsIAAAABAAAAAkCWwkPAA3wYgAA AAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD6DwQA AAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQIDwAE8NwAAAASAArwCAAA AAcMAAAACgAAgwAL8DAAAAB/AAEAAQCAAMhmWwmHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEA AAj/AQEACQAAABDwCAAAAGAVkAngEIAWDwAR8BAAAAAAAMMLCAAAAAUAAAAIAlsJDwAN8GQAAAAA AJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADYDwQA AAAAAAAAAACqDxwAAAABAAAABwAAAAAABAgJBAEAAAAHAAAAAAAJBAQIDwAE8EgAAAASAArwCAAA AAEMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAEAwkA AAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAP AIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACwpnIAgCSqcw8A yQ+gBAAADwAMBDAEAAAPAALwKAQAAOACCPAIAAAABQAAAAWwAAAPAAPwwAMAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAsAAABQAAAA8ABPDYAAAAEgAK8AgAAAACsAAA AAoAAIMAC/AwAAAAfwABAAUAgADoMFsJgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAAAAAAAAUAcgAQ8AEfAQAAAAAADDCwgAAAAAAAAACgJgDA8ADfBgAAAAAACfDwQA AAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPkPBAAAAAAAAAAA AKoPGgAAAAEAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIDwAE8NoAAAASAArwCAAAAAOwAAAACgAA gwAL8DAAAAB/AAEABQCAAKgbWwmBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgA ABDwCAAAAAAAjwnfECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAlsJDwAN8GIAAAAAAJ8PBAAAAAQA AAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAAAAAAAACq DxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECA8ABPDeAAAAEgAK8AgAAAAEsAAAAAoAAJMA C/A2AAAAfwABAAUAgAD8FVsJhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAABfFQAAUAd/Fg8AEfAQAAAAAADDCwgAAAACAAAACQJbCQ8ADfBgAAAAAACfDwQA AAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPoPBAAAAAAAAAAA AKoPGgAAAAEAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIDwAE8OAAAAASAArwCAAAAAWwAAAACgAA kwAL8DYAAAB/AAEABQCAAIQeWwmHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB AgIAAAgAABDwCAAAAF8VjwnfEH8WDwAR8BAAAAAAAMMLCAAAAAMAAAAIAlsJDwAN8GIAAAAAAJ8P BAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADYDwQAAAAA AAAAAACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECA8ABPBIAAAAEgAK8AgAAAABsAAA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAXGvGAXDPjTQPAO4DHksA AAIA7wMYAAAAAQAAAA0OAAAAAAAAAwAAgAAAAAAHAAswDwAMBDVKAAAPAALwLUoAANAoCPAIAAAA KwAAAEXgCgAPAAPwxUkAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA 4AoABQAAAA8ABPBoAQAAEgAK8AgAAAAC4AoAAAoAAJMBC/CWAAAAfwAAAAQAgADYflkMgQAhZQEA ggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEA AAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAADYNTg1gDsEQDwAN8GQAAAAAAJ8PBAAAAAQA AAAAAKgPBAAAAENvcmUAAKEPGAAAAAUAAAAAAAAIAAABAAUAAAABAAIAAQALAAAAqg8UAAAABAAA AAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H4AAAASAArwCAAAAAPgCgAgAgAA cwAL8CoAAAAEAAAAAAB/AAAABACAAEwvWQy/AQAAAQD/AQAAAQABAwJ4AQCIAwAAAAAAABDwCAAA ABkAUAHyGJQCDwAR8BAAAAAAAMMLCAAAAAAAAAANAFkMDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATw cgAAABIACvAIAAAANOAKACACAABTAAvwHgAAAH8AAAAEAIAAfNxZDL8BAAABAP8BAAABAAEDA3gB AAAAEPAIAAAA0gNQAfIYqwkPABHwEAAAAAAAwwsIAAAAAQAAAA4AWQwPAA3wDAAAAAAAng8EAAAA AQAAAA8ABPB3AQAAEgAK8AgAAAAF4AoAAAoAAJMBC/CWAAAAfwAAAAQAgABYOVkMgQAhZQEAggCQ sgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAI vwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIB AA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAANgJQxJUE+8QDwAN8HMAAAAAAJ8PBAAAAAQAAAAA AKgPEwAAAFNlcnZpY2UNRWRnZQ1Sb3V0ZXIAAKEPGAAAABQAAAAAAAAIAAABABQAAAABAAIAAQAL AAAAqg8UAAAAEwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8HkBAAASAArw CAAAAAbgCgAACgAAkwEL8JYAAAB/AAAABACAAKwuWQyBACFlAQCCAJCyAACDACFlAQCEAJCyAACF AAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYA DgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCT ACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8G BgAOAAAAEPAIAAAA2QneBe8GwRAPAA3wdQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAQVRNDURTTEFN AAChDxgAAAAKAAAAAAAACAAAAQAKAAAAAQACAAEACwAAAKoPIAAAAAMAAAAGAAAACQgAAAEAAAAA AAAABgAAAAYAAAAJCAAAAACmDwgAAABACAAAXwNfAw8ABPB1AQAAEgAK8AgAAAAH4AoAAAoAAJMB C/CWAAAAfwAAAAQAgACkDVkMgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQ AB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQ AgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/ AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAJ4L yQ/bEMEQDwAN8HEAAAAAAJ8PBAAAAAQAAAAAAKgPEQAAAFdob2xlDXNhbGUNQWNjZXNzAAChDxgA AAASAAAAAAAACAAAAQASAAAAAQACAAEACwAAAKoPFAAAABEAAAAGAAAACQgAAAEAAAAAAAAAAACm DwgAAABACAAAXwNfAw8ABPBuAQAAEgAK8AgAAAAI4AoAAAoAAJMBC/CWAAAAfwAAAAQAgABoGFkM gQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd 3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAA PwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/ BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAJ4LpQq3C8EQDwAN8GoAAAAAAJ8P BAAAAAQAAAAAAKgPCgAAAE1ldHJvDUNvcmUAAKEPGAAAAAsAAAAAAAAIAAABAAsAAAABAAIAAQAL AAAAqg8UAAAACgAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8G4BAAASAArw CAAAAAngCgAACgAAkwEL8JYAAAB/AAAABACAAEDgWQyBACFlAQCCAJCyAACDACFlAQCEAJCyAACF AAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYA DgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCT ACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8G BgAOAAAAEPAIAAAAngtZCGoJwRAPAA3wagAAAAAAnw8EAAAABAAAAAAAqA8KAAAATWV0cm8NRWRn ZQAAoQ8YAAAACwAAAAAAAAgAAAEACwAAAAEAAgABAAsAAACqDxQAAAAKAAAABgAAAAkIAAABAAAA AAAAAAAApg8IAAAAQAgAAF8DXwMPAATwbwEAABIACvAIAAAACuAKAAAKAACTAQvwlgAAAH8AAAAE AIAAZMpZDIEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8B AAAGAIEB3d3dAIMBAAAACL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMAB vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADZCZADoQTBEA8ADfBr AAAAAACfDwQAAAAEAAAAAACoDwsAAABIT01FDUdXQVkNSQAAoQ8YAAAADAAAAAAAAAgAAAEADAAA AAEAAgABAAsAAACqDxQAAAALAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATw RgEAABIACvAIAAAAC+AKAAAKAABjAQvwhAAAAH8AAAAEAIAAYAFZDIEAIWUBAIIAkLIAAIMAIWUB AIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEB3d3dAIMBAAAACL8BEAAQAMABAQAACP8B AAAIAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgACAL8CAAAIAFMAIvEeAAAAvwEA AGAAfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgAAAAQ8AgAAADYCcoB3ALBEA8ADfBsAAAAAACfDwQA AAAEAAAAAACoDwwAAABQSE9ORQ1TVEINUEMAAKEPGAAAAA0AAAAAAAAIAAABAA0AAAABAAIAAQAL AAAAqg8UAAAADAAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8IwBAAASAArw CAAAAAzgCgAACgAAgwEL8JAAAAB/AIAAhACAAEzwWQyBAAAAAACCAAAAAACDAAAAAACEAAAAAACF AAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAf/MAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUA AAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAA AD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAAMwomAioWEwsPAA3wjgAAAAAAnw8EAAAABAAAAAAAqA8CAAAASVAAAKEPNgAAAAMAAAAA ABZYAAAGAAUAAQBaAJD/AgAAAAEAQwABAAQABAAQAAEAAAABBGMAAQQEAAIABAAQAAAAqg8UAAAA AgAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwlAEA AKIMCvAIAAAADeAKAAAKAAADAQvwjgAAAIAAECxRDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUA AgAAAL8AEAAfAIABAQAAAIEBAAAACIMB/8wAAIZBGgAAAIfBLgAAAL8BFAAUAMABAQAACP8BAAAI AAECAgAACEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAAATACLx BgAAAL8BAABgAAAAEPAIAAAAuwoYBJ8SFgsPAA3wyAAAAAAAnw8EAAAABAAAAAAAoA8oAAAAIAAg ACAAIAAgACAAUABQAFAAbwBBACAA8/AgACAAUABQAFAAbwBFAAAAoQ8wAAAAFQAAAAAAAAAAAAwA AAABAAIAAQALAAEAAAABAIIAAQADAAsACAAAAAEAAgABAAsAAACqDzwAAAAGAAAABgAAAAkIAAAF AAAABwAAAAMACQgAAAQAAAAGAAAACQgAAAUAAAAHAAAAAwAJCAAAAQAAAAAAAAAAAKYPCAAAAEAI AABfA18DDwAE8EEBAAASAArwCAAAAA7gCgAACgAAcwEL8IoAAAB/AIAAhACAAKyMUQyBAAAAAACC AAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAZaWlgCDATNm/wC/ARwA HgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/ AgEADwATACLxBgAAAL8BAABgAAAAEPAIAAAAZA1/EHISNA4PAA3weQAAAAAAnw8EAAAABAAAAAAA qA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAEABAA AACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATweQEA ABIACvAIAAAAEOAKAAAKAACTAQvwlgAAAH8AgACEAIAAYDBRDIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBAP8AAL8BHAAeAMABAQAACMsBakoA AP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8D AAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG AE4AfwYGAA4AAAAQ8AgAAABkDQEJ9QpGDg8ADfB1AAAAAACfDwQAAAAEAAAAAACoDwMAAABFVlAA AKEPJAAAAAQAAAAAABZYAAAGAAUAAQBaAJD/BAAAAAEAQwABAAQABAAQAAAAqg8MAAAABAAAAAYA AAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8EEBAAASAArwCAAAABHgCgAA CgAAcwEL8IoAAAB/AIAAhACAACywUQyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIA AAC/ABAAHwAMAfMDMxCBAZaWlgCDATNm/wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwATACLxBgAAAL8BAABgAAAAEPAIAAAA ZA3BBoUIPQ4PAA3weQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZY AAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAA APEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwgwEAABIACvAIAAAAE+AKAAAKAACjAQvwnAAAAH8A gACEAIAASGdRDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMz ED8BAAAGAIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC 8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEA AGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDjsJ 0wqPDw8ADfB5AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYA BQABAFoAkP8GAAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4A AKACUAFQAaACoALwA/ADQAVABQ8ABPCBAQAAEgAK8AgAAAAU4AoAAAoAAKMBC/CcAAAAfwCAAIQA gACMmVEMgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEA AAYAgQGWlpYAgwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQ BQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/ AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGMNcwQMBj0O DwAN8HcAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAERTTAAAoQ8mAAAABAAAAAAAFlgAAAYABQABAFoA kP8EAAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAQAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPAzAQAAEgAK8AgAAAAV4AoAAAoAAHMBC/CKAAAAfwCAAIQAgABcoVEM gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwABAAAAvwAQAB8ADAHzAzMQgQGWlpYAgwEz Zv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAA PwICAAMAvwIBAA8AAAAQ8AgAAADLC4ECvwN3DA8ADfB5AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4 MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEABAACAAQADgAAAKoPDAAA AAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPCIAQAAEgAK8AgA AAAW4AoAAAoAANMBC/CuAAAAfwCAAIQAgACcEFEMgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAC AAAAhwABAAAAvwAQAB8ADAHzAzMQPwEAAAYAgAEHAAAAgQH/ZgAAgwH//wAAiwEAAKb/jAFkAAAA vwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwIC AAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/ASAAYAD/AQAAwAG/AwCCAIJ/BQYA TgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAMsLZgbgCKsMDwAN8GwAAAAAAJ8PBAAA AAQAAAAAAKEPJgAAAAEAAAAAABZYAAAGAAUAAQBaAJD/AQAAAAEAYwABAAQAAgAEABAAAACqDwwA AAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwoQEAABIACvAI AAAAF+AKAAAKAACjAQvwnAAAAH8AgACEAIAA8DVRDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUA AgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB//8AAIMBmf9mAL8BHAAeAMABAQAACMsBakoA AP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8D AAAPAJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG AE4AfwYGAA4AAAAQ8AgAAADLC+AIURCrDA8ADfCXAAAAAACfDwQAAAAEAAAAAACoDwkAAAAocm1w KSBFVkMAAKEPJgAAAAoAAAAAABZYAAAGAAUAAQBaAJD/CgAAAAEAYwABAAQAAgAEABAAAACqDyYA AAABAAAAAAAAAAMAAAABAAAAAwAFAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPCIAQAAEgAK8AgAAAAY4AoAAAoAANMBC/CuAAAAfwCAAIQAgAAgP1EM gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwABAAAAvwAQAB8ADAHzAzMQPwEAAAYAgAEH AAAAgQH//wAAgwH/ZgAAiwEAAKb/jAFkAAAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAA AQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/ AQAAQAC/ASAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDw CAAAAMsLURCgEqsMDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKEPJgAAAAEAAAAAABZYAAAGAAUAAQBa AJD/AQAAAAEAYwABAAQAAgAEABAAAACqDwwAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlAB UAGgAqAC8APwA0AFQAUPAATwjAEAABIACvAIAAAAGeAKAAAKAACjAQvwnAAAAH8AgACEAIAAPEFR DIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB zMwAAIMBmf9mAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMAB vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADLC0YEOQarDA8ADfCC AAAAAACfDwQAAAAEAAAAAACoDwYAAABBVE0gVkMAAKEPJgAAAAcAAAAAABZYAAAGAAUAAQBaAJD/ BwAAAAEAYwABAAQAAgAEABAAAACqDxQAAAAGAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4A AKACUAFQAaACoALwA/ADQAVABQ8ABPB9AQAAogwK8AgAAAAd4AoAAAoAAFMBC/CsAAAAgACQwlEM gQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwH/ /2YAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2 AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4A AAAQ8AgAAADLC5QGcRImDA8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMAAABNQUMAAKEPGAAAAAQA AAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAA AEAIAABfA18DDwAE8H0BAACiDArwCAAAACHgCgAACgAAUwEL8KwAAACAADghUQyBACFlAQCCAAAA AACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAAAAiDAZn/ZgCGQRoAAACH wS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEA cgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/ AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQN DQnTCr8NDwAN8GMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFRBRwAAoQ8YAAAABAAAAAAAAAgAAAEA BAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMP AATwfQEAAKIMCvAIAAAAIuAKAAAKAABTAQvwrAAAAIAAcFtRDIEAIWUBAIIAAAAAAIMAIWUBAIQA AAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAe AMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8A dwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADA Ab8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAZA2sEEQSvw0PAA3w YwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAVEFHAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEA CwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAAogwK 8AgAAAAl4AoAAAoAAFMBC/CsAAAAgADgXFEMgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAA vwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIA ZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDjsJ0wr8Dg8ADfBjAAAAAACfDwQA AAAEAAAAAACoDwMAAABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAA AwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H0BAACiDArwCAAAACfgCgAA CgAAUwEL8KwAAACAABhiUQyBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAA BgCAAQEAAACBAQAAAAiDAcDAwACGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEA ZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQN7QaFCL8NDwAN8GMAAAAAAJ8PBAAAAAQAAAAAAKgP AwAAAFRBRwAAoQ8YAAAABAAAAAAAAAgAAAEABAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAAAAkI AAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwfQEAAKIMCvAIAAAAKOAKAAAKAABTAQvwrAAA AIAA/IhRDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEB AAAACIMBzJkAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwA AACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBO AH8GBgAOAAAAEPAIAAAAywtyBAoGJgwPAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAVkNJAACh DxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAA AACmDwgAAABACAAAXwNfAw8ABPC2EwAAogQK8AgAAAAv4AoAAAoAALMAC/COEwAAhQACAAAAhwAB AAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIgMMaAAAAgcMyEwAAvwMCAAIA RAB0AHMAUwBoAGEAcABlAE4AYQBtAGUAAABDADAAMwA1ADcAQwA1AEMAMQBHADQAQwA1ADcAOQBE AEAAOAAxADEANAA3AEAARQBAAEUANgA5ADMANAA1ADkAMAA4ADUARgA0AGEAOAA1AEYAPwA1AEwA MQAxADgAMQAxADEAMQAzACEAIQAhAEIASQBIAE8AQABdAEwAMQAxADgAMQAxADEAMQAzACEAIQAh ACEAIQAhACEAMQAxADEAMABCADMANABDADkAMABDAEcARwBjAGMALABjAGAAYgBqAGkAYAB0AG0A LABgAHMAYgBpAGgAdQBkAGIAdQB0AHMAZAAsADEAMQAvAHEAcQB1ACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAMQAhADEAAAAAABDwCAAAAAAAAAABAAEADwAE 8F4AAACCBQrwCAAAADHgCgAACgAAkwAL8DYAAAAEAAAAWgCFAAIAAACHAAEAAACBAQQAAAiDAQAA AAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAEoRkwZQENIRDwAE8L8AAACiDArwCAAA ADLgCgAACgAAowAL8DwAAACAAOjgUQyFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAALgRaQpsDOISDwAN8FMAAAAAAJ8PBAAAAAQAAAAA AKgPAwAAAFBUTgAAoQ8YAAAABAAAAAAAAAgAAAEABAAAAAEAAgABABkAAACqDxQAAAADAAAABgAA AAkIAAABAAAAAAAAAA8ABPCDAQAAEgAK8AgAAAA74AoAAAoAAKMBC/CcAAAAfwCAAIQAgACcI1EM gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQGW lpYAgwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAA BgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/ AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKEOigt7DYQPDwAN8HkA AAAAAJ8PBAAAAAQAAAAAAKgPBQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYA AAABAGMAAQAEAAIABAAQAAAAqg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKg AvAD8ANABUAFDwAE8EkBAAASAArwCAAAADzgCgAACgAAYwEL8IQAAAB/AIAAhACAAPDYUQyBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAQD/AAC/ARwAHgDA AQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEA DwATACLxBgAAAL8BAABgAAAAEPAIAAAAZA1bCyQQPg4PAA3whwAAAAAAnw8EAAAABAAAAAAAqA8D AAAATFNQAAChDzYAAAAEAAAAAAAWWAAABgAFAAEAWgCQ/wMAAAABAEMAAQAEAAQAEAABAAAAAQRj AAEEBAACAAQAEAAAAKoPDAAAAAQAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/AD QAVABQ8ABPCDAQAAEgAK8AgAAAA94AoAAAoAAKMBC/CcAAAAfwCAAIQAgACEXkwMgQAAAAAAggAA AAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQGWlpYAgwEzZv8A vwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwIC AAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYA TgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKEOMg72D4QPDwAN8HkAAAAAAJ8PBAAA AAQAAAAAAKgPBQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYAAAABAGMAAQAE AAIABAAQAAAAqg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAF DwAE8H0BAACiDArwCAAAAD7gCgAACgAAUwEL8KwAAACAABAJTAyBACFlAQCCAAAAAACDACFlAQCE AAAAAACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAAAAiDAZn/ZgCGQRoAAACHwS4AAAC/ARwA HgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEAcgBrACAAZABv AHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAA wAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQNiAv2D78NDwAN 8GMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAExTRQAAoQ8YAAAABAAAAAAAAAgAAAEABAAAAAEAAgAB AAsAAACqDxQAAAADAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwgQEAAKIM CvAIAAAAP+AKAAAKAABTAQvwrAAAAIAATE1MDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAA AL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8B BgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQBy AGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8F BgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ5eDvYP/A4PAA3wZwAAAAAAnw8E AAAABAAAAAAAqA8HAAAATFNFL01BQwAAoQ8YAAAACAAAAAAAAAgAAAEACAAAAAEAAgABAAsAAACq DxQAAAAHAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwgQEAAKIMCvAIAAAA QOAKAAAKAABTAQvwrAAAAIAA9BRMDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAf AD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAEC AgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABk AGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8F BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ62C04N/A4PAA3wZwAAAAAAnw8EAAAABAAA AAAAqA8HAAAATFNFL01BQwAAoQ8YAAAACAAAAAAAAAgAAAEACAAAAAEAAgABAAsAAACqDxQAAAAH AAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwvwAAAKIMCvAIAAAAQeAKAAAK AACjAAvwPAAAAIAAwBZMDIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACAAAEPAIAAAAcw4BB1gIDQ8PAA3wUwAAAAAAnw8EAAAABAAAAAAAqA8FAAAA Qy1UYWcAAKEPFgAAAAYAAAAAAAAAAAAGAAAAAwACAAMACgAAAKoPFAAAAAUAAAAGAAAACQgAAAEA AAAAAAAADwAE8McAAACiDArwCAAAAELgCgAACgAAowAL8DwAAACAAKQbTAyFAAIAAACHAAYAAAC/ AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAJ8PaAm/CpkQ DwAN8FsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAEMtVGFnDVMtVGFnAAChDxgAAAAMAAAAAAAACAAA AQAMAAAAAwACAAMACgAAAKoPFAAAAAsAAAAGAAAACQgAAAEAAAAAAAAADwAE8MoAAACiDArwCAAA AEPgCgAACgAAowAL8DwAAACAADwgTAyFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAJ8PmwtgDZkQDwAN8F4AAAAAAJ8PBAAAAAQAAAAA AKgPDgAAAFBXLUxTRQ1MU1AtTFNFAAChDxgAAAAPAAAAAAAACAAAAQAPAAAAAwACAAMACgAAAKoP FAAAAA4AAAAGAAAACQgAAAEAAAAAAAAADwAE8MoAAACiDArwCAAAAETgCgAACgAAowAL8DwAAACA AIgeTAyFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA AAgAABDwCAAAAJoPMQ72D5QQDwAN8F4AAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBXLUxTRQ1MU1At TFNFAAChDxgAAAAPAAAAAAAACAAAAQAPAAAAAwACAAMACgAAAKoPFAAAAA4AAAAGAAAACQgAAAEA AAAAAAAADwAE8L8AAACiDArwCAAAAEXgCgAACgAAowAL8DwAAACAAKBXTAyFAAIAAACHAAYAAAC/ AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHMO2hAxEg0P DwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAEMtVGFnAAChDxYAAAAGAAAAAAAAAAAABgAAAAMA AgADAAoAAACqDxQAAAAFAAAABgAAAAkIAAABAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAAB4AoAAAwA AIMAC/AwAAAAgQEAAAAIgwEFAAAIkwEV7aIAlAG2LnoAvwESABIA/wEAAAgABAMJAAAAPwMBAAEA EADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAA ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAjrTJAQBUvqwAAAArBAAAAAAA AAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAJkM/////xIAAAAPAD3xDQAA AEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gN4SAAAAgDvAxgAAAABAAAADQ4AAAAAAAADAACAAAAA AAcACzAPAAwEj0cAAA8AAvCHRwAAACkI8AgAAAApAAAANOwKAA8AA/AfRwAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADsCgAFAAAADwAE8GgBAAASAArwCAAAAAPsCgAA CgAAkwEL8JYAAAB/AAAABACAAKwhYAyBACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIA AAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8B AABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAI AAAANg1ODWAOwRAPAA3wZAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAQ29yZQAAoQ8YAAAABQAAAAAA AAgAAAEABQAAAAEAAgABAAsAAACqDxQAAAAEAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgA AF8DXwMPAATwfgAAABIACvAIAAAABOwKACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAAAI5gDL8B AAABAP8BAAABAAEDAngBAIgDAAAAAAAAEPAIAAAAGQBQAfIYlAIPABHwEAAAAAAAwwsIAAAAAAAA AA0AYAwPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPB3AQAAEgAK8AgAAAAH7AoAAAoAAJMBC/CWAAAA fwAAAAQAgADon2AMgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHz AzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQ BQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/ AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAANgJQxJUE+8Q DwAN8HMAAAAAAJ8PBAAAAAQAAAAAAKgPEwAAAFNlcnZpY2UNRWRnZQ1Sb3V0ZXIAAKEPGAAAABQA AAAAAAAIAAABABQAAAABAAIAAQALAAAAqg8UAAAAEwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAA AEAIAABfA18DDwAE8JIBAAASAArwCAAAAAjsCgAACgAAkwEL8JYAAAB/AAAABACAAPQhXgyBACFl AQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCD AQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAngveBe8GwRAPAA3wjgAAAAAAnw8EAAAA BAAAAAAAqA8UAAAAVkRTTDINb3INRmliZXINRFNMQU0AAKEPGAAAABUAAAAAAAAIAAABABUAAAAB AAIAAQALAAAAqg8uAAAACQAAAAYAAAAJCAAABQAAAAcAAAADAAkIAAAGAAAABgAAAAkIAAABAAAA AAAAAAAApg8IAAAAQAgAAF8DXwMPAATwdQEAABIACvAIAAAACewKAAAKAACTAQvwlgAAAH8AAAAE AIAAZJReDIEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8B AAAGAIEB3d3dAIMBAAAACL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMAB vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAACeC8kP2xDBEA8ADfBx AAAAAACfDwQAAAAEAAAAAACoDxEAAABXaG9sZQ1zYWxlDUFjY2VzcwAAoQ8YAAAAEgAAAAAAAAgA AAEAEgAAAAEAAgABAAsAAACqDxQAAAARAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8D XwMPAATwbgEAABIACvAIAAAACuwKAAAKAACTAQvwlgAAAH8AAAAEAIAA2IheDIEAIWUBAIIAkLIA AIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB3d3dAIMBAAAACL8B HAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAP AP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A /wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAACeC6UKtwvBEA8ADfBqAAAAAACfDwQAAAAEAAAAAACo DwoAAABNZXRybw1Db3JlAAChDxgAAAALAAAAAAAACAAAAQALAAAAAQACAAEACwAAAKoPFAAAAAoA AAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBuAQAAEgAK8AgAAAAL7AoAAAoA AJMBC/CWAAAAfwAAAAQAgADoil4MgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAA vwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAA QAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAA AJ4LWQhqCcEQDwAN8GoAAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAE1ldHJvDUVkZ2UAAKEPGAAAAAsA AAAAAAAIAAABAAsAAAABAAIAAQALAAAAqg8UAAAACgAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAA AEAIAABfA18DDwAE8HABAAASAArwCAAAAAzsCgAACgAAkwEL8JYAAAB/AAAABACAADwyXgyBACFl AQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCD AQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA2QmQA6EEwRAPAA3wbAAAAAAAnw8EAAAA BAAAAAAAqA8MAAAASE9NRQ1HV0FZDUlJAAChDxgAAAANAAAAAAAACAAAAQANAAAAAQACAAEACwAA AKoPFAAAAAwAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBGAQAAEgAK8AgA AAAN7AoAAAoAAGMBC/CEAAAAfwAAAAQAgABoN14MgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQAC AAAAhwACAAAAvwAQAB8ADAHzAzMQgQHd3d0AgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAAIFAAAA AQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAIAvwIAAAgAUwAi8R4AAAC/AQAAYAB/BQAACAC/ BQAACAD/BQAACAA/BgAACAAAABDwCAAAANgJygHcAsEQDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKgP DAAAAFBIT05FDVNUQg1QQwAAoQ8YAAAADQAAAAAAAAgAAAEADQAAAAEAAgABAAsAAACqDxQAAAAM AAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwjAEAABIACvAIAAAADuwKAAAK AACDAQvwkAAAAH8AgACEAIAArAheDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAf AAwB8wMzED8BAAAGAIEB/8wAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC 8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEA AGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAzCiYC KhYTCw8ADfCOAAAAAACfDwQAAAAEAAAAAACoDwIAAABJUAAAoQ82AAAAAwAAAAAAFlgAAAYABQAB AFoAkP8CAAAAAQBDAAEABAAEABAAAQAAAAEEYwABBAQAAgAEABAAAACqDxQAAAACAAAAAAAAAAEA AAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPA6AQAAogwK8AgAAAAP 7AoAAAoAAAMBC/COAAAAgABEW14MgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8A gAEBAAAAgQEAAAAIgwH/zAAAhkEaAAAAh8EuAAAAvwEUABQAwAEBAAAI/wEAAAgAAQICAAAIRABh AHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAABMAIvEGAAAAvwEAAGAA AAAQ8AgAAAC7ChgEnxIWCw8ADfBuAAAAAACfDwQAAAAEAAAAAACoDw4AAAAgICAgICBQUFAvREhD UAAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAEAAgABAAsAAACqDxQAAAAOAAAABgAAAAkIAAABAAAA AAAAAAAApg8IAAAAQAgAAF8DXwMPAATwQQEAABIACvAIAAAAEOwKAAAKAABzAQvwigAAAH8AgACE AIAAfEFeDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEB lpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPABMAIvEGAAAAvwEAAGAAAAAQ8AgAAABkDX8QchI0Dg8ADfB5AAAA AACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAA AQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALw A/ADQAVABQ8ABPB5AQAAEgAK8AgAAAAR7AoAAAoAAJMBC/CWAAAAfwCAAIQAgABkoF4MgQAAAAAA ggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQEA/wAAvwEc AB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQNAQn1CkYODwAN8HUAAAAAAJ8PBAAAAAQA AAAAAKgPAwAAAEVWUAAAoQ8kAAAABAAAAAAAFlgAAAYABQABAFoAkP8EAAAAAQBDAAEABAAEABAA AACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwQQEA ABIACvAIAAAAEuwKAAAKAABzAQvwigAAAH8AgACEAIAATE9eDIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoA AP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPABMAIvEGAAAA vwEAAGAAAAAQ8AgAAABkDcEGhQg9Dg8ADfB5AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAA oQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAG AAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPCDAQAAEgAK8AgAAAAT7AoA AAoAAKMBC/CcAAAAfwCAAIQAgACQR14MgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwAC AAAAvwAQAB8ADAHzAzMQPwEAAAYAgQGWlpYAgwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4A AAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAAKEOigt7DYQPDwAN8HkAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAADgwMi4zAAChDyYA AAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAABgAAAAYAAAAJ CAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8IMBAAASAArwCAAAABTsCgAACgAA owEL8JwAAAB/AIAAhACAANhyXgyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ ABAAHwAMAfMDMxA/AQAABgCBAZaWlgCDATNm/wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUA AAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAA AD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAAoQ47CdMKjw8PAA3weQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYA AAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwgQEAABIACvAIAAAAFewKAAAKAACjAQvw nAAAAH8AgACEAIAAeN1eDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAf AAwB8wMzED8BAAAGAIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC 8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEA AEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgA AABjDXMEDAY9Dg8ADfB3AAAAAACfDwQAAAAEAAAAAACoDwMAAABEU0wAAKEPJgAAAAQAAAAAABZY AAAGAAUAAQBaAJD/BAAAAAEAYwABAAQAAgAEABAAAACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAA APEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwMwEAABIACvAIAAAAFuwKAAAKAABzAQvwigAAAH8A gACEAIAAQNNeDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMz EIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUC nDEAAAYCnDEAAD8CAgADAL8CAQAPAAAAEPAIAAAAywuBAr8DdwwPAA3weQAAAAAAnw8EAAAABAAA AAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAE AA4AAACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATw iAEAABIACvAIAAAAF+wKAAAKAADTAQvwrgAAAH8AgACEAIAApP9eDIEAAAAAAIIAAAAAAIMAAAAA AIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzED8BAAAGAIABBwAAAIEB/2YAAIMB//8AAIsB AACm/4wBZAAAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMAB vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADLCxgEkgarDA8ADfBs AAAAAACfDwQAAAAEAAAAAAChDyYAAAABAAAAAAAWWAAABgAFAAEAWgCQ/wEAAAABAGMAAQAEAAIA BAAQAAAAqg8MAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE 8KEBAAASAArwCAAAABjsCgAACgAAowEL8JwAAAB/AIAAhACAANBOXgyBAAAAAACCAAAAAACDAAAA AACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAf//AACDAZn/ZgC/ARwAHgDA AQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEA DwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BIABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBO AP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAywuTBlEQqwwPAA3wlwAAAAAAnw8EAAAABAAAAAAA qA8JAAAAKHJtcCkgRVZDAAChDyYAAAAKAAAAAAAWWAAABgAFAAEAWgCQ/woAAAABAGMAAQAEAAIA BAAQAAAAqg8mAAAAAQAAAAAAAAADAAAAAQAAAAMABQAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAA APEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwiAEAABIACvAIAAAAGewKAAAKAADTAQvwrgAAAH8A gACEAIAAEGVeDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMz ED8BAAAGAIABBwAAAIEB//8AAIMB/2YAAIsBAACm/4wBZAAAAL8BHAAeAMABAQAACMsBakoAAP8B BgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAP AJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4A fwYGAA4AAAAQ8AgAAADLC1EQoBKrDA8ADfBsAAAAAACfDwQAAAAEAAAAAAChDyYAAAABAAAAAAAW WAAABgAFAAEAWgCQ/wEAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAAAQAAAAYAAAAJCAQIAACmDxYA AADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8EkBAAASAArwCAAAAB3sCgAACgAAYwEL8IQAAAB/ AIAAhACAALABXgyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMD MxCBAQD/AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwATACLxBgAAAL8BAABgAAAAEPAIAAAAZA1bCyQQPg4PAA3whwAAAAAA nw8EAAAABAAAAAAAqA8DAAAATFNQAAChDzYAAAAEAAAAAAAWWAAABgAFAAEAWgCQ/wMAAAABAEMA AQAEAAQAEAABAAAAAQRjAAEEBAACAAQAEAAAAKoPDAAAAAQAAAAGAAAACQgECAAApg8WAAAA8R4A AKACUAFQAaACoALwA/ADQAVABQ8ABPCwAQAAogwK8AgAAAAe7AoAAAoAAFMBC/CsAAAAgAC091kM gQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwH/ /2YAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2 AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4A AAAQ8AgAAADLC0UEcRImDA8ADfCWAAAAAACfDwQAAAAEAAAAAACgDx4AAABDAC0ATQBBAEMAIADz 8CAAUABDAEMALQBNAEEAQwAAAKEPMAAAABAAAAAAAAAAAAAGAAAAAQACAAEACwABAAAAAQCCAAEA AwALAAkAAAABAAIAAQALAAAAqg8UAAAADwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABf A18DDwAE8IMBAAASAArwCAAAAB/sCgAACgAAowEL8JwAAAB/AIAAhACAAGCjWQyBAAAAAACCAAAA AACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAZaWlgCDATNm/wC/ ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ4yDvYPhA8PAA3weQAAAAAAnw8EAAAA BAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQA AgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUP AATwfQEAAKIMCvAIAAAAIuwKAAAKAABTAQvwrAAAAIAA/M9ZDIEAIWUBAIIAAAAAAIMAIWUBAIQA AAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBmf9mAIZBGgAAAIfBLgAAAL8BHAAe AMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8A dwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADA Ab8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAZA2IC/YPvw0PAA3w YwAAAAAAnw8EAAAABAAAAAAAqA8DAAAATFNFAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEA CwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAAogwK 8AgAAAAj7AoAAAoAAFMBC/CsAAAAgAA40VkMgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAA vwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwGZ/2YAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIA ZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDQ0J0wq/DQ8ADfBjAAAAAACfDwQA AAAEAAAAAACoDwMAAABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAA AwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H0BAACiDArwCAAAACTsCgAA CgAAUwEL8KwAAACAAOBFWQyBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAA BgCAAQEAAACBAQAAAAiDAcDAwACGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEA ZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQNrBBEEr8NDwAN8GMAAAAAAJ8PBAAAAAQAAAAAAKgP AwAAAFRBRwAAoQ8YAAAABAAAAAAAAAgAAAEABAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAAAAkI AAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwgQEAAKIMCvAIAAAAJewKAAAKAABTAQvwrAAA AIAAaGtZDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEB AAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwA AACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBO AH8GBgAOAAAAEPAIAAAAoQ5eDvYP/A4PAA3wZwAAAAAAnw8EAAAABAAAAAAAqA8HAAAATFNFL01B QwAAoQ8YAAAACAAAAAAAAAgAAAEACAAAAAEAAgABAAsAAACqDxQAAAAHAAAABgAAAAkIAAABAAAA AAAAAAAApg8IAAAAQAgAAF8DXwMPAATwgQEAAKIMCvAIAAAAJuwKAAAKAABTAQvwrAAAAIAAJNdZ DIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMB wMDAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLx NgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAO AAAAEPAIAAAAoQ62C04N/A4PAA3wZwAAAAAAnw8EAAAABAAAAAAAqA8HAAAATFNFL01BQwAAoQ8Y AAAACAAAAAAAAAgAAAEACAAAAAEAAgABAAsAAACqDxQAAAAHAAAABgAAAAkIAAABAAAAAAAAAAAA pg8IAAAAQAgAAF8DXwMPAATwfQEAAKIMCvAIAAAAJ+wKAAAKAABTAQvwrAAAAIAArLBZDIEAIWUB AIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZB GgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8B AABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAI AAAAoQ47CdMK/A4PAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAVEFHAAChDxgAAAAEAAAAAAAA CAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAA XwNfAw8ABPB9AQAAogwK8AgAAAAo7AoAAAoAAFMBC/CsAAAAgAAcslkMgQAhZQEAggAAAAAAgwAh ZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAA vwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAg AGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA /wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDe0GhQi/ DQ8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMAAABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAAB AAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8LYT AACiBArwCAAAACzsCgAACgAAswAL8I4TAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADA AQEAAAj/AQgACAABAgIAAAiAwxoAAACBwzITAAC/AwIAAgBEAHQAcwBTAGgAYQBwAGUATgBhAG0A ZQAAAEMAMAAzADUANwBDADUAQwAxAEcANABDADUANwA5AEQAQAA4ADEAMQA0ADcAQABFAEAARQA2 ADkAMwA0ADUAOQAwADgANQBGADQAYQA4ADUARgA3ADYATAAxADEAOAAxADEAMQAxADMAIQAhACEA QgBJAEgATwBAAF0ATAAxADEAOAAxADEAMQAxADMAIQAhACEAIQAhACEAIQAxADEAMQAwAEIAMwA0 AEMAOQAwAEMARwBHAGMAYwAsAGMAYABiAGoAaQBgAHQAbQAsAGAAcwBiAGkAaAB1AGQAYgB1AHQA cwBkACwAMQAxAC8AcQBxAHUAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAxACEAMQAAAAAAEPAIAAAAAAAAAAEAAQAPAATwXgAAAIIFCvAIAAAALewKAAAKAACT AAvwNgAAAAQAAABaAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAEC AgAACAAAEPAIAAAAShGTBlAQ0hEPAATwvwAAAKIMCvAIAAAALuwKAAAKAACjAAvwPAAAAIAAeFlZ DIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAA EPAIAAAAuBFpCmwM4hIPAA3wUwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUFROAAChDxgAAAAEAAAA AAAACAAAAQAEAAAAAQACAAEAGQAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAADwAE8L8AAACi DArwCAAAAC/sCgAACgAAowAL8DwAAACAAIReWQyFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAA AAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHMOAQdYCA0PDwAN8FMAAAAAAJ8PBAAA AAQAAAAAAKgPBQAAAEMtVGFnAAChDxYAAAAGAAAAAAAAAAAABgAAAAMAAgADAAoAAACqDxQAAAAF AAAABgAAAAkIAAABAAAAAAAAAA8ABPDHAAAAogwK8AgAAAAw7AoAAAoAAKMAC/A8AAAAgABAXVkM hQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ 8AgAAACfD2gJvwqZEA8ADfBbAAAAAACfDwQAAAAEAAAAAACoDwsAAABDLVRhZw1TLVRhZwAAoQ8Y AAAADAAAAAAAAAgAAAEADAAAAAMAAgADAAoAAACqDxQAAAALAAAABgAAAAkIAAABAAAAAAAAAA8A BPDKAAAAogwK8AgAAAAx7AoAAAoAAKMAC/A8AAAAgABgiVkMhQACAAAAhwAGAAAAvwACAAIAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACfD5sLYA2ZEA8ADfBeAAAA AACfDwQAAAAEAAAAAACoDw4AAABQVy1MU0UNTFNQLUxTRQAAoQ8YAAAADwAAAAAAAAgAAAEADwAA AAMAAgADAAoAAACqDxQAAAAOAAAABgAAAAkIAAABAAAAAAAAAA8ABPDKAAAAogwK8AgAAAAy7AoA AAoAAKMAC/A8AAAAgABYZFkMhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEB AAAI/wEAAAgAAQICAAAIAAAQ8AgAAACaDzEO9g+UEA8ADfBeAAAAAACfDwQAAAAEAAAAAACoDw4A AABQVy1MU0UNTFNQLUxTRQAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAMAAgADAAoAAACqDxQAAAAO AAAABgAAAAkIAAABAAAAAAAAAA8ABPC/AAAAogwK8AgAAAAz7AoAAAoAAKMAC/A8AAAAgADgkFkM hQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ 8AgAAABzDtoQMRINDw8ADfBTAAAAAACfDwQAAAAEAAAAAACoDwUAAABDLVRhZwAAoQ8WAAAABgAA AAAAAAAAAAYAAAADAAIAAwAKAAAAqg8UAAAABQAAAAYAAAAJCAAAAQAAAAAAAAAPAATw8gAAABIA CvAIAAAANOwKACAKAABzAQvwigAAAAQAAAAAAH8AAQAFAIAATHhZDIEA8mQBAIIAe7IAAIMA8mQB AIQAe7IAAIUAAAAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAIEB BAAACIMBAAAACL8BAAARAMABAQAACP8BAAAJAAECAgAACAEDA3gBAIgDAAAAACMAIvEMAAAAjAAB AAAAjQAwZQEAAAAQ8AgAAAD/A1AB8hirCQ8AEfAQAAAAAADDCwgAAAABAAAADgBZDA8ADfAMAAAA AACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHsCgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiT ARXtogCUAbYuegC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAA AAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAw AAAAixNpAAAAAADrLggAAACOtMkBAFS+rAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAA AwAAAAAAAAAAAAAAAAAAAAAAmQz/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAA DwDuA/FIAAACAO8DGAAAAAEAAAANDgAAAAAAAAMAAIAAAAAABwALMA8ADAQISAAADwAC8ABIAAAQ KQjwCAAAACkAAAAz8AoADwAD8JhHAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAAPAKAAUAAAAPAATwkgEAABIACvAIAAAALfAKAAAKAACTAQvwlgAAAH8AAAAEAIAASHM0 CoEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB 3d3dAIMBAAAACL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEA AD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAACeC94F7wbBEA8ADfCOAAAAAACf DwQAAAAEAAAAAACoDxQAAABWRFNMMg1vcg1GaWJlcg1EU0xBTQAAoQ8YAAAAFQAAAAAAAAgAAAEA FQAAAAEAAgABAAsAAACqDy4AAAAJAAAABgAAAAkIAAAFAAAABwAAAAMACQgAAAYAAAAGAAAACQgA AAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBoAQAAEgAK8AgAAAAD8AoAAAoAAJMBC/CWAAAA fwAAAAQAgABkezQKgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHz AzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQ BQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/ AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAADYNTg1gDsEQ DwAN8GQAAAAAAJ8PBAAAAAQAAAAAAKgPBAAAAENvcmUAAKEPGAAAAAUAAAAAAAAIAAABAAUAAAAB AAIAAQALAAAAqg8UAAAABAAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H4A AAASAArwCAAAAATwCgAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACAAJgzNAq/AQAAAQD/AQAAAQAB AwJ4AQCIAwAAAAAAABDwCAAAABkAUAHyGJQCDwAR8BAAAAAAAMMLCAAAAAAAAAANADQKDwAN8AwA AAAAAJ4PBAAAAAAAAAAPAATwdwEAABIACvAIAAAAB/AKAAAKAACTAQvwlgAAAH8AAAAEAIAA1Hw0 CoEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB 3d3dAIMBAAAACL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEA AD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADYCUMSVBPvEA8ADfBzAAAAAACf DwQAAAAEAAAAAACoDxMAAABTZXJ2aWNlDUVkZ2UNUm91dGVyAAChDxgAAAAUAAAAAAAACAAAAQAU AAAAAQACAAEACwAAAKoPFAAAABMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8A BPB1AQAAEgAK8AgAAAAJ8AoAAAoAAJMBC/CWAAAAfwAAAAQAgADgNzQKgQAhZQEAggCQsgAAgwAh ZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4A wAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIW AB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYA TgA/BgYATgB/BgYADgAAABDwCAAAAJ4LyQ/bEMEQDwAN8HEAAAAAAJ8PBAAAAAQAAAAAAKgPEQAA AFdob2xlDXNhbGUNQWNjZXNzAAChDxgAAAASAAAAAAAACAAAAQASAAAAAQACAAEACwAAAKoPFAAA ABEAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBuAQAAEgAK8AgAAAAK8AoA AAoAAJMBC/CWAAAAfwAAAAQAgAB0CiIKgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwAC AAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAA AQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/ AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDw CAAAAJ4LpQq3C8EQDwAN8GoAAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAE1ldHJvDUNvcmUAAKEPGAAA AAsAAAAAAAAIAAABAAsAAAABAAIAAQALAAAAqg8UAAAACgAAAAYAAAAJCAAAAQAAAAAAAAAAAKYP CAAAAEAIAABfA18DDwAE8G4BAAASAArwCAAAAAvwCgAACgAAkwEL8JYAAAB/AAAABACAAEgVIgqB ACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d 3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/ AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8F BgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAngtZCGoJwRAPAA3wagAAAAAAnw8E AAAABAAAAAAAqA8KAAAATWV0cm8NRWRnZQAAoQ8YAAAACwAAAAAAAAgAAAEACwAAAAEAAgABAAsA AACqDxQAAAAKAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwcQEAABIACvAI AAAADPAKAAAKAACTAQvwlgAAAH8AAAAEAIAAOBYiCoEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUA AgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB3d3dAIMBAAAACL8BHAAeAMABAQAACP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMA IvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYG AA4AAAAQ8AgAAACeC5ADoQTBEA8ADfBtAAAAAACfDwQAAAAEAAAAAACoDw0AAABIT01FDUdXQVkN SUlJAAChDxgAAAAOAAAAAAAACAAAAQAOAAAAAQACAAEACwAAAKoPFAAAAA0AAAAGAAAACQgAAAEA AAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBGAQAAEgAK8AgAAAAN8AoAAAoAAGMBC/CEAAAAfwAA AAQAgAAYICIKgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQ gQHd3d0AgwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKc MQAAPwICAAIAvwIAAAgAUwAi8R4AAAC/AQAAYAB/BQAACAC/BQAACAD/BQAACAA/BgAACAAAABDw CAAAANgJygHcAsEQDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKgPDAAAAFBIT05FDVNUQg1QQwAAoQ8Y AAAADQAAAAAAAAgAAAEADQAAAAEAAgABAAsAAACqDxQAAAAMAAAABgAAAAkIAAABAAAAAAAAAAAA pg8IAAAAQAgAAF8DXwMPAATwjAEAABIACvAIAAAADvAKAAAKAACDAQvwkAAAAH8AgACEAIAAFC8i CoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB/8wAAL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAzCiYCKhYTCw8ADfCOAAAAAACfDwQAAAAE AAAAAACoDwIAAABJUAAAoQ82AAAAAwAAAAAAFlgAAAYABQABAFoAkP8CAAAAAQBDAAEABAAEABAA AQAAAAEEYwABBAQAAgAEABAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4A AKACUAFQAaACoALwA/ADQAVABQ8ABPA6AQAAogwK8AgAAAAP8AoAAAoAAAMBC/COAAAAgAA4OiIK gQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8AgAEBAAAAgQEAAAAIgwH/zAAAhkEa AAAAh8EuAAAAvwEUABQAwAEBAAAI/wEAAAgAAQICAAAIRABhAHIAawAgAGQAbwB3AG4AdwBhAHIA ZAAgAGQAaQBhAGcAbwBuAGEAbAAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAC7ClICnxIWCw8ADfBu AAAAAACfDwQAAAAEAAAAAACoDw4AAAAgICAgICBQUFAvREhDUAAAoQ8YAAAADwAAAAAAAAgAAAEA DwAAAAEAAgABAAsAAACqDxQAAAAOAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMP AATwQQEAABIACvAIAAAAEPAKAAAKAABzAQvwigAAAH8AgACEAIAAlEQiCoEAAAAAAIIAAAAAAIMA AAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBlpaWAIMBM2b/AL8BHAAeAMABAQAA CMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPABMA IvEGAAAAvwEAAGAAAAAQ8AgAAABkDX8QchI0Dg8ADfB5AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4 MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEABAACAAQAEAAAAKoPDAAA AAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPB5AQAAEgAK8AgA AAAR8AoAAAoAAJMBC/CWAAAAfwCAAIQAgADwTiIKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAC AAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQEA/wAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4A AAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAAGQNAQn1CkYODwAN8HUAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVWUAAAoQ8kAAAA BAAAAAAAFlgAAAYABQABAFoAkP8EAAAAAQBDAAEABAAEABAAAACqDwwAAAAEAAAABgAAAAkIBAgA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwQQEAABIACvAIAAAAEvAKAAAKAABzAQvw igAAAH8AgACEAIAATFkiCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAf AAwB8wMzEIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC 8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPABMAIvEGAAAAvwEAAGAAAAAQ8AgAAABkDcEGhQg9 Dg8ADfB5AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQAB AFoAkP8GAAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKAC UAFQAaACoALwA/ADQAVABQ8ABPCDAQAAEgAK8AgAAAAT8AoAAAoAAKMBC/CcAAAAfwCAAIQAgACE AyIKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYA gQGWlpYAgwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKc MQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAA wAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKEOigt7DYQPDwAN 8HkAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ /wYAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVAB oAKgAvAD8ANABUAFDwAE8IMBAAASAArwCAAAABTwCgAACgAAowEL8JwAAAB/AIAAhACAABAAIQqB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAZaW lgCDATNm/wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ47CdMKjw8PAA3weQAA AAAAnw8EAAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAA AAEAYwABAAQAAgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC 8APwA0AFQAUPAATwgQEAABIACvAIAAAAFfAKAAAKAACjAQvwnAAAAH8AgACEAIAAbAAhCoEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBlpaWAIMB M2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEA AD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABjDXMEDAY9Dg8ADfB3AAAAAACf DwQAAAAEAAAAAACoDwMAAABEU0wAAKEPJgAAAAQAAAAAABZYAAAGAAUAAQBaAJD/BAAAAAEAYwAB AAQAAgAEABAAAACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AF QAUPAATwgwEAABIACvAIAAAAFvAKAAAKAACjAQvwnAAAAH8AgACEAIAApBEhCoEAAAAAAIIAAAAA AIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBlpaWAIMBM2b/AL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABjDYECvwNGDg8ADfB5AAAAAACfDwQAAAAE AAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEABAAC AAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8A BPCIAQAAEgAK8AgAAAAX8AoAAAoAANMBC/CuAAAAfwCAAIQAgACQGiEKgQAAAAAAggAAAAAAgwAA AAAAhAAAAAAAhQACAAAAhwABAAAAvwAQAB8ADAHzAzMQPwEAAAYAgAEHAAAAgQH/ZgAAgwH//wAA iwEAAKb/jAFkAAAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKc MQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/ASAAYAD/AQAA wAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAMsLUgKTBqsMDwAN 8GwAAAAAAJ8PBAAAAAQAAAAAAKEPJgAAAAEAAAAAABZYAAAGAAUAAQBaAJD/AQAAAAEAYwABAAQA AgAEABAAAACqDwwAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUP AATwoQEAABIACvAIAAAAGPAKAAAKAACjAQvwnAAAAH8AgACEAIAALGEhCoEAAAAAAIIAAAAAAIMA AAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB//8AAIMBmf9mAL8BHAAe AMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8C AQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMABvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADLC5MGURCrDA8ADfCXAAAAAACfDwQAAAAEAAAA AACoDwkAAAAocm1wKSBFVkMAAKEPJgAAAAoAAAAAABZYAAAGAAUAAQBaAJD/CgAAAAEAYwABAAQA AgAEABAAAACqDyYAAAABAAAAAAAAAAMAAAABAAAAAwAFAAAAAAAAAAEAAAAGAAAACQgECAAApg8W AAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPCIAQAAEgAK8AgAAAAZ8AoAAAoAANMBC/CuAAAA fwCAAIQAgABcaiEKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwABAAAAvwAQAB8ADAHz AzMQPwEAAAYAgAEHAAAAgQH//wAAgwH/ZgAAiwEAAKb/jAFkAAAAvwEcAB4AwAEBAAAIywFqSgAA /wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMA AA8AkwAi8TYAAAA/AQAAQAC/ASAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYA TgB/BgYADgAAABDwCAAAAMsLURCgEqsMDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKEPJgAAAAEAAAAA ABZYAAAGAAUAAQBaAJD/AQAAAAEAYwABAAQAAgAEABAAAACqDwwAAAABAAAABgAAAAkIBAgAAKYP FgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwSQEAABIACvAIAAAAHPAKAAAKAABjAQvwhAAA AH8AgACEAIAAnHUhCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB 8wMzEIEBAP8AAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPABMAIvEGAAAAvwEAAGAAAAAQ8AgAAABkDVsLJBA+Dg8ADfCHAAAA AACfDwQAAAAEAAAAAACoDwMAAABMU1AAAKEPNgAAAAQAAAAAABZYAAAGAAUAAQBaAJD/AwAAAAEA QwABAAQABAAQAAEAAAABBGMAAQQEAAIABAAQAAAAqg8MAAAABAAAAAYAAAAJCAQIAACmDxYAAADx HgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8NgBAACiDArwCAAAAB3wCgAACgAAUwEL8KwAAACAAPh6 IQqBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAAAAiD Af//ZgCGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYA HwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAAkwAi 8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAAMsLfwJxEiYMDwAN8L4AAAAAAJ8PBAAAAAQAAAAAAKAPRgAAACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABDAC0ATQBBAEMAIADz8CAAUABDAEMALQBNAEEA QwAAAKEPMAAAACQAAAAAAAAAAAAaAAAAAQACAAEACwABAAAAAQCCAAEAAwALAAkAAAABAAIAAQAL AAAAqg8UAAAAIwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8IMBAAASAArw CAAAAB7wCgAACgAAowEL8JwAAAB/AIAAhACAANiNIQqBAAAAAACCAAAAAACDAAAAAACEAAAAAACF AAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAZaWlgCDATNm/wC/ARwAHgDAAQEAAAjLAWpK AAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/ AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8G BgBOAH8GBgAOAAAAEPAIAAAAoQ4yDvYPhA8PAA3weQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAODAy LjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAEABAAAACqDwwAAAAG AAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwfQEAAKIMCvAIAAAA IfAKAAAKAABTAQvwrAAAAIAApI8hCoEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAf AD8BAAAGAIABAQAAAIEBAAAACIMBmf9mAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAEC AgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABk AGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8F BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAZA2IC/YPvw0PAA3wYwAAAAAAnw8EAAAABAAA AAAAqA8DAAAATFNFAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMAAAAG AAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAAogwK8AgAAAAi8AoAAAoAAFMB C/CsAAAAgAAwmiEKgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYAgAEB AAAAgQEAAAAIgwGZ/2YAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBu AGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4A PwYGAE4AfwYGAA4AAAAQ8AgAAABkDQ0J0wq/DQ8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMAAABU QUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAAAQAA AAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H0BAACiDArwCAAAACPwCgAACgAAUwEL8KwAAACAALyk IQqBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAAAAiD AcDAwACGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYA HwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAAkwAi 8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAAGQNrBBEEr8NDwAN8GMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFRBRwAAoQ8YAAAA BAAAAAAAAAgAAAEABAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAAAAkIAAABAAAAAAAAAAAApg8I AAAAQAgAAF8DXwMPAATwgQEAAKIMCvAIAAAAJPAKAAAKAABTAQvwrAAAAIAAwCEhCoEAIWUBAIIA AAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAA AIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQA YQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABA AL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA oQ5eDvYP/A4PAA3wZwAAAAAAnw8EAAAABAAAAAAAqA8HAAAATFNFL01BQwAAoQ8YAAAACAAAAAAA AAgAAAEACAAAAAEAAgABAAsAAACqDxQAAAAHAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgA AF8DXwMPAATwgQEAAKIMCvAIAAAAJfAKAAAKAABTAQvwrAAAAIAATCwhCoEAIWUBAIIAAAAAAIMA IWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAA AL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsA IABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABg AP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ62C04N /A4PAA3wZwAAAAAAnw8EAAAABAAAAAAAqA8HAAAATFNFL01BQwAAoQ8YAAAACAAAAAAAAAgAAAEA CAAAAAEAAgABAAsAAACqDxQAAAAHAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMP AATwfQEAAKIMCvAIAAAAJvAKAAAKAABTAQvwrAAAAIAA2DYhCoEAIWUBAIIAAAAAAIMAIWUBAIQA AAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAe AMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8A dwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADA Ab8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ47CdMK/A4PAA3w YwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAVEFHAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEA CwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAAogwK 8AgAAAAn8AoAAAoAAFMBC/CsAAAAgABkQSEKgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAA vwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIA ZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDe0GhQi/DQ8ADfBjAAAAAACfDwQA AAAEAAAAAACoDwMAAABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAA AwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8LYTAACiBArwCAAAACrwCgAA CgAAswAL8I4TAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIA AAiAwxoAAACBwzITAAC/AwIAAgBEAHQAcwBTAGgAYQBwAGUATgBhAG0AZQAAAEMAMAAzADUANwBD ADUAQwAxAEcANABDADUANwA5AEQAQAA4ADEAMQA0ADcAQABFAEAARQA2ADkAMwA0ADUAOQAwADgA NQBGADQAYQA4ADUARgA3ADYATAAxADEAOAAxADEAMQAxADMAIQAhACEAQgBJAEgATwBAAF0ATAAx ADEAOAAxADEAMQAxADMAIQAhACEAIQAhACEAIQAxADEAMQAwAEIAMwA0AEMAOQAwAEMARwBHAGMA YwAsAGMAYABiAGoAaQBgAHQAbQAsAGAAcwBiAGkAaAB1AGQAYgB1AHQAcwBkACwAMQAxAC8AcQBx AHUAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAxACEAMQAA AAAAEPAIAAAAAAAAAAEAAQAPAATwXgAAAIIFCvAIAAAAK/AKAAAKAACTAAvwNgAAAAQAAABaAIUA AgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAShGT BlAQ0hEPAATwvwAAAKIMCvAIAAAALPAKAAAKAACjAAvwPAAAAIAAiEwhCoUAAgAAAIcABgAAAL8A AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAuBFpCmwM4hIP AA3wUwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUFROAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQAC AAEAGQAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAADwAE8L8AAACiDArwCAAAAC7wCgAACgAA owAL8DwAAACAAIhCIQqFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAgAABDwCAAAAHMOAQdYCA0PDwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAEMt VGFnAAChDxYAAAAGAAAAAAAAAAAABgAAAAMAAgADAAoAAACqDxQAAAAFAAAABgAAAAkIAAABAAAA AAAAAA8ABPDHAAAAogwK8AgAAAAv8AoAAAoAAKMAC/A8AAAAgABQUCEKhQACAAAAhwAGAAAAvwAC AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACfD2gJvwqZEA8A DfBbAAAAAACfDwQAAAAEAAAAAACoDwsAAABDLVRhZw1TLVRhZwAAoQ8YAAAADAAAAAAAAAgAAAEA DAAAAAMAAgADAAoAAACqDxQAAAALAAAABgAAAAkIAAABAAAAAAAAAA8ABPDKAAAAogwK8AgAAAAw 8AoAAAoAAKMAC/A8AAAAgACAqCEKhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACfD5sLYA2ZEA8ADfBeAAAAAACfDwQAAAAEAAAAAACo Dw4AAABQVy1MU0UNTFNQLUxTRQAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAMAAgADAAoAAACqDxQA AAAOAAAABgAAAAkIAAABAAAAAAAAAA8ABPDKAAAAogwK8AgAAAAx8AoAAAoAAKMAC/A8AAAAgAB4 uVsJhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAQ8AgAAACaDzEO9g+UEA8ADfBeAAAAAACfDwQAAAAEAAAAAACoDw4AAABQVy1MU0UNTFNQLUxT RQAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAMAAgADAAoAAACqDxQAAAAOAAAABgAAAAkIAAABAAAA AAAAAA8ABPC/AAAAogwK8AgAAAAy8AoAAAoAAKMAC/A8AAAAgAAEv1sJhQACAAAAhwAGAAAAvwAC AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABzDtoQMRINDw8A DfBTAAAAAACfDwQAAAAEAAAAAACoDwUAAABDLVRhZwAAoQ8WAAAABgAAAAAAAAAAAAYAAAADAAIA AwAKAAAAqg8UAAAABQAAAAYAAAAJCAAAAQAAAAAAAAAPAATw8gAAABIACvAIAAAAM/AKACAKAABz AQvwigAAAAQAAAAAAH8AAQAFAIAA6CVbCYEA8mQBAIIAe7IAAIMA8mQBAIQAe7IAAIUAAAAAAIYA AAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAIEBBAAACIMBAAAACL8BAAAR AMABAQAACP8BAAAJAAECAgAACAEDA3gBAIgDAAAAACMAIvEMAAAAjAABAAAAjQAwZQEAAAAQ8AgA AACkA1AB8hirCQ8AEfAQAAAAAADDCwgAAAABAAAADgBbCQ8ADfAMAAAAAACeDwQAAAABAAAADwAE 8EgAAAASAArwCAAAAAHwCgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTARXtogCUAbYuegC/ARIA EgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZ zAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggA AACOtMkBAFS+rAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA AAAAmQz/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuA7lRAAACAO8DGAAA AAEAAAANDgAAAAAAAAMAAIAAAAAABwALMA8ADATQUAAADwAC8MhQAAAwKQjwCAAAADkAAAA8AAsA DwAD8GBQAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAALAAUAAAAP AATwaAEAABIACvAIAAAAAgALAAAKAACTAQvwlgAAAH8AAAAEAIAAOFOtCIEAIWUBAIIAkLIAAIMA IWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB3d3dAIMBAAAACL8BHAAe AMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8C FgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUG AE4APwYGAE4AfwYGAA4AAAAQ8AgAAAA2DU4NYA7BEA8ADfBkAAAAAACfDwQAAAAEAAAAAACoDwQA AABDb3JlAAChDxgAAAAFAAAAAAAACAAAAQAFAAAAAQACAAEACwAAAKoPFAAAAAQAAAAGAAAACQgA AAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB+AAAAEgAK8AgAAAADAAsAIAIAAHMAC/AqAAAA BAAAAAAAfwAAAAQAgAAEuVsJvwEAAAEA/wEAAAEAAQMCeAEAiAMAAAAAAAAQ8AgAAAAZAFAB8hiU Ag8AEfAQAAAAAADDCwgAAAAAAAAADQBbCQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArw CAAAAAQACwAgAgAAYwAL8CQAAAB/AAAABACAAPD1qwi/AQAAAQD/AQAAAQABAwN4AQCIAwAAAAAA ABDwCAAAANIDUAHyGPUIDwAR8BAAAAAAAMMLCAAAAAEAAAAOAFsJDwAN8AwAAAAAAJ4PBAAAAAEA AAAPAATwdwEAABIACvAIAAAABQALAAAKAACTAQvwlgAAAH8AAAAEAIAA6AetCIEAIWUBAIIAkLIA AIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB3d3dAIMBAAAACL8B HAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAP AP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A /wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABQCUMSVBPvEA8ADfBzAAAAAACfDwQAAAAEAAAAAACo DxMAAABTZXJ2aWNlDUVkZ2UNUm91dGVyAAChDxgAAAAUAAAAAAAACAAAAQAUAAAAAQACAAEACwAA AKoPFAAAABMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB5AQAAEgAK8AgA AAAGAAsAAAoAAJMBC/CWAAAAfwAAAAQAgAA8ha0IgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQAC AAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4A AAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAAFUJ3gXvBsEQDwAN8HUAAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEFUTQ1EU0xBTQAA oQ8YAAAACgAAAAAAAAgAAAEACgAAAAEAAgABAAsAAACqDyAAAAADAAAABgAAAAkIAAABAAAAAAAA AAYAAAAGAAAACQgAAAAApg8IAAAAQAgAAF8DXwMPAATwdQEAABIACvAIAAAABwALAAAKAACTAQvw lgAAAH8AAAAEAIAAyJOZDIEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAf AAwB8wMzED8BAAAGAIEB3d3dAIMBAAAACL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC 8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEA AGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADoCskP 2xDBEA8ADfBxAAAAAACfDwQAAAAEAAAAAACoDxEAAABXaG9sZQ1zYWxlDUFjY2VzcwAAoQ8YAAAA EgAAAAAAAAgAAAEAEgAAAAEAAgABAAsAAACqDxQAAAARAAAABgAAAAkIAAABAAAAAAAAAAAApg8I AAAAQAgAAF8DXwMPAATwbgEAABIACvAIAAAACAALAAAKAACTAQvwlgAAAH8AAAAEAIAAOO6ZDIEA IWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB3d3d AIMBAAAACL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8C AgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADoCqUKtwvBEA8ADfBqAAAAAACfDwQA AAAEAAAAAACoDwoAAABNZXRybw1Db3JlAAChDxgAAAALAAAAAAAACAAAAQALAAAAAQACAAEACwAA AKoPFAAAAAoAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBuAQAAEgAK8AgA AAAJAAsAAAoAAJMBC/CWAAAAfwAAAAQAgADArpkMgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQAC AAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4A AAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi 8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYA DgAAABDwCAAAAOgKWQhqCcEQDwAN8GoAAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAE1ldHJvDUVkZ2UA AKEPGAAAAAsAAAAAAAAIAAABAAsAAAABAAIAAQALAAAAqg8UAAAACgAAAAYAAAAJCAAAAQAAAAAA AAAAAKYPCAAAAEAIAABfA18DDwAE8G8BAAASAArwCAAAAAoACwAACgAAkwEL8JYAAAB/AAAABACA AKjFmQyBACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAA BgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAVQmQA6EEwRAPAA3wawAA AAAAnw8EAAAABAAAAAAAqA8LAAAASE9NRQ1HV0FZDUkAAKEPGAAAAAwAAAAAAAAIAAABAAwAAAAB AAIAAQALAAAAqg8UAAAACwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8EYB AAASAArwCAAAAAsACwAACgAAYwEL8IQAAAB/AAAABACAAOCXmQyBACFlAQCCAJCyAACDACFlAQCE AJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAd3d3QCDAQAAAAi/ARAAEADAAQEAAAj/AQAA CAAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAgC/AgAACABTACLxHgAAAL8BAABg AH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAEPAIAAAAUwnKAdwCwRAPAA3wbAAAAAAAnw8EAAAA BAAAAAAAqA8MAAAAUEhPTkUNU1RCDVBDAAChDxgAAAANAAAAAAAACAAAAQANAAAAAQACAAEACwAA AKoPFAAAAAwAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPCMAQAAEgAK8AgA AAAMAAsAAAoAAIMBC/CQAAAAfwCAAIQAgADYkZkMgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAC AAAAvwAQAB8ADAHzAzMQPwEAAAYAgQH/zAAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAA AQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/ AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDw CAAAAH0JJgIqFl0KDwAN8I4AAAAAAJ8PBAAAAAQAAAAAAKgPAgAAAElQAAChDzYAAAADAAAAAAAW WAAABgAFAAEAWgCQ/wIAAAABAEMAAQAEAAQAEAABAAAAAQRjAAEEBAACAAQAEAAAAKoPFAAAAAIA AAAAAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8JQBAACi DArwCAAAAA0ACwAACgAAAwEL8I4AAACAAAzjmQyBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIA AAC/ABAAHwCAAQEAAACBAQAAAAiDAf/MAACGQRoAAACHwS4AAAC/ARQAFADAAQEAAAj/AQAACAAB AgIAAAhEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAAEwAi8QYA AAC/AQAAYAAAABDwCAAAAAUKGASfEmAKDwAN8MgAAAAAAJ8PBAAAAAQAAAAAAKAPKAAAACAAIAAg ACAAIAAgAFAAUABQAG8AQQAgAPPwIAAgAFAAUABQAG8ARQAAAKEPMAAAABUAAAAAAAAAAAAMAAAA AQACAAEACwABAAAAAQCCAAEAAwALAAgAAAABAAIAAQALAAAAqg88AAAABgAAAAYAAAAJCAAABQAA AAcAAAADAAkIAAAEAAAABgAAAAkIAAAFAAAABwAAAAMACQgAAAEAAAAAAAAAAACmDwgAAABACAAA XwNfAw8ABPBBAQAAEgAK8AgAAAAOAAsAAAoAAHMBC/CKAAAAfwCAAIQAgAD445kMgQAAAAAAggAA AAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQGWlpYAgwEzZv8AvwEcAB4A wAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIB AA8AEwAi8QYAAAC/AQAAYAAAABDwCAAAAGQNfxByEjQODwAN8HkAAAAAAJ8PBAAAAAQAAAAAAKgP BQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYAAAABAGMAAQAEAAIABAAQAAAA qg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8HkBAAAS AArwCAAAAA8ACwAACgAAkwEL8JYAAAB/AIAAhACAAADhlwyBAAAAAACCAAAAAACDAAAAAACEAAAA AACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAQD/AAC/ARwAHgDAAQEAAAjLAWpKAAD/ AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAA DwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBO AH8GBgAOAAAAEPAIAAAAZA0BCfUKRg4PAA3wdQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARVZQAACh DyQAAAAEAAAAAAAWWAAABgAFAAEAWgCQ/wQAAAABAEMAAQAEAAQAEAAAAKoPDAAAAAQAAAAGAAAA CQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBBAQAAEgAK8AgAAAAQAAsAAAoA AHMBC/CKAAAAfwCAAIQAgADEjJcMgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAA vwAQAB8ADAHzAzMQgQGWlpYAgwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLx AZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8AEwAi8QYAAAC/AQAAYAAAABDwCAAAAGQN wQaFCD0ODwAN8HkAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAA BgAFAAEAWgCQ/wYAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADx HgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8IMBAAASAArwCAAAABEACwAACgAAowEL8JwAAAB/AIAA hACAAAyLlwyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/ AQAABgCBAZaWlgCDATNm/wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMD ZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABg AP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ47CdMK jw8PAA3weQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZYAAAGAAUA AQBaAJD/BgAAAAEAYwABAAQAAgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAAAPEeAACg AlABUAGgAqAC8APwA0AFQAUPAATwgQEAABIACvAIAAAAEgALAAAKAACjAQvwnAAAAH8AgACEAIAA ZCaXDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAG AIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUC nDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEA AMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAACuDHMEDAaIDQ8A DfB3AAAAAACfDwQAAAAEAAAAAACoDwMAAABEU0wAAKEPJgAAAAQAAAAAABZYAAAGAAUAAQBaAJD/ BAAAAAEAYwABAAQAAgAEABAAAACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGg AqAC8APwA0AFQAUPAATwMwEAABIACvAIAAAAEwALAAAKAABzAQvwigAAAH8AgACEAIAAzGaXDIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzEIEBlpaWAIMBM2b/ AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8C AgADAL8CAQAPAAAAEPAIAAAAFQuBAr8DwQsPAA3weQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAODAy LjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAEAA4AAACqDwwAAAAG AAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwiAEAABIACvAIAAAA FAALAAAKAADTAQvwrgAAAH8AgACEAIAAXCiXDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAA AIcAAQAAAL8AEAAfAAwB8wMzED8BAAAGAIABBwAAAIEB/2YAAIMB//8AAIsBAACm/4wBZAAAAL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMABvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAVC2YG4AjbDA8ADfBsAAAAAACfDwQAAAAE AAAAAAChDyYAAAABAAAAAAAWWAAABgAFAAEAWgCQ/wEAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAA AQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8KEBAAASAArwCAAA ABUACwAACgAAowEL8JwAAAB/AIAAhACAAKh4lwyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIA AACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAf//AACDAZn/ZgC/ARwAHgDAAQEAAAjLAWpKAAD/ AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAA DwCTACLxNgAAAD8BAABAAL8BIABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBO AH8GBgAOAAAAEPAIAAAAFQvgCFEQ2wwPAA3wlwAAAAAAnw8EAAAABAAAAAAAqA8JAAAAKHJtcCkg RVZDAAChDyYAAAAKAAAAAAAWWAAABgAFAAEAWgCQ/woAAAABAGMAAQAEAAIABAAQAAAAqg8mAAAA AQAAAAAAAAADAAAAAQAAAAMABQAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGg AqAC8APwA0AFQAUPAATwiAEAABIACvAIAAAAFgALAAAKAADTAQvwrgAAAH8AgACEAIAAiLGXDIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzED8BAAAGAIABBwAA AIEB//8AAIMB/2YAAIsBAACm/4wBZAAAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC 8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEA AEAAvwEgAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgA AAAVC1EQoBLbDA8ADfBsAAAAAACfDwQAAAAEAAAAAAChDyYAAAABAAAAAAAWWAAABgAFAAEAWgCQ /wEAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVAB oAKgAvAD8ANABUAFDwAE8IwBAAASAArwCAAAABcACwAACgAAowEL8JwAAAB/AIAAhACAAJzolwyB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAczM AACDAZn/ZgC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BIABgAP8BAADAAb8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAFQtGBDkG9QsPAA3wggAA AAAAnw8EAAAABAAAAAAAqA8GAAAAQVRNIFZDAAChDyYAAAAHAAAAAAAWWAAABgAFAAEAWgCQ/wcA AAABAGMAAQAEAAIABAAQAAAAqg8UAAAABgAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACg AlABUAGgAqAC8APwA0AFQAUPAATwfQEAAKIMCvAIAAAAGAALAAAKAABTAQvwrAAAAIAAQJ6XDIEA IWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMB//9m AIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAA AD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAAFQuUBnEScAsPAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8DAAAATUFDAAChDxgAAAAEAAAA AAAACAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABA CAAAXwNfAw8ABPB9AQAAogwK8AgAAAAZAAsAAAoAAFMBC/CsAAAAgABQn5cMgQAhZQEAggAAAAAA gwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwGZ/2YAhkEaAAAAh8Eu AAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIA awAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEA AGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDQ0J 0wq/DQ8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMAAABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQA AAABAAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE 8H0BAACiDArwCAAAABoACwAACgAAUwEL8KwAAACAAIRFlwyBACFlAQCCAAAAAACDACFlAQCEAAAA AACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAAAAiDAcDAwACGQRoAAACHwS4AAAC/ARwAHgDA AQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcA bgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/ AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQNrBBEEr8NDwAN8GMA AAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFRBRwAAoQ8YAAAABAAAAAAAAAgAAAEABAAAAAEAAgABAAsA AACqDxQAAAADAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwfQEAAKIMCvAI AAAAGwALAAAKAABTAQvwrAAAAIAAYFGXDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8A EAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAO AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQA IABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ47CdMK/A4PAA3wYwAAAAAAnw8EAAAA BAAAAAAAqA8DAAAAVEFHAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMA AAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAAogwK8AgAAAAcAAsAAAoA AFMBC/CsAAAAgAB4NJcMgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYA gAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcA bwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUG AE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDe0GhQi/DQ8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMA AABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAA AQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H0BAACiDArwCAAAAB0ACwAACgAAUwEL8KwAAACA APBVlwyBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAA AAiDAcyZAACGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAA kwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAABDwCAAAABULcgQKBnALDwAN8GMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFZDSQAAoQ8Y AAAABAAAAAAAAAgAAAEABAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAAAAkIAAABAAAAAAAAAAAA pg8IAAAAQAgAAF8DXwMPAATwthMAAKIECvAIAAAAHgALAAAKAACzAAvwjhMAAIUAAgAAAIcAAQAA AIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACIDDGgAAAIHDMhMAAL8DAgACAEQA dABzAFMAaABhAHAAZQBOAGEAbQBlAAAAQwAwADMANQA3AEMANQBDADEARwA0AEMANQA3ADkARABA ADgAMQAxADQANwBAAEUAQABFADYAOQAzADQANQA5ADAAOAA1AEYANABhADgANQBGADwAYwBMADEA MQA4ADEAMQAxADEAMwAhACEAIQBCAEkASABPAEAAXQBMADEAMQA4ADEAMQAxADEAMwAhACEAIQAh ACEAIQAhADEAMQAxADAAQgAzADQAQwA5ADAAQwBHAEcAYwBjACwAYwBgAGIAagBpAGAAdABtACwA YABzAGIAaQBoAHUAZABiAHUAdABzAGQALAAxADEALwBxAHEAdQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhADEAIQAxAAAAAAAQ8AgAAAAAAAAAAQABAA8ABPBe AAAAggUK8AgAAAAfAAsAAAoAAJMAC/A2AAAABAAAAFoAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABKEZMGUBDSEQ8ABPC/AAAAogwK8AgAAAAg AAsAAAoAAKMAC/A8AAAAgAAQAJcMhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAC4EWkKbAziEg8ADfBTAAAAAACfDwQAAAAEAAAAAACo DwMAAABQVE4AAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQAZAAAAqg8UAAAAAwAAAAYAAAAJ CAAAAQAAAAAAAAAPAATwgwEAABIACvAIAAAAIQALAAAKAACjAQvwnAAAAH8AgACEAIAARNCXDIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBlpaW AIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYC nDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMA ggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDooLew2EDw8ADfB5AAAA AACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAA AQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALw A/ADQAVABQ8ABPBJAQAAEgAK8AgAAAAiAAsAAAoAAGMBC/CEAAAAfwCAAIQAgADcPZcMgQAAAAAA ggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQEA/wAAvwEcAB4AwAEB AAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A EwAi8QYAAAC/AQAAYAAAABDwCAAAAGQNWwskED4ODwAN8IcAAAAAAJ8PBAAAAAQAAAAAAKgPAwAA AExTUAAAoQ82AAAABAAAAAAAFlgAAAYABQABAFoAkP8DAAAAAQBDAAEABAAEABAAAQAAAAEEYwAB BAQAAgAEABAAAACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AF QAUPAATwgwEAABIACvAIAAAAIwALAAAKAACjAQvwnAAAAH8AgACEAIAA8AmXDIEAAAAAAIIAAAAA AIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBlpaWAIMBM2b/AL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDjIO9g+EDw8ADfB5AAAAAACfDwQAAAAE AAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEABAAC AAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8A BPB9AQAAogwK8AgAAAAkAAsAAAoAAFMBC/CsAAAAgAAsq5cMgQAhZQEAggAAAAAAgwAhZQEAhAAA AAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwGZ/2YAhkEaAAAAh8EuAAAAvwEcAB4A wAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3 AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMAB vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDYgL9g+/DQ8ADfBj AAAAAACfDwQAAAAEAAAAAACoDwMAAABMU0UAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQAL AAAAqg8UAAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8IEBAACiDArw CAAAACUACwAACgAAUwEL8KwAAACAAOw+lwyBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ ABAAHwA/AQAABgCAAQEAAACBAQAAAAiDAcDAwACGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYA DgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBk ACAAZABpAGEAZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYA TgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKEOXg72D/wODwAN8GcAAAAAAJ8PBAAA AAQAAAAAAKgPBwAAAExTRS9NQUMAAKEPGAAAAAgAAAAAAAAIAAABAAgAAAABAAIAAQALAAAAqg8U AAAABwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8IEBAACiDArwCAAAACYA CwAACgAAUwEL8KwAAACAAICYlwyBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/ AQAABgCAAQEAAACBAQAAAAiDAcDAwACGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIA AAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABp AGEAZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKEOtgtODfwODwAN8GcAAAAAAJ8PBAAAAAQAAAAA AKgPBwAAAExTRS9NQUMAAKEPGAAAAAgAAAAAAAAIAAABAAgAAAABAAIAAQALAAAAqg8UAAAABwAA AAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8L8AAACiDArwCAAAACcACwAACgAA owAL8DwAAACAAKwzkgyFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAgAABDwCAAAAHMOAQdYCA0PDwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAEMt VGFnAAChDxYAAAAGAAAAAAAAAAAABgAAAAMAAgADAAoAAACqDxQAAAAFAAAABgAAAAkIAAABAAAA AAAAAA8ABPDHAAAAogwK8AgAAAAoAAsAAAoAAKMAC/A8AAAAgAAcPJIMhQACAAAAhwAGAAAAvwAC AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACfD2gJvwqZEA8A DfBbAAAAAACfDwQAAAAEAAAAAACoDwsAAABDLVRhZw1TLVRhZwAAoQ8YAAAADAAAAAAAAAgAAAEA DAAAAAMAAgADAAoAAACqDxQAAAALAAAABgAAAAkIAAABAAAAAAAAAA8ABPDKAAAAogwK8AgAAAAp AAsAAAoAAKMAC/A8AAAAgAAURpIMhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACfD5sLYA2ZEA8ADfBeAAAAAACfDwQAAAAEAAAAAACo Dw4AAABQVy1MU0UNTFNQLUxTRQAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAMAAgADAAoAAACqDxQA AAAOAAAABgAAAAkIAAABAAAAAAAAAA8ABPDKAAAAogwK8AgAAAAqAAsAAAoAAKMAC/A8AAAAgABo O5IMhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAQ8AgAAACaDzEO9g+UEA8ADfBeAAAAAACfDwQAAAAEAAAAAACoDw4AAABQVy1MU0UNTFNQLUxT RQAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAMAAgADAAoAAACqDxQAAAAOAAAABgAAAAkIAAABAAAA AAAAAA8ABPC/AAAAogwK8AgAAAArAAsAAAoAAKMAC/A8AAAAgABsIZIMhQACAAAAhwAGAAAAvwAC AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABzDtoQMRINDw8A DfBTAAAAAACfDwQAAAAEAAAAAACoDwUAAABDLVRhZwAAoQ8WAAAABgAAAAAAAAAAAAYAAAADAAIA AwAKAAAAqg8UAAAABQAAAAYAAAAJCAAAAQAAAAAAAAAPAATwyQAAABIACvAIAAAALQALAAAKAACj AAvwPAAAAH8AAAAEAIAAeHBODIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B CAAIAAECAgAACAAAEPAIAAAAnguTBkQS+AsPAA3wXQAAAAAAnw8EAAAABAAAAAAAqA8NAAAATUVH IChsZXZlbCA3KQAAoQ8YAAAADgAAAAAAAAgAAAEADgAAAAMAAgADAAsAAACqDxQAAAANAAAABgAA AAkIAAABAAAAAAAAAA8ABPDoAAAAEgAK8AgAAAAuAAsAAAoAAKMAC/A8AAAAfwAAAAQAgAAIOQII hQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD4 C8AGfhBSDA8ADfB8AAAAAACfDwQAAAAEAAAAAACoDywAAAAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTUVHIChsZXZlbCA0KQAAoQ8YAAAALQAAAAAAAAgAAAEALQAAAAMAAgADAAsAAACq DxQAAAAsAAAABgAAAAkIAAABAAAAAAAAAA8ABPBeAAAAUgAK8AgAAAAvAAsAgAoAAJMAC/A2AAAA BAAAAA4BhQACAAAAhwABAAAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ 8AgAAACdC+kRRBL4Cw8ABPBkAAAAUgQK8AgAAAAwAAsAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAA RwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACe C1EQrBD5Cw8ABPBeAAAAUgAK8AgAAAAxAAsAgAoAAJMAC/A2AAAABAAAAA4BhQACAAAAhwABAAAA gQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD4CyQQfxBTDA8ABPBk AAAAUgQK8AgAAAAyAAsAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAA gwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD5C5wP9w9UDA8ABPBeAAAAUgAK 8AgAAAAzAAsAwAoAAJMAC/A2AAAABAAAAA4BhQACAAAAhwABAAAAgQEAAAAAgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD3C8AGGwdSDA8ABPBkAAAAUgQK8AgAAAA0AAsAAAoA AKMAC/A8AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAQ8AgAAAD4C1sLtgtTDA8ABPBkAAAAUgQK8AgAAAA1AAsAAAoAAKMAC/A8 AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIAAAQ8AgAAAD4C6YKAQtTDA8ABPBkAAAAUgQK8AgAAAA2AAsAAAoAAKMAC/A8AAAAhQAC AAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI AAAQ8AgAAAD4Cw4JaQlTDA8ABPBkAAAAUgQK8AgAAAA3AAsAAAoAAKMAC/A8AAAAhQACAAAAhwAB AAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgA AAD4C1gIswhTDA8ABPBeAAAAUgAK8AgAAAA6AAsAwAoAAJMAC/A2AAAABAAAAA4BhQACAAAAhwAB AAAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACeC5MG7gb5Cw8A BPBSAAAAQgEK8AgAAAA7AAsAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIzgEG AAAA/wEYABgAAQICAAAIAAAQ8AgAAADLC5MGRBLLCw8ABPBSAAAAQgEK8AgAAAA8AAsAAAoAAHMA C/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIzgEHAAAA/wEYABgAAQICAAAIAAAQ8AgAAAAm DMAGfxAmDA8ABPBIAAAAEgAK8AgAAAABAAsAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwEV7aIA lAG2LnoAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+Dj ADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT aQAAAAAA6y4IAAAAjrTJAQBUvqwAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAA AAAAAAAAAAAAAAAAAJkM/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gPl TwAAAgDvAxgAAAABAAAADQ4AAAAAAAADAACAAAAAAAcACzAPAAwE/E4AAA8AAvD0TgAAQCkI8AgA AAA5AAAAPAQLAA8AA/CMTgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AAAECwAFAAAADwAE8GgBAAASAArwCAAAAAIECwAACgAAkwEL8JYAAAB/AAAABACAACyOkgyBACFl AQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCD AQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAANg1ODWAOwRAPAA3wZAAAAAAAnw8EAAAA BAAAAAAAqA8EAAAAQ29yZQAAoQ8YAAAABQAAAAAAAAgAAAEABQAAAAEAAgABAAsAAACqDxQAAAAE AAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwfgAAABIACvAIAAAAAwQLACAC AABzAAvwKgAAAAQAAAAAAH8AAAAEAIAAgJCSDL8BAAABAP8BAAABAAEDAngBAIgDAAAAAAAAEPAI AAAAGQBQAfIYlAIPABHwEAAAAAAAwwsIAAAAAAAAAA0AkgwPAA3wDAAAAAAAng8EAAAAAAAAAA8A BPB3AQAAEgAK8AgAAAAEBAsAAAoAAJMBC/CWAAAAfwAAAAQAgABUnZIMgQAhZQEAggCQsgAAgwAh ZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4A wAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIW AB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYA TgA/BgYATgB/BgYADgAAABDwCAAAAFAJQxJUE+8QDwAN8HMAAAAAAJ8PBAAAAAQAAAAAAKgPEwAA AFNlcnZpY2UNRWRnZQ1Sb3V0ZXIAAKEPGAAAABQAAAAAAAAIAAABABQAAAABAAIAAQALAAAAqg8U AAAAEwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8JIBAAASAArwCAAAAAUE CwAACgAAkwEL8JYAAAB/AAAABACAABiokgyBACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACH AAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUA AAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAA AD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAA6AreBe8GwRAPAA3wjgAAAAAAnw8EAAAABAAAAAAAqA8UAAAAVkRTTDINb3INRmliZXIN RFNMQU0AAKEPGAAAABUAAAAAAAAIAAABABUAAAABAAIAAQALAAAAqg8uAAAACQAAAAYAAAAJCAAA BQAAAAcAAAADAAkIAAAGAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwdQEA ABIACvAIAAAABgQLAAAKAACTAQvwlgAAAH8AAAAEAIAAgLKSDIEAIWUBAIIAkLIAAIMAIWUBAIQA kLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB3d3dAIMBAAAACL8BHAAeAMABAQAA CP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8D AAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG AE4AfwYGAA4AAAAQ8AgAAADoCskP2xDBEA8ADfBxAAAAAACfDwQAAAAEAAAAAACoDxEAAABXaG9s ZQ1zYWxlDUFjY2VzcwAAoQ8YAAAAEgAAAAAAAAgAAAEAEgAAAAEAAgABAAsAAACqDxQAAAARAAAA BgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwbgEAABIACvAIAAAABwQLAAAKAACT AQvwlgAAAH8AAAAEAIAALLySDIEAIWUBAIIAkLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8A EAAfAAwB8wMzED8BAAAGAIEB3d3dAIMBAAAACL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZ EAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAA vwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADo CqUKtwvBEA8ADfBqAAAAAACfDwQAAAAEAAAAAACoDwoAAABNZXRybw1Db3JlAAChDxgAAAALAAAA AAAACAAAAQALAAAAAQACAAEACwAAAKoPFAAAAAoAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABA CAAAXwNfAw8ABPBuAQAAEgAK8AgAAAAIBAsAAAoAAJMBC/CWAAAAfwAAAAQAgABExpIMgQAhZQEA ggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEA AAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAOgKWQhqCcEQDwAN8GoAAAAAAJ8PBAAAAAQA AAAAAKgPCgAAAE1ldHJvDUVkZ2UAAKEPGAAAAAsAAAAAAAAIAAABAAsAAAABAAIAAQALAAAAqg8U AAAACgAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8HABAAASAArwCAAAAAkE CwAACgAAkwEL8JYAAAB/AAAABACAAFTHkgyBACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACH AAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUA AAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAA AD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAAVQmQA6EEwRAPAA3wbAAAAAAAnw8EAAAABAAAAAAAqA8MAAAASE9NRQ1HV0FZDUlJAACh DxgAAAANAAAAAAAACAAAAQANAAAAAQACAAEACwAAAKoPFAAAAAwAAAAGAAAACQgAAAEAAAAAAAAA AACmDwgAAABACAAAXwNfAw8ABPBGAQAAEgAK8AgAAAAKBAsAAAoAAGMBC/CEAAAAfwAAAAQAgACk BZIMgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQHd3d0A gwEAAAAIvwEQABAAwAEBAAAI/wEAAAgAAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwIC AAIAvwIAAAgAUwAi8R4AAAC/AQAAYAB/BQAACAC/BQAACAD/BQAACAA/BgAACAAAABDwCAAAAFMJ ygHcAsEQDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKgPDAAAAFBIT05FDVNUQg1QQwAAoQ8YAAAADQAA AAAAAAgAAAEADQAAAAEAAgABAAsAAACqDxQAAAAMAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAA QAgAAF8DXwMPAATwjAEAABIACvAIAAAACwQLAAAKAACDAQvwkAAAAH8AgACEAIAAPI+SDIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB/8wAAL8BHAAeAMAB AQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAP AP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A /wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAB9CSYCKhZdCg8ADfCOAAAAAACfDwQAAAAEAAAAAACo DwIAAABJUAAAoQ82AAAAAwAAAAAAFlgAAAYABQABAFoAkP8CAAAAAQBDAAEABAAEABAAAQAAAAEE YwABBAQAAgAEABAAAACqDxQAAAACAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPA6AQAAogwK8AgAAAAMBAsAAAoAAAMBC/COAAAAgACgxpIMgQAhZQEA ggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8AgAEBAAAAgQEAAAAIgwH/zAAAhkEaAAAAh8Eu AAAAvwEUABQAwAEBAAAI/wEAAAgAAQICAAAIRABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQA aQBhAGcAbwBuAGEAbAAAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAAFChgEnxJgCg8ADfBuAAAAAACf DwQAAAAEAAAAAACoDw4AAAAgICAgICBQUFAvREhDUAAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAEA AgABAAsAAACqDxQAAAAOAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwQQEA ABIACvAIAAAADQQLAAAKAABzAQvwigAAAH8AgACEAIAA5MaBDIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzEIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoA AP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPABMAIvEGAAAA vwEAAGAAAAAQ8AgAAABkDX8QchI0Dg8ADfB5AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAA oQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAG AAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPB5AQAAEgAK8AgAAAAOBAsA AAoAAJMBC/CWAAAAfwCAAIQAgADU0IEMgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwAC AAAAvwAQAB8ADAHzAzMQPwEAAAYAgQEA/wAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAA AQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/ AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDw CAAAAGQNAQn1CkYODwAN8HUAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEVWUAAAoQ8kAAAABAAAAAAA FlgAAAYABQABAFoAkP8EAAAAAQBDAAEABAAEABAAAACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAA APEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwQQEAABIACvAIAAAADwQLAAAKAABzAQvwigAAAH8A gACEAIAAQMeBDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMz EIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUC nDEAAAYCnDEAAD8CAgADAL8CAQAPABMAIvEGAAAAvwEAAGAAAAAQ8AgAAABkDcEGhQg9Dg8ADfB5 AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8G AAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaAC oALwA/ADQAVABQ8ABPCDAQAAEgAK8AgAAAAQBAsAAAoAAKMBC/CcAAAAfwCAAIQAgAB80YEMgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQGWlpYA gwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKc MQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCC AIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKEOigt7DYQPDwAN8HkAAAAA AJ8PBAAAAAQAAAAAAKgPBQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYAAAAB AGMAAQAEAAIABAAQAAAAqg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD 8ANABUAFDwAE8IMBAAASAArwCAAAABEECwAACgAAowEL8JwAAAB/AIAAhACAAPy8gQyBAAAAAACC AAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAZaWlgCDATNm /wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/ AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8F BgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ47CdMKjw8PAA3weQAAAAAAnw8E AAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwAB AAQAAgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AF QAUPAATwgQEAABIACvAIAAAAEgQLAAAKAACjAQvwnAAAAH8AgACEAIAA6OyBDIEAAAAAAIIAAAAA AIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBlpaWAIMBM2b/AL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAABjDXMEDAY9Dg8ADfB3AAAAAACfDwQAAAAE AAAAAACoDwMAAABEU0wAAKEPJgAAAAQAAAAAABZYAAAGAAUAAQBaAJD/BAAAAAEAYwABAAQAAgAE ABAAAACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATw MwEAABIACvAIAAAAEwQLAAAKAABzAQvwigAAAH8AgACEAIAAhPaBDIEAAAAAAIIAAAAAAIMAAAAA AIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzEIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsB akoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAAAAEPAI AAAAFQuBAr8DwQsPAA3weQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAA ABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAEAA4AAACqDwwAAAAGAAAABgAAAAkIBAgAAKYP FgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwiAEAABIACvAIAAAAFAQLAAAKAADTAQvwrgAA AH8AgACEAIAAjP6BDIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB 8wMzED8BAAAGAIABBwAAAIEB/2YAAIMB//8AAIsBAACm/4wBZAAAAL8BHAAeAMABAQAACMsBakoA AP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8D AAAPAJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG AE4AfwYGAA4AAAAQ8AgAAAAVCxgEkgbbDA8ADfBsAAAAAACfDwQAAAAEAAAAAAChDyYAAAABAAAA AAAWWAAABgAFAAEAWgCQ/wEAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAAAQAAAAYAAAAJCAQIAACm DxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8KEBAAASAArwCAAAABUECwAACgAAowEL8JwA AAB/AIAAhACAAICRhQyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAM AfMDMxA/AQAABgCBAf//AACDAZn/ZgC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEB mRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABA AL8BIABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA FQuTBlEQ2wwPAA3wlwAAAAAAnw8EAAAABAAAAAAAqA8JAAAAKHJtcCkgRVZDAAChDyYAAAAKAAAA AAAWWAAABgAFAAEAWgCQ/woAAAABAGMAAQAEAAIABAAQAAAAqg8mAAAAAQAAAAAAAAADAAAAAQAA AAMABQAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATw iAEAABIACvAIAAAAFgQLAAAKAADTAQvwrgAAAH8AgACEAIAAgFWFDIEAAAAAAIIAAAAAAIMAAAAA AIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzED8BAAAGAIABBwAAAIEB//8AAIMB/2YAAIsB AACm/4wBZAAAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEA AAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEgAGAA/wEAAMAB vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAVC1EQoBLbDA8ADfBs AAAAAACfDwQAAAAEAAAAAAChDyYAAAABAAAAAAAWWAAABgAFAAEAWgCQ/wEAAAABAGMAAQAEAAIA BAAQAAAAqg8MAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE 8EkBAAASAArwCAAAABcECwAACgAAYwEL8IQAAAB/AIAAhACAAJCShQyBAAAAAACCAAAAAACDAAAA AACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAQD/AAC/ARwAHgDAAQEAAAjLAWpKAAD/ AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwATACLxBgAAAL8B AABgAAAAEPAIAAAAZA1bCyQQPg4PAA3whwAAAAAAnw8EAAAABAAAAAAAqA8DAAAATFNQAAChDzYA AAAEAAAAAAAWWAAABgAFAAEAWgCQ/wMAAAABAEMAAQAEAAQAEAABAAAAAQRjAAEEBAACAAQAEAAA AKoPDAAAAAQAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPCwAQAA ogwK8AgAAAAYBAsAAAoAAFMBC/CsAAAAgADckYUMgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQAC AAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwH//2YAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI /wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBh AHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAVC0UEcRJwCw8ADfCWAAAAAACf DwQAAAAEAAAAAACgDx4AAABDAC0ATQBBAEMAIADz8CAAUABDAEMALQBNAEEAQwAAAKEPMAAAABAA AAAAAAAAAAAGAAAAAQACAAEACwABAAAAAQCCAAEAAwALAAkAAAABAAIAAQALAAAAqg8UAAAADwAA AAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8IMBAAASAArwCAAAABkECwAACgAA owEL8JwAAAB/AIAAhACAAFzahQyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ ABAAHwAMAfMDMxA/AQAABgCBAZaWlgCDATNm/wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUA AAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAA AD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAA EPAIAAAAoQ4yDvYPhA8PAA3weQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYA AAAAABZYAAAGAAUAAQBaAJD/BgAAAAEAYwABAAQAAgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgA AKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwfQEAAKIMCvAIAAAAGgQLAAAKAABTAQvw rAAAAIAAHDiFDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAA AIEBAAAACIMBmf9mAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBh AGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8G BgBOAH8GBgAOAAAAEPAIAAAAZA2IC/YPvw0PAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8DAAAATFNF AAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAA AAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAAogwK8AgAAAAbBAsAAAoAAFMBC/CsAAAAgABsAoUM gQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwGZ /2YAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2 AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4A AAAQ8AgAAABkDQ0J0wq/DQ8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMAAABUQUcAAKEPGAAAAAQA AAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAA AEAIAABfA18DDwAE8H0BAACiDArwCAAAABwECwAACgAAUwEL8KwAAACAAAhwhQyBACFlAQCCAAAA AACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAAAAiDAcDAwACGQRoAAACH wS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEA cgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/ AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQN rBBEEr8NDwAN8GMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFRBRwAAoQ8YAAAABAAAAAAAAAgAAAEA BAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMP AATwgQEAAKIMCvAIAAAAHQQLAAAKAABTAQvwrAAAAIAAyAuFDIEAIWUBAIIAAAAAAIMAIWUBAIQA AAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAe AMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8A dwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADA Ab8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ5eDvYP/A4PAA3w ZwAAAAAAnw8EAAAABAAAAAAAqA8HAAAATFNFL01BQwAAoQ8YAAAACAAAAAAAAAgAAAEACAAAAAEA AgABAAsAAACqDxQAAAAHAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwgQEA AKIMCvAIAAAAHgQLAAAKAABTAQvwrAAAAIAAbEiFDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUA AgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcA YQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ62C04N/A4PAA3wZwAAAAAA nw8EAAAABAAAAAAAqA8HAAAATFNFL01BQwAAoQ8YAAAACAAAAAAAAAgAAAEACAAAAAEAAgABAAsA AACqDxQAAAAHAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwfQEAAKIMCvAI AAAAHwQLAAAKAABTAQvwrAAAAIAAFEqFDIEAIWUBAIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8A EAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZBGgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAO AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQA IABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBO AL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ47CdMK/A4PAA3wYwAAAAAAnw8EAAAA BAAAAAAAqA8DAAAAVEFHAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMA AAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAAogwK8AgAAAAgBAsAAAoA AFMBC/CsAAAAgAAIE4UMgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYA gAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcA bwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUG AE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDe0GhQi/DQ8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMA AABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAA AQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8LYTAACiBArwCAAAACEECwAACgAAswAL8I4TAACF AAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAiAwxoAAACBwzIT AAC/AwIAAgBEAHQAcwBTAGgAYQBwAGUATgBhAG0AZQAAAEMAMAAzADUANwBDADUAQwAxAEcANABD ADUANwA5AEQAQAA4ADEAMQA0ADcAQABFAEAARQA2ADkAMwA0ADUAOQAwADgANQBGADQAYQA4ADUA RgA3ADYATAAxADEAOAAxADEAMQAxADMAIQAhACEAQgBJAEgATwBAAF0ATAAxADEAOAAxADEAMQAx ADMAIQAhACEAIQAhACEAIQAxADEAMQAwAEIAMwA0AEMAOQAwAEMARwBHAGMAYwAsAGMAYABiAGoA aQBgAHQAbQAsAGAAcwBiAGkAaAB1AGQAYgB1AHQAcwBkACwAMQAxAC8AcQBxAHUAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAxACEAMQAAAAAAEPAIAAAAAAAA AAEAAQAPAATwXgAAAIIFCvAIAAAAIgQLAAAKAACTAAvwNgAAAAQAAABaAIUAAgAAAIcAAQAAAIEB BAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAShGTBlAQ0hEPAATwvwAA AKIMCvAIAAAAIwQLAAAKAACjAAvwPAAAAIAAeKuFDIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMB AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAuBFpCmwM4hIPAA3wUwAAAAAAnw8E AAAABAAAAAAAqA8DAAAAUFROAAChDxgAAAAEAAAAAAAACAAAAQAEAAAAAQACAAEAGQAAAKoPFAAA AAMAAAAGAAAACQgAAAEAAAAAAAAADwAE8L8AAACiDArwCAAAACQECwAACgAAowAL8DwAAACAAFS1 hQyFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA ABDwCAAAAHMOAQdYCA0PDwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAEMtVGFnAAChDxYAAAAG AAAAAAAAAAAABgAAAAMAAgADAAoAAACqDxQAAAAFAAAABgAAAAkIAAABAAAAAAAAAA8ABPDHAAAA ogwK8AgAAAAlBAsAAAoAAKMAC/A8AAAAgAA0GIUMhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACfD2gJvwqZEA8ADfBbAAAAAACfDwQA AAAEAAAAAACoDwsAAABDLVRhZw1TLVRhZwAAoQ8YAAAADAAAAAAAAAgAAAEADAAAAAMAAgADAAoA AACqDxQAAAALAAAABgAAAAkIAAABAAAAAAAAAA8ABPDKAAAAogwK8AgAAAAmBAsAAAoAAKMAC/A8 AAAAgADMIoUMhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAQ8AgAAACfD5sLYA2ZEA8ADfBeAAAAAACfDwQAAAAEAAAAAACoDw4AAABQVy1MU0UN TFNQLUxTRQAAoQ8YAAAADwAAAAAAAAgAAAEADwAAAAMAAgADAAoAAACqDxQAAAAOAAAABgAAAAkI AAABAAAAAAAAAA8ABPDKAAAAogwK8AgAAAAnBAsAAAoAAKMAC/A8AAAAgADULIUMhQACAAAAhwAG AAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACaDzEO 9g+UEA8ADfBeAAAAAACfDwQAAAAEAAAAAACoDw4AAABQVy1MU0UNTFNQLUxTRQAAoQ8YAAAADwAA AAAAAAgAAAEADwAAAAMAAgADAAoAAACqDxQAAAAOAAAABgAAAAkIAAABAAAAAAAAAA8ABPC/AAAA ogwK8AgAAAAoBAsAAAoAAKMAC/A8AAAAgACwNoUMhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABzDtoQMRINDw8ADfBTAAAAAACfDwQA AAAEAAAAAACoDwUAAABDLVRhZwAAoQ8WAAAABgAAAAAAAAAAAAYAAAADAAIAAwAKAAAAqg8UAAAA BQAAAAYAAAAJCAAAAQAAAAAAAAAPAATw8gAAABIACvAIAAAAKQQLACAKAABzAQvwigAAAAQAAAAA AH8AAQAFAIAAIIhODIEA8mQBAIIAe7IAAIMA8mQBAIQAe7IAAIUAAAAAAIYAAAAAAIcAAAAAAIgA AAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAIEBBAAACIMBAAAACL8BAAARAMABAQAACP8BAAAJ AAECAgAACAEDA3gBAIgDAAAAACMAIvEMAAAAjAABAAAAjQAwZQEAAAAQ8AgAAABKA1AB8hj2CA8A EfAQAAAAAADDCwgAAAABAAAADgCFDA8ADfAMAAAAAACeDwQAAAABAAAADwAE8MkAAAASAArwCAAA ACsECwAACgAAowAL8DwAAAB/AAAABACAAJxohQyFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAJ4LcgREEvgLDwAN8F0AAAAAAJ8PBAAAAAQAAAAA AKgPDQAAAE1FRyAobGV2ZWwgNykAAKEPGAAAAA4AAAAAAAAIAAABAA4AAAADAAIAAwALAAAAqg8U AAAADQAAAAYAAAAJCAAAAQAAAAAAAAAPAATw6AAAABIACvAIAAAALAQLAAAKAACjAAvwPAAAAH8A AAAEAIAA7H8CCIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAA CAAAEPAIAAAA+AvABn4QUgwPAA3wfAAAAAAAnw8EAAAABAAAAAAAqA8sAAAAICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE1FRyAobGV2ZWwgNCkAAKEPGAAAAC0AAAAAAAAIAAABAC0AAAAD AAIAAwALAAAAqg8UAAAALAAAAAYAAAAJCAAAAQAAAAAAAAAPAATwXgAAAFIACvAIAAAALQQLAIAK AACTAAvwNgAAAAQAAAAOAYUAAgAAAIcAAQAAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAI AAECAgAACAAAEPAIAAAAnQvpEUQS+AsPAATwZAAAAFIECvAIAAAALgQLAAAKAACjAAvwPAAAAIUA AgAAAIcAAQAAAEcB0RsAAEgBCRkAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAA CAAAEPAIAAAAngtREKwQ+QsPAATwXgAAAFIACvAIAAAALwQLAIAKAACTAAvwNgAAAAQAAAAOAYUA AgAAAIcAAQAAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA+Ask EH8QUwwPAATwZAAAAFIECvAIAAAAMAQLAAAKAACjAAvwPAAAAIUAAgAAAIcAAQAAAEcB0RsAAEgB CRkAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA+QucD/cPVAwP AATwXgAAAFIACvAIAAAAMQQLAMAKAACTAAvwNgAAAAQAAAAOAYUAAgAAAIcAAQAAAIEBAAAAAIMB AAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA9wvABhsHUgwPAATwZAAAAFIECvAI AAAAMgQLAAAKAACjAAvwPAAAAIUAAgAAAIcAAQAAAEcB0RsAAEgBCRkAAIEBAAAAAIMBAAAACL8B EAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA+AtbC7YLUwwPAATwZAAAAFIECvAIAAAAMwQL AAAKAACjAAvwPAAAAIUAAgAAAIcAAQAAAEcB0RsAAEgBCRkAAIEBAAAAAIMBAAAACL8BEAAQAMAB AQAACP8BCAAIAAECAgAACAAAEPAIAAAA+AumCgELUwwPAATwZAAAAFIECvAIAAAANAQLAAAKAACj AAvwPAAAAIUAAgAAAIcAAQAAAEcB0RsAAEgBCRkAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACAAAEPAIAAAA+AsOCWkJUwwPAATwZAAAAFIECvAIAAAANQQLAAAKAACjAAvwPAAA AIUAAgAAAIcAAQAAAEcB0RsAAEgBCRkAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAEC AgAACAAAEPAIAAAA+AtYCLMIUwwPAATwZAAAAFIECvAIAAAANgQLAAAKAACjAAvwPAAAAIUAAgAA AIcAAQAAAEcB0RsAAEgBCRkAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAA EPAIAAAAnguTBu4G+QsPAATwZAAAAFIECvAIAAAANwQLAAAKAACjAAvwPAAAAIUAAgAAAIcAAQAA AEcB0RsAAEgBCRkAAIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA ngvdBTgG+QsPAATwXgAAAFIACvAIAAAAOgQLAMAKAACTAAvwNgAAAAQAAAAOAYUAAgAAAIcAAQAA AIEBAAAAAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAngtyBM0E+QsPAATw UgAAAEIBCvAIAAAAOwQLAAAKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BBgAA AP8BGAAYAAECAgAACAAAEPAIAAAAywtyBEQSywsPAATwUgAAAEIBCvAIAAAAPAQLAAAKAABzAAvw KgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BBwAAAP8BGAAYAAECAgAACAAAEPAIAAAAJgzA Bn8QJgwPAATwSAAAABIACvAIAAAAAQQLAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBFe2iAJQB ti56AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAz M5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kA AAAAAOsuCAAAAI60yQEAVL6sAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAA AAAAAAAAAAAAAACZDP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DNlEA AAIA7wMYAAAAAQAAAA0OAAAAAAAAAwAAgAAAAAAHAAswDwAMBE1QAAAPAALwRVAAACApCPAIAAAA OwAAADv8CgAPAAPw3U8AAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA /AoABQAAAA8ABPCSAQAAEgAK8AgAAAAC/AoAAAoAAJMBC/CWAAAAfwAAAAQAgABMJjQKgQAhZQEA ggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEA AAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAOgK3gXvBsEQDwAN8I4AAAAAAJ8PBAAAAAQA AAAAAKgPFAAAAFZEU0wyDW9yDUZpYmVyDURTTEFNAAChDxgAAAAVAAAAAAAACAAAAQAVAAAAAQAC AAEACwAAAKoPLgAAAAkAAAAGAAAACQgAAAUAAAAHAAAAAwAJCAAABgAAAAYAAAAJCAAAAQAAAAAA AAAAAKYPCAAAAEAIAABfA18DDwAE8GgBAAASAArwCAAAAAP8CgAACgAAkwEL8JYAAAB/AAAABACA AFAuNAqBACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAA BgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAG ApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8D AIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAANg1ODWAOwRAPAA3wZAAA AAAAnw8EAAAABAAAAAAAqA8EAAAAQ29yZQAAoQ8YAAAABQAAAAAAAAgAAAEABQAAAAEAAgABAAsA AACqDxQAAAAEAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwfgAAABIACvAI AAAABPwKACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAAaI1MDL8BAAABAP8BAAABAAEDAngBAIgD AAAAAAAAEPAIAAAAGQBQAfIYlAIPABHwEAAAAAAAwwsIAAAAAAAAAA0ATAwPAA3wDAAAAAAAng8E AAAAAAAAAA8ABPB3AQAAEgAK8AgAAAAF/AoAAAoAAJMBC/CWAAAAfwAAAAQAgADMu60IgQAhZQEA ggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEA AAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAFAJQxJUE+8QDwAN8HMAAAAAAJ8PBAAAAAQA AAAAAKgPEwAAAFNlcnZpY2UNRWRnZQ1Sb3V0ZXIAAKEPGAAAABQAAAAAAAAIAAABABQAAAABAAIA AQALAAAAqg8UAAAAEwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8HUBAAAS AArwCAAAAAb8CgAACgAAkwEL8JYAAAB/AAAABACAAPwLrQiBACFlAQCCAJCyAACDACFlAQCEAJCy AACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/ AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAA DwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBO AH8GBgAOAAAAEPAIAAAA6ArJD9sQwRAPAA3wcQAAAAAAnw8EAAAABAAAAAAAqA8RAAAAV2hvbGUN c2FsZQ1BY2Nlc3MAAKEPGAAAABIAAAAAAAAIAAABABIAAAABAAIAAQALAAAAqg8UAAAAEQAAAAYA AAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8G4BAAASAArwCAAAAAf8CgAACgAAkwEL 8JYAAAB/AAAABACAANQNrQiBACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAA HwAMAfMDMxA/AQAABgCBAd3d3QCDAQAAAAi/ARwAHgDAAQEAAAj/AQYADgAAAgUAAAABAvEBmRAC AvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8B AABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA6Aql CrcLwRAPAA3wagAAAAAAnw8EAAAABAAAAAAAqA8KAAAATWV0cm8NQ29yZQAAoQ8YAAAACwAAAAAA AAgAAAEACwAAAAEAAgABAAsAAACqDxQAAAAKAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgA AF8DXwMPAATwbgEAABIACvAIAAAACPwKAAAKAACTAQvwlgAAAH8AAAAEAIAAYM+tCIEAIWUBAIIA kLIAAIMAIWUBAIQAkLIAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEB3d3dAIMBAAAA CL8BHAAeAMABAQAACP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8C AQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUG AE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADoClkIagnBEA8ADfBqAAAAAACfDwQAAAAEAAAA AACoDwoAAABNZXRybw1FZGdlAAChDxgAAAALAAAAAAAACAAAAQALAAAAAQACAAEACwAAAKoPFAAA AAoAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBxAQAAEgAK8AgAAAAJ/AoA AAoAAJMBC/CWAAAAfwAAAAQAgAA0Lq0IgQAhZQEAggCQsgAAgwAhZQEAhACQsgAAhQACAAAAhwAC AAAAvwAQAB8ADAHzAzMQPwEAAAYAgQHd3d0AgwEAAAAIvwEcAB4AwAEBAAAI/wEGAA4AAAIFAAAA AQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/ AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDw CAAAAOgKkAOhBMEQDwAN8G0AAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAEhPTUUNR1dBWQ1JSUkAAKEP GAAAAA4AAAAAAAAIAAABAA4AAAABAAIAAQALAAAAqg8UAAAADQAAAAYAAAAJCAAAAQAAAAAAAAAA AKYPCAAAAEAIAABfA18DDwAE8EYBAAASAArwCAAAAAr8CgAACgAAYwEL8IQAAAB/AAAABACAAECU rQiBACFlAQCCAJCyAACDACFlAQCEAJCyAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxCBAd3d3QCD AQAAAAi/ARAAEADAAQEAAAj/AQAACAAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIA AgC/AgAACABTACLxHgAAAL8BAABgAH8FAAAIAL8FAAAIAP8FAAAIAD8GAAAIAAAAEPAIAAAAUwnK AdwCwRAPAA3wbAAAAAAAnw8EAAAABAAAAAAAqA8MAAAAUEhPTkUNU1RCDVBDAAChDxgAAAANAAAA AAAACAAAAQANAAAAAQACAAEACwAAAKoPFAAAAAwAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABA CAAAXwNfAw8ABPCMAQAAEgAK8AgAAAAL/AoAAAoAAIMBC/CQAAAAfwCAAIQAgABoaq0IgQAAAAAA ggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQH/zAAAvwEcAB4AwAEB AAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A /wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAABDwCAAAAH0JJgIqFl0KDwAN8I4AAAAAAJ8PBAAAAAQAAAAAAKgP AgAAAElQAAChDzYAAAADAAAAAAAWWAAABgAFAAEAWgCQ/wIAAAABAEMAAQAEAAQAEAABAAAAAQRj AAEEBAACAAQAEAAAAKoPFAAAAAIAAAAAAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVAB oAKgAvAD8ANABUAFDwAE8DoBAACiDArwCAAAAAz8CgAACgAAAwEL8I4AAACAAITsrQiBACFlAQCC AAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwCAAQEAAACBAQAAAAiDAf/MAACGQRoAAACHwS4A AAC/ARQAFADAAQEAAAj/AQAACAABAgIAAAhEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABp AGEAZwBvAG4AYQBsAAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAAAUKUgKfEmAKDwAN8G4AAAAAAJ8P BAAAAAQAAAAAAKgPDgAAACAgICAgIFBQUC9ESENQAAChDxgAAAAPAAAAAAAACAAAAQAPAAAAAQAC AAEACwAAAKoPFAAAAA4AAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPBBAQAA EgAK8AgAAAAN/AoAAAoAAHMBC/CKAAAAfwCAAIQAgAAMFq0IgQAAAAAAggAAAAAAgwAAAAAAhAAA AAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQGWlpYAgwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA /wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8AEwAi8QYAAAC/ AQAAYAAAABDwCAAAAGQNfxByEjQODwAN8HkAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAADgwMi4zAACh DyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYAAAABAGMAAQAEAAIABAAQAAAAqg8MAAAABgAAAAYA AAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8HkBAAASAArwCAAAAA78CgAA CgAAkwEL8JYAAAB/AIAAhACAADimrQiBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIA AAC/ABAAHwAMAfMDMxA/AQAABgCBAQD/AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8B AABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAI AAAAZA0BCfUKRg4PAA3wdQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARVZQAAChDyQAAAAEAAAAAAAW WAAABgAFAAEAWgCQ/wQAAAABAEMAAQAEAAQAEAAAAKoPDAAAAAQAAAAGAAAACQgECAAApg8WAAAA 8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBBAQAAEgAK8AgAAAAP/AoAAAoAAHMBC/CKAAAAfwCA AIQAgABg+60IgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQ gQGWlpYAgwEzZv8AvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKc MQAABgKcMQAAPwICAAMAvwIBAA8AEwAi8QYAAAC/AQAAYAAAABDwCAAAAGQNwQaFCD0ODwAN8HkA AAAAAJ8PBAAAAAQAAAAAAKgPBQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYA AAABAGMAAQAEAAIABAAQAAAAqg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKg AvAD8ANABUAFDwAE8IMBAAASAArwCAAAABD8CgAACgAAowEL8JwAAAB/AIAAhACAAAB8rQiBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAIAAAC/ABAAHwAMAfMDMxA/AQAABgCBAZaWlgCD ATNm/wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAoQ6KC3sNhA8PAA3weQAAAAAA nw8EAAAABAAAAAAAqA8FAAAAODAyLjMAAKEPJgAAAAYAAAAAABZYAAAGAAUAAQBaAJD/BgAAAAEA YwABAAQAAgAEABAAAACqDwwAAAAGAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APw A0AFQAUPAATwgwEAABIACvAIAAAAEfwKAAAKAACjAQvwnAAAAH8AgACEAIAAKHKrCIEAAAAAAIIA AAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBlpaWAIMBM2b/ AL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8C AgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUG AE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDjsJ0wqPDw8ADfB5AAAAAACfDwQA AAAEAAAAAACoDwUAAAA4MDIuMwAAoQ8mAAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEA BAACAAQAEAAAAKoPDAAAAAYAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVA BQ8ABPCBAQAAEgAK8AgAAAAS/AoAAAoAAKMBC/CcAAAAfwCAAIQAgACc16sIgQAAAAAAggAAAAAA gwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQGWlpYAgwEzZv8AvwEc AB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMA vwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/ BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGMNcwQMBj0ODwAN8HcAAAAAAJ8PBAAAAAQA AAAAAKgPAwAAAERTTAAAoQ8mAAAABAAAAAAAFlgAAAYABQABAFoAkP8EAAAAAQBjAAEABAACAAQA EAAAAKoPDAAAAAQAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPCD AQAAEgAK8AgAAAAT/AoAAAoAAKMBC/CcAAAAfwCAAIQAgAAQdKsIgQAAAAAAggAAAAAAgwAAAAAA hAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQGWlpYAgwEzZv8AvwEcAB4AwAEB AAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A /wIWAB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/ BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGMNgQK/A0YODwAN8HkAAAAAAJ8PBAAAAAQAAAAAAKgP BQAAADgwMi4zAAChDyYAAAAGAAAAAAAWWAAABgAFAAEAWgCQ/wYAAAABAGMAAQAEAAIABAAQAAAA qg8MAAAABgAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8IgBAAAS AArwCAAAABT8CgAACgAA0wEL8K4AAAB/AIAAhACAALzVqwiBAAAAAACCAAAAAACDAAAAAACEAAAA AACFAAIAAACHAAEAAAC/ABAAHwAMAfMDMxA/AQAABgCAAQcAAACBAf9mAACDAf//AACLAQAApv+M AWQAAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BIABgAP8BAADAAb8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAFQtSApMG2wwPAA3wbAAAAAAA nw8EAAAABAAAAAAAoQ8mAAAAAQAAAAAAFlgAAAYABQABAFoAkP8BAAAAAQBjAAEABAACAAQAEAAA AKoPDAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPChAQAA EgAK8AgAAAAV/AoAAAoAAKMBC/CcAAAAfwCAAIQAgAAYBKsIgQAAAAAAggAAAAAAgwAAAAAAhAAA AAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQPwEAAAYAgQH//wAAgwGZ/2YAvwEcAB4AwAEBAAAI ywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8A/wIW AB8AfwMAAA8AkwAi8TYAAAA/AQAAQAC/ASAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYA TgA/BgYATgB/BgYADgAAABDwCAAAABULkwZRENsMDwAN8JcAAAAAAJ8PBAAAAAQAAAAAAKgPCQAA AChybXApIEVWQwAAoQ8mAAAACgAAAAAAFlgAAAYABQABAFoAkP8KAAAAAQBjAAEABAACAAQAEAAA AKoPJgAAAAEAAAAAAAAAAwAAAAEAAAADAAUAAAAAAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAA oAJQAVABoAKgAvAD8ANABUAFDwAE8IgBAAASAArwCAAAABb8CgAACgAA0wEL8K4AAAB/AIAAhACA AHRsqwiBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAEAAAC/ABAAHwAMAfMDMxA/AQAA BgCAAQcAAACBAf//AACDAf9mAACLAQAApv+MAWQAAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAA AgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwD/AhYAHwB/AwAADwCTACLx NgAAAD8BAABAAL8BIABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAO AAAAEPAIAAAAFQtREKAS2wwPAA3wbAAAAAAAnw8EAAAABAAAAAAAoQ8mAAAAAQAAAAAAFlgAAAYA BQABAFoAkP8BAAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4A AKACUAFQAaACoALwA/ADQAVABQ8ABPBJAQAAEgAK8AgAAAAX/AoAAAoAAGMBC/CEAAAAfwCAAIQA gABcTKsIgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwACAAAAvwAQAB8ADAHzAzMQgQEA /wAAvwEcAB4AwAEBAAAIywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAA PwICAAMAvwIBAA8AEwAi8QYAAAC/AQAAYAAAABDwCAAAAGQNWwskED4ODwAN8IcAAAAAAJ8PBAAA AAQAAAAAAKgPAwAAAExTUAAAoQ82AAAABAAAAAAAFlgAAAYABQABAFoAkP8DAAAAAQBDAAEABAAE ABAAAQAAAAEEYwABBAQAAgAEABAAAACqDwwAAAAEAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlAB UAGgAqAC8APwA0AFQAUPAATw2AEAAKIMCvAIAAAAGPwKAAAKAABTAQvwrAAAAIAAJFerCIEAIWUB AIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMB//9mAIZB GgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8B AABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAI AAAAFQt/AnEScAsPAA3wvgAAAAAAnw8EAAAABAAAAAAAoA9GAAAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEMALQBNAEEAQwAgAPPwIABQAEMAQwAtAE0AQQBDAAAAoQ8w AAAAJAAAAAAAAAAAABoAAAABAAIAAQALAAEAAAABAIIAAQADAAsACQAAAAEAAgABAAsAAACqDxQA AAAjAAAABgAAAAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwgwEAABIACvAIAAAAGfwK AAAKAACjAQvwnAAAAH8AgACEAIAAFESrCIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcA AgAAAL8AEAAfAAwB8wMzED8BAAAGAIEBlpaWAIMBM2b/AL8BHAAeAMABAQAACMsBakoAAP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMA IvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYG AA4AAAAQ8AgAAAChDjIO9g+EDw8ADfB5AAAAAACfDwQAAAAEAAAAAACoDwUAAAA4MDIuMwAAoQ8m AAAABgAAAAAAFlgAAAYABQABAFoAkP8GAAAAAQBjAAEABAACAAQAEAAAAKoPDAAAAAYAAAAGAAAA CQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPB9AQAAogwK8AgAAAAa/AoAAAoA AFMBC/CsAAAAgADMV6sIgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYA gAEBAAAAgQEAAAAIgwGZ/2YAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcA bwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUG AE4APwYGAE4AfwYGAA4AAAAQ8AgAAABkDYgL9g+/DQ8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMA AABMU0UAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8UAAAAAwAAAAYAAAAJCAAA AQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H0BAACiDArwCAAAABv8CgAACgAAUwEL8KwAAACA ABhNqwiBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/AQAABgCAAQEAAACBAQAA AAiDAZn/ZgCGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABpAGEAZwBvAG4AYQBsAAAA kwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/ BgYADgAAABDwCAAAAGQNDQnTCr8NDwAN8GMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFRBRwAAoQ8Y AAAABAAAAAAAAAgAAAEABAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAAAAkIAAABAAAAAAAAAAAA pg8IAAAAQAgAAF8DXwMPAATwfQEAAKIMCvAIAAAAHPwKAAAKAABTAQvwrAAAAIAAtBKrCIEAIWUB AIIAAAAAAIMAIWUBAIQAAAAAAIUAAgAAAL8AEAAfAD8BAAAGAIABAQAAAIEBAAAACIMBwMDAAIZB GgAAAIfBLgAAAL8BHAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AEQAYQByAGsAIABkAG8AdwBuAHcAYQByAGQAIABkAGkAYQBnAG8AbgBhAGwAAACTACLxNgAAAD8B AABAAL8BAABgAP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAI AAAAZA2sEEQSvw0PAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAVEFHAAChDxgAAAAEAAAAAAAA CAAAAQAEAAAAAQACAAEACwAAAKoPFAAAAAMAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAA XwNfAw8ABPCBAQAAogwK8AgAAAAd/AoAAAoAAFMBC/CsAAAAgADwMqsIgQAhZQEAggAAAAAAgwAh ZQEAhAAAAAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAA vwEcAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAg AGQAbwB3AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA /wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDl4O9g/8 Dg8ADfBnAAAAAACfDwQAAAAEAAAAAACoDwcAAABMU0UvTUFDAAChDxgAAAAIAAAAAAAACAAAAQAI AAAAAQACAAEACwAAAKoPFAAAAAcAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8A BPCBAQAAogwK8AgAAAAe/AoAAAoAAFMBC/CsAAAAgAC0JKsIgQAhZQEAggAAAAAAgwAhZQEAhAAA AAAAhQACAAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAAvwEcAB4A wAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3 AG4AdwBhAHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMAB vwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDrYLTg38Dg8ADfBn AAAAAACfDwQAAAAEAAAAAACoDwcAAABMU0UvTUFDAAChDxgAAAAIAAAAAAAACAAAAQAIAAAAAQAC AAEACwAAAKoPFAAAAAcAAAAGAAAACQgAAAEAAAAAAAAAAACmDwgAAABACAAAXwNfAw8ABPB9AQAA ogwK8AgAAAAf/AoAAAoAAFMBC/CsAAAAgACYNKsIgQAhZQEAggAAAAAAgwAhZQEAhAAAAAAAhQAC AAAAvwAQAB8APwEAAAYAgAEBAAAAgQEAAAAIgwHAwMAAhkEaAAAAh8EuAAAAvwEcAB4AwAEBAAAI /wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8ARABhAHIAawAgAGQAbwB3AG4AdwBh AHIAZAAgAGQAaQBhAGcAbwBuAGEAbAAAAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCC fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAChDjsJ0wr8Dg8ADfBjAAAAAACf DwQAAAAEAAAAAACoDwMAAABUQUcAAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQALAAAAqg8U AAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAAAKYPCAAAAEAIAABfA18DDwAE8H0BAACiDArwCAAAACD8 CgAACgAAUwEL8KwAAACAACAnqwiBACFlAQCCAAAAAACDACFlAQCEAAAAAACFAAIAAAC/ABAAHwA/ AQAABgCAAQEAAACBAQAAAAiDAcDAwACGQRoAAACHwS4AAAC/ARwAHgDAAQEAAAj/AQYADgABAgIA AAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwBEAGEAcgBrACAAZABvAHcAbgB3AGEAcgBkACAAZABp AGEAZwBvAG4AYQBsAAAAkwAi8TYAAAA/AQAAQAC/AQAAYAD/AQAAwAG/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAGQN7QaFCL8NDwAN8GMAAAAAAJ8PBAAAAAQAAAAA AKgPAwAAAFRBRwAAoQ8YAAAABAAAAAAAAAgAAAEABAAAAAEAAgABAAsAAACqDxQAAAADAAAABgAA AAkIAAABAAAAAAAAAAAApg8IAAAAQAgAAF8DXwMPAATwthMAAKIECvAIAAAAIfwKAAAKAACzAAvw jhMAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACIDDGgAA AIHDMhMAAL8DAgACAEQAdABzAFMAaABhAHAAZQBOAGEAbQBlAAAAQwAwADMANQA3AEMANQBDADEA RwA0AEMANQA3ADkARABAADgAMQAxADQANwBAAEUAQABFADYAOQAzADQANQA5ADAAOAA1AEYANABh ADgANQBGADcANgBMADEAMQA4ADEAMQAxADEAMwAhACEAIQBCAEkASABPAEAAXQBMADEAMQA4ADEA MQAxADEAMwAhACEAIQAhACEAIQAhADEAMQAxADAAQgAzADQAQwA5ADAAQwBHAEcAYwBjACwAYwBg AGIAagBpAGAAdABtACwAYABzAGIAaQBoAHUAZABiAHUAdABzAGQALAAxADEALwBxAHEAdQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhADEAIQAxAAAAAAAQ8AgA AAAAAAAAAQABAA8ABPBeAAAAggUK8AgAAAAi/AoAAAoAAJMAC/A2AAAABAAAAFoAhQACAAAAhwAB AAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABKEZMGUBDSEQ8A BPC/AAAAogwK8AgAAAAj/AoAAAoAAKMAC/A8AAAAgAC0g6sIhQACAAAAhwAGAAAAvwACAAIAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAC4EWkKbAziEg8ADfBTAAAA AACfDwQAAAAEAAAAAACoDwMAAABQVE4AAKEPGAAAAAQAAAAAAAAIAAABAAQAAAABAAIAAQAZAAAA qg8UAAAAAwAAAAYAAAAJCAAAAQAAAAAAAAAPAATwvwAAAKIMCvAIAAAAJPwKAAAKAACjAAvwPAAA AIAAXGGrCIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC AgAACAAAEPAIAAAAcw4BB1gIDQ8PAA3wUwAAAAAAnw8EAAAABAAAAAAAqA8FAAAAQy1UYWcAAKEP FgAAAAYAAAAAAAAAAAAGAAAAAwACAAMACgAAAKoPFAAAAAUAAAAGAAAACQgAAAEAAAAAAAAADwAE 8McAAACiDArwCAAAACX8CgAACgAAowAL8DwAAACAANCdqwiFAAIAAACHAAYAAAC/AAIAAgCBAQQA AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAJ8PaAm/CpkQDwAN8FsAAAAA AJ8PBAAAAAQAAAAAAKgPCwAAAEMtVGFnDVMtVGFnAAChDxgAAAAMAAAAAAAACAAAAQAMAAAAAwAC AAMACgAAAKoPFAAAAAsAAAAGAAAACQgAAAEAAAAAAAAADwAE8MoAAACiDArwCAAAACb8CgAACgAA owAL8DwAAACAAIimqwiFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAgAABDwCAAAAJ8PmwtgDZkQDwAN8F4AAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBX LUxTRQ1MU1AtTFNFAAChDxgAAAAPAAAAAAAACAAAAQAPAAAAAwACAAMACgAAAKoPFAAAAA4AAAAG AAAACQgAAAEAAAAAAAAADwAE8MoAAACiDArwCAAAACf8CgAACgAAowAL8DwAAACAADywqwiFAAIA AACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAA AJoPMQ72D5QQDwAN8F4AAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBXLUxTRQ1MU1AtTFNFAAChDxgA AAAPAAAAAAAACAAAAQAPAAAAAwACAAMACgAAAKoPFAAAAA4AAAAGAAAACQgAAAEAAAAAAAAADwAE 8L8AAACiDArwCAAAACj8CgAACgAAowAL8DwAAACAADTPqwiFAAIAAACHAAYAAAC/AAIAAgCBAQQA AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHMO2hAxEg0PDwAN8FMAAAAA AJ8PBAAAAAQAAAAAAKgPBQAAAEMtVGFnAAChDxYAAAAGAAAAAAAAAAAABgAAAAMAAgADAAoAAACq DxQAAAAFAAAABgAAAAkIAAABAAAAAAAAAA8ABPDyAAAAEgAK8AgAAAAp/AoAIAoAAHMBC/CKAAAA BAAAAAAAfwABAAUAgAC8jpkMgQDyZAEAggB7sgAAgwDyZAEAhAB7sgAAhQAAAAAAhgAAAAAAhwAA AAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEAABEAwAEBAAAI /wEAAAkAAQICAAAIAQMDeAEAiAMAAAAAIwAi8QwAAACMAAEAAACNADBlAQAAABDwCAAAAKQDUAHy GFAJDwAR8BAAAAAAAMMLCAAAAAEAAAAOAKsIDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwyQAAABIA CvAIAAAAKvwKAAAKAACjAAvwPAAAAH8AAAAEAIAAmPGZDIUAAgAAAIcAAQAAAIEBBAAACIMBAAAA CL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAngutAkQS+AsPAA3wXQAAAAAAnw8EAAAA BAAAAAAAqA8NAAAATUVHIChsZXZlbCA3KQAAoQ8YAAAADgAAAAAAAAgAAAEADgAAAAMAAgADAAsA AACqDxQAAAANAAAABgAAAAkIAAABAAAAAAAAAA8ABPDoAAAAEgAK8AgAAAAr/AoAAAoAAKMAC/A8 AAAAfwAAAAQAgACwZK0IhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgA AQICAAAIAAAQ8AgAAAD4C8AGfhBSDA8ADfB8AAAAAACfDwQAAAAEAAAAAACoDywAAAAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTUVHIChsZXZlbCA0KQAAoQ8YAAAALQAAAAAAAAgAAAEA LQAAAAMAAgADAAsAAACqDxQAAAAsAAAABgAAAAkIAAABAAAAAAAAAA8ABPBeAAAAUgAK8AgAAAAs /AoAgAoAAJMAC/A2AAAABAAAAA4BhQACAAAAhwABAAAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAQ8AgAAACdC+kRRBL4Cw8ABPBkAAAAUgQK8AgAAAAt/AoAAAoAAKMAC/A8 AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIAAAQ8AgAAACeC1EQrBD5Cw8ABPBeAAAAUgAK8AgAAAAu/AoAgAoAAJMAC/A2AAAABAAA AA4BhQACAAAAhwABAAAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgA AAD4CyQQfxBTDA8ABPBkAAAAUgQK8AgAAAAv/AoAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAARwHR GwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD5C5wP 9w9UDA8ABPBeAAAAUgAK8AgAAAAw/AoAwAoAAJMAC/A2AAAABAAAAA4BhQACAAAAhwABAAAAgQEA AAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD3C8AGGwdSDA8ABPBkAAAA UgQK8AgAAAAx/AoAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEA AAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD4C1sLtgtTDA8ABPBkAAAAUgQK8AgA AAAy/AoAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQ ABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD4C6YKAQtTDA8ABPBkAAAAUgQK8AgAAAAz/AoA AAoAAKMAC/A8AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEB AAAI/wEIAAgAAQICAAAIAAAQ8AgAAAD4Cw4JaQlTDA8ABPBkAAAAUgQK8AgAAAA0/AoAAAoAAKMA C/A8AAAAhQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEI AAgAAQICAAAIAAAQ8AgAAAD4C1gIswhTDA8ABPBkAAAAUgQK8AgAAAA1/AoAAAoAAKMAC/A8AAAA hQACAAAAhwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQIC AAAIAAAQ8AgAAACeC5MG7gb5Cw8ABPBkAAAAUgQK8AgAAAA2/AoAAAoAAKMAC/A8AAAAhQACAAAA hwABAAAARwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ 8AgAAACeC90FOAb5Cw8ABPBkAAAAUgQK8AgAAAA3/AoAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAA RwHRGwAASAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACe C0YEoQT5Cw8ABPBkAAAAUgQK8AgAAAA4/AoAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAARwHRGwAA SAEJGQAAgQEAAAAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACeC5AD6wP5 Cw8ABPBeAAAAUgAK8AgAAAA5/AoAwAoAAJMAC/A2AAAABAAAAA4BhQACAAAAhwABAAAAgQEAAAAA gwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACeC60CCAP5Cw8ABPBSAAAAQgEK 8AgAAAA6/AoAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIzgEGAAAA/wEYABgA AQICAAAIAAAQ8AgAAADLC60CRBLLCw8ABPBSAAAAQgEK8AgAAAA7/AoAAAoAAHMAC/AqAAAARAEE AAAAfwEAAAEAvwEAABAAwAEBAAAIzgEHAAAA/wEYABgAAQICAAAIAAAQ8AgAAAAmDMAGfxAmDA8A BPBIAAAAEgAK8AgAAAAB/AoAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwEV7aIAlAG2LnoAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkA mcwAAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4I AAAAjrTJAQBUvqwAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAAAAJcM/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAchdEAAAAAQAQAAAA AAAFABAAxkkAACwAEAD2TwAAQAAQAH1BAAACAhAAnlQAAAQCIADEnwAAROgAAAgCMADr0gEAPTEB AP6CAQAAAPUPHAAAALsBAACkGQADAAAAACkkAgABAAAACgIAAAEAxTEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAMRaAAAMAAAA AQAAAGgAAAACAAAAcAAAAAQAAAC4AAAABwAAAMgAAAAIAAAA5AAAAAkAAAD0AAAAEgAAAAABAAAK AAAAIAEAAAwAAAAsAQAADQAAADgBAAAPAAAARAEAABEAAABMAQAAAgAAAOQEAAAeAAAAQAAAAE9w dGljYWwgJiBQYWNrZXQgVHJhbnNwb3J0IE5ldHdvcmtzIGFuZCBMMy9MMi9MMSBJbnRlZ3JhdGlv bgAAAAAeAAAACAAAAFZpc3NlcnMAHgAAABQAAABodWF3ZWktdGVtcGxhdGUtbXYAAB4AAAAIAAAA Vmlzc2VycwAeAAAABAAAADcyNAAeAAAAGAAAAE1pY3Jvc29mdCBQb3dlclBvaW50AAAAAEAAAAAA DGEKUwgAAEAAAACgvk1yTs3IAUAAAADQSTGcC8TJAQMAAABaAwAARwAAAHBZAAD/////AwAAAAgA iRBnDAAAAQAJAAADrywAAAcAPQAAAAAABAAAAAMBCAAFAAAACwIAAAAABQAAAAwCeQChAAMAAAAe AAcAAAD8AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAAAAAD///8ABAAAAC0BAQAOAAAAJAMFAP// /////3gAoAB4AKAA////////CAAAAPoCAAAAAAAAAAAAAAQAAAAtAQIABwAAAPwCAAD///8AAAAE AAAALQEDAAQAAAAnAf//BAAAAPABAAADAAAAHgAHAAAA/AIAAOvr6wAAAAQAAAAtAQAABAAAAC0B AQAOAAAAJAMFAFAAUABQAGUAVwBlAFcAUABQAFAABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAA APwCAACFhYUAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQBRAFAAUQBmAFcAZgBXAFAAUQBQAAQA AAAtAQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAA3d3dAAAABAAAAC0BAAAEAAAALQEBAA4AAAAk AwUAUQBQAFEAZgBXAGYAVwBQAFEAUAAEAAAALQECAAQAAAAtAQMABAAAACcB//8cAAAA+wL+/wAA AAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAA AC4BGAAEAAAAAgEBAAUAAAAJAgAAAAINAAAAMgplAFIABAAAAENvcmUBAAEAAQABAAQAAAAuAQAA HAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAAAAAAAAAAAAABgAAAACAAAAmDkVAOQEAAAE AAAALQEFAAQAAADwAQQAHAAAAPsC+f8AAAAAAAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQKZAAACKAAAADIKCgAH ABYAAABXaG9sZXNhbGUgRVZDIE9wdGlvbiBJBwAEAAQAAgAEAAQABAACAAQAAQAFAAUABAACAAUA BAACAAIABAAEAAIAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL7/wAAAAAAALwCAAAA AABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAA AgEBAAUAAAAJAgAAAAI6AAAAMgodAAcAIgAAAFNlcnZpY2UgRWRnZSByb3V0ZXIgY29ubmVjdHMg dmlhIEUDAAMAAgADAAEAAwADAAEAAwADAAMAAwABAAIAAwADAAIAAwACAAEAAwADAAMAAwACAAMA AgADAAEAAwABAAMAAQADAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Avv/AAAAAAAAvAIA AAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQA AAACAQEABQAAAAkCAAAAAgkAAAAyCh0AWQABAAAALXECAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEE ABwAAAD7Avv/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAi4AAAAyCh0AWwAaAAAAVHJlZSBzZXJ2 aWNlIHdpdGggZS5nLiAyMCADAAEAAwADAAEAAwADAAIAAwABAAIAAwABAAQAAQACAAMAAQADAAEA AwABAAEAAwADAAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC+/8AAAAAAAC8AgAAAAAA QAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIB AQAFAAAACQIAAAACDQAAADIKIgAHAAQAAABBVE0gBAADAAQAAQAEAAAALgEAAAQAAAAtAQUABAAA APABBAAcAAAA+wL7/wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIQAAAAMgoiABMABgAAAERTTEFN cwQAAwADAAQABAADAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Avv/AAAAAAAAvAIAAAAA AEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAAC AQEABQAAAAkCAAAAAiIAAAAyCiIAKQASAAAAbG9jYXRlZCBpbiBvZmZpY2VzAQADAAMAAwABAAMA AwABAAEAAwABAAMAAgACAAEAAwADAAMABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/P8A AAAAAACQAQAAAAIAQAACV2luZ2RpbmdzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQA AAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIKKAAOAAEAAABxcQQABAAAAC4BAAAEAAAALQEF AAQAAADwAQQAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACEAAAADIKKAAUAAYAAABS b290ZWQDAAIAAgABAAMAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL8/wAAAAAAAJAB AAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAE AAAAAgEBAAUAAAAJAgAAAAIJAAAAMgooACEAAQAAAC1xAgAEAAAALgEAAAQAAAAtAQUABAAAAPAB BAAcAAAA+wL8/wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAI9AAAAMgooACMAJAAAAG1wIEVWQyBz dGFydHMgaW4gcm91dGVyIGFuZCBlbmRzIGluIAMAAgABAAMAAwADAAEAAwABAAIAAgABAAIAAQAB AAMAAQABAAMAAgABAAMAAQABAAMAAgACAAIAAgACAAMAAgABAAEAAgABAAQAAAAuAQAABAAAAC0B BQAEAAAA8AEEABwAAAD7Avz/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhAAAAAyCigAZwAGAAAA RFNMQU1zAwAEAAIAAwADAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/P8AAAAAAACQ AQAAAAIAQAACV2luZ2RpbmdzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgA BAAAAAIBAQAFAAAACQIAAAACCQAAADIKLgAOAAEAAABxcQQABAAAAC4BAAAEAAAALQEFAAQAAADw AQQAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACLQAAADIKLgAUABkAAABQVE4gYW5k IElTUCBzaGFyZSB0aGUgRVZDIAMAAgADAAEAAwACAAIAAQABAAMAAwABAAMAAgACAAIAAgABAAIA AgACAAEAAwADAAMABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/P8AAAAAAACQAQAAAAIA QAACV2luZ2RpbmdzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIB AQAFAAAACQIAAAACCQAAADIKNAAOAAEAAABxcQQABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAA APsC/P8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACNgAAADIKNAAUAB8AAABGZXcgKGUuZy4gMjEp IE1BQyBhZGRyZXNzZXMgaW4gAAIAAgADAAIAAQACAAIAAgABAAEAAwACAAEAAgADAAMAAwACAAIA AgADAAEAAgACAAMAAgACAAEAAQADAAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/P8A AAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQA AAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKNABSAAMAAABybXAIAgADAAIABAAAAC4BAAAE AAAALQEFAAQAAADwAQQAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKNABa AAMAAABFVkMIAwADAAMABAAAAC4BAAAEAAAALQEFAAQAAADwAQQABAAAAPABAAADAAAAHgAHAAAA /AIAAOvr6wAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFAG8AOwBvAGcAdQBnAHUAOwBvADsABAAA AC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAACFhYUAAAAEAAAALQEAAAQAAAAtAQEADgAAACQD BQBvADwAbwBnAHYAZwB2ADwAbwA8AAQAAAAtAQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAA3d3d AAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAbwA8AG8AZwB1AGcAdQA8AG8APAAEAAAALQECAAQA AAAtAQMABAAAACcB//8cAAAA+wL+/wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAISAAAAMgphAG4A BwAAAFNlcnZpY2UIAQABAAEAAQABAAEAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+ /wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQA BAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAINAAAAMgpkAHAABAAAAEVkZ2UBAAEAAQABAAQAAAAu AQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhAAAAAy CmcAbwAGAAAAUm91dGVyAQABAAEAAQABAAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQABAAAAPAB AAADAAAAHgAHAAAA/AIAAOvr6wAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFACMAOwAjAGUAKgBl ACoAOwAjADsABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAACFhYUAAAAEAAAALQEAAAQA AAAtAQEADgAAACQDBQAkADwAJABmACoAZgAqADwAJAA8AAQAAAAtAQIABAAAAC0BAwAEAAAA8AEA AAcAAAD8AgAA3d3dAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAIwA8ACMAZgAqAGYAKgA8ACMA PAAEAAAALQECAAQAAAAtAQMABAAAACcB//8cAAAA+wL+/wAAAAAAALwCAAAAAABAACJBcmlhbAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAA AAIMAAAAMgpjACUAAwAAAEFUTQgBAAEAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+ /wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQA BAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIPAAAAMgplACIABQAAAERTTEFNcgEAAQACAAEAAgAE AAAALgEAAAQAAAAtAQUABAAAAPABBAAEAAAA8AEAAAMAAAAeAAcAAAD8AgAA6+vrAAAABAAAAC0B AAAEAAAALQEBAA4AAAAkAwUAYABGAGAAZQBmAGUAZgBGAGAARgAEAAAALQECAAQAAAAtAQMABAAA APABAAAHAAAA/AIAAIWFhQAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFAGAARwBgAGYAZgBmAGYA RwBgAEcABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAADd3d0AAAAEAAAALQEAAAQAAAAt AQEADgAAACQDBQBgAEYAYABmAGYAZgBmAEYAYABGAAQAAAAtAQIABAAAAC0BAwAEAAAAJwH//xwA AAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA AC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAyCmAAYAAFAAAAV2hvbGVyAgABAAEA AQABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAg0AAAAyCmMAYQAEAAAAc2FsZQEAAQABAAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAA APsC/v8AAAAAAAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACEAAAADIKZQBfAAYAAABBY2Nlc3MBAAEAAQAB AAIAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAEAAAA8AEAAAMAAAAeAAcAAAD8AgAA6+vrAAAA BAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAQABGAEAAZQBHAGUARwBGAEAARgAEAAAALQECAAQAAAAt AQMABAAAAPABAAAHAAAA/AIAAIWFhQAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFAEEARwBBAGYA RwBmAEcARwBBAEcABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAADd3d0AAAAEAAAALQEA AAQAAAAtAQEADgAAACQDBQBAAEYAQABmAEcAZgBHAEYAQABGAAQAAAAtAQIABAAAAC0BAwAEAAAA JwH//xwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAyCmMAQQAFAAAATWV0cm9z AgABAAEAAQABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIAAAAAAEAA IkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEA BQAAAAkCAAAAAg0AAAAyCmUAQgAEAAAAQ29yZQEAAQABAAEABAAAAC4BAAAEAAAALQEFAAQAAADw AQQABAAAAPABAAADAAAAHgAHAAAA/AIAAOvr6wAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFADIA RgAyAGUAOQBlADkARgAyAEYABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAACFhYUAAAAE AAAALQEAAAQAAAAtAQEADgAAACQDBQAzAEcAMwBmADkAZgA5AEcAMwBHAAQAAAAtAQIABAAAAC0B AwAEAAAA8AEAAAcAAAD8AgAA3d3dAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAMgBGADIAZgA5 AGYAOQBGADIARgAEAAAALQECAAQAAAAtAQMABAAAACcB//8cAAAA+wL+/wAAAAAAALwCAAAAAABA ACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEB AAUAAAAJAgAAAAIPAAAAMgpjADMABQAAAE1ldHJvcwIAAQABAAEAAQAEAAAALgEAAAQAAAAtAQUA BAAAAPABBAAcAAAA+wL+/wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAINAAAAMgplADQABAAAAEVk Z2UBAAEAAQABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEAAQAAADwAQAAAwAAAB4ABwAAAPwCAADr 6+sAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQAVADsAFQBlABwAZQAcADsAFQA7AAQAAAAtAQIA BAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAAhYWFAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAFQA8 ABUAZgAcAGYAHAA8ABUAPAAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAN3d3QAAAAQA AAAtAQAABAAAAC0BAQAOAAAAJAMFABUAPAAVAGYAHABmABwAPAAVADwABAAAAC0BAgAEAAAALQED AAQAAAAnAf//HAAAAPsC/v8AAAAAAAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDQAAADIKYAAWAAQAAABI T01FAQACAAIAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAAAAAAALwCAAAAAABA ACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEB AAUAAAAJAgAAAAINAAAAMgpjABYABAAAAEdXQVkCAAIAAQABAAQAAAAuAQAABAAAAC0BBQAEAAAA 8AEEABwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgkAAAAyCmUAGQABAAAASXEBAAQA AAAuAQAABAAAAC0BBQAEAAAA8AEEAAQAAADwAQAAAwAAAB4ABwAAAPwCAADr6+sAAAAEAAAALQEA AAQAAAAtAQEADgAAACQDBQAKADsACgBlABEAZQARADsACgA7AAQAAAAtAQIABAAAAC0BAwAEAAAA 8AEAAAcAAAD8AgAAhYWFAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUACwA8AAsAZgARAGYAEQA8 AAsAPAAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAN3d3QAAAAQAAAAtAQAABAAAAC0B AQAOAAAAJAMFAAoAPAAKAGYAEQBmABEAPAAKADwABAAAAC0BAgAEAAAALQEDAAQAAAAnAf//HAAA APsC/v8AAAAAAAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDwAAADIKYAAJAAUAAABQSE9ORXMBAAEAAgAC AAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/v8AAAAAAAC8AgAAAAAAQAAiQXJpYWwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIA AAACDAAAADIKYwAMAAMAAABTVEIIAQABAAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC /v8AAAAAAAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEE AAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACCgAAADIKZQANAAIAAABQQwEAAQAEAAAALgEAAAQA AAAtAQUABAAAAPABBAAEAAAA8AEAAAMAAAAeAAcAAAD8AgAA/+BmAAAABAAAAC0BAAAEAAAALQEB AA4AAAAkAwUADAA+AAwAQwCGAEMAhgA+AAwAPgAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA /AIAAJl6AAAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFAA0APgANAEMAhwBDAIcAPgANAD4ABAAA AC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAAD/zAAAAAAEAAAALQEAAAQAAAAtAQEADgAAACQD BQANAD4ADQBDAIcAQwCHAD4ADQA+AAQAAAAtAQIABAAAAC0BAwAEAAAAJwH//xwAAAD7Av3/AAAA AAAAvAIAAAAAAEAAIlRyZWJ1Y2hldCBNUwAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAA LgEYAAQAAAACAQEABQAAAAkCAAAAAgoAAAAyCkAASQACAAAASVABAAIABAAAAC4BAAAEAAAALQEF AAQAAADwAQQAAwAAAB4ALQAAAEIBBQAAACgAAAAIAAAACAAAAAEAAQAAAAAAIAAAAAAAAAAAAAAA AAAAAAAAAAAAzP8A////AJkAAAAzAAAAZgAAAMwAAACZAAAAMwAAAGYAAADMAAAABAAAAC0BBAAE AAAALQEBAA4AAAAkAwUAGQBBABkAQwBxAEMAcQBBABkAQQAEAAAALQECAAQAAAAtAQMABAAAAPAB BAAEAAAAJwH//xwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAyCkQAHgAFAAAA UFBQb0FzAQABAAEAAgABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIA AAACAEAAAldpbmdkaW5ncwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQA AAACAQEABQAAAAkCAAAAAgkAAAAyCkQAJQABAAAA83EDAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEE ABwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAyCkQAKgAFAAAAUFBQb0VzAQAB AAEAAQABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEAAQAAADwAQAAAwAAAB4ABwAAAPwCAADAwMAA AAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQBkAFEAZABWAHAAVgBwAFEAZABRAAQAAAAtAQIABAAA AC0BAwAEAAAA8AEAAAcAAAD8AgAAWlpaAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAZABRAGQA VgBwAFYAcABRAGQAUQAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAJaWlgAAAAQAAAAt AQAABAAAAC0BAQAOAAAAJAMFAGQAUQBkAFYAcABWAHAAUQBkAFEABAAAAC0BAgAEAAAALQEDAAQA AAAnAf//HAAAAPsC/f8AAAAAAAC8AgAAAAAAQAAiVHJlYnVjaGV0IE1TAAAAAAAAAAAAAAAAAAAA AAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDwAAADIKVgBmAAUAAAA4MDIu M3MCAAIAAgABAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQQABAAAAPABAAADAAAAHgAHAAAA/AIA AGb/ZgAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFADYAUQA2AFYAQgBWAEIAUQA2AFEABAAAAC0B AgAEAAAALQEDAAQAAADwAQAABwAAAPwCAAAAmQAAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQA3 AFEANwBXAEMAVwBDAFEANwBRAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAAAP8AAAAA BAAAAC0BAAAEAAAALQEBAA4AAAAkAwUANgBRADYAVwBCAFcAQgBRADYAUQAEAAAALQECAAQAAAAt AQMABAAAACcB//8cAAAA+wL9/wAAAAAAALwCAAAAAABAACJUcmVidWNoZXQgTVMAAAAAAAAAAAAA AAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIMAAAAMgpWADkAAwAA AEVWUAgCAAIAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAEAAAA8AEAAAMAAAAeAAcAAAD8AgAA wMDAAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAKQBRACkAVgAzAFYAMwBRACkAUQAEAAAALQEC AAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAFpaWgAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFACkA UQApAFcANABXADQAUQApAFEABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAACWlpYAAAAE AAAALQEAAAQAAAAtAQEADgAAACQDBQApAFEAKQBWADMAVgAzAFEAKQBRAAQAAAAtAQIABAAAAC0B AwAEAAAAJwH//xwAAAD7Av3/AAAAAAAAvAIAAAAAAEAAIlRyZWJ1Y2hldCBNUwAAAAAAAAAAAAAA AAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAyClYAKgAFAAAA ODAyLjNzAgACAAIAAQACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEAAQAAADwAQAAAwAAAB4ABwAA APwCAADAwMAAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQA4AFkAOABeAEEAXgBBAFkAOABZAAQA AAAtAQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAAWlpaAAAABAAAAC0BAAAEAAAALQEBAA4AAAAk AwUAOABZADgAXwBCAF8AQgBZADgAWQAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAJaW lgAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFADgAWQA4AF4AQgBeAEIAWQA4AFkABAAAAC0BAgAE AAAALQEDAAQAAAAnAf//HAAAAPsC/f8AAAAAAAC8AgAAAAAAQAAiVHJlYnVjaGV0IE1TAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDwAAADIKXgA5 AAUAAAA4MDIuM3MCAAIAAgABAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQQABAAAAPABAAADAAAA HgAHAAAA/AIAAMDAwAAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFABoAUQAaAFYAJABWACQAUQAa AFEABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAABaWloAAAAEAAAALQEAAAQAAAAtAQEA DgAAACQDBQAbAFEAGwBXACUAVwAlAFEAGwBRAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8 AgAAlpaWAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAGwBRABsAVgAkAFYAJABRABsAUQAEAAAA LQECAAQAAAAtAQMABAAAACcB//8cAAAA+wL9/wAAAAAAALwCAAAAAABAACJUcmVidWNoZXQgTVMA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIMAAAA MgpWAB0AAwAAAERTTAgCAAIAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAEAAAA8AEAAAMAAAAe AAcAAAD8AgAAwMDAAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUADwBHAA8ASwAWAEsAFgBHAA8A RwAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAFpaWgAAAAQAAAAtAQAABAAAAC0BAQAO AAAAJAMFAA8ASAAPAEwAFwBMABcASAAPAEgABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwC AACWlpYAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQAPAEcADwBMABYATAAWAEcADwBHAAQAAAAt AQIABAAAAC0BAwAEAAAAJwH//xwAAAD7Av3/AAAAAAAAvAIAAAAAAEAAIlRyZWJ1Y2hldCBNUwAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAy CkoADwAFAAAAODAyLjNzAgACAAIAAAACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEAAQAAADwAQAA AwAAAB4ABwAAAPwCAAD/o2YAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQAmAEcAJgBNADUATQA1 AEcAJgBHAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAAmT0AAAAABAAAAC0BAAAEAAAA LQEBAA4AAAAkAwUAJwBIACcATQA2AE0ANgBIACcASAAEAAAALQECAAQAAAAtAQMABAAAAC0BAQAH AAAA/AIAAP9mAAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFACYARwAmAE0AJwBNACcARwAmAEcA BAAAAC0BAQAEAAAALQEDAAQAAADwAQQABwAAAPwCAAD/bAAAAAAEAAAALQEEAAQAAAAtAQEADgAA ACQDBQAnAEcAJwBNACgATQAoAEcAJwBHAAQAAAAtAQEABAAAAC0BAwAEAAAA8AEEAAcAAAD8AgAA /3QAAAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAKABHACgATQApAE0AKQBHACgARwAEAAAALQEB AAQAAAAtAQMABAAAAPABBAAHAAAA/AIAAP9/AAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFACkA RwApAE0AKgBNACoARwApAEcABAAAAC0BAQAEAAAALQEDAAQAAADwAQQABwAAAPwCAAD/jgAAAAAE AAAALQEEAAQAAAAtAQEADgAAACQDBQAqAEcAKgBNACsATQArAEcAKgBHAAQAAAAtAQEABAAAAC0B AwAEAAAA8AEEAAcAAAD8AgAA/50AAAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAKwBHACsATQAs AE0ALABHACsARwAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAHAAAA/AIAAP+tAAAAAAQAAAAtAQQA BAAAAC0BAQAOAAAAJAMFACwARwAsAE0ALQBNAC0ARwAsAEcABAAAAC0BAQAEAAAALQEDAAQAAADw AQQABwAAAPwCAAD/vQAAAAAEAAAALQEEAAQAAAAtAQEADgAAACQDBQAtAEcALQBNAC4ATQAuAEcA LQBHAAQAAAAtAQEABAAAAC0BAwAEAAAA8AEEAAcAAAD8AgAA/8wAAAAABAAAAC0BBAAEAAAALQEB AA4AAAAkAwUALgBHAC4ATQAvAE0ALwBHAC4ARwAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAHAAAA /AIAAP/aAAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFAC8ARwAvAE0AMABNADAARwAvAEcABAAA AC0BAQAEAAAALQEDAAQAAADwAQQABwAAAPwCAAD/5QAAAAAEAAAALQEEAAQAAAAtAQEADgAAACQD BQAwAEcAMABNADEATQAxAEcAMABHAAQAAAAtAQEABAAAAC0BAwAEAAAA8AEEAAcAAAD8AgAA/+0A AAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAMQBHADEATQAyAE0AMgBHADEARwAEAAAALQEBAAQA AAAtAQMABAAAAPABBAAHAAAA/AIAAP/0AAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFADIARwAy AE0AMwBNADMARwAyAEcABAAAAC0BAQAEAAAALQEDAAQAAADwAQQABwAAAPwCAAD/+QAAAAAEAAAA LQEEAAQAAAAtAQEADgAAACQDBQAzAEcAMwBNADQATQA0AEcAMwBHAAQAAAAtAQEABAAAAC0BAwAE AAAA8AEEAAcAAAD8AgAA//0AAAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUANABHADQATQA1AE0A NQBHADQARwAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAHAAAA/AIAAP//AAAAAAQAAAAtAQQABAAA AC0BAQAOAAAAJAMFADUARwA1AE0ANgBNADYARwA1AEcABAAAAC0BAQAEAAAALQEDAAQAAADwAQQA BAAAAC0BAgAEAAAAJwH//wQAAADwAQAAAwAAAB4ABwAAAPwCAAD//2YAAAAEAAAALQEAAAQAAAAt AQEADgAAACQDBQA1AEcANQBNAGMATQBjAEcANQBHAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEAAAcA AAD8AgAAmZkAAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUANgBIADYATQBjAE0AYwBIADYASAAE AAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAP//AAAAAAQAAAAtAQAABAAAAC0BAQAOAAAA JAMFADYARwA2AE0AYwBNAGMARwA2AEcABAAAAC0BAgAEAAAALQEDAAQAAAAnAf//HAAAAPsC/f8A AAAAAAC8AgAAAAAAQAAiVHJlYnVjaGV0IE1TAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQA AAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIKTABFAAEAAAAocQEABAAAAC4BAAAEAAAALQEF AAQAAADwAQQAHAAAAPsC/f8AAAAAAAC8AgAAAAAAQAAiVHJlYnVjaGV0IE1TAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKTABGAAMAAABy bXAIAQADAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/f8AAAAAAAC8AgAAAAAAQAAi VHJlYnVjaGV0IE1TAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAF AAAACQIAAAACDwAAADIKTABMAAUAAAApIEVWQ3MBAAEAAgACAAIABAAAAC4BAAAEAAAALQEFAAQA AADwAQQABAAAAPABAAADAAAAHgAHAAAA/AIAAP//ZgAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMF AGMARwBjAE0AcQBNAHEARwBjAEcABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAACZmQAA AAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQBjAEgAYwBNAHEATQBxAEgAYwBIAAQAAAAtAQIABAAA AC0BAwAEAAAALQEBAAcAAAD8AgAA//4AAAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAYgBHAGIA TQBkAE0AZABHAGIARwAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAHAAAA/AIAAP/7AAAAAAQAAAAt AQQABAAAAC0BAQAOAAAAJAMFAGQARwBkAE0AZQBNAGUARwBkAEcABAAAAC0BAQAEAAAALQEDAAQA AADwAQQABwAAAPwCAAD/9gAAAAAEAAAALQEEAAQAAAAtAQEADgAAACQDBQBlAEcAZQBNAGYATQBm AEcAZQBHAAQAAAAtAQEABAAAAC0BAwAEAAAA8AEEAAcAAAD8AgAA/+8AAAAABAAAAC0BBAAEAAAA LQEBAA4AAAAkAwUAZgBHAGYATQBnAE0AZwBHAGYARwAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAH AAAA/AIAAP/mAAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFAGcARwBnAE0AaABNAGgARwBnAEcA BAAAAC0BAQAEAAAALQEDAAQAAADwAQQABwAAAPwCAAD/2wAAAAAEAAAALQEEAAQAAAAtAQEADgAA ACQDBQBoAEcAaABNAGkATQBpAEcAaABHAAQAAAAtAQEABAAAAC0BAwAEAAAA8AEEAAcAAAD8AgAA /8wAAAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAaQBHAGkATQBqAE0AagBHAGkARwAEAAAALQEB AAQAAAAtAQMABAAAAPABBAAHAAAA/AIAAP+8AAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFAGoA RwBqAE0AawBNAGsARwBqAEcABAAAAC0BAQAEAAAALQEDAAQAAADwAQQABwAAAPwCAAD/qwAAAAAE AAAALQEEAAQAAAAtAQEADgAAACQDBQBrAEcAawBNAGwATQBsAEcAawBHAAQAAAAtAQEABAAAAC0B AwAEAAAA8AEEAAcAAAD8AgAA/5oAAAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAbABHAGwATQBt AE0AbQBHAGwARwAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAHAAAA/AIAAP+KAAAAAAQAAAAtAQQA BAAAAC0BAQAOAAAAJAMFAG0ARwBtAE0AbgBNAG4ARwBtAEcABAAAAC0BAQAEAAAALQEDAAQAAADw AQQABwAAAPwCAAD/ewAAAAAEAAAALQEEAAQAAAAtAQEADgAAACQDBQBuAEcAbgBNAG8ATQBvAEcA bgBHAAQAAAAtAQEABAAAAC0BAwAEAAAA8AEEAAcAAAD8AgAA/3EAAAAABAAAAC0BBAAEAAAALQEB AA4AAAAkAwUAbwBHAG8ATQBwAE0AcABHAG8ARwAEAAAALQEBAAQAAAAtAQMABAAAAPABBAAHAAAA /AIAAP9pAAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFAHAARwBwAE0AcQBNAHEARwBwAEcABAAA AC0BAQAEAAAALQEDAAQAAADwAQQABAAAAC0BAgAEAAAAJwH//wQAAADwAQAAAwAAAB4ABwAAAPwC AADg4GYAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQAZAEcAGQBNACUATQAlAEcAGQBHAAQAAAAt AQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAAenoAAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUA GgBIABoATQAmAE0AJgBIABoASAAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAMzMAAAA AAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFABoARwAaAE0AJQBNACUARwAaAEcABAAAAC0BAgAEAAAA LQEDAAQAAAAnAf//HAAAAPsC/f8AAAAAAAC8AgAAAAAAQAAiVHJlYnVjaGV0IE1TAAAAAAAAAAAA AAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACEAAAADIKTAAbAAYA AABBVE0gVkMCAAIAAgABAAIAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBAADAAAAHgAtAAAAQgEF AAAAKAAAAAgAAAAIAAAAAQABAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAGb//wD///8AmQAAADMA AABmAAAAzAAAAJkAAAAzAAAAZgAAAMwAAAAEAAAALQEEAAQAAAAtAQEADgAAACQDBQAoAEcAKABK AHAASgBwAEcAKABHAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEEAAQAAAAnAf//HAAAAPsC/v8AAAAA AAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAu ARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKSgBKAAMAAABNQUMIAgABAAEABAAAAC4BAAAEAAAA LQEFAAQAAADwAQQAAwAAAB4ALQAAAEIBBQAAACgAAAAIAAAACAAAAAEAAQAAAAAAIAAAAAAAAAAA AAAAAAAAAAAAAABm/5kA////AJkAAAAzAAAAZgAAAMwAAACZAAAAMwAAAGYAAADMAAAABAAAAC0B BAAEAAAALQEBAA4AAAAkAwUANwBRADcAUwBCAFMAQgBRADcAUQAEAAAALQECAAQAAAAtAQMABAAA APABBAAEAAAAJwH//xwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgwAAAAyClQAOQAD AAAAVEFHCAEAAQACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEAAMAAAAeAC0AAABCAQUAAAAoAAAA CAAAAAgAAAABAAEAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAAP///wCZAAAAMwAAAGYAAADM AAAAmQAAADMAAABmAAAAzAAAAAQAAAAtAQQABAAAAC0BAQAOAAAAJAMFAGUAUQBlAFMAbwBTAG8A UQBlAFEABAAAAC0BAgAEAAAALQEDAAQAAADwAQQABAAAACcB//8cAAAA+wL+/wAAAAAAALwCAAAA AABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAA AgEBAAUAAAAJAgAAAAIMAAAAMgpUAGcAAwAAAFRBRwgBAAEAAgAEAAAALgEAAAQAAAAtAQUABAAA APABBAADAAAAHgAtAAAAQgEFAAAAKAAAAAgAAAAIAAAAAQABAAAAAAAgAAAAAAAAAAAAAAAAAAAA AAAAAMDAwAD///8AmQAAADMAAABmAAAAzAAAAJkAAAAzAAAAZgAAAMwAAAAEAAAALQEEAAQAAAAt AQEADgAAACQDBQA4AFkAOABbAEIAWwBCAFkAOABZAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEEAAQA AAAnAf//HAAAAPsC/v8AAAAAAAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKXAA6AAMAAABUQUcI AQABAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAAwAAAB4ALQAAAEIBBQAAACgAAAAIAAAACAAA AAEAAQAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAADAwMAA////AJkAAAAzAAAAZgAAAMwAAACZAAAA MwAAAGYAAADMAAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAKgBRACoAUwAzAFMAMwBRACoAUQAE AAAALQECAAQAAAAtAQMABAAAAPABBAAEAAAAJwH//xwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFy aWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAA AAkCAAAAAgwAAAAyClQALAADAAAAVEFHCAEAAQACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEAAMA AAAeAC0AAABCAQUAAAAoAAAACAAAAAgAAAABAAEAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAJnM AP///wCZAAAAMwAAAGYAAADMAAAAmQAAADMAAABmAAAAzAAAAAQAAAAtAQQABAAAAC0BAQAOAAAA JAMFABsARwAbAEoAJABKACQARwAbAEcABAAAAC0BAgAEAAAALQEDAAQAAADwAQQABAAAACcB//8c AAAA+wL+/wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIMAAAAMgpKAB0AAwAAAFZDSQgBAAEAAQAE AAAALgEAAAQAAAAtAQUABAAAAPABBAADAAAAHgAIAAAA+gIAAAEAAAAAAAAABAAAAC0BBAAHAAAA /AIBAAAAAAAAAAQAAAAtAQYAKgAAACUDEwBjAGkAYwBqAGIAagBgAGoAXgBrAEoAawBIAGsARwBr AEYAbABFAGwARQBsAEQAawBCAGsAQABrAC0AawArAGoAKQBqACgAagAoAGkABAAAAC0BAgAEAAAA LQEDAAQAAADwAQQABAAAACcB//8cAAAA+wL7/wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIMAAAA MgpxAEAAAwAAAFBUTggDAAMABAAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAEAAAA8AEAAAMAAAAe AAcAAAD8AgAAwMDAAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUARgBZAEYAXgBSAF4AUgBZAEYA WQAEAAAALQECAAQAAAAtAQMABAAAAPABAAAHAAAA/AIAAFpaWgAAAAQAAAAtAQAABAAAAC0BAQAO AAAAJAMFAEYAWQBGAF4AUgBeAFIAWQBGAFkABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwC AACWlpYAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQBGAFkARgBeAFIAXgBSAFkARgBZAAQAAAAt AQIABAAAAC0BAwAEAAAAJwH//xwAAAD7Av3/AAAAAAAAvAIAAAAAAEAAIlRyZWJ1Y2hldCBNUwAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAy Cl4ASAAFAAAAODAyLjNDAgACAAIAAQACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEAAQAAADwAQAA AwAAAB4ABwAAAPwCAABm/2YAAAAEAAAALQEAAAQAAAAtAQEADgAAACQDBQBFAFEARQBWAGIAVgBi AFEARQBRAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEAAAcAAAD8AgAAAJkAAAAABAAAAC0BAAAEAAAA LQEBAA4AAAAkAwUARQBRAEUAVwBiAFcAYgBRAEUAUQAEAAAALQECAAQAAAAtAQMABAAAAPABAAAH AAAA/AIAAAD/AAAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFAEUAUQBFAFYAYgBWAGIAUQBFAFEA BAAAAC0BAgAEAAAALQEDAAQAAAAnAf//HAAAAPsC/f8AAAAAAAC8AgAAAAAAQAAiVHJlYnVjaGV0 IE1TAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAAC DAAAADIKVgBRAAMAAABMU1AIAgACAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQQABAAAAPABAAAD AAAAHgAHAAAA/AIAAMDAwAAAAAQAAAAtAQAABAAAAC0BAQAOAAAAJAMFAFYAWQBWAF4AYQBeAGEA WQBWAFkABAAAAC0BAgAEAAAALQEDAAQAAADwAQAABwAAAPwCAABaWloAAAAEAAAALQEAAAQAAAAt AQEADgAAACQDBQBWAFkAVgBeAGEAXgBhAFkAVgBZAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEAAAcA AAD8AgAAlpaWAAAABAAAAC0BAAAEAAAALQEBAA4AAAAkAwUAVgBZAFYAXgBhAF4AYQBZAFYAWQAE AAAALQECAAQAAAAtAQMABAAAACcB//8cAAAA+wL9/wAAAAAAALwCAAAAAABAACJUcmVidWNoZXQg TVMAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIP AAAAMgpeAFgABQAAADgwMi4zQwIAAgACAAEAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBAADAAAA HgAtAAAAQgEFAAAAKAAAAAgAAAAIAAAAAQABAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAGb/mQD/ //8AmQAAADMAAABmAAAAzAAAAJkAAAAzAAAAZgAAAMwAAAAEAAAALQEEAAQAAAAtAQEADgAAACQD BQBGAFEARgBTAGEAUwBhAFEARgBRAAQAAAAtAQIABAAAAC0BAwAEAAAA8AEEAAQAAAAnAf//HAAA APsC/v8AAAAAAAC8AgAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKVABSAAMAAABMU0UIAQABAAEABAAA AC4BAAAEAAAALQEFAAQAAADwAQQAAwAAAB4ALQAAAEIBBQAAACgAAAAIAAAACAAAAAEAAQAAAAAA IAAAAAAAAAAAAAAAAAAAAAAAAADAwMAA////AJkAAAAzAAAAZgAAAMwAAACZAAAAMwAAAGYAAADM AAAABAAAAC0BBAAEAAAALQEBAA4AAAAkAwUAVwBZAFcAWwBhAFsAYQBZAFcAWQAEAAAALQECAAQA AAAtAQMABAAAAPABBAAEAAAAJwH//xwAAAD7Av7/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhIA AAAyClwAVwAHAAAATFNFL01BQwgBAAEAAQABAAIAAgABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEE AAMAAAAeAC0AAABCAQUAAAAoAAAACAAAAAgAAAABAAEAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAA wMDAAP///wCZAAAAMwAAAGYAAADMAAAAmQAAADMAAABmAAAAzAAAAAQAAAAtAQQABAAAAC0BAQAO AAAAJAMFAEcAWQBHAFsAUQBbAFEAWQBHAFkABAAAAC0BAgAEAAAALQEDAAQAAADwAQQABAAAACcB //8cAAAA+wL+/wAAAAAAALwCAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAISAAAAMgpcAEcABwAAAExTRS9NQUMI AQABAAEAAQACAAIAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAAAAAAALwCAQAA AABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAA AgEBAAUAAAAJAgAAAAIJAAAAMgpbACwAAQAAAENxAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAc AAAA+wL+/wAAAAAAALwCAQAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpbAC0AAQAAAC1xAQAEAAAALgEA AAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAAAAAAALwCAQAAAABAACJBcmlhbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIMAAAAMgpb AC4AAwAAAFRhZwgBAAEAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAAAAAAALwC AQAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAE AAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpiADoAAQAAAENxAQAEAAAALgEAAAQAAAAtAQUABAAAAPAB BAAcAAAA+wL+/wAAAAAAALwCAQAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpiADsAAQAAAC1xAQAEAAAA LgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAAAAAAALwCAQAAAABAACJBcmlhbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIMAAAA MgpiADwAAwAAAFRhZwgBAAEAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAAAAAA ALwCAQAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4B GAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpkADsAAQAAAFNxAQAEAAAALgEAAAQAAAAtAQUABAAA APABBAAcAAAA+wL+/wAAAAAAALwCAQAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpkADwAAQAAAC1xAQAE AAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAAAAAAALwCAQAAAABAACJBcmlhbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIM AAAAMgpkAD0AAwAAAFRhZwgBAAEAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBAAcAAAA+wL+/wAA AAAAALwCAQAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQQABAAA AC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIKAAAAMgpiAEcAAgAAAFBXAQACAAQAAAAuAQAABAAAAC0B BQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIBAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgkAAAAyCmIASgABAAAA LXEBAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIBAAAAAEAAIkFyaWFs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAgwAAAAyCmIASwADAAAATFNFCAEAAQABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7 Av7/AAAAAAAAvAIBAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0B BAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgwAAAAyCmQASAADAAAATFNQCAEAAQABAAQAAAAu AQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIBAAAAAEAAIkFyaWFsAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgkAAAAy CmQASwABAAAALXEBAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEEABwAAAD7Av7/AAAAAAAAvAIBAAAA AEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAAC AQEABQAAAAkCAAAAAgwAAAAyCmQATAADAAAATFNFCAEAAQABAAQAAAAuAQAABAAAAC0BBQAEAAAA 8AEEABwAAAD7Av7/AAAAAAAAvAIBAAAAAEAAIkFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgoAAAAyCmIAVwACAAAAUFcBAAIA BAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/v8AAAAAAAC8AgEAAAAAQAAiQXJpYWwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAAC CQAAADIKYgBaAAEAAAAtcQEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/v8AAAAAAAC8 AgEAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgA BAAAAAIBAQAFAAAACQIAAAACDAAAADIKYgBbAAMAAABMU0UIAQABAAEABAAAAC4BAAAEAAAALQEF AAQAAADwAQQAHAAAAPsC/v8AAAAAAAC8AgEAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKZABYAAMAAABM U1AIAQABAAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/v8AAAAAAAC8AgEAAAAAQAAi QXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAF AAAACQIAAAACCQAAADIKZABbAAEAAAAtcQEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC /v8AAAAAAAC8AgEAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEE AAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKZABcAAMAAABMU0UIAQABAAEABAAAAC4B AAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/v8AAAAAAAC8AgEAAAAAQAAiQXJpYWwAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIK WwBoAAEAAABDcQEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC/v8AAAAAAAC8AgEAAAAA QAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIB AQAFAAAACQIAAAACCQAAADIKWwBpAAEAAAAtcQEABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAA APsC/v8AAAAAAAC8AgEAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEEAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDAAAADIKWwBqAAMAAABUYWcIAQABAAEABAAA AC4BAAAEAAAALQEFAAQAAADwAQQAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5rlwDAAAYAwAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAoAAAAAQA AADIAAAABgAAANAAAAAHAAAA2AAAAAgAAADgAAAACQAAAOgAAAAKAAAA8AAAABcAAAD4AAAACwAA AAABAAAQAAAACAEAABMAAAAQAQAAFgAAABgBAAANAAAAIAEAAAwAAAC4AgAAAgAAAOn9AAAeAAAA CAAAAEN1c3RvbQAAHgAAACAAAABIdWF3ZWkgVGVjaG5vbG9naWVzIENvLixMdGQuAAAAAAMAAACZ NAIAAwAAAEwBAAADAAAABgAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAABkHwsACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAADQAAAAYAAABBcmlhbAALAAAATVMgUEdvdGhp YwAHAAAA5a6L5L2TAAoAAABXaW5nZGluZ3MADQAAAFRyZWJ1Y2hldCBNUwAQAAAAVGltZXMgTmV3 IFJvbWFuABMAAABodWF3ZWktdGVtcGxhdGUtbXYAFwAAAFdob2xlc2FsZSBFVkMgT3B0aW9uIEkA GAAAAFdob2xlc2FsZSBFVkMgT3B0aW9uIElJABkAAABXaG9sZXNhbGUgRVZDIE9wdGlvbiBJSUkA PgAAAFdob2xlc2FsZSBFVkMgT3B0aW9uIEkgTWFpbnRlbmFuY2UgRW50aXR5IEdyb3VwIChNRUcp IGV4YW1wbGUAPwAAAFdob2xlc2FsZSBFVkMgT3B0aW9uIElJIE1haW50ZW5hbmNlIEVudGl0eSBH cm91cCAoTUVHKSBleGFtcGxlAEUAAABXaG9sZXNhbGUgRVZDIE9wdGlvbiBJSUkgIEVWQyBNYWlu dGVuYW5jZSBFbnRpdHkgR3JvdXAgKE1FRykgZXhhbXBsZQAMEAAABgAAAB4AAAALAAAARm9udHMg VXNlZAADAAAABgAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlk ZSBUaXRsZXMAAwAAAAYAAABQAAAAAwAAAAAAAAAgAAAAAQAAADIAAAACAAAAOgAAAAEAAAACAAAA BgAAAHNmbGFnAAIAAADp/QAAHgAAAAwAAAAxMjQwMzM4MTAyAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA9g8fAAAAFAAAAF/AkeN1JAIABwD0AwMAEwBWaXNzZXJzCAAAAFYAaQBzAHMAZQByAHMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA AgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA/v///wkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQ AAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4A AAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAA AC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAA OwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJ AAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcA AABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAA AGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAA dAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAIEAAACC AAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAA AACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAA AJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAA rQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAAALcAAAC4AAAAuQAAALoAAAC7 AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADHAAAAyAAAAMkA AADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUAAADWAAAA1wAA ANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAAAOQAAADlAAAA 5gAAAOcAAADoAAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAAAPAAAADxAAAA8gAAAPMAAAD0 AAAA9QAAAPYAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA/gAAAP8AAAAAAQAAAQEAAAIB AAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEAAA4BAAAPAQAAEAEA ABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAD+////HAEAAB0BAAAeAQAA HwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEAACkBAAAqAQAAKwEAACwBAAAt AQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAANwEAADgBAAA5AQAAOgEAADsB AAA8AQAAPQEAAD4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAABFAQAARgEAAEcBAABIAQAA/v// /0oBAABLAQAATAEAAE0BAABOAQAATwEAAFABAAD+////UgEAAFMBAABUAQAAVQEAAFYBAABXAQAA WAEAAP7////9/////f////3///9dAQAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////9SAG8AbwB0 ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgAFAf//////////AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8A AAAAAAAAAFAAaQBjAHQAdQByAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAASAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAQAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA//////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRAQAAABAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAFAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsBAAD0WgAAAAAAAFAAbwB3AGUA cgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAJkk AgAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBv AG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABJAQAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAg AEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYA BQH//////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAAMIYWtw/EyQFhAQAAwAMA AAAAAABQAGkAYwB0AHUAcgBlAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEAAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAUQEAAAAQAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABQAAAP////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAQAA9FoAAAAAAAABAQAAAgEAAAMB AAAEAQAABQEAAAYBAAAHAQAACAEAAAkBAAAKAQAACwEAAAwBAAANAQAADgEAAA8BAAAQAQAAEQEA ABIBAAATAQAAFAEAABUBAAAWAQAAFwEAABgBAAAZAQAAGgEAAP7///8cAQAAHQEAAB4BAAAfAQAA IAEAACEBAAAiAQAAIwEAACQBAAAlAQAAJgEAACcBAAAoAQAAKQEAACoBAAArAQAALAEAAC0BAAAu AQAALwEAADABAAAxAQAAMgEAADMBAAA0AQAANQEAADYBAAA3AQAAOAEAADkBAAA6AQAAOwEAADwB AAA9AQAAPgEAAD8BAABAAQAAQQEAAEIBAABDAQAARAEAAEUBAABGAQAARwEAAEgBAAD+//////// //////////////////////////////////////9SAQAAUwEAAFQBAABVAQAAVgEAAFcBAABYAQAA /v////3////9////////////////////YwEAAP3////+////YgEAAP7////+//////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////wEAAAACAAAAAwAA AAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA/v////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////v8AAAUBAgAAAAAA AAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rlwDAAAY AwAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAoAAAAAQAAADIAAAABgAAANAAAAAHAAAA2AAAAAgA AADgAAAACQAAAOgAAAAKAAAA8AAAABcAAAD4AAAACwAAAAABAAAQAAAACAEAABMAAAAQAQAAFgAA ABgBAAANAAAAIAEAAAwAAAC4AgAAAgAAAOn9AAAeAAAACAAAAEN1c3RvbQAAHgAAACAAAABIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLixMdGQuAAAAAAMAAACZNAIAAwAAAEwBAAADAAAABgAAAAMAAAAA AAAAAwAAAAAAAAADAAAAAAAAAAMAAABkHwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAADQAAAAYAAABBcmlhbAALAAAATVMgUEdvdGhpYwAHAAAA5a6L5L2TAAoAAABXaW5nZGlu Z3MADQAAAFRyZWJ1Y2hldCBNUwAQAAAAVGltZXMgTmV3IFJvbWFuABMAAABodWF3ZWktdGVtcGxh dGUtbXYAFwAAAFdob2xlc2FsZSBFVkMgT3B0aW9uIEkAGAAAAFdob2xlc2FsZSBFVkMgT3B0aW9u IElJABkAAABXaG9sZXNhbGUgRVZDIE9wdGlvbiBJSUkAPgAAAFdob2xlc2FsZSBFVkMgT3B0aW9u IEkgTWFpbnRlbmFuY2UgRW50aXR5IEdyb3VwIChNRUcpIGV4YW1wbGUAPwAAAFdob2xlc2FsZSBF VkMgT3B0aW9uIElJIE1haW50ZW5hbmNlIEVudGl0eSBHcm91cCAoTUVHKSBleGFtcGxlAEUAAABX aG9sZXNhbGUgRVZDIE9wdGlvbiBJSUkgIEVWQyBNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAgKE1F RykgZXhhbXBsZQAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAABgAAAB4AAAAQAAAARGVz aWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAYAAABQAAAAAwAA AAAAAAAgAAAAAQAAADQAAAACAAAAPAAAAAEAAAACAAAABgAAAHNmbGFnAAIAAgAAAOn9AAAeAAAA DAAAADEyNDAzMzgxMDIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAbwB3AGUAcgBQAG8A aQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAJkkAgAAAAAA BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAArAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0001_01C9C420.B75CF550-- From John.E.Drake2@boeing.com Thu Apr 23 09:29:04 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F3A28C6F9 for ; Thu, 23 Apr 2009 09:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW-Sq5eMC0hX for ; Thu, 23 Apr 2009 09:29:03 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id BEFEB28C4B0 for ; Thu, 23 Apr 2009 09:29:03 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3NGU9sP028453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Apr 2009 11:30:09 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3NGU8sI014616; Thu, 23 Apr 2009 09:30:08 -0700 (PDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3NGTxcN013943; Thu, 23 Apr 2009 09:30:06 -0700 (PDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 09:30:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Apr 2009 09:29:08 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01ABA32B@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDpkljnFPJ53FoTkiYXmmzxV4tpAAik5qw References: From: "Drake, John E" To: "Ben Niven-Jenkins" , , "BRUNGARD, DEBORAH A, ATTLABS" X-OriginalArrivalTime: 23 Apr 2009 16:30:03.0593 (UTC) FILETIME=[C1383390:01C9C430] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 16:29:04 -0000 Ben, Very well put. Thanks, John=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Wednesday, April 22, 2009 4:59 PM > To: liu.guoman@zte.com.cn; BRUNGARD, DEBORAH A, ATTLABS > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport=20 > path requirements >=20 > On 21/04/2009 02:59, "liu.guoman@zte.com.cn"=20 > wrote: >=20 > > Deborah: > > maybe what you said is right. but I can't completely agree=20 > your opinions. > > IMO. mpls-tp is regard as transport network like SDH/SONET. so it=20 > > should have AIS/FDI fuctions as SDH/SONET. > >=20 > > do you think so. >=20 > No we must assess the requirements for packet transport=20 > networks supporting the needs of operators today and in the=20 > future. We must not blindly recreate SDH/SONET. If we do so=20 > without consideration to how operators' needs and=20 > requirements may have evolved (and continue to evolve in=20 > future) we will have failed IMO and I would severely question=20 > the value of the work we will have produced. If we just=20 > recreate SDH/SONET then what is the purpose of the work an=20 > operator would be better off just deploying existing=20 > SDH/SONET equipment. >=20 >=20 > Ben >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From DALLAN@nortel.com Thu Apr 23 12:18:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7B73A68D8 for ; Thu, 23 Apr 2009 12:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.346 X-Spam-Level: X-Spam-Status: No, score=-5.346 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aHJZytz2mcj for ; Thu, 23 Apr 2009 12:18:26 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 792783A6F75 for ; Thu, 23 Apr 2009 12:18:25 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3NJIs714035; Thu, 23 Apr 2009 19:18:54 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C447.BE8B7044" Date: Thu, 23 Apr 2009 15:14:37 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE193A8507@zcarhxm2.corp.nortel.com> In-Reply-To: <000001c9c40f$f3d42550$0800540a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDqIM1poMBpMA1QHCY51t7wHwYNwABL+4gACZIuOA= References: <787be2780904221714l4e3c5fffv6db3cf2ebae4c40a@mail.gmail.com> <000001c9c40f$f3d42550$0800540a@china.huawei.com> From: "David Allan" To: "Maarten Vissers" , "Greg Mirsky" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 19:18:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C447.BE8B7044 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Maarten: =20 A couple of questions on these charts simply before these examples be = considered gospel...from a BBF TR101 perspective.... =20 1) You are suggesting broadcast domains on the RMP constructs of up to = 80000 end points? =20 2) You do not seem to be extending S-tag, and hence EVP, from DSLAM to = Service router... why? This does not seem to correspond to current = practice... =20 thanks Dave =20 =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Maarten Vissers Sent: Thursday, April 23, 2009 8:35 AM To: 'Greg Mirsky' Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Greg, =20 The reason I have placed UNIs also as peers of the EVC is because many = operators provide this type of service today.=20 E.g. when a packet transport network provides interconnection between an = ISPs service edge router to a group of DSLAMs, then the service edge = router of such ISP is connected to the PTN of the network operator via a = rooted-mp EVC that has an endpoint in the service edge router and in the = group of DSLAMs (case of ATM DSLAMs). With the introduction of VDSL2 and = fiber DSLAMs into the network, the EVC endpoints will be in the home = gateways or in the end-user terminal equipment (STB, PC, VoIP telephone, = ...). I have illustrated these three cases in the attached slides 1 to = 3. Slides 4 to 6 illustrate some examples of EVC maintenance entity = groups that could be defined for those three cases.=20 =20 Another case is carrier-carrier services. Carrier A wants to = interconnect with a number of remote network termination devices which = are located behind the network of a regional carrier B. E.g. 10 NT = devices, each connected with a fast ethernet interface to carrier B = network. Carrier A network connects via 1GE interface to carrier B = network. Two scenarios are now possible: =20 1) each fast ethernet interface carries a single VLAN service, which is = carried as an E ging n VC through the network of carrier B towards the = interface with carrier A. At this interface the 10 EVCs are multiplexed = onto the 1GE interface. The EVCs are now commonly owned by carrier A and = B, and possibly by the customer. Carrier B monitors those 10 EVCs via a = TCM MEG level. =20 2) each fast ethernet interface carries a number of VLAN services, each = identified by a C-Tag. This group of services is treated as a port based = service in the network of carrier B. This port based service (section = VLAN (EVS)) is treated as EVC in carrier B's network and often = identified by means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 = EVSs of the customers) are multiplex into the 1GE interface and = delivered to carrier A's Virtual UNI-N port. Carrier A's V-UNI-N port = treats those 10 EVCs of carrier B as 10 EVPs, each EVP carrying multiple = EVC signals. Each carrier A EVC signal is traffic conditioned, and gets = EVC OAM in the EVC TCM MEP functions located in this V-UNI-N port card. - The EVCs in carrier B's network have their endpoints in customer edge = equipment and in the V-UNI-N port of carrier A. For the customer this is = an EVS endpoint, while for the carrier A this is an EVP endpoint. = Carrier B's EVC peers as such with carrier A and customer for this EVC = and carrier B will monitor its EVC via a TCM MEG level. - The EVCs in carrier A network have their endpoints in the customer = network (e.g. customer edge equipments). Carrier A deploys a TCM MEG = level to monitor this service.=20 =20 Regards, Maarten ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: donderdag 23 april 2009 2:15 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I agree with your presentation of layers but only wonder why you've = placed UNIs both as clients of EVC layer as well as its peers. I'd leave = UNIs only as clients of EVC layer. Would you agree? Regards, Greg 2009/4/22 Maarten Vissers Dear Greg, =20 Thank you for this confirmation.=20 This other layer is that the EVC layer as illustrated in the figure = below? =20 UNI UNI --||------- ---------||----- | | UNI ------------------------------------------------- UNI --||----| EVC layer |-----||----- ------------------------------------------------- | MPLS-TP layer | | other layer | ----------------- ---------------- =20 MEF's E-Tree is a bidirectional rooted-multipoint connection, in which = frames are forwarded on the basis of the value in their DA field. Such = selective forwarding is not supported in an LSP connection. An LSP = connection will as such just support one EVC link connection, i.e. a = part of the EVC between two adjacent EVC switch/bridge functions. Those = p2p EVC link connections simply require non-selective forwarding, = something that an LSP connection can provide. =20 Regards, Maarten ________________________________ =09 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 =09 Sent: woensdag 22 april 2009 23:00=20 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 Dear Maarten, I think you've captured my view pretty accurately. Since MPLS-TP = supports only p2p and p2mp transports it would be responsibility of = another layer to support specific services among UNI-Ns. Interesting = thing that E-Tree can not be directly mapped to p2mp unidirectional = MPLS-TP LSP since by MEF's definition E-Tree is a bidirectional service. = (Just a note). =09 Kind regards, Greg =09 =09 2009/4/22 Maarten Vissers =09 Dear Greg, =20 Do you mean that there is a layer network above MPLS-TP that will = support these services from UNI-N port to UNI-N port, and that MPLS-TP = will support this service layer network? =20 Regards, Maarten ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 Dear Maarten, I believe that it is not a requirement for MPLS-TP to support any = specific service, including ones you've listed in your message. On the = other hand, support of listed services is a requirement for a client = layer that uses MPLS-TP services. =09 Regards, Greg Mirsky =09 =09 2009/4/22 Maarten Vissers =09 Neil, =20 I expect that the main requirement for a packet transport network = technology like MPLS-TP is that it is able to support at least the = following services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed manner. =20 Another main requirement is that it must be able to support those = services in a scalable manner between points anywhere in the world. =20 The E-Line, E-Tree and E-LAN services allow to reorder client frames = that belong to different priorities and to drop client frames that are = drop eligible. =20 The E-Tree and E-LAN services require that client bits are read to = deliver the frames to the appropriate output port or ports of the E-Tree = or E-LAN supporting transport entity/differentiated connection. =20 The packet transport network technology must as such support traffic = engineered transport entities (differentiated connections) with n input = ports (i.e. multi source constructs). This in addition of traffic = engineered transport entities with 1 input port. =20 Regards, Maarten =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 Liu, =20 If MPLS-TP is going to be taken seriously as a transport network = (like SDH/SONET) then the 2 key MUST HAVE requirements are these. =20 1 Provide a transparent client/server relationship...which means: - all client bits treated equally - client bit ordering preserved - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols - the traffic behaviour of client X must not impact the = performance experienced by client Y =20 A key corollary of the above is that MPLS-TP must only support proper = connections (ie single source constructs) =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology. =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise. =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones). =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on = balance we considered not a good idea for PBB-TE OAM because it requires = a conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong. =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim. =20 regards, Neil =20 =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 =09 =09 =09 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =09 =B3=AD=CB=CD mpls-tp@ietf.org =09 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an = operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects = dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will = not be able to understand that as long as you refuse to accept that = "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated = connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE = and P-OTN VP trails inside metro and core domains interconnecting EVC = matrices. When one of those EVC links is interrupted, e.g. in the core between = metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more = frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a = connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and = OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means = is that OAM that is of a request/response nature cannot be trusted in co = mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it = won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to have = to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact = as they all offer something different/important. But do not be hoodwinked = by those who peddle a story that that tries to make the OAM of the 3 modes = the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a = return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs = could be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of = requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other = > > more important requirements (e.g. the possibility to work w/o IP = > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or = management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for = these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs = seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the = pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there = is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM = packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM = MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for = performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements = section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the = pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met = by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms = of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane = content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, = but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that = associated=20 > > > > > bidirectional paths are the only types of paths that can = be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional = paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the = time > > > > > being, the most important type of bidirectional paths = in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 ------_=_NextPart_001_01C9C447.BE8B7044 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi=20 Maarten: A=20 couple of questions on these charts simply before these examples be = considered gospel...from a BBF TR101 perspective.... 1) You=20 are suggesting broadcast domains on the RMP constructs of up to 80000 = end=20 points? 2) You=20 do not seem to be extending S-tag, and hence EVP, from DSLAM to Service=20 router... why? This does not seem to correspond to current=20 practice... thanks Dave From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Thursday, April 23, 2009 8:35 AM To: = 'Greg=20 Mirsky' Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path = requirements Dear Greg, The reason I have placed UNIs also as peers of = the EVC is=20 because many operators provide this type of service today. = E.g. when a packet transport network provides=20 interconnection between an ISPs service edge router to a group of = DSLAMs, then=20 the service edge router of such ISP is connected to the PTN of the = network=20 operator via a rooted-mp EVC that has an endpoint in the service = edge=20 router and in the group of DSLAMs (case of ATM DSLAMs). With the=20 introduction of VDSL2 and fiber DSLAMs into the network, the EVC = endpoints will=20 be in the home gateways or in the end-user terminal equipment (STB, PC, = VoIP=20 telephone, ...). I have illustrated these three cases in the = attached=20 slides 1 to 3. Slides 4 to 6 illustrate some examples of EVC = maintenance=20 entity groups that could be defined for those three=20 cases. Another case is carrier-carrier services. = Carrier A wants=20 to interconnect with a number of remote network termination devices = which=20 are located behind the network of a regional carrier B. E.g. 10 NT = devices, each=20 connected with a fast ethernet interface to carrier B network. Carrier A = network=20 connects via 1GE interface to carrier B network. Two scenarios are now=20 possible: 1) each fast ethernet interface carries a = single VLAN=20 service, which is carried as an E ging=20 n VC through the network of carrier B towards the interface = with=20 carrier A. At this interface the 10 EVCs are multiplexed onto the 1GE = interface.=20 The EVCs are now commonly owned by carrier A and B, and possibly by the=20 customer. Carrier B monitors those 10 EVCs via a TCM MEG=20 level. 2) each fast ethernet interface carries a = number of VLAN=20 services, each identified by a C-Tag. This group of services is treated = as a=20 port based service in the network of carrier B. This port based service = (section=20 VLAN (EVS)) is treated as EVC in carrier B's network and often = identified by=20 means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 EVSs of the = customers)=20 are multiplex into the 1GE interface and delivered to carrier A's = Virtual UNI-N=20 port. Carrier A's V-UNI-N port treats those 10 EVCs of carrier B as 10 = EVPs,=20 each EVP carrying multiple EVC signals. Each carrier A EVC signal is = traffic=20 conditioned, and gets EVC OAM in the EVC TCM MEP functions located in = this=20 V-UNI-N port card. - The EVCs in carrier B's network have their = endpoints in=20 customer edge equipment and in the V-UNI-N port of carrier A. For the = customer=20 this is an EVS endpoint, while for the carrier A this is an EVP = endpoint.=20 Carrier B's EVC peers as such with carrier A and customer for this = EVC and=20 carrier B will monitor its EVC via a TCM MEG level. - The EVCs in carrier A network have their = endpoints in the=20 customer network (e.g. customer edge equipments). Carrier A deploys a = TCM MEG=20 level to monitor this service. Regards, Maarten From: Greg Mirsky = [mailto:gregimirsky@gmail.com]=20 Sent: donderdag 23 april 2009 2:15 To: Maarten=20 Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path = requirements Dear Maarten, I agree with your presentation of layers but = only=20 wonder why you've placed UNIs both as clients of EVC layer as well as = its peers.=20 I'd leave UNIs only as clients of EVC layer. Would you=20 agree? Regards, Greg 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com= > Dear=20 Greg, Thank you=20 for this confirmation. This other=20 layer is that the EVC layer as illustrated in the figure=20 below? =20 = UNI           &nbs= p;            = ;            =             &= nbsp;       =20 UNI --||-------         = ;            =             &= nbsp;     =20    ---------||-----          =20 = |            =             &= nbsp;           &n= bsp;  =20    | UNI  =20 -------------------------------------------------   =20 UNI --||----|         &= nbsp;      =20 EVC=20 = layer           &n= bsp;        =20 |-----||-----        =20 -------------------------------------------------           &nbs= p;  | MPLS-TP=20 layer |    |  other layer = |           &nbs= p;  -----------------   =20 ---------------- MEF's=20 E-Tree is a bidirectional rooted-multipoint connection, in = which=20 frames are forwarded on the basis of the value in their DA field. Such = selective forwarding is not supported in an LSP connection. An LSP = connection=20 will as such just support one EVC link connection, i.e. a = part of=20 the EVC between two adjacent EVC switch/bridge functions. Those p2p = EVC link=20 connections simply require non-selective forwarding, something that an = LSP=20 connection can provide. Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00=20 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path = requirements Dear Maarten, I think you've captured my view pretty = accurately.=20 Since MPLS-TP supports only p2p and p2mp transports it would be = responsibility=20 of another layer to support specific services among UNI-Ns. = Interesting thing=20 that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP = LSP=20 since by MEF's definition E-Tree is a bidirectional service. (Just a=20 note). Kind regards, Greg 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com> Dear=20 Greg, Do you=20 mean that there is a layer network above MPLS-TP that will support = these=20 services from UNI-N port to UNI-N port, and that MPLS-TP will = support this=20 service layer network? Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten=20 Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org=20 Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements Dear Maarten, I believe that it is not a requirement = for=20 MPLS-TP to support any specific service, including ones you've = listed in=20 your message. On the other hand, support of listed services is a = requirement=20 for a client layer that uses MPLS-TP = services. Regards, Greg=20 Mirsky 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com> Neil, I=20 expect that the main requirement for a packet = transport network=20 technology like MPLS-TP is that it is able to support at least the = following services: -=20 E-Line -=20 E-Tree -=20 E-LAN - PDH=20 CES in a=20 traffic engineered and managed manner. Another main requirement is that it must be able to = support those=20 services in a scalable manner between points anywhere in the=20 world. The=20 E-Line, E-Tree and E-LAN services allow to reorder = client frames that=20 belong to different priorities and to drop client frames that = are=20 drop eligible. The=20 E-Tree and E-LAN services require that client bits are read to = deliver the=20 frames to the appropriate output port or ports of the E-Tree = or E-LAN=20 supporting transport entity/differentiated = connection. The=20 packet transport network technology must as such support traffic=20 engineered transport entities (differentiated connections) = with n=20 input ports (i.e. multi source constructs). This in addition of = traffic=20 engineered transport entities with 1 input = port. Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = neil.2.harrison@bt.com Sent: dinsdag = 21 april=20 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path=20 requirements Liu, If MPLS-TP is going to be taken seriously as a transport = network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. 1    Provide a transparent client/server=20 relationship...which means: -    all client bits treated=20 equally -    client bit ordering=20 preserved -    no attempt to infer client symbol (ie = sequence=20 of client bits) meaning and no attempt to change client=20 symbols -    the traffic behaviour of client X = must not=20 impact the performance experienced by client Y A key corollary of the above is that MPLS-TP must only = support=20 proper connections (ie single source = constructs) 2   Since MPLS-TP is a transport network it is = not a=20 top-of-stack network (ie it does not support directly external=20 message/file/stream applications). MPLS-TP therefore does = not=20 require an E-NNI specification. A key corollary of this is = that=20 MPLS-TP will not have any peer interworking relationship with any = other=20 network mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. You = could argue=20 this should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE = (also a=20 co-ps mode network) should have FDI/AIS we concluded that on = balance it=20 was not a good idea.....and note that initially I was in favour of = having=20 AIS, but my colleagues provided strong technical arguments that = convinced=20 me otherwise. AIS/FDI is historically linked to the early = PDH co-cs=20 mode layer networks that used TTL logic. When this died it = put out a=20 +5V (all 1s) signal by default, ie it required no conscious effort = to=20 generate it.....this is key point. Further, in these = networks there=20 is a fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never = specified=20 AIS for IP and its why IEEE had the good sense to throw-out AIS in = 802.1ag=20 for Ethernet (though ITU have unwisely IMO retained it in = Y.1731....but I=20 suspect any operator planning to use Ethernet equipment would = always look=20 to IEEE stds and not ITU ones). AIS/FDI and the co-ps mode is = debatable. As I=20 noted above, on balance we considered not a good idea for PBB-TE = OAM=20 because it requires a conscious effort to generate it (unlike the = co-cs=20 mode) so there are likely to be scaling problems and its one more = thing to=20 go wrong. You should also have seen me make the point = many times=20 in the past that the always-on defect detection/handling OAM needs = to be=20 as simple/sparse as possible with as little config as possible = because we=20 need super reliability......TCM goes completely against the grain=20 here. Also note that the OAM required for each of the 3 = network=20 modes is not the same, despite what some=20 claim. regards, = Neil From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = liu.guoman@zte.com.cn Sent: 21 = April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: = mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path=20 requirements Deborah: maybe what you=20 said is right. but I can't completely agree your opinions. IMO. = mpls-tp=20 is regard as transport network like SDH/SONET. so it should have = AIS/FDI=20 fuctions as SDH/SONET. do=20 you think so. best=20 regards liu = "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten Vissers" = <maarten.vissers@huawei.com>, = <neil.2.harrison@bt.com> =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 size=3D2>I agree with Neil, it is very questionable the = value of=20 AIS/FDI in a packet network- any mode. It can result in a DoS = attack=20 by an operator on themselves so even Y1731 recommends not to = block=20 data frames: "A MEP can decide whether it blocks data frames = when it=20 detects dAIS. The principle requirement that influences = this=20 decision is that data frames ought to be forwarded as much as = possible, without the possibility of forwarding wrong data = frames=20 downstream." Table I.7-2 shows for AIS, not to = block. And as=20 Y1731 states, AIS can only be used under very=20 constrained architectures - if required for MPLS-TP, it needs = to have=20 the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a point-to-point ETH connection, a MEP has = only a=20 single peer MEP. Therefore, there is no ambiguity = regarding the=20 peer MEP for which it should suppress alarms when it receives = the ETH-AIS information." So should only be within one = domain -=20 then no need. Deborah -----Original = Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport = path requirements Neil, >=20 but AIS/FDI in the cl mode?...do me a favour! Ethernet = AIS is=20 indeed a requirement and a necessity. And you will = not be able to=20 understand that as long as you refuse to accept that = "cl-mode" is=20 a forwarding mode within a **transport entity**. G.800 = amendment 1=20 has finally reintroduced this transport entity into G.800. = Besides=20 that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is = a=20 transport entity that transfers information belonging to = multiple=20 communications between ports across a subnetwork. <..> = In a=20 differentiated connection message contents are interpreted = to=20 identify (sets of) communications which=20 receive different treatment. The sets of = communications may=20 be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms of=20 G.800 "differentiated connections". Ethernet AIS provides = AIS=20 within the scope of such "differentiated = connection". If you apply=20 this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and core = domains=20 interconnecting EVC matrices. When one of those EVC links = is=20 interrupted, e.g. in the core between metro 1 and metro 4 = (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS = is=20 inserted in the downstream direction to suppress the EVC-LOC = alarms=20 at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet AIS)=20 frame has a reserved multicast address, which guarantees that = the AIS=20 is broadcast to the endpoints of the EVC. I believe that = it is=20 time for you to adapt your view on co and cl = modes and relate it=20 to the forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP = differentiated connection"=20 with a billion or more ports. What we know as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN is=20 essentially an "Ethernet differentiated connection" with n = ports=20 (n in the range of e.g. 2 to 1000). What we know as a p2p = MPLS E-LSP=20 is essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection" with=20 2 ports. Transport network OAM applies to transport = entities,=20 which are (in terms of G.800 am1) connections and = differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 = april=20 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements John, = Thanks=20 this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting = a wee=20 bit tired of folks trying to make all 3 network modes look = alike=20 (and then, even worse, interwork them as as peers...esp = when not=20 not top-of-stack networks...I mean how silly can we get?). = I=20 am even more frustrated by the fact those peddling this FUD = only ever=20 seem to consider OAM and forget all other DP/CP/MP = components (esp=20 top-of-stack message/file/stream application adaptations). = How=20 wrong can this get! In the co modes a *connection* is a = very=20 specific and *constraining* construct.....I am assuming here = we=20 respect the rules of a connection (ie single source) = though some=20 folks don't even bother to respect this, and this is = despite the=20 fact that we all know what problems = multiple-source constructs can=20 cause (from LDP/PHP....ergo MPLS-TP). When we have a = connection=20 this restricts *all* DP (ie traffic and OAM) to stay = within the=20 bounds of the connection. Which is fine=20 under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is = broken.=20 In a nutshell what this means is that OAM that is of = a=20 request/response nature cannot be trusted in co mode networks = under=20 misconnectivity defects.....indeed, why should a = leaking DP have a=20 symmetric go/return defect behaviour?....very likely it=20 won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts to = explain=20 that physics....G.805 does not. So, the 3 modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the=20 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Drake, John=20 E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; = Alexander=20 Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > = requirements >=20 > Italo, > > As described in the MPLS TP OAM = Requirements I-D, virtually all of the > OAM functions = require=20 a return path, and in the absence of a return > path they = are=20 disabled. > > As described in David Sinicrope's = meeting=20 minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/w= iki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the issue=20 of return path for unidirectional LSPs could be > = charaterized=20 as the elephant in the room. In the MPLS TP OAM > = Framework=20 I-D, unicast LSPs are only mentioned three times and return = >=20 paths not at all. > > Thanks, > > = John >=20 > -----Original Message----- > > From: BUSI ITALO = [mailto:Italo.Busi@alcatel-lucent.it] > > = Sent:=20 Friday, April 17, 2009 1:59 AM > > To: Drake, John E; = Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path > >=20 requirements > > > > John, > > = > >=20 I might have missed the agreement of MPLS-TP being capable of = >=20 > sending replies to OAM requests sent on uni-directional=20 LSPs. > > > > This requirement does not = belong to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken = into=20 account (at worst in a > subsequent phase). > > = >=20 > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility = to work=20 w/o IP > > forwarding and the need for OAM to continue = to=20 monitor the data > > plane also in case of failures = affecting=20 the control or management > > plane). > > = >=20 > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = >=20 > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Drake, John=20 E > > > Sent: Thursday, April 16, 2009 8:00 = PM > >=20 > To: Alexander Vainshtein; Maarten Vissers > > > = Cc: mpls-tp@ietf.org > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 requirements > > > > > > At the meeting = last=20 fall at Juniper in Massachusetts, I > > think it = was >=20 > > agreed that an MPLS TP network needs to have a=20 forwarding > > capability > > > for = management,=20 control, and OAM packets (e.g., sending > > replies to=20 OAM > > > requests sent on uni-directional LSPs) = even if it=20 does not > > have an IP > > > forwarding = data=20 plane. > > > > > > > -----Original=20 Message----- > > > > From: Alexander = Vainshtein >=20 > > [mailto:Alexander.Vainshtein@ecitele.com] > = > >=20 > Sent: Thursday, April 16, 2009 9:57 AM > > > = > To:=20 Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Maarten, > > > > It seems that you've just = (implicitly=20 and, probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will = not=20 ever support MIP loopback function > > (and = fault > >=20 > > localization which requires this function ) = for > >=20 unidirectional P2MP > > > > and P2P = paths. > >=20 > > > > > > If this statement is correct, = this=20 (IMHO and FWIW) > raises a valid > > > >=20 question: > > > > > > > > = =20 Is MPLS-TP an=20 appropriate solution for these > types of = transport > >=20 > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > = functionality=20 today > > > > for (unidirectional - but it does = not know=20 any other > > type) P2P LSPs > > > > as=20 described in RFC 4379. And its extension to P2MP LSPs seems = >=20 > > > easy... > > > > > > > = >=20 > > > > > > > > = Regards, >=20 > > > > > > > = Sasha >=20 > > > > > > > > > > > = >=20 > > > ________________________________________ > = >=20 > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > = > >=20 Sent: Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Adrian, > > > > > > > > >>=20 <quote> > > > > >> = The=20 intermediate nodes (including MEPs, MIPs and > > > = >=20 other internal > > > > >> = =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of = that > >=20 > > >> transport path. > = >=20 > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > is, there is > > > > >=20 *nothing* that can be observed from a black box point of > = >=20 > view that > > > > > results from adhering = to this=20 requirement. > > > > > > > > Your = understanding is not correct. It is very much > observable = if > > > > this requirement is met from a black = box point=20 of view. > > > > The MIP functions can only = perform the=20 Loopback when there is a > > > > co-routed = bidirectional=20 transport path. The MPLS-TP LBM packet > > > > = received=20 at a MIP needs to be returned (as LBR > > > > = packet) to=20 the originating MEP function via the other > > = direction=20 of > > > > the co-routed bidirectional transport = path.=20 This other > direction > > > > would not be = available in an associated bidirectional transport > > = >=20 > path... and thus the loopback test > > > would=20 fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not in a > > > > associated = bidir=20 transport path. In the first case the TCM MEP > > > = >=20 Source and Sink functions are co-located and can > = exchange what=20 is > > > > called "remote information" which is = necessary=20 for performance > > > > monitoring. > > = >=20 > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, > >=20 > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = > Your=20 understanding is not correct. This text must not be > > = deleted=20 at > > > > all. > > > > > = > >=20 > > Actually, I am quite fed up about this = persistent > >=20 > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > >=20 is > > > > poorly > > > > > = specified=20 and comes from the monitoring of a path that is > > = > >=20 parallel (i.e. > > > > tandem) > > > = >=20 > to the data path being monitored. This definition of = TC >=20 > > > seems to be at > > > > = variance, >=20 > > > > and would be if the ACH was actually in=20 band. > > > > > > > > I don't = understand=20 where your interpretation of tandem > > connection = is >=20 > > > described in ITU-T recommendations. I.e. "from=20 the > > monitoring of a > > > > path = that is=20 parallel (i.e. tandem) to the data path being > > > = >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection is = a=20 set > > > > of interconnected "link connections" = and=20 "matrix > connections". A > > > > subset of = those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to as > = a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There=20 is only additional OAM inserted inside the data > path by=20 the > > > > TCM MEP_So function and this OAM is = extracted=20 from the > > data path by > > > > the = TCM MEP_Sk=20 function. > > > > > > > >=20 Regards, > > > > Maarten > > > > = >=20 > > > > > > > -----Original=20 Message----- > > > > From: mpls-tp-bounces@ietf.org > > > = >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Adrian=20 Farrel > > > > Sent: donderdag 16 april 2009=20 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > >=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > > = Unfortunately=20 I cannot fully agree with your statement: > > > > = > > > > > > <quote> > > > = >=20 > From the point of view of hardware, = co-routed >=20 > > bidirectional LSPs > > > > > = =20 are a special case of associated bidirectional LSPs. > = > >=20 > > <end quote> > > > > > > = >=20 > > > This statement would be obviously correct, were = it not=20 for > > > > Requirement > > > > = > 34 in=20 the latest MPLS-TP requirements draft > > > > = >=20 > > > OK. Got it. > > > > > > = >=20 > But what is this doing in the data plane requirements=20 section? > > > > > > > > In fact, = what is=20 this requirement actually saying? > > > > = > >=20 > > > <quote> > > > > > = =20 The intermediate nodes (including MEPs, MIPs and > = > >=20 other internal > > > > > =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > = > >=20 > > relationship of the forward and = the=20 backward > > > > directions of that > > = >=20 > > transport path. > > > = >=20 > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > = > is,=20 there is > > > > *nothing* that can be observed = from a=20 black box point of > > view that > > > > = results=20 from adhering to this requirement. > > > > = > >=20 > > Therefore it could be assumed that this requirement is = met by=20 > > > > configuring some data plane database = component=20 through the > > > > management plane. The = database=20 component is not used > for anything > > > = > except=20 to satisfy this requirement for "awareness". > > > = >=20 > > > > Ben! Can we please try to rewrite this=20 requirement in terms of > > > > = behavior? > >=20 > > > > > > > Please note that = Requirement 34=20 is the ONLY item in the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = >=20 > paths are > > > > > exactly the same even = if they=20 appear in two different > > > items in the > = > >=20 > > requirements' list). > > > > > In = other=20 words, without Requirement 34 the notion of > = co-routed >=20 > > > > bidirectional paths would be void of any = data plane=20 content. > > > > > > > > > > = The=20 somewhat vague scope of this requirement ("other internal = > >=20 > > > functions as appropriate") creates a suspicion = that=20 HW > > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with = it. >=20 > > > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > MIPs and other > > = >=20 > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate=20 nodes." > > > > > > > > > The=20 following text in the draft increases this suspicion: > = > >=20 > > > > > > > <quote> > > = >=20 > > Tandem Connection: A tandem connection is = an >=20 > arbitrary part of a > > > > > = transport=20 path that can be monitored (via OAM) > > > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of a=20 transport path. > > The tandem > > > = >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > > > > = > =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = >=20 > Actually, I am quite fed up about this persistent > = >=20 insistence on the > > > > inclusion of "Tandem=20 Connection." The definition within > > the ITU-T = of >=20 > > > this term is poorly specified and comes from = the >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > = >=20 > > > > > > Doesn't "forwarding engine" = sound like=20 hardware to you? > > > > > > > > = Yes, but=20 so what? > > > > > > > > > = IMHO it is=20 worth noting that neither the MPLS-TP > > > = Requirements=20 draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > > > > > > > > = >=20 > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed in=20 the MPLS-TP OAM > > Framework > > > > = >=20 draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-fr >=20 > > > amework-00.txt > > > > ). > = >=20 > > > > > > Right. > > > > = Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some clarity=20 regarding > > > co-routed vs. > > > > = >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 to=20 specific > > > functionality. > > > > = > > > > Agreed. > > > > > = >=20 > > Adrian > > > > > > > > = >=20 > > > > > > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > = Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > Not really = sure=20 whether you are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one of Ben's = messages is that associated > > > > >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will = have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > = > This=20 is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > = >=20 > > a special case of associated bidirectional = LSPs. > >=20 > > > > > > If you can set up two = unidirectional=20 LSPs (e.g. using the > > management > > > = >=20 plane) you can surely set up a co-routed > > > = bidirectional=20 LSP. > > > > > > > > There are = shipping=20 solutions that achieve co-routed > bidirectional > = > >=20 > LSPs using the control plane. These either use the = GMPLS >=20 > (which is > > > > cleaner) or non-standard=20 proprietary solutions (which is > > messy but > = > >=20 > functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are software > > > > = solutions. >=20 > > > > > > = > >=20 2. My reading of one of Neil's messages is that the = actual > >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > = >=20 transport networks rather than any specific benefit. > = > >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, >=20 > > > feel, and behavioral characteristics of a=20 "legacy" > > > > transport network. > > = >=20 > > > > > > Based on these observations, = I'd guess=20 (FWIW) that: > > > > > * associated = bidirectional=20 paths are, at least for the time > > > > > = =20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = >=20 > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other = upgrades to=20 existing MPLS solutions will be > needed to reach > = >=20 > > the full function level of MPLS-TP. > > > = >=20 > > > > > * they had a good chance to remain = the only=20 type of > > bidirectional > > > > > = =20 paths in real deployments. > > > > > = >=20 > > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 _______________________________________________ mpls-tp = mailing=20 list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ----------------------------------------------------= ---- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ________________________________= _______________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp = ------_=_NextPart_001_01C9C447.BE8B7044-- From maarten.vissers@huawei.com Thu Apr 23 12:43:23 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B010828C725 for ; Thu, 23 Apr 2009 12:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[AWL=-1.968, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paVzwa5Iixim for ; Thu, 23 Apr 2009 12:43:18 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id A21F53A728B for ; Thu, 23 Apr 2009 12:40:55 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042312420511225 ; Thu, 23 Apr 2009 12:42:05 -0700 Received: from M00900002 ([10.84.0.8]) by s-utl01-sjpop.stsn.net; Thu, 23 Apr 2009 12:41:56 -0700 From: "Maarten Vissers" To: Date: Thu, 23 Apr 2009 21:41:48 +0200 Message-ID: <005301c9c44b$90e185a0$0800540a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C9C45C.546A55A0" X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 19:43:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0054_01C9C45C.546A55A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin = domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server layer. = AIS suppresses the LOC alarm in those cases so that the maintenance guys = don't get triggered and start looking for a fault that is outside their area. =20 Regards, Maarten =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are concerned = with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* = the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you = think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even when AIS = was being received as the service guys want to know about the alarms. The = normal practice is for the equipment to report the alarms *including* AIS and = then a filter is applied in the management system to suppress alarms to the = fault fixing guys. As I'm aware, there are many different techniques applied = for the filtering algorithms, especially when you consider multiple = concurrent faults in a network, however, the existance of AIS/FDI doesn't add = anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And = if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up = simple time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation you describe is = only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to = fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, maybe = AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there = is no AIS/FDI functions, when there is a defects in a given layer network, = it can cause multiple alarm events to be raised. it is diffcult for = operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so I = think every new functions and things may have positive and negative effects. = but we should consider it very much, don't delete some functions at random.=20 best regards=20 liu=20 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------=_NextPart_000_0054_01C9C45C.546A55A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Andy, > The problem is *not* about a lack of alarm = suppression in=20 the data plane - that information is readily=20 available. I don't = believe that this is=20 a correct statement in a multi-operator transport network, or in = transport=20 networks of one operator that have more then one administrative = subdomain (each=20 with its own network management system). A problem occuring in admin = domain A=20 will be unknown in admin domain B. The loss of continuaity alarms that = are=20 activated in admin domain B due to the fault in admin domain A will = appear as=20 primary alarms, suggesting connectivity problems in admin domain=20 B. > The issue arises=20 because the two sides of maintenance want different things. The fault=20 fixing > guys=20 want to locate the fault and don't want any other information. The = service=20 maintenance > guys=20 want to know whether their customer service is=20 working. This=20 is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means = of the=20 additional SSF alarm. The SSF alarm is for the service guys telling = them=20 that the service was interrupted due to a fault in a server layer. AIS=20 suppresses the LOC alarm in those cases so that the maintenance guys = don't get=20 triggered and start looking for a fault that is outside their=20 area. Regards, Maarten From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn; = neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Liu, Allow me to jump in. You are bringing together = two things=20 which are separate and for which AIS/FDI is no help. Maintenance = operations are=20 concerned with two separate things. 1) Identifying faults in equipment, line = plant, and=20 other systems (eg misconfigurations) and fixing them (equipment=20 maintenance). 2) Identifying the health of end to end = connections,=20 especially when they are directly supporting customer services (service=20 maintenance). The problem is *not* about a lack of alarm = suppression in=20 the data plane - that information is readily available. If, at an end = equipment,=20 I have a good server/section layer and a loss of CC at the client layer, = I=20 *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you=20 think about, if the fault is in the end equipment, it is quite likely = that the=20 fault means it cannot report the traffic loss to the management=20 system!) The issue arises because the two sides of = maintenance want=20 different things. The fault fixing guys want to locate the fault and = don't want=20 any other information. The service maintenance guys want to know whether = their=20 customer service is working. This arose in the early days of SONET/SDH, when = the=20 operations guys demanded that the equipment did *not* suppress the = traffic alarm=20 even when AIS was being received as the service guys want to know about = the=20 alarms. The normal practice is for the equipment to report the = alarms=20 *including* AIS and then a filter is applied in the management = system to=20 suppress alarms to the fault fixing guys. As I'm aware, there are many = different=20 techniques applied for the filtering algorithms, especially when you = consider=20 multiple concurrent faults in a network, however, the existance of = AIS/FDI=20 doesn't add anything to these that's not already known. In fact, I = believe=20 simple time-stamp correlation is one of the most powerful and = widely used=20 techniques. And if the equipment starts messing up the reporting of loss = of CC=20 because it waiting for/persistence checking AIS/FDI, it could end = up=20 messing up simple time-stamp correlation! In practice, it is often not quite a simple as = this, as the=20 service guys like to be able to 'localise' the fault. However, under = most=20 circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter hasn't = worked for=20 some reason. But the bottom line is, whatever operations = process you=20 want to use, AIS/FDI doesn't add anything other than complexity and = fault=20 liability to the equipment. Remember AIS goes back to the TDM world = where=20 you *have to fill the bit stream with something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 Newgate = Street=20 London EC1A 7AJ Registered in England no. 1800000 = This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009 = 09:15 To:=20 Harrison,N,Neil,CXM R Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Neil: thank you for wasting more time in = describling=20 the problems. but I think some of what you said is no relations with = our=20 problem.for me, maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. = but for=20 CO-PS networks.if there is no AIS/FDI functions, when there is a = defects in a=20 given layer network, it can cause multiple alarm events to be raised. = it is=20 diffcult for operators to locate and diagnose the faults. = though I completely agree = you on=20 adding new things and functions will bring some complexity . but = if we=20 have no functions, it is more complex and difcult for operators to = maintence=20 and administrator the network. so I think every new functions and = things may=20 have positive and negative effects. but we should consider it very = much, don't=20 delete some functions at random. best regards liu=20 <neil.2.harrison@bt.com> 2009-04-21 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, If=20 MPLS-TP is going to be taken seriously as a transport network (like = SDH/SONET)=20 then the 2 key MUST HAVE requirements are these. 1=20 Provide a transparent client/server relationship...which=20 means: - =20 all client bits treated equally - client bit ordering = preserved=20 - = no attempt=20 to infer client symbol (ie sequence of client bits) meaning and no = attempt to=20 change client symbols - the traffic behaviour of client X must not = impact the=20 performance experienced by client Y =20 A key = corollary of the=20 above is that MPLS-TP must only support proper connections (ie single = source=20 constructs) 2=20 Since MPLS-TP is a transport network it is not a top-of-stack = network=20 (ie it does not support directly external message/file/stream = applications).=20 MPLS-TP therefore does not require an E-NNI specification. = A key=20 corollary of this is that MPLS-TP will not have any peer interworking=20 relationship with any other network mode/technology. Now wrt OAM MPLS-TP is = a co-ps mode=20 network. You could argue this should have FDI/AIS....however, = the merit=20 of this is highly questionable. When I and colleagues discussed = whether=20 PBB-TE (also a co-ps mode network) should have FDI/AIS we concluded = that on=20 balance it was not a good idea.....and note that initially I was in = favour of=20 having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise. = AIS/FDI is = historically linked to=20 the early PDH co-cs mode layer networks that used TTL logic. = When this=20 died it put out a +5V (all 1s) signal by default, ie it required no = conscious=20 effort to generate it.....this is key point. Further, in these = networks=20 there is a fairly static/long-holding client server relationship.=20 Clearly this is not true in the cl-ps mode and it's why IETF = have never=20 specified AIS for IP and its why IEEE had the good sense to throw-out = AIS in=20 802.1ag for Ethernet (though ITU have unwisely IMO retained it in=20 Y.1731....but I suspect any operator planning to use Ethernet = equipment would=20 always look to IEEE stds and not ITU ones). AIS/FDI and the co-ps mode is debatable. As I noted = above, on=20 balance we considered not a good idea for PBB-TE OAM because it = requires a=20 conscious effort to generate it (unlike the co-cs mode) so there are = likely to=20 be scaling problems and its one more thing to go wrong. = You=20 should also have seen me make the point many times in the past that = the=20 always-on defect detection/handling OAM needs to be as simple/sparse = as=20 possible with as little config as possible because we need super=20 reliability......TCM goes completely against the grain here. = Also note=20 that the OAM required for each of the 3 network modes is not the same, = despite=20 what some claim. regards, Neil = From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009 = 02:59 To:=20 BRUNGARD, DEBORAH A, ATTLABS Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah: maybe what you said is right. but I can't completely = agree your=20 opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. = so it=20 should have AIS/FDI fuctions as SDH/SONET.=20 do you think = so. best = regards liu "BRUNGARD, = DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten = Vissers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with Neil, it = is very=20 questionable the value of AIS/FDI in a packet network- any mode. It = can=20 result in a DoS attack by an operator on themselves so even Y1731=20 recommends not to block data frames: "A MEP can decide whether it = blocks=20 data frames when it detects dAIS. The principle requirement that = influences this decision is that data frames ought to be = forwarded as much=20 as possible, without the possibility of forwarding wrong data = frames=20 downstream." Table I.7-2 shows for AIS, not to block. And as = Y1731=20 states, AIS can only be used under very constrained architectures - = if=20 required for MPLS-TP, it needs to have the same guidance as in = Y1731, i.e.=20 point-to-point and server/client one-to-one: "for a point-to-point = ETH=20 connection, a MEP has only a single peer MEP. Therefore, = there is no=20 ambiguity regarding the peer MEP for which it should = suppress alarms when=20 it receives the ETH-AIS information." So should only be within = one=20 domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten = Vissers Sent:=20 Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements Neil, > but AIS/FDI in the cl = mode?...do=20 me a favour! Ethernet AIS is indeed a requirement and a = necessity. And=20 you will not be able to understand that as long as you refuse to = accept=20 that "cl-mode" is a forwarding mode within a **transport = entity**. G.800=20 amendment 1 has finally reintroduced this transport entity into = G.800.=20 Besides that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is a = transport=20 entity that transfers information belonging to multiple = communications=20 between ports across a subnetwork. <..> In a differentiated=20 connection message contents are interpreted to identify (sets = of)=20 communications which receive different treatment. The sets = of=20 communications may be distinguished by the forwarding identifier or = other=20 layer information. Order is not necessarily preserved = between=20 messages belonging to sets of communications receiving different = treatment.=20 Sets of communications may be identified for purposes such = as=20 traffic conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 = "differentiated=20 connections". Ethernet AIS provides AIS within the scope of such = "differentiated connection". If you apply this to my proposed = PTN layer=20 stack, then the EVC layer topology will consists of EVC links = supported=20 by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro = and core=20 domains interconnecting EVC matrices. When one of those EVC = links is=20 interrupted, e.g. in the core between metro 1 and metro 4 (see = attached=20 slide), then the EVC differentiated connection that is present = on this=20 link will be interrupted. At the EVC switch/bridge node in metro = 4 this=20 interruption is noticed and EVC-AIS is inserted in the downstream = direction=20 to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. The=20 EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which=20 guarantees that the AIS is broadcast to the endpoints of the = EVC. I=20 believe that it is time for you to adapt your view on co and cl=20 modes and relate it to the forwarding mode **INSIDE** a = transport=20 entity. What we know as the internet is essentially an "IP=20 differentiated connection" with a billion or more ports. What we = know as=20 an IP VPN is essentially an "IP differentiated connection" with = e.g. n=20 ports (n in the range of e.g. 2 to 1000). What we know as an = Ethernet VLAN=20 is essentially an "Ethernet differentiated connection" with n = ports (n=20 in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP = is=20 essentially an "MPLS differentiated connection" with 2 = ports. What we=20 know as a p2p SDH VC-n is a "SDH VC-n connection" with 2=20 ports. Transport network OAM applies to transport entities, = which are=20 (in terms of G.800 am1) connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com = [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting a wee = bit=20 tired of folks trying to make all 3 network modes look alike = (and then,=20 even worse, interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). I am = even=20 more frustrated by the fact those peddling this FUD only ever seem = to=20 consider OAM and forget all other DP/CP/MP components (esp = top-of-stack=20 message/file/stream application adaptations). How wrong can = this get!=20 In the co modes a *connection* is a very specific and=20 *constraining* construct.....I am assuming here we respect the = rules of a=20 connection (ie single source) though some folks don't even = bother to=20 respect this, and this is despite the fact that we all know what = problems multiple-source constructs can cause (from LDP/PHP....ergo = MPLS-TP). When we have a connection this restricts *all* DP (ie = traffic=20 and OAM) to stay within the bounds of the connection. = Which is=20 fine under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is broken. = In=20 a nutshell what this means is that OAM that is of a = request/response=20 nature cannot be trusted in co mode networks under misconnectivity=20 defects.....indeed, why should a leaking DP have a symmetric = go/return=20 defect behaviour?....very likely it won't. So whilst = request/response=20 OAM is right for the cl mode it is not right for the co mode = under=20 misconnectivity defect conditions. More generally the 3 modes = are=20 different and not just in OAM requirements....but AIS/FDI in the cl = mode?...do me a favour!...at least IEEE had the good sense to bin = this for=20 Ethernet even though it remains in Y.1731. And which is = why I=20 often trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found it = necessary to=20 create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies = in the=20 physics...and G.800 attempts to explain that physics....G.805 does=20 not. So, the 3 modes are different...please accept/rejoice in = this fact=20 as they all offer something different/important. But do = not be=20 hoodwinked by those who peddle a story that that tries to make = the OAM=20 of the 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > = Sent: 17=20 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten = Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > requirements > >=20 Italo, > > As described in the MPLS TP OAM Requirements = I-D,=20 virtually all of the > OAM functions require a return path, = and in=20 the absence of a return > path they are disabled. > = > As=20 described in David Sinicrope's meeting minutes >=20 (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > = meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP = addressing=20 is used, an > MPLS TP network needs to be capable of getting IP = packets=20 from > destination to source; neither the minutes nor I = stipulate that=20 a > control plane needs to be used to instantiate this=20 forwarding. > > As an aside, the issue of return path for = unidirectional LSPs could be > charaterized as the elephant = in the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs = are only=20 mentioned three times and return > paths not at all. > = >=20 Thanks, > > John > > -----Original = Message----- >=20 > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > = > Sent:=20 Friday, April 17, 2009 1:59 AM > > To: Drake, John E; = Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > = >=20 Subject: RE: [mpls-tp] Associated bidirectional transport path = > >=20 requirements > > > > John, > > > = > I=20 might have missed the agreement of MPLS-TP being capable of > = >=20 sending replies to OAM requests sent on uni-directional LSPs. > = >=20 > > This requirement does not belong to the first set of=20 requirements > > ITU-T is expecting to be met by = October. >=20 > > > However, I think this in a potential interesting = additional=20 > > requirement to be taken into account (at worst in = a >=20 subsequent phase). > > > > I think that this = requirement=20 needs to be evaluated versus other > > more important = requirements=20 (e.g. the possibility to work w/o IP > > forwarding and the = need for=20 OAM to continue to monitor the data > > plane also in case = of=20 failures affecting the control or management > > = plane). >=20 > > > I am open to discuss it but not sure this is the = right time=20 because > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = > >=20 > -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of Drake, John E > > > Sent: Thursday, April 16, = 2009=20 8:00 PM > > > To: Alexander Vainshtein; Maarten = Vissers >=20 > > Cc: mpls-tp@ietf.org > > > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > > >=20 requirements > > > > > > At the meeting last = fall at=20 Juniper in Massachusetts, I > > think it was > > = > agreed=20 that an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM packets = (e.g.,=20 sending > > replies to OAM > > > requests sent on = uni-directional LSPs) even if it does not > > have an = IP > >=20 > forwarding data plane. > > > > > > >=20 -----Original Message----- > > > > From: Alexander=20 Vainshtein > > > = [mailto:Alexander.Vainshtein@ecitele.com] >=20 > > > Sent: Thursday, April 16, 2009 9:57 AM > > = > >=20 To: Maarten Vissers > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > > = > >=20 > Maarten, > > > > It seems that you've just = (implicitly=20 and, probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will not ever = support MIP=20 loopback function > > (and fault > > > > = localization=20 which requires this function ) for > > unidirectional = P2MP >=20 > > > and P2P paths. > > > > > > = > >=20 If this statement is correct, this (IMHO and FWIW) > raises a=20 valid > > > > question: > > > > > = >=20 > > = Is=20 MPLS-TP an appropriate solution for these > types of = transport >=20 > > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > functionality=20 today > > > > for (unidirectional - but it does not = know any=20 other > > type) P2P LSPs > > > > as described = in RFC=20 4379. And its extension to P2MP LSPs seems > > > >=20 easy... > > > > > > > > > = >=20 > > > > > > Regards, > > > > = >=20 > > > Sasha > > > > = > >=20 > > > > > > > > > >=20 ________________________________________ > > > > From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: Thursday, = April 16,=20 2009 3:24 PM > > > > To: 'Adrian Farrel' > > = > >=20 Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > > = requirements > >=20 > > > > > > Adrian, > > > > = > >=20 > > >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > > = > >=20 other internal > > > > >> = functions=20 as appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> path at = each=20 (sub-)layer MUST be aware of the pairing > > > > = >>=20 relationship of the forward and the = backward > >=20 > > directions of that > > > > >> = =20 transport path. > > > > >> <end=20 quote> > > > > > > > > > > = There is no=20 way this is a functional requirement. That > > > is, there = is > > > > > *nothing* that can be observed from a = black box=20 point of > > > view that > > > > > = results from=20 adhering to this requirement. > > > > > > = > >=20 Your understanding is not correct. It is very much > observable=20 if > > > > this requirement is met from a black box = point of=20 view. > > > > The MIP functions can only perform the = Loopback=20 when there is a > > > > co-routed bidirectional = transport=20 path. The MPLS-TP LBM packet > > > > received at a MIP = needs=20 to be returned (as LBR > > > > packet) to the = originating MEP=20 function via the other > > direction of > > > = > the=20 co-routed bidirectional transport path. This other > = direction >=20 > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > = > >=20 would fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, then > = >=20 > > this is possible in a co-routed bidir transport path > = but not=20 in a > > > > associated bidir transport path. In the = first case=20 the TCM MEP > > > > Source and Sink functions are = co-located=20 and can > exchange what is > > > > called "remote = information" which is necessary for performance > > > = >=20 monitoring. > > > > In the latter case the TCM MEP = Source and=20 Sink functions > > are in e.g. > > > > = different=20 nodes in the network and TCM would not be able > > to = provide >=20 > > > performance monitoring. > > > > > = >=20 > > > The entirety of the bracketted text "(including = MEPs, >=20 > > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does = not >=20 > > > add to "The > > > > > intermediate=20 nodes." > > > > > > > > Your = understanding is=20 not correct. This text must not be > > deleted at > = > >=20 > all. > > > > > > > > > = Actually, I am=20 quite fed up about this persistent > > > insistence on = the >=20 > > > inclusion > > > > > of "Tandem = Connection."=20 The definition within the ITU-T of > > > > this = term >=20 > > > > is > > > > poorly > > > = >=20 > specified and comes from the monitoring of a path that is > = >=20 > > parallel (i.e. > > > > tandem) > > = > >=20 > to the data path being monitored. This definition of TC > = > >=20 > seems to be at > > > > variance, > > > = >=20 > and would be if the ACH was actually in band. > > > = >=20 > > > > I don't understand where your interpretation = of=20 tandem > > connection is > > > > described in = ITU-T=20 recommendations. I.e. "from the > > monitoring of a > = > >=20 > path that is parallel (i.e. tandem) to the data path being = > >=20 > > monitored."? > > > > > > > > = There is=20 a "network connection" and this network > > connection is a=20 set > > > > of interconnected "link connections" and=20 "matrix > connections". A > > > > subset of those = interconnected link connections and matrix > > > > = connections=20 can be monitored and is then referred to as > a "tandem > = >=20 > > connection". There is no "path that is parallel to = the > >=20 data path". > > > > There is only additional OAM = inserted=20 inside the data > path by the > > > > TCM MEP_So = function=20 and this OAM is extracted from the > > data path by > = > >=20 > the TCM MEP_Sk function. > > > > > > = > >=20 Regards, > > > > Maarten > > > > = > >=20 > > > > > > -----Original Message----- > = > >=20 > From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > = > >=20 > Sent: donderdag 16 april 2009 11:59 > > > > To: = Alexander=20 Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: = BUSI=20 ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi = Sasha, >=20 > > > > > > > > Unfortunately I cannot = fully agree=20 with your statement: > > > > > > > > = > >=20 <quote> > > > > > From the point = of view=20 of hardware, co-routed > > > bidirectional LSPs > = > >=20 > > are a special case of associated bidirectional = LSPs. > > > > > <end quote> > > > = >=20 > > > > > > This statement would be obviously = correct,=20 were it not for > > > > Requirement > > > = > >=20 34 in the latest MPLS-TP requirements draft > > > > = >=20 > > > OK. Got it. > > > > > > > = > But=20 what is this doing in the data plane requirements section? > = > >=20 > > > > > In fact, what is this requirement = actually=20 saying? > > > > > > > > >=20 <quote> > > > > > The = intermediate=20 nodes (including MEPs, MIPs and > > > other = internal > >=20 > > > functions as appropriate) of a=20 co-routed > > > > bidirectional transport > > = >=20 > > path at each (sub-)layer MUST be aware = of the=20 pairing > > > > > relationship = of the=20 forward and the backward > > > > directions of = that >=20 > > > > transport path. > > = >=20 > > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > > = is, there=20 is > > > > *nothing* that can be observed from a black = box=20 point of > > view that > > > > results from = adhering=20 to this requirement. > > > > > > > > = Therefore=20 it could be assumed that this requirement is met by > > > = >=20 configuring some data plane database component through the > = > >=20 > management plane. The database component is not used > for=20 anything > > > > except to satisfy this requirement for = "awareness". > > > > > > > > Ben! Can = we please=20 try to rewrite this requirement in terms of > > > >=20 behavior? > > > > > > > > > Please = note that=20 Requirement 34 is the ONLY item in the > > > > list = that=20 is > > > > > specific for co-routed bidirectional = LSPs. (The=20 pairing > > > > requirements > > > > = > at end=20 points for co-routed and associated bidirectional > > > = paths=20 are > > > > > exactly the same even if they appear = in two=20 different > > > items in the > > > > >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > > = >=20 bidirectional paths would be void of any data plane content. > = > >=20 > > > > > > > The somewhat vague scope of this = requirement ("other internal > > > > > functions as = appropriate") creates a suspicion that HW > > > > = support of=20 the > > > > > pairing awareness may be required in = order to=20 comply with it. > > > > > > > > The = entirety of=20 the bracketted text "(including MEPs, > > MIPs and = other > >=20 > > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate = nodes." >=20 > > > > > > > > The following text in the = draft=20 increases this suspicion: > > > > > > > = > >=20 > <quote> > > > > > Tandem = Connection: A=20 tandem connection is an > > arbitrary part of a > > = >=20 > > transport path that can be monitored (via = OAM) > >=20 > > independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > segment or=20 a > > > > > monitored concatenated segment of = a=20 transport path. > > The tandem > > > > = >=20 connection may also include the forwarding engine(s) of > = >=20 > > the node(s) > > > > > at the = edge(s) of the=20 segment or concatenated segment. > > > > > <end=20 quote> > > > > > > > > Actually, I = am quite=20 fed up about this persistent > > insistence on the > = > >=20 > inclusion of "Tandem Connection." The definition within > = > the=20 ITU-T of > > > > this term is poorly specified and = comes from=20 the > monitoring of a > > > > path that is = parallel (i.e.=20 tandem) to the data path being > > > > monitored. This = definition of TC seems to be at variance, > > and = would > >=20 > > be if the ACH was actually in band. > > > > = >=20 > > > > Doesn't "forwarding engine" sound like hardware to = you? > > > > > > > > Yes, but so = what? >=20 > > > > > > > > IMHO it is worth noting = that=20 neither the MPLS-TP > > > Requirements draft > > = >=20 > > nor the MPLS-TP OAM requirements one > > > > = >=20 > > > > > > > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing with=20 tandem > > > connections. > > > > = > > >=20 > > > But tandem connections are discussed in the MPLS-TP = OAM >=20 > Framework > > > > > draft > > > = >=20 (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > = >=20 > > amework-00.txt > > > > ). > > > = >=20 > > > > Right. > > > > Let's just get = rid of an=20 unnecessary term and bring all > the I-Ds > > > > = into=20 line. > > > > > > > > > The bottom = line,=20 IMHO, is that some clarity regarding > > > co-routed = vs. >=20 > > > > associated > > > > > = bidirectional paths=20 is still required. One way to provide > > > > that=20 could > > > > > be by explicitly limiting = Requirement 34 to=20 specific > > > functionality. > > > > = > >=20 > > Agreed. > > > > > > > >=20 Adrian > > > > > > > > > > = > >=20 > > > > > > > >=20 ________________________________________ > > > > From: = Adrian=20 Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, = April 16,=20 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou = Berger;=20 BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = > >=20 > > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > Not really sure = whether=20 you are misrepresenting anyone, but... > > > > > = >=20 > > > 1. My reading of one of Ben's messages is = that=20 associated > > > > > bidirectional paths are the = only types=20 of paths that can be > > > > created in > > = > >=20 > the existing networks; "true" co-routed bidirectional = paths > >=20 > > will have > > > > > to wait until (if = ever) new=20 equipment becomes available. > > > > > > > = >=20 This is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > > = > >=20 a special case of associated bidirectional LSPs. > > > = >=20 > > > > If you can set up two unidirectional LSPs = (e.g. using=20 the > > management > > > > plane) you can = surely set=20 up a co-routed > > > bidirectional LSP. > > > = >=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using the = control=20 plane. These either use the GMPLS > > (which is > > = >=20 > cleaner) or non-standard proprietary solutions (which is > = >=20 messy but > > > > functional). > > > > = >=20 > > > But (of course) the management plane or control = plane >=20 > solutions have > > > > nothing to do with = availability of=20 equipment as they > are = software >=20 > > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the actual > = > >=20 > driver for > > > > > co-routed bidirectional = paths may=20 be experience with existing > > > > > transport = networks=20 rather than any specific benefit. > > > > > > = >=20 > Isn't that the case with 75% of the MPLS-TP requirements? > = >=20 > > Which is not to say it is a bad thing. > > > = >=20 > > > > A large driver for MPLS-TP is to give the = packet=20 network > > the look, > > > > feel, and = behavioral=20 characteristics of a "legacy" > > > > transport=20 network. > > > > > > > > > Based on = these=20 observations, I'd guess (FWIW) that: > > > > > * = associated=20 bidirectional paths are, at least for the time > > > > = >=20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = > >=20 > > I think that is wrong both given my statement above, = and >=20 > given that > > > > other upgrades to existing MPLS = solutions will be > needed to reach > > > > the = full=20 function level of MPLS-TP. > > > > > > > = > >=20 * they had a good chance to remain the only type of > >=20 bidirectional > > > > > paths in real=20 deployments. > > > > > > > > I don't = see what=20 that follows from. > > > > > > > >=20 Cheers, > > > > Adrian > > > > > = >=20 > > _______________________________________________ > > = >=20 > mpls-tp mailing list > > > > = mpls-tp@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > = > >=20 > > > >=20 _______________________________________________ > > > > = mpls-tp=20 mailing list > > > > mpls-tp@ietf.org > > > = >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > > = >=20 > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = > >=20 > _______________________________________________ > = mpls-tp=20 mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing = = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this mail is = solely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy = and are=20 not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender. This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------=_NextPart_000_0054_01C9C45C.546A55A0-- From benjamin.niven-jenkins@bt.com Thu Apr 23 15:12:19 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870093A6E24 for ; Thu, 23 Apr 2009 15:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAYbs1ierMM3 for ; Thu, 23 Apr 2009 15:12:18 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 26AC53A68E5 for ; Thu, 23 Apr 2009 15:12:17 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 23:13:33 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Apr 2009 22:13:33 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 23 Apr 2009 23:13:31 +0100 From: Ben Niven-Jenkins To: Message-ID: Thread-Topic: We appear to be going around in circles (Re: [mpls-tp] Associated bidirectional transport path requirements) Thread-Index: AcnEYLwwpSRuv4zbdUCO9uPM0MsD/g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 23 Apr 2009 22:13:33.0813 (UTC) FILETIME=[BDDE3250:01C9C460] Subject: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 22:12:19 -0000 Colleagues, The current debates appear to be going around in circles and achieving nothing of value IMO. Two major operators have expressed their opinions and no operator that I can see has disagreed with those opinions. I apologise for being direct (and possibly rude) but I am getting tired of being told by folks who do not represent operators what functionality I nee= d or should have in my networks. To put some context on BT's comments in these threads: I have the largest MPLS network in the UK. I have one of the largest MPLS networks globally delivering service to 173 countries with over 200 000 customer ports I have (off the top of my head) at least another 10 MPLS networks in specific countries covering at least 3 continents delivering dedicated services to particular market segments. I have an extremely large SDH network in the UK consisting of over 30 000 switches and supporting in excess of 1 million circuits. I have an extremely large SDH network globally delivering service in 110 countries. I would like to think my BT colleagues and I might know a little something about building large scale networks and the requirements of those networks and the needs of the customers that I deliver services to. Can we please stop these circular arguments which are IMO going nowhere and focus on the task in hand which is defining the requirements (and later solutions) being asked for by myself, my company and my colleagues in other operators on this list. Thanks Ben --=20 Ben Niven-Jenkins IP, Data & Content Architect Network Infrastructure Architecture, BT =20 E-mail: benjamin.niven-jenkins@bt.com Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 British Telecommunications plc. Registered office: 81 Newgate Street Londo= n EC1A 7AJ Registered in England no: 1800000 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" wrote: > ben: > I understand your meaning, you still wish to resign and make a more > reliable and effective, easy to operator and easy to manage packet > transport network like me. but why not apply this SDH/SONET in the future > maybe the following cause: > 1 it adopted circuit switching techonogy to bring lower useful of the > resource than PTN network; > 2 it can't bear all kinds of traffics like PTN networks > it noted that we can't apply SDH/SONET network in the future not because > it have a complex OAM functions. while more people like to move the > advantages of the OAM functions in SDH/SONET to PTN networks. and AIS/FD= I > function is a kind of OAM functions of SDH/SONET . we should use and > extend the AIS/FDI functions to MPLS-TP ; >=20 > best regards > liu >=20 >=20 >=20 > Ben Niven-Jenkins > 2009-04-23 07:58 >=20 > =CA=D5=BC=FE=C8=CB > , "BRUNGARD, DEBORAH A, ATTLABS" > > =B3=AD=CB=CD > > =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidirectional transport path requirements >=20 >=20 >=20 >=20 >=20 >=20 > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > wrote: >=20 >> Deborah: >> maybe what you said is right. but I can't completely agree your > opinions. >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it should >> have AIS/FDI fuctions as SDH/SONET. >>=20 >> do you think so. >=20 > No we must assess the requirements for packet transport networks > supporting > the needs of operators today and in the future. We must not blindly > recreate > SDH/SONET. If we do so without consideration to how operators' needs and > requirements may have evolved (and continue to evolve in future) we will > have failed IMO and I would severely question the value of the work we > will > have produced. If we just recreate SDH/SONET then what is the purpose of > the > work an operator would be better off just deploying existing SDH/SONET > equipment. >=20 >=20 > Ben >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d are > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. From maarten.vissers@huawei.com Thu Apr 23 15:47:16 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79AAF3A68E5 for ; Thu, 23 Apr 2009 15:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBqPlSzBdDRz for ; Thu, 23 Apr 2009 15:47:15 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id 7BAEB3A67D4 for ; Thu, 23 Apr 2009 15:47:15 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042315482611725 ; Thu, 23 Apr 2009 15:48:26 -0700 Received: from M00900002 ([10.84.0.8]) by s-utl01-sjpop.stsn.net; Thu, 23 Apr 2009 15:48:25 -0700 From: "Maarten Vissers" To: "'Ben Niven-Jenkins'" , Date: Fri, 24 Apr 2009 00:48:17 +0200 Message-ID: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnEYLwwpSRuv4zbdUCO9uPM0MsD/gAAReig Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 22:47:16 -0000 Ben, Your company is one of the many operators in the world, and the number = of nodes outside your network is factors larger then the number of nodes = inside your network. My experience is that different operators have different = sets of requirements. Manufacturers have to support the superset of those requirements. Each operator will then deploy the subset of provided = features that fits its needs (and turn off or don't use the others). Your company = for some years has been asking for less, other operators have been asking = for more. Manufacturers thus build their products with lots of = configurability to support all variations.=20 It is my opinion that we should not remove well established features = like AIS, TCM, frame loss counting, delay measurement, loopback, etc before = the majority of operators have agreed that such features are not longer necessary. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Ben Niven-Jenkins Sent: vrijdag 24 april 2009 0:14 To: mpls-tp@ietf.org Subject: [mpls-tp] We appear to be going around in circles (Re: = Associated bidirectional transport path requirements) Colleagues, The current debates appear to be going around in circles and achieving nothing of value IMO. Two major operators have expressed their opinions = and no operator that I can see has disagreed with those opinions. I apologise for being direct (and possibly rude) but I am getting tired = of being told by folks who do not represent operators what functionality I = need or should have in my networks. To put some context on BT's comments in these threads: I have the largest MPLS network in the UK. I have one of the largest MPLS networks globally delivering service to = 173 countries with over 200 000 customer ports I have (off the top of my = head) at least another 10 MPLS networks in specific countries covering at = least 3 continents delivering dedicated services to particular market segments. I have an extremely large SDH network in the UK consisting of over 30 = 000 switches and supporting in excess of 1 million circuits. I have an extremely large SDH network globally delivering service in 110 countries. I would like to think my BT colleagues and I might know a little = something about building large scale networks and the requirements of those = networks and the needs of the customers that I deliver services to. Can we please stop these circular arguments which are IMO going nowhere = and focus on the task in hand which is defining the requirements (and later solutions) being asked for by myself, my company and my colleagues in = other operators on this list. Thanks Ben --=20 Ben Niven-Jenkins IP, Data & Content Architect Network Infrastructure Architecture, BT =20 E-mail: benjamin.niven-jenkins@bt.com Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 British Telecommunications plc. Registered office: 81 Newgate Street = London EC1A 7AJ Registered in England no: 1800000 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" = wrote: > ben: > I understand your meaning, you still wish to resign and make a more=20 > reliable and effective, easy to operator and easy to manage packet=20 > transport network like me. but why not apply this SDH/SONET in the=20 > future maybe the following cause: > 1 it adopted circuit switching techonogy to bring lower useful of=20 > the resource than PTN network; > 2 it can't bear all kinds of traffics like PTN networks it noted=20 > that we can't apply SDH/SONET network in the future not because it=20 > have a complex OAM functions. while more people like to move the=20 > advantages of the OAM functions in SDH/SONET to PTN networks. and=20 > AIS/FDI function is a kind of OAM functions of SDH/SONET . we should=20 > use and extend the AIS/FDI functions to MPLS-TP ; >=20 > best regards > liu >=20 >=20 >=20 > Ben Niven-Jenkins > 2009-04-23 07:58 >=20 > =CA=D5=BC=FE=C8=CB > , "BRUNGARD, DEBORAH A, ATTLABS" > > =B3=AD=CB=CD > > =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidirectional transport path requirements >=20 >=20 >=20 >=20 >=20 >=20 > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > wrote: >=20 >> Deborah: >> maybe what you said is right. but I can't completely agree your > opinions. >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it=20 >> should have AIS/FDI fuctions as SDH/SONET. >>=20 >> do you think so. >=20 > No we must assess the requirements for packet transport networks=20 > supporting the needs of operators today and in the future. We must not = > blindly recreate SDH/SONET. If we do so without consideration to how=20 > operators' needs and requirements may have evolved (and continue to=20 > evolve in future) we will have failed IMO and I would severely=20 > question the value of the work we will have produced. If we just=20 > recreate SDH/SONET then what is the purpose of the work an operator=20 > would be better off just deploying existing SDH/SONET equipment. >=20 >=20 > Ben >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this=20 > mail is solely property of the sender's organization. This mail=20 > communication is confidential. Recipients named above are obligated to = > maintain secrecy and are not permitted to disclose the contents of = this communication to others. > This email and any files transmitted with it are confidential and=20 > intended solely for the use of the individual or entity to whom they=20 > are addressed. If you have received this email in error please notify=20 > the originator of the message. Any views expressed in this message are = > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Thu Apr 23 15:58:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3590A3A6D29 for ; Thu, 23 Apr 2009 15:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK9kkjcG2aeb for ; Thu, 23 Apr 2009 15:58:05 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id A14383A69F2 for ; Thu, 23 Apr 2009 15:58:05 -0700 (PDT) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009042315592111755 ; Thu, 23 Apr 2009 15:59:21 -0700 Received: from M00900002 ([10.84.0.8]) by s-utl01-sjpop.stsn.net; Thu, 23 Apr 2009 15:59:09 -0700 From: "Maarten Vissers" To: "'David Allan'" Date: Fri, 24 Apr 2009 00:59:02 +0200 Message-ID: <001a01c9c467$1e98dd60$0800540a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C9C477.E221AD60" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <87AC5F88F03E6249AEA68D40BD3E00BE193A8507@zcarhxm2.corp.nortel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnDqIM1poMBpMA1QHCY51t7wHwYNwABL+4gACZIuOAABPYHQA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 22:58:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C9C477.E221AD60 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Dave, =20 See inline... _____ =20 From: David Allan [mailto:dallan@nortel.com]=20 Sent: donderdag 23 april 2009 21:15 To: Maarten Vissers; Greg Mirsky Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Hi Maarten: =20 A couple of questions on these charts simply before these examples be considered gospel...from a BBF TR101 perspective....=20 =20 [mv] Thanks for adding this perspective..=20 =20 1) You are suggesting broadcast domains on the RMP constructs of up to = 80000 end points?=20 =20 [mv] yes, this is what I got when I connected 200 subscribers which are behind 100 VDSL2/Fiber DSLAMs and behind a bridging home gateway with a service edge router for e.g. VoIP service (each subscriber has 4 = phones). It is a large number, but from a bandwidth perspective (voice) it = presumably could be handled. I expect that in practice there are some other limitations. Furthermore the subscribers are supported typically by more then one ISP, so the number of home gateways and/or end terminal devices = per ISP EVC will be lower then this maximum. =20 2) You do not seem to be extending S-tag, and hence EVP, from DSLAM to Service router... why? This does not seem to correspond to current practice...=20 =20 [mv] I was told that this is because the service edge routers could only handle a single VLAN Tag. Newer service edge nodes will be able to = handle two VLAN Tags (i.e. C and S Tag). Same for DSLAMs. Still the presence of = two VLAN Tags on the interfaces between DSLAM and metro edge node and = service edge and wholesale access nodes will not result in extending the EVP. It will only allow more then 4k EVCs to be present on those interfaces, = which could be important for business services (which have a dedicated EVC). =20 Regards, Maarten =20 thanks Dave =20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Maarten Vissers Sent: Thursday, April 23, 2009 8:35 AM To: 'Greg Mirsky' Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Greg, =20 The reason I have placed UNIs also as peers of the EVC is because many operators provide this type of service today.=20 E.g. when a packet transport network provides interconnection between an ISPs service edge router to a group of DSLAMs, then the service edge = router of such ISP is connected to the PTN of the network operator via a = rooted-mp EVC that has an endpoint in the service edge router and in the group of DSLAMs (case of ATM DSLAMs). With the introduction of VDSL2 and fiber = DSLAMs into the network, the EVC endpoints will be in the home gateways or in = the end-user terminal equipment (STB, PC, VoIP telephone, ...). I have illustrated these three cases in the attached slides 1 to 3. Slides 4 to = 6 illustrate some examples of EVC maintenance entity groups that could be defined for those three cases.=20 =20 Another case is carrier-carrier services. Carrier A wants to = interconnect with a number of remote network termination devices which are located = behind the network of a regional carrier B. E.g. 10 NT devices, each connected = with a fast ethernet interface to carrier B network. Carrier A network = connects via 1GE interface to carrier B network. Two scenarios are now possible: =20 1) each fast ethernet interface carries a single VLAN service, which is carried as an E ging n VC through the network of carrier B towards the interface with carrier A. At this interface the 10 EVCs are multiplexed = onto the 1GE interface. The EVCs are now commonly owned by carrier A and B, = and possibly by the customer. Carrier B monitors those 10 EVCs via a TCM MEG level. =20 2) each fast ethernet interface carries a number of VLAN services, each identified by a C-Tag. This group of services is treated as a port based service in the network of carrier B. This port based service (section = VLAN (EVS)) is treated as EVC in carrier B's network and often identified by means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 EVSs of the customers) are multiplex into the 1GE interface and delivered to carrier = A's Virtual UNI-N port. Carrier A's V-UNI-N port treats those 10 EVCs of = carrier B as 10 EVPs, each EVP carrying multiple EVC signals. Each carrier A EVC signal is traffic conditioned, and gets EVC OAM in the EVC TCM MEP = functions located in this V-UNI-N port card. - The EVCs in carrier B's network have their endpoints in customer edge equipment and in the V-UNI-N port of carrier A. For the customer this is = an EVS endpoint, while for the carrier A this is an EVP endpoint. Carrier = B's EVC peers as such with carrier A and customer for this EVC and carrier B will monitor its EVC via a TCM MEG level. - The EVCs in carrier A network have their endpoints in the customer = network (e.g. customer edge equipments). Carrier A deploys a TCM MEG level to monitor this service.=20 =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: donderdag 23 april 2009 2:15 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I agree with your presentation of layers but only wonder why you've = placed UNIs both as clients of EVC layer as well as its peers. I'd leave UNIs = only as clients of EVC layer. Would you agree? Regards, Greg 2009/4/22 Maarten Vissers Dear Greg, =20 Thank you for this confirmation.=20 This other layer is that the EVC layer as illustrated in the figure = below? =20 UNI UNI --||------- ---------||----- | | UNI ------------------------------------------------- UNI --||----| EVC layer |-----||----- ------------------------------------------------- | MPLS-TP layer | | other layer | ----------------- ---------------- =20 MEF's E-Tree is a bidirectional rooted-multipoint connection, in which frames are forwarded on the basis of the value in their DA field. Such selective forwarding is not supported in an LSP connection. An LSP connection will as such just support one EVC link connection, i.e. a = part of the EVC between two adjacent EVC switch/bridge functions. Those p2p EVC = link connections simply require non-selective forwarding, something that an = LSP connection can provide. =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00=20 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I think you've captured my view pretty accurately. Since MPLS-TP = supports only p2p and p2mp transports it would be responsibility of another layer = to support specific services among UNI-Ns. Interesting thing that E-Tree = can not be directly mapped to p2mp unidirectional MPLS-TP LSP since by MEF's definition E-Tree is a bidirectional service. (Just a note). Kind regards, Greg 2009/4/22 Maarten Vissers Dear Greg, =20 Do you mean that there is a layer network above MPLS-TP that will = support these services from UNI-N port to UNI-N port, and that MPLS-TP will = support this service layer network? =20 Regards, Maarten _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Dear Maarten, I believe that it is not a requirement for MPLS-TP to support any = specific service, including ones you've listed in your message. On the other = hand, support of listed services is a requirement for a client layer that uses MPLS-TP services. Regards, Greg Mirsky 2009/4/22 Maarten Vissers Neil, =20 I expect that the main requirement for a packet transport network = technology like MPLS-TP is that it is able to support at least the following = services: - E-Line - E-Tree - E-LAN - PDH CES in a traffic engineered and managed manner. =20 Another main requirement is that it must be able to support those = services in a scalable manner between points anywhere in the world. =20 The E-Line, E-Tree and E-LAN services allow to reorder client frames = that belong to different priorities and to drop client frames that are drop eligible. =20 The E-Tree and E-LAN services require that client bits are read to = deliver the frames to the appropriate output port or ports of the E-Tree or = E-LAN supporting transport entity/differentiated connection. =20 The packet transport network technology must as such support traffic engineered transport entities (differentiated connections) with n input ports (i.e. multi source constructs). This in addition of traffic = engineered transport entities with 1 input port. =20 Regards, Maarten _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: dinsdag 21 april 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these. =20 1 Provide a transparent client/server relationship...which means: - all client bits treated equally - client bit ordering preserved - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols - the traffic behaviour of client X must not impact the performance experienced by client Y =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs) =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology. =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise. =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones). =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong. =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim. =20 regards, Neil =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , =B3=AD=CB=CD mpls-tp@ietf.org =09 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ------=_NextPart_000_001B_01C9C477.E221AD60 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Dave, See inline... From: David Allan = [mailto:dallan@nortel.com]=20 Sent: donderdag 23 april 2009 21:15 To: Maarten = Vissers;=20 Greg Mirsky Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path = requirements Hi=20 Maarten: A couple of questions on these charts simply before these = examples=20 be considered gospel...from a BBF TR101 perspective.... [mv] Thanks for adding this=20 perspective.. 1) You are suggesting broadcast domains on the RMP constructs = of up to=20 80000 end points? [mv] yes, this is what I = got when I=20 connected 200 subscribers which are behind 100 VDSL2/Fiber DSLAMs = and=20 behind a bridging home gateway with a service edge router for e.g. VoIP = service=20 (each subscriber has 4 phones). It is a large number, but from a = bandwidth=20 perspective (voice) it presumably could be handled. I expect that in = practice=20 there are some other limitations. Furthermore the subscribers are = supported=20 typically by more then one ISP, so the number of home gateways and/or = end=20 terminal devices per ISP EVC will be lower then this=20 maximum. 2) You do not seem to be extending S-tag, and hence EVP, from = DSLAM to=20 Service router... why? This does not seem to correspond to current=20 practice... [mv] I was told that this is = because the=20 service edge routers could only handle a single VLAN Tag. Newer = service=20 edge nodes will be able to handle two VLAN Tags (i.e. C and S Tag). Same = for=20 DSLAMs. Still the presence of two VLAN Tags on the interfaces between = DSLAM and=20 metro edge node and service edge and wholesale access nodes will not = result in=20 extending the EVP. It will only allow more then 4k EVCs to be = present on=20 those interfaces, which could be important for business services (which = have a=20 dedicated EVC). Regards, Maarten thanks Dave From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Thursday, April 23, 2009 8:35 AM To: = 'Greg=20 Mirsky' Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path = requirements Dear Greg, The reason I have placed UNIs also as peers of = the EVC is=20 because many operators provide this type of service today. = E.g. when a packet transport network provides=20 interconnection between an ISPs service edge router to a group of = DSLAMs, then=20 the service edge router of such ISP is connected to the PTN of the = network=20 operator via a rooted-mp EVC that has an endpoint in the service = edge=20 router and in the group of DSLAMs (case of ATM DSLAMs). With the=20 introduction of VDSL2 and fiber DSLAMs into the network, the EVC = endpoints will=20 be in the home gateways or in the end-user terminal equipment (STB, PC, = VoIP=20 telephone, ...). I have illustrated these three cases in the = attached=20 slides 1 to 3. Slides 4 to 6 illustrate some examples of EVC = maintenance=20 entity groups that could be defined for those three=20 cases. Another case is carrier-carrier services. = Carrier A wants=20 to interconnect with a number of remote network termination devices = which=20 are located behind the network of a regional carrier B. E.g. 10 NT = devices, each=20 connected with a fast ethernet interface to carrier B network. Carrier A = network=20 connects via 1GE interface to carrier B network. Two scenarios are now=20 possible: 1) each fast ethernet interface carries a = single VLAN=20 service, which is carried as an E ging=20 n VC through the network of carrier B towards the interface = with=20 carrier A. At this interface the 10 EVCs are multiplexed onto the 1GE = interface.=20 The EVCs are now commonly owned by carrier A and B, and possibly by the=20 customer. Carrier B monitors those 10 EVCs via a TCM MEG=20 level. 2) each fast ethernet interface carries a = number of VLAN=20 services, each identified by a C-Tag. This group of services is treated = as a=20 port based service in the network of carrier B. This port based service = (section=20 VLAN (EVS)) is treated as EVC in carrier B's network and often = identified by=20 means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 EVSs of the = customers)=20 are multiplex into the 1GE interface and delivered to carrier A's = Virtual UNI-N=20 port. Carrier A's V-UNI-N port treats those 10 EVCs of carrier B as 10 = EVPs,=20 each EVP carrying multiple EVC signals. Each carrier A EVC signal is = traffic=20 conditioned, and gets EVC OAM in the EVC TCM MEP functions located in = this=20 V-UNI-N port card. - The EVCs in carrier B's network have their = endpoints in=20 customer edge equipment and in the V-UNI-N port of carrier A. For the = customer=20 this is an EVS endpoint, while for the carrier A this is an EVP = endpoint.=20 Carrier B's EVC peers as such with carrier A and customer for this = EVC and=20 carrier B will monitor its EVC via a TCM MEG level. - The EVCs in carrier A network have their = endpoints in the=20 customer network (e.g. customer edge equipments). Carrier A deploys a = TCM MEG=20 level to monitor this service. Regards, Maarten From: Greg Mirsky = [mailto:gregimirsky@gmail.com]=20 Sent: donderdag 23 april 2009 2:15 To: Maarten=20 Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path = requirements Dear Maarten, I agree with your presentation of layers but = only=20 wonder why you've placed UNIs both as clients of EVC layer as well as = its peers.=20 I'd leave UNIs only as clients of EVC layer. Would you=20 agree? Regards, Greg 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com= > Dear=20 Greg, Thank you=20 for this confirmation. This other=20 layer is that the EVC layer as illustrated in the figure=20 below? =20 = UNI           &nbs= p;            = ;            =             &= nbsp;       =20 UNI --||-------         = ;            =             &= nbsp;     =20    ---------||-----          =20 = |            =             &= nbsp;           &n= bsp;  =20    | UNI  =20 -------------------------------------------------   =20 UNI --||----|         &= nbsp;      =20 EVC=20 = layer           &n= bsp;        =20 |-----||-----        =20 -------------------------------------------------           &nbs= p;  | MPLS-TP=20 layer |    |  other layer = |           &nbs= p;  -----------------   =20 ---------------- MEF's=20 E-Tree is a bidirectional rooted-multipoint connection, in = which=20 frames are forwarded on the basis of the value in their DA field. Such = selective forwarding is not supported in an LSP connection. An LSP = connection=20 will as such just support one EVC link connection, i.e. a = part of=20 the EVC between two adjacent EVC switch/bridge functions. Those p2p = EVC link=20 connections simply require non-selective forwarding, something that an = LSP=20 connection can provide. Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 23:00=20 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path = requirements Dear Maarten, I think you've captured my view pretty = accurately.=20 Since MPLS-TP supports only p2p and p2mp transports it would be = responsibility=20 of another layer to support specific services among UNI-Ns. = Interesting thing=20 that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP = LSP=20 since by MEF's definition E-Tree is a bidirectional service. (Just a=20 note). Kind regards, Greg 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com> Dear=20 Greg, Do you=20 mean that there is a layer network above MPLS-TP that will support = these=20 services from UNI-N port to UNI-N port, and that MPLS-TP will = support this=20 service layer network? Regards, Maarten From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: woensdag 22 april 2009 18:25 To: Maarten=20 Vissers Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org=20 Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements Dear Maarten, I believe that it is not a requirement = for=20 MPLS-TP to support any specific service, including ones you've = listed in=20 your message. On the other hand, support of listed services is a = requirement=20 for a client layer that uses MPLS-TP = services. Regards, Greg=20 Mirsky 2009/4/22 Maarten Vissers <maarten.vissers@huawei.com> Neil, I=20 expect that the main requirement for a packet = transport network=20 technology like MPLS-TP is that it is able to support at least the = following services: -=20 E-Line -=20 E-Tree -=20 E-LAN - PDH=20 CES in a=20 traffic engineered and managed manner. Another main requirement is that it must be able to = support those=20 services in a scalable manner between points anywhere in the=20 world. The=20 E-Line, E-Tree and E-LAN services allow to reorder = client frames that=20 belong to different priorities and to drop client frames that = are=20 drop eligible. The=20 E-Tree and E-LAN services require that client bits are read to = deliver the=20 frames to the appropriate output port or ports of the E-Tree = or E-LAN=20 supporting transport entity/differentiated = connection. The=20 packet transport network technology must as such support traffic=20 engineered transport entities (differentiated connections) = with n=20 input ports (i.e. multi source constructs). This in addition of = traffic=20 engineered transport entities with 1 input = port. Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = neil.2.harrison@bt.com Sent: dinsdag = 21 april=20 2009 14:31 To: liu.guoman@zte.com.cn; dbrungard@att.com=20 Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path=20 requirements Liu, If MPLS-TP is going to be taken seriously as a transport = network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. 1    Provide a transparent client/server=20 relationship...which means: -    all client bits treated=20 equally -    client bit ordering=20 preserved -    no attempt to infer client symbol (ie = sequence=20 of client bits) meaning and no attempt to change client=20 symbols -    the traffic behaviour of client X = must not=20 impact the performance experienced by client Y A key corollary of the above is that MPLS-TP must only = support=20 proper connections (ie single source = constructs) 2   Since MPLS-TP is a transport network it is = not a=20 top-of-stack network (ie it does not support directly external=20 message/file/stream applications). MPLS-TP therefore does = not=20 require an E-NNI specification. A key corollary of this is = that=20 MPLS-TP will not have any peer interworking relationship with any = other=20 network mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. You = could argue=20 this should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE = (also a=20 co-ps mode network) should have FDI/AIS we concluded that on = balance it=20 was not a good idea.....and note that initially I was in favour of = having=20 AIS, but my colleagues provided strong technical arguments that = convinced=20 me otherwise. AIS/FDI is historically linked to the early = PDH co-cs=20 mode layer networks that used TTL logic. When this died it = put out a=20 +5V (all 1s) signal by default, ie it required no conscious effort = to=20 generate it.....this is key point. Further, in these = networks there=20 is a fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never = specified=20 AIS for IP and its why IEEE had the good sense to throw-out AIS in = 802.1ag=20 for Ethernet (though ITU have unwisely IMO retained it in = Y.1731....but I=20 suspect any operator planning to use Ethernet equipment would = always look=20 to IEEE stds and not ITU ones). AIS/FDI and the co-ps mode is = debatable. As I=20 noted above, on balance we considered not a good idea for PBB-TE = OAM=20 because it requires a conscious effort to generate it (unlike the = co-cs=20 mode) so there are likely to be scaling problems and its one more = thing to=20 go wrong. You should also have seen me make the point = many times=20 in the past that the always-on defect detection/handling OAM needs = to be=20 as simple/sparse as possible with as little config as possible = because we=20 need super reliability......TCM goes completely against the grain=20 here. Also note that the OAM required for each of the 3 = network=20 modes is not the same, despite what some=20 claim. regards, = Neil From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = liu.guoman@zte.com.cn Sent: 21 = April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: = mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path=20 requirements Deborah: maybe what you=20 said is right. but I can't completely agree your opinions. IMO. = mpls-tp=20 is regard as transport network like SDH/SONET. so it should have = AIS/FDI=20 fuctions as SDH/SONET. do=20 you think so. best=20 regards liu = "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten Vissers" = <maarten.vissers@huawei.com>, = <neil.2.harrison@bt.com> =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 size=3D2>I agree with Neil, it is very questionable the = value of=20 AIS/FDI in a packet network- any mode. It can result in a DoS = attack=20 by an operator on themselves so even Y1731 recommends not to = block=20 data frames: "A MEP can decide whether it blocks data frames = when it=20 detects dAIS. The principle requirement that influences = this=20 decision is that data frames ought to be forwarded as much as = possible, without the possibility of forwarding wrong data = frames=20 downstream." Table I.7-2 shows for AIS, not to = block. And as=20 Y1731 states, AIS can only be used under very=20 constrained architectures - if required for MPLS-TP, it needs = to have=20 the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a point-to-point ETH connection, a MEP has = only a=20 single peer MEP. Therefore, there is no ambiguity = regarding the=20 peer MEP for which it should suppress alarms when it receives = the ETH-AIS information." So should only be within one = domain -=20 then no need. Deborah -----Original = Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport = path requirements Neil, >=20 but AIS/FDI in the cl mode?...do me a favour! Ethernet = AIS is=20 indeed a requirement and a necessity. And you will = not be able to=20 understand that as long as you refuse to accept that = "cl-mode" is=20 a forwarding mode within a **transport entity**. G.800 = amendment 1=20 has finally reintroduced this transport entity into G.800. = Besides=20 that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection is = a=20 transport entity that transfers information belonging to = multiple=20 communications between ports across a subnetwork. <..> = In a=20 differentiated connection message contents are interpreted = to=20 identify (sets of) communications which=20 receive different treatment. The sets of = communications may=20 be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms of=20 G.800 "differentiated connections". Ethernet AIS provides = AIS=20 within the scope of such "differentiated = connection". If you apply=20 this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and core = domains=20 interconnecting EVC matrices. When one of those EVC links = is=20 interrupted, e.g. in the core between metro 1 and metro 4 = (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS = is=20 inserted in the downstream direction to suppress the EVC-LOC = alarms=20 at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet AIS)=20 frame has a reserved multicast address, which guarantees that = the AIS=20 is broadcast to the endpoints of the EVC. I believe that = it is=20 time for you to adapt your view on co and cl = modes and relate it=20 to the forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP = differentiated connection"=20 with a billion or more ports. What we know as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN is=20 essentially an "Ethernet differentiated connection" with n = ports=20 (n in the range of e.g. 2 to 1000). What we know as a p2p = MPLS E-LSP=20 is essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection" with=20 2 ports. Transport network OAM applies to transport = entities,=20 which are (in terms of G.800 am1) connections and = differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 = april=20 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements John, = Thanks=20 this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting = a wee=20 bit tired of folks trying to make all 3 network modes look = alike=20 (and then, even worse, interwork them as as peers...esp = when not=20 not top-of-stack networks...I mean how silly can we get?). = I=20 am even more frustrated by the fact those peddling this FUD = only ever=20 seem to consider OAM and forget all other DP/CP/MP = components (esp=20 top-of-stack message/file/stream application adaptations). = How=20 wrong can this get! In the co modes a *connection* is a = very=20 specific and *constraining* construct.....I am assuming here = we=20 respect the rules of a connection (ie single source) = though some=20 folks don't even bother to respect this, and this is = despite the=20 fact that we all know what problems = multiple-source constructs can=20 cause (from LDP/PHP....ergo MPLS-TP). When we have a = connection=20 this restricts *all* DP (ie traffic and OAM) to stay = within the=20 bounds of the connection. Which is fine=20 under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is = broken.=20 In a nutshell what this means is that OAM that is of = a=20 request/response nature cannot be trusted in co mode networks = under=20 misconnectivity defects.....indeed, why should a = leaking DP have a=20 symmetric go/return defect behaviour?....very likely it=20 won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts to = explain=20 that physics....G.805 does not. So, the 3 modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the=20 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Drake, John=20 E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; = Alexander=20 Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > = requirements >=20 > Italo, > > As described in the MPLS TP OAM = Requirements I-D, virtually all of the > OAM functions = require=20 a return path, and in the absence of a return > path they = are=20 disabled. > > As described in David Sinicrope's = meeting=20 minutes > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/w= iki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the issue=20 of return path for unidirectional LSPs could be > = charaterized=20 as the elephant in the room. In the MPLS TP OAM > = Framework=20 I-D, unicast LSPs are only mentioned three times and return = >=20 paths not at all. > > Thanks, > > = John >=20 > -----Original Message----- > > From: BUSI ITALO = [mailto:Italo.Busi@alcatel-lucent.it] > > = Sent:=20 Friday, April 17, 2009 1:59 AM > > To: Drake, John E; = Alexander=20 Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path > >=20 requirements > > > > John, > > = > >=20 I might have missed the agreement of MPLS-TP being capable of = >=20 > sending replies to OAM requests sent on uni-directional=20 LSPs. > > > > This requirement does not = belong to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken = into=20 account (at worst in a > subsequent phase). > > = >=20 > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility = to work=20 w/o IP > > forwarding and the need for OAM to continue = to=20 monitor the data > > plane also in case of failures = affecting=20 the control or management > > plane). > > = >=20 > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = >=20 > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Drake, John=20 E > > > Sent: Thursday, April 16, 2009 8:00 = PM > >=20 > To: Alexander Vainshtein; Maarten Vissers > > > = Cc: mpls-tp@ietf.org > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 requirements > > > > > > At the meeting = last=20 fall at Juniper in Massachusetts, I > > think it = was >=20 > > agreed that an MPLS TP network needs to have a=20 forwarding > > capability > > > for = management,=20 control, and OAM packets (e.g., sending > > replies to=20 OAM > > > requests sent on uni-directional LSPs) = even if it=20 does not > > have an IP > > > forwarding = data=20 plane. > > > > > > > -----Original=20 Message----- > > > > From: Alexander = Vainshtein >=20 > > [mailto:Alexander.Vainshtein@ecitele.com] > = > >=20 > Sent: Thursday, April 16, 2009 9:57 AM > > > = > To:=20 Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Maarten, > > > > It seems that you've just = (implicitly=20 and, probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will = not=20 ever support MIP loopback function > > (and = fault > >=20 > > localization which requires this function ) = for > >=20 unidirectional P2MP > > > > and P2P = paths. > >=20 > > > > > > If this statement is correct, = this=20 (IMHO and FWIW) > raises a valid > > > >=20 question: > > > > > > > > = =20 Is MPLS-TP an=20 appropriate solution for these > types of = transport > >=20 > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > = functionality=20 today > > > > for (unidirectional - but it does = not know=20 any other > > type) P2P LSPs > > > > as=20 described in RFC 4379. And its extension to P2MP LSPs seems = >=20 > > > easy... > > > > > > > = >=20 > > > > > > > > = Regards, >=20 > > > > > > > = Sasha >=20 > > > > > > > > > > > = >=20 > > > ________________________________________ > = >=20 > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > = > >=20 Sent: Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Adrian, > > > > > > > > >>=20 <quote> > > > > >> = The=20 intermediate nodes (including MEPs, MIPs and > > > = >=20 other internal > > > > >> = =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of = that > >=20 > > >> transport path. > = >=20 > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > is, there is > > > > >=20 *nothing* that can be observed from a black box point of > = >=20 > view that > > > > > results from adhering = to this=20 requirement. > > > > > > > > Your = understanding is not correct. It is very much > observable = if > > > > this requirement is met from a black = box point=20 of view. > > > > The MIP functions can only = perform the=20 Loopback when there is a > > > > co-routed = bidirectional=20 transport path. The MPLS-TP LBM packet > > > > = received=20 at a MIP needs to be returned (as LBR > > > > = packet) to=20 the originating MEP function via the other > > = direction=20 of > > > > the co-routed bidirectional transport = path.=20 This other > direction > > > > would not be = available in an associated bidirectional transport > > = >=20 > path... and thus the loopback test > > > would=20 fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not in a > > > > associated = bidir=20 transport path. In the first case the TCM MEP > > > = >=20 Source and Sink functions are co-located and can > = exchange what=20 is > > > > called "remote information" which is = necessary=20 for performance > > > > monitoring. > > = >=20 > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, > >=20 > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = > Your=20 understanding is not correct. This text must not be > > = deleted=20 at > > > > all. > > > > > = > >=20 > > Actually, I am quite fed up about this = persistent > >=20 > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > >=20 is > > > > poorly > > > > > = specified=20 and comes from the monitoring of a path that is > > = > >=20 parallel (i.e. > > > > tandem) > > > = >=20 > to the data path being monitored. This definition of = TC >=20 > > > seems to be at > > > > = variance, >=20 > > > > and would be if the ACH was actually in=20 band. > > > > > > > > I don't = understand=20 where your interpretation of tandem > > connection = is >=20 > > > described in ITU-T recommendations. I.e. "from=20 the > > monitoring of a > > > > path = that is=20 parallel (i.e. tandem) to the data path being > > > = >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection is = a=20 set > > > > of interconnected "link connections" = and=20 "matrix > connections". A > > > > subset of = those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to as > = a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There=20 is only additional OAM inserted inside the data > path by=20 the > > > > TCM MEP_So function and this OAM is = extracted=20 from the > > data path by > > > > the = TCM MEP_Sk=20 function. > > > > > > > >=20 Regards, > > > > Maarten > > > > = >=20 > > > > > > > -----Original=20 Message----- > > > > From: mpls-tp-bounces@ietf.org > > > = >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Adrian=20 Farrel > > > > Sent: donderdag 16 april 2009=20 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > >=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > > = Unfortunately=20 I cannot fully agree with your statement: > > > > = > > > > > > <quote> > > > = >=20 > From the point of view of hardware, = co-routed >=20 > > bidirectional LSPs > > > > > = =20 are a special case of associated bidirectional LSPs. > = > >=20 > > <end quote> > > > > > > = >=20 > > > This statement would be obviously correct, were = it not=20 for > > > > Requirement > > > > = > 34 in=20 the latest MPLS-TP requirements draft > > > > = >=20 > > > OK. Got it. > > > > > > = >=20 > But what is this doing in the data plane requirements=20 section? > > > > > > > > In fact, = what is=20 this requirement actually saying? > > > > = > >=20 > > > <quote> > > > > > = =20 The intermediate nodes (including MEPs, MIPs and > = > >=20 other internal > > > > > =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > = > >=20 > > relationship of the forward and = the=20 backward > > > > directions of that > > = >=20 > > transport path. > > > = >=20 > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > = > is,=20 there is > > > > *nothing* that can be observed = from a=20 black box point of > > view that > > > > = results=20 from adhering to this requirement. > > > > = > >=20 > > Therefore it could be assumed that this requirement is = met by=20 > > > > configuring some data plane database = component=20 through the > > > > management plane. The = database=20 component is not used > for anything > > > = > except=20 to satisfy this requirement for "awareness". > > > = >=20 > > > > Ben! Can we please try to rewrite this=20 requirement in terms of > > > > = behavior? > >=20 > > > > > > > Please note that = Requirement 34=20 is the ONLY item in the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = >=20 > paths are > > > > > exactly the same even = if they=20 appear in two different > > > items in the > = > >=20 > > requirements' list). > > > > > In = other=20 words, without Requirement 34 the notion of > = co-routed >=20 > > > > bidirectional paths would be void of any = data plane=20 content. > > > > > > > > > > = The=20 somewhat vague scope of this requirement ("other internal = > >=20 > > > functions as appropriate") creates a suspicion = that=20 HW > > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with = it. >=20 > > > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > MIPs and other > > = >=20 > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate=20 nodes." > > > > > > > > > The=20 following text in the draft increases this suspicion: > = > >=20 > > > > > > > <quote> > > = >=20 > > Tandem Connection: A tandem connection is = an >=20 > arbitrary part of a > > > > > = transport=20 path that can be monitored (via OAM) > > > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of a=20 transport path. > > The tandem > > > = >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > > > > = > =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = >=20 > Actually, I am quite fed up about this persistent > = >=20 insistence on the > > > > inclusion of "Tandem=20 Connection." The definition within > > the ITU-T = of >=20 > > > this term is poorly specified and comes from = the >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > = >=20 > > > > > > Doesn't "forwarding engine" = sound like=20 hardware to you? > > > > > > > > = Yes, but=20 so what? > > > > > > > > > = IMHO it is=20 worth noting that neither the MPLS-TP > > > = Requirements=20 draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > > > > > > > > = >=20 > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed in=20 the MPLS-TP OAM > > Framework > > > > = >=20 draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oa= m-fr >=20 > > > amework-00.txt > > > > ). > = >=20 > > > > > > Right. > > > > = Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some clarity=20 regarding > > > co-routed vs. > > > > = >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 to=20 specific > > > functionality. > > > > = > > > > Agreed. > > > > > = >=20 > > Adrian > > > > > > > > = >=20 > > > > > > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > = Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path > > = >=20 > requirements > > > > > > > > = Hi=20 Sasha, > > > > > > > > Not really = sure=20 whether you are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one of Ben's = messages is that associated > > > > >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will = have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > = > This=20 is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > = >=20 > > a special case of associated bidirectional = LSPs. > >=20 > > > > > > If you can set up two = unidirectional=20 LSPs (e.g. using the > > management > > > = >=20 plane) you can surely set up a co-routed > > > = bidirectional=20 LSP. > > > > > > > > There are = shipping=20 solutions that achieve co-routed > bidirectional > = > >=20 > LSPs using the control plane. These either use the = GMPLS >=20 > (which is > > > > cleaner) or non-standard=20 proprietary solutions (which is > > messy but > = > >=20 > functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are software > > > > = solutions. >=20 > > > > > > = > >=20 2. My reading of one of Neil's messages is that the = actual > >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > = >=20 transport networks rather than any specific benefit. > = > >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, >=20 > > > feel, and behavioral characteristics of a=20 "legacy" > > > > transport network. > > = >=20 > > > > > > Based on these observations, = I'd guess=20 (FWIW) that: > > > > > * associated = bidirectional=20 paths are, at least for the time > > > > > = =20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = >=20 > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other = upgrades to=20 existing MPLS solutions will be > needed to reach > = >=20 > > the full function level of MPLS-TP. > > > = >=20 > > > > > * they had a good chance to remain = the only=20 type of > > bidirectional > > > > > = =20 paths in real deployments. > > > > > = >=20 > > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 > > > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= =20 _______________________________________________ mpls-tp = mailing=20 list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ----------------------------------------------------= ---- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ________________________________= _______________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp = ------=_NextPart_000_001B_01C9C477.E221AD60-- From Alexander.Vainshtein@ecitele.com Thu Apr 23 23:42:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787DF28C71B for ; Thu, 23 Apr 2009 23:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=-1.998, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egaShRJJjNz0 for ; Thu, 23 Apr 2009 23:42:40 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 7A1493A6FE6 for ; Thu, 23 Apr 2009 23:42:05 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 24 Apr 2009 09:41:16 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 09:43:22 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 24 Apr 2009 09:43:22 +0300 From: Alexander Vainshtein To: Maarten Vissers , "mpls-tp@ietf.org" Date: Fri, 24 Apr 2009 09:43:21 +0300 Thread-Topic: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Thread-Index: AcnEYLwwpSRuv4zbdUCO9uPM0MsD/gAAReigABE8wAs= Message-ID: References: , <001701c9c465$9e8c36e0$0800540a@china.huawei.com> In-Reply-To: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90B3ILPTMAIL02eci_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2009 06:43:22.0610 (UTC) FILETIME=[F6363520:01C9C4A7] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 06:42:41 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90B3ILPTMAIL02eci_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TWFhcnRlbiwNCg0KWW91IGhhdmUgY2xhaW1lZDoNCg0KPHF1b3RlPg0KDQp3ZWxsIGVzdGFibGlz aGVkIGZlYXR1cmVzIGxpa2UgQUlTLCBUQ00sIGZyYW1lIGxvc3MgY291bnRpbmcsIGRlbGF5IG1l YXN1cmVtZW50LCBsb29wYmFjaywgZXRjDQoNCjxlbmQgcXVvdGU+DQoNCkkgd291bGQgYmUgcmVh bGx5IGdsYWQgdG8gaGVhciBhYm91dCBhY3R1YWwgZGVwbG95bWVudCBvZiBFdGhlcm5ldCBBSVMg YW5kIFkuMTczMS1iYXNlZCBmcmFtZSBsb3NzIGNvdW50IGZyb20gdGhlIG9wZXJhdG9ycy4NCg0K DQoNCkFuZCwgQUZBSUssICBCZW4ncyBjYWxsIGZvciB0aGUgb3BlcmF0b3JzJyBzaG93IG9mIGhh bmRzIGluIGFja25vd2xlZGdlbWVudCBvZiBkZXBsb3ltZW50IG9mIFRDTSBpbiB0aGVpciBuZXR3 b3JrcyBoYXMgbm90IHNvIGZhciwgeWllbGRlZCBldmVuIGEgc2luZ2xlICJZZWEiLg0KDQoNCg0K U28gdGhlIHF1ZXN0aW9uIGlzOiBXaGF0IGNvbnN0aXR1dGVzIGEgd2VsbCBlc3RhYmxpc2hlZCBm ZWF0dXJlPw0KDQoNCg0KTXkgMmMsDQoNCiAgICAgU2FzaGENCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9y ZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFhcnRlbiBWaXNzZXJz IFttYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMjQsIDIw MDkgMTo0OCBBTQ0KVG86ICdCZW4gTml2ZW4tSmVua2lucyc7IG1wbHMtdHBAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbbXBscy10cF0gV2UgYXBwZWFyIHRvIGJlIGdvaW5nIGFyb3VuZCBpbiBjaXJj bGVzIChSZTogICAgIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1 aXJlbWVudHMpDQoNCkJlbiwNCg0KWW91ciBjb21wYW55IGlzIG9uZSBvZiB0aGUgbWFueSBvcGVy YXRvcnMgaW4gdGhlIHdvcmxkLCBhbmQgdGhlIG51bWJlciBvZg0Kbm9kZXMgb3V0c2lkZSB5b3Vy IG5ldHdvcmsgaXMgZmFjdG9ycyBsYXJnZXIgdGhlbiB0aGUgbnVtYmVyIG9mIG5vZGVzIGluc2lk ZQ0KeW91ciBuZXR3b3JrLiBNeSBleHBlcmllbmNlIGlzIHRoYXQgZGlmZmVyZW50IG9wZXJhdG9y cyBoYXZlIGRpZmZlcmVudCBzZXRzDQpvZiByZXF1aXJlbWVudHMuIE1hbnVmYWN0dXJlcnMgaGF2 ZSB0byBzdXBwb3J0IHRoZSBzdXBlcnNldCBvZiB0aG9zZQ0KcmVxdWlyZW1lbnRzLiBFYWNoIG9w ZXJhdG9yIHdpbGwgdGhlbiBkZXBsb3kgdGhlIHN1YnNldCBvZiBwcm92aWRlZCBmZWF0dXJlcw0K dGhhdCBmaXRzIGl0cyBuZWVkcyAoYW5kIHR1cm4gb2ZmIG9yIGRvbid0IHVzZSB0aGUgb3RoZXJz KS4gWW91ciBjb21wYW55IGZvcg0Kc29tZSB5ZWFycyBoYXMgYmVlbiBhc2tpbmcgZm9yIGxlc3Ms IG90aGVyIG9wZXJhdG9ycyBoYXZlIGJlZW4gYXNraW5nIGZvcg0KbW9yZS4gTWFudWZhY3R1cmVy cyB0aHVzIGJ1aWxkIHRoZWlyIHByb2R1Y3RzIHdpdGggbG90cyBvZiBjb25maWd1cmFiaWxpdHkN CnRvIHN1cHBvcnQgYWxsIHZhcmlhdGlvbnMuDQoNCkl0IGlzIG15IG9waW5pb24gdGhhdCB3ZSBz aG91bGQgbm90IHJlbW92ZSB3ZWxsIGVzdGFibGlzaGVkIGZlYXR1cmVzIGxpa2UNCkFJUywgVENN LCBmcmFtZSBsb3NzIGNvdW50aW5nLCBkZWxheSBtZWFzdXJlbWVudCwgbG9vcGJhY2ssIGV0YyBi ZWZvcmUgdGhlDQptYWpvcml0eSBvZiBvcGVyYXRvcnMgaGF2ZSBhZ3JlZWQgdGhhdCBzdWNoIGZl YXR1cmVzIGFyZSBub3QgbG9uZ2VyDQpuZWNlc3NhcnkuDQoNClJlZ2FyZHMsDQpNYWFydGVuDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KT2YgQmVuIE5p dmVuLUplbmtpbnMNClNlbnQ6IHZyaWpkYWcgMjQgYXByaWwgMjAwOSAwOjE0DQpUbzogbXBscy10 cEBpZXRmLm9yZw0KU3ViamVjdDogW21wbHMtdHBdIFdlIGFwcGVhciB0byBiZSBnb2luZyBhcm91 bmQgaW4gY2lyY2xlcyAoUmU6IEFzc29jaWF0ZWQNCmJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzKQ0KDQpDb2xsZWFndWVzLA0KDQpUaGUgY3VycmVudCBkZWJhdGVzIGFw cGVhciB0byBiZSBnb2luZyBhcm91bmQgaW4gY2lyY2xlcyBhbmQgYWNoaWV2aW5nDQpub3RoaW5n IG9mIHZhbHVlIElNTy4gVHdvIG1ham9yIG9wZXJhdG9ycyBoYXZlIGV4cHJlc3NlZCB0aGVpciBv cGluaW9ucyBhbmQNCm5vIG9wZXJhdG9yIHRoYXQgSSBjYW4gc2VlIGhhcyBkaXNhZ3JlZWQgd2l0 aCB0aG9zZSBvcGluaW9ucy4NCg0KSSBhcG9sb2dpc2UgZm9yIGJlaW5nIGRpcmVjdCAoYW5kIHBv c3NpYmx5IHJ1ZGUpIGJ1dCBJIGFtIGdldHRpbmcgdGlyZWQgb2YNCmJlaW5nIHRvbGQgYnkgZm9s a3Mgd2hvIGRvIG5vdCByZXByZXNlbnQgb3BlcmF0b3JzIHdoYXQgZnVuY3Rpb25hbGl0eSBJIG5l ZWQNCm9yIHNob3VsZCBoYXZlIGluIG15IG5ldHdvcmtzLg0KDQpUbyBwdXQgc29tZSBjb250ZXh0 IG9uIEJUJ3MgY29tbWVudHMgaW4gdGhlc2UgdGhyZWFkczoNCkkgaGF2ZSB0aGUgbGFyZ2VzdCBN UExTIG5ldHdvcmsgaW4gdGhlIFVLLg0KSSBoYXZlIG9uZSBvZiB0aGUgbGFyZ2VzdCBNUExTIG5l dHdvcmtzIGdsb2JhbGx5IGRlbGl2ZXJpbmcgc2VydmljZSB0byAxNzMNCmNvdW50cmllcyB3aXRo IG92ZXIgMjAwIDAwMCBjdXN0b21lciBwb3J0cyBJIGhhdmUgKG9mZiB0aGUgdG9wIG9mIG15IGhl YWQpDQphdCBsZWFzdCBhbm90aGVyIDEwIE1QTFMgbmV0d29ya3MgaW4gc3BlY2lmaWMgY291bnRy aWVzIGNvdmVyaW5nIGF0IGxlYXN0IDMNCmNvbnRpbmVudHMgZGVsaXZlcmluZyBkZWRpY2F0ZWQg c2VydmljZXMgdG8gcGFydGljdWxhciBtYXJrZXQgc2VnbWVudHMuDQoNCkkgaGF2ZSBhbiBleHRy ZW1lbHkgbGFyZ2UgU0RIIG5ldHdvcmsgaW4gdGhlIFVLIGNvbnNpc3Rpbmcgb2Ygb3ZlciAzMCAw MDANCnN3aXRjaGVzIGFuZCBzdXBwb3J0aW5nIGluIGV4Y2VzcyBvZiAxIG1pbGxpb24gY2lyY3Vp dHMuDQpJIGhhdmUgYW4gZXh0cmVtZWx5IGxhcmdlIFNESCBuZXR3b3JrIGdsb2JhbGx5IGRlbGl2 ZXJpbmcgc2VydmljZSBpbiAxMTANCmNvdW50cmllcy4NCg0KSSB3b3VsZCBsaWtlIHRvIHRoaW5r IG15IEJUIGNvbGxlYWd1ZXMgYW5kIEkgbWlnaHQga25vdyBhIGxpdHRsZSBzb21ldGhpbmcNCmFi b3V0IGJ1aWxkaW5nIGxhcmdlIHNjYWxlIG5ldHdvcmtzIGFuZCB0aGUgcmVxdWlyZW1lbnRzIG9m IHRob3NlIG5ldHdvcmtzDQphbmQgdGhlIG5lZWRzIG9mIHRoZSBjdXN0b21lcnMgdGhhdCBJIGRl bGl2ZXIgc2VydmljZXMgdG8uDQoNCkNhbiB3ZSBwbGVhc2Ugc3RvcCB0aGVzZSBjaXJjdWxhciBh cmd1bWVudHMgd2hpY2ggYXJlIElNTyBnb2luZyBub3doZXJlIGFuZA0KZm9jdXMgb24gdGhlIHRh c2sgaW4gaGFuZCB3aGljaCBpcyBkZWZpbmluZyB0aGUgcmVxdWlyZW1lbnRzIChhbmQgbGF0ZXIN CnNvbHV0aW9ucykgYmVpbmcgYXNrZWQgZm9yIGJ5IG15c2VsZiwgbXkgY29tcGFueSBhbmQgbXkg Y29sbGVhZ3VlcyBpbiBvdGhlcg0Kb3BlcmF0b3JzIG9uIHRoaXMgbGlzdC4NCg0KVGhhbmtzDQpC ZW4NCg0KDQotLQ0KDQpCZW4gTml2ZW4tSmVua2lucw0KSVAsIERhdGEgJiBDb250ZW50IEFyY2hp dGVjdA0KTmV0d29yayBJbmZyYXN0cnVjdHVyZSBBcmNoaXRlY3R1cmUsIEJUDQoNCkUtbWFpbDog YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20NCk9mZmljZTogKzQ0ICgwKTE0NzMgNjQ4MjI1 DQpNb2JpbGU6ICs0NCAoMCk3OTE4IDA3NzIwNQ0KICAgRmF4OiArNDQgKDApMTMzMiA1Nzg4MjcN Cg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjLiBSZWdpc3RlcmVkIG9mZmljZTogIDgx IE5ld2dhdGUgU3RyZWV0IExvbmRvbg0KRUMxQSA3QUogICBSZWdpc3RlcmVkIGluIEVuZ2xhbmQg bm86ICAxODAwMDAwDQoNCg0KT24gMjMvMDQvMjAwOSAwNzoyMywgImxpdS5ndW9tYW5AenRlLmNv bS5jbiIgPGxpdS5ndW9tYW5AenRlLmNvbS5jbj4gd3JvdGU6DQoNCj4gYmVuOg0KPiAgSSB1bmRl cnN0YW5kIHlvdXIgbWVhbmluZywgeW91IHN0aWxsIHdpc2ggdG8gcmVzaWduIGFuZCBtYWtlIGEg bW9yZQ0KPiByZWxpYWJsZSBhbmQgZWZmZWN0aXZlLCBlYXN5IHRvIG9wZXJhdG9yIGFuZCBlYXN5 IHRvIG1hbmFnZSBwYWNrZXQNCj4gdHJhbnNwb3J0IG5ldHdvcmsgbGlrZSBtZS4gYnV0IHdoeSBu b3QgYXBwbHkgdGhpcyBTREgvU09ORVQgaW4gdGhlDQo+IGZ1dHVyZSBtYXliZSB0aGUgZm9sbG93 aW5nIGNhdXNlOg0KPiAgICAxIGl0IGFkb3B0ZWQgY2lyY3VpdCBzd2l0Y2hpbmcgdGVjaG9ub2d5 IHRvIGJyaW5nIGxvd2VyIHVzZWZ1bCBvZg0KPiB0aGUgcmVzb3VyY2UgdGhhbiBQVE4gbmV0d29y azsNCj4gICAgMiBpdCBjYW4ndCBiZWFyIGFsbCBraW5kcyBvZiB0cmFmZmljcyBsaWtlIFBUTiBu ZXR3b3JrcyBpdCBub3RlZA0KPiB0aGF0IHdlIGNhbid0IGFwcGx5IFNESC9TT05FVCBuZXR3b3Jr IGluIHRoZSBmdXR1cmUgbm90IGJlY2F1c2UgaXQNCj4gaGF2ZSBhIGNvbXBsZXggT0FNIGZ1bmN0 aW9ucy4gd2hpbGUgbW9yZSBwZW9wbGUgbGlrZSB0byBtb3ZlIHRoZQ0KPiBhZHZhbnRhZ2VzIG9m ICB0aGUgT0FNIGZ1bmN0aW9ucyBpbiBTREgvU09ORVQgdG8gUFROIG5ldHdvcmtzLiBhbmQNCj4g QUlTL0ZESSBmdW5jdGlvbiBpcyBhIGtpbmQgb2YgT0FNIGZ1bmN0aW9ucyBvZiBTREgvU09ORVQg LiB3ZSBzaG91bGQNCj4gdXNlIGFuZCBleHRlbmQgdGhlIEFJUy9GREkgZnVuY3Rpb25zIHRvIE1Q TFMtVFAgOw0KPg0KPiBiZXN0IHJlZ2FyZHMNCj4gbGl1DQo+DQo+DQo+DQo+IEJlbiBOaXZlbi1K ZW5raW5zIDxiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbT4NCj4gMjAwOS0wNC0yMyAwNzo1 OA0KPg0KPiDK1bz+yMsNCj4gPGxpdS5ndW9tYW5AenRlLmNvbS5jbj4sICJCUlVOR0FSRCwgREVC T1JBSCBBLCBBVFRMQUJTIg0KPiA8ZGJydW5nYXJkQGF0dC5jb20+DQo+ILOty80NCj4gPG1wbHMt dHBAaWV0Zi5vcmc+DQo+INb3zOINCj4gUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQo+DQo+DQo+DQo+DQo+DQo+DQo+IE9u IDIxLzA0LzIwMDkgMDI6NTksICJsaXUuZ3VvbWFuQHp0ZS5jb20uY24iIDxsaXUuZ3VvbWFuQHp0 ZS5jb20uY24+DQo+IHdyb3RlOg0KPg0KPj4gRGVib3JhaDoNCj4+ICBtYXliZSB3aGF0IHlvdSBz YWlkIGlzIHJpZ2h0LiBidXQgSSBjYW4ndCBjb21wbGV0ZWx5IGFncmVlIHlvdXINCj4gb3Bpbmlv bnMuDQo+PiBJTU8uIG1wbHMtdHAgaXMgcmVnYXJkIGFzIHRyYW5zcG9ydCBuZXR3b3JrIGxpa2Ug U0RIL1NPTkVULiBzbyBpdA0KPj4gc2hvdWxkIGhhdmUgQUlTL0ZESSBmdWN0aW9ucyBhcyBTREgv U09ORVQuDQo+Pg0KPj4gZG8geW91IHRoaW5rIHNvLg0KPg0KPiBObyB3ZSBtdXN0IGFzc2VzcyB0 aGUgcmVxdWlyZW1lbnRzIGZvciBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzDQo+IHN1cHBvcnRp bmcgdGhlIG5lZWRzIG9mIG9wZXJhdG9ycyB0b2RheSBhbmQgaW4gdGhlIGZ1dHVyZS4gV2UgbXVz dCBub3QNCj4gYmxpbmRseSByZWNyZWF0ZSBTREgvU09ORVQuIElmIHdlIGRvIHNvIHdpdGhvdXQg Y29uc2lkZXJhdGlvbiB0byBob3cNCj4gb3BlcmF0b3JzJyBuZWVkcyBhbmQgcmVxdWlyZW1lbnRz IG1heSBoYXZlIGV2b2x2ZWQgKGFuZCBjb250aW51ZSB0bw0KPiBldm9sdmUgaW4gZnV0dXJlKSB3 ZSB3aWxsIGhhdmUgZmFpbGVkIElNTyBhbmQgSSB3b3VsZCBzZXZlcmVseQ0KPiBxdWVzdGlvbiB0 aGUgdmFsdWUgb2YgdGhlIHdvcmsgd2Ugd2lsbCBoYXZlIHByb2R1Y2VkLiBJZiB3ZSBqdXN0DQo+ IHJlY3JlYXRlIFNESC9TT05FVCB0aGVuIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIHdvcmsg YW4gb3BlcmF0b3INCj4gd291bGQgYmUgYmV0dGVyIG9mZiBqdXN0IGRlcGxveWluZyBleGlzdGlu ZyBTREgvU09ORVQgZXF1aXBtZW50Lg0KPg0KPg0KPiBCZW4NCj4NCj4NCj4NCj4NCj4NCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzDQo+IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbA0KPiBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvDQo+IG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzDQpj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQNCj4gaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkNCj4gYXJl IGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVh c2Ugbm90aWZ5DQo+IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUNCj4gdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtDQpzeXN0ZW0uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptcGxzLXRwIG1haWxpbmcgbGlzdA0KbXBscy10cEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAg bWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHANCg== --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90B3ILPTMAIL02eci_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, You have claimed: <quote> well established features like AIS, TCM, frame loss coun= ting, delay measurement, loopback, etc <end quote> I would be really glad to hear about actual deployment of Ethernet= AIS and Y.1731-based frame loss count from the operators. <= /font> A= nd, AFAIK, Ben's call for the operators' show of hands in acknow= ledgement of deployment of TCM in their networks has not so far, = yielded even a single "Yea". So the question is: What constitutes a we= ll established feature? My 2c,      Sasha ________________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maar= ten Vissers [maarten.vissers@huawei.com] Sent: Friday, April 24, 2009 1:48 AM To: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: &n= bsp;   Associated bidirectional transport path requirements) Ben, Your company is one of the many operators in the world, and the number of nodes outside your network is factors larger then the number of nodes insid= e your network. My experience is that different operators have different sets= of requirements. Manufacturers have to support the superset of those requirements. Each operator will then deploy the subset of provided feature= s that fits its needs (and turn off or don't use the others). Your company fo= r some years has been asking for less, other operators have been asking for more. Manufacturers thus build their products with lots of configurability<= br> to support all variations. It is my opinion that we should not remove well established features like AIS, TCM, frame loss counting, delay measurement, loopback, etc before the<= br> majority of operators have agreed that such features are not longer necessary. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf<= br> Of Ben Niven-Jenkins Sent: vrijdag 24 april 2009 0:14 To: mpls-tp@ietf.org Subject: [mpls-tp] We appear to be going around in circles (Re: Associated<= br> bidirectional transport path requirements) Colleagues, The current debates appear to be going around in circles and achieving nothing of value IMO. Two major operators have expressed their opinions and= no operator that I can see has disagreed with those opinions. I apologise for being direct (and possibly rude) but I am getting tired of<= br> being told by folks who do not represent operators what functionality I nee= d or should have in my networks. To put some context on BT's comments in these threads: I have the largest MPLS network in the UK. I have one of the largest MPLS networks globally delivering service to 173<= br> countries with over 200 000 customer ports I have (off the top of my head)<= br> at least another 10 MPLS networks in specific countries covering at least 3= continents delivering dedicated services to particular market segments. I have an extremely large SDH network in the UK consisting of over 30 000 switches and supporting in excess of 1 million circuits. I have an extremely large SDH network globally delivering service in 110 countries. I would like to think my BT colleagues and I might know a little something<= br> about building large scale networks and the requirements of those networks<= br> and the needs of the customers that I deliver services to. Can we please stop these circular arguments which are IMO going nowhere and= focus on the task in hand which is defining the requirements (and later solutions) being asked for by myself, my company and my colleagues in other= operators on this list. Thanks Ben -- Ben Niven-Jenkins IP, Data & Content Architect Network Infrastructure Architecture, BT E-mail: benjamin.niven-jenkins@bt.com Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205    Fax: +44 (0)1332 578827 British Telecommunications plc. Registered office: 81 Newgate Street = London EC1A 7AJ   Registered in England no: 1800000 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.c= om.cn> wrote: > ben: > I understand your meaning, you still wish to resign and make a m= ore > reliable and effective, easy to operator and easy to manage packet > transport network like me. but why not apply this SDH/SONET in the > future maybe the following cause: >    1 it adopted circuit switching techonogy to bring lo= wer useful of > the resource than PTN network; >    2 it can't bear all kinds of traffics like PTN netwo= rks it noted > that we can't apply SDH/SONET network in the future not because it > have a complex OAM functions. while more people like to move the > advantages of the OAM functions in SDH/SONET to PTN networks. an= d > AIS/FDI function is a kind of OAM functions of SDH/SONET . we should > use and extend the AIS/FDI functions to MPLS-TP ; > > best regards > liu > > > > Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com> > 2009-04-23 07:58 > > =CA=D5=BC=FE=C8=CB > <liu.guoman@zte.com.cn>, "BRUNGARD, DEBORAH A, ATTLABS"= ; > <dbrungard@att.com> > =B3=AD=CB=CD > <mpls-tp@ietf.org> > =D6=F7=CC=E2 > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@= zte.com.cn> > wrote: > >> Deborah: >> maybe what you said is right. but I can't completely agree y= our > opinions. >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it<= br> >> should have AIS/FDI fuctions as SDH/SONET. >> >> do you think so. > > No we must assess the requirements for packet transport networks > supporting the needs of operators today and in the future. We must not= > blindly recreate SDH/SONET. If we do so without consideration to how > operators' needs and requirements may have evolved (and continue to > evolve in future) we will have failed IMO and I would severely > question the value of the work we will have produced. If we just > recreate SDH/SONET then what is the purpose of the work an operator > would be better off just deploying existing SDH/SONET equipment. > > > Ben > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to= > maintain secrecy and are not permitted to disclose the contents of thi= s communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify<= br> > the originator of the message. Any views expressed in this message are= > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90B3ILPTMAIL02eci_-- From andy.bd.reid@bt.com Fri Apr 24 03:33:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B241C3A67EE for ; Fri, 24 Apr 2009 03:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kzu3JllDpzq for ; Fri, 24 Apr 2009 03:32:55 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B2DC03A68AD for ; Fri, 24 Apr 2009 03:32:54 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.47]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 11:34:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C4C8.3486BA16" Date: Fri, 24 Apr 2009 11:34:12 +0100 Message-ID: In-Reply-To: <005301c9c44b$90e185a0$0800540a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEA== From: To: X-OriginalArrivalTime: 24 Apr 2009 10:34:11.0984 (UTC) FILETIME=[3514F900:01C9C4C8] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 10:33:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C4C8.3486BA16 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only = adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network = management system). A problem occuring in admin domain A will be unknown = in admin domain B. The loss of continuaity alarms that are activated in = admin domain B due to the fault in admin domain A will appear as primary = alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different = things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server = layer. AIS suppresses the LOC alarm in those cases so that the = maintenance guys don't get triggered and start looking for a fault that = is outside their area. =20 Regards, Maarten =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg = misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. If, at an end equipment, = I have a good server/section layer and a loss of CC at the client layer, = I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service = guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions = will bring some complexity . but if we have no functions, it is more = complex and difcult for operators to maintence and administrator the = network. so I think every new functions and things may have positive and = negative effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like = SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance = experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper = connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim.=20 =20 regards, Neil=20 =20 =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 =09 =09 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro = 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated = by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to have = to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could = be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management = > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems = > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is = a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet = > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP = > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance = > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of = > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C4C8.3486BA16 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, These points are irrelevant to the points I = made. My point=20 is that AIS/FDI gives no information above what is already known - it is = only=20 adds complexity and fault liability. Neither of your points change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = =20 British=20 Telecommunications plc Registered office: 81 Newgate Street London = EC1A=20 7AJ Registered in England no. 1800000 This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009=20 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of alarm = suppression in=20 the data plane - that information is readily=20 available. I don't = believe that this=20 is a correct statement in a multi-operator transport network, or in = transport=20 networks of one operator that have more then one administrative = subdomain=20 (each with its own network management system). A problem occuring in = admin=20 domain A will be unknown in admin domain B. The loss of continuaity = alarms=20 that are activated in admin domain B due to the fault in admin domain = A will=20 appear as primary alarms, suggesting connectivity problems in admin = domain=20 B. > The issue=20 arises because the two sides of maintenance want different things. The = fault=20 fixing > guys=20 want to locate the fault and don't want any other information. The = service=20 maintenance > guys=20 want to know whether their customer service is=20 working. This=20 is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means = of the=20 additional SSF alarm. The SSF alarm is for the service guys = telling them=20 that the service was interrupted due to a fault in a server layer. AIS = suppresses the LOC alarm in those cases so that the maintenance guys = don't get=20 triggered and start looking for a fault that is outside their=20 area. Regards, Maarten From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two things=20 which are separate and for which AIS/FDI is no help. Maintenance = operations=20 are concerned with two separate things. 1) Identifying faults in equipment, = line plant, and=20 other systems (eg misconfigurations) and fixing them (equipment=20 maintenance). 2) Identifying the health of end to end = connections, especially when they are directly supporting customer = services=20 (service maintenance). The problem is *not* about a lack of alarm = suppression in=20 the data plane - that information is readily available. If, at an end=20 equipment, I have a good server/section layer and a loss of CC at the = client=20 layer, I *know* the fault is elsewhere - I don't need AIS/FDI to tell = me.=20 (Indeed, if you think about, if the fault is in the end equipment, it = is quite=20 likely that the fault means it cannot report the traffic loss to the=20 management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the fault = and=20 don't want any other information. The service maintenance guys want to = know=20 whether their customer service is working. This arose in the early days of SONET/SDH, = when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know about=20 the alarms. The normal practice is for the equipment to report = the alarms=20 *including* AIS and then a filter is applied in the management = system to=20 suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you=20 consider multiple concurrent faults in a network, however, the = existance of=20 AIS/FDI doesn't add anything to these that's not already known. In = fact, I=20 believe simple time-stamp correlation is one of the most powerful = and=20 widely used techniques. And if the equipment starts messing up the = reporting=20 of loss of CC because it waiting for/persistence = checking AIS/FDI, it=20 could end up messing up simple time-stamp=20 correlation! In practice, it is often not quite a simple = as this, as=20 the service guys like to be able to 'localise' the fault. However, = under most=20 circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter hasn't = worked=20 for some reason. But the bottom line is, whatever operations = process you=20 want to use, AIS/FDI doesn't add anything other than complexity = and fault=20 liability to the equipment. Remember AIS goes back to the TDM = world where=20 you *have to fill the bit stream with something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009 = 09:15 To:=20 Harrison,N,Neil,CXM R Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Neil: = thank you for wasting more time in = describling=20 the problems. but I think some of what you said is no relations with = our=20 problem.for me, maybe AIS/FDI functions is no sense in cl-ps ,eg. = IP. but=20 for CO-PS networks.if there is no AIS/FDI functions, when there is a = defects=20 in a given layer network, it can cause multiple alarm events to be = raised.=20 it is diffcult for operators to locate and diagnose the = faults.=20 though I completely agree = you on=20 adding new things and functions will bring some complexity . = but if we=20 have no functions, it is more complex and difcult for operators to = maintence=20 and administrator the network. so I think every new functions and = things may=20 have positive and negative effects. but we should consider it very = much,=20 don't delete some functions at random. best regards liu <neil.2.harrison@bt.com> 2009-04-21 20:30 = =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If=20 MPLS-TP is going to be taken seriously as a transport network (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are these. = 1=20 Provide a transparent client/server = relationship...which=20 means: - =20 all client bits treated equally - client bit ordering = preserved=20 - = no=20 attempt to infer client symbol (ie sequence of client bits) meaning = and no=20 attempt to change client symbols - the traffic behaviour of = client X must=20 not impact the performance experienced by client Y A=20 key corollary of the above is that MPLS-TP must only support proper=20 connections (ie single source constructs) 2 Since = MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does not = support=20 directly external message/file/stream applications). MPLS-TP = therefore=20 does not require an E-NNI specification. A key corollary of = this is=20 that MPLS-TP will not have any peer interworking relationship with = any other=20 network mode/technology. = Now=20 wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should=20 have FDI/AIS....however, the merit of this is highly questionable.=20 When I and colleagues discussed whether PBB-TE (also a co-ps = mode=20 network) should have FDI/AIS we concluded that on balance it was not = a good=20 idea.....and note that initially I was in favour of having AIS, but = my=20 colleagues provided strong technical arguments that convinced me=20 otherwise. AIS/FDI is = historically linked to=20 the early PDH co-cs mode layer networks that used TTL logic. = When this=20 died it put out a +5V (all 1s) signal by default, ie it required no=20 conscious effort to generate it.....this is key point. = Further, in=20 these networks there is a fairly static/long-holding client server=20 relationship. Clearly this is not true in the cl-ps mode and = it's why=20 IETF have never specified AIS for IP and its why IEEE had the good = sense to=20 throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO = retained=20 it in Y.1731....but I suspect any operator planning to use Ethernet=20 equipment would always look to IEEE stds and not ITU ones). = AIS/FDI and the co-ps mode is debatable. As I noted = above, on=20 balance we considered not a good idea for PBB-TE OAM because it = requires a=20 conscious effort to generate it (unlike the co-cs mode) so there are = likely=20 to be scaling problems and its one more thing to go wrong. = You=20 should also have seen me make the point many times in the past that = the=20 always-on defect detection/handling OAM needs to be as simple/sparse = as=20 possible with as little config as possible because we need super=20 reliability......TCM goes completely against the grain here. = Also note=20 that the OAM required for each of the 3 network modes is not the = same,=20 despite what some claim. = regards, Neil = From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009 = 02:59 To:=20 BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Deborah: maybe what you = said is=20 right. but I can't completely agree your opinions. IMO. mpls-tp is = regard as=20 transport network like SDH/SONET. so it should have AIS/FDI fuctions = as=20 SDH/SONET. do you think so. best regards = liu "BRUNGARD, = DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB: = mpls-tp-bounces@ietf.org 2009-04-20 = 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with Neil, it = is very=20 questionable the value of AIS/FDI in a packet network- any mode. = It can=20 result in a DoS attack by an operator on themselves so even Y1731 = recommends not to block data frames: "A MEP can decide whether it = blocks=20 data frames when it detects dAIS. The principle = requirement that=20 influences this decision is that data frames ought to be = forwarded as=20 much as possible, without the possibility of forwarding wrong = data frames=20 downstream." Table I.7-2 shows for AIS, not to block. And = as Y1731=20 states, AIS can only be used under very constrained architectures = - if=20 required for MPLS-TP, it needs to have the same guidance as in = Y1731,=20 i.e. point-to-point and server/client one-to-one: "for a = point-to-point=20 ETH connection, a MEP has only a single peer MEP. Therefore, = there is=20 no ambiguity regarding the peer MEP for which it should = suppress alarms=20 when it receives the ETH-AIS information." So should only be = within=20 one domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten = Vissers Sent:=20 Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional=20 transport path requirements Neil, > but AIS/FDI = in the=20 cl mode?...do me a favour! Ethernet AIS is indeed a = requirement and a=20 necessity. And you will not be able to understand that as long = as you=20 refuse to accept that "cl-mode" is a forwarding mode within a=20 **transport entity**. G.800 amendment 1 = has finally reintroduced this=20 transport entity into G.800. Besides that, it also introduced the = **differentiated connection**: [G.800 am1] "A differentiated=20 connection is a transport entity that transfers information = belonging to=20 multiple communications between ports across a subnetwork. = <..> In=20 a differentiated connection message contents are interpreted = to=20 identify (sets of) communications which = receive different treatment.=20 The sets of communications may be distinguished by = the forwarding=20 identifier or other layer information. Order is=20 not necessarily preserved between messages belonging to sets = of=20 communications receiving different treatment. Sets of=20 communications may be identified for purposes such as traffic=20 conditioning or preserving communication message = order." Ethernet=20 VLANs are in terms of G.800 "differentiated = connections". Ethernet AIS=20 provides AIS within the scope of such "differentiated=20 connection". If you apply this to my proposed PTN layer stack, = then=20 the EVC layer topology will consists of EVC links supported by = MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and = core=20 domains interconnecting EVC matrices. When one of those EVC = links is=20 interrupted, e.g. in the core between metro 1 and metro 4 (see = attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS is = inserted=20 in the downstream direction to suppress the EVC-LOC alarms at EVC = endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) = frame has=20 a reserved multicast address, which guarantees that the AIS is = broadcast=20 to the endpoints of the EVC. I believe that it is time for = you to=20 adapt your view on co and cl modes and relate it to the = forwarding=20 mode **INSIDE** a transport entity. What we know as the = internet is=20 essentially an "IP differentiated connection" with a billion or = more=20 ports. What we know as an IP VPN is essentially an "IP=20 differentiated connection" with e.g. n ports (n in the range = of e.g. 2=20 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in the = range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially = an "MPLS=20 differentiated connection" with 2 ports. What we know as a p2p = SDH=20 VC-n is a "SDH VC-n connection" with 2 ports. Transport = network OAM=20 applies to transport entities, which are (in terms of G.800 = am1)=20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com = [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: = John.E.Drake2@boeing.com;=20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path requirements John, = Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting a = wee bit=20 tired of folks trying to make all 3 network modes look alike = (and=20 then, even worse, interwork them as as peers...esp when not = not=20 top-of-stack networks...I mean how silly can we get?). I = am even=20 more frustrated by the fact those peddling this FUD only ever = seem to=20 consider OAM and forget all other DP/CP/MP components (esp=20 top-of-stack message/file/stream application adaptations). = How=20 wrong can this get! In the co modes a *connection* is a very = specific and *constraining* construct.....I am assuming here we = respect=20 the rules of a connection (ie single source) though some folks = don't=20 even bother to respect this, and this is despite the fact that = we all=20 know what problems multiple-source constructs can cause (from=20 LDP/PHP....ergo MPLS-TP). When we have a connection this = restricts=20 *all* DP (ie traffic and OAM) to stay within the bounds of the = connection. Which is fine under defect-free conditions, = but if=20 we have leaking traffic then the constraining nature of the = connection=20 construct is broken. In a nutshell what this means = is that OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity defects.....indeed, why = should a=20 leaking DP have a symmetric go/return defect = behaviour?....very likely=20 it won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and not = just in=20 OAM requirements....but AIS/FDI in the cl mode?...do me a = favour!...at=20 least IEEE had the good sense to bin this for Ethernet even = though it=20 remains in Y.1731. And which is why I often trot-out the = rather=20 silly (to have to say this) observation that if IP (cl mode) = could do=20 it all then why have IETF found it necessary to create MPLS = (co-ps)=20 and GMPLS (CP for co-cs). The answer lies in the = physics...and=20 G.800 attempts to explain that physics....G.805 does = not. So, the=20 3 modes are different...please accept/rejoice in this fact = as they all=20 offer something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the OAM of = the 3=20 modes the same. regards, Neil > -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > = Sent:=20 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; = Maarten=20 Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > = requirements >=20 > Italo, > > As described in the MPLS TP OAM=20 Requirements I-D, virtually all of the > OAM functions = require a=20 return path, and in the absence of a return > path they are=20 disabled. > > As described in David Sinicrope's meeting = minutes=20 >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP = addressing=20 is used, an > MPLS TP network needs to be capable of getting = IP=20 packets from > destination to source; neither the minutes nor = I=20 stipulate that a > control plane needs to be used to = instantiate this=20 forwarding. > > As an aside, the issue of return path = for=20 unidirectional LSPs could be > charaterized as the = elephant in the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs = are only=20 mentioned three times and return > paths not at all. > = >=20 Thanks, > > John > > -----Original=20 Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April 17,=20 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; = Maarten=20 Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE:=20 [mpls-tp] Associated bidirectional transport path > >=20 requirements > > > > John, > > > = > I=20 might have missed the agreement of MPLS-TP being capable of > = >=20 sending replies to OAM requests sent on uni-directional = LSPs. > >=20 > > This requirement does not belong to the first set of=20 requirements > > ITU-T is expecting to be met by = October. >=20 > > > However, I think this in a potential interesting=20 additional > > requirement to be taken into account (at = worst in=20 a > subsequent phase). > > > > I think that = this=20 requirement needs to be evaluated versus other > > more = important=20 requirements (e.g. the possibility to work w/o IP > > = forwarding=20 and the need for OAM to continue to monitor the data > > = plane=20 also in case of failures affecting the control or management = > >=20 plane). > > > > I am open to discuss it but not = sure this=20 is the right time because > > I wish to avoid delaying the = first=20 phase of the design solution. > > > > Thanks,=20 Italo > > > > > -----Original = Message----- >=20 > > From: mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > = >=20 > Sent: Thursday, April 16, 2009 8:00 PM > > > To: = Alexander=20 Vainshtein; Maarten Vissers > > > Cc: = mpls-tp@ietf.org >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > requirements > > > > > > = At the=20 meeting last fall at Juniper in Massachusetts, I > > think = it=20 was > > > agreed that an MPLS TP network needs to have a = forwarding > > capability > > > for management, = control, and OAM packets (e.g., sending > > replies to = OAM >=20 > > requests sent on uni-directional LSPs) even if it does = not >=20 > have an IP > > > forwarding data plane. > = > >=20 > > > > -----Original Message----- > > > = >=20 From: Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = > >=20 > > requirements > > > > > > > = >=20 Maarten, > > > > It seems that you've just = (implicitly and,=20 probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will not = ever=20 support MIP loopback function > > (and fault > > = > >=20 localization which requires this function ) for > > = unidirectional=20 P2MP > > > > and P2P paths. > > > > = >=20 > > > If this statement is correct, this (IMHO and = FWIW) >=20 raises a valid > > > > question: > > > = >=20 > > > > = =20 Is MPLS-TP an appropriate solution for these > = types of=20 transport > > > > paths? > > > > = > >=20 > > For the reference, IP/MPLS provides this kind of > = >=20 functionality today > > > > for (unidirectional - but = it does=20 not know any other > > type) P2P LSPs > > > = > as=20 described in RFC 4379. And its extension to P2MP LSPs seems > = >=20 > > easy... > > > > > > > >=20 > > > > > > > > = Regards, > >=20 > > > > > > Sasha > = >=20 > > > > > > > > > > > = > >=20 > ________________________________________ > > > > = From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: Thursday, = April=20 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > = >=20 > > Cc: mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > = Adrian, >=20 > > > > > > > >> = <quote> > >=20 > > >> The intermediate nodes = (including=20 MEPs, MIPs and > > > > other internal > > = > >=20 >> functions as appropriate) of a=20 co-routed > > > > bidirectional transport > = > >=20 > >> path at each (sub-)layer MUST be = aware of=20 the pairing > > > > >> =20 relationship of the forward and the backward > > > >=20 directions of that > > > > >> = =20 transport path. > > > > >> <end = quote> >=20 > > > > > > > > > There is no way this = is a=20 functional requirement. That > > > is, there is > = >=20 > > > *nothing* that can be observed from a black box point = of > > > view that > > > > > results = from=20 adhering to this requirement. > > > > > > = > >=20 Your understanding is not correct. It is very much > = observable=20 if > > > > this requirement is met from a black box = point of=20 view. > > > > The MIP functions can only perform the = Loopback=20 when there is a > > > > co-routed bidirectional = transport=20 path. The MPLS-TP LBM packet > > > > received at a = MIP needs=20 to be returned (as LBR > > > > packet) to the = originating MEP=20 function via the other > > direction of > > > = > the=20 co-routed bidirectional transport path. This other > = direction >=20 > > > would not be available in an associated bidirectional = transport > > > > path... and thus the loopback = test >=20 > > would fail. > > > > > > > > = Similarly, when we have to apply TCM MEPs to monitor a > > = segment,=20 then > > > > this is possible in a co-routed bidir = transport=20 path > but not in a > > > > associated bidir = transport=20 path. In the first case the TCM MEP > > > > Source = and Sink=20 functions are co-located and can > exchange what is > = > >=20 > called "remote information" which is necessary for performance = >=20 > > > monitoring. > > > > In the latter case = the TCM=20 MEP Source and Sink functions > > are in e.g. > > = >=20 > different nodes in the network and TCM would not be = able > >=20 to provide > > > > performance monitoring. > = > >=20 > > > > > > The entirety of the bracketted = text=20 "(including MEPs, > > > MIPs and other > > > = >=20 internal > > > > > functions as appropriate)" = should be=20 deleted. It does not > > > > add to "The > > = >=20 > > intermediate nodes." > > > > > > = >=20 > Your understanding is not correct. This text must not = be > >=20 deleted at > > > > all. > > > > = > >=20 > > > Actually, I am quite fed up about this = persistent >=20 > > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > > = is >=20 > > > poorly > > > > > specified and = comes from=20 the monitoring of a path that is > > > > parallel=20 (i.e. > > > > tandem) > > > > > to = the data=20 path being monitored. This definition of TC > > > > = seems to=20 be at > > > > variance, > > > > > = and would=20 be if the ACH was actually in band. > > > > > = >=20 > > I don't understand where your interpretation of = tandem >=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of a > = >=20 > > path that is parallel (i.e. tandem) to the data path being = > > > > monitored."? > > > > > = >=20 > > There is a "network connection" and this network > = >=20 connection is a set > > > > of interconnected "link=20 connections" and "matrix > connections". A > > > = >=20 subset of those interconnected link connections and matrix > = >=20 > > connections can be monitored and is then referred to = as > a=20 "tandem > > > > connection". There is no "path that = is=20 parallel to the > > data path". > > > > = There is=20 only additional OAM inserted inside the data > path by = the >=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM MEP_Sk=20 function. > > > > > > > > = Regards, >=20 > > > Maarten > > > > > > > = >=20 > > > > -----Original Message----- > > > = >=20 From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > = >=20 > > Sent: donderdag 16 april 2009 11:59 > > > > = To:=20 Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > >=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > = Unfortunately I=20 cannot fully agree with your statement: > > > > = > >=20 > > > > <quote> > > > > > = =20 From the point of view of hardware, co-routed > > >=20 bidirectional LSPs > > > > > are a = special=20 case of associated bidirectional LSPs. > > > > > = <end=20 quote> > > > > > > > > > > = This=20 statement would be obviously correct, were it not for > > = > >=20 Requirement > > > > > 34 in the latest MPLS-TP=20 requirements draft > > > > > > > > = OK. Got=20 it. > > > > > > > > But what is this = doing in=20 the data plane requirements section? > > > > > = >=20 > > In fact, what is this requirement actually saying? > = >=20 > > > > > > > <quote> > > = > >=20 > The intermediate nodes (including MEPs, = MIPs=20 and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > > = >=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > = >=20 > > > relationship of the forward and = the=20 backward > > > > directions of that > > > = >=20 > transport path. > > > > = >=20 <end quote> > > > > > > > > = There is no=20 way this is a functional requirement. That > > is, there = is >=20 > > > *nothing* that can be observed from a black box point = of > > view that > > > > results from = adhering to=20 this requirement. > > > > > > > > = Therefore=20 it could be assumed that this requirement is met by > > = > >=20 configuring some data plane database component through the > = >=20 > > management plane. The database component is not = used > for=20 anything > > > > except to satisfy this requirement = for=20 "awareness". > > > > > > > > Ben! Can = we=20 please try to rewrite this requirement in terms of > > = > >=20 behavior? > > > > > > > > > Please = note=20 that Requirement 34 is the ONLY item in the > > > > = list that=20 is > > > > > specific for co-routed bidirectional = LSPs.=20 (The pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = > >=20 paths are > > > > > exactly the same even if they = appear=20 in two different > > > items in the > > > = > >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > = > >=20 bidirectional paths would be void of any data plane content. > = >=20 > > > > > > > > The somewhat vague scope = of this=20 requirement ("other internal > > > > > functions = as=20 appropriate") creates a suspicion that HW > > > > = support of=20 the > > > > > pairing awareness may be required in = order=20 to comply with it. > > > > > > > > = The=20 entirety of the bracketted text "(including MEPs, > > MIPs = and=20 other > > > > internal functions as appropriate)" = should be=20 deleted. It > > does not > > > > add to "The = intermediate nodes." > > > > > > > > = > The=20 following text in the draft increases this suspicion: > > = > >=20 > > > > > > <quote> > > > = > >=20 Tandem Connection: A tandem connection is an > > = arbitrary=20 part of a > > > > > transport path that can = be=20 monitored (via OAM) > > > > independently from = the >=20 > > > > end-to-end monitoring (OAM). It may = be a=20 monitored > > segment or a > > > > > = =20 monitored concatenated segment of a transport path. > = > The=20 tandem > > > > > connection may also = include the=20 forwarding engine(s) of > > > > the node(s) > = > >=20 > > at the edge(s) of the segment or concatenated=20 segment. > > > > > <end quote> > > = >=20 > > > > > Actually, I am quite fed up about this=20 persistent > > insistence on the > > > > = inclusion=20 of "Tandem Connection." The definition within > > the ITU-T = of > > > > this term is poorly specified and comes = from=20 the > monitoring of a > > > > path that is = parallel=20 (i.e. tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > > = >=20 > > > > > Doesn't "forwarding engine" sound like = hardware=20 to you? > > > > > > > > Yes, but so=20 what? > > > > > > > > > IMHO it is = worth=20 noting that neither the MPLS-TP > > > Requirements = draft >=20 > > > > nor the MPLS-TP OAM requirements one > = > >=20 > > > > > > > > > > > = >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing with = tandem > > > connections. > > > > = > >=20 > > > > But tandem connections are discussed in the = MPLS-TP=20 OAM > > Framework > > > > > draft > = >=20 > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > = >=20 > > amework-00.txt > > > > ). > > > = >=20 > > > > Right. > > > > Let's just get = rid of=20 an unnecessary term and bring all > the I-Ds > > > = >=20 into line. > > > > > > > > > The = bottom=20 line, IMHO, is that some clarity regarding > > > = co-routed=20 vs. > > > > > associated > > > > = >=20 bidirectional paths is still required. One way to provide > = > >=20 > that could > > > > > be by explicitly = limiting=20 Requirement 34 to specific > > > functionality. > = >=20 > > > > > > Agreed. > > > > = >=20 > > > Adrian > > > > > > > > = > > > > > > > > > > > = >=20 ________________________________________ > > > > = From: Adrian=20 Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, = April=20 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; = Lou=20 Berger; BUSI ITALO > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > > = >=20 > > Hi Sasha, > > > > > > > > = Not=20 really sure whether you are misrepresenting anyone, but... > = > >=20 > > > > > > 1. My reading of one of = Ben's=20 messages is that associated > > > > > = bidirectional=20 paths are the only types of paths that can be > > > > = created=20 in > > > > > the existing networks; "true" = co-routed=20 bidirectional paths > > > > will have > > = > >=20 > to wait until (if ever) new equipment becomes = available. > >=20 > > > > > > This is clearly nonsense! > = >=20 > > From the point of view of hardware, co-routed > > = bidirectional LSPs are > > > > a special case of = associated=20 bidirectional LSPs. > > > > > > > > = If you=20 can set up two unidirectional LSPs (e.g. using the > >=20 management > > > > plane) you can surely set up a=20 co-routed > > > bidirectional LSP. > > > = >=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using = the=20 control plane. These either use the GMPLS > > (which = is >=20 > > > cleaner) or non-standard proprietary solutions (which = is > > messy but > > > > = functional). > >=20 > > > > > > But (of course) the management = plane or=20 control plane > > solutions have > > > > = nothing to=20 do with availability of equipment as they > are software > > > > = solutions. > >=20 > > > > > > > 2. My reading of one of = Neil's=20 messages is that the actual > > > > driver = for > >=20 > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any = specific=20 benefit. > > > > > > > > Isn't that = the case=20 with 75% of the MPLS-TP requirements? > > > > Which = is not to=20 say it is a bad thing. > > > > > > > = > A=20 large driver for MPLS-TP is to give the packet network > > = the=20 look, > > > > feel, and behavioral characteristics of = a=20 "legacy" > > > > transport network. > > > = >=20 > > > > > Based on these observations, I'd guess = (FWIW)=20 that: > > > > > * associated bidirectional paths = are, at=20 least for the time > > > > > being, = the most=20 important type of bidirectional paths in > > > > > = =20 MPLS-TP > > > > > > > > I think = that is=20 wrong both given my statement above, and > > given = that >=20 > > > other upgrades to existing MPLS solutions will = be >=20 needed to reach > > > > the full function level of=20 MPLS-TP. > > > > > > > > > * they = had a=20 good chance to remain the only type of > > = bidirectional >=20 > > > > paths in real deployments. > = >=20 > > > > > > I don't see what that follows=20 from. > > > > > > > > Cheers, > = >=20 > > Adrian > > > > > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > = >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > = >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = >=20 > > = _______________________________________________ >=20 mpls-tp mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this mail = is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy and=20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify = the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender. This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9C4C8.3486BA16-- From Martin.Vigoureux@alcatel-lucent.com Fri Apr 24 04:12:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082EB3A6FFC; Fri, 24 Apr 2009 04:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeXwbBp53d2V; Fri, 24 Apr 2009 04:12:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 71B8F3A6FFF; Fri, 24 Apr 2009 04:11:14 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3OBCSZ8011888; Fri, 24 Apr 2009 13:12:28 +0200 Received: from [135.244.36.16] ([135.244.36.16]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 13:12:27 +0200 Message-ID: <49F19E8F.7050105@alcatel-lucent.com> Date: Fri, 24 Apr 2009 13:12:15 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2009 11:12:28.0253 (UTC) FILETIME=[8DC3D0D0:01C9C4CD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: ccamp@ops.ietf.org, l2vpn@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: [mpls-tp] IETF 74 - MPLS WG minutes X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 11:12:12 -0000 all, the minutes of the mpls wg sessions are available on-line: http://tools.ietf.org/wg/mpls/minutes Please have a look at them and let me know if you would like additional details to be reflected. Three slide sets are still missing, I'll contact the presenters and upload them as soon as I receive them. regards, martin From neil.2.harrison@bt.com Fri Apr 24 05:30:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D878C3A67F1 for ; Fri, 24 Apr 2009 05:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=-1.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHgg8wrKkctP for ; Fri, 24 Apr 2009 05:30:03 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 79A723A733C for ; Fri, 24 Apr 2009 05:30:02 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 13:31:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C4D8.90E903CF" Date: Fri, 24 Apr 2009 13:31:14 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0479D2B3@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAE7+hA From: To: , X-OriginalArrivalTime: 24 Apr 2009 12:31:19.0233 (UTC) FILETIME=[91A61310:01C9C4D8] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 12:30:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C4D8.90E903CF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmdWxseSBhZ3JlZSB3aXRoIEFuZHkgb24gdGhpcy4NCiANCnJlZ2FyZHMsIE5laWwNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJRnJvbTogbXBscy10cC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg YW5keS5iZC5yZWlkQGJ0LmNvbQ0KCVNlbnQ6IDI0IEFwcmlsIDIwMDkgMTE6MzQNCglUbzogbWFh cnRlbi52aXNzZXJzQGh1YXdlaS5jb20NCglDYzogbXBscy10cEBpZXRmLm9yZw0KCVN1YmplY3Q6 IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJl cXVpcmVtZW50cw0KCQ0KCQ0KCU1hYXJ0ZW4sDQoJIA0KCVRoZXNlIHBvaW50cyBhcmUgaXJyZWxl dmFudCB0byB0aGUgcG9pbnRzIEkgbWFkZS4gTXkgcG9pbnQgaXMgdGhhdCBBSVMvRkRJIGdpdmVz IG5vIGluZm9ybWF0aW9uIGFib3ZlIHdoYXQgaXMgYWxyZWFkeSBrbm93biAtIGl0IGlzIG9ubHkg YWRkcyBjb21wbGV4aXR5IGFuZCBmYXVsdCBsaWFiaWxpdHkuIE5laXRoZXIgb2YgeW91ciBwb2lu dHMgY2hhbmdlIHRoaXMuDQoJIA0KCUFuZHkNCgkgDQoJIA0KDQoJQW5keSBSZWlkIA0KCUNoaWVm IE5ldHdvcmsgU2VydmljZXMgU3RyYXRlZ2lzdCANCglCVCBJbm5vdmF0ZSANCgkgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoJT2ZmaWNlOiArNDQgKDApMTI3NyAzMjIwMzggDQoJ TW9iaWxlOiArNDQgKDApNzkxNyAwMjU0NTEgDQoJRmF4IDogICAgICAgKzQ0ICgwKTEyNzcgMzI0 MDE1IA0KCUVtYWlsOiAgYW5keS5iZC5yZWlkQGJ0LmNvbSANCg0KCQ0KCUJyaXRpc2ggVGVsZWNv bW11bmljYXRpb25zIHBsYw0KCVJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBM b25kb24gRUMxQSA3QUoNCglSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm8uIDE4MDAwMDAgDQoJVGhp cyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gZnJvbSBCcml0aXNoIFRl bGVjb21tdW5pY2F0aW9ucyBwbGMgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50 aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcs IGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24g aXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbGVjdHJvbmljIG1lc3Nh Z2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgYnkgdGVsZXBob25lIG9yIGVtYWlsICh0byB0 aGUgbnVtYmVycyBvciBhZGRyZXNzIGFib3ZlKSBpbW1lZGlhdGVseS4NCg0KCUFjdGl2aXR5IGFu ZCB1c2Ugb2YgdGhlIEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYyBlbWFpbCBzeXN0ZW0g aXMgbW9uaXRvcmVkIHRvIHNlY3VyZSBpdHMgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90 aGVyIGxhd2Z1bCBidXNpbmVzcyBwdXJwb3Nlcy4gQ29tbXVuaWNhdGlvbnMgdXNpbmcgdGhpcyBz eXN0ZW0gd2lsbCBhbHNvIGJlIG1vbml0b3JlZCBhbmQgbWF5IGJlIHJlY29yZGVkIHRvIHNlY3Vy ZSBlZmZlY3RpdmUgb3BlcmF0aW9uIGFuZCBmb3Igb3RoZXIgbGF3ZnVsIGJ1c2luZXNzIHB1cnBv c2VzLg0KDQoJIA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCgkJRnJv bTogTWFhcnRlbiBWaXNzZXJzIFttYWlsdG86bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dIA0K CQlTZW50OiAyMyBBcHJpbCAyMDA5IDIwOjQyDQoJCVRvOiBSZWlkLEFCRCxBbmR5LENYTSBSDQoJ CUNjOiBtcGxzLXRwQGlldGYub3JnDQoJCVN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KCQkNCgkJDQoJCUFu ZHksDQoJCSANCgkJPiBUaGUgcHJvYmxlbSBpcyAqbm90KiBhYm91dCBhIGxhY2sgb2YgYWxhcm0g c3VwcHJlc3Npb24gaW4gdGhlIGRhdGEgcGxhbmUgLSB0aGF0IGluZm9ybWF0aW9uIGlzIHJlYWRp bHkgYXZhaWxhYmxlLg0KCQkgDQoJCUkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgYSBjb3Jy ZWN0IHN0YXRlbWVudCBpbiBhIG11bHRpLW9wZXJhdG9yIHRyYW5zcG9ydCBuZXR3b3JrLCBvciBp biB0cmFuc3BvcnQgbmV0d29ya3Mgb2Ygb25lIG9wZXJhdG9yIHRoYXQgaGF2ZSBtb3JlIHRoZW4g b25lIGFkbWluaXN0cmF0aXZlIHN1YmRvbWFpbiAoZWFjaCB3aXRoIGl0cyBvd24gbmV0d29yayBt YW5hZ2VtZW50IHN5c3RlbSkuIEEgcHJvYmxlbSBvY2N1cmluZyBpbiBhZG1pbiBkb21haW4gQSB3 aWxsIGJlIHVua25vd24gaW4gYWRtaW4gZG9tYWluIEIuIFRoZSBsb3NzIG9mIGNvbnRpbnVhaXR5 IGFsYXJtcyB0aGF0IGFyZSBhY3RpdmF0ZWQgaW4gYWRtaW4gZG9tYWluIEIgZHVlIHRvIHRoZSBm YXVsdCBpbiBhZG1pbiBkb21haW4gQSB3aWxsIGFwcGVhciBhcyBwcmltYXJ5IGFsYXJtcywgc3Vn Z2VzdGluZyBjb25uZWN0aXZpdHkgcHJvYmxlbXMgaW4gYWRtaW4gZG9tYWluIEIuDQoJCSANCgkJ PiBUaGUgaXNzdWUgYXJpc2VzIGJlY2F1c2UgdGhlIHR3byBzaWRlcyBvZiBtYWludGVuYW5jZSB3 YW50IGRpZmZlcmVudCB0aGluZ3MuIFRoZSBmYXVsdCBmaXhpbmcNCgkJPiBndXlzIHdhbnQgdG8g bG9jYXRlIHRoZSBmYXVsdCBhbmQgZG9uJ3Qgd2FudCBhbnkgb3RoZXIgaW5mb3JtYXRpb24uIFRo ZSBzZXJ2aWNlIG1haW50ZW5hbmNlDQoJCT4gZ3V5cyB3YW50IHRvIGtub3cgd2hldGhlciB0aGVp ciBjdXN0b21lciBzZXJ2aWNlIGlzIHdvcmtpbmcuDQoJCSANCgkJVGhpcyBpcyBhZGRyZXNzZWQg aW4gU0RILCBPVE4sIEV0aGVybmV0IGFuZCBULU1QTFMgcmVjb21tZW5kYXRpb25zIGJ5IG1lYW5z IG9mIHRoZSBhZGRpdGlvbmFsIFNTRiBhbGFybS4gVGhlIFNTRiBhbGFybSBpcyBmb3IgdGhlIHNl cnZpY2UgZ3V5cyB0ZWxsaW5nIHRoZW0gdGhhdCB0aGUgc2VydmljZSB3YXMgaW50ZXJydXB0ZWQg ZHVlIHRvIGEgZmF1bHQgaW4gYSBzZXJ2ZXIgbGF5ZXIuIEFJUyBzdXBwcmVzc2VzIHRoZSBMT0Mg YWxhcm0gaW4gdGhvc2UgY2FzZXMgc28gdGhhdCB0aGUgbWFpbnRlbmFuY2UgZ3V5cyBkb24ndCBn ZXQgdHJpZ2dlcmVkIGFuZCBzdGFydCBsb29raW5nIGZvciBhIGZhdWx0IHRoYXQgaXMgb3V0c2lk ZSB0aGVpciBhcmVhLg0KCQkgDQoJCVJlZ2FyZHMsDQoJCU1hYXJ0ZW4NCgkJIA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJCUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGFuZHku YmQucmVpZEBidC5jb20NCgkJU2VudDogd29lbnNkYWcgMjIgYXByaWwgMjAwOSAxMjoxNA0KCQlU bzogbGl1Lmd1b21hbkB6dGUuY29tLmNuOyBuZWlsLjIuaGFycmlzb25AYnQuY29tDQoJCUNjOiBt cGxzLXRwQGlldGYub3JnDQoJCVN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KCQkNCgkJDQoJCUxpdSwNCgkJ IA0KCQlBbGxvdyBtZSB0byBqdW1wIGluLiBZb3UgYXJlIGJyaW5naW5nIHRvZ2V0aGVyIHR3byB0 aGluZ3Mgd2hpY2ggYXJlIHNlcGFyYXRlIGFuZCBmb3Igd2hpY2ggQUlTL0ZESSBpcyBubyBoZWxw LiBNYWludGVuYW5jZSBvcGVyYXRpb25zIGFyZSBjb25jZXJuZWQgd2l0aCB0d28gc2VwYXJhdGUg dGhpbmdzLg0KCQkgDQoJCTEpICBJZGVudGlmeWluZyBmYXVsdHMgaW4gZXF1aXBtZW50LCBsaW5l IHBsYW50LCBhbmQgb3RoZXIgc3lzdGVtcyAoZWcgbWlzY29uZmlndXJhdGlvbnMpIGFuZCBmaXhp bmcgdGhlbSAoZXF1aXBtZW50IG1haW50ZW5hbmNlKS4NCgkJMikgIElkZW50aWZ5aW5nIHRoZSBo ZWFsdGggb2YgZW5kIHRvIGVuZCBjb25uZWN0aW9ucywgZXNwZWNpYWxseSB3aGVuIHRoZXkgYXJl IGRpcmVjdGx5IHN1cHBvcnRpbmcgY3VzdG9tZXIgc2VydmljZXMgKHNlcnZpY2UgbWFpbnRlbmFu Y2UpLg0KCQkgDQoJCVRoZSBwcm9ibGVtIGlzICpub3QqIGFib3V0IGEgbGFjayBvZiBhbGFybSBz dXBwcmVzc2lvbiBpbiB0aGUgZGF0YSBwbGFuZSAtIHRoYXQgaW5mb3JtYXRpb24gaXMgcmVhZGls eSBhdmFpbGFibGUuIElmLCBhdCBhbiBlbmQgZXF1aXBtZW50LCBJIGhhdmUgYSBnb29kIHNlcnZl ci9zZWN0aW9uIGxheWVyIGFuZCBhIGxvc3Mgb2YgQ0MgYXQgdGhlIGNsaWVudCBsYXllciwgSSAq a25vdyogdGhlIGZhdWx0IGlzIGVsc2V3aGVyZSAtIEkgZG9uJ3QgbmVlZCBBSVMvRkRJIHRvIHRl bGwgbWUuIChJbmRlZWQsIGlmIHlvdSB0aGluayBhYm91dCwgaWYgdGhlIGZhdWx0IGlzIGluIHRo ZSBlbmQgZXF1aXBtZW50LCBpdCBpcyBxdWl0ZSBsaWtlbHkgdGhhdCB0aGUgZmF1bHQgbWVhbnMg aXQgY2Fubm90IHJlcG9ydCB0aGUgdHJhZmZpYyBsb3NzIHRvIHRoZSBtYW5hZ2VtZW50IHN5c3Rl bSEpDQoJCSANCgkJVGhlIGlzc3VlIGFyaXNlcyBiZWNhdXNlIHRoZSB0d28gc2lkZXMgb2YgbWFp bnRlbmFuY2Ugd2FudCBkaWZmZXJlbnQgdGhpbmdzLiBUaGUgZmF1bHQgZml4aW5nIGd1eXMgd2Fu dCB0byBsb2NhdGUgdGhlIGZhdWx0IGFuZCBkb24ndCB3YW50IGFueSBvdGhlciBpbmZvcm1hdGlv bi4gVGhlIHNlcnZpY2UgbWFpbnRlbmFuY2UgZ3V5cyB3YW50IHRvIGtub3cgd2hldGhlciB0aGVp ciBjdXN0b21lciBzZXJ2aWNlIGlzIHdvcmtpbmcuDQoJCSANCgkJVGhpcyBhcm9zZSBpbiB0aGUg ZWFybHkgZGF5cyBvZiBTT05FVC9TREgsIHdoZW4gdGhlIG9wZXJhdGlvbnMgZ3V5cyBkZW1hbmRl ZCB0aGF0IHRoZSBlcXVpcG1lbnQgZGlkICpub3QqIHN1cHByZXNzIHRoZSB0cmFmZmljIGFsYXJt IGV2ZW4gd2hlbiBBSVMgd2FzIGJlaW5nIHJlY2VpdmVkIGFzIHRoZSBzZXJ2aWNlIGd1eXMgd2Fu dCB0byBrbm93IGFib3V0IHRoZSBhbGFybXMuIFRoZSBub3JtYWwgcHJhY3RpY2UgaXMgZm9yIHRo ZSBlcXVpcG1lbnQgdG8gcmVwb3J0IHRoZSBhbGFybXMgKmluY2x1ZGluZyogQUlTIGFuZCB0aGVu IGEgZmlsdGVyIGlzIGFwcGxpZWQgaW4gdGhlIG1hbmFnZW1lbnQgc3lzdGVtIHRvIHN1cHByZXNz IGFsYXJtcyB0byB0aGUgZmF1bHQgZml4aW5nIGd1eXMuIEFzIEknbSBhd2FyZSwgdGhlcmUgYXJl IG1hbnkgZGlmZmVyZW50IHRlY2huaXF1ZXMgYXBwbGllZCBmb3IgdGhlIGZpbHRlcmluZyBhbGdv cml0aG1zLCBlc3BlY2lhbGx5IHdoZW4geW91IGNvbnNpZGVyIG11bHRpcGxlIGNvbmN1cnJlbnQg ZmF1bHRzIGluIGEgbmV0d29yaywgaG93ZXZlciwgdGhlIGV4aXN0YW5jZSBvZiBBSVMvRkRJIGRv ZXNuJ3QgYWRkIGFueXRoaW5nIHRvIHRoZXNlIHRoYXQncyBub3QgYWxyZWFkeSBrbm93bi4gSW4g ZmFjdCwgSSBiZWxpZXZlIHNpbXBsZSB0aW1lLXN0YW1wIGNvcnJlbGF0aW9uIGlzIG9uZSBvZiB0 aGUgbW9zdCBwb3dlcmZ1bCBhbmQgd2lkZWx5IHVzZWQgdGVjaG5pcXVlcy4gQW5kIGlmIHRoZSBl cXVpcG1lbnQgc3RhcnRzIG1lc3NpbmcgdXAgdGhlIHJlcG9ydGluZyBvZiBsb3NzIG9mIENDIGJl Y2F1c2UgaXQgd2FpdGluZyBmb3IvcGVyc2lzdGVuY2UgY2hlY2tpbmcgQUlTL0ZESSwgaXQgY291 bGQgZW5kIHVwIG1lc3NpbmcgdXAgc2ltcGxlIHRpbWUtc3RhbXAgY29ycmVsYXRpb24hIA0KCQkg DQoJCUluIHByYWN0aWNlLCBpdCBpcyBvZnRlbiBub3QgcXVpdGUgYSBzaW1wbGUgYXMgdGhpcywg YXMgdGhlIHNlcnZpY2UgZ3V5cyBsaWtlIHRvIGJlIGFibGUgdG8gJ2xvY2FsaXNlJyB0aGUgZmF1 bHQuIEhvd2V2ZXIsIHVuZGVyIG1vc3QgY2lyY3Vtc3RhbmNlcywgdGhlIGZpbHRlciBoYXMgYXV0 b21hdGljYWxseSBkb25lIHRoaXMuIFNvIGxvY2FsaXNhdGlvbiB5b3UgZGVzY3JpYmUgaXMgb25s eSB3aGVuIHRoZSBmaWx0ZXIgaGFzbid0IHdvcmtlZCBmb3Igc29tZSByZWFzb24uDQoJCSANCgkJ QnV0IHRoZSBib3R0b20gbGluZSBpcywgd2hhdGV2ZXIgb3BlcmF0aW9ucyBwcm9jZXNzIHlvdSB3 YW50IHRvIHVzZSwgQUlTL0ZESSBkb2Vzbid0IGFkZCBhbnl0aGluZyBvdGhlciB0aGFuIGNvbXBs ZXhpdHkgYW5kIGZhdWx0IGxpYWJpbGl0eSB0byB0aGUgZXF1aXBtZW50LiBSZW1lbWJlciBBSVMg Z29lcyBiYWNrIHRvIHRoZSBURE0gd29ybGQgd2hlcmUgeW91ICpoYXZlIHRvIGZpbGwgdGhlIGJp dCBzdHJlYW0gd2l0aCBzb21ldGhpbmcqLg0KCQkgDQoJCSANCgkJIA0KCQlBbmR5DQoJCSANCg0K CQlBbmR5IFJlaWQgDQoJCUNoaWVmIE5ldHdvcmsgU2VydmljZXMgU3RyYXRlZ2lzdCANCgkJQlQg SW5ub3ZhdGUgDQoJCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCgkJT2ZmaWNl OiArNDQgKDApMTI3NyAzMjIwMzggDQoJCU1vYmlsZTogKzQ0ICgwKTc5MTcgMDI1NDUxIA0KCQlG YXggOiAgICAgICArNDQgKDApMTI3NyAzMjQwMTUgDQoJCUVtYWlsOiAgYW5keS5iZC5yZWlkQGJ0 LmNvbSANCg0KCQkNCgkJQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQoJCVJlZ2lzdGVy ZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNCgkJUmVnaXN0ZXJl ZCBpbiBFbmdsYW5kIG5vLiAxODAwMDAwIA0KCQlUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250 YWlucyBpbmZvcm1hdGlvbiBmcm9tIEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYyB3aGlj aCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBp bnRlbmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkg bmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdh cmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0 aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB1cyBieSB0ZWxlcGhvbmUgb3IgZW1haWwgKHRvIHRoZSBudW1iZXJzIG9yIGFkZHJlc3MgYWJv dmUpIGltbWVkaWF0ZWx5Lg0KDQoJCUFjdGl2aXR5IGFuZCB1c2Ugb2YgdGhlIEJyaXRpc2ggVGVs ZWNvbW11bmljYXRpb25zIHBsYyBlbWFpbCBzeXN0ZW0gaXMgbW9uaXRvcmVkIHRvIHNlY3VyZSBp dHMgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBidXNpbmVzcyBwdXJw b3Nlcy4gQ29tbXVuaWNhdGlvbnMgdXNpbmcgdGhpcyBzeXN0ZW0gd2lsbCBhbHNvIGJlIG1vbml0 b3JlZCBhbmQgbWF5IGJlIHJlY29yZGVkIHRvIHNlY3VyZSBlZmZlY3RpdmUgb3BlcmF0aW9uIGFu ZCBmb3Igb3RoZXIgbGF3ZnVsIGJ1c2luZXNzIHB1cnBvc2VzLg0KDQoJCSANCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJCQlGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaXUu Z3VvbWFuQHp0ZS5jb20uY24NCgkJCVNlbnQ6IDIyIEFwcmlsIDIwMDkgMDk6MTUNCgkJCVRvOiBI YXJyaXNvbixOLE5laWwsQ1hNIFINCgkJCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJCQlTdWJqZWN0 OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCBy ZXF1aXJlbWVudHMNCgkJCQ0KCQkJDQoNCgkJCU5laWw6IA0KCQkJICB0aGFuayB5b3UgZm9yIHdh c3RpbmcgbW9yZSB0aW1lIGluIGRlc2NyaWJsaW5nIHRoZSBwcm9ibGVtcy4gYnV0IEkgdGhpbmsg c29tZSBvZiB3aGF0IHlvdSBzYWlkIGlzIG5vIHJlbGF0aW9ucyB3aXRoIG91ciBwcm9ibGVtLmZv ciBtZSwgbWF5YmUgQUlTL0ZESSBmdW5jdGlvbnMgaXMgbm8gc2Vuc2UgaW4gY2wtcHMgLGVnLiBJ UC4gYnV0IGZvciBDTy1QUyBuZXR3b3Jrcy5pZiB0aGVyZSBpcyBubyBBSVMvRkRJIGZ1bmN0aW9u cywgd2hlbiB0aGVyZSBpcyBhIGRlZmVjdHMgaW4gYSBnaXZlbiBsYXllciBuZXR3b3JrLCBpdCBj YW4gY2F1c2UgbXVsdGlwbGUgYWxhcm0gZXZlbnRzIHRvIGJlIHJhaXNlZC4gaXQgaXMgZGlmZmN1 bHQgIGZvciBvcGVyYXRvcnMgdG8gbG9jYXRlIGFuZCBkaWFnbm9zZSB0aGUgZmF1bHRzLiANCgkJ CSB0aG91Z2ggSSBjb21wbGV0ZWx5IGFncmVlIHlvdSBvbiAgYWRkaW5nIG5ldyB0aGluZ3MgYW5k IGZ1bmN0aW9ucyB3aWxsIGJyaW5nIHNvbWUgY29tcGxleGl0eSAuIGJ1dCBpZiB3ZSBoYXZlIG5v IGZ1bmN0aW9ucywgaXQgaXMgbW9yZSBjb21wbGV4IGFuZCBkaWZjdWx0IGZvciBvcGVyYXRvcnMg dG8gbWFpbnRlbmNlIGFuZCBhZG1pbmlzdHJhdG9yIHRoZSBuZXR3b3JrLiBzbyBJIHRoaW5rIGV2 ZXJ5IG5ldyBmdW5jdGlvbnMgYW5kIHRoaW5ncyBtYXkgaGF2ZSBwb3NpdGl2ZSBhbmQgbmVnYXRp dmUgZWZmZWN0cy4gYnV0IHdlIHNob3VsZCBjb25zaWRlciBpdCB2ZXJ5IG11Y2gsIGRvbid0IGRl bGV0ZSBzb21lIGZ1bmN0aW9ucyBhdCByYW5kb20uIA0KCQkJDQoJCQkNCgkJCWJlc3QgcmVnYXJk cyANCgkJCWxpdSANCgkJCQ0KCQkJDQoJCQkNCjxuZWlsLjIuaGFycmlzb25AYnQuY29tPiANCg0K MjAwOS0wNC0yMSAyMDozMCANCg0K5pS25Lu25Lq6DQo8bGl1Lmd1b21hbkB6dGUuY29tLmNuPiwg PGRicnVuZ2FyZEBhdHQuY29tPiANCuaKhOmAgQ0KPG1wbHMtdHBAaWV0Zi5vcmc+IA0K5Li76aKY DQpSRTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCBy ZXF1aXJlbWVudHMJDQoNCgkJDQoNCg0KDQoNCgkJCUxpdSwgDQoJCQkgIA0KCQkJSWYgTVBMUy1U UCBpcyBnb2luZyB0byBiZSB0YWtlbiBzZXJpb3VzbHkgYXMgYSB0cmFuc3BvcnQgbmV0d29yayAo bGlrZSBTREgvU09ORVQpIHRoZW4gdGhlIDIga2V5IE1VU1QgSEFWRSByZXF1aXJlbWVudHMgYXJl IHRoZXNlLiANCgkJCSAgDQoJCQkxICAgIFByb3ZpZGUgYSB0cmFuc3BhcmVudCBjbGllbnQvc2Vy dmVyIHJlbGF0aW9uc2hpcC4uLndoaWNoIG1lYW5zOiANCgkJCS0gICAgYWxsIGNsaWVudCBiaXRz IHRyZWF0ZWQgZXF1YWxseSANCgkJCS0gICAgY2xpZW50IGJpdCBvcmRlcmluZyBwcmVzZXJ2ZWQg DQoJCQktICAgIG5vIGF0dGVtcHQgdG8gaW5mZXIgY2xpZW50IHN5bWJvbCAoaWUgc2VxdWVuY2Ug b2YgY2xpZW50IGJpdHMpIG1lYW5pbmcgYW5kIG5vIGF0dGVtcHQgdG8gY2hhbmdlIGNsaWVudCBz eW1ib2xzIA0KCQkJLSAgICB0aGUgdHJhZmZpYyBiZWhhdmlvdXIgb2YgY2xpZW50IFggbXVzdCBu b3QgaW1wYWN0IHRoZSBwZXJmb3JtYW5jZSBleHBlcmllbmNlZCBieSBjbGllbnQgWSANCgkJCSAg DQoJCQlBIGtleSBjb3JvbGxhcnkgb2YgdGhlIGFib3ZlIGlzIHRoYXQgTVBMUy1UUCBtdXN0IG9u bHkgc3VwcG9ydCBwcm9wZXIgY29ubmVjdGlvbnMgKGllIHNpbmdsZSBzb3VyY2UgY29uc3RydWN0 cykgDQoJCQkgIA0KCQkJICANCgkJCTIgICBTaW5jZSBNUExTLVRQIGlzIGEgdHJhbnNwb3J0IG5l dHdvcmsgaXQgaXMgbm90IGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgKGllIGl0IGRvZXMgbm90IHN1 cHBvcnQgZGlyZWN0bHkgZXh0ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMp LiAgTVBMUy1UUCB0aGVyZWZvcmUgZG9lcyBub3QgcmVxdWlyZSBhbiBFLU5OSSBzcGVjaWZpY2F0 aW9uLiAgQSBrZXkgY29yb2xsYXJ5IG9mIHRoaXMgaXMgdGhhdCBNUExTLVRQIHdpbGwgbm90IGhh dmUgYW55IHBlZXIgaW50ZXJ3b3JraW5nIHJlbGF0aW9uc2hpcCB3aXRoIGFueSBvdGhlciBuZXR3 b3JrIG1vZGUvdGVjaG5vbG9neS4gDQoJCQkgIA0KCQkJICANCgkJCU5vdyB3cnQgT0FNIE1QTFMt VFAgaXMgYSBjby1wcyBtb2RlIG5ldHdvcmsuICBZb3UgY291bGQgYXJndWUgdGhpcyBzaG91bGQg aGF2ZSBGREkvQUlTLi4uLmhvd2V2ZXIsIHRoZSBtZXJpdCBvZiB0aGlzIGlzIGhpZ2hseSBxdWVz dGlvbmFibGUuICBXaGVuIEkgYW5kIGNvbGxlYWd1ZXMgZGlzY3Vzc2VkIHdoZXRoZXIgUEJCLVRF IChhbHNvIGEgY28tcHMgbW9kZSBuZXR3b3JrKSBzaG91bGQgaGF2ZSBGREkvQUlTIHdlIGNvbmNs dWRlZCB0aGF0IG9uIGJhbGFuY2UgaXQgd2FzIG5vdCBhIGdvb2QgaWRlYS4uLi4uYW5kIG5vdGUg dGhhdCBpbml0aWFsbHkgSSB3YXMgaW4gZmF2b3VyIG9mIGhhdmluZyBBSVMsIGJ1dCBteSBjb2xs ZWFndWVzIHByb3ZpZGVkIHN0cm9uZyB0ZWNobmljYWwgYXJndW1lbnRzIHRoYXQgY29udmluY2Vk IG1lIG90aGVyd2lzZS4gDQoJCQkgIA0KCQkJQUlTL0ZESSBpcyBoaXN0b3JpY2FsbHkgbGlua2Vk IHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXllciBuZXR3b3JrcyB0aGF0IHVzZWQgVFRM IGxvZ2ljLiAgV2hlbiB0aGlzIGRpZWQgaXQgcHV0IG91dCBhICs1ViAoYWxsIDFzKSBzaWduYWwg YnkgZGVmYXVsdCwgaWUgaXQgcmVxdWlyZWQgbm8gY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0 ZSBpdC4uLi4udGhpcyBpcyBrZXkgcG9pbnQuICBGdXJ0aGVyLCBpbiB0aGVzZSBuZXR3b3JrcyB0 aGVyZSBpcyBhIGZhaXJseSBzdGF0aWMvbG9uZy1ob2xkaW5nIGNsaWVudCBzZXJ2ZXIgcmVsYXRp b25zaGlwLiAgQ2xlYXJseSB0aGlzIGlzIG5vdCB0cnVlIGluIHRoZSBjbC1wcyBtb2RlIGFuZCBp dCdzIHdoeSBJRVRGIGhhdmUgbmV2ZXIgc3BlY2lmaWVkIEFJUyBmb3IgSVAgYW5kIGl0cyB3aHkg SUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2UgdG8gdGhyb3ctb3V0IEFJUyBpbiA4MDIuMWFnIGZvciBF dGhlcm5ldCAodGhvdWdoIElUVSBoYXZlIHVud2lzZWx5IElNTyByZXRhaW5lZCBpdCBpbiBZLjE3 MzEuLi4uYnV0IEkgc3VzcGVjdCBhbnkgb3BlcmF0b3IgcGxhbm5pbmcgdG8gdXNlIEV0aGVybmV0 IGVxdWlwbWVudCB3b3VsZCBhbHdheXMgbG9vayB0byBJRUVFIHN0ZHMgYW5kIG5vdCBJVFUgb25l cykuIA0KCQkJICANCgkJCUFJUy9GREkgYW5kIHRoZSBjby1wcyBtb2RlIGlzIGRlYmF0YWJsZS4g IEFzIEkgbm90ZWQgYWJvdmUsIG9uIGJhbGFuY2Ugd2UgY29uc2lkZXJlZCBub3QgYSBnb29kIGlk ZWEgZm9yIFBCQi1URSBPQU0gYmVjYXVzZSBpdCByZXF1aXJlcyBhIGNvbnNjaW91cyBlZmZvcnQg dG8gZ2VuZXJhdGUgaXQgKHVubGlrZSB0aGUgY28tY3MgbW9kZSkgc28gdGhlcmUgYXJlIGxpa2Vs eSB0byBiZSBzY2FsaW5nIHByb2JsZW1zIGFuZCBpdHMgb25lIG1vcmUgdGhpbmcgdG8gZ28gd3Jv bmcuIA0KCQkJICANCgkJCVlvdSBzaG91bGQgYWxzbyBoYXZlIHNlZW4gbWUgbWFrZSB0aGUgcG9p bnQgbWFueSB0aW1lcyBpbiB0aGUgcGFzdCB0aGF0IHRoZSBhbHdheXMtb24gZGVmZWN0IGRldGVj dGlvbi9oYW5kbGluZyBPQU0gbmVlZHMgdG8gYmUgYXMgc2ltcGxlL3NwYXJzZSBhcyBwb3NzaWJs ZSB3aXRoIGFzIGxpdHRsZSBjb25maWcgYXMgcG9zc2libGUgYmVjYXVzZSB3ZSBuZWVkIHN1cGVy IHJlbGlhYmlsaXR5Li4uLi4uVENNIGdvZXMgY29tcGxldGVseSBhZ2FpbnN0IHRoZSBncmFpbiBo ZXJlLiAgQWxzbyBub3RlIHRoYXQgdGhlIE9BTSByZXF1aXJlZCBmb3IgZWFjaCBvZiB0aGUgMyBu ZXR3b3JrIG1vZGVzIGlzIG5vdCB0aGUgc2FtZSwgZGVzcGl0ZSB3aGF0IHNvbWUgY2xhaW0uIA0K CQkJICANCgkJCXJlZ2FyZHMsIE5laWwgDQoJCQkgIA0KCQkJDQoJCQkNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCgkJCUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpdS5ndW9tYW5A enRlLmNvbS5jbg0KCQkJU2VudDogMjEgQXByaWwgMjAwOSAwMjo1OQ0KCQkJVG86IEJSVU5HQVJE LCBERUJPUkFIIEEsIEFUVExBQlMNCgkJCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJCQlTdWJqZWN0 OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCBy ZXF1aXJlbWVudHMNCgkJCQ0KCQkJDQoJCQlEZWJvcmFoOiANCgkJCW1heWJlIHdoYXQgeW91IHNh aWQgaXMgcmlnaHQuIGJ1dCBJIGNhbid0IGNvbXBsZXRlbHkgYWdyZWUgeW91ciBvcGluaW9ucy4g SU1PLiBtcGxzLXRwIGlzIHJlZ2FyZCBhcyB0cmFuc3BvcnQgbmV0d29yayBsaWtlIFNESC9TT05F VC4gc28gaXQgc2hvdWxkIGhhdmUgQUlTL0ZESSBmdWN0aW9ucyBhcyBTREgvU09ORVQuIA0KCQkJ DQoJCQlkbyB5b3UgdGhpbmsgc28uIA0KCQkJDQoJCQliZXN0IHJlZ2FyZHMgDQoJCQlsaXUgDQoJ CQkNCgkJCQ0KIkJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMiIDxkYnJ1bmdhcmRAYXR0LmNv bT4gDQrlj5Hku7bkuro6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQoNCjIwMDktMDQtMjAg MjM6NDcgDQoNCg0KDQrmlLbku7bkuroNCiJNYWFydGVuIFZpc3NlcnMiIDxtYWFydGVuLnZpc3Nl cnNAaHVhd2VpLmNvbT4sIDxuZWlsLjIuaGFycmlzb25AYnQuY29tPiANCuaKhOmAgQ0KbXBscy10 cEBpZXRmLm9yZyANCuS4u+mimA0KUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzCQ0KDQoNCgkJDQoNCg0KCQkJDQoJCQkNCgkJ CQ0KCQkJSSBhZ3JlZSB3aXRoIE5laWwsIGl0IGlzIHZlcnkgcXVlc3Rpb25hYmxlIHRoZSB2YWx1 ZSBvZiBBSVMvRkRJIGluIGENCgkJCXBhY2tldCBuZXR3b3JrLSBhbnkgbW9kZS4gSXQgY2FuIHJl c3VsdCBpbiBhIERvUyBhdHRhY2sgYnkgYW4gb3BlcmF0b3INCgkJCW9uIHRoZW1zZWx2ZXMgc28g ZXZlbiBZMTczMSByZWNvbW1lbmRzIG5vdCB0byBibG9jayBkYXRhIGZyYW1lczoNCgkJCSJBIE1F UCBjYW4gZGVjaWRlIHdoZXRoZXIgaXQgYmxvY2tzIGRhdGEgZnJhbWVzIHdoZW4gaXQgZGV0ZWN0 cyBkQUlTLg0KCQkJVGhlIHByaW5jaXBsZSByZXF1aXJlbWVudA0KCQkJdGhhdCBpbmZsdWVuY2Vz IHRoaXMgZGVjaXNpb24gaXMgdGhhdCBkYXRhIGZyYW1lcyBvdWdodCB0byBiZSBmb3J3YXJkZWQN CgkJCWFzIG11Y2ggYXMgcG9zc2libGUsIHdpdGhvdXQNCgkJCXRoZSBwb3NzaWJpbGl0eSBvZiBm b3J3YXJkaW5nIHdyb25nIGRhdGEgZnJhbWVzIGRvd25zdHJlYW0uIg0KCQkJVGFibGUgSS43LTIg c2hvd3MgZm9yIEFJUywgbm90IHRvIGJsb2NrLg0KCQkJDQoJCQlBbmQgYXMgWTE3MzEgc3RhdGVz LCBBSVMgY2FuIG9ubHkgYmUgdXNlZCB1bmRlciB2ZXJ5IGNvbnN0cmFpbmVkDQoJCQlhcmNoaXRl Y3R1cmVzIC0gaWYgcmVxdWlyZWQgZm9yIE1QTFMtVFAsIGl0IG5lZWRzIHRvIGhhdmUgdGhlIHNh bWUNCgkJCWd1aWRhbmNlIGFzIGluIFkxNzMxLCBpLmUuIHBvaW50LXRvLXBvaW50IGFuZCBzZXJ2 ZXIvY2xpZW50IG9uZS10by1vbmU6DQoJCQkiZm9yIGEgcG9pbnQtdG8tcG9pbnQgRVRIIGNvbm5l Y3Rpb24sIGEgTUVQIGhhcyBvbmx5IGEgc2luZ2xlIHBlZXIgTUVQLg0KCQkJVGhlcmVmb3JlLCB0 aGVyZQ0KCQkJaXMgbm8gYW1iaWd1aXR5IHJlZ2FyZGluZyB0aGUgcGVlciBNRVAgZm9yIHdoaWNo IGl0IHNob3VsZCBzdXBwcmVzcw0KCQkJYWxhcm1zIHdoZW4gaXQgcmVjZWl2ZXMgdGhlDQoJCQlF VEgtQUlTIGluZm9ybWF0aW9uLiINCgkJCVNvIHNob3VsZCBvbmx5IGJlIHdpdGhpbiBvbmUgZG9t YWluIC0gdGhlbiBubyBuZWVkLg0KCQkJDQoJCQlEZWJvcmFoDQoJCQkNCgkJCS0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoJCQlGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQoJCQlCZWhhbGYgT2YgTWFhcnRlbiBWaXNz ZXJzDQoJCQlTZW50OiBNb25kYXksIEFwcmlsIDIwLCAyMDA5IDEwOjA1IEFNDQoJCQlUbzogbmVp bC4yLmhhcnJpc29uQGJ0LmNvbQ0KCQkJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCVN1YmplY3Q6 IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQoJ CQlyZXF1aXJlbWVudHMNCgkJCQ0KCQkJTmVpbCwNCgkJCQ0KCQkJPiBidXQgQUlTL0ZESSBpbiB0 aGUgY2wgbW9kZT8uLi5kbyBtZSBhIGZhdm91ciENCgkJCQ0KCQkJRXRoZXJuZXQgQUlTIGlzIGlu ZGVlZCBhIHJlcXVpcmVtZW50IGFuZCBhIG5lY2Vzc2l0eS4gQW5kIHlvdSB3aWxsIG5vdA0KCQkJ YmUNCgkJCWFibGUgdG8gdW5kZXJzdGFuZCB0aGF0IGFzIGxvbmcgYXMgeW91IHJlZnVzZSB0byBh Y2NlcHQgdGhhdCAiY2wtbW9kZSINCgkJCWlzIGENCgkJCWZvcndhcmRpbmcgbW9kZSB3aXRoaW4g YSAqKnRyYW5zcG9ydCBlbnRpdHkqKi4gRy44MDAgYW1lbmRtZW50IDEgaGFzDQoJCQlmaW5hbGx5 DQoJCQlyZWludHJvZHVjZWQgdGhpcyB0cmFuc3BvcnQgZW50aXR5IGludG8gRy44MDAuIEJlc2lk ZXMgdGhhdCwgaXQgYWxzbw0KCQkJaW50cm9kdWNlZCB0aGUgKipkaWZmZXJlbnRpYXRlZCBjb25u ZWN0aW9uKio6DQoJCQkNCgkJCVtHLjgwMCBhbTFdICJBIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rp b24gaXMgYSB0cmFuc3BvcnQgZW50aXR5IHRoYXQNCgkJCXRyYW5zZmVycyBpbmZvcm1hdGlvbiBi ZWxvbmdpbmcgdG8gbXVsdGlwbGUgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBwb3J0cw0KCQkJYWNy b3NzIGEgc3VibmV0d29yay4gPC4uPiBJbiBhIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24gbWVz c2FnZQ0KCQkJY29udGVudHMNCgkJCWFyZSBpbnRlcnByZXRlZCB0byBpZGVudGlmeSAoc2V0cyBv ZikgY29tbXVuaWNhdGlvbnMgd2hpY2ggcmVjZWl2ZQ0KCQkJZGlmZmVyZW50DQoJCQl0cmVhdG1l bnQuICBUaGUgc2V0cyBvZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgZGlzdGluZ3Vpc2hlZCBieSB0 aGUNCgkJCWZvcndhcmRpbmcgaWRlbnRpZmllciBvciBvdGhlciBsYXllciBpbmZvcm1hdGlvbi4g IE9yZGVyIGlzIG5vdA0KCQkJbmVjZXNzYXJpbHkNCgkJCXByZXNlcnZlZCBiZXR3ZWVuIG1lc3Nh Z2VzIGJlbG9uZ2luZyB0byBzZXRzIG9mIGNvbW11bmljYXRpb25zIHJlY2VpdmluZw0KCQkJZGlm ZmVyZW50IHRyZWF0bWVudC4gIFNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIGlkZW50aWZp ZWQgZm9yDQoJCQlwdXJwb3Nlcw0KCQkJc3VjaCBhcyB0cmFmZmljIGNvbmRpdGlvbmluZyBvciBw cmVzZXJ2aW5nIGNvbW11bmljYXRpb24gbWVzc2FnZSBvcmRlci4iDQoJCQkNCgkJCQ0KCQkJRXRo ZXJuZXQgVkxBTnMgYXJlIGluIHRlcm1zIG9mIEcuODAwICJkaWZmZXJlbnRpYXRlZCBjb25uZWN0 aW9ucyIuDQoJCQlFdGhlcm5ldA0KCQkJQUlTIHByb3ZpZGVzIEFJUyB3aXRoaW4gdGhlIHNjb3Bl IG9mIHN1Y2ggImRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24iLg0KCQkJSWYNCgkJCXlvdSBhcHBs eSB0aGlzIHRvIG15IHByb3Bvc2VkIFBUTiBsYXllciBzdGFjaywgdGhlbiB0aGUgRVZDIGxheWVy DQoJCQl0b3BvbG9neQ0KCQkJd2lsbCBjb25zaXN0cyBvZiBFVkMgbGlua3Mgc3VwcG9ydGVkIGJ5 IE1QTFMtVFAsIEV0aGVybmV0LCBQQkItVEUgYW5kDQoJCQlQLU9UTg0KCQkJVlAgdHJhaWxzIGlu c2lkZSBtZXRybyBhbmQgY29yZSBkb21haW5zIGludGVyY29ubmVjdGluZyBFVkMgbWF0cmljZXMu DQoJCQlXaGVuDQoJCQlvbmUgb2YgdGhvc2UgRVZDIGxpbmtzIGlzIGludGVycnVwdGVkLCBlLmcu IGluIHRoZSBjb3JlIGJldHdlZW4gbWV0cm8gMQ0KCQkJYW5kDQoJCQltZXRybyA0IChzZWUgYXR0 YWNoZWQgc2xpZGUpLCB0aGVuIHRoZSBFVkMgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbg0KCQkJ dGhhdCBpcw0KCQkJcHJlc2VudCBvbiB0aGlzIGxpbmsgd2lsbCBiZSBpbnRlcnJ1cHRlZC4gQXQg dGhlIEVWQyBzd2l0Y2gvYnJpZGdlIG5vZGUNCgkJCWluDQoJCQltZXRybyA0IHRoaXMgaW50ZXJy dXB0aW9uIGlzIG5vdGljZWQgYW5kIEVWQy1BSVMgaXMgaW5zZXJ0ZWQgaW4gdGhlDQoJCQlkb3du c3RyZWFtIGRpcmVjdGlvbiB0byBzdXBwcmVzcyB0aGUgRVZDLUxPQyBhbGFybXMgYXQgRVZDIGVu ZHBvaW50cyBENA0KCQkJYW5kDQoJCQlENS4NCgkJCQ0KCQkJVGhlIEVWQy1BSVMgKGkuZS4gRXRo ZXJuZXQgQUlTKSBmcmFtZSBoYXMgYSByZXNlcnZlZCBtdWx0aWNhc3QgYWRkcmVzcywNCgkJCXdo aWNoIGd1YXJhbnRlZXMgdGhhdCB0aGUgQUlTIGlzIGJyb2FkY2FzdCB0byB0aGUgZW5kcG9pbnRz IG9mIHRoZSBFVkMuDQoJCQkNCgkJCUkgYmVsaWV2ZSB0aGF0IGl0IGlzIHRpbWUgZm9yIHlvdSB0 byBhZGFwdCB5b3VyIHZpZXcgb24gY28gYW5kIGNsIG1vZGVzDQoJCQlhbmQNCgkJCXJlbGF0ZSBp dCB0byB0aGUgZm9yd2FyZGluZyBtb2RlICoqSU5TSURFKiogYSB0cmFuc3BvcnQgZW50aXR5LiAN CgkJCQ0KCQkJV2hhdCB3ZSBrbm93IGFzIHRoZSBpbnRlcm5ldCBpcyBlc3NlbnRpYWxseSBhbiAi SVAgZGlmZmVyZW50aWF0ZWQNCgkJCWNvbm5lY3Rpb24iIHdpdGggYSBiaWxsaW9uIG9yIG1vcmUg cG9ydHMuDQoJCQlXaGF0IHdlIGtub3cgYXMgYW4gSVAgVlBOIGlzIGVzc2VudGlhbGx5IGFuICJJ UCBkaWZmZXJlbnRpYXRlZA0KCQkJY29ubmVjdGlvbiINCgkJCXdpdGggZS5nLiBuIHBvcnRzIChu IGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuDQoJCQlXaGF0IHdlIGtub3cgYXMgYW4g RXRoZXJuZXQgVkxBTiBpcyBlc3NlbnRpYWxseSBhbiAiRXRoZXJuZXQNCgkJCWRpZmZlcmVudGlh dGVkDQoJCQljb25uZWN0aW9uIiB3aXRoIG4gcG9ydHMgKG4gaW4gdGhlIHJhbmdlIG9mIGUuZy4g MiB0byAxMDAwKS4NCgkJCVdoYXQgd2Uga25vdyBhcyBhIHAycCBNUExTIEUtTFNQIGlzIGVzc2Vu dGlhbGx5IGFuICJNUExTIGRpZmZlcmVudGlhdGVkDQoJCQljb25uZWN0aW9uIiB3aXRoIDIgcG9y dHMuDQoJCQlXaGF0IHdlIGtub3cgYXMgYSBwMnAgU0RIIFZDLW4gaXMgYSAiU0RIIFZDLW4gY29u bmVjdGlvbiIgd2l0aCAyIHBvcnRzLg0KCQkJDQoJCQlUcmFuc3BvcnQgbmV0d29yayBPQU0gYXBw bGllcyB0byB0cmFuc3BvcnQgZW50aXRpZXMsIHdoaWNoIGFyZSAoaW4gdGVybXMNCgkJCW9mDQoJ CQlHLjgwMCBhbTEpIGNvbm5lY3Rpb25zIGFuZCBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9ucy4N CgkJCQ0KCQkJUmVnYXJkcywNCgkJCU1hYXJ0ZW4NCgkJCQ0KCQkJLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCgkJCUZyb206IG5laWwuMi5oYXJyaXNvbkBidC5jb20gW21haWx0bzpuZWlsLjIu aGFycmlzb25AYnQuY29tXSANCgkJCVNlbnQ6IHZyaWpkYWcgMTcgYXByaWwgMjAwOSAyMjowMA0K CQkJVG86IEpvaG4uRS5EcmFrZTJAYm9laW5nLmNvbTsgSXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2Vu dC5pdDsNCgkJCUFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBtYWFydGVuLnZpc3Nl cnNAaHVhd2VpLmNvbQ0KCQkJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCVN1YmplY3Q6IFJFOiBb bXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoDQoJCQlyZXF1 aXJlbWVudHMNCgkJCQ0KCQkJSm9obiwgIFRoYW5rcyB0aGlzIGlzIGEgZ3JlYXQgcGxhdGZvcm0g dG8gZXhwbGFpbiB3aHkgT0FNIGZvciB0aGUgMw0KCQkJbmV0d29yaw0KCQkJbW9kZXMgbmVlZHMg dG8gYmUgZGlmZmVyZW50LiAgSSBhbSBnZXR0aW5nIGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xrcw0K CQkJdHJ5aW5nDQoJCQl0byBtYWtlIGFsbCAzIG5ldHdvcmsgbW9kZXMgbG9vayBhbGlrZSAoYW5k IHRoZW4sIGV2ZW4gd29yc2UsIGludGVyd29yaw0KCQkJdGhlbQ0KCQkJYXMgYXMgcGVlcnMuLi5l c3Agd2hlbiBub3Qgbm90IHRvcC1vZi1zdGFjaw0KCQkJbmV0d29ya3MuLi5JIG1lYW4gaG93IHNp bGx5IGNhbiB3ZSBnZXQ/KS4gICBJIGFtIGV2ZW4gbW9yZSBmcnVzdHJhdGVkIGJ5DQoJCQl0aGUg ZmFjdCB0aG9zZSBwZWRkbGluZyB0aGlzIEZVRCBvbmx5IGV2ZXIgc2VlbSB0byBjb25zaWRlciBP QU0gYW5kDQoJCQlmb3JnZXQNCgkJCWFsbCBvdGhlciBEUC9DUC9NUCBjb21wb25lbnRzIChlc3Ag dG9wLW9mLXN0YWNrIG1lc3NhZ2UvZmlsZS9zdHJlYW0NCgkJCWFwcGxpY2F0aW9uIGFkYXB0YXRp b25zKS4gIEhvdyB3cm9uZyBjYW4gdGhpcyBnZXQhIA0KCQkJDQoJCQlJbiB0aGUgY28gbW9kZXMg YSAqY29ubmVjdGlvbiogaXMgYSB2ZXJ5IHNwZWNpZmljIGFuZCAqY29uc3RyYWluaW5nKg0KCQkJ Y29uc3RydWN0Li4uLi5JIGFtIGFzc3VtaW5nIGhlcmUgd2UgcmVzcGVjdCB0aGUgcnVsZXMgb2Yg YSBjb25uZWN0aW9uDQoJCQkoaWUNCgkJCXNpbmdsZSBzb3VyY2UpIHRob3VnaCBzb21lIGZvbGtz IGRvbid0IGV2ZW4gYm90aGVyIHRvIHJlc3BlY3QgdGhpcywgYW5kDQoJCQl0aGlzDQoJCQlpcyBk ZXNwaXRlIHRoZSBmYWN0IHRoYXQgd2UgYWxsIGtub3cgd2hhdCBwcm9ibGVtcyBtdWx0aXBsZS1z b3VyY2UNCgkJCWNvbnN0cnVjdHMgY2FuIGNhdXNlIChmcm9tIExEUC9QSFAuLi4uZXJnbyBNUExT LVRQKS4NCgkJCQ0KCQkJV2hlbiB3ZSBoYXZlIGEgY29ubmVjdGlvbiB0aGlzIHJlc3RyaWN0cyAq YWxsKiBEUCAoaWUgdHJhZmZpYyBhbmQgT0FNKQ0KCQkJdG8NCgkJCXN0YXkgd2l0aGluIHRoZSBi b3VuZHMgb2YgdGhlIGNvbm5lY3Rpb24uICBXaGljaCBpcyBmaW5lIHVuZGVyDQoJCQlkZWZlY3Qt ZnJlZQ0KCQkJY29uZGl0aW9ucywgYnV0IGlmIHdlIGhhdmUgbGVha2luZyB0cmFmZmljIHRoZW4g dGhlIGNvbnN0cmFpbmluZyBuYXR1cmUNCgkJCW9mDQoJCQl0aGUgY29ubmVjdGlvbiBjb25zdHJ1 Y3QgaXMgYnJva2VuLiAgSW4gYSBudXRzaGVsbCB3aGF0IHRoaXMgbWVhbnMgaXMNCgkJCXRoYXQN CgkJCU9BTSB0aGF0IGlzIG9mIGEgcmVxdWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fubm90IGJlIHRy dXN0ZWQgaW4gY28gbW9kZQ0KCQkJbmV0d29ya3MgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVj dHMuLi4uLmluZGVlZCwgd2h5IHNob3VsZCBhIGxlYWtpbmcNCgkJCURQDQoJCQloYXZlIGEgc3lt bWV0cmljIGdvL3JldHVybiBkZWZlY3QgYmVoYXZpb3VyPy4uLi52ZXJ5IGxpa2VseSBpdCB3b24n dC4NCgkJCVNvDQoJCQl3aGlsc3QgcmVxdWVzdC9yZXNwb25zZSBPQU0gaXMgcmlnaHQgZm9yIHRo ZSBjbCBtb2RlIGl0IGlzIG5vdCByaWdodCBmb3INCgkJCXRoZQ0KCQkJY28gbW9kZSB1bmRlciBt aXNjb25uZWN0aXZpdHkgZGVmZWN0IGNvbmRpdGlvbnMuDQoJCQkNCgkJCU1vcmUgZ2VuZXJhbGx5 IHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJlbnQgYW5kIG5vdCBqdXN0IGluIE9BTQ0KCQkJcmVxdWly ZW1lbnRzLi4uLmJ1dCBBSVMvRkRJIGluIHRoZSBjbCBtb2RlPy4uLmRvIG1lIGEgZmF2b3VyIS4u LmF0IGxlYXN0DQoJCQlJRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRo ZXJuZXQgZXZlbiB0aG91Z2ggaXQgcmVtYWlucw0KCQkJaW4NCgkJCVkuMTczMS4gIEFuZCB3aGlj aCBpcyB3aHkgSSBvZnRlbiB0cm90LW91dCB0aGUgcmF0aGVyIHNpbGx5ICh0byBoYXZlIHRvDQoJ CQlzYXkNCgkJCXRoaXMpIG9ic2VydmF0aW9uIHRoYXQgaWYgSVAgKGNsIG1vZGUpIGNvdWxkIGRv IGl0IGFsbCB0aGVuIHdoeSBoYXZlDQoJCQlJRVRGDQoJCQlmb3VuZCBpdCBuZWNlc3NhcnkgdG8g Y3JlYXRlIE1QTFMgKGNvLXBzKSBhbmQgR01QTFMgKENQIGZvciBjby1jcykuICBUaGUNCgkJCWFu c3dlciBsaWVzIGluIHRoZSBwaHlzaWNzLi4uYW5kIEcuODAwIGF0dGVtcHRzIHRvIGV4cGxhaW4g dGhhdA0KCQkJcGh5c2ljcy4uLi5HLjgwNSBkb2VzIG5vdC4NCgkJCQ0KCQkJU28sIHRoZSAzIG1v ZGVzIGFyZSBkaWZmZXJlbnQuLi5wbGVhc2UgYWNjZXB0L3Jlam9pY2UgaW4gdGhpcyBmYWN0IGFz DQoJCQl0aGV5DQoJCQlhbGwgb2ZmZXIgc29tZXRoaW5nIGRpZmZlcmVudC9pbXBvcnRhbnQuICBC dXQgZG8gbm90IGJlIGhvb2R3aW5rZWQgYnkNCgkJCXRob3NlDQoJCQl3aG8gcGVkZGxlIGEgc3Rv cnkgdGhhdCB0aGF0IHRyaWVzIHRvIG1ha2UgdGhlIE9BTSBvZiB0aGUgMyBtb2RlcyB0aGUNCgkJ CXNhbWUuIA0KCQkJDQoJCQlyZWdhcmRzLCBOZWlsIA0KCQkJDQoJCQk+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoJCQk+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KCQkJPiBb bWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERyYWtlLCBKb2hu IEUNCgkJCT4gU2VudDogMTcgQXByaWwgMjAwOSAyMDowMg0KCQkJPiBUbzogQlVTSSBJVEFMTzsg QWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KCQkJPiBDYzogbXBscy10cEBp ZXRmLm9yZw0KCQkJPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCB0cmFuc3BvcnQgcGF0aCANCgkJCT4gcmVxdWlyZW1lbnRzDQoJCQk+IA0KCQkJPiBJdGFs bywNCgkJCT4gDQoJCQk+IEFzIGRlc2NyaWJlZCBpbiB0aGUgTVBMUyBUUCBPQU0gUmVxdWlyZW1l bnRzIEktRCwgdmlydHVhbGx5IGFsbCBvZiB0aGUNCgkJCQ0KCQkJPiBPQU0gZnVuY3Rpb25zIHJl cXVpcmUgYSByZXR1cm4gcGF0aCwgYW5kIGluIHRoZSBhYnNlbmNlIG9mIGEgcmV0dXJuIA0KCQkJ PiBwYXRoIHRoZXkgYXJlIGRpc2FibGVkLg0KCQkJPiANCgkJCT4gQXMgZGVzY3JpYmVkIGluIERh dmlkIFNpbmljcm9wZSdzIG1lZXRpbmcgbWludXRlcyANCgkJCT4gKGh0dHA6Ly93aWtpLnRvb2xz LmlldGYub3JnL21pc2MvbXBscy1pbnRlcm9wL2F0dGFjaG1lbnQvd2lraS8NCgkJCT4gbWVldGlu Zy1ubw0KCQkJPiB0ZXMvMjAwODEwMTUubXBscy1pbnRlcm9wLWR0LW5vdGVzLnppcCksIGlmIElQ IGFkZHJlc3NpbmcgaXMgdXNlZCwgYW4gDQoJCQk+IE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBi ZSBjYXBhYmxlIG9mIGdldHRpbmcgSVAgcGFja2V0cyBmcm9tIA0KCQkJPiBkZXN0aW5hdGlvbiB0 byBzb3VyY2U7IG5laXRoZXIgdGhlIG1pbnV0ZXMgbm9yIEkgc3RpcHVsYXRlIHRoYXQgYSANCgkJ CT4gY29udHJvbCBwbGFuZSBuZWVkcyB0byBiZSB1c2VkIHRvIGluc3RhbnRpYXRlIHRoaXMgZm9y d2FyZGluZy4NCgkJCT4gDQoJCQk+IEFzIGFuIGFzaWRlLCB0aGUgaXNzdWUgb2YgcmV0dXJuIHBh dGggZm9yIHVuaWRpcmVjdGlvbmFsIExTUHMgY291bGQgYmUNCgkJCQ0KCQkJPiBjaGFyYXRlcml6 ZWQgYXMgdGhlIGVsZXBoYW50IGluIHRoZSByb29tLiAgSW4gdGhlIE1QTFMgVFAgT0FNIA0KCQkJ PiBGcmFtZXdvcmsgSS1ELCB1bmljYXN0IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRp bWVzIGFuZCByZXR1cm4gDQoJCQk+IHBhdGhzIG5vdCBhdCBhbGwuDQoJCQk+IA0KCQkJPiBUaGFu a3MsDQoJCQk+IA0KCQkJPiBKb2huDQoJCQk+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CgkJCT4gPiBGcm9tOiBCVVNJIElUQUxPIFttYWlsdG86SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2Vu dC5pdF0NCgkJCT4gPiBTZW50OiBGcmlkYXksIEFwcmlsIDE3LCAyMDA5IDE6NTkgQU0NCgkJCT4g PiBUbzogRHJha2UsIEpvaG4gRTsgQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vy cw0KCQkJPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQoJCQk+ID4gU3ViamVjdDogUkU6IFttcGxz LXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQoJCQk+ID4gcmVx dWlyZW1lbnRzDQoJCQk+ID4gDQoJCQk+ID4gSm9obiwNCgkJCT4gPiANCgkJCT4gPiBJIG1pZ2h0 IGhhdmUgbWlzc2VkIHRoZSBhZ3JlZW1lbnQgb2YgTVBMUy1UUCBiZWluZyBjYXBhYmxlIG9mIA0K CQkJPiA+IHNlbmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2VudCBvbiB1bmktZGlyZWN0 aW9uYWwgTFNQcy4NCgkJCT4gPiANCgkJCT4gPiBUaGlzIHJlcXVpcmVtZW50IGRvZXMgbm90IGJl bG9uZyB0byB0aGUgZmlyc3Qgc2V0IG9mIHJlcXVpcmVtZW50cyANCgkJCT4gPiBJVFUtVCBpcyBl eHBlY3RpbmcgdG8gYmUgbWV0IGJ5IE9jdG9iZXIuDQoJCQk+ID4gDQoJCQk+ID4gSG93ZXZlciwg SSB0aGluayB0aGlzIGluIGEgcG90ZW50aWFsIGludGVyZXN0aW5nIGFkZGl0aW9uYWwgDQoJCQk+ ID4gcmVxdWlyZW1lbnQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IChhdCB3b3JzdCBpbiBhDQoJ CQk+IHN1YnNlcXVlbnQgcGhhc2UpLg0KCQkJPiA+IA0KCQkJPiA+IEkgdGhpbmsgdGhhdCB0aGlz IHJlcXVpcmVtZW50IG5lZWRzIHRvIGJlIGV2YWx1YXRlZCB2ZXJzdXMgb3RoZXIgDQoJCQk+ID4g bW9yZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIChlLmcuIHRoZSBwb3NzaWJpbGl0eSB0byB3b3Jr IHcvbyBJUCANCgkJCT4gPiBmb3J3YXJkaW5nIGFuZCB0aGUgbmVlZCBmb3IgT0FNIHRvIGNvbnRp bnVlIHRvIG1vbml0b3IgdGhlIGRhdGEgDQoJCQk+ID4gcGxhbmUgYWxzbyBpbiBjYXNlIG9mIGZh aWx1cmVzIGFmZmVjdGluZyB0aGUgY29udHJvbCBvciBtYW5hZ2VtZW50IA0KCQkJPiA+IHBsYW5l KS4NCgkJCT4gPiANCgkJCT4gPiBJIGFtIG9wZW4gdG8gZGlzY3VzcyBpdCBidXQgbm90IHN1cmUg dGhpcyBpcyB0aGUgcmlnaHQgdGltZSBiZWNhdXNlIA0KCQkJPiA+IEkgd2lzaCB0byBhdm9pZCBk ZWxheWluZyB0aGUgZmlyc3QgcGhhc2Ugb2YgdGhlIGRlc2lnbiBzb2x1dGlvbi4NCgkJCT4gPiAN CgkJCT4gPiBUaGFua3MsIEl0YWxvDQoJCQk+ID4gDQoJCQk+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KCQkJPiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoJCQk+ ID4gPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERyYWtl LCBKb2huIEUNCgkJCT4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA4OjAwIFBN DQoJCQk+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2Vycw0KCQkJ PiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCT4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10 cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCQkJPiA+ID4gcmVx dWlyZW1lbnRzDQoJCQk+ID4gPiANCgkJCT4gPiA+IEF0IHRoZSBtZWV0aW5nIGxhc3QgZmFsbCBh dCBKdW5pcGVyIGluIE1hc3NhY2h1c2V0dHMsIEkNCgkJCT4gPiB0aGluayBpdCB3YXMNCgkJCT4g PiA+IGFncmVlZCB0aGF0IGFuIE1QTFMgVFAgbmV0d29yayBuZWVkcyB0byBoYXZlIGEgZm9yd2Fy ZGluZw0KCQkJPiA+IGNhcGFiaWxpdHkNCgkJCT4gPiA+IGZvciBtYW5hZ2VtZW50LCBjb250cm9s LCBhbmQgT0FNIHBhY2tldHMgKGUuZy4sIHNlbmRpbmcNCgkJCT4gPiByZXBsaWVzIHRvIE9BTQ0K CQkJPiA+ID4gcmVxdWVzdHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQcykgZXZlbiBpZiBp dCBkb2VzIG5vdA0KCQkJPiA+IGhhdmUgYW4gSVANCgkJCT4gPiA+IGZvcndhcmRpbmcgZGF0YSBw bGFuZS4NCgkJCT4gPiA+IA0KCQkJPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K CQkJPiA+ID4gPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KCQkJPiA+ID4gW21haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCgkJCT4gPiA+ID4gU2VudDogVGh1cnNk YXksIEFwcmlsIDE2LCAyMDA5IDk6NTcgQU0NCgkJCT4gPiA+ID4gVG86IE1hYXJ0ZW4gVmlzc2Vy cw0KCQkJPiA+ID4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KCQkJPiA+ID4gPiBTdWJqZWN0OiBS ZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgkJ CT4gPiA+ID4gcmVxdWlyZW1lbnRzDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBNYWFydGVuLA0K CQkJPiA+ID4gPiBJdCBzZWVtcyB0aGF0IHlvdSd2ZSBqdXN0IChpbXBsaWNpdGx5IGFuZCwgcHJv YmFibHksDQoJCQk+ID4gPiA+IGluYWR2ZXJ0ZW50bHkpIHN0YXRlZCB0aGUgZm9sbG93aW5nOg0K CQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gICAgICAgICAgICAgICAgICBNUExTLVRQIE9BTSB3aWxs IG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0aW9uDQoJCQk+ID4gKGFuZCBmYXVs dA0KCQkJPiA+ID4gPiBsb2NhbGl6YXRpb24gd2hpY2ggcmVxdWlyZXMgdGhpcyBmdW5jdGlvbiAp IGZvcg0KCQkJPiA+IHVuaWRpcmVjdGlvbmFsIFAyTVANCgkJCT4gPiA+ID4gYW5kIFAyUCBwYXRo cy4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IElmIHRoaXMgc3RhdGVtZW50IGlzIGNvcnJlY3Qs IHRoaXMgKElNSE8gYW5kIEZXSVcpDQoJCQk+IHJhaXNlcyBhIHZhbGlkDQoJCQk+ID4gPiA+IHF1 ZXN0aW9uOg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gICAgICAgICAgICAgICAgICBJcyBNUExT LVRQIGFuIGFwcHJvcHJpYXRlIHNvbHV0aW9uIGZvciB0aGVzZQ0KCQkJPiB0eXBlcyBvZiB0cmFu c3BvcnQNCgkJCT4gPiA+ID4gcGF0aHM/DQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBGb3IgdGhl IHJlZmVyZW5jZSwgSVAvTVBMUyBwcm92aWRlcyB0aGlzIGtpbmQgb2YNCgkJCT4gPiBmdW5jdGlv bmFsaXR5IHRvZGF5DQoJCQk+ID4gPiA+IGZvciAodW5pZGlyZWN0aW9uYWwgLSBidXQgaXQgZG9l cyBub3Qga25vdyBhbnkgb3RoZXINCgkJCT4gPiB0eXBlKSBQMlAgTFNQcw0KCQkJPiA+ID4gPiBh cyBkZXNjcmliZWQgaW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0ZW5zaW9uIHRvIFAyTVAgTFNQcyBz ZWVtcyANCgkJCT4gPiA+ID4gZWFzeS4uLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gIA0KCQkJ PiA+ID4gPiANCgkJCT4gPiA+ID4gUmVnYXJkcywNCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ICAg ICAgU2FzaGENCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCQkJPiA+ID4gPiBG cm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10N CgkJCT4gPiBPbiBCZWhhbGYNCgkJCT4gPiA+ID4gT2YgTWFhcnRlbiBWaXNzZXJzIFttYWFydGVu LnZpc3NlcnNAaHVhd2VpLmNvbV0NCgkJCT4gPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2 LCAyMDA5IDM6MjQgUE0NCgkJCT4gPiA+ID4gVG86ICdBZHJpYW4gRmFycmVsJw0KCQkJPiA+ID4g PiBDYzogbXBscy10cEBpZXRmLm9yZw0KCQkJPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBd IEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgkJCT4gPiA+ID4gcmVx dWlyZW1lbnRzDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBBZHJpYW4sDQoJCQk+ID4gPiA+IA0K CQkJPiA+ID4gPiA+PiA8cXVvdGU+DQoJCQk+ID4gPiA+ID4+ICAgICAgVGhlIGludGVybWVkaWF0 ZSBub2RlcyAoaW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5kDQoJCQk+ID4gPiA+IG90aGVyIGludGVy bmFsDQoJCQk+ID4gPiA+ID4+ICAgICAgIGZ1bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2YgYSBj by1yb3V0ZWQNCgkJCT4gPiA+ID4gYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCgkJCT4gPiA+ID4g Pj4gICAgICAgcGF0aCBhdCBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBh aXJpbmcNCgkJCT4gPiA+ID4gPj4gICAgICAgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFu ZCB0aGUgYmFja3dhcmQNCgkJCT4gPiA+ID4gZGlyZWN0aW9ucyBvZiB0aGF0DQoJCQk+ID4gPiA+ ID4+ICAgICAgIHRyYW5zcG9ydCBwYXRoLg0KCQkJPiA+ID4gPiA+PiA8ZW5kIHF1b3RlPg0KCQkJ PiA+ID4gPiA+DQoJCQk+ID4gPiA+ID4gVGhlcmUgaXMgbm8gd2F5IHRoaXMgaXMgYSBmdW5jdGlv bmFsIHJlcXVpcmVtZW50LiBUaGF0DQoJCQk+ID4gPiBpcywgdGhlcmUgaXMNCgkJCT4gPiA+ID4g PiAqbm90aGluZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBv Zg0KCQkJPiA+ID4gdmlldyB0aGF0DQoJCQk+ID4gPiA+ID4gcmVzdWx0cyBmcm9tIGFkaGVyaW5n IHRvIHRoaXMgcmVxdWlyZW1lbnQuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBZb3VyIHVuZGVy c3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIEl0IGlzIHZlcnkgbXVjaA0KCQkJPiBvYnNlcnZhYmxl IGlmDQoJCQk+ID4gPiA+IHRoaXMgcmVxdWlyZW1lbnQgaXMgbWV0IGZyb20gYSBibGFjayBib3gg cG9pbnQgb2Ygdmlldy4NCgkJCT4gPiA+ID4gVGhlIE1JUCBmdW5jdGlvbnMgY2FuIG9ubHkgcGVy Zm9ybSB0aGUgTG9vcGJhY2sgd2hlbiB0aGVyZSBpcyBhIA0KCQkJPiA+ID4gPiBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4gVGhlIE1QTFMtVFAgTEJNIHBhY2tldCANCgkJ CT4gPiA+ID4gcmVjZWl2ZWQgYXQgYSBNSVAgbmVlZHMgdG8gYmUgcmV0dXJuZWQgKGFzIExCUg0K CQkJPiA+ID4gPiBwYWNrZXQpIHRvIHRoZSBvcmlnaW5hdGluZyBNRVAgZnVuY3Rpb24gdmlhIHRo ZSBvdGhlcg0KCQkJPiA+IGRpcmVjdGlvbiBvZg0KCQkJPiA+ID4gPiB0aGUgY28tcm91dGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoaXMgb3RoZXINCgkJCT4gZGlyZWN0aW9uDQoJ CQk+ID4gPiA+IHdvdWxkIG5vdCBiZSBhdmFpbGFibGUgaW4gYW4gYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCANCgkJCT4gPiA+ID4gcGF0aC4uLiBhbmQgdGh1cyB0aGUgbG9vcGJh Y2sgdGVzdA0KCQkJPiA+ID4gd291bGQgZmFpbC4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IFNp bWlsYXJseSwgd2hlbiB3ZSBoYXZlIHRvIGFwcGx5IFRDTSBNRVBzIHRvIG1vbml0b3IgYQ0KCQkJ PiA+IHNlZ21lbnQsIHRoZW4NCgkJCT4gPiA+ID4gdGhpcyBpcyBwb3NzaWJsZSBpbiBhIGNvLXJv dXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aA0KCQkJPiBidXQgbm90IGluIGENCgkJCT4gPiA+ID4g YXNzb2NpYXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aC4gSW4gdGhlIGZpcnN0IGNhc2UgdGhlIFRD TSBNRVAgDQoJCQk+ID4gPiA+IFNvdXJjZSBhbmQgU2luayBmdW5jdGlvbnMgYXJlIGNvLWxvY2F0 ZWQgYW5kIGNhbg0KCQkJPiBleGNoYW5nZSB3aGF0IGlzDQoJCQk+ID4gPiA+IGNhbGxlZCAicmVt b3RlIGluZm9ybWF0aW9uIiB3aGljaCBpcyBuZWNlc3NhcnkgZm9yIHBlcmZvcm1hbmNlIA0KCQkJ PiA+ID4gPiBtb25pdG9yaW5nLg0KCQkJPiA+ID4gPiBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRD TSBNRVAgU291cmNlIGFuZCBTaW5rIGZ1bmN0aW9ucw0KCQkJPiA+IGFyZSBpbiBlLmcuIA0KCQkJ PiA+ID4gPiBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgYW5kIFRDTSB3b3VsZCBub3Qg YmUgYWJsZQ0KCQkJPiA+IHRvIHByb3ZpZGUNCgkJCT4gPiA+ID4gcGVyZm9ybWFuY2UgbW9uaXRv cmluZy4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4gVGhlIGVudGlyZXR5IG9mIHRoZSBicmFj a2V0dGVkIHRleHQgIihpbmNsdWRpbmcgTUVQcywNCgkJCT4gPiA+IE1JUHMgYW5kIG90aGVyDQoJ CQk+ID4gPiA+IGludGVybmFsDQoJCQk+ID4gPiA+ID4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRl KSIgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90DQoJCQk+ID4gPiA+IGFkZCB0byAiVGhl DQoJCQk+ID4gPiA+ID4gaW50ZXJtZWRpYXRlIG5vZGVzLiINCgkJCT4gPiA+ID4gDQoJCQk+ID4g PiA+IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBub3QgY29ycmVjdC4gVGhpcyB0ZXh0IG11c3Qgbm90 IGJlDQoJCQk+ID4gZGVsZXRlZCBhdA0KCQkJPiA+ID4gPiBhbGwuDQoJCQk+ID4gPiA+IA0KCQkJ PiA+ID4gPiA+IEFjdHVhbGx5LCBJIGFtIHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3Rl bnQNCgkJCT4gPiA+IGluc2lzdGVuY2Ugb24gdGhlDQoJCQk+ID4gPiA+IGluY2x1c2lvbg0KCQkJ PiA+ID4gPiA+IG9mICJUYW5kZW0gQ29ubmVjdGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbiB0 aGUgSVRVLVQgb2YNCgkJCT4gPiA+ID4gdGhpcyB0ZXJtDQoJCQk+ID4gPiA+ID4gaXMNCgkJCT4g PiA+ID4gcG9vcmx5DQoJCQk+ID4gPiA+ID4gc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZSBt b25pdG9yaW5nIG9mIGEgcGF0aCB0aGF0IGlzDQoJCQk+ID4gPiA+IHBhcmFsbGVsIChpLmUuDQoJ CQk+ID4gPiA+IHRhbmRlbSkNCgkJCT4gPiA+ID4gPiB0byB0aGUgZGF0YSBwYXRoIGJlaW5nIG1v bml0b3JlZC4gVGhpcyBkZWZpbml0aW9uIG9mIFRDDQoJCQk+ID4gPiA+IHNlZW1zIHRvIGJlIGF0 DQoJCQk+ID4gPiA+IHZhcmlhbmNlLA0KCQkJPiA+ID4gPiA+IGFuZCB3b3VsZCBiZSBpZiB0aGUg QUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gSSBkb24n dCB1bmRlcnN0YW5kIHdoZXJlIHlvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGFuZGVtDQoJCQk+ID4g Y29ubmVjdGlvbiBpcw0KCQkJPiA+ID4gPiBkZXNjcmliZWQgaW4gSVRVLVQgcmVjb21tZW5kYXRp b25zLiBJLmUuICJmcm9tIHRoZQ0KCQkJPiA+IG1vbml0b3Jpbmcgb2YgYQ0KCQkJPiA+ID4gPiBw YXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJlaW5n IA0KCQkJPiA+ID4gPiBtb25pdG9yZWQuIj8NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IFRoZXJl IGlzIGEgIm5ldHdvcmsgY29ubmVjdGlvbiIgYW5kIHRoaXMgbmV0d29yaw0KCQkJPiA+IGNvbm5l Y3Rpb24gaXMgYSBzZXQNCgkJCT4gPiA+ID4gb2YgaW50ZXJjb25uZWN0ZWQgImxpbmsgY29ubmVj dGlvbnMiIGFuZCAibWF0cml4DQoJCQk+IGNvbm5lY3Rpb25zIi4gQQ0KCQkJPiA+ID4gPiBzdWJz ZXQgb2YgdGhvc2UgaW50ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQgbWF0cml4IA0K CQkJPiA+ID4gPiBjb25uZWN0aW9ucyBjYW4gYmUgbW9uaXRvcmVkIGFuZCBpcyB0aGVuIHJlZmVy cmVkIHRvIGFzDQoJCQk+IGEgInRhbmRlbQ0KCQkJPiA+ID4gPiBjb25uZWN0aW9uIi4gVGhlcmUg aXMgbm8gInBhdGggdGhhdCBpcyBwYXJhbGxlbCB0byB0aGUNCgkJCT4gPiBkYXRhIHBhdGgiLiAN CgkJCT4gPiA+ID4gVGhlcmUgaXMgb25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBpbnNpZGUg dGhlIGRhdGENCgkJCT4gcGF0aCBieSB0aGUNCgkJCT4gPiA+ID4gVENNIE1FUF9TbyBmdW5jdGlv biBhbmQgdGhpcyBPQU0gaXMgZXh0cmFjdGVkIGZyb20gdGhlDQoJCQk+ID4gZGF0YSBwYXRoIGJ5 DQoJCQk+ID4gPiA+IHRoZSBUQ00gTUVQX1NrIGZ1bmN0aW9uLg0KCQkJPiA+ID4gPiANCgkJCT4g PiA+ID4gUmVnYXJkcywNCgkJCT4gPiA+ID4gTWFhcnRlbg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ ID4gDQoJCQk+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJCQk+ID4gPiA+IEZy b206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KCQkJPiA+ID4gPiBbbWFpbHRvOm1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCgkJCT4gPiA+ID4g U2VudDogZG9uZGVyZGFnIDE2IGFwcmlsIDIwMDkgMTE6NTkNCgkJCT4gPiA+ID4gVG86IEFsZXhh bmRlciBWYWluc2h0ZWluOyBiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbQ0KCQkJPiA+ID4g PiBDYzogQlVTSSBJVEFMTzsgbXBscy10cEBpZXRmLm9yZw0KCQkJPiA+ID4gPiBTdWJqZWN0OiBS ZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgkJ CT4gPiA+ID4gcmVxdWlyZW1lbnRzDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBIaSBTYXNoYSwN CgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ID4gVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmdWxseSBh Z3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50Og0KCQkJPiA+ID4gPiA+DQoJCQk+ID4gPiA+ID4gPHF1 b3RlPg0KCQkJPiA+ID4gPiA+ICAgICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJl LCBjby1yb3V0ZWQNCgkJCT4gPiA+IGJpZGlyZWN0aW9uYWwgTFNQcw0KCQkJPiA+ID4gPiA+ICAg ICBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuDQoJ CQk+ID4gPiA+ID4gPGVuZCBxdW90ZT4NCgkJCT4gPiA+ID4gPg0KCQkJPiA+ID4gPiA+IFRoaXMg c3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNseSBjb3JyZWN0LCB3ZXJlIGl0IG5vdCBmb3INCgkJ CT4gPiA+ID4gUmVxdWlyZW1lbnQNCgkJCT4gPiA+ID4gPiAzNCBpbiB0aGUgbGF0ZXN0IE1QTFMt VFAgcmVxdWlyZW1lbnRzIGRyYWZ0DQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBPSy4gR290IGl0 Lg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gQnV0IHdoYXQgaXMgdGhpcyBkb2luZyBpbiB0aGUg ZGF0YSBwbGFuZSByZXF1aXJlbWVudHMgc2VjdGlvbj8NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ IEluIGZhY3QsIHdoYXQgaXMgdGhpcyByZXF1aXJlbWVudCBhY3R1YWxseSBzYXlpbmc/DQoJCQk+ ID4gPiA+IA0KCQkJPiA+ID4gPiA+IDxxdW90ZT4NCgkJCT4gPiA+ID4gPiAgICAgIFRoZSBpbnRl cm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZyBNRVBzLCBNSVBzIGFuZA0KCQkJPiA+ID4gb3RoZXIg aW50ZXJuYWwNCgkJCT4gPiA+ID4gPiAgICAgICBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9m IGEgY28tcm91dGVkDQoJCQk+ID4gPiA+IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0DQoJCQk+ID4g PiA+ID4gICAgICAgcGF0aCBhdCBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhl IHBhaXJpbmcNCgkJCT4gPiA+ID4gPiAgICAgICByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQg YW5kIHRoZSBiYWNrd2FyZA0KCQkJPiA+ID4gPiBkaXJlY3Rpb25zIG9mIHRoYXQNCgkJCT4gPiA+ ID4gPiAgICAgICB0cmFuc3BvcnQgcGF0aC4NCgkJCT4gPiA+ID4gPiA8ZW5kIHF1b3RlPg0KCQkJ PiA+ID4gPiANCgkJCT4gPiA+ID4gVGhlcmUgaXMgbm8gd2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFs IHJlcXVpcmVtZW50LiBUaGF0DQoJCQk+ID4gaXMsIHRoZXJlIGlzDQoJCQk+ID4gPiA+ICpub3Ro aW5nKiB0aGF0IGNhbiBiZSBvYnNlcnZlZCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mDQoJCQk+ ID4gdmlldyB0aGF0DQoJCQk+ID4gPiA+IHJlc3VsdHMgZnJvbSBhZGhlcmluZyB0byB0aGlzIHJl cXVpcmVtZW50Lg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gVGhlcmVmb3JlIGl0IGNvdWxkIGJl IGFzc3VtZWQgdGhhdCB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBieSANCgkJCT4gPiA+ID4gY29u ZmlndXJpbmcgc29tZSBkYXRhIHBsYW5lIGRhdGFiYXNlIGNvbXBvbmVudCB0aHJvdWdoIHRoZSAN CgkJCT4gPiA+ID4gbWFuYWdlbWVudCBwbGFuZS4gVGhlIGRhdGFiYXNlIGNvbXBvbmVudCBpcyBu b3QgdXNlZA0KCQkJPiBmb3IgYW55dGhpbmcNCgkJCT4gPiA+ID4gZXhjZXB0IHRvIHNhdGlzZnkg dGhpcyByZXF1aXJlbWVudCBmb3IgImF3YXJlbmVzcyIuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4g PiBCZW4hIENhbiB3ZSBwbGVhc2UgdHJ5IHRvIHJld3JpdGUgdGhpcyByZXF1aXJlbWVudCBpbiB0 ZXJtcyBvZiANCgkJCT4gPiA+ID4gYmVoYXZpb3I/DQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiA+ IFBsZWFzZSBub3RlIHRoYXQgUmVxdWlyZW1lbnQgMzQgaXMgdGhlIE9OTFkgaXRlbSBpbiB0aGUN CgkJCT4gPiA+ID4gbGlzdCB0aGF0IGlzDQoJCQk+ID4gPiA+ID4gc3BlY2lmaWMgZm9yIGNvLXJv dXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChUaGUgcGFpcmluZw0KCQkJPiA+ID4gPiByZXF1aXJl bWVudHMNCgkJCT4gPiA+ID4gPiBhdCBlbmQgcG9pbnRzIGZvciBjby1yb3V0ZWQgYW5kIGFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbA0KCQkJPiA+ID4gcGF0aHMgYXJlDQoJCQk+ID4gPiA+ID4gZXhh Y3RseSB0aGUgc2FtZSBldmVuIGlmIHRoZXkgYXBwZWFyIGluIHR3byBkaWZmZXJlbnQNCgkJCT4g PiA+IGl0ZW1zIGluIHRoZQ0KCQkJPiA+ID4gPiA+IHJlcXVpcmVtZW50cycgbGlzdCkuDQoJCQk+ ID4gPiA+ID4gSW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgUmVxdWlyZW1lbnQgMzQgdGhlIG5vdGlv biBvZg0KCQkJPiBjby1yb3V0ZWQNCgkJCT4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBhdGhzIHdv dWxkIGJlIHZvaWQgb2YgYW55IGRhdGEgcGxhbmUgY29udGVudC4NCgkJCT4gPiA+ID4gPg0KCQkJ PiA+ID4gPiA+IFRoZSBzb21ld2hhdCB2YWd1ZSBzY29wZSBvZiB0aGlzIHJlcXVpcmVtZW50ICgi b3RoZXIgaW50ZXJuYWwgDQoJCQk+ID4gPiA+ID4gZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlIikg Y3JlYXRlcyBhIHN1c3BpY2lvbiB0aGF0IEhXDQoJCQk+ID4gPiA+IHN1cHBvcnQgb2YgdGhlDQoJ CQk+ID4gPiA+ID4gcGFpcmluZyBhd2FyZW5lc3MgbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIHRv IGNvbXBseSB3aXRoIGl0Lg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gVGhlIGVudGlyZXR5IG9m IHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRpbmcgTUVQcywNCgkJCT4gPiBNSVBzIGFuZCBv dGhlcg0KCQkJPiA+ID4gPiBpbnRlcm5hbCBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91 bGQgYmUgZGVsZXRlZC4gSXQNCgkJCT4gPiBkb2VzIG5vdA0KCQkJPiA+ID4gPiBhZGQgdG8gIlRo ZSBpbnRlcm1lZGlhdGUgbm9kZXMuIg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gPiBUaGUgZm9s bG93aW5nIHRleHQgaW4gdGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzIHN1c3BpY2lvbjoNCgkJCT4g PiA+ID4gPg0KCQkJPiA+ID4gPiA+IDxxdW90ZT4NCgkJCT4gPiA+ID4gPiAgIFRhbmRlbSBDb25u ZWN0aW9uOiBBIHRhbmRlbSBjb25uZWN0aW9uIGlzIGFuDQoJCQk+ID4gYXJiaXRyYXJ5IHBhcnQg b2YgYQ0KCQkJPiA+ID4gPiA+ICAgdHJhbnNwb3J0IHBhdGggdGhhdCBjYW4gYmUgbW9uaXRvcmVk ICh2aWEgT0FNKQ0KCQkJPiA+ID4gPiBpbmRlcGVuZGVudGx5IGZyb20gdGhlDQoJCQk+ID4gPiA+ ID4gICBlbmQtdG8tZW5kIG1vbml0b3JpbmcgKE9BTSkuICBJdCBtYXkgYmUgYSBtb25pdG9yZWQN CgkJCT4gPiBzZWdtZW50IG9yIGENCgkJCT4gPiA+ID4gPiAgIG1vbml0b3JlZCBjb25jYXRlbmF0 ZWQgc2VnbWVudCBvZiBhIHRyYW5zcG9ydCBwYXRoLiAgDQoJCQk+ID4gVGhlIHRhbmRlbQ0KCQkJ PiA+ID4gPiA+ICAgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVu Z2luZShzKSBvZg0KCQkJPiA+ID4gPiB0aGUgbm9kZShzKQ0KCQkJPiA+ID4gPiA+ICAgYXQgdGhl IGVkZ2Uocykgb2YgdGhlIHNlZ21lbnQgb3IgY29uY2F0ZW5hdGVkIHNlZ21lbnQuDQoJCQk+ID4g PiA+ID4gPGVuZCBxdW90ZT4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IEFjdHVhbGx5LCBJIGFt IHF1aXRlIGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQNCgkJCT4gPiBpbnNpc3RlbmNlIG9u IHRoZQ0KCQkJPiA+ID4gPiBpbmNsdXNpb24gb2YgIlRhbmRlbSBDb25uZWN0aW9uLiIgVGhlIGRl ZmluaXRpb24gd2l0aGluDQoJCQk+ID4gdGhlIElUVS1UIG9mDQoJCQk+ID4gPiA+IHRoaXMgdGVy bSBpcyBwb29ybHkgc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZQ0KCQkJPiBtb25pdG9yaW5n IG9mIGENCgkJCT4gPiA+ID4gcGF0aCB0aGF0IGlzIHBhcmFsbGVsIChpLmUuIHRhbmRlbSkgdG8g dGhlIGRhdGEgcGF0aCBiZWluZyANCgkJCT4gPiA+ID4gbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRp b24gb2YgVEMgc2VlbXMgdG8gYmUgYXQgdmFyaWFuY2UsDQoJCQk+ID4gYW5kIHdvdWxkDQoJCQk+ ID4gPiA+IGJlIGlmIHRoZSBBQ0ggd2FzIGFjdHVhbGx5IGluIGJhbmQuDQoJCQk+ID4gPiA+IA0K CQkJPiA+ID4gPiA+IERvZXNuJ3QgImZvcndhcmRpbmcgZW5naW5lIiBzb3VuZCBsaWtlIGhhcmR3 YXJlIHRvIHlvdT8NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IFllcywgYnV0IHNvIHdoYXQ/DQoJ CQk+ID4gPiA+IA0KCQkJPiA+ID4gPiA+IElNSE8gaXQgaXMgd29ydGggbm90aW5nIHRoYXQgbmVp dGhlciB0aGUgTVBMUy1UUA0KCQkJPiA+ID4gUmVxdWlyZW1lbnRzIGRyYWZ0DQoJCQk+ID4gPiA+ ID4gbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25lDQoJCQk+ID4gPiA+ID4gDQoJ CQk+ID4gPiA+IA0KCQkJPiA+ID4gDQoJCQk+ID4gDQoJCQk+IChodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVtZW4NCgkJCT4g PiA+ID4gPiB0cy0wMS50eHQpIGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGgg dGFuZGVtDQoJCQk+ID4gPiBjb25uZWN0aW9ucy4NCgkJCT4gPiA+ID4gPg0KCQkJPiA+ID4gPiA+ IEJ1dCB0YW5kZW0gY29ubmVjdGlvbnMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgTVBMUy1UUCBPQU0N CgkJCT4gPiBGcmFtZXdvcmsNCgkJCT4gPiA+ID4gPiBkcmFmdA0KCQkJPiA+ID4gPiAoaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1mcg0K CQkJPiA+ID4gPiBhbWV3b3JrLTAwLnR4dA0KCQkJPiA+ID4gPiApLg0KCQkJPiA+ID4gPiANCgkJ CT4gPiA+ID4gUmlnaHQuDQoJCQk+ID4gPiA+IExldCdzIGp1c3QgZ2V0IHJpZCBvZiBhbiB1bm5l Y2Vzc2FyeSB0ZXJtIGFuZCBicmluZyBhbGwNCgkJCT4gdGhlIEktRHMNCgkJCT4gPiA+ID4gaW50 byBsaW5lLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gPiBUaGUgYm90dG9tIGxpbmUsIElNSE8s IGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2FyZGluZw0KCQkJPiA+ID4gY28tcm91dGVkIHZzLg0K CQkJPiA+ID4gPiA+IGFzc29jaWF0ZWQNCgkJCT4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBhdGhz IGlzIHN0aWxsIHJlcXVpcmVkLiBPbmUgd2F5IHRvIHByb3ZpZGUNCgkJCT4gPiA+ID4gdGhhdCBj b3VsZA0KCQkJPiA+ID4gPiA+IGJlIGJ5IGV4cGxpY2l0bHkgbGltaXRpbmcgUmVxdWlyZW1lbnQg MzQgdG8gc3BlY2lmaWMNCgkJCT4gPiA+IGZ1bmN0aW9uYWxpdHkuDQoJCQk+ID4gPiA+IA0KCQkJ PiA+ID4gPiBBZ3JlZWQuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBBZHJpYW4NCgkJCT4gPiA+ ID4gDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgkJCT4gPiA+ID4gRnJvbTog QWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5jby51a10NCgkJCT4gPiA+ID4gU2VudDogVGh1 cnNkYXksIEFwcmlsIDE2LCAyMDA5IDEyOjEzIEFNDQoJCQk+ID4gPiA+IFRvOiBBbGV4YW5kZXIg VmFpbnNodGVpbjsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTw0KCQkJPiA+ID4gPiBDYzogbXBscy10 cEBpZXRmLm9yZw0KCQkJPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgkJCT4gPiA+ID4gcmVxdWlyZW1lbnRzDQoJ CQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBIaSBTYXNoYSwNCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+ IE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5nIGFueW9uZSwg YnV0Li4uDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiA+IDEuIE15IHJlYWRpbmcgb2YgIG9uZSBv ZiBCZW4ncyAgbWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkIA0KCQkJPiA+ID4gPiA+IGJpZGly ZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBvbmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQgY2FuIGJlDQoJ CQk+ID4gPiA+IGNyZWF0ZWQgaW4NCgkJCT4gPiA+ID4gPiB0aGUgZXhpc3RpbmcgbmV0d29ya3M7 ICJ0cnVlIiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocw0KCQkJPiA+ID4gPiB3aWxsIGhh dmUNCgkJCT4gPiA+ID4gPiB0byB3YWl0IHVudGlsIChpZiBldmVyKSBuZXcgZXF1aXBtZW50IGJl Y29tZXMgYXZhaWxhYmxlLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gVGhpcyBpcyBjbGVhcmx5 IG5vbnNlbnNlIQ0KCQkJPiA+ID4gPiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJl LCBjby1yb3V0ZWQNCgkJCT4gPiBiaWRpcmVjdGlvbmFsIExTUHMgYXJlDQoJCQk+ID4gPiA+IGEg c3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLg0KCQkJPiA+ID4g PiANCgkJCT4gPiA+ID4gSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMg KGUuZy4gdXNpbmcgdGhlDQoJCQk+ID4gbWFuYWdlbWVudA0KCQkJPiA+ID4gPiBwbGFuZSkgeW91 IGNhbiBzdXJlbHkgc2V0IHVwIGEgY28tcm91dGVkDQoJCQk+ID4gPiBiaWRpcmVjdGlvbmFsIExT UC4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IFRoZXJlIGFyZSBzaGlwcGluZyBzb2x1dGlvbnMg dGhhdCBhY2hpZXZlIGNvLXJvdXRlZA0KCQkJPiBiaWRpcmVjdGlvbmFsDQoJCQk+ID4gPiA+IExT UHMgdXNpbmcgdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNlIGVpdGhlciB1c2UgdGhlIEdNUExTDQoJ CQk+ID4gKHdoaWNoIGlzDQoJCQk+ID4gPiA+IGNsZWFuZXIpIG9yIG5vbi1zdGFuZGFyZCBwcm9w cmlldGFyeSBzb2x1dGlvbnMgKHdoaWNoIGlzDQoJCQk+ID4gbWVzc3kgYnV0DQoJCQk+ID4gPiA+ IGZ1bmN0aW9uYWwpLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gQnV0IChvZiBjb3Vyc2UpIHRo ZSBtYW5hZ2VtZW50IHBsYW5lIG9yIGNvbnRyb2wgcGxhbmUNCgkJCT4gPiBzb2x1dGlvbnMgaGF2 ZQ0KCQkJPiA+ID4gPiBub3RoaW5nIHRvIGRvIHdpdGggYXZhaWxhYmlsaXR5IG9mIGVxdWlwbWVu dCBhcyB0aGV5IA0KCQkJPiBhcmUgc29mdHdhcmUNCgkJCT4gPiA+ID4gc29sdXRpb25zLg0KCQkJ PiA+ID4gPiANCgkJCT4gPiA+ID4gPiAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVz c2FnZXMgaXMgdGhhdCB0aGUgYWN0dWFsDQoJCQk+ID4gPiA+IGRyaXZlciBmb3INCgkJCT4gPiA+ ID4gPiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRo IGV4aXN0aW5nIA0KCQkJPiA+ID4gPiA+IHRyYW5zcG9ydCBuZXR3b3JrcyByYXRoZXIgdGhhbiBh bnkgc3BlY2lmaWMgYmVuZWZpdC4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IElzbid0IHRoYXQg dGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPw0KCQkJPiA+ID4g PiBXaGljaCBpcyBub3QgdG8gc2F5IGl0IGlzIGEgYmFkIHRoaW5nLg0KCQkJPiA+ID4gPiANCgkJ CT4gPiA+ID4gQSBsYXJnZSBkcml2ZXIgZm9yIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0 IG5ldHdvcmsNCgkJCT4gPiB0aGUgbG9vaywNCgkJCT4gPiA+ID4gZmVlbCwgYW5kIGJlaGF2aW9y YWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgImxlZ2FjeSINCgkJCT4gPiA+ID4gdHJhbnNwb3J0IG5l dHdvcmsuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiA+IEJhc2VkIG9uIHRoZXNlIG9ic2VydmF0 aW9ucywgSSdkIGd1ZXNzIChGV0lXKSB0aGF0Og0KCQkJPiA+ID4gPiA+ICogYXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHBhdGhzIGFyZSwgYXQgbGVhc3QgZm9yIHRoZSB0aW1lDQoJCQk+ID4gPiA+ ID4gICAgYmVpbmcsIHRoZSBtb3N0IGltcG9ydGFudCB0eXBlIG9mIGJpZGlyZWN0aW9uYWwgcGF0 aHMgaW4NCgkJCT4gPiA+ID4gPiAgICBNUExTLVRQDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBJ IHRoaW5rIHRoYXQgaXMgd3JvbmcgYm90aCBnaXZlbiBteSBzdGF0ZW1lbnQgYWJvdmUsIGFuZA0K CQkJPiA+IGdpdmVuIHRoYXQNCgkJCT4gPiA+ID4gb3RoZXIgdXBncmFkZXMgdG8gZXhpc3Rpbmcg TVBMUyBzb2x1dGlvbnMgd2lsbCBiZQ0KCQkJPiBuZWVkZWQgdG8gcmVhY2gNCgkJCT4gPiA+ID4g dGhlIGZ1bGwgZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC4NCgkJCT4gPiA+ID4gDQoJCQk+ID4g PiA+ID4gKiB0aGV5IGhhZCBhIGdvb2QgY2hhbmNlIHRvIHJlbWFpbiB0aGUgb25seSB0eXBlIG9m DQoJCQk+ID4gYmlkaXJlY3Rpb25hbA0KCQkJPiA+ID4gPiA+ICAgcGF0aHMgaW4gIHJlYWwgZGVw bG95bWVudHMuDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBJIGRvbid0IHNlZSB3aGF0IHRoYXQg Zm9sbG93cyBmcm9tLg0KCQkJPiA+ID4gPiANCgkJCT4gPiA+ID4gQ2hlZXJzLA0KCQkJPiA+ID4g PiBBZHJpYW4NCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoJCQk+ID4gPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0 DQoJCQk+ID4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCT4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoJCQk+ID4gPiA+IA0KCQkJPiA+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCQkJPiA+ID4g PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KCQkJPiA+ID4gPiBtcGxzLXRwQGlldGYub3JnDQoJCQk+ ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQkJ PiA+ID4gPiANCgkJCT4gPiA+ID4gDQoJCQk+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KCQkJPiA+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCgkJ CT4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCT4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQkJPiA+ID4gDQoJCQk+ID4gDQoJCQk+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJCQk+IG1wbHMtdHAgbWFp bGluZyBsaXN0DQoJCQk+IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCT4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoJCQk+IA0KCQkJX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgkJCW1wbHMtdHAgbWFpbGluZyBsaXN0DQoJ CQltcGxzLXRwQGlldGYub3JnDQoJCQlodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMtdHANCgkJCQ0KCQkJDQoJCQktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCQkJWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0 aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVk IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KCQkJVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KCQkJVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQoJCQkNCgkJCQ0KCQkJDQoJCQkt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K CQkJWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFy ZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmlj YXRpb24gdG8gb3RoZXJzLg0KCQkJVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KCQkJVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQoNCg== ------_=_NextPart_001_01C9C4D8.90E903CF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0yNzQ1NjMwMTItMjQwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5JIGZ1bGx5IGFncmVlIHdpdGgg QW5keSBvbiANCnRoaXMuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxTUEFOIGNsYXNzPTI3NDU2MzAxMi0yNDA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNh bnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0yNzQ1NjMwMTItMjQwNDIwMDk+PEZP TlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5yZWdhcmRzLCBO ZWlsPC9GT05UPjwvU1BBTj48L0RJVj48QlI+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9 IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzgwMDAw MCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVz c2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4 PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZyANCiAgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9u IEJlaGFsZiBPZiANCiAgPC9CPmFuZHkuYmQucmVpZEBidC5jb208QlI+PEI+U2VudDo8L0I+IDI0 IEFwcmlsIDIwMDkgMTE6MzQ8QlI+PEI+VG86PC9CPiANCiAgbWFhcnRlbi52aXNzZXJzQGh1YXdl aS5jb208QlI+PEI+Q2M6PC9CPiBtcGxzLXRwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiAN CiAgUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgg DQogIHJlcXVpcmVtZW50czxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0zNjUzNDA5MTAtMjQwNDIwMDk+PEZP TlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+TWFhcnRlbiw8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0zNjUzNDA5 MTAtMjQwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9MzY1MzQwOTEwLTI0MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPlRoZXNlIHBvaW50cyBhcmUgaXJyZWxldmFudCB0byB0aGUgcG9pbnRzIEkgbWFk ZS4gTXkgDQogIHBvaW50IGlzIHRoYXQgQUlTL0ZESSBnaXZlcyBubyBpbmZvcm1hdGlvbiBhYm92 ZSB3aGF0IGlzIGFscmVhZHkga25vd24gLSBpdCBpcyANCiAgb25seSBhZGRzIGNvbXBsZXhpdHkg YW5kIGZhdWx0IGxpYWJpbGl0eS4gTmVpdGhlciBvZiB5b3VyIHBvaW50cyBjaGFuZ2UgDQogIHRo aXMuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9MzY1MzQwOTEwLTI0MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTM2NTM0MDkxMC0yNDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0K ICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5BbmR5PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBk aXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MzY1MzQwOTEwLTI0MDQyMDA5PjxGT05UIGZh Y2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9E SVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3J0ZiBmb3Jt YXQgLS0+DQogIDxQPjxCPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j ODA4MDgwIHNpemU9Mj5BbmR5IA0KICBSZWlkPC9GT05UPjwvU1BBTj48L0I+IDxCUj48U1BBTiBs YW5nPWVuLXVzPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkNoaWVmIA0KICBOZXR3b3JrIFNlcnZp Y2VzIFN0cmF0ZWdpc3Q8L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCAN CiAgZmFjZT1BcmlhbCBzaXplPTI+QlQgSW5ub3ZhdGU8L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4g bGFuZz1lbi11cz48VT48Rk9OVCANCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCiAgc2l6ZT0y PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L1U+PC9TUEFOPiANCiAgPEJSPjxT UEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+T2ZmaWNlOiArNDQgKDApMTI3 NyANCiAgMzIyMDM4PC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+TW9iaWxlOiArNDQgDQogICgwKTc5MTcgMDI1NDUxPC9GT05UPjwvU1BB Tj4gPEJSPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPkZheCZu YnNwOzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKzQ0ICgwKTEyNzcgDQog IDMyNDAxNTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+IDxCUj48U1BBTiBs YW5nPWVuLXVzPjxGT05UIA0KICBmYWNlPUFyaWFsIHNpemU9Mj5FbWFpbDombmJzcDsgYW5keS5i ZC5yZWlkQGJ0LmNvbTwvRk9OVD48L1NQQU4+IDwvUD4NCiAgPFA+PFNQQU4gbGFuZz1lbi1nYj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDgwODAgDQogIHNpemU9MT48L0ZPTlQ+PC9TUEFOPjxC Uj48U1BBTiBsYW5nPWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwODA4MCANCiAgc2l6 ZT0xPkJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYzxCUj5SZWdpc3RlcmVkIG9mZmljZTog ODEgTmV3Z2F0ZSBTdHJlZXQgDQogIExvbmRvbiBFQzFBIDdBSjxCUj5SZWdpc3RlcmVkIGluIEVu Z2xhbmQgbm8uIDE4MDAwMDA8L0ZPTlQ+IDwvU1BBTj48QlI+PFNQQU4gDQogIGxhbmc9ZW4tZ2I+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jODA4MDgwIHNpemU9MT5UaGlzIGVsZWN0cm9uaWMgbWVz c2FnZSANCiAgY29udGFpbnMgaW5mb3JtYXRpb24gZnJvbSBCcml0aXNoIFRlbGVjb21tdW5pY2F0 aW9ucyBwbGMgd2hpY2ggbWF5IGJlIA0KICBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhl IGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9mIA0KICB0aGUgaW5k aXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgDQogIGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcs IGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIA0KICB0aGlzIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZWxlY3Ryb25pYyBt ZXNzYWdlIA0KICBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBieSB0ZWxlcGhvbmUgb3IgZW1h aWwgKHRvIHRoZSBudW1iZXJzIG9yIGFkZHJlc3MgDQogIGFib3ZlKSBpbW1lZGlhdGVseS48L0ZP TlQ+PC9TUEFOPjwvUD4NCiAgPFA+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSM4MDgwODAgc2l6ZT0xPkFjdGl2aXR5IGFuZCB1c2Ugb2YgDQogIHRoZSBCcml0aXNoIFRl bGVjb21tdW5pY2F0aW9ucyBwbGMgZW1haWwgc3lzdGVtIGlzIG1vbml0b3JlZCB0byBzZWN1cmUg aXRzIA0KICBlZmZlY3RpdmUgb3BlcmF0aW9uIGFuZCBmb3Igb3RoZXIgbGF3ZnVsIGJ1c2luZXNz IHB1cnBvc2VzLiBDb21tdW5pY2F0aW9ucyANCiAgdXNpbmcgdGhpcyBzeXN0ZW0gd2lsbCBhbHNv IGJlIG1vbml0b3JlZCBhbmQgbWF5IGJlIHJlY29yZGVkIHRvIHNlY3VyZSANCiAgZWZmZWN0aXZl IG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBidXNpbmVzcyBwdXJwb3Nlcy48L0ZPTlQ+ PC9TUEFOPjwvUD4NCiAgPERJVj4mbmJzcDs8L0RJVj48QlI+DQogIDxCTE9DS1FVT1RFIGRpcj1s dHIgDQogIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVS LUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgPERJViBj bGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4N CiAgICA8SFIgdGFiSW5kZXg9LTE+DQogICAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZy b206PC9CPiBNYWFydGVuIFZpc3NlcnMgDQogICAgW21haWx0bzptYWFydGVuLnZpc3NlcnNAaHVh d2VpLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiAyMyBBcHJpbCAyMDA5IA0KICAgIDIwOjQyPEJSPjxC PlRvOjwvQj4gUmVpZCxBQkQsQW5keSxDWE0gUjxCUj48Qj5DYzo8L0I+IA0KICAgIG1wbHMtdHBA aWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIA0KICAgIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxCUj48L0ZPTlQ+PEJS PjwvRElWPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ QU4gY2xhc3M9NzgxNDI0OTE4LTIzMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9 IzAwMDBmZiBzaXplPTI+QW5keSw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc4MTQyNDkxOC0yMzA0MjAwOT48Rk9OVCBmYWNlPUFy aWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzgxNDI0OTE4LTIzMDQy MDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+Jmd0OyA8U1BB TiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0j MDAwMGZmIHNpemU9Mj5UaGUgcHJvYmxlbSBpcyAqbm90KiBhYm91dCBhIGxhY2sgb2YgYWxhcm0g c3VwcHJlc3Npb24gDQogICAgaW4gdGhlIGRhdGEgcGxhbmUgLSB0aGF0IGluZm9ybWF0aW9uIGlz IHJlYWRpbHkgDQogICAgYXZhaWxhYmxlLjwvRk9OVD48L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJ Vj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03ODE0MjQ5MTgtMjMw NDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiAN CiAgICBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PC9TUEFOPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzgxNDI0OTE4 LTIzMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PkkgZG9uJ3QgYmVsaWV2ZSB0aGF0IA0KICAgIHRo aXMgaXMgYSBjb3JyZWN0IHN0YXRlbWVudCBpbiBhIG11bHRpLW9wZXJhdG9yIHRyYW5zcG9ydCBu ZXR3b3JrLCBvciBpbiANCiAgICB0cmFuc3BvcnQgbmV0d29ya3Mgb2Ygb25lIG9wZXJhdG9yIHRo YXQgaGF2ZSBtb3JlIHRoZW4gb25lIGFkbWluaXN0cmF0aXZlIA0KICAgIHN1YmRvbWFpbiAoZWFj aCB3aXRoIGl0cyBvd24gbmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbSkuIEEgcHJvYmxlbSBvY2N1 cmluZyANCiAgICBpbiBhZG1pbiBkb21haW4gQSB3aWxsIGJlIHVua25vd24gaW4gYWRtaW4gZG9t YWluIEIuIFRoZSBsb3NzIG9mIGNvbnRpbnVhaXR5IA0KICAgIGFsYXJtcyB0aGF0IGFyZSBhY3Rp dmF0ZWQgaW4gYWRtaW4gZG9tYWluIEIgZHVlIHRvIHRoZSBmYXVsdCBpbiBhZG1pbiBkb21haW4g DQogICAgQSB3aWxsIGFwcGVhciBhcyBwcmltYXJ5IGFsYXJtcywgc3VnZ2VzdGluZyBjb25uZWN0 aXZpdHkgcHJvYmxlbXMgaW4gYWRtaW4gDQogICAgZG9tYWluIEIuPC9TUEFOPjwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzgxNDI0 OTE4LTIzMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQogICAgY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjwvU1BBTj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc4 MTQyNDkxOC0yMzA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT4mZ3Q7IDxTUEFOIA0KICAgIGNsYXNz PTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PlRoZSBpc3N1ZSANCiAgICBhcmlzZXMgYmVjYXVzZSB0aGUgdHdvIHNpZGVzIG9mIG1haW50ZW5h bmNlIHdhbnQgZGlmZmVyZW50IHRoaW5ncy4gVGhlIGZhdWx0IA0KICAgIGZpeGluZzwvRk9OVD48 L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9NzgxNDI0OTE4LTIzMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQog ICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxT UEFOIA0KICAgIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgDQogICAgc2l6ZT0yPiZndDsmbmJzcDtndXlzIHdhbnQgdG8gbG9jYXRlIHRoZSBm YXVsdCBhbmQgZG9uJ3Qgd2FudCBhbnkgb3RoZXIgDQogICAgaW5mb3JtYXRpb24uIFRoZSBzZXJ2 aWNlIA0KbWFpbnRlbmFuY2U8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc4MTQyNDkxOC0yMzA0 MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNs YXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48U1BBTiANCiAgICBjbGFzcz0xNjQzMDIzMDktMjIwNDIw MDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgIHNpemU9Mj4mZ3Q7Jm5ic3A7 Z3V5cyB3YW50IHRvIGtub3cgd2hldGhlciB0aGVpciBjdXN0b21lciBzZXJ2aWNlIGlzIA0KICAg IHdvcmtpbmcuPC9GT05UPjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8 RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz03ODE0MjQ5MTgtMjMwNDIwMDk+VGhpcyBpcyBhZGRy ZXNzZWQgaW4gU0RILCBPVE4sIEV0aGVybmV0IGFuZCBULU1QTFMgDQogICAgcmVjb21tZW5kYXRp b25zIGJ5IG1lYW5zIG9mIHRoZSBhZGRpdGlvbmFsJm5ic3A7U1NGIGFsYXJtLiBUaGUgU1NGIGFs YXJtIGlzIA0KICAgIGZvciB0aGUgc2VydmljZSBndXlzIHRlbGxpbmcgdGhlbSB0aGF0IHRoZSBz ZXJ2aWNlIHdhcyBpbnRlcnJ1cHRlZCBkdWUgdG8gYSANCiAgICBmYXVsdCBpbiBhIHNlcnZlciBs YXllci4gQUlTIHN1cHByZXNzZXMgdGhlIExPQyBhbGFybSBpbiB0aG9zZSBjYXNlcyBzbyB0aGF0 IA0KICAgIHRoZSBtYWludGVuYW5jZSBndXlzIGRvbid0IGdldCB0cmlnZ2VyZWQgYW5kIHN0YXJ0 IGxvb2tpbmcgZm9yIGEgZmF1bHQgdGhhdCANCiAgICBpcyBvdXRzaWRlIHRoZWlyIGFyZWEuPC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiBzaXplPTI+PFNQQU4gDQogICAgY2xhc3M9NzgxNDI0OTE4LTIzMDQyMDA5PjwvU1BBTj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTc4MTQyNDkxOC0yMzA0MjAwOT5SZWdhcmRzLDwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTc4MTQyNDkxOC0yMzA0MjAwOT5NYWFydGVuPC9TUEFO PjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEJSPjwvRElWPg0KICAgIDxESVYg Y2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+ DQogICAgPEhSIHRhYkluZGV4PS0xPg0KICAgIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5G cm9tOjwvQj4gbXBscy10cC1ib3VuY2VzQGlldGYub3JnIA0KICAgIFttYWlsdG86bXBscy10cC1i b3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgDQogICAgPC9CPmFuZHkuYmQucmVpZEBi dC5jb208QlI+PEI+U2VudDo8L0I+IHdvZW5zZGFnIDIyIGFwcmlsIDIwMDkgDQogICAgMTI6MTQ8 QlI+PEI+VG86PC9CPiBsaXUuZ3VvbWFuQHp0ZS5jb20uY247IA0KICAgIG5laWwuMi5oYXJyaXNv bkBidC5jb208QlI+PEI+Q2M6PC9CPiBtcGxzLXRwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9C PiBSZTogDQogICAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQg cGF0aCANCiAgICByZXF1aXJlbWVudHM8QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgICA8RElWPjwv RElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0y MjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkxpdSw8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFs aWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwg DQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+QWxsb3cgbWUgdG8ganVtcCBpbi4gWW91IGFyZSBi cmluZ2luZyB0b2dldGhlciB0d28gDQogICAgdGhpbmdzIHdoaWNoIGFyZSBzZXBhcmF0ZSBhbmQg Zm9yIHdoaWNoIEFJUy9GREkgaXMgbm8gaGVscC4gTWFpbnRlbmFuY2UgDQogICAgb3BlcmF0aW9u cyBhcmUgY29uY2VybmVkIHdpdGggdHdvIHNlcGFyYXRlIHRoaW5ncy48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0y MjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAw MDBmZiBzaXplPTI+MSkmbmJzcDsgSWRlbnRpZnlpbmcgZmF1bHRzIGluIGVxdWlwbWVudCwgbGlu ZSBwbGFudCwgDQogICAgYW5kIG90aGVyIHN5c3RlbXMgKGVnIG1pc2NvbmZpZ3VyYXRpb25zKSBh bmQgZml4aW5nIHRoZW0gKGVxdWlwbWVudCANCiAgICBtYWludGVuYW5jZSkuPC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIz MDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4y KSZuYnNwOyBJZGVudGlmeWluZyB0aGUgaGVhbHRoIG9mIGVuZCB0byBlbmQgDQogICAgY29ubmVj dGlvbnMsIGVzcGVjaWFsbHkgd2hlbiB0aGV5IGFyZSBkaXJlY3RseSBzdXBwb3J0aW5nIGN1c3Rv bWVyIHNlcnZpY2VzIA0KICAgIChzZXJ2aWNlIG1haW50ZW5hbmNlKS48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0y MjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAw MDBmZiBzaXplPTI+VGhlIHByb2JsZW0gaXMgKm5vdCogYWJvdXQgYSBsYWNrIG9mIGFsYXJtIHN1 cHByZXNzaW9uIA0KICAgIGluIHRoZSBkYXRhIHBsYW5lIC0gdGhhdCBpbmZvcm1hdGlvbiBpcyBy ZWFkaWx5IGF2YWlsYWJsZS4gSWYsIGF0IGFuIGVuZCANCiAgICBlcXVpcG1lbnQsIEkgaGF2ZSBh IGdvb2Qgc2VydmVyL3NlY3Rpb24gbGF5ZXIgYW5kIGEgbG9zcyBvZiBDQyBhdCB0aGUgY2xpZW50 IA0KICAgIGxheWVyLCBJICprbm93KiB0aGUgZmF1bHQgaXMgZWxzZXdoZXJlIC0gSSBkb24ndCBu ZWVkIEFJUy9GREkgdG8gdGVsbCBtZS4gDQogICAgKEluZGVlZCwgaWYgeW91IHRoaW5rIGFib3V0 LCBpZiB0aGUgZmF1bHQgaXMgaW4gdGhlIGVuZCBlcXVpcG1lbnQsIGl0IGlzIA0KICAgIHF1aXRl IGxpa2VseSB0aGF0IHRoZSBmYXVsdCBtZWFucyBpdCBjYW5ub3QgcmVwb3J0IHRoZSB0cmFmZmlj IGxvc3MgdG8gdGhlIA0KICAgIG1hbmFnZW1lbnQgc3lzdGVtISk8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0 MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBm ZiBzaXplPTI+VGhlIGlzc3VlIGFyaXNlcyBiZWNhdXNlIHRoZSB0d28gc2lkZXMgb2YgbWFpbnRl bmFuY2UgDQogICAgd2FudCBkaWZmZXJlbnQgdGhpbmdzLiBUaGUgZmF1bHQgZml4aW5nIGd1eXMg d2FudCB0byBsb2NhdGUgdGhlIGZhdWx0IGFuZCANCiAgICBkb24ndCB3YW50IGFueSBvdGhlciBp bmZvcm1hdGlvbi4gVGhlIHNlcnZpY2UgbWFpbnRlbmFuY2UgZ3V5cyB3YW50IHRvIGtub3cgDQog ICAgd2hldGhlciB0aGVpciBjdXN0b21lciBzZXJ2aWNlIGlzIHdvcmtpbmcuPC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIz MDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPlRoaXMgYXJvc2UgaW4gdGhlIGVhcmx5IGRheXMgb2YgU09ORVQvU0RI LCB3aGVuIHRoZSANCiAgICBvcGVyYXRpb25zIGd1eXMgZGVtYW5kZWQgdGhhdCB0aGUgZXF1aXBt ZW50IGRpZCAqbm90KiBzdXBwcmVzcyB0aGUgdHJhZmZpYyANCiAgICBhbGFybSBldmVuIHdoZW4g QUlTIHdhcyBiZWluZyByZWNlaXZlZCBhcyB0aGUgc2VydmljZSBndXlzIHdhbnQgdG8ga25vdyAN CiAgICBhYm91dCB0aGUgYWxhcm1zLiBUaGUgbm9ybWFsIHByYWN0aWNlIGlzIGZvciB0aGUgZXF1 aXBtZW50IHRvJm5ic3A7cmVwb3J0IA0KICAgIHRoZSBhbGFybXMgKmluY2x1ZGluZyogQUlTIGFu ZCB0aGVuIGEgZmlsdGVyIGlzIGFwcGxpZWQgaW4gdGhlIG1hbmFnZW1lbnQgDQogICAgc3lzdGVt Jm5ic3A7dG8gc3VwcHJlc3MgYWxhcm1zIHRvIHRoZSBmYXVsdCBmaXhpbmcgZ3V5cy4gQXMgSSdt IGF3YXJlLCB0aGVyZSANCiAgICBhcmUgbWFueSBkaWZmZXJlbnQgdGVjaG5pcXVlcyBhcHBsaWVk IGZvciB0aGUgZmlsdGVyaW5nIGFsZ29yaXRobXMsIA0KICAgIGVzcGVjaWFsbHkgd2hlbiB5b3Ug Y29uc2lkZXIgbXVsdGlwbGUgY29uY3VycmVudCBmYXVsdHMgaW4gYSBuZXR3b3JrLCANCiAgICBo b3dldmVyLCB0aGUgZXhpc3RhbmNlIG9mIEFJUy9GREkgZG9lc24ndCBhZGQgYW55dGhpbmcgdG8g dGhlc2UgdGhhdCdzIG5vdCANCiAgICBhbHJlYWR5IGtub3duLiBJbiBmYWN0LCBJIGJlbGlldmUg c2ltcGxlJm5ic3A7dGltZS1zdGFtcCBjb3JyZWxhdGlvbiBpcyBvbmUgDQogICAgb2YgdGhlIG1v c3QgcG93ZXJmdWwgYW5kIHdpZGVseSB1c2VkIHRlY2huaXF1ZXMuIEFuZCBpZiB0aGUgZXF1aXBt ZW50IHN0YXJ0cyANCiAgICBtZXNzaW5nIHVwIHRoZSByZXBvcnRpbmcgb2YgbG9zcyBvZiBDQyBi ZWNhdXNlIGl0IHdhaXRpbmcgZm9yL3BlcnNpc3RlbmNlIA0KICAgIGNoZWNraW5nJm5ic3A7QUlT L0ZESSwgaXQgY291bGQgZW5kIHVwIG1lc3NpbmcgdXAgc2ltcGxlIHRpbWUtc3RhbXAgDQogICAg Y29ycmVsYXRpb24hJm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIg YWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1Bcmlh bCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K ICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAw OT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkluIHByYWN0aWNl LCBpdCBpcyBvZnRlbiBub3QgcXVpdGUgYSBzaW1wbGUgYXMgdGhpcywgYXMgDQogICAgdGhlIHNl cnZpY2UgZ3V5cyBsaWtlIHRvIGJlIGFibGUgdG8gJ2xvY2FsaXNlJyB0aGUgZmF1bHQuIEhvd2V2 ZXIsIHVuZGVyIA0KICAgIG1vc3QgY2lyY3Vtc3RhbmNlcywmbmJzcDt0aGUgZmlsdGVyIGhhcyBh dXRvbWF0aWNhbGx5IGRvbmUgdGhpcy4gDQogICAgU28mbmJzcDtsb2NhbGlzYXRpb24mbmJzcDt5 b3UgZGVzY3JpYmUgaXMgb25seSB3aGVuIHRoZSBmaWx0ZXIgaGFzbid0IHdvcmtlZCANCiAgICBm b3Igc29tZSByZWFzb24uPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PC9TUEFOPiZuYnNwOzwvRElW Pg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0 MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkJ1dCB0aGUg Ym90dG9tIGxpbmUgaXMsIHdoYXRldmVyIG9wZXJhdGlvbnMgcHJvY2VzcyB5b3UgDQogICAgd2Fu dCB0byB1c2UsJm5ic3A7QUlTL0ZESSBkb2Vzbid0IGFkZCBhbnl0aGluZyBvdGhlciB0aGFuIGNv bXBsZXhpdHkgYW5kIA0KICAgIGZhdWx0IGxpYWJpbGl0eSB0byB0aGUgZXF1aXBtZW50LiBSZW1l bWJlciZuYnNwO0FJUyBnb2VzIGJhY2sgdG8gdGhlIFRETSANCiAgICB3b3JsZCB3aGVyZSB5b3Ug KmhhdmUgdG8gZmlsbCB0aGUgYml0IHN0cmVhbSB3aXRoIA0KICAgIHNvbWV0aGluZyouPC9GT05U PjwvU1BBTj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0x NjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAg IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJ ViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05U IGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJz cDs8L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIz MDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5B bmR5PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4 dC9ydGYgZm9ybWF0IC0tPg0KICAgIDxQPjxCPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jODA4MDgwIHNpemU9Mj5BbmR5IA0KICAgIFJlaWQ8L0ZPTlQ+PC9TUEFOPjwv Qj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Q2hpZWYgDQog ICAgTmV0d29yayBTZXJ2aWNlcyBTdHJhdGVnaXN0PC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIGxh bmc9ZW4tdXM+PEZPTlQgDQogICAgZmFjZT1BcmlhbCBzaXplPTI+QlQgSW5ub3ZhdGU8L0ZPTlQ+ PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1lbi11cz48VT48Rk9OVCANCiAgICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIA0KICAgIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+ PC9VPjwvU1BBTj4gDQogICAgPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+T2ZmaWNlOiArNDQgKDApMTI3NyANCiAgICAzMjIwMzg8L0ZPTlQ+PC9TUEFOPiA8QlI+ PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Nb2JpbGU6IA0KICAgICs0 NCAoMCk3OTE3IDAyNTQ1MTwvRk9OVD48L1NQQU4+IDxCUj48U1BBTiBsYW5nPWVuLWdiPjxGT05U IGZhY2U9QXJpYWwgDQogICAgc2l6ZT0yPkZheCZuYnNwOzombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKzQ0ICgwKTEyNzcgDQogICAgMzI0MDE1PC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgDQogICAgZmFj ZT1BcmlhbCBzaXplPTI+RW1haWw6Jm5ic3A7IGFuZHkuYmQucmVpZEBidC5jb208L0ZPTlQ+PC9T UEFOPiA8L1A+DQogICAgPFA+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSM4MDgwODAgDQogICAgc2l6ZT0xPjwvRk9OVD48L1NQQU4+PEJSPjxTUEFOIGxhbmc9ZW4tZ2I+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jODA4MDgwIA0KICAgIHNpemU9MT5Ccml0aXNoIFRlbGVj b21tdW5pY2F0aW9ucyBwbGM8QlI+UmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgDQogICAg U3RyZWV0IExvbmRvbiBFQzFBIDdBSjxCUj5SZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm8uIDE4MDAw MDA8L0ZPTlQ+IA0KICAgIDwvU1BBTj48QlI+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSM4MDgwODAgc2l6ZT0xPlRoaXMgDQogICAgZWxlY3Ryb25pYyBtZXNzYWdlIGNv bnRhaW5zIGluZm9ybWF0aW9uIGZyb20gQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjIA0K ICAgIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0 aW9uIGlzIGludGVuZGVkIHRvIGJlIA0KICAgIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs KHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIA0KICAgIGludGVu ZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0 cmlidXRpb24gb3IgDQogICAgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9u IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KICAgIHRoaXMgZWxlY3Ryb25p YyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHRlbGVwaG9uZSBvciBlbWFp bCAodG8gDQogICAgdGhlIG51bWJlcnMgb3IgYWRkcmVzcyBhYm92ZSkgaW1tZWRpYXRlbHkuPC9G T05UPjwvU1BBTj48L1A+DQogICAgPFA+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSM4MDgwODAgc2l6ZT0xPkFjdGl2aXR5IGFuZCB1c2UgDQogICAgb2YgdGhlIEJyaXRp c2ggVGVsZWNvbW11bmljYXRpb25zIHBsYyBlbWFpbCBzeXN0ZW0gaXMgbW9uaXRvcmVkIHRvIHNl Y3VyZSANCiAgICBpdHMgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBi dXNpbmVzcyBwdXJwb3Nlcy4gDQogICAgQ29tbXVuaWNhdGlvbnMgdXNpbmcgdGhpcyBzeXN0ZW0g d2lsbCBhbHNvIGJlIG1vbml0b3JlZCBhbmQgbWF5IGJlIHJlY29yZGVkIA0KICAgIHRvIHNlY3Vy ZSBlZmZlY3RpdmUgb3BlcmF0aW9uIGFuZCBmb3Igb3RoZXIgbGF3ZnVsIGJ1c2luZXNzIA0KICAg IHB1cnBvc2VzLjwvRk9OVD48L1NQQU4+PC9QPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+PEJSPg0K ICAgIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogICAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBN QVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1S SUdIVDogMHB4Ij4NCiAgICAgIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1l bi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQogICAgICA8SFIgdGFiSW5kZXg9LTE+DQogICAgICA8 Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZyANCiAgICAgIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhh bGYgT2YgDQogICAgICA8L0I+bGl1Lmd1b21hbkB6dGUuY29tLmNuPEJSPjxCPlNlbnQ6PC9CPiAy MiBBcHJpbCAyMDA5IA0KICAgICAgMDk6MTU8QlI+PEI+VG86PC9CPiBIYXJyaXNvbixOLE5laWws Q1hNIFI8QlI+PEI+Q2M6PC9CPiANCiAgICAgIG1wbHMtdHBAaWV0Zi5vcmc8QlI+PEI+U3ViamVj dDo8L0I+IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIA0KICAgICAgdHJh bnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogICAgICA8RElW PjwvRElWPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0zPk5laWw6PC9GT05UPiA8QlI+ PEZPTlQgDQogICAgICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0zPiZuYnNwOyB0aGFuayB5b3UgZm9y IHdhc3RpbmcgbW9yZSB0aW1lIGluIA0KICAgICAgZGVzY3JpYmxpbmcgdGhlIHByb2JsZW1zLiBi dXQgSSB0aGluayBzb21lIG9mIHdoYXQgeW91IHNhaWQgaXMgbm8gDQogICAgICByZWxhdGlvbnMg d2l0aCBvdXIgcHJvYmxlbS5mb3IgbWUsIG1heWJlIEFJUy9GREkgZnVuY3Rpb25zIGlzIG5vIHNl bnNlIGluIA0KICAgICAgY2wtcHMgLGVnLiBJUC4gYnV0IGZvciBDTy1QUyBuZXR3b3Jrcy5pZiB0 aGVyZSBpcyBubyBBSVMvRkRJIGZ1bmN0aW9ucywgDQogICAgICB3aGVuIHRoZXJlIGlzIGEgZGVm ZWN0cyBpbiBhIGdpdmVuIGxheWVyIG5ldHdvcmssIGl0IGNhbiBjYXVzZSBtdWx0aXBsZSANCiAg ICAgIGFsYXJtIGV2ZW50cyB0byBiZSByYWlzZWQuIGl0IGlzIGRpZmZjdWx0ICZuYnNwO2ZvciBv cGVyYXRvcnMgdG8gbG9jYXRlIA0KICAgICAgYW5kIGRpYWdub3NlIHRoZSBmYXVsdHMuPC9GT05U PiA8QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgc2l6ZT0zPiZuYnNwO3Rob3VnaCBJ IGNvbXBsZXRlbHkgYWdyZWUgeW91IG9uICZuYnNwO2FkZGluZyBuZXcgdGhpbmdzIGFuZCANCiAg ICAgIGZ1bmN0aW9ucyB3aWxsIGJyaW5nIHNvbWUgY29tcGxleGl0eSAuIGJ1dCBpZiB3ZSBoYXZl IG5vIGZ1bmN0aW9ucywgaXQgaXMgDQogICAgICBtb3JlIGNvbXBsZXggYW5kIGRpZmN1bHQgZm9y IG9wZXJhdG9ycyB0byBtYWludGVuY2UgYW5kIGFkbWluaXN0cmF0b3IgdGhlIA0KICAgICAgbmV0 d29yay4gc28gSSB0aGluayBldmVyeSBuZXcgZnVuY3Rpb25zIGFuZCB0aGluZ3MgbWF5IGhhdmUg cG9zaXRpdmUgYW5kIA0KICAgICAgbmVnYXRpdmUgZWZmZWN0cy4gYnV0IHdlIHNob3VsZCBjb25z aWRlciBpdCB2ZXJ5IG11Y2gsIGRvbid0IGRlbGV0ZSBzb21lIA0KICAgICAgZnVuY3Rpb25zIGF0 IHJhbmRvbS48L0ZPTlQ+IDxCUj48QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTM+ YmVzdCANCiAgICAgIHJlZ2FyZHM8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0zPmxpdTwvRk9OVD4gPEJSPjxCUj48QlI+DQogICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0K ICAgICAgICA8VEJPRFk+DQogICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgIDxURCB3 aWR0aD0iMjYlIj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQogICAgICAgICAgICBzaXplPTE+PEI+ Jmx0O25laWwuMi5oYXJyaXNvbkBidC5jb20mZ3Q7PC9CPiA8L0ZPTlQ+DQogICAgICAgICAgICA8 UD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPjIwMDktMDQtMjEgMjA6MzA8L0ZPTlQ+IDwv UD4NCiAgICAgICAgICA8VEQgd2lkdGg9IjczJSI+DQogICAgICAgICAgICA8VEFCTEUgd2lkdGg9 IjEwMCUiPg0KICAgICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUiB2QWxpZ249 dG9wPg0KICAgICAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249 cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7mlLbku7bkuro8L0ZPTlQ+PC9ESVY+ DQogICAgICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCiAgICAgICAgICAg ICAgICAgIHNpemU9MT4mbHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0OywgDQogICAgICAgICAg ICAgICAgICAmbHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9GT05UPiANCiAgICAgICAgICAgICAg PFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICAgICAg PERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuaKhOmAgTwvRk9O VD48L0RJVj4NCiAgICAgICAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAg ICAgICAgICAgICAgICAgc2l6ZT0xPiZsdDttcGxzLXRwQGlldGYub3JnJmd0OzwvRk9OVD4gDQog ICAgICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgICAgIDxURD4NCiAgICAg ICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9 MT7kuLvpopg8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTE+UkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIA0KICAgICAgICAgICAgICAg ICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCiAgICAgICAgICAgIHJlcXVpcmVtZW50 czwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj4NCiAgICAgICAgICAgIDxUQUJM RT4NCiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFIgdkFsaWduPXRvcD4N CiAgICAgICAgICAgICAgICA8VEQ+DQogICAgICAgICAgICAgICAgPFREPjwvVEQ+PC9UUj48L1RC T0RZPjwvVEFCTEU+PEJSPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjxCUj48QlI+PEZP TlQgDQogICAgICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5MaXUs PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQg ZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgICAgIHNpemU9Mj5JZiBNUExT LVRQIGlzIGdvaW5nIHRvIGJlIHRha2VuIHNlcmlvdXNseSBhcyBhIHRyYW5zcG9ydCBuZXR3b3Jr IA0KICAgICAgKGxpa2UgU0RIL1NPTkVUKSB0aGVuIHRoZSAyIGtleSBNVVNUIEhBVkUgcmVxdWly ZW1lbnRzIGFyZSB0aGVzZS48L0ZPTlQ+IA0KICAgICAgPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8 L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgICAgIGNvbG9yPSM4MDAw MDAgc2l6ZT0yPjEgJm5ic3A7ICZuYnNwO1Byb3ZpZGUgYSB0cmFuc3BhcmVudCBjbGllbnQvc2Vy dmVyIA0KICAgICAgcmVsYXRpb25zaGlwLi4ud2hpY2ggbWVhbnM6PC9GT05UPiA8QlI+PEZPTlQg ZmFjZT0iQ29taWMgU2FucyBNUyIgDQogICAgICBjb2xvcj0jODAwMDAwIHNpemU9Mj4tICZuYnNw OyAmbmJzcDthbGwgY2xpZW50IGJpdHMgdHJlYXRlZCBlcXVhbGx5PC9GT05UPiANCiAgICAgIDxC Uj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj4tICZuYnNw OyAmbmJzcDtjbGllbnQgDQogICAgICBiaXQgb3JkZXJpbmcgcHJlc2VydmVkPC9GT05UPiA8QlI+ PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgICAgIHNpemU9Mj4t ICZuYnNwOyAmbmJzcDtubyBhdHRlbXB0IHRvIGluZmVyIGNsaWVudCBzeW1ib2wgKGllIHNlcXVl bmNlIG9mIA0KICAgICAgY2xpZW50IGJpdHMpIG1lYW5pbmcgYW5kIG5vIGF0dGVtcHQgdG8gY2hh bmdlIGNsaWVudCBzeW1ib2xzPC9GT05UPiANCiAgICAgIDxCUj48Rk9OVCBmYWNlPSJDb21pYyBT YW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj4tICZuYnNwOyAmbmJzcDt0aGUgDQogICAgICB0 cmFmZmljIGJlaGF2aW91ciBvZiBjbGllbnQgWCBtdXN0IG5vdCBpbXBhY3QgdGhlIHBlcmZvcm1h bmNlIGV4cGVyaWVuY2VkIA0KICAgICAgYnkgY2xpZW50IFk8L0ZPTlQ+IDxCUj48Rk9OVCBzaXpl PTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICBmYWNlPSJDb21pYyBTYW5zIE1TIiBj b2xvcj0jODAwMDAwIHNpemU9Mj5BIGtleSBjb3JvbGxhcnkgb2YgdGhlIGFib3ZlIGlzIA0KICAg ICAgdGhhdCBNUExTLVRQIG11c3Qgb25seSBzdXBwb3J0IHByb3BlciBjb25uZWN0aW9ucyAoaWUg c2luZ2xlIHNvdXJjZSANCiAgICAgIGNvbnN0cnVjdHMpPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0z PiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIA0KICAgICAgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJS PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjIgDQogICAg ICAmbmJzcDsgU2luY2UgTVBMUy1UUCBpcyBhIHRyYW5zcG9ydCBuZXR3b3JrIGl0IGlzIG5vdCBh IHRvcC1vZi1zdGFjayANCiAgICAgIG5ldHdvcmsgKGllIGl0IGRvZXMgbm90IHN1cHBvcnQgZGly ZWN0bHkgZXh0ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSANCiAgICAgIGFwcGxpY2F0aW9ucyku ICZuYnNwO01QTFMtVFAgdGhlcmVmb3JlIGRvZXMgbm90IHJlcXVpcmUgYW4gRS1OTkkgDQogICAg ICBzcGVjaWZpY2F0aW9uLiAmbmJzcDtBIGtleSBjb3JvbGxhcnkgb2YgdGhpcyBpcyB0aGF0IE1Q TFMtVFAgd2lsbCBub3QgaGF2ZSANCiAgICAgIGFueSBwZWVyIGludGVyd29ya2luZyByZWxhdGlv bnNoaXAgd2l0aCBhbnkgb3RoZXIgbmV0d29yayANCiAgICAgIG1vZGUvdGVjaG5vbG9neS48L0ZP TlQ+IDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICBzaXpl PTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9Izgw MDAwMCANCiAgICAgIHNpemU9Mj5Ob3cgd3J0IE9BTSBNUExTLVRQIGlzIGEgY28tcHMgbW9kZSBu ZXR3b3JrLiAmbmJzcDtZb3UgY291bGQgYXJndWUgDQogICAgICB0aGlzIHNob3VsZCBoYXZlIEZE SS9BSVMuLi4uaG93ZXZlciwgdGhlIG1lcml0IG9mIHRoaXMgaXMgaGlnaGx5IA0KICAgICAgcXVl c3Rpb25hYmxlLiAmbmJzcDtXaGVuIEkgYW5kIGNvbGxlYWd1ZXMgZGlzY3Vzc2VkIHdoZXRoZXIg UEJCLVRFIChhbHNvIGEgDQogICAgICBjby1wcyBtb2RlIG5ldHdvcmspIHNob3VsZCBoYXZlIEZE SS9BSVMgd2UgY29uY2x1ZGVkIHRoYXQgb24gYmFsYW5jZSBpdCANCiAgICAgIHdhcyBub3QgYSBn b29kIGlkZWEuLi4uLmFuZCBub3RlIHRoYXQgaW5pdGlhbGx5IEkgd2FzIGluIGZhdm91ciBvZiBo YXZpbmcgDQogICAgICBBSVMsIGJ1dCBteSBjb2xsZWFndWVzIHByb3ZpZGVkIHN0cm9uZyB0ZWNo bmljYWwgYXJndW1lbnRzIHRoYXQgY29udmluY2VkIA0KICAgICAgbWUgb3RoZXJ3aXNlLjwvRk9O VD4gPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgIGZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPkFJUy9GREkgaXMgaGlzdG9yaWNh bGx5IGxpbmtlZCANCiAgICAgIHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXllciBuZXR3 b3JrcyB0aGF0IHVzZWQgVFRMIGxvZ2ljLiAmbmJzcDtXaGVuIA0KICAgICAgdGhpcyBkaWVkIGl0 IHB1dCBvdXQgYSArNVYgKGFsbCAxcykgc2lnbmFsIGJ5IGRlZmF1bHQsIGllIGl0IHJlcXVpcmVk IG5vIA0KICAgICAgY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0ZSBpdC4uLi4udGhpcyBpcyBr ZXkgcG9pbnQuICZuYnNwO0Z1cnRoZXIsIGluIA0KICAgICAgdGhlc2UgbmV0d29ya3MgdGhlcmUg aXMgYSBmYWlybHkgc3RhdGljL2xvbmctaG9sZGluZyBjbGllbnQgc2VydmVyIA0KICAgICAgcmVs YXRpb25zaGlwLiAmbmJzcDtDbGVhcmx5IHRoaXMgaXMgbm90IHRydWUgaW4gdGhlIGNsLXBzIG1v ZGUgYW5kIGl0J3MgDQogICAgICB3aHkgSUVURiBoYXZlIG5ldmVyIHNwZWNpZmllZCBBSVMgZm9y IElQIGFuZCBpdHMgd2h5IElFRUUgaGFkIHRoZSBnb29kIA0KICAgICAgc2Vuc2UgdG8gdGhyb3ct b3V0IEFJUyBpbiA4MDIuMWFnIGZvciBFdGhlcm5ldCAodGhvdWdoIElUVSBoYXZlIHVud2lzZWx5 IA0KICAgICAgSU1PIHJldGFpbmVkIGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0IGFueSBv cGVyYXRvciBwbGFubmluZyB0byB1c2UgDQogICAgICBFdGhlcm5ldCBlcXVpcG1lbnQgd291bGQg YWx3YXlzIGxvb2sgdG8gSUVFRSBzdGRzIGFuZCBub3QgSVRVIA0KICAgICAgb25lcykuPC9GT05U PiA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIA0KICAgICAgZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+QUlTL0ZESSBhbmQgdGhlIGNvLXBz IG1vZGUgaXMgDQogICAgICBkZWJhdGFibGUuICZuYnNwO0FzIEkgbm90ZWQgYWJvdmUsIG9uIGJh bGFuY2Ugd2UgY29uc2lkZXJlZCBub3QgYSBnb29kIA0KICAgICAgaWRlYSBmb3IgUEJCLVRFIE9B TSBiZWNhdXNlIGl0IHJlcXVpcmVzIGEgY29uc2Npb3VzIGVmZm9ydCB0byBnZW5lcmF0ZSBpdCAN CiAgICAgICh1bmxpa2UgdGhlIGNvLWNzIG1vZGUpIHNvIHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUg c2NhbGluZyBwcm9ibGVtcyBhbmQgaXRzIA0KICAgICAgb25lIG1vcmUgdGhpbmcgdG8gZ28gd3Jv bmcuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gDQogICAgICA8QlI+PEZP TlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+WW91IHNob3VsZCBh bHNvIGhhdmUgDQogICAgICBzZWVuIG1lIG1ha2UgdGhlIHBvaW50IG1hbnkgdGltZXMgaW4gdGhl IHBhc3QgdGhhdCB0aGUgYWx3YXlzLW9uIGRlZmVjdCANCiAgICAgIGRldGVjdGlvbi9oYW5kbGlu ZyBPQU0gbmVlZHMgdG8gYmUgYXMgc2ltcGxlL3NwYXJzZSBhcyBwb3NzaWJsZSB3aXRoIGFzIA0K ICAgICAgbGl0dGxlIGNvbmZpZyBhcyBwb3NzaWJsZSBiZWNhdXNlIHdlIG5lZWQgc3VwZXIgcmVs aWFiaWxpdHkuLi4uLi5UQ00gZ29lcyANCiAgICAgIGNvbXBsZXRlbHkgYWdhaW5zdCB0aGUgZ3Jh aW4gaGVyZS4gJm5ic3A7QWxzbyBub3RlIHRoYXQgdGhlIE9BTSByZXF1aXJlZCANCiAgICAgIGZv ciBlYWNoIG9mIHRoZSAzIG5ldHdvcmsgbW9kZXMgaXMgbm90IHRoZSBzYW1lLCBkZXNwaXRlIHdo YXQgc29tZSANCiAgICAgIGNsYWltLjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZP TlQ+IDxCUj48Rk9OVCANCiAgICAgIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAg c2l6ZT0yPnJlZ2FyZHMsIE5laWw8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgIHNpemU9Mz4mbmJz cDs8L0ZPTlQ+IDxCUj48QlI+DQogICAgICA8SFI+DQogICAgICA8Rk9OVCBmYWNlPVRhaG9tYSBz aXplPTI+PEI+RnJvbTo8L0I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgICAgIFttYWls dG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgDQogICAgICA8L0I+ bGl1Lmd1b21hbkB6dGUuY29tLmNuPEI+PEJSPlNlbnQ6PC9CPiAyMSBBcHJpbCAyMDA5IA0KICAg ICAgMDI6NTk8Qj48QlI+VG86PC9CPiBCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTPEI+PEJS PkNjOjwvQj4gDQogICAgICBtcGxzLXRwQGlldGYub3JnPEI+PEJSPlN1YmplY3Q6PC9CPiBSZTog W21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCANCiAgICAgIHRyYW5zcG9ydCBwYXRo IHJlcXVpcmVtZW50czwvRk9OVD48Rk9OVCBzaXplPTM+PEJSPjwvRk9OVD48QlI+PEZPTlQgDQog ICAgICBzaXplPTI+PFRUPjxCUj5EZWJvcmFoPC9UVD48L0ZPTlQ+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIA0KICAgICAgc2l6ZT0yPjo8L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9Mj48QlI+bWF5YmUgDQogICAgICB3aGF0IHlvdSBzYWlkIGlzIHJp Z2h0LiBidXQgSSBjYW4ndCBjb21wbGV0ZWx5IGFncmVlIHlvdXIgb3BpbmlvbnMuIElNTy4gDQog ICAgICBtcGxzLXRwIGlzIHJlZ2FyZCBhcyB0cmFuc3BvcnQgbmV0d29yayBsaWtlIFNESC9TT05F VC4gc28gaXQgc2hvdWxkIGhhdmUgDQogICAgICBBSVMvRkRJIGZ1Y3Rpb25zIGFzIFNESC9TT05F VC48L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8QlI+PC9GT05UPjxGT05UIA0KICAgICAgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj48QlI+ZG8geW91IHRoaW5rIHNvLjwvRk9OVD48Rk9OVCBzaXplPTM+IA0K ICAgICAgPEJSPjwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5iZXN0IHJl Z2FyZHM8L0ZPTlQ+PEZPTlQgDQogICAgICBzaXplPTM+IDwvRk9OVD48Rk9OVCBmYWNlPXNhbnMt c2VyaWYgc2l6ZT0yPjxCUj5saXUgPC9GT05UPjxGT05UIA0KICAgICAgc2l6ZT0zPjxCUj48QlI+ PC9GT05UPg0KICAgICAgPFRBQkxFIHdpZHRoPSIxMDAlIj4NCiAgICAgICAgPFRCT0RZPg0KICAg ICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICA8VEQgd2lkdGg9IjQyJSI+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9MT48Qj4iQlJVTkdBUkQsIERFQk9SQUggDQogICAgICAgICAgICBB LCBBVFRMQUJTIiAmbHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9CPiA8QlI+5Y+R5Lu25Lq6OiAN CiAgICAgICAgICAgICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzwvRk9OVD48Rk9OVCBz aXplPTM+IDwvRk9OVD4NCiAgICAgICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTE+MjAwOS0wNC0yMCAyMzo0NzwvRk9OVD48Rk9OVCBzaXplPTM+IA0KICAgICAgICAgICAgPC9G T05UPjwvUD4NCiAgICAgICAgICA8VEQgd2lkdGg9IjU3JSI+PEJSPg0KICAgICAgICAgICAgPFRB QkxFIHdpZHRoPSIxMDAlIj4NCiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8 VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICAgICAgICA8VEQgd2lkdGg9IjclIj4NCiAgICAgICAg ICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7m lLbku7bkuro8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI5MiUiPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+Ik1hYXJ0ZW4gVmlzc2VycyIgDQogICAgICAgICAg ICAgICAgICAmbHQ7bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20mZ3Q7LCANCiAgICAgICAgICAg ICAgICAgICZsdDtuZWlsLjIuaGFycmlzb25AYnQuY29tJmd0OzwvRk9OVD48Rk9OVCBzaXplPTM+ IDwvRk9OVD4NCiAgICAgICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgICAgICAg PFREPg0KICAgICAgICAgICAgICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMt c2VyaWYgc2l6ZT0xPuaKhOmAgTwvRk9OVD48L0RJVj4NCiAgICAgICAgICAgICAgICA8VEQ+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT5tcGxzLXRwQGlldGYub3JnPC9GT05UPjxGT05UIA0K ICAgICAgICAgICAgICAgICAgc2l6ZT0zPiA8L0ZPTlQ+DQogICAgICAgICAgICAgIDxUUiB2QWxp Z249dG9wPg0KICAgICAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgICAgIDxESVYgYWxp Z249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7kuLvpopg8L0ZPTlQ+PC9ESVY+ DQogICAgICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+UmU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIA0KICAgICAgICAgICAgICAgICAgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCANCiAgICAgICAgICAgIHJlcXVpcmVtZW50czwvRk9OVD48L1REPjwvVFI+PC9U Qk9EWT48L1RBQkxFPjxCUj48QlI+DQogICAgICAgICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0K ICAgICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAg ICAgICAgICAgICAgIDxURCB3aWR0aD0iNTAlIj4NCiAgICAgICAgICAgICAgICA8VEQgDQogICAg ICB3aWR0aD0iNTAlIj48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48L1REPjwvVFI+PC9U Qk9EWT48L1RBQkxFPjxCUj48Rk9OVCANCiAgICAgIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48Rk9O VCBzaXplPTI+PFRUPjxCUj5JIGFncmVlIHdpdGggTmVpbCwgaXQgaXMgdmVyeSANCiAgICAgIHF1 ZXN0aW9uYWJsZSB0aGUgdmFsdWUgb2YgQUlTL0ZESSBpbiBhPEJSPnBhY2tldCBuZXR3b3JrLSBh bnkgbW9kZS4gSXQgY2FuIA0KICAgICAgcmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBhbiBvcGVy YXRvcjxCUj5vbiB0aGVtc2VsdmVzIHNvIGV2ZW4gWTE3MzEgDQogICAgICByZWNvbW1lbmRzIG5v dCB0byBibG9jayBkYXRhIGZyYW1lczo8QlI+IkEgTUVQIGNhbiBkZWNpZGUgd2hldGhlciBpdCAN CiAgICAgIGJsb2NrcyBkYXRhIGZyYW1lcyB3aGVuIGl0IGRldGVjdHMgZEFJUy48QlI+VGhlIHBy aW5jaXBsZSANCiAgICAgIHJlcXVpcmVtZW50PEJSPnRoYXQgaW5mbHVlbmNlcyB0aGlzIGRlY2lz aW9uIGlzIHRoYXQgZGF0YSBmcmFtZXMgb3VnaHQgdG8gDQogICAgICBiZSBmb3J3YXJkZWQ8QlI+ YXMgbXVjaCBhcyBwb3NzaWJsZSwgd2l0aG91dDxCUj50aGUgcG9zc2liaWxpdHkgb2YgDQogICAg ICBmb3J3YXJkaW5nIHdyb25nIGRhdGEgZnJhbWVzIGRvd25zdHJlYW0uIjxCUj5UYWJsZSBJLjct MiBzaG93cyBmb3IgQUlTLCANCiAgICAgIG5vdCB0byBibG9jay48QlI+PEJSPkFuZCBhcyBZMTcz MSBzdGF0ZXMsIEFJUyBjYW4gb25seSBiZSB1c2VkIHVuZGVyIHZlcnkgDQogICAgICBjb25zdHJh aW5lZDxCUj5hcmNoaXRlY3R1cmVzIC0gaWYgcmVxdWlyZWQgZm9yIE1QTFMtVFAsIGl0IG5lZWRz IHRvIGhhdmUgDQogICAgICB0aGUgc2FtZTxCUj5ndWlkYW5jZSBhcyBpbiBZMTczMSwgaS5lLiBw b2ludC10by1wb2ludCBhbmQgc2VydmVyL2NsaWVudCANCiAgICAgIG9uZS10by1vbmU6PEJSPiJm b3IgYSBwb2ludC10by1wb2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSANCiAg ICAgIHNpbmdsZSBwZWVyIE1FUC48QlI+VGhlcmVmb3JlLCB0aGVyZTxCUj5pcyBubyBhbWJpZ3Vp dHkgcmVnYXJkaW5nIHRoZSBwZWVyIA0KICAgICAgTUVQIGZvciB3aGljaCBpdCBzaG91bGQgc3Vw cHJlc3M8QlI+YWxhcm1zIHdoZW4gaXQgcmVjZWl2ZXMgdGhlPEJSPkVUSC1BSVMgDQogICAgICBp bmZvcm1hdGlvbi4iPEJSPlNvIHNob3VsZCBvbmx5IGJlIHdpdGhpbiBvbmUgZG9tYWluIC0gdGhl biBubyANCiAgICAgIG5lZWQuPEJSPjxCUj5EZWJvcmFoPEJSPjxCUj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxCUj5Gcm9tOiANCiAgICAgIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT248QlI+QmVoYWxmIE9mIA0KICAgICAgTWFh cnRlbiBWaXNzZXJzPEJSPlNlbnQ6IE1vbmRheSwgQXByaWwgMjAsIDIwMDkgMTA6MDUgQU08QlI+ VG86IA0KICAgICAgbmVpbC4yLmhhcnJpc29uQGJ0LmNvbTxCUj5DYzogbXBscy10cEBpZXRmLm9y ZzxCUj5TdWJqZWN0OiBSZTogW21wbHMtdHBdIA0KICAgICAgQXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCANCiAgICAgIHBhdGg8QlI+cmVxdWlyZW1lbnRzPEJSPjxCUj5OZWlsLDxC Uj48QlI+Jmd0OyBidXQgQUlTL0ZESSBpbiB0aGUgY2wgDQogICAgICBtb2RlPy4uLmRvIG1lIGEg ZmF2b3VyITxCUj48QlI+RXRoZXJuZXQgQUlTIGlzIGluZGVlZCBhIHJlcXVpcmVtZW50IGFuZCBh IA0KICAgICAgbmVjZXNzaXR5LiBBbmQgeW91IHdpbGwgbm90PEJSPmJlPEJSPmFibGUgdG8gdW5k ZXJzdGFuZCB0aGF0IGFzIGxvbmcgYXMgDQogICAgICB5b3UgcmVmdXNlIHRvIGFjY2VwdCB0aGF0 ICJjbC1tb2RlIjxCUj5pcyBhPEJSPmZvcndhcmRpbmcgbW9kZSB3aXRoaW4gYSANCiAgICAgICoq dHJhbnNwb3J0IGVudGl0eSoqLiBHLjgwMCBhbWVuZG1lbnQgMSBoYXM8QlI+ZmluYWxseTxCUj5y ZWludHJvZHVjZWQgDQogICAgICB0aGlzIHRyYW5zcG9ydCBlbnRpdHkgaW50byBHLjgwMC4gQmVz aWRlcyB0aGF0LCBpdCBhbHNvPEJSPmludHJvZHVjZWQgdGhlIA0KICAgICAgKipkaWZmZXJlbnRp YXRlZCBjb25uZWN0aW9uKio6PEJSPjxCUj5bRy44MDAgYW0xXSAiQSBkaWZmZXJlbnRpYXRlZCAN CiAgICAgIGNvbm5lY3Rpb24gaXMgYSB0cmFuc3BvcnQgZW50aXR5IHRoYXQ8QlI+dHJhbnNmZXJz IGluZm9ybWF0aW9uIGJlbG9uZ2luZyANCiAgICAgIHRvIG11bHRpcGxlIGNvbW11bmljYXRpb25z IGJldHdlZW4gcG9ydHM8QlI+YWNyb3NzIGEgc3VibmV0d29yay4gDQogICAgICAmbHQ7Li4mZ3Q7 IEluIGEgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBtZXNzYWdlPEJSPmNvbnRlbnRzPEJSPmFy ZSANCiAgICAgIGludGVycHJldGVkIHRvIGlkZW50aWZ5IChzZXRzIG9mKSBjb21tdW5pY2F0aW9u cyB3aGljaCANCiAgICAgIHJlY2VpdmU8QlI+ZGlmZmVyZW50PEJSPnRyZWF0bWVudC4gJm5ic3A7 VGhlIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5IGJlIA0KICAgICAgZGlzdGluZ3Vpc2hlZCBi eSB0aGU8QlI+Zm9yd2FyZGluZyBpZGVudGlmaWVyIG9yIG90aGVyIGxheWVyIGluZm9ybWF0aW9u LiANCiAgICAgICZuYnNwO09yZGVyIGlzIG5vdDxCUj5uZWNlc3NhcmlseTxCUj5wcmVzZXJ2ZWQg YmV0d2VlbiBtZXNzYWdlcyBiZWxvbmdpbmcgDQogICAgICB0byBzZXRzIG9mIGNvbW11bmljYXRp b25zIHJlY2VpdmluZzxCUj5kaWZmZXJlbnQgdHJlYXRtZW50LiAmbmJzcDtTZXRzIG9mIA0KICAg ICAgY29tbXVuaWNhdGlvbnMgbWF5IGJlIGlkZW50aWZpZWQgZm9yPEJSPnB1cnBvc2VzPEJSPnN1 Y2ggYXMgdHJhZmZpYyANCiAgICAgIGNvbmRpdGlvbmluZyBvciBwcmVzZXJ2aW5nIGNvbW11bmlj YXRpb24gbWVzc2FnZSANCiAgICAgIG9yZGVyLiI8QlI+PEJSPjxCUj5FdGhlcm5ldCBWTEFOcyBh cmUgaW4gdGVybXMgb2YgRy44MDAgImRpZmZlcmVudGlhdGVkIA0KICAgICAgY29ubmVjdGlvbnMi LjxCUj5FdGhlcm5ldDxCUj5BSVMgcHJvdmlkZXMgQUlTIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc3Vj aCANCiAgICAgICJkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIi48QlI+SWY8QlI+eW91IGFwcGx5 IHRoaXMgdG8gbXkgcHJvcG9zZWQgUFROIA0KICAgICAgbGF5ZXIgc3RhY2ssIHRoZW4gdGhlIEVW QyBsYXllcjxCUj50b3BvbG9neTxCUj53aWxsIGNvbnNpc3RzIG9mIEVWQyBsaW5rcyANCiAgICAg IHN1cHBvcnRlZCBieSBNUExTLVRQLCBFdGhlcm5ldCwgUEJCLVRFIGFuZDxCUj5QLU9UTjxCUj5W UCB0cmFpbHMgaW5zaWRlIA0KICAgICAgbWV0cm8gYW5kIGNvcmUgZG9tYWlucyBpbnRlcmNvbm5l Y3RpbmcgRVZDIG1hdHJpY2VzLjxCUj5XaGVuPEJSPm9uZSBvZiANCiAgICAgIHRob3NlIEVWQyBs aW5rcyBpcyBpbnRlcnJ1cHRlZCwgZS5nLiBpbiB0aGUgY29yZSBiZXR3ZWVuIG1ldHJvIA0KICAg ICAgMTxCUj5hbmQ8QlI+bWV0cm8gNCAoc2VlIGF0dGFjaGVkIHNsaWRlKSwgdGhlbiB0aGUgRVZD IGRpZmZlcmVudGlhdGVkIA0KICAgICAgY29ubmVjdGlvbjxCUj50aGF0IGlzPEJSPnByZXNlbnQg b24gdGhpcyBsaW5rIHdpbGwgYmUgaW50ZXJydXB0ZWQuIEF0IHRoZSANCiAgICAgIEVWQyBzd2l0 Y2gvYnJpZGdlIG5vZGU8QlI+aW48QlI+bWV0cm8gNCB0aGlzIGludGVycnVwdGlvbiBpcyBub3Rp Y2VkIGFuZCANCiAgICAgIEVWQy1BSVMgaXMgaW5zZXJ0ZWQgaW4gdGhlPEJSPmRvd25zdHJlYW0g ZGlyZWN0aW9uIHRvIHN1cHByZXNzIHRoZSBFVkMtTE9DIA0KICAgICAgYWxhcm1zIGF0IEVWQyBl bmRwb2ludHMgRDQ8QlI+YW5kPEJSPkQ1LjxCUj48QlI+VGhlIEVWQy1BSVMgKGkuZS4gRXRoZXJu ZXQgDQogICAgICBBSVMpIGZyYW1lIGhhcyBhIHJlc2VydmVkIG11bHRpY2FzdCBhZGRyZXNzLDxC Uj53aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIA0KICAgICAgQUlTIGlzIGJyb2FkY2FzdCB0byB0 aGUgZW5kcG9pbnRzIG9mIHRoZSBFVkMuPEJSPjxCUj5JIGJlbGlldmUgdGhhdCBpdCBpcyANCiAg ICAgIHRpbWUgZm9yIHlvdSB0byBhZGFwdCB5b3VyIHZpZXcgb24gY28gYW5kIGNsIG1vZGVzPEJS PmFuZDxCUj5yZWxhdGUgaXQgdG8gDQogICAgICB0aGUgZm9yd2FyZGluZyBtb2RlICoqSU5TSURF KiogYSB0cmFuc3BvcnQgZW50aXR5LiA8QlI+PEJSPldoYXQgd2Uga25vdyBhcyANCiAgICAgIHRo ZSBpbnRlcm5ldCBpcyBlc3NlbnRpYWxseSBhbiAiSVAgZGlmZmVyZW50aWF0ZWQ8QlI+Y29ubmVj dGlvbiIgd2l0aCBhIA0KICAgICAgYmlsbGlvbiBvciBtb3JlIHBvcnRzLjxCUj5XaGF0IHdlIGtu b3cgYXMgYW4gSVAgVlBOIGlzIGVzc2VudGlhbGx5IGFuICJJUCANCiAgICAgIGRpZmZlcmVudGlh dGVkPEJSPmNvbm5lY3Rpb24iPEJSPndpdGggZS5nLiBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBv ZiBlLmcuIA0KICAgICAgMiB0byAxMDAwKS48QlI+V2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0 IFZMQU4gaXMgZXNzZW50aWFsbHkgYW4gDQogICAgICAiRXRoZXJuZXQ8QlI+ZGlmZmVyZW50aWF0 ZWQ8QlI+Y29ubmVjdGlvbiIgd2l0aCBuIHBvcnRzIChuIGluIHRoZSByYW5nZSBvZiANCiAgICAg IGUuZy4gMiB0byAxMDAwKS48QlI+V2hhdCB3ZSBrbm93IGFzIGEgcDJwIE1QTFMgRS1MU1AgaXMg ZXNzZW50aWFsbHkgYW4gDQogICAgICAiTVBMUyBkaWZmZXJlbnRpYXRlZDxCUj5jb25uZWN0aW9u IiB3aXRoIDIgcG9ydHMuPEJSPldoYXQgd2Uga25vdyBhcyBhIHAycCANCiAgICAgIFNESCBWQy1u IGlzIGEgIlNESCBWQy1uIGNvbm5lY3Rpb24iIHdpdGggMiBwb3J0cy48QlI+PEJSPlRyYW5zcG9y dCBuZXR3b3JrIA0KICAgICAgT0FNIGFwcGxpZXMgdG8gdHJhbnNwb3J0IGVudGl0aWVzLCB3aGlj aCBhcmUgKGluIHRlcm1zPEJSPm9mPEJSPkcuODAwIGFtMSkgDQogICAgICBjb25uZWN0aW9ucyBh bmQgZGlmZmVyZW50aWF0ZWQgDQogICAgICBjb25uZWN0aW9ucy48QlI+PEJSPlJlZ2FyZHMsPEJS Pk1hYXJ0ZW48QlI+PEJSPi0tLS0tT3JpZ2luYWwgDQogICAgICBNZXNzYWdlLS0tLS08QlI+RnJv bTogbmVpbC4yLmhhcnJpc29uQGJ0LmNvbSANCiAgICAgIFttYWlsdG86bmVpbC4yLmhhcnJpc29u QGJ0LmNvbV0gPEJSPlNlbnQ6IHZyaWpkYWcgMTcgYXByaWwgMjAwOSANCiAgICAgIDIyOjAwPEJS PlRvOiBKb2huLkUuRHJha2UyQGJvZWluZy5jb207IA0KICAgICAgSXRhbG8uQnVzaUBhbGNhdGVs LWx1Y2VudC5pdDs8QlI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IA0KICAgICAg bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb208QlI+Q2M6IG1wbHMtdHBAaWV0Zi5vcmc8QlI+U3Vi amVjdDogUkU6IA0KICAgICAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgDQogICAgICBwYXRoPEJSPnJlcXVpcmVtZW50czxCUj48QlI+Sm9obiwgJm5ic3A7VGhh bmtzIHRoaXMgaXMgYSBncmVhdCBwbGF0Zm9ybSB0byANCiAgICAgIGV4cGxhaW4gd2h5IE9BTSBm b3IgdGhlIDM8QlI+bmV0d29yazxCUj5tb2RlcyBuZWVkcyB0byBiZSBkaWZmZXJlbnQuIA0KICAg ICAgJm5ic3A7SSBhbSBnZXR0aW5nIGEgd2VlIGJpdCB0aXJlZCBvZiBmb2xrczxCUj50cnlpbmc8 QlI+dG8gbWFrZSBhbGwgMyANCiAgICAgIG5ldHdvcmsgbW9kZXMgbG9vayBhbGlrZSAoYW5kIHRo ZW4sIGV2ZW4gd29yc2UsIGludGVyd29yazxCUj50aGVtPEJSPmFzIGFzIA0KICAgICAgcGVlcnMu Li5lc3Agd2hlbiBub3Qgbm90IHRvcC1vZi1zdGFjazxCUj5uZXR3b3Jrcy4uLkkgbWVhbiBob3cg c2lsbHkgY2FuIA0KICAgICAgd2UgZ2V0PykuICZuYnNwOyBJIGFtIGV2ZW4gbW9yZSBmcnVzdHJh dGVkIGJ5PEJSPnRoZSBmYWN0IHRob3NlIHBlZGRsaW5nIA0KICAgICAgdGhpcyBGVUQgb25seSBl dmVyIHNlZW0gdG8gY29uc2lkZXIgT0FNIGFuZDxCUj5mb3JnZXQ8QlI+YWxsIG90aGVyIA0KICAg ICAgRFAvQ1AvTVAgY29tcG9uZW50cyAoZXNwIHRvcC1vZi1zdGFjayBtZXNzYWdlL2ZpbGUvc3Ry ZWFtPEJSPmFwcGxpY2F0aW9uIA0KICAgICAgYWRhcHRhdGlvbnMpLiAmbmJzcDtIb3cgd3Jvbmcg Y2FuIHRoaXMgZ2V0ISA8QlI+PEJSPkluIHRoZSBjbyBtb2RlcyBhIA0KICAgICAgKmNvbm5lY3Rp b24qIGlzIGEgdmVyeSBzcGVjaWZpYyBhbmQgKmNvbnN0cmFpbmluZyo8QlI+Y29uc3RydWN0Li4u Li5JIGFtIA0KICAgICAgYXNzdW1pbmcgaGVyZSB3ZSByZXNwZWN0IHRoZSBydWxlcyBvZiBhIGNv bm5lY3Rpb248QlI+KGllPEJSPnNpbmdsZSANCiAgICAgIHNvdXJjZSkgdGhvdWdoIHNvbWUgZm9s a3MgZG9uJ3QgZXZlbiBib3RoZXIgdG8gcmVzcGVjdCB0aGlzLCANCiAgICAgIGFuZDxCUj50aGlz PEJSPmlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBhbGwga25vdyB3aGF0IHByb2JsZW1zIA0K ICAgICAgbXVsdGlwbGUtc291cmNlPEJSPmNvbnN0cnVjdHMgY2FuIGNhdXNlIChmcm9tIExEUC9Q SFAuLi4uZXJnbyANCiAgICAgIE1QTFMtVFApLjxCUj48QlI+V2hlbiB3ZSBoYXZlIGEgY29ubmVj dGlvbiB0aGlzIHJlc3RyaWN0cyAqYWxsKiBEUCAoaWUgDQogICAgICB0cmFmZmljIGFuZCBPQU0p PEJSPnRvPEJSPnN0YXkgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIGNvbm5lY3Rpb24uIA0KICAg ICAgJm5ic3A7V2hpY2ggaXMgZmluZSB1bmRlcjxCUj5kZWZlY3QtZnJlZTxCUj5jb25kaXRpb25z LCBidXQgaWYgd2UgaGF2ZSANCiAgICAgIGxlYWtpbmcgdHJhZmZpYyB0aGVuIHRoZSBjb25zdHJh aW5pbmcgbmF0dXJlPEJSPm9mPEJSPnRoZSBjb25uZWN0aW9uIA0KICAgICAgY29uc3RydWN0IGlz IGJyb2tlbi4gJm5ic3A7SW4gYSBudXRzaGVsbCB3aGF0IHRoaXMgbWVhbnMgaXM8QlI+dGhhdDxC Uj5PQU0gDQogICAgICB0aGF0IGlzIG9mIGEgcmVxdWVzdC9yZXNwb25zZSBuYXR1cmUgY2Fubm90 IGJlIHRydXN0ZWQgaW4gY28gDQogICAgICBtb2RlPEJSPm5ldHdvcmtzIHVuZGVyIG1pc2Nvbm5l Y3Rpdml0eSBkZWZlY3RzLi4uLi5pbmRlZWQsIHdoeSBzaG91bGQgYSANCiAgICAgIGxlYWtpbmc8 QlI+RFA8QlI+aGF2ZSBhIHN5bW1ldHJpYyBnby9yZXR1cm4gZGVmZWN0IGJlaGF2aW91cj8uLi4u dmVyeSANCiAgICAgIGxpa2VseSBpdCB3b24ndC48QlI+U288QlI+d2hpbHN0IHJlcXVlc3QvcmVz cG9uc2UgT0FNIGlzIHJpZ2h0IGZvciB0aGUgY2wgDQogICAgICBtb2RlIGl0IGlzIG5vdCByaWdo dCBmb3I8QlI+dGhlPEJSPmNvIG1vZGUgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCANCiAg ICAgIGNvbmRpdGlvbnMuPEJSPjxCUj5Nb3JlIGdlbmVyYWxseSB0aGUgMyBtb2RlcyBhcmUgZGlm ZmVyZW50IGFuZCBub3QganVzdCANCiAgICAgIGluIE9BTTxCUj5yZXF1aXJlbWVudHMuLi4uYnV0 IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSANCiAgICAgIGZhdm91ciEuLi5hdCBs ZWFzdDxCUj5JRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRoZXJuZXQg DQogICAgICBldmVuIHRob3VnaCBpdCByZW1haW5zPEJSPmluPEJSPlkuMTczMS4gJm5ic3A7QW5k IHdoaWNoIGlzIHdoeSBJIG9mdGVuIA0KICAgICAgdHJvdC1vdXQgdGhlIHJhdGhlciBzaWxseSAo dG8gaGF2ZSB0bzxCUj5zYXk8QlI+dGhpcykgb2JzZXJ2YXRpb24gdGhhdCBpZiANCiAgICAgIElQ IChjbCBtb2RlKSBjb3VsZCBkbyBpdCBhbGwgdGhlbiB3aHkgaGF2ZTxCUj5JRVRGPEJSPmZvdW5k IGl0IG5lY2Vzc2FyeSANCiAgICAgIHRvIGNyZWF0ZSBNUExTIChjby1wcykgYW5kIEdNUExTIChD UCBmb3IgY28tY3MpLiAmbmJzcDtUaGU8QlI+YW5zd2VyIGxpZXMgDQogICAgICBpbiB0aGUgcGh5 c2ljcy4uLmFuZCBHLjgwMCBhdHRlbXB0cyB0byBleHBsYWluIHRoYXQ8QlI+cGh5c2ljcy4uLi5H LjgwNSANCiAgICAgIGRvZXMgbm90LjxCUj48QlI+U28sIHRoZSAzIG1vZGVzIGFyZSBkaWZmZXJl bnQuLi5wbGVhc2UgYWNjZXB0L3Jlam9pY2UgaW4gDQogICAgICB0aGlzIGZhY3QgYXM8QlI+dGhl eTxCUj5hbGwgb2ZmZXIgc29tZXRoaW5nIGRpZmZlcmVudC9pbXBvcnRhbnQuICZuYnNwO0J1dCAN CiAgICAgIGRvIG5vdCBiZSBob29kd2lua2VkIGJ5PEJSPnRob3NlPEJSPndobyBwZWRkbGUgYSBz dG9yeSB0aGF0IHRoYXQgdHJpZXMgdG8gDQogICAgICBtYWtlIHRoZSBPQU0gb2YgdGhlIDMgbW9k ZXMgdGhlPEJSPnNhbWUuIDxCUj48QlI+cmVnYXJkcywgTmVpbCANCiAgICAgIDxCUj48QlI+Jmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7IEZyb206IA0KICAgICAgbXBscy10 cC1ib3VuY2VzQGlldGYub3JnPEJSPiZndDsgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmddIE9uIA0KICAgICAgQmVoYWxmIE9mIERyYWtlLCBKb2huIEU8QlI+Jmd0OyBTZW50OiAxNyBB cHJpbCAyMDA5IDIwOjAyPEJSPiZndDsgVG86IEJVU0kgDQogICAgICBJVEFMTzsgQWxleGFuZGVy IFZhaW5zaHRlaW47IE1hYXJ0ZW4gVmlzc2VyczxCUj4mZ3Q7IENjOiANCiAgICAgIG1wbHMtdHBA aWV0Zi5vcmc8QlI+Jmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCANCiAgICAgIHRyYW5zcG9ydCBwYXRoIDxCUj4mZ3Q7IHJlcXVpcmVtZW50czxCUj4m Z3Q7IDxCUj4mZ3Q7IEl0YWxvLDxCUj4mZ3Q7IA0KICAgICAgPEJSPiZndDsgQXMgZGVzY3JpYmVk IGluIHRoZSBNUExTIFRQIE9BTSBSZXF1aXJlbWVudHMgSS1ELCB2aXJ0dWFsbHkgYWxsIA0KICAg ICAgb2YgdGhlPEJSPjxCUj4mZ3Q7IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJldHVybiBwYXRo LCBhbmQgaW4gdGhlIGFic2VuY2UgDQogICAgICBvZiBhIHJldHVybiA8QlI+Jmd0OyBwYXRoIHRo ZXkgYXJlIGRpc2FibGVkLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEFzIGRlc2NyaWJlZCANCiAgICAgIGlu IERhdmlkIFNpbmljcm9wZSdzIG1lZXRpbmcgbWludXRlcyA8QlI+Jmd0OyANCiAgICAgIChodHRw Oi8vd2lraS50b29scy5pZXRmLm9yZy9taXNjL21wbHMtaW50ZXJvcC9hdHRhY2htZW50L3dpa2kv PEJSPiZndDsgDQogICAgICBtZWV0aW5nLW5vPEJSPiZndDsgdGVzLzIwMDgxMDE1Lm1wbHMtaW50 ZXJvcC1kdC1ub3Rlcy56aXApLCBpZiBJUCANCiAgICAgIGFkZHJlc3NpbmcgaXMgdXNlZCwgYW4g PEJSPiZndDsgTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgDQogICAgICBn ZXR0aW5nIElQIHBhY2tldHMgZnJvbSA8QlI+Jmd0OyBkZXN0aW5hdGlvbiB0byBzb3VyY2U7IG5l aXRoZXIgdGhlIA0KICAgICAgbWludXRlcyBub3IgSSBzdGlwdWxhdGUgdGhhdCBhIDxCUj4mZ3Q7 IGNvbnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgdXNlZCB0byANCiAgICAgIGluc3RhbnRpYXRlIHRo aXMgZm9yd2FyZGluZy48QlI+Jmd0OyA8QlI+Jmd0OyBBcyBhbiBhc2lkZSwgdGhlIGlzc3VlIG9m IA0KICAgICAgcmV0dXJuIHBhdGggZm9yIHVuaWRpcmVjdGlvbmFsIExTUHMgY291bGQgYmU8QlI+ PEJSPiZndDsgY2hhcmF0ZXJpemVkIGFzIA0KICAgICAgdGhlIGVsZXBoYW50IGluIHRoZSByb29t LiAmbmJzcDtJbiB0aGUgTVBMUyBUUCBPQU0gPEJSPiZndDsgRnJhbWV3b3JrIEktRCwgDQogICAg ICB1bmljYXN0IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRpbWVzIGFuZCByZXR1cm4g PEJSPiZndDsgcGF0aHMgbm90IA0KICAgICAgYXQgYWxsLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoYW5r cyw8QlI+Jmd0OyA8QlI+Jmd0OyBKb2huPEJSPiZndDsgJmd0OyANCiAgICAgIC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgJmd0OyBGcm9tOiBCVVNJIElUQUxPIA0KICAgICAgW21h aWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0XTxCUj4mZ3Q7ICZndDsgU2VudDogRnJp ZGF5LCBBcHJpbCAxNywgDQogICAgICAyMDA5IDE6NTkgQU08QlI+Jmd0OyAmZ3Q7IFRvOiBEcmFr ZSwgSm9obiBFOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiANCiAgICAgIFZpc3NlcnM8 QlI+Jmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyBTdWJqZWN0OiBS RTogDQogICAgICBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBw YXRoIDxCUj4mZ3Q7ICZndDsgDQogICAgICByZXF1aXJlbWVudHM8QlI+Jmd0OyAmZ3Q7IDxCUj4m Z3Q7ICZndDsgSm9obiw8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgSSANCiAgICAgIG1pZ2h0 IGhhdmUgbWlzc2VkIHRoZSBhZ3JlZW1lbnQgb2YgTVBMUy1UUCBiZWluZyBjYXBhYmxlIG9mIDxC Uj4mZ3Q7ICZndDsgDQogICAgICBzZW5kaW5nIHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNlbnQg b24gdW5pLWRpcmVjdGlvbmFsIExTUHMuPEJSPiZndDsgJmd0OyANCiAgICAgIDxCUj4mZ3Q7ICZn dDsgVGhpcyByZXF1aXJlbWVudCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlIGZpcnN0IHNldCBvZiAN CiAgICAgIHJlcXVpcmVtZW50cyA8QlI+Jmd0OyAmZ3Q7IElUVS1UIGlzIGV4cGVjdGluZyB0byBi ZSBtZXQgYnkgDQogICAgICBPY3RvYmVyLjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBIb3dl dmVyLCBJIHRoaW5rIHRoaXMgaW4gYSBwb3RlbnRpYWwgDQogICAgICBpbnRlcmVzdGluZyBhZGRp dGlvbmFsIDxCUj4mZ3Q7ICZndDsgcmVxdWlyZW1lbnQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50 IA0KICAgICAgKGF0IHdvcnN0IGluIGE8QlI+Jmd0OyBzdWJzZXF1ZW50IHBoYXNlKS48QlI+Jmd0 OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgSSANCiAgICAgIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVu dCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgdmVyc3VzIG90aGVyIDxCUj4mZ3Q7IA0KICAgICAgJmd0 OyBtb3JlIGltcG9ydGFudCByZXF1aXJlbWVudHMgKGUuZy4gdGhlIHBvc3NpYmlsaXR5IHRvIHdv cmsgdy9vIElQIA0KICAgICAgPEJSPiZndDsgJmd0OyBmb3J3YXJkaW5nIGFuZCB0aGUgbmVlZCBm b3IgT0FNIHRvIGNvbnRpbnVlIHRvIG1vbml0b3IgdGhlIA0KICAgICAgZGF0YSA8QlI+Jmd0OyAm Z3Q7IHBsYW5lIGFsc28gaW4gY2FzZSBvZiBmYWlsdXJlcyBhZmZlY3RpbmcgdGhlIGNvbnRyb2wg b3IgDQogICAgICBtYW5hZ2VtZW50IDxCUj4mZ3Q7ICZndDsgcGxhbmUpLjxCUj4mZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyBJIGFtIG9wZW4gdG8gDQogICAgICBkaXNjdXNzIGl0IGJ1dCBub3Qgc3Vy ZSB0aGlzIGlzIHRoZSByaWdodCB0aW1lIGJlY2F1c2UgPEJSPiZndDsgJmd0OyBJIA0KICAgICAg d2lzaCB0byBhdm9pZCBkZWxheWluZyB0aGUgZmlyc3QgcGhhc2Ugb2YgdGhlIGRlc2lnbiBzb2x1 dGlvbi48QlI+Jmd0OyANCiAgICAgICZndDsgPEJSPiZndDsgJmd0OyBUaGFua3MsIEl0YWxvPEJS PiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyBGcm9tOiANCiAgICAgIG1wbHMtdHAtYm91bmNlc0Bp ZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgIFttYWlsdG86bXBscy10cC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRHJha2UsIEpvaG4gRTxCUj4mZ3Q7ICZndDsgDQogICAg ICAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA4OjAwIFBNPEJSPiZndDsgJmd0 OyAmZ3Q7IFRvOiANCiAgICAgIEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnM8 QlI+Jmd0OyAmZ3Q7ICZndDsgQ2M6IA0KICAgICAgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZn dDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgDQogICAgICBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoIDxCUj4mZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgQXQgdGhlIG1lZXRpbmcg bGFzdCBmYWxsIGF0IEp1bmlwZXIgaW4gDQogICAgICBNYXNzYWNodXNldHRzLCBJPEJSPiZndDsg Jmd0OyB0aGluayBpdCB3YXM8QlI+Jmd0OyAmZ3Q7ICZndDsgYWdyZWVkIHRoYXQgDQogICAgICBh biBNUExTIFRQIG5ldHdvcmsgbmVlZHMgdG8gaGF2ZSBhIGZvcndhcmRpbmc8QlI+Jmd0OyAmZ3Q7 IA0KICAgICAgY2FwYWJpbGl0eTxCUj4mZ3Q7ICZndDsgJmd0OyBmb3IgbWFuYWdlbWVudCwgY29u dHJvbCwgYW5kIE9BTSBwYWNrZXRzIA0KICAgICAgKGUuZy4sIHNlbmRpbmc8QlI+Jmd0OyAmZ3Q7 IHJlcGxpZXMgdG8gT0FNPEJSPiZndDsgJmd0OyAmZ3Q7IHJlcXVlc3RzIHNlbnQgDQogICAgICBv biB1bmktZGlyZWN0aW9uYWwgTFNQcykgZXZlbiBpZiBpdCBkb2VzIG5vdDxCUj4mZ3Q7ICZndDsg aGF2ZSBhbiANCiAgICAgIElQPEJSPiZndDsgJmd0OyAmZ3Q7IGZvcndhcmRpbmcgZGF0YSBwbGFu ZS48QlI+Jmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb206IA0KICAg ICAgQWxleGFuZGVyIFZhaW5zaHRlaW48QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICBbbWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFNlbnQ6IA0KICAgICAgVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDk6NTcgQU08QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBUbzogTWFhcnRlbiANCiAgICAgIFZpc3NlcnM8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHM8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIE1hYXJ0 ZW4sPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSXQgc2VlbXMgdGhhdCB5b3UndmUganVzdCAoaW1w bGljaXRseSBhbmQsIA0KICAgICAgcHJvYmFibHksPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5h ZHZlcnRlbnRseSkgc3RhdGVkIHRoZSANCiAgICAgIGZvbGxvd2luZzo8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IA0KICAgICAgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TVBMUy1UUCBPQU0g d2lsbCBub3QgZXZlciANCiAgICAgIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0aW9uPEJSPiZn dDsgJmd0OyAoYW5kIGZhdWx0PEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyBsb2NhbGl6 YXRpb24gd2hpY2ggcmVxdWlyZXMgdGhpcyBmdW5jdGlvbiApIGZvcjxCUj4mZ3Q7ICZndDsgDQog ICAgICB1bmlkaXJlY3Rpb25hbCBQMk1QPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYW5kIFAyUCBw YXRocy48QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IElmIHRoaXMgc3RhdGVtZW50IGlzIGNvcnJlY3QsIHRoaXMgKElNSE8gDQogICAgICBhbmQg RldJVyk8QlI+Jmd0OyByYWlzZXMgYSB2YWxpZDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHF1ZXN0 aW9uOjxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAgICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0lzIE1QTFMtVFAgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIA0K ICAgICAgdGhlc2U8QlI+Jmd0OyB0eXBlcyBvZiB0cmFuc3BvcnQ8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBwYXRocz88QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IEZvciB0aGUgcmVmZXJlbmNlLCBJUC9NUExTIHByb3ZpZGVzIA0KICAgICAgdGhp cyBraW5kIG9mPEJSPiZndDsgJmd0OyBmdW5jdGlvbmFsaXR5IHRvZGF5PEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgZm9yIA0KICAgICAgKHVuaWRpcmVjdGlvbmFsIC0gYnV0IGl0IGRvZXMgbm90IGtu b3cgYW55IG90aGVyPEJSPiZndDsgJmd0OyB0eXBlKSBQMlAgDQogICAgICBMU1BzPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgYXMgZGVzY3JpYmVkIGluIFJGQyA0Mzc5LiBBbmQgaXRzIGV4dGVuc2lv biB0byANCiAgICAgIFAyTVAgTFNQcyBzZWVtcyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBlYXN5 Li4uPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbmJzcDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAg ICAmZ3Q7IFJlZ2FyZHMsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyANCiAgICAgICZuYnNwO1Nhc2hhPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tOiANCiAgICAg IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbXBscy10cC1ib3VuY2VzQGlldGYub3JnXTxCUj4m Z3Q7ICZndDsgT24gDQogICAgICBCZWhhbGY8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBPZiBNYWFy dGVuIFZpc3NlcnMgDQogICAgICBbbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEFwcmlsIA0KICAgICAgMTYsIDIwMDkgMzoy NCBQTTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiAnQWRyaWFuIEZhcnJlbCc8QlI+Jmd0OyAm Z3Q7IA0KICAgICAgJmd0OyAmZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgU3ViamVjdDogUmU6IA0KICAgICAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIHJl cXVpcmVtZW50czxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IA0KICAgICAgQWRyaWFuLDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsmZ3Q7IA0KICAgICAgJmx0O3F1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIA0KICAgICAgaW50ZXJtZWRpYXRl IG5vZGVzIChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBv dGhlciANCiAgICAgIGludGVybmFsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25zIGFzIA0KICAgICAgYXBwcm9wcmlhdGUpIG9mIGEg Y28tcm91dGVkPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYmlkaXJlY3Rpb25hbCANCiAgICAgIHRy YW5zcG9ydDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHBhdGggYXQgDQogICAgICBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhl IHBhaXJpbmc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHJlbGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIA0KICAgICAg YmFja3dhcmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRy YW5zcG9ydCBwYXRoLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyZndDsgJmx0 O2VuZCBxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAm Z3Q7IA0KICAgICAgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlzIGEgZnVuY3Rpb25h bCByZXF1aXJlbWVudC4gVGhhdDxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IGlzLCB0aGVyZSBp czxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKm5vdGhpbmcqIHRoYXQgY2FuIGJlIA0KICAg ICAgb2JzZXJ2ZWQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCBvZjxCUj4mZ3Q7ICZndDsgJmd0OyB2 aWV3IHRoYXQ8QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVzdWx0cyBmcm9t IGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNv cnJlY3QuIA0KICAgICAgSXQgaXMgdmVyeSBtdWNoPEJSPiZndDsgb2JzZXJ2YWJsZSBpZjxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgDQogICAgICByZXF1aXJlbWVudCBpcyBtZXQgZnJvbSBh IGJsYWNrIGJveCBwb2ludCBvZiB2aWV3LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAg VGhlIE1JUCBmdW5jdGlvbnMgY2FuIG9ubHkgcGVyZm9ybSB0aGUgTG9vcGJhY2sgd2hlbiB0aGVy ZSBpcyBhIDxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGguIFRoZSBNUExTLVRQIExCTSANCiAgICAgIHBhY2tldCA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyByZWNlaXZlZCBhdCBhIE1JUCBuZWVkcyB0byBiZSByZXR1cm5l ZCAoYXMgDQogICAgICBMQlI8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYWNrZXQpIHRvIHRoZSBv cmlnaW5hdGluZyBNRVAgZnVuY3Rpb24gdmlhIHRoZSANCiAgICAgIG90aGVyPEJSPiZndDsgJmd0 OyBkaXJlY3Rpb24gb2Y8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgY28tcm91dGVkIA0KICAg ICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aC4gVGhpcyBvdGhlcjxCUj4mZ3Q7IGRpcmVj dGlvbjxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgd291bGQgbm90IGJlIGF2YWlsYWJs ZSBpbiBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IA0KICAgICAgPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgcGF0aC4uLiBhbmQgdGh1cyB0aGUgbG9vcGJhY2sgdGVzdDxCUj4m Z3Q7ICZndDsgDQogICAgICAmZ3Q7IHdvdWxkIGZhaWwuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgU2ltaWxhcmx5LCANCiAgICAgIHdoZW4gd2UgaGF2ZSB0 byBhcHBseSBUQ00gTUVQcyB0byBtb25pdG9yIGE8QlI+Jmd0OyAmZ3Q7IHNlZ21lbnQsIA0KICAg ICAgdGhlbjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgaXMgcG9zc2libGUgaW4gYSBjby1y b3V0ZWQgYmlkaXIgDQogICAgICB0cmFuc3BvcnQgcGF0aDxCUj4mZ3Q7IGJ1dCBub3QgaW4gYTxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFzc29jaWF0ZWQgDQogICAgICBiaWRpciB0cmFuc3BvcnQg cGF0aC4gSW4gdGhlIGZpcnN0IGNhc2UgdGhlIFRDTSBNRVAgPEJSPiZndDsgJmd0OyAmZ3Q7IA0K ICAgICAgJmd0OyBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zIGFyZSBjby1sb2NhdGVkIGFuZCBj YW48QlI+Jmd0OyBleGNoYW5nZSANCiAgICAgIHdoYXQgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyBjYWxsZWQgInJlbW90ZSBpbmZvcm1hdGlvbiIgd2hpY2ggaXMgDQogICAgICBuZWNlc3Nhcnkg Zm9yIHBlcmZvcm1hbmNlIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3JpbmcuPEJSPiZn dDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBJbiB0aGUgbGF0dGVyIGNhc2UgdGhlIFRDTSBNRVAg U291cmNlIGFuZCBTaW5rIGZ1bmN0aW9uczxCUj4mZ3Q7IA0KICAgICAgJmd0OyBhcmUgaW4gZS5n LiA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsg DQogICAgICBhbmQgVENNIHdvdWxkIG5vdCBiZSBhYmxlPEJSPiZndDsgJmd0OyB0byBwcm92aWRl PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLjxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0 OyBUaGUgZW50aXJldHkgb2YgdGhlIGJyYWNrZXR0ZWQgdGV4dCAiKGluY2x1ZGluZyBNRVBzLDxC Uj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7IE1JUHMgYW5kIG90aGVyPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgaW50ZXJuYWw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsgZnVuY3Rp b25zIGFzIGFwcHJvcHJpYXRlKSIgc2hvdWxkIGJlIGRlbGV0ZWQuIEl0IGRvZXMgbm90PEJSPiZn dDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyBhZGQgdG8gIlRoZTxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgaW50ZXJtZWRpYXRlIA0KICAgICAgbm9kZXMuIjxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFlvdXIgdW5kZXJzdGFuZGluZyANCiAgICAgIGlz IG5vdCBjb3JyZWN0LiBUaGlzIHRleHQgbXVzdCBub3QgYmU8QlI+Jmd0OyAmZ3Q7IGRlbGV0ZWQg YXQ8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IGFsbC48QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgQWN0dWFsbHksIEkgYW0g cXVpdGUgZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAg ICAgIGluc2lzdGVuY2Ugb24gdGhlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5jbHVzaW9uPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IG9mICJUYW5kZW0gQ29ubmVjdGlvbi4i IFRoZSBkZWZpbml0aW9uIHdpdGhpbiB0aGUgSVRVLVQgb2Y8QlI+Jmd0OyANCiAgICAgICZndDsg Jmd0OyAmZ3Q7IHRoaXMgdGVybTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaXM8QlI+Jmd0 OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IHBvb3JseTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgc3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZSANCiAgICAgIG1vbml0b3Jpbmcgb2YgYSBw YXRoIHRoYXQgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXJhbGxlbCAoaS5lLjxCUj4mZ3Q7 IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgdGFuZGVtKTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgdG8gdGhlIGRhdGEgcGF0aCBiZWluZyANCiAgICAgIG1vbml0b3JlZC4gVGhpcyBkZWZpbml0 aW9uIG9mIFRDPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgc2VlbXMgdG8gYmUgDQogICAgICBhdDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHZhcmlhbmNlLDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgYW5kIHdvdWxkIA0KICAgICAgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC48 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IEkg ZG9uJ3QgdW5kZXJzdGFuZCB3aGVyZSB5b3VyIGludGVycHJldGF0aW9uIG9mIHRhbmRlbTxCUj4m Z3Q7IA0KICAgICAgJmd0OyBjb25uZWN0aW9uIGlzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgZGVz Y3JpYmVkIGluIElUVS1UIA0KICAgICAgcmVjb21tZW5kYXRpb25zLiBJLmUuICJmcm9tIHRoZTxC Uj4mZ3Q7ICZndDsgbW9uaXRvcmluZyBvZiBhPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0 OyBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUgZGF0YSBwYXRoIGJl aW5nIA0KICAgICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbW9uaXRvcmVkLiI/PEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBUaGVyZSBpcyBh ICJuZXR3b3JrIGNvbm5lY3Rpb24iIGFuZCB0aGlzIG5ldHdvcms8QlI+Jmd0OyAmZ3Q7IA0KICAg ICAgY29ubmVjdGlvbiBpcyBhIHNldDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9mIGludGVyY29u bmVjdGVkICJsaW5rIA0KICAgICAgY29ubmVjdGlvbnMiIGFuZCAibWF0cml4PEJSPiZndDsgY29u bmVjdGlvbnMiLiBBPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBzdWJzZXQgb2YgdGhv c2UgaW50ZXJjb25uZWN0ZWQgbGluayBjb25uZWN0aW9ucyBhbmQgbWF0cml4IDxCUj4mZ3Q7ICZn dDsgDQogICAgICAmZ3Q7ICZndDsgY29ubmVjdGlvbnMgY2FuIGJlIG1vbml0b3JlZCBhbmQgaXMg dGhlbiByZWZlcnJlZCB0byBhczxCUj4mZ3Q7IA0KICAgICAgYSAidGFuZGVtPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgY29ubmVjdGlvbiIuIFRoZXJlIGlzIG5vICJwYXRoIHRoYXQgaXMgDQogICAg ICBwYXJhbGxlbCB0byB0aGU8QlI+Jmd0OyAmZ3Q7IGRhdGEgcGF0aCIuIDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFRoZXJlIGlzIA0KICAgICAgb25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBp bnNpZGUgdGhlIGRhdGE8QlI+Jmd0OyBwYXRoIGJ5IHRoZTxCUj4mZ3Q7IA0KICAgICAgJmd0OyAm Z3Q7ICZndDsgVENNIE1FUF9TbyBmdW5jdGlvbiBhbmQgdGhpcyBPQU0gaXMgZXh0cmFjdGVkIGZy b20gDQogICAgICB0aGU8QlI+Jmd0OyAmZ3Q7IGRhdGEgcGF0aCBieTxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IHRoZSBUQ00gTUVQX1NrIA0KICAgICAgZnVuY3Rpb24uPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgUmVnYXJkcyw8QlI+Jmd0OyANCiAgICAgICZn dDsgJmd0OyAmZ3Q7IE1hYXJ0ZW48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyANCiAgICAgIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBGcm9tOiBtcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIFttYWlsdG86 bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbDxCUj4m Z3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgU2VudDogZG9uZGVyZGFnIDE2IGFwcmlsIDIwMDkg MTE6NTk8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogDQogICAgICBBbGV4YW5kZXIgVmFpbnNo dGVpbjsgYmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb208QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyANCiAgICAgIENjOiBCVVNJIElUQUxPOyBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgU3ViamVjdDogUmU6IA0KICAgICAgW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIHJl cXVpcmVtZW50czxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IEhpIA0KICAgICAgU2FzaGEsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBVbmZvcnR1bmF0ZWx5IEkgDQogICAgICBjYW5ub3QgZnVsbHkgYWdyZWUg d2l0aCB5b3VyIHN0YXRlbWVudDo8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDs8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IA0KICAgICAgJm5ic3A7ICZuYnNwOyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3 IG9mIGhhcmR3YXJlLCBjby1yb3V0ZWQ8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyBiaWRpcmVj dGlvbmFsIExTUHM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgYXJl IGEgDQogICAgICBzcGVjaWFsIGNhc2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMu PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICZsdDtlbmQgcXVvdGUmZ3Q7PEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQog ICAgICBUaGlzIHN0YXRlbWVudCB3b3VsZCBiZSBvYnZpb3VzbHkgY29ycmVjdCwgd2VyZSBpdCBu b3QgZm9yPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBSZXF1aXJlbWVudDxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgMzQgaW4gdGhlIGxhdGVzdCBNUExTLVRQIA0KICAgICAgcmVx dWlyZW1lbnRzIGRyYWZ0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgT0suIEdvdCANCiAgICAgIGl0LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IEJ1dCB3aGF0IGlzIHRoaXMgZG9pbmcgDQogICAgICBpbiB0aGUgZGF0 YSBwbGFuZSByZXF1aXJlbWVudHMgc2VjdGlvbj88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+ Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7IEluIGZhY3QsIHdoYXQgaXMgdGhpcyByZXF1aXJl bWVudCBhY3R1YWxseSBzYXlpbmc/PEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyA8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7IA0KICAg ICAgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIG5v ZGVzIChpbmNsdWRpbmcgTUVQcywgDQogICAgICBNSVBzIGFuZDxCUj4mZ3Q7ICZndDsgJmd0OyBv dGhlciBpbnRlcm5hbDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkPEJS PiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydDxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IA0KICAgICAgJm5ic3A7ICZuYnNwOyBwYXRo IGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgDQogICAgICBwYWlyaW5n PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGlv bnNoaXAgb2YgDQogICAgICB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgZGlyZWN0aW9ucyBvZiANCiAgICAgIHRoYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCANCiAgICAgIHBhdGguPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0OzxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IA0KICAgICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8gd2F5 IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50LiANCiAgICAgIFRoYXQ8QlI+Jmd0OyAm Z3Q7IGlzLCB0aGVyZSBpczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICpub3RoaW5nKiB0aGF0IGNh biANCiAgICAgIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2Y8QlI+Jmd0OyAm Z3Q7IHZpZXcgdGhhdDxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgcmVzdWx0cyBmcm9t IGFkaGVyaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZWZvcmUgaXQgY291bGQgYmUgYXNzdW1l ZCB0aGF0IHRoaXMgDQogICAgICByZXF1aXJlbWVudCBpcyBtZXQgYnkgPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgY29uZmlndXJpbmcgc29tZSBkYXRhIHBsYW5lIA0KICAgICAgZGF0YWJhc2UgY29t cG9uZW50IHRocm91Z2ggdGhlIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1hbmFnZW1lbnQgcGxh bmUuIA0KICAgICAgVGhlIGRhdGFiYXNlIGNvbXBvbmVudCBpcyBub3QgdXNlZDxCUj4mZ3Q7IGZv ciBhbnl0aGluZzxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsgZXhjZXB0IHRvIHNhdGlz ZnkgdGhpcyByZXF1aXJlbWVudCBmb3IgImF3YXJlbmVzcyIuPEJSPiZndDsgJmd0OyAmZ3Q7IA0K ICAgICAgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBCZW4hIENhbiB3ZSBwbGVhc2UgdHJ5 IHRvIHJld3JpdGUgdGhpcyANCiAgICAgIHJlcXVpcmVtZW50IGluIHRlcm1zIG9mIDxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGJlaGF2aW9yPzxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50 IDM0IGlzIA0KICAgICAgdGhlIE9OTFkgaXRlbSBpbiB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyBsaXN0IHRoYXQgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgc3BlY2lm aWMgZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuIChUaGUgcGFpcmluZzxCUj4mZ3Q7 IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBhdCBlbmQgcG9pbnRzIGZvciANCiAgICAgIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsPEJSPiZndDsgJmd0OyAmZ3Q7IHBhdGhzIGFyZTxCUj4mZ3Q7IA0KICAg ICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyBleGFjdGx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhleSBhcHBl YXIgaW4gdHdvIA0KICAgICAgZGlmZmVyZW50PEJSPiZndDsgJmd0OyAmZ3Q7IGl0ZW1zIGluIHRo ZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICByZXF1aXJlbWVudHMnIGxpc3Qp LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgDQog ICAgICBSZXF1aXJlbWVudCAzNCB0aGUgbm90aW9uIG9mPEJSPiZndDsgY28tcm91dGVkPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQg YmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50LjxCUj4mZ3Q7ICZndDsgDQogICAgICAm Z3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIHNvbWV3aGF0IHZh Z3VlIHNjb3BlIG9mIA0KICAgICAgdGhpcyByZXF1aXJlbWVudCAoIm90aGVyIGludGVybmFsIDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZnVuY3Rpb25zIA0KICAgICAgYXMgYXBwcm9wcmlh dGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAN CiAgICAgIHN1cHBvcnQgb2YgdGhlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYWlyaW5n IGF3YXJlbmVzcyBtYXkgYmUgDQogICAgICByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0 aCBpdC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAm Z3Q7IFRoZSBlbnRpcmV0eSBvZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICIoaW5jbHVkaW5nIE1FUHMs PEJSPiZndDsgDQogICAgICAmZ3Q7IE1JUHMgYW5kIG90aGVyPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgaW50ZXJuYWwgZnVuY3Rpb25zIGFzIA0KICAgICAgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUg ZGVsZXRlZC4gSXQ8QlI+Jmd0OyAmZ3Q7IGRvZXMgbm90PEJSPiZndDsgJmd0OyANCiAgICAgICZn dDsgJmd0OyBhZGQgdG8gIlRoZSBpbnRlcm1lZGlhdGUgbm9kZXMuIjxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZm9sbG93aW5n IHRleHQgaW4gdGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzIA0KICAgICAgc3VzcGljaW9uOjxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgJmx0O3F1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IFRhbmRl bSBDb25uZWN0aW9uOiBBIA0KICAgICAgdGFuZGVtIGNvbm5lY3Rpb24gaXMgYW48QlI+Jmd0OyAm Z3Q7IGFyYml0cmFyeSBwYXJ0IG9mIGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZn dDsgJm5ic3A7IHRyYW5zcG9ydCBwYXRoIHRoYXQgY2FuIGJlIG1vbml0b3JlZCAodmlhIE9BTSk8 QlI+Jmd0OyANCiAgICAgICZndDsgJmd0OyAmZ3Q7IGluZGVwZW5kZW50bHkgZnJvbSB0aGU8QlI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgIGVuZC10by1lbmQgbW9uaXRv cmluZyAoT0FNKS4gJm5ic3A7SXQgbWF5IGJlIGEgbW9uaXRvcmVkPEJSPiZndDsgJmd0OyANCiAg ICAgIHNlZ21lbnQgb3IgYTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IG1vbml0 b3JlZCBjb25jYXRlbmF0ZWQgDQogICAgICBzZWdtZW50IG9mIGEgdHJhbnNwb3J0IHBhdGguICZu YnNwOzxCUj4mZ3Q7ICZndDsgVGhlIHRhbmRlbTxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgY29ubmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5n IGVuZ2luZShzKSANCiAgICAgIG9mPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIG5vZGUocyk8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgIGF0IHRoZSBlZGdlKHMp IG9mIHRoZSBzZWdtZW50IG9yIGNvbmNhdGVuYXRlZCBzZWdtZW50LjxCUj4mZ3Q7ICZndDsgJmd0 OyANCiAgICAgICZndDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgQWN0dWFsbHksIEkgYW0gcXVpdGUg ZmVkIHVwIGFib3V0IHRoaXMgcGVyc2lzdGVudDxCUj4mZ3Q7ICZndDsgaW5zaXN0ZW5jZSANCiAg ICAgIG9uIHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluY2x1c2lvbiBvZiAiVGFuZGVtIENv bm5lY3Rpb24uIiBUaGUgDQogICAgICBkZWZpbml0aW9uIHdpdGhpbjxCUj4mZ3Q7ICZndDsgdGhl IElUVS1UIG9mPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyANCiAgICAgIHRlcm0gaXMgcG9v cmx5IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGU8QlI+Jmd0OyBtb25pdG9yaW5nIG9mIA0K ICAgICAgYTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhdGggdGhhdCBpcyBwYXJhbGxlbCAoaS5l LiB0YW5kZW0pIHRvIHRoZSBkYXRhIA0KICAgICAgcGF0aCBiZWluZyA8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyBtb25pdG9yZWQuIFRoaXMgZGVmaW5pdGlvbiBvZiBUQyBzZWVtcyANCiAgICAgIHRv IGJlIGF0IHZhcmlhbmNlLDxCUj4mZ3Q7ICZndDsgYW5kIHdvdWxkPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgYmUgaWYgdGhlIA0KICAgICAgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgJmd0OyBEb2Vz bid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgc291bmQgbGlrZSBoYXJkd2FyZSB0byB5b3U/PEJSPiZn dDsgJmd0OyANCiAgICAgICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZZXMsIGJ1 dCBzbyB3aGF0PzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBJTUhPIGl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IG5laXRoZXIgdGhlIA0K ICAgICAgTVBMUy1UUDxCUj4mZ3Q7ICZndDsgJmd0OyBSZXF1aXJlbWVudHMgZHJhZnQ8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJl bWVudHMgb25lPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyANCiAgICAgICZn dDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0K ICAgICAgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBs cy10cC1vYW0tcmVxdWlyZW1lbjxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0 cy0wMS50eHQpIGNvbnRhaW4gYW55IHJlcXVpcmVtZW50cyBkZWFsaW5nIHdpdGggDQogICAgICB0 YW5kZW08QlI+Jmd0OyAmZ3Q7ICZndDsgY29ubmVjdGlvbnMuPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OzxCUj4mZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyBCdXQgdGFuZGVtIGNv bm5lY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIE1QTFMtVFAgDQogICAgICBPQU08QlI+Jmd0 OyAmZ3Q7IEZyYW1ld29yazxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZHJhZnQ8QlI+Jmd0 OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IA0KICAgICAgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tZnI8QlI+Jmd0OyANCiAgICAgICZn dDsgJmd0OyAmZ3Q7IGFtZXdvcmstMDAudHh0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgKS48QlI+ Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJpZ2h0 LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IExldCdzIGp1c3QgZ2V0IA0KICAgICAgcmlkIG9mIGFu IHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nIGFsbDxCUj4mZ3Q7IHRoZSBJLURzPEJSPiZndDsg Jmd0OyANCiAgICAgICZndDsgJmd0OyBpbnRvIGxpbmUuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIFRoZSBib3R0b20gbGluZSwgSU1I TywgaXMgdGhhdCBzb21lIGNsYXJpdHkgcmVnYXJkaW5nPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgY28tcm91dGVkIHZzLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXNzb2NpYXRlZDxC Uj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGlz IHN0aWxsIHJlcXVpcmVkLiBPbmUgd2F5IHRvIA0KICAgICAgcHJvdmlkZTxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHRoYXQgY291bGQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlIA0KICAg ICAgYnkgZXhwbGljaXRseSBsaW1pdGluZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYzxCUj4m Z3Q7ICZndDsgJmd0OyANCiAgICAgIGZ1bmN0aW9uYWxpdHkuPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICBBZ3JlZWQuPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgQWRyaWFuPEJSPiZndDsgJmd0OyANCiAg ICAgICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IA0KICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb206IA0KICAgICAgQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9s ZGRvZy5jby51a108QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgDQogICAg ICBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBBbGV4 YW5kZXIgVmFpbnNodGVpbjsgDQogICAgICBMb3UgQmVyZ2VyOyBCVVNJIElUQUxPPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8QlI+Jmd0OyANCiAgICAgICZndDsg Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydCANCiAgICAgIHBhdGggPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1l bnRzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0 OyBIaSBTYXNoYSw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyANCiAgICAgIE5vdCByZWFsbHkgc3VyZSB3aGV0aGVyIHlvdSBhcmUgbWlzcmVwcmVzZW50aW5n IGFueW9uZSwgYnV0Li4uPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IDEuIE15IHJlYWRpbmcgb2YgJm5ic3A7b25lIG9mIA0KICAgICAg QmVuJ3MgJm5ic3A7bWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkIDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogICAgICBiaWRpcmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBl cyBvZiBwYXRocyB0aGF0IGNhbiBiZTxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgY3Jl YXRlZCBpbjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlIGV4aXN0aW5nIG5ldHdvcmtz OyANCiAgICAgICJ0cnVlIiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRoczxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHdpbGwgDQogICAgICBoYXZlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyB0byB3YWl0IHVudGlsIChpZiBldmVyKSBuZXcgZXF1aXBtZW50IA0KICAgICAgYmVjb21lcyBh dmFpbGFibGUuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg VGhpcyBpcyANCiAgICAgIGNsZWFybHkgbm9uc2Vuc2UhPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiANCiAgICAgIGhhcmR3YXJlLCBjby1yb3V0ZWQ8QlI+ Jmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQcyBhcmU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAg ICAmZ3Q7IGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLjxC Uj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYg eW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMgDQogICAgICAoZS5nLiB1c2lu ZyB0aGU8QlI+Jmd0OyAmZ3Q7IG1hbmFnZW1lbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwbGFu ZSkgeW91IA0KICAgICAgY2FuIHN1cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQ8QlI+Jmd0OyAmZ3Q7 ICZndDsgYmlkaXJlY3Rpb25hbCBMU1AuPEJSPiZndDsgDQogICAgICAmZ3Q7ICZndDsgJmd0OyA8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgc2hpcHBpbmcgc29sdXRpb25zIHRoYXQg DQogICAgICBhY2hpZXZlIGNvLXJvdXRlZDxCUj4mZ3Q7IGJpZGlyZWN0aW9uYWw8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBMU1BzIHVzaW5nIA0KICAgICAgdGhlIGNvbnRyb2wgcGxhbmUuIFRoZXNl IGVpdGhlciB1c2UgdGhlIEdNUExTPEJSPiZndDsgJmd0OyAod2hpY2ggDQogICAgICBpczxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IGNsZWFuZXIpIG9yIG5vbi1zdGFuZGFyZCBwcm9wcmlldGFyeSBz b2x1dGlvbnMgDQogICAgICAod2hpY2ggaXM8QlI+Jmd0OyAmZ3Q7IG1lc3N5IGJ1dDxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgZnVuY3Rpb25hbCkuPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0IChvZiANCiAgICAgIGNvdXJzZSkgdGhlIG1h bmFnZW1lbnQgcGxhbmUgb3IgY29udHJvbCBwbGFuZTxCUj4mZ3Q7ICZndDsgc29sdXRpb25zIA0K ICAgICAgaGF2ZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5vdGhpbmcgdG8gZG8gd2l0aCBhdmFp bGFiaWxpdHkgb2YgZXF1aXBtZW50IA0KICAgICAgYXMgdGhleTwvVFQ+PC9GT05UPiA8QlI+PEZP TlQgc2l6ZT0yPjxUVD4mZ3Q7IGFyZSBzb2Z0d2FyZTxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7 ICZndDsgc29sdXRpb25zLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogICAgICAyLiBNeSByZWFkaW5nIG9mIG9uZSBvZiBOZWlsJ3MgbWVzc2Fn ZXMgaXMgdGhhdCB0aGUgYWN0dWFsPEJSPiZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBkcml2 ZXIgZm9yPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCANCiAgICAgIHBhdGhzIG1heSBiZSBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcgPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIHRyYW5zcG9ydCBuZXR3b3JrcyByYXRoZXIgdGhh biBhbnkgc3BlY2lmaWMgYmVuZWZpdC48QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAmZ3Q7IDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2YgdGhl IE1QTFMtVFAgDQogICAgICByZXF1aXJlbWVudHM/PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgV2hp Y2ggaXMgbm90IHRvIHNheSBpdCBpcyBhIGJhZCANCiAgICAgIHRoaW5nLjxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEEgbGFyZ2UgZHJpdmVyIGZvciANCiAg ICAgIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcms8QlI+Jmd0OyAmZ3Q7IHRo ZSBsb29rLDxCUj4mZ3Q7ICZndDsgDQogICAgICAmZ3Q7ICZndDsgZmVlbCwgYW5kIGJlaGF2aW9y YWwgY2hhcmFjdGVyaXN0aWNzIG9mIGEgImxlZ2FjeSI8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0 OyAmZ3Q7IHRyYW5zcG9ydCBuZXR3b3JrLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7 ICZndDsgJmd0OyANCiAgICAgICZndDsgJmd0OyBCYXNlZCBvbiB0aGVzZSBvYnNlcnZhdGlvbnMs IEknZCBndWVzcyAoRldJVykgdGhhdDo8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7ICZn dDsgKiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlLCBhdCBsZWFzdCBmb3IgdGhl IA0KICAgICAgdGltZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2Jl aW5nLCB0aGUgbW9zdCBpbXBvcnRhbnQgDQogICAgICB0eXBlIG9mIGJpZGlyZWN0aW9uYWwgcGF0 aHMgaW48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgICZuYnNwO01Q TFMtVFA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHRo aW5rIHRoYXQgDQogICAgICBpcyB3cm9uZyBib3RoIGdpdmVuIG15IHN0YXRlbWVudCBhYm92ZSwg YW5kPEJSPiZndDsgJmd0OyBnaXZlbiANCiAgICAgIHRoYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyBvdGhlciB1cGdyYWRlcyB0byBleGlzdGluZyBNUExTIHNvbHV0aW9ucyB3aWxsIA0KICAgICAg YmU8QlI+Jmd0OyBuZWVkZWQgdG8gcmVhY2g8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZnVs bCBmdW5jdGlvbiBsZXZlbCANCiAgICAgIG9mIE1QTFMtVFAuPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqIHRoZXkgaGFkIA0KICAgICAgYSBnb29k IGNoYW5jZSB0byByZW1haW4gdGhlIG9ubHkgdHlwZSBvZjxCUj4mZ3Q7ICZndDsgDQogICAgICBi aWRpcmVjdGlvbmFsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgcGF0aHMgaW4g Jm5ic3A7cmVhbCANCiAgICAgIGRlcGxveW1lbnRzLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgZG9uJ3Qgc2VlIA0KICAgICAgd2hhdCB0aGF0IGZvbGxv d3MgZnJvbS48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAN CiAgICAgIENoZWVycyw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBZHJpYW48QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgJmd0OyANCiAgICAgICZn dDsgJmd0OyBtcGxzLXRwIG1haWxpbmcgbGlzdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgDQogICAgICA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgDQogICAgICBtcGxzLXRwIG1haWxpbmcgbGlzdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1w bHMtdHBAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAg ICAgICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0 OyAmZ3Q7ICZndDsgbXBscy10cCANCiAgICAgIG1haWxpbmcgbGlzdDxCUj4mZ3Q7ICZndDsgJmd0 OyBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPEJSPiZndDsgJmd0OyAmZ3Q7IDxCUj4m Z3Q7IA0KICAgICAgJmd0OyA8QlI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxCUj4mZ3Q7IA0KICAgICAgbXBscy10cCBtYWlsaW5nIGxpc3Q8QlI+ Jmd0OyBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgDQogICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8QlI+Jmd0OyANCiAgICAgIDxCUj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5tcGxzLXRwIG1haWxpbmcg DQogICAgICBsaXN0PEJSPm1wbHMtdHBAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPC9UVD48L0ZPTlQ+PEZPTlQgDQogICAgICBzaXplPTM+ PEJSPjxCUj48L0ZPTlQ+PEJSPjxGT05UIA0KICAgICAgc2l6ZT0zPjxUVD4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5aVEUgDQogICAg ICBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIA0KICAgICAgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KICAgICAgY29uZmlkZW50 aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2Vj cmVjeSBhbmQgDQogICAgICBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0KICAgICAgb3RoZXJzLjxCUj5UaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIA0KICAg ICAgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IA0KICAgICAgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCiAgICAgIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSANCiAgICAgIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48QlI+VGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIA0KICAgICAgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS48QlI+PC9UVD48L0ZPTlQ+PEJSPjxCUj48UFJFPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9QUkU+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9C T0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C9C4D8.90E903CF-- From neil.2.harrison@bt.com Fri Apr 24 05:39:04 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6C03A6826 for ; Fri, 24 Apr 2009 05:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0xFo91PK6WG for ; Fri, 24 Apr 2009 05:39:02 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6D01D28C192 for ; Fri, 24 Apr 2009 05:39:02 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 13:40:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 24 Apr 2009 13:40:11 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0479D2D5@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) thread-index: AcnEYLwwpSRuv4zbdUCO9uPM0MsD/gAd/N9Q From: To: , X-OriginalArrivalTime: 24 Apr 2009 12:40:19.0299 (UTC) FILETIME=[D38D9B30:01C9C4D9] Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 12:39:04 -0000 SSB0b3RhbGx5IGFncmVlIEJlbi4gIFRoZXJlIGlzIGEgY29uc2lkZXJhYmxlIGJvZHkgb2Ygb3Bl cmF0aW9uYWwgZXhwZXJpZW5jZSAoZXNwIG9uIE9BTSByZXF1aXJlbWVudHMpIGJlaGluZCB0aGUg Y29tbWVudHMgeW91IGhhdmUgc2VlbiBmcm9tIEJUIGZvbGtzLiAgV2UgYXJlIG5vdCBtYWtpbmcg dGhlc2UgcG9pbnRzIGxpZ2h0bHkuDQoNCkFuZCBmcm9tIHRoZSBkaWN1c3Npb25zIHNvIGZhciB0 aGUgb25lIHRoaW5nIEkgd291bGQgcmVhbGx5IGFwcHJlY2lhdGUgdGhlIE1QTFMtVFAgcmVxdWly ZW1lbnRzIG5vdyBjYXB0dXJpbmcgaXMgdGhlIGZhY3QgdGhhdCBNUExTLVRQIChhbmQgYW55IHR5 cGUgb2YgTVBMUyBvciBpbmRlZWQgRXRoZXJuZXQpIGFyZSAqbm90KiB0b3Atb2Ytc3RhY2sgbGF5 ZXIgbmV0d29ya3MgYW5kIHRodXMgdGhleSBkbyBub3QgbmVlZCBFLU5OSXMgYmVpbmcgY3JlYXRl ZCBmb3IgdGhlbS4gIEkgdGhpbmsgSSBjYW4gc3BlYWsgb24gYmVoYWxmIG9mIGFsbCBteSBCVCBj b2xsZWFndWVzIHdoZW4gSSBzYXkgdGhhdCB3ZSBjb3VsZCBuZXZlciBzdXBwb3J0IGFueSBNUExT LVRQIHN0YW5kYXJkcyB0aGF0IG1hbmRhdGVkIEUtTk5JcyBpbiB0aGVtIChhbmQgZm9yIHN1cmUg bm9uZSB0aGF0IGFkdm92YXRlZCBwZWVyIGludGVyd29ya2luZyBhY3Jvc3MgRS1OTklzIHdpdGgg YW55IG90aGVyIG5vbiB0b3Atb2Ytc3RhY2sgbGF5ZXIgbmV0d29yayB0ZWNobm9sb2d5IGxpa2Ug RXRoZXJuZXQpLg0KDQpyZWdhcmRzLCBOZWlsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIA0KPiBbbWFpbHRvOm1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBOaXZlbi1KZW5raW5zDQo+IFNlbnQ6 IDIzIEFwcmlsIDIwMDkgMjM6MTQNCj4gVG86IG1wbHMtdHBAaWV0Zi5vcmcNCj4gU3ViamVjdDog W21wbHMtdHBdIFdlIGFwcGVhciB0byBiZSBnb2luZyBhcm91bmQgaW4gY2lyY2xlcyANCj4gKFJl OiBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0K PiANCj4gQ29sbGVhZ3VlcywNCj4gDQo+IFRoZSBjdXJyZW50IGRlYmF0ZXMgYXBwZWFyIHRvIGJl IGdvaW5nIGFyb3VuZCBpbiBjaXJjbGVzIGFuZCBhY2hpZXZpbmcNCj4gbm90aGluZyBvZiB2YWx1 ZSBJTU8uIFR3byBtYWpvciBvcGVyYXRvcnMgaGF2ZSBleHByZXNzZWQgDQo+IHRoZWlyIG9waW5p b25zIGFuZA0KPiBubyBvcGVyYXRvciB0aGF0IEkgY2FuIHNlZSBoYXMgZGlzYWdyZWVkIHdpdGgg dGhvc2Ugb3BpbmlvbnMuDQo+IA0KPiBJIGFwb2xvZ2lzZSBmb3IgYmVpbmcgZGlyZWN0IChhbmQg cG9zc2libHkgcnVkZSkgYnV0IEkgYW0gDQo+IGdldHRpbmcgdGlyZWQgb2YNCj4gYmVpbmcgdG9s ZCBieSBmb2xrcyB3aG8gZG8gbm90IHJlcHJlc2VudCBvcGVyYXRvcnMgd2hhdCANCj4gZnVuY3Rp b25hbGl0eSBJIG5lZWQNCj4gb3Igc2hvdWxkIGhhdmUgaW4gbXkgbmV0d29ya3MuDQo+IA0KPiBU byBwdXQgc29tZSBjb250ZXh0IG9uIEJUJ3MgY29tbWVudHMgaW4gdGhlc2UgdGhyZWFkczoNCj4g SSBoYXZlIHRoZSBsYXJnZXN0IE1QTFMgbmV0d29yayBpbiB0aGUgVUsuDQo+IEkgaGF2ZSBvbmUg b2YgdGhlIGxhcmdlc3QgTVBMUyBuZXR3b3JrcyBnbG9iYWxseSBkZWxpdmVyaW5nIA0KPiBzZXJ2 aWNlIHRvIDE3Mw0KPiBjb3VudHJpZXMgd2l0aCBvdmVyIDIwMCAwMDAgY3VzdG9tZXIgcG9ydHMN Cj4gSSBoYXZlIChvZmYgdGhlIHRvcCBvZiBteSBoZWFkKSBhdCBsZWFzdCBhbm90aGVyIDEwIE1Q TFMgbmV0d29ya3MgaW4NCj4gc3BlY2lmaWMgY291bnRyaWVzIGNvdmVyaW5nIGF0IGxlYXN0IDMg Y29udGluZW50cyBkZWxpdmVyaW5nIGRlZGljYXRlZA0KPiBzZXJ2aWNlcyB0byBwYXJ0aWN1bGFy IG1hcmtldCBzZWdtZW50cy4NCj4gDQo+IEkgaGF2ZSBhbiBleHRyZW1lbHkgbGFyZ2UgU0RIIG5l dHdvcmsgaW4gdGhlIFVLIGNvbnNpc3Rpbmcgb2YgDQo+IG92ZXIgMzAgMDAwDQo+IHN3aXRjaGVz IGFuZCBzdXBwb3J0aW5nIGluIGV4Y2VzcyBvZiAxIG1pbGxpb24gY2lyY3VpdHMuDQo+IEkgaGF2 ZSBhbiBleHRyZW1lbHkgbGFyZ2UgU0RIIG5ldHdvcmsgZ2xvYmFsbHkgZGVsaXZlcmluZyANCj4g c2VydmljZSBpbiAxMTANCj4gY291bnRyaWVzLg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHRoaW5r IG15IEJUIGNvbGxlYWd1ZXMgYW5kIEkgbWlnaHQga25vdyBhIA0KPiBsaXR0bGUgc29tZXRoaW5n DQo+IGFib3V0IGJ1aWxkaW5nIGxhcmdlIHNjYWxlIG5ldHdvcmtzIGFuZCB0aGUgcmVxdWlyZW1l bnRzIG9mIA0KPiB0aG9zZSBuZXR3b3Jrcw0KPiBhbmQgdGhlIG5lZWRzIG9mIHRoZSBjdXN0b21l cnMgdGhhdCBJIGRlbGl2ZXIgc2VydmljZXMgdG8uDQo+IA0KPiBDYW4gd2UgcGxlYXNlIHN0b3Ag dGhlc2UgY2lyY3VsYXIgYXJndW1lbnRzIHdoaWNoIGFyZSBJTU8gDQo+IGdvaW5nIG5vd2hlcmUg YW5kDQo+IGZvY3VzIG9uIHRoZSB0YXNrIGluIGhhbmQgd2hpY2ggaXMgZGVmaW5pbmcgdGhlIHJl cXVpcmVtZW50cyANCj4gKGFuZCBsYXRlcg0KPiBzb2x1dGlvbnMpIGJlaW5nIGFza2VkIGZvciBi eSBteXNlbGYsIG15IGNvbXBhbnkgYW5kIG15IA0KPiBjb2xsZWFndWVzIGluIG90aGVyDQo+IG9w ZXJhdG9ycyBvbiB0aGlzIGxpc3QuDQo+IA0KPiBUaGFua3MNCj4gQmVuDQo+IA0KPiANCj4gLS0g DQo+IA0KPiBCZW4gTml2ZW4tSmVua2lucw0KPiBJUCwgRGF0YSAmIENvbnRlbnQgQXJjaGl0ZWN0 DQo+IE5ldHdvcmsgSW5mcmFzdHJ1Y3R1cmUgQXJjaGl0ZWN0dXJlLCBCVA0KPiAgIA0KPiBFLW1h aWw6IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tDQo+IE9mZmljZTogKzQ0ICgwKTE0NzMg NjQ4MjI1DQo+IE1vYmlsZTogKzQ0ICgwKTc5MTggMDc3MjA1DQo+ICAgIEZheDogKzQ0ICgwKTEz MzIgNTc4ODI3DQo+IA0KPiBCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMuIFJlZ2lzdGVy ZWQgb2ZmaWNlOiAgODEgDQo+IE5ld2dhdGUgU3RyZWV0IExvbmRvbg0KPiBFQzFBIDdBSiAgIFJl Z2lzdGVyZWQgaW4gRW5nbGFuZCBubzogIDE4MDAwMDANCj4gDQo+IA0KPiBPbiAyMy8wNC8yMDA5 IDA3OjIzLCAibGl1Lmd1b21hbkB6dGUuY29tLmNuIiANCj4gPGxpdS5ndW9tYW5AenRlLmNvbS5j bj4gd3JvdGU6DQo+IA0KPiA+IGJlbjoNCj4gPiAgSSB1bmRlcnN0YW5kIHlvdXIgbWVhbmluZywg eW91IHN0aWxsIHdpc2ggdG8gcmVzaWduIGFuZCBtYWtlIGEgbW9yZQ0KPiA+IHJlbGlhYmxlIGFu ZCBlZmZlY3RpdmUsIGVhc3kgdG8gb3BlcmF0b3IgYW5kIGVhc3kgdG8gbWFuYWdlIHBhY2tldA0K PiA+IHRyYW5zcG9ydCBuZXR3b3JrIGxpa2UgbWUuIGJ1dCB3aHkgbm90IGFwcGx5IHRoaXMgU0RI L1NPTkVUIA0KPiBpbiB0aGUgZnV0dXJlDQo+ID4gbWF5YmUgdGhlIGZvbGxvd2luZyBjYXVzZToN Cj4gPiAgICAxIGl0IGFkb3B0ZWQgY2lyY3VpdCBzd2l0Y2hpbmcgdGVjaG9ub2d5IHRvIGJyaW5n IGxvd2VyIA0KPiB1c2VmdWwgb2YgdGhlDQo+ID4gcmVzb3VyY2UgdGhhbiBQVE4gbmV0d29yazsN Cj4gPiAgICAyIGl0IGNhbid0IGJlYXIgYWxsIGtpbmRzIG9mIHRyYWZmaWNzIGxpa2UgUFROIG5l dHdvcmtzDQo+ID4gaXQgbm90ZWQgdGhhdCB3ZSBjYW4ndCBhcHBseSBTREgvU09ORVQgbmV0d29y ayBpbiB0aGUgDQo+IGZ1dHVyZSBub3QgYmVjYXVzZQ0KPiA+IGl0IGhhdmUgYSBjb21wbGV4IE9B TSBmdW5jdGlvbnMuIHdoaWxlIG1vcmUgcGVvcGxlIGxpa2UgdG8gbW92ZSB0aGUNCj4gPiBhZHZh bnRhZ2VzIG9mICB0aGUgT0FNIGZ1bmN0aW9ucyBpbiBTREgvU09ORVQgdG8gUFROIA0KPiBuZXR3 b3Jrcy4gYW5kIEFJUy9GREkNCj4gPiBmdW5jdGlvbiBpcyBhIGtpbmQgb2YgT0FNIGZ1bmN0aW9u cyBvZiBTREgvU09ORVQgLiB3ZSBzaG91bGQgdXNlIGFuZA0KPiA+IGV4dGVuZCB0aGUgQUlTL0ZE SSBmdW5jdGlvbnMgdG8gTVBMUy1UUCA7DQo+ID4gDQo+ID4gYmVzdCByZWdhcmRzDQo+ID4gbGl1 DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gQmVuIE5pdmVuLUplbmtpbnMgPGJlbmphbWluLm5pdmVu LWplbmtpbnNAYnQuY29tPg0KPiA+IDIwMDktMDQtMjMgMDc6NTgNCj4gPiANCj4gPiDmlLbku7bk uroNCj4gPiA8bGl1Lmd1b21hbkB6dGUuY29tLmNuPiwgIkJSVU5HQVJELCBERUJPUkFIIEEsIEFU VExBQlMiDQo+ID4gPGRicnVuZ2FyZEBhdHQuY29tPg0KPiA+IOaKhOmAgQ0KPiA+IDxtcGxzLXRw QGlldGYub3JnPg0KPiA+IOS4u+mimA0KPiA+IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRp cmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KPiA+IA0KPiA+IA0KPiA+IA0K PiA+IA0KPiA+IA0KPiA+IA0KPiA+IE9uIDIxLzA0LzIwMDkgMDI6NTksICJsaXUuZ3VvbWFuQHp0 ZS5jb20uY24iIDxsaXUuZ3VvbWFuQHp0ZS5jb20uY24+DQo+ID4gd3JvdGU6DQo+ID4gDQo+ID4+ IERlYm9yYWg6DQo+ID4+ICBtYXliZSB3aGF0IHlvdSBzYWlkIGlzIHJpZ2h0LiBidXQgSSBjYW4n dCBjb21wbGV0ZWx5IGFncmVlIHlvdXINCj4gPiBvcGluaW9ucy4NCj4gPj4gSU1PLiBtcGxzLXRw IGlzIHJlZ2FyZCBhcyB0cmFuc3BvcnQgbmV0d29yayBsaWtlIA0KPiBTREgvU09ORVQuIHNvIGl0 IHNob3VsZA0KPiA+PiBoYXZlIEFJUy9GREkgZnVjdGlvbnMgYXMgU0RIL1NPTkVULg0KPiA+PiAN Cj4gPj4gZG8geW91IHRoaW5rIHNvLg0KPiA+IA0KPiA+IE5vIHdlIG11c3QgYXNzZXNzIHRoZSBy ZXF1aXJlbWVudHMgZm9yIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MNCj4gPiBzdXBwb3J0aW5n DQo+ID4gdGhlIG5lZWRzIG9mIG9wZXJhdG9ycyB0b2RheSBhbmQgaW4gdGhlIGZ1dHVyZS4gV2Ug bXVzdCBub3QgYmxpbmRseQ0KPiA+IHJlY3JlYXRlDQo+ID4gU0RIL1NPTkVULiBJZiB3ZSBkbyBz byB3aXRob3V0IGNvbnNpZGVyYXRpb24gdG8gaG93IA0KPiBvcGVyYXRvcnMnIG5lZWRzIGFuZA0K PiA+IHJlcXVpcmVtZW50cyBtYXkgaGF2ZSBldm9sdmVkIChhbmQgY29udGludWUgdG8gZXZvbHZl IGluIA0KPiBmdXR1cmUpIHdlIHdpbGwNCj4gPiBoYXZlIGZhaWxlZCBJTU8gYW5kIEkgd291bGQg c2V2ZXJlbHkgcXVlc3Rpb24gdGhlIHZhbHVlIG9mIA0KPiB0aGUgd29yayB3ZQ0KPiA+IHdpbGwN Cj4gPiBoYXZlIHByb2R1Y2VkLiBJZiB3ZSBqdXN0IHJlY3JlYXRlIFNESC9TT05FVCB0aGVuIHdo YXQgaXMgDQo+IHRoZSBwdXJwb3NlIG9mDQo+ID4gdGhlDQo+ID4gd29yayBhbiBvcGVyYXRvciB3 b3VsZCBiZSBiZXR0ZXIgb2ZmIGp1c3QgZGVwbG95aW5nIA0KPiBleGlzdGluZyBTREgvU09ORVQN Cj4gPiBlcXVpcG1lbnQuDQo+ID4gDQo+ID4gDQo+ID4gQmVuDQo+ID4gDQo+ID4gDQo+ID4gDQo+ ID4gDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIA0KPiBpbiB0aGlzIG1haWwgaXMNCj4gPiBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIA0KPiBjb21tdW5p Y2F0aW9uIGlzDQo+ID4gY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gDQo+IG1haW50YWluIHNlY3JlY3kgYW5kIGFyZQ0KPiA+IG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgDQo+IGNvbW11bmljYXRpb24gdG8g b3RoZXJzLg0KPiA+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSANCj4gY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0KPiA+IHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IA0KPiBhcmUgYWRkcmVz c2VkLiBJZg0KPiA+IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgDQo+IG9yaWdpbmF0b3Igb2YgdGhlDQo+ID4gbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIA0KPiB0aGUgaW5kaXZpZHVh bA0KPiA+IHNlbmRlci4NCj4gPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgDQo+IEFudGktU3BhbSBzeXN0ZW0uDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzLXRwIG1haWxp bmcgbGlzdA0KPiBtcGxzLXRwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscy10cA0KPiANCg== From tnadeau@lucidvision.com Fri Apr 24 06:33:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0E33A6B04 for ; Fri, 24 Apr 2009 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA+lwuCZQcnW for ; Fri, 24 Apr 2009 06:33:40 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id D10CC3A6ACA for ; Fri, 24 Apr 2009 06:33:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 0AC8A3D4363B; Fri, 24 Apr 2009 09:34:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E1DmklNmf9T; Fri, 24 Apr 2009 09:34:56 -0400 (EDT) Received: from [10.10.1.97] (unknown [217.39.1.157]) by lucidvision.com (Postfix) with ESMTP id C774B3D4362D; Fri, 24 Apr 2009 09:34:55 -0400 (EDT) Message-Id: <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com> From: Thomas Nadeau To: Maarten Vissers In-Reply-To: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 14:34:53 +0100 References: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> X-Mailer: Apple Mail (2.930.3) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 13:33:41 -0000 Maartin, > Ben, > > Your company is one of the many operators in the world, and the =20 > number of > nodes outside your network is factors larger then the number of =20 > nodes inside > your network. My experience is that different operators have =20 > different sets > of requirements. Manufacturers have to support the superset of those > requirements. Each operator will then deploy the subset of provided =20= > features > that fits its needs (and turn off or don't use the others). Your =20 > company for > some years has been asking for less, other operators have been =20 > asking for > more. Manufacturers thus build their products with lots of =20 > configurability > to support all variations. Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? Unless our requirements are very different, I am confident vendors will build (or have built) their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features =20= > like > AIS, TCM, frame loss counting, delay measurement, loopback, etc =20 > before the > majority of operators have agreed that such features are not longer > necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me =20 recommend that you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they =20 want. Unless you think we don't know what we are talking about. Is this =20 perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On =20= > Behalf > Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: =20 > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their =20 > opinions and > no operator that I can see has disagreed with those opinions. > > I apologise for being direct (and possibly rude) but I am getting =20 > tired of > being told by folks who do not represent operators what =20 > functionality I need > or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service =20= > to 173 > countries with over 200 000 customer ports I have (off the top of my =20= > head) > at least another 10 MPLS networks in specific countries covering at =20= > least 3 > continents delivering dedicated services to particular market =20 > segments. > > I have an extremely large SDH network in the UK consisting of over =20 > 30 000 > switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in =20= > 110 > countries. > > I would like to think my BT colleagues and I might know a little =20 > something > about building large scale networks and the requirements of those =20 > networks > and the needs of the customers that I deliver services to. > > Can we please stop these circular arguments which are IMO going =20 > nowhere and > focus on the task in hand which is defining the requirements (and =20 > later > solutions) being asked for by myself, my company and my colleagues =20 > in other > operators on this list. > > Thanks > Ben > > > --=20 > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate =20 > Street London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" =20= > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must =20= >> not >> blindly recreate SDH/SONET. If we do so without consideration to how >> operators' needs and requirements may have evolved (and continue to >> evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated =20= >> to >> maintain secrecy and are not permitted to disclose the contents of =20= >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message =20= >> are >> those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From loa@pi.nu Fri Apr 24 07:48:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F4E28C0ED for ; Fri, 24 Apr 2009 07:48:31 -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_SE=0.35, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33quFfUE3dmO for ; Fri, 24 Apr 2009 07:48:30 -0700 (PDT) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 8B3793A69A2 for ; Fri, 24 Apr 2009 07:48:29 -0700 (PDT) Received: from [94.191.172.84] (94.191.172.84.bredband.tre.se [94.191.172.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 1EC742D8288; Fri, 24 Apr 2009 16:49:02 +0200 (CEST) Message-ID: <49F1D155.6070801@pi.nu> Date: Fri, 24 Apr 2009 16:48:53 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Thomas Nadeau References: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com> In-Reply-To: <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 14:48:31 -0000 All, I spent most of my years in the in the industry on the vendor side, but for four shiort years I was with an operator. I'd many opportunities to understand that people working for vendors very seldom are channeling operator requirements, but rather what they think the operator requirements should be. The Lesson learned is that it much better to speak with and listen to operators than trying to speak for them. /Loa Thomas Nadeau wrote: > > Maartin, > >> Ben, >> >> Your company is one of the many operators in the world, and the number of >> nodes outside your network is factors larger then the number of nodes >> inside >> your network. My experience is that different operators have different >> sets >> of requirements. Manufacturers have to support the superset of those >> requirements. Each operator will then deploy the subset of provided >> features >> that fits its needs (and turn off or don't use the others). Your >> company for >> some years has been asking for less, other operators have been asking for >> more. Manufacturers thus build their products with lots of >> configurability >> to support all variations. > > Do you see our (BT's) requirements to be very divergent from > those of other operators participating in this effort? Unless our > requirements are very different, I am confident vendors will build > (or have built) their devices based on our (sensible) requirements. > >> It is my opinion that we should not remove well established features like >> AIS, TCM, frame loss counting, delay measurement, loopback, etc before >> the >> majority of operators have agreed that such features are not longer >> necessary. > > Again, that is your opinion, which frankly seems to diverge > from what other operators have expressed. Furthermore, let me recommend > that > you get out of the habit of telling your customers (or potential ones), > what they require after they have been plainly clear about what they want. > Unless you think we don't know what we are talking about. Is this perhaps > the case? > > --Tom > > > > >> Regards, >> Maarten >> >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf >> Of Ben Niven-Jenkins >> Sent: vrijdag 24 april 2009 0:14 >> To: mpls-tp@ietf.org >> Subject: [mpls-tp] We appear to be going around in circles (Re: >> Associated >> bidirectional transport path requirements) >> >> Colleagues, >> >> The current debates appear to be going around in circles and achieving >> nothing of value IMO. Two major operators have expressed their >> opinions and >> no operator that I can see has disagreed with those opinions. >> >> I apologise for being direct (and possibly rude) but I am getting >> tired of >> being told by folks who do not represent operators what functionality >> I need >> or should have in my networks. >> >> To put some context on BT's comments in these threads: >> I have the largest MPLS network in the UK. >> I have one of the largest MPLS networks globally delivering service to >> 173 >> countries with over 200 000 customer ports I have (off the top of my >> head) >> at least another 10 MPLS networks in specific countries covering at >> least 3 >> continents delivering dedicated services to particular market segments. >> >> I have an extremely large SDH network in the UK consisting of over 30 000 >> switches and supporting in excess of 1 million circuits. >> I have an extremely large SDH network globally delivering service in 110 >> countries. >> >> I would like to think my BT colleagues and I might know a little >> something >> about building large scale networks and the requirements of those >> networks >> and the needs of the customers that I deliver services to. >> >> Can we please stop these circular arguments which are IMO going >> nowhere and >> focus on the task in hand which is defining the requirements (and later >> solutions) being asked for by myself, my company and my colleagues in >> other >> operators on this list. >> >> Thanks >> Ben >> >> >> -- >> >> Ben Niven-Jenkins >> IP, Data & Content Architect >> Network Infrastructure Architecture, BT >> >> E-mail: benjamin.niven-jenkins@bt.com >> Office: +44 (0)1473 648225 >> Mobile: +44 (0)7918 077205 >> Fax: +44 (0)1332 578827 >> >> British Telecommunications plc. Registered office: 81 Newgate Street >> London >> EC1A 7AJ Registered in England no: 1800000 >> >> >> On 23/04/2009 07:23, "liu.guoman@zte.com.cn" >> wrote: >> >>> ben: >>> I understand your meaning, you still wish to resign and make a more >>> reliable and effective, easy to operator and easy to manage packet >>> transport network like me. but why not apply this SDH/SONET in the >>> future maybe the following cause: >>> 1 it adopted circuit switching techonogy to bring lower useful of >>> the resource than PTN network; >>> 2 it can't bear all kinds of traffics like PTN networks it noted >>> that we can't apply SDH/SONET network in the future not because it >>> have a complex OAM functions. while more people like to move the >>> advantages of the OAM functions in SDH/SONET to PTN networks. and >>> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >>> use and extend the AIS/FDI functions to MPLS-TP ; >>> >>> best regards >>> liu >>> >>> >>> >>> Ben Niven-Jenkins >>> 2009-04-23 07:58 >>> >>> �� >>> , "BRUNGARD, DEBORAH A, ATTLABS" >>> >>> �� >>> >>> �� >>> Re: [mpls-tp] Associated bidirectional transport path requirements >>> >>> >>> >>> >>> >>> >>> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >>> wrote: >>> >>>> Deborah: >>>> maybe what you said is right. but I can't completely agree your >>> opinions. >>>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>>> should have AIS/FDI fuctions as SDH/SONET. >>>> >>>> do you think so. >>> >>> No we must assess the requirements for packet transport networks >>> supporting the needs of operators today and in the future. We must not >>> blindly recreate SDH/SONET. If we do so without consideration to how >>> operators' needs and requirements may have evolved (and continue to >>> evolve in future) we will have failed IMO and I would severely >>> question the value of the work we will have produced. If we just >>> recreate SDH/SONET then what is the purpose of the work an operator >>> would be better off just deploying existing SDH/SONET equipment. >>> >>> >>> Ben >>> >>> >>> >>> >>> >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained in this >>> mail is solely property of the sender's organization. This mail >>> communication is confidential. Recipients named above are obligated to >>> maintain secrecy and are not permitted to disclose the contents of this >> communication to others. >>> This email and any files transmitted with it are confidential and >>> intended solely for the use of the individual or entity to whom they >>> are addressed. If you have received this email in error please notify >>> the originator of the message. Any views expressed in this message are >>> those of the individual sender. >>> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From tnadeau@lucidvision.com Fri Apr 24 07:53:52 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBA63A69A2 for ; Fri, 24 Apr 2009 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzBu4ahhFdUV for ; Fri, 24 Apr 2009 07:53:51 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id B29D83A699C for ; Fri, 24 Apr 2009 07:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 5132D3D43BEA; Fri, 24 Apr 2009 10:55:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0Mrakj7xf3v; Fri, 24 Apr 2009 10:55:07 -0400 (EDT) Received: from [10.10.1.97] (unknown [217.39.1.157]) by lucidvision.com (Postfix) with ESMTP id 5BCC73D43BDF; Fri, 24 Apr 2009 10:55:06 -0400 (EDT) Message-Id: From: Thomas Nadeau To: Loa Andersson In-Reply-To: <49F1D155.6070801@pi.nu> Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 15:55:03 +0100 References: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com> <49F1D155.6070801@pi.nu> X-Mailer: Apple Mail (2.930.3) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 14:53:52 -0000 Well said. --Tom > All, > > I spent most of my years in the in the industry on the vendor side, =20= > but > for four shiort years I was with an operator. > > I'd many opportunities to understand that people working for vendors > very seldom are channeling operator requirements, but rather what > they think the operator requirements should be. > > The Lesson learned is that it much better to speak with and listen > to operators than trying to speak for them. > > /Loa > > Thomas Nadeau wrote: >> >> Maartin, >> >>> Ben, >>> >>> Your company is one of the many operators in the world, and the =20 >>> number of >>> nodes outside your network is factors larger then the number of =20 >>> nodes >>> inside >>> your network. My experience is that different operators have =20 >>> different >>> sets >>> of requirements. Manufacturers have to support the superset of those >>> requirements. Each operator will then deploy the subset of provided >>> features >>> that fits its needs (and turn off or don't use the others). Your >>> company for >>> some years has been asking for less, other operators have been =20 >>> asking for >>> more. Manufacturers thus build their products with lots of >>> configurability >>> to support all variations. >> >> Do you see our (BT's) requirements to be very divergent from >> those of other operators participating in this effort? Unless our >> requirements are very different, I am confident vendors will build >> (or have built) their devices based on our (sensible) requirements. >> >>> It is my opinion that we should not remove well established =20 >>> features like >>> AIS, TCM, frame loss counting, delay measurement, loopback, etc =20 >>> before >>> the >>> majority of operators have agreed that such features are not longer >>> necessary. >> >> Again, that is your opinion, which frankly seems to diverge >> from what other operators have expressed. Furthermore, let me =20 >> recommend >> that >> you get out of the habit of telling your customers (or potential =20 >> ones), >> what they require after they have been plainly clear about what =20 >> they want. >> Unless you think we don't know what we are talking about. Is this =20 >> perhaps >> the case? >> >> --Tom >> >> >> >> >>> Regards, >>> Maarten >>> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>> Behalf >>> Of Ben Niven-Jenkins >>> Sent: vrijdag 24 april 2009 0:14 >>> To: mpls-tp@ietf.org >>> Subject: [mpls-tp] We appear to be going around in circles (Re: >>> Associated >>> bidirectional transport path requirements) >>> >>> Colleagues, >>> >>> The current debates appear to be going around in circles and =20 >>> achieving >>> nothing of value IMO. Two major operators have expressed their >>> opinions and >>> no operator that I can see has disagreed with those opinions. >>> >>> I apologise for being direct (and possibly rude) but I am getting >>> tired of >>> being told by folks who do not represent operators what =20 >>> functionality >>> I need >>> or should have in my networks. >>> >>> To put some context on BT's comments in these threads: >>> I have the largest MPLS network in the UK. >>> I have one of the largest MPLS networks globally delivering =20 >>> service to >>> 173 >>> countries with over 200 000 customer ports I have (off the top of my >>> head) >>> at least another 10 MPLS networks in specific countries covering at >>> least 3 >>> continents delivering dedicated services to particular market =20 >>> segments. >>> >>> I have an extremely large SDH network in the UK consisting of over =20= >>> 30 000 >>> switches and supporting in excess of 1 million circuits. >>> I have an extremely large SDH network globally delivering service =20= >>> in 110 >>> countries. >>> >>> I would like to think my BT colleagues and I might know a little >>> something >>> about building large scale networks and the requirements of those >>> networks >>> and the needs of the customers that I deliver services to. >>> >>> Can we please stop these circular arguments which are IMO going >>> nowhere and >>> focus on the task in hand which is defining the requirements (and =20= >>> later >>> solutions) being asked for by myself, my company and my colleagues =20= >>> in >>> other >>> operators on this list. >>> >>> Thanks >>> Ben >>> >>> >>> --=20 >>> >>> Ben Niven-Jenkins >>> IP, Data & Content Architect >>> Network Infrastructure Architecture, BT >>> >>> E-mail: benjamin.niven-jenkins@bt.com >>> Office: +44 (0)1473 648225 >>> Mobile: +44 (0)7918 077205 >>> Fax: +44 (0)1332 578827 >>> >>> British Telecommunications plc. Registered office: 81 Newgate =20 >>> Street >>> London >>> EC1A 7AJ Registered in England no: 1800000 >>> >>> >>> On 23/04/2009 07:23, "liu.guoman@zte.com.cn" >>> wrote: >>> >>>> ben: >>>> I understand your meaning, you still wish to resign and make a more >>>> reliable and effective, easy to operator and easy to manage packet >>>> transport network like me. but why not apply this SDH/SONET in the >>>> future maybe the following cause: >>>> 1 it adopted circuit switching techonogy to bring lower useful of >>>> the resource than PTN network; >>>> 2 it can't bear all kinds of traffics like PTN networks it noted >>>> that we can't apply SDH/SONET network in the future not because it >>>> have a complex OAM functions. while more people like to move the >>>> advantages of the OAM functions in SDH/SONET to PTN networks. and >>>> AIS/FDI function is a kind of OAM functions of SDH/SONET . we =20 >>>> should >>>> use and extend the AIS/FDI functions to MPLS-TP ; >>>> >>>> best regards >>>> liu >>>> >>>> >>>> >>>> Ben Niven-Jenkins >>>> 2009-04-23 07:58 >>>> >>>> =CA=D5=BC=FE=C8=CB >>>> , "BRUNGARD, DEBORAH A, ATTLABS" >>>> >>>> =B3=AD=CB=CD >>>> >>>> =D6=F7=CC=E2 >>>> Re: [mpls-tp] Associated bidirectional transport path requirements >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" =20 >>>> >>>> wrote: >>>> >>>>> Deborah: >>>>> maybe what you said is right. but I can't completely agree your >>>> opinions. >>>>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>>>> should have AIS/FDI fuctions as SDH/SONET. >>>>> >>>>> do you think so. >>>> >>>> No we must assess the requirements for packet transport networks >>>> supporting the needs of operators today and in the future. We =20 >>>> must not >>>> blindly recreate SDH/SONET. If we do so without consideration to =20= >>>> how >>>> operators' needs and requirements may have evolved (and continue to >>>> evolve in future) we will have failed IMO and I would severely >>>> question the value of the work we will have produced. If we just >>>> recreate SDH/SONET then what is the purpose of the work an operator >>>> would be better off just deploying existing SDH/SONET equipment. >>>> >>>> >>>> Ben >>>> >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------- >>>> ZTE Information Security Notice: The information contained in this >>>> mail is solely property of the sender's organization. This mail >>>> communication is confidential. Recipients named above are =20 >>>> obligated to >>>> maintain secrecy and are not permitted to disclose the contents =20 >>>> of this >>> communication to others. >>>> This email and any files transmitted with it are confidential and >>>> intended solely for the use of the individual or entity to whom =20 >>>> they >>>> are addressed. If you have received this email in error please =20 >>>> notify >>>> the originator of the message. Any views expressed in this =20 >>>> message are >>>> those of the individual sender. >>>> This message has been scanned for viruses and Spam by ZTE Anti-Spam >>> system. >>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > > --=20 > > > Loa Andersson > > Sr Strategy and Standards Manager phone: +46 10 717 52 13 > Ericsson /// +46 767 72 92 13 > > > email: =20 > loa.andersson@ericsson.com > loa.andersson@redback.com > loa@pi.nu > > > From maarten.vissers@huawei.com Fri Apr 24 11:13:55 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468733A6B37 for ; Fri, 24 Apr 2009 11:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.956 X-Spam-Level: **** X-Spam-Status: No, score=4.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY2-SjmO3V9c for ; Fri, 24 Apr 2009 11:13:49 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C07153A6A24 for ; Fri, 24 Apr 2009 11:13:48 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIM00BU9AOWDN@szxga03-in.huawei.com> for mpls-tp@ietf.org; Sat, 25 Apr 2009 02:14:57 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIM00FY7AOWEB@szxga03-in.huawei.com> for mpls-tp@ietf.org; Sat, 25 Apr 2009 02:14:56 +0800 (CST) Received: from M00900002 (rrcs-24-43-176-142.west.biz.rr.com [24.43.176.142]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIM007D7AOJFK@szxml02-in.huawei.com>; Sat, 25 Apr 2009 02:14:56 +0800 (CST) Date: Fri, 24 Apr 2009 20:14:46 +0200 From: Maarten Vissers In-reply-to: To: andy.bd.reid@bt.com Message-id: <000a01c9c508$8f5bd420$1100000a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_5+z4iVSC7VTPxX15sUnR2A)" Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQg Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:13:55 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5+z4iVSC7VTPxX15sUnR2A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to = locate the misconfigured or failed connection function. Once this faulty = connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the performance = against the SLA for the connection. =20 Regards, Maarten _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin = domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server layer. = AIS suppresses the LOC alarm in those cases so that the maintenance guys = don't get triggered and start looking for a fault that is outside their area. =20 Regards, Maarten =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are concerned = with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* = the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you = think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even when AIS = was being received as the service guys want to know about the alarms. The = normal practice is for the equipment to report the alarms *including* AIS and = then a filter is applied in the management system to suppress alarms to the = fault fixing guys. As I'm aware, there are many different techniques applied = for the filtering algorithms, especially when you consider multiple = concurrent faults in a network, however, the existance of AIS/FDI doesn't add = anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And = if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up = simple time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation you describe is = only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to = fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, maybe = AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there = is no AIS/FDI functions, when there is a defects in a given layer network, = it can cause multiple alarm events to be raised. it is diffcult for = operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so I = think every new functions and things may have positive and negative effects. = but we should consider it very much, don't delete some functions at random.=20 best regards=20 liu=20 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Boundary_(ID_5+z4iVSC7VTPxX15sUnR2A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, AIS/FDI does give additional information. Let = me=20 explain: The need for AIS/FDI is a consequence of the = deployment of=20 loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The = objective=20 of such CCM OAM is to be able to detect a misconfiguration or fault of a = connection function (fabric) in the connection, which interrupts the = forwarding=20 of traffic in the connection. This is a fault condition that can only be = discovered by the layer network in which the connection is supported. It = requires that the organization responsible for the layer network takes = action=20 (i.e. locate the layer's connection function that includes the=20 fault) to restore the connection. Unfortunately, an interruption of one of = the link=20 connections of such connection (due to a fault in a server layer) will = also=20 interrupt the forwarding of traffic in the = connection. As such, loss of CC messages (LOC defect) does = not provide=20 sufficient information to determine if the configuration in the layer's=20 connection functions along the connection have to be checked and=20 corrected. AIS has been introduced and is used to help = differentiate=20 between the two fault cases. 1) if LOC and AIS are detected, then there is a = server=20 layer fault. This server layer fault is already reported by the server = layer MEP=20 detecting this fault. No action is required, so no alarm to=20 generate. 2) if LOC is detected and there is no AIS, then = there is a=20 layer network fault (i.e. continuity fault). Fault localization must be = started=20 to locate the misconfigured or failed connection function. Once this=20 faulty connection function is located, the configuration fault (or = hardware=20 fault) can be corrected, after which the connection is=20 retored. The interruption of the forwarding of traffic = in the=20 connection in both fault cases is however registered as part of = performance=20 monitoring. This performance monitoring information is used to verify = the=20 performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points I = made. My point=20 is that AIS/FDI gives no information above what is already known - it is = only=20 adds complexity and fault liability. Neither of your points change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 Newgate = Street=20 London EC1A 7AJ Registered in England no. 1800000 = This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009=20 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of alarm = suppression in=20 the data plane - that information is readily=20 available. I don't = believe that this=20 is a correct statement in a multi-operator transport network, or in = transport=20 networks of one operator that have more then one administrative = subdomain=20 (each with its own network management system). A problem occuring in = admin=20 domain A will be unknown in admin domain B. The loss of continuaity = alarms=20 that are activated in admin domain B due to the fault in admin domain = A will=20 appear as primary alarms, suggesting connectivity problems in admin = domain=20 B. > The issue=20 arises because the two sides of maintenance want different things. The = fault=20 fixing > guys=20 want to locate the fault and don't want any other information. The = service=20 maintenance > guys=20 want to know whether their customer service is=20 working. This=20 is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means = of the=20 additional SSF alarm. The SSF alarm is for the service guys = telling them=20 that the service was interrupted due to a fault in a server layer. AIS = suppresses the LOC alarm in those cases so that the maintenance guys = don't get=20 triggered and start looking for a fault that is outside their=20 area. Regards, Maarten From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two things=20 which are separate and for which AIS/FDI is no help. Maintenance = operations=20 are concerned with two separate things. 1) Identifying faults in equipment, = line plant, and=20 other systems (eg misconfigurations) and fixing them (equipment=20 maintenance). 2) Identifying the health of end to end = connections, especially when they are directly supporting customer = services=20 (service maintenance). The problem is *not* about a lack of alarm = suppression in=20 the data plane - that information is readily available. If, at an end=20 equipment, I have a good server/section layer and a loss of CC at the = client=20 layer, I *know* the fault is elsewhere - I don't need AIS/FDI to tell = me.=20 (Indeed, if you think about, if the fault is in the end equipment, it = is quite=20 likely that the fault means it cannot report the traffic loss to the=20 management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the fault = and=20 don't want any other information. The service maintenance guys want to = know=20 whether their customer service is working. This arose in the early days of SONET/SDH, = when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know about=20 the alarms. The normal practice is for the equipment to report = the alarms=20 *including* AIS and then a filter is applied in the management = system to=20 suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you=20 consider multiple concurrent faults in a network, however, the = existance of=20 AIS/FDI doesn't add anything to these that's not already known. In = fact, I=20 believe simple time-stamp correlation is one of the most powerful = and=20 widely used techniques. And if the equipment starts messing up the = reporting=20 of loss of CC because it waiting for/persistence = checking AIS/FDI, it=20 could end up messing up simple time-stamp=20 correlation! In practice, it is often not quite a simple = as this, as=20 the service guys like to be able to 'localise' the fault. However, = under most=20 circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter hasn't = worked=20 for some reason. But the bottom line is, whatever operations = process you=20 want to use, AIS/FDI doesn't add anything other than complexity = and fault=20 liability to the equipment. Remember AIS goes back to the TDM = world where=20 you *have to fill the bit stream with something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009 = 09:15 To:=20 Harrison,N,Neil,CXM R Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Neil: = thank you for wasting more time in = describling=20 the problems. but I think some of what you said is no relations with = our=20 problem.for me, maybe AIS/FDI functions is no sense in cl-ps ,eg. = IP. but=20 for CO-PS networks.if there is no AIS/FDI functions, when there is a = defects=20 in a given layer network, it can cause multiple alarm events to be = raised.=20 it is diffcult for operators to locate and diagnose the = faults.=20 though I completely agree = you on=20 adding new things and functions will bring some complexity . = but if we=20 have no functions, it is more complex and difcult for operators to = maintence=20 and administrator the network. so I think every new functions and = things may=20 have positive and negative effects. but we should consider it very = much,=20 don't delete some functions at random. best regards liu <neil.2.harrison@bt.com> 2009-04-21 20:30 = =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If=20 MPLS-TP is going to be taken seriously as a transport network (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are these. = 1=20 Provide a transparent client/server = relationship...which=20 means: - =20 all client bits treated equally - client bit ordering = preserved=20 - = no=20 attempt to infer client symbol (ie sequence of client bits) meaning = and no=20 attempt to change client symbols - the traffic behaviour of = client X must=20 not impact the performance experienced by client Y A=20 key corollary of the above is that MPLS-TP must only support proper=20 connections (ie single source constructs) 2 Since = MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does not = support=20 directly external message/file/stream applications). MPLS-TP = therefore=20 does not require an E-NNI specification. A key corollary of = this is=20 that MPLS-TP will not have any peer interworking relationship with = any other=20 network mode/technology. = Now=20 wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should=20 have FDI/AIS....however, the merit of this is highly questionable.=20 When I and colleagues discussed whether PBB-TE (also a co-ps = mode=20 network) should have FDI/AIS we concluded that on balance it was not = a good=20 idea.....and note that initially I was in favour of having AIS, but = my=20 colleagues provided strong technical arguments that convinced me=20 otherwise. AIS/FDI is = historically linked to=20 the early PDH co-cs mode layer networks that used TTL logic. = When this=20 died it put out a +5V (all 1s) signal by default, ie it required no=20 conscious effort to generate it.....this is key point. = Further, in=20 these networks there is a fairly static/long-holding client server=20 relationship. Clearly this is not true in the cl-ps mode and = it's why=20 IETF have never specified AIS for IP and its why IEEE had the good = sense to=20 throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO = retained=20 it in Y.1731....but I suspect any operator planning to use Ethernet=20 equipment would always look to IEEE stds and not ITU ones). = AIS/FDI and the co-ps mode is debatable. As I noted = above, on=20 balance we considered not a good idea for PBB-TE OAM because it = requires a=20 conscious effort to generate it (unlike the co-cs mode) so there are = likely=20 to be scaling problems and its one more thing to go wrong. = You=20 should also have seen me make the point many times in the past that = the=20 always-on defect detection/handling OAM needs to be as simple/sparse = as=20 possible with as little config as possible because we need super=20 reliability......TCM goes completely against the grain here. = Also note=20 that the OAM required for each of the 3 network modes is not the = same,=20 despite what some claim. = regards, Neil = From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009 = 02:59 To:=20 BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Deborah: maybe what you = said is=20 right. but I can't completely agree your opinions. IMO. mpls-tp is = regard as=20 transport network like SDH/SONET. so it should have AIS/FDI fuctions = as=20 SDH/SONET. do you think so. best regards = liu "BRUNGARD, = DEBORAH A,=20 ATTLABS" <dbrungard@att.com> =B7=A2=BC=FE=C8=CB: = mpls-tp-bounces@ietf.org 2009-04-20 = 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with Neil, it = is very=20 questionable the value of AIS/FDI in a packet network- any mode. = It can=20 result in a DoS attack by an operator on themselves so even Y1731 = recommends not to block data frames: "A MEP can decide whether it = blocks=20 data frames when it detects dAIS. The principle = requirement that=20 influences this decision is that data frames ought to be = forwarded as=20 much as possible, without the possibility of forwarding wrong = data frames=20 downstream." Table I.7-2 shows for AIS, not to block. And = as Y1731=20 states, AIS can only be used under very constrained architectures = - if=20 required for MPLS-TP, it needs to have the same guidance as in = Y1731,=20 i.e. point-to-point and server/client one-to-one: "for a = point-to-point=20 ETH connection, a MEP has only a single peer MEP. Therefore, = there is=20 no ambiguity regarding the peer MEP for which it should = suppress alarms=20 when it receives the ETH-AIS information." So should only be = within=20 one domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten = Vissers Sent:=20 Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional=20 transport path requirements Neil, > but AIS/FDI = in the=20 cl mode?...do me a favour! Ethernet AIS is indeed a = requirement and a=20 necessity. And you will not be able to understand that as long = as you=20 refuse to accept that "cl-mode" is a forwarding mode within a=20 **transport entity**. G.800 amendment 1 = has finally reintroduced this=20 transport entity into G.800. Besides that, it also introduced the = **differentiated connection**: [G.800 am1] "A differentiated=20 connection is a transport entity that transfers information = belonging to=20 multiple communications between ports across a subnetwork. = <..> In=20 a differentiated connection message contents are interpreted = to=20 identify (sets of) communications which = receive different treatment.=20 The sets of communications may be distinguished by = the forwarding=20 identifier or other layer information. Order is=20 not necessarily preserved between messages belonging to sets = of=20 communications receiving different treatment. Sets of=20 communications may be identified for purposes such as traffic=20 conditioning or preserving communication message = order." Ethernet=20 VLANs are in terms of G.800 "differentiated = connections". Ethernet AIS=20 provides AIS within the scope of such "differentiated=20 connection". If you apply this to my proposed PTN layer stack, = then=20 the EVC layer topology will consists of EVC links supported by = MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and = core=20 domains interconnecting EVC matrices. When one of those EVC = links is=20 interrupted, e.g. in the core between metro 1 and metro 4 (see = attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS is = inserted=20 in the downstream direction to suppress the EVC-LOC alarms at EVC = endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) = frame has=20 a reserved multicast address, which guarantees that the AIS is = broadcast=20 to the endpoints of the EVC. I believe that it is time for = you to=20 adapt your view on co and cl modes and relate it to the = forwarding=20 mode **INSIDE** a transport entity. What we know as the = internet is=20 essentially an "IP differentiated connection" with a billion or = more=20 ports. What we know as an IP VPN is essentially an "IP=20 differentiated connection" with e.g. n ports (n in the range = of e.g. 2=20 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in the = range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially = an "MPLS=20 differentiated connection" with 2 ports. What we know as a p2p = SDH=20 VC-n is a "SDH VC-n connection" with 2 ports. Transport = network OAM=20 applies to transport entities, which are (in terms of G.800 = am1)=20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com = [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: = John.E.Drake2@boeing.com;=20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp]=20 Associated bidirectional transport path requirements John, = Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am getting a = wee bit=20 tired of folks trying to make all 3 network modes look alike = (and=20 then, even worse, interwork them as as peers...esp when not = not=20 top-of-stack networks...I mean how silly can we get?). I = am even=20 more frustrated by the fact those peddling this FUD only ever = seem to=20 consider OAM and forget all other DP/CP/MP components (esp=20 top-of-stack message/file/stream application adaptations). = How=20 wrong can this get! In the co modes a *connection* is a very = specific and *constraining* construct.....I am assuming here we = respect=20 the rules of a connection (ie single source) though some folks = don't=20 even bother to respect this, and this is despite the fact that = we all=20 know what problems multiple-source constructs can cause (from=20 LDP/PHP....ergo MPLS-TP). When we have a connection this = restricts=20 *all* DP (ie traffic and OAM) to stay within the bounds of the = connection. Which is fine under defect-free conditions, = but if=20 we have leaking traffic then the constraining nature of the = connection=20 construct is broken. In a nutshell what this means = is that OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity defects.....indeed, why = should a=20 leaking DP have a symmetric go/return defect = behaviour?....very likely=20 it won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and not = just in=20 OAM requirements....but AIS/FDI in the cl mode?...do me a = favour!...at=20 least IEEE had the good sense to bin this for Ethernet even = though it=20 remains in Y.1731. And which is why I often trot-out the = rather=20 silly (to have to say this) observation that if IP (cl mode) = could do=20 it all then why have IETF found it necessary to create MPLS = (co-ps)=20 and GMPLS (CP for co-cs). The answer lies in the = physics...and=20 G.800 attempts to explain that physics....G.805 does = not. So, the=20 3 modes are different...please accept/rejoice in this fact = as they all=20 offer something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the OAM of = the 3=20 modes the same. regards, Neil > -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > = Sent:=20 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; = Maarten=20 Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > = requirements >=20 > Italo, > > As described in the MPLS TP OAM=20 Requirements I-D, virtually all of the > OAM functions = require a=20 return path, and in the absence of a return > path they are=20 disabled. > > As described in David Sinicrope's meeting = minutes=20 >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP = addressing=20 is used, an > MPLS TP network needs to be capable of getting = IP=20 packets from > destination to source; neither the minutes nor = I=20 stipulate that a > control plane needs to be used to = instantiate this=20 forwarding. > > As an aside, the issue of return path = for=20 unidirectional LSPs could be > charaterized as the = elephant in the=20 room. In the MPLS TP OAM > Framework I-D, unicast LSPs = are only=20 mentioned three times and return > paths not at all. > = >=20 Thanks, > > John > > -----Original=20 Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April 17,=20 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; = Maarten=20 Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE:=20 [mpls-tp] Associated bidirectional transport path > >=20 requirements > > > > John, > > > = > I=20 might have missed the agreement of MPLS-TP being capable of > = >=20 sending replies to OAM requests sent on uni-directional = LSPs. > >=20 > > This requirement does not belong to the first set of=20 requirements > > ITU-T is expecting to be met by = October. >=20 > > > However, I think this in a potential interesting=20 additional > > requirement to be taken into account (at = worst in=20 a > subsequent phase). > > > > I think that = this=20 requirement needs to be evaluated versus other > > more = important=20 requirements (e.g. the possibility to work w/o IP > > = forwarding=20 and the need for OAM to continue to monitor the data > > = plane=20 also in case of failures affecting the control or management = > >=20 plane). > > > > I am open to discuss it but not = sure this=20 is the right time because > > I wish to avoid delaying the = first=20 phase of the design solution. > > > > Thanks,=20 Italo > > > > > -----Original = Message----- >=20 > > From: mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > = >=20 > Sent: Thursday, April 16, 2009 8:00 PM > > > To: = Alexander=20 Vainshtein; Maarten Vissers > > > Cc: = mpls-tp@ietf.org >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > requirements > > > > > > = At the=20 meeting last fall at Juniper in Massachusetts, I > > think = it=20 was > > > agreed that an MPLS TP network needs to have a = forwarding > > capability > > > for management, = control, and OAM packets (e.g., sending > > replies to = OAM >=20 > > requests sent on uni-directional LSPs) even if it does = not >=20 > have an IP > > > forwarding data plane. > = > >=20 > > > > -----Original Message----- > > > = >=20 From: Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = > >=20 > > requirements > > > > > > > = >=20 Maarten, > > > > It seems that you've just = (implicitly and,=20 probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will not = ever=20 support MIP loopback function > > (and fault > > = > >=20 localization which requires this function ) for > > = unidirectional=20 P2MP > > > > and P2P paths. > > > > = >=20 > > > If this statement is correct, this (IMHO and = FWIW) >=20 raises a valid > > > > question: > > > = >=20 > > > > = =20 Is MPLS-TP an appropriate solution for these > = types of=20 transport > > > > paths? > > > > = > >=20 > > For the reference, IP/MPLS provides this kind of > = >=20 functionality today > > > > for (unidirectional - but = it does=20 not know any other > > type) P2P LSPs > > > = > as=20 described in RFC 4379. And its extension to P2MP LSPs seems > = >=20 > > easy... > > > > > > > >=20 > > > > > > > > = Regards, > >=20 > > > > > > Sasha > = >=20 > > > > > > > > > > > = > >=20 > ________________________________________ > > > > = From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: Thursday, = April=20 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > = >=20 > > Cc: mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > = Adrian, >=20 > > > > > > > >> = <quote> > >=20 > > >> The intermediate nodes = (including=20 MEPs, MIPs and > > > > other internal > > = > >=20 >> functions as appropriate) of a=20 co-routed > > > > bidirectional transport > = > >=20 > >> path at each (sub-)layer MUST be = aware of=20 the pairing > > > > >> =20 relationship of the forward and the backward > > > >=20 directions of that > > > > >> = =20 transport path. > > > > >> <end = quote> >=20 > > > > > > > > > There is no way this = is a=20 functional requirement. That > > > is, there is > = >=20 > > > *nothing* that can be observed from a black box point = of > > > view that > > > > > results = from=20 adhering to this requirement. > > > > > > = > >=20 Your understanding is not correct. It is very much > = observable=20 if > > > > this requirement is met from a black box = point of=20 view. > > > > The MIP functions can only perform the = Loopback=20 when there is a > > > > co-routed bidirectional = transport=20 path. The MPLS-TP LBM packet > > > > received at a = MIP needs=20 to be returned (as LBR > > > > packet) to the = originating MEP=20 function via the other > > direction of > > > = > the=20 co-routed bidirectional transport path. This other > = direction >=20 > > > would not be available in an associated bidirectional = transport > > > > path... and thus the loopback = test >=20 > > would fail. > > > > > > > > = Similarly, when we have to apply TCM MEPs to monitor a > > = segment,=20 then > > > > this is possible in a co-routed bidir = transport=20 path > but not in a > > > > associated bidir = transport=20 path. In the first case the TCM MEP > > > > Source = and Sink=20 functions are co-located and can > exchange what is > = > >=20 > called "remote information" which is necessary for performance = >=20 > > > monitoring. > > > > In the latter case = the TCM=20 MEP Source and Sink functions > > are in e.g. > > = >=20 > different nodes in the network and TCM would not be = able > >=20 to provide > > > > performance monitoring. > = > >=20 > > > > > > The entirety of the bracketted = text=20 "(including MEPs, > > > MIPs and other > > > = >=20 internal > > > > > functions as appropriate)" = should be=20 deleted. It does not > > > > add to "The > > = >=20 > > intermediate nodes." > > > > > > = >=20 > Your understanding is not correct. This text must not = be > >=20 deleted at > > > > all. > > > > = > >=20 > > > Actually, I am quite fed up about this = persistent >=20 > > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > > = is >=20 > > > poorly > > > > > specified and = comes from=20 the monitoring of a path that is > > > > parallel=20 (i.e. > > > > tandem) > > > > > to = the data=20 path being monitored. This definition of TC > > > > = seems to=20 be at > > > > variance, > > > > > = and would=20 be if the ACH was actually in band. > > > > > = >=20 > > I don't understand where your interpretation of = tandem >=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of a > = >=20 > > path that is parallel (i.e. tandem) to the data path being = > > > > monitored."? > > > > > = >=20 > > There is a "network connection" and this network > = >=20 connection is a set > > > > of interconnected "link=20 connections" and "matrix > connections". A > > > = >=20 subset of those interconnected link connections and matrix > = >=20 > > connections can be monitored and is then referred to = as > a=20 "tandem > > > > connection". There is no "path that = is=20 parallel to the > > data path". > > > > = There is=20 only additional OAM inserted inside the data > path by = the >=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM MEP_Sk=20 function. > > > > > > > > = Regards, >=20 > > > Maarten > > > > > > > = >=20 > > > > -----Original Message----- > > > = >=20 From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > = >=20 > > Sent: donderdag 16 april 2009 11:59 > > > > = To:=20 Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > >=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp] Associated bidirectional transport path > > > = >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > = Unfortunately I=20 cannot fully agree with your statement: > > > > = > >=20 > > > > <quote> > > > > > = =20 From the point of view of hardware, co-routed > > >=20 bidirectional LSPs > > > > > are a = special=20 case of associated bidirectional LSPs. > > > > > = <end=20 quote> > > > > > > > > > > = This=20 statement would be obviously correct, were it not for > > = > >=20 Requirement > > > > > 34 in the latest MPLS-TP=20 requirements draft > > > > > > > > = OK. Got=20 it. > > > > > > > > But what is this = doing in=20 the data plane requirements section? > > > > > = >=20 > > In fact, what is this requirement actually saying? > = >=20 > > > > > > > <quote> > > = > >=20 > The intermediate nodes (including MEPs, = MIPs=20 and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > > = >=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the pairing > = >=20 > > > relationship of the forward and = the=20 backward > > > > directions of that > > > = >=20 > transport path. > > > > = >=20 <end quote> > > > > > > > > = There is no=20 way this is a functional requirement. That > > is, there = is >=20 > > > *nothing* that can be observed from a black box point = of > > view that > > > > results from = adhering to=20 this requirement. > > > > > > > > = Therefore=20 it could be assumed that this requirement is met by > > = > >=20 configuring some data plane database component through the > = >=20 > > management plane. The database component is not = used > for=20 anything > > > > except to satisfy this requirement = for=20 "awareness". > > > > > > > > Ben! Can = we=20 please try to rewrite this requirement in terms of > > = > >=20 behavior? > > > > > > > > > Please = note=20 that Requirement 34 is the ONLY item in the > > > > = list that=20 is > > > > > specific for co-routed bidirectional = LSPs.=20 (The pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = > >=20 paths are > > > > > exactly the same even if they = appear=20 in two different > > > items in the > > > = > >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > = > >=20 bidirectional paths would be void of any data plane content. > = >=20 > > > > > > > > The somewhat vague scope = of this=20 requirement ("other internal > > > > > functions = as=20 appropriate") creates a suspicion that HW > > > > = support of=20 the > > > > > pairing awareness may be required in = order=20 to comply with it. > > > > > > > > = The=20 entirety of the bracketted text "(including MEPs, > > MIPs = and=20 other > > > > internal functions as appropriate)" = should be=20 deleted. It > > does not > > > > add to "The = intermediate nodes." > > > > > > > > = > The=20 following text in the draft increases this suspicion: > > = > >=20 > > > > > > <quote> > > > = > >=20 Tandem Connection: A tandem connection is an > > = arbitrary=20 part of a > > > > > transport path that can = be=20 monitored (via OAM) > > > > independently from = the >=20 > > > > end-to-end monitoring (OAM). It may = be a=20 monitored > > segment or a > > > > > = =20 monitored concatenated segment of a transport path. > = > The=20 tandem > > > > > connection may also = include the=20 forwarding engine(s) of > > > > the node(s) > = > >=20 > > at the edge(s) of the segment or concatenated=20 segment. > > > > > <end quote> > > = >=20 > > > > > Actually, I am quite fed up about this=20 persistent > > insistence on the > > > > = inclusion=20 of "Tandem Connection." The definition within > > the ITU-T = of > > > > this term is poorly specified and comes = from=20 the > monitoring of a > > > > path that is = parallel=20 (i.e. tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > > = >=20 > > > > > Doesn't "forwarding engine" sound like = hardware=20 to you? > > > > > > > > Yes, but so=20 what? > > > > > > > > > IMHO it is = worth=20 noting that neither the MPLS-TP > > > Requirements = draft >=20 > > > > nor the MPLS-TP OAM requirements one > = > >=20 > > > > > > > > > > > = >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing with = tandem > > > connections. > > > > = > >=20 > > > > But tandem connections are discussed in the = MPLS-TP=20 OAM > > Framework > > > > > draft > = >=20 > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > = >=20 > > amework-00.txt > > > > ). > > > = >=20 > > > > Right. > > > > Let's just get = rid of=20 an unnecessary term and bring all > the I-Ds > > > = >=20 into line. > > > > > > > > > The = bottom=20 line, IMHO, is that some clarity regarding > > > = co-routed=20 vs. > > > > > associated > > > > = >=20 bidirectional paths is still required. One way to provide > = > >=20 > that could > > > > > be by explicitly = limiting=20 Requirement 34 to specific > > > functionality. > = >=20 > > > > > > Agreed. > > > > = >=20 > > > Adrian > > > > > > > > = > > > > > > > > > > > = >=20 ________________________________________ > > > > = From: Adrian=20 Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, = April=20 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; = Lou=20 Berger; BUSI ITALO > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > > = >=20 > > Hi Sasha, > > > > > > > > = Not=20 really sure whether you are misrepresenting anyone, but... > = > >=20 > > > > > > 1. My reading of one of = Ben's=20 messages is that associated > > > > > = bidirectional=20 paths are the only types of paths that can be > > > > = created=20 in > > > > > the existing networks; "true" = co-routed=20 bidirectional paths > > > > will have > > = > >=20 > to wait until (if ever) new equipment becomes = available. > >=20 > > > > > > This is clearly nonsense! > = >=20 > > From the point of view of hardware, co-routed > > = bidirectional LSPs are > > > > a special case of = associated=20 bidirectional LSPs. > > > > > > > > = If you=20 can set up two unidirectional LSPs (e.g. using the > >=20 management > > > > plane) you can surely set up a=20 co-routed > > > bidirectional LSP. > > > = >=20 > > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > > > LSPs using = the=20 control plane. These either use the GMPLS > > (which = is >=20 > > > cleaner) or non-standard proprietary solutions (which = is > > messy but > > > > = functional). > >=20 > > > > > > But (of course) the management = plane or=20 control plane > > solutions have > > > > = nothing to=20 do with availability of equipment as they > are software > > > > = solutions. > >=20 > > > > > > > 2. My reading of one of = Neil's=20 messages is that the actual > > > > driver = for > >=20 > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any = specific=20 benefit. > > > > > > > > Isn't that = the case=20 with 75% of the MPLS-TP requirements? > > > > Which = is not to=20 say it is a bad thing. > > > > > > > = > A=20 large driver for MPLS-TP is to give the packet network > > = the=20 look, > > > > feel, and behavioral characteristics of = a=20 "legacy" > > > > transport network. > > > = >=20 > > > > > Based on these observations, I'd guess = (FWIW)=20 that: > > > > > * associated bidirectional paths = are, at=20 least for the time > > > > > being, = the most=20 important type of bidirectional paths in > > > > > = =20 MPLS-TP > > > > > > > > I think = that is=20 wrong both given my statement above, and > > given = that >=20 > > > other upgrades to existing MPLS solutions will = be >=20 needed to reach > > > > the full function level of=20 MPLS-TP. > > > > > > > > > * they = had a=20 good chance to remain the only type of > > = bidirectional >=20 > > > > paths in real deployments. > = >=20 > > > > > > I don't see what that follows=20 from. > > > > > > > > Cheers, > = >=20 > > Adrian > > > > > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > = >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > mpls-tp@ietf.org > = >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = >=20 > > = _______________________________________________ >=20 mpls-tp mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this mail = is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy and=20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify = the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender. This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. --Boundary_(ID_5+z4iVSC7VTPxX15sUnR2A)-- From amalis@gmail.com Fri Apr 24 15:27:34 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41C23A67EB for ; Fri, 24 Apr 2009 15:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-1.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHQXq8kq6iff for ; Fri, 24 Apr 2009 15:27:33 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id A673F3A6B79 for ; Fri, 24 Apr 2009 15:27:30 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1437735qwe.31 for ; Fri, 24 Apr 2009 15:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=nIXxownd7DWy8T/TIm1iO1EQ0DKMPqPoPoNSphX2ZrE=; b=ZYb+j2T+Ahwt+mWZg1viACVNitW9RLdwnrAb6MuuVHxdI0MQL1lM4BcwdIkXiWCog/ ICN8yNSyP2b8X+lzTkOMfQOGIjrxoThdN+CsOBuJ7nNrK8Tpz5jzh5v6A5OHCBKP765O 5VuRVHuBBzHnOyXr42l7gFJRtGmVxw7PKzKZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=c8PgkVeAIPCFB6YzfsIECJ+YMn27iQok+6Yjf3Yf8n5XKGmGW1mXv0MIBQTFHmlw0q a4b2CbCFkT1ZwkbYbZWKo3eayxRjh7W/+C/pfl8N0n3MxmlMI7aModFESo/8/4l9SzQ0 Pwbokr9GoFRhiZo+fyC56UzWdB7IYe+t5aqJA= MIME-Version: 1.0 Received: by 10.224.28.129 with SMTP id m1mr3630144qac.85.1240612129128; Fri, 24 Apr 2009 15:28:49 -0700 (PDT) In-Reply-To: References: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com> <49F1D155.6070801@pi.nu> From: "Andrew G. Malis" Date: Fri, 24 Apr 2009 18:28:34 -0400 Message-ID: To: Thomas Nadeau Content-Type: multipart/alternative; boundary=0015175cb21e42c26804685485c2 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 22:27:34 -0000 --0015175cb21e42c26804685485c2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I've been holding off commenting specifically on the need for AIS until I have a chance to consult with my transport experts. Unfortunately, they wer= e all at the OIF meeting this past week. However, I can report that when we previously reviewed the requirements draft, they indicated at that time tha= t they would prefer MPLS-TP OAM to resemble SONET/SDH OAM due to our embedded management systems and operator expertise. I hope to be able to report back soon on further internal discussions. Cheers, Andy 2009/4/24 Thomas Nadeau > > Well said. > > --Tom > > > All, >> >> I spent most of my years in the in the industry on the vendor side, but >> for four shiort years I was with an operator. >> >> I'd many opportunities to understand that people working for vendors >> very seldom are channeling operator requirements, but rather what >> they think the operator requirements should be. >> >> The Lesson learned is that it much better to speak with and listen >> to operators than trying to speak for them. >> >> /Loa >> >> Thomas Nadeau wrote: >> >>> >>> Maartin, >>> >>> Ben, >>>> >>>> Your company is one of the many operators in the world, and the number >>>> of >>>> nodes outside your network is factors larger then the number of nodes >>>> inside >>>> your network. My experience is that different operators have different >>>> sets >>>> of requirements. Manufacturers have to support the superset of those >>>> requirements. Each operator will then deploy the subset of provided >>>> features >>>> that fits its needs (and turn off or don't use the others). Your >>>> company for >>>> some years has been asking for less, other operators have been asking >>>> for >>>> more. Manufacturers thus build their products with lots of >>>> configurability >>>> to support all variations. >>>> >>> >>> Do you see our (BT's) requirements to be very divergent from >>> those of other operators participating in this effort? Unless our >>> requirements are very different, I am confident vendors will build >>> (or have built) their devices based on our (sensible) requirements. >>> >>> It is my opinion that we should not remove well established features >>>> like >>>> AIS, TCM, frame loss counting, delay measurement, loopback, etc before >>>> the >>>> majority of operators have agreed that such features are not longer >>>> necessary. >>>> >>> >>> Again, that is your opinion, which frankly seems to diverge >>> from what other operators have expressed. Furthermore, let me recommend >>> that >>> you get out of the habit of telling your customers (or potential ones), >>> what they require after they have been plainly clear about what they >>> want. >>> Unless you think we don't know what we are talking about. Is this perha= ps >>> the case? >>> >>> --Tom >>> >>> >>> >>> >>> Regards, >>>> Maarten >>>> >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>>> Behalf >>>> Of Ben Niven-Jenkins >>>> Sent: vrijdag 24 april 2009 0:14 >>>> To: mpls-tp@ietf.org >>>> Subject: [mpls-tp] We appear to be going around in circles (Re: >>>> Associated >>>> bidirectional transport path requirements) >>>> >>>> Colleagues, >>>> >>>> The current debates appear to be going around in circles and achieving >>>> nothing of value IMO. Two major operators have expressed their >>>> opinions and >>>> no operator that I can see has disagreed with those opinions. >>>> >>>> I apologise for being direct (and possibly rude) but I am getting >>>> tired of >>>> being told by folks who do not represent operators what functionality >>>> I need >>>> or should have in my networks. >>>> >>>> To put some context on BT's comments in these threads: >>>> I have the largest MPLS network in the UK. >>>> I have one of the largest MPLS networks globally delivering service to >>>> 173 >>>> countries with over 200 000 customer ports I have (off the top of my >>>> head) >>>> at least another 10 MPLS networks in specific countries covering at >>>> least 3 >>>> continents delivering dedicated services to particular market segments= . >>>> >>>> I have an extremely large SDH network in the UK consisting of over 30 >>>> 000 >>>> switches and supporting in excess of 1 million circuits. >>>> I have an extremely large SDH network globally delivering service in 1= 10 >>>> countries. >>>> >>>> I would like to think my BT colleagues and I might know a little >>>> something >>>> about building large scale networks and the requirements of those >>>> networks >>>> and the needs of the customers that I deliver services to. >>>> >>>> Can we please stop these circular arguments which are IMO going >>>> nowhere and >>>> focus on the task in hand which is defining the requirements (and late= r >>>> solutions) being asked for by myself, my company and my colleagues in >>>> other >>>> operators on this list. >>>> >>>> Thanks >>>> Ben >>>> >>>> >>>> -- >>>> >>>> Ben Niven-Jenkins >>>> IP, Data & Content Architect >>>> Network Infrastructure Architecture, BT >>>> >>>> E-mail: benjamin.niven-jenkins@bt.com >>>> Office: +44 (0)1473 648225 >>>> Mobile: +44 (0)7918 077205 >>>> Fax: +44 (0)1332 578827 >>>> >>>> British Telecommunications plc. Registered office: 81 Newgate Street >>>> London >>>> EC1A 7AJ Registered in England no: 1800000 >>>> >>>> >>>> On 23/04/2009 07:23, "liu.guoman@zte.com.cn" >>>> wrote: >>>> >>>> ben: >>>>> I understand your meaning, you still wish to resign and make a more >>>>> reliable and effective, easy to operator and easy to manage packet >>>>> transport network like me. but why not apply this SDH/SONET in the >>>>> future maybe the following cause: >>>>> 1 it adopted circuit switching techonogy to bring lower useful of >>>>> the resource than PTN network; >>>>> 2 it can't bear all kinds of traffics like PTN networks it noted >>>>> that we can't apply SDH/SONET network in the future not because it >>>>> have a complex OAM functions. while more people like to move the >>>>> advantages of the OAM functions in SDH/SONET to PTN networks. and >>>>> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >>>>> use and extend the AIS/FDI functions to MPLS-TP ; >>>>> >>>>> best regards >>>>> liu >>>>> >>>>> >>>>> >>>>> Ben Niven-Jenkins >>>>> 2009-04-23 07:58 >>>>> >>>>> =CA=D5=BC=FE=C8=CB >>>>> , "BRUNGARD, DEBORAH A, ATTLABS" >>>>> >>>>> =B3=AD=CB=CD >>>>> >>>>> =D6=F7=CC=E2 >>>>> Re: [mpls-tp] Associated bidirectional transport path requirements >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >>>>> wrote: >>>>> >>>>> Deborah: >>>>>> maybe what you said is right. but I can't completely agree your >>>>>> >>>>> opinions. >>>>> >>>>>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>>>>> should have AIS/FDI fuctions as SDH/SONET. >>>>>> >>>>>> do you think so. >>>>>> >>>>> >>>>> No we must assess the requirements for packet transport networks >>>>> supporting the needs of operators today and in the future. We must no= t >>>>> blindly recreate SDH/SONET. If we do so without consideration to how >>>>> operators' needs and requirements may have evolved (and continue to >>>>> evolve in future) we will have failed IMO and I would severely >>>>> question the value of the work we will have produced. If we just >>>>> recreate SDH/SONET then what is the purpose of the work an operator >>>>> would be better off just deploying existing SDH/SONET equipment. >>>>> >>>>> >>>>> Ben >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------- >>>>> ZTE Information Security Notice: The information contained in this >>>>> mail is solely property of the sender's organization. This mail >>>>> communication is confidential. Recipients named above are obligated t= o >>>>> maintain secrecy and are not permitted to disclose the contents of th= is >>>>> >>>> communication to others. >>>> >>>>> This email and any files transmitted with it are confidential and >>>>> intended solely for the use of the individual or entity to whom they >>>>> are addressed. If you have received this email in error please notify >>>>> the originator of the message. Any views expressed in this message ar= e >>>>> those of the individual sender. >>>>> This message has been scanned for viruses and Spam by ZTE Anti-Spam >>>>> >>>> system. >>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >> -- >> >> >> Loa Andersson >> >> Sr Strategy and Standards Manager phone: +46 10 717 52 13 >> Ericsson /// +46 767 72 92 13 >> >> >> email: loa.andersson@ericsson.com >> loa.andersson@redback.com >> loa@pi.nu >> >> >> >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --0015175cb21e42c26804685485c2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable I've been holding off commenting specifically on the need for AIS until= I have a chance to consult with my transport experts. Unfortunately, they = were all at the OIF meeting this past week. However, I can report that when= we previously reviewed the requirements draft, they indicated at that time= that they would prefer MPLS-TP OAM to resemble SONET/SDH OAM due to our em= bedded management systems and operator expertise. I hope to be able to repo= rt back soon on further internal discussions. Cheers, Andy 2009/4/24 Thomas Nade= au <tnadeau= @lucidvision.com> Well said. --Tom All, I spent most of my years in the in the industry on the vendor side, but for four shiort years I was with an operator. I'd many opportunities to understand that people working for vendors very seldom are channeling operator requirements, but rather what they think the operator requirements should be. The Lesson learned is that it much better to speak with and listen to operators than trying to speak for them. /Loa Thomas Nadeau wrote: Maartin, Ben, Your company is one of the many operators in the world, and the number of nodes outside your network is factors larger then the number of nodes inside your network. My experience is that different operators have different sets of requirements. Manufacturers have to support the superset of those requirements. Each operator will then deploy the subset of provided features that fits its needs (and turn off or don't use the others). Your company for some years has been asking for less, other operators have been asking for more. Manufacturers thus build their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? Unless our requirements are very different, I am confident vendors will build (or have built) their devices based on our (sensible) requirements. It is my opinion that we should not remove well established features like AIS, TCM, frame loss counting, delay measurement, loopback, etc before the majority of operators have agreed that such features are not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want.<= br> Unless you think we don't know what we are talking about. Is this perha= ps the case? --Tom Regards, Maarten -----Original Message----- From: mpls-tp= -bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: vrijdag 24 april 2009 0:14 To: mpls-tp@ietf.org<= /a> Subject: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Colleagues, The current debates appear to be going around in circles and achieving nothing of value IMO. Two major operators have expressed their opinions and no operator that I can see has disagreed with those opinions. I apologise for being direct (and possibly rude) but I am getting tired of being told by folks who do not represent operators what functionality I need or should have in my networks. To put some context on BT's comments in these threads: I have the largest MPLS network in the UK. I have one of the largest MPLS networks globally delivering service to 173 countries with over 200 000 customer ports I have (off the top of my head) at least another 10 MPLS networks in specific countries covering at least 3 continents delivering dedicated services to particular market segments. I have an extremely large SDH network in the UK consisting of over 30 000 switches and supporting in excess of 1 million circuits. I have an extremely large SDH network globally delivering service in 110 countries. I would like to think my BT colleagues and I might know a little something about building large scale networks and the requirements of those networks and the needs of the customers that I deliver services to. Can we please stop these circular arguments which are IMO going nowhere and focus on the task in hand which is defining the requirements (and later solutions) being asked for by myself, my company and my colleagues in other operators on this list. Thanks Ben -- Ben Niven-Jenkins IP, Data & Content Architect Network Infrastructure Architecture, BT E-mail: = benjamin.niven-jenkins@bt.com Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 British Telecommunications plc. Registered office: 81 Newgate Street<= br> London EC1A 7AJ Registered in England no: 1800000 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> wrote: ben: I understand your meaning, you still wish to resign and make a more reliable and effective, easy to operator and easy to manage packet transport network like me. but why not apply this SDH/SONET in the future maybe the following cause: 1 it adopted circuit switching techonogy to bring lower useful of the resource than PTN network; 2 it can't bear all kinds of traffics like PTN networks it noted<= br> that we can't apply SDH/SONET network in the future not because it have a complex OAM functions. while more people like to move the advantages of the OAM functions in SDH/SONET to PTN networks. and AIS/FDI function is a kind of OAM functions of SDH/SONET . we should use and extend the AIS/FDI functions to MPLS-TP ; best regards liu Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com> 2009-04-23 07:58 =CA=D5=BC=FE=C8=CB <liu.guoman@z= te.com.cn>, "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.co= m> =B3=AD=CB=CD <mpls-tp@ietf.org<= /a>> =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> wrote: Deborah: maybe what you said is right. but I can't completely agree your opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET. do you think so. No we must assess the requirements for packet transport networks supporting the needs of operators today and in the future. We must not blindly recreate SDH/SONET. If we do so without consideration to how operators' needs and requirements may have evolved (and continue to evolve in future) we will have failed IMO and I would severely question the value of the work we will have produced. If we just recreate SDH/SONET then what is the purpose of the work an operator would be better off just deploying existing SDH/SONET equipment. Ben -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 1= 3 Ericsson /// = +46 767 72 92 13 &nbs= p; email: loa.andersson@ericsso= n.com &nbs= p; &n= bsp; loa.and= ersson@redback.com &nbs= p; &n= bsp; loa@pi.nu _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp --0015175cb21e42c26804685485c2-- From rahul@juniper.net Fri Apr 24 15:53:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127593A6B7D for ; Fri, 24 Apr 2009 15:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKYn8C2Iyenv for ; Fri, 24 Apr 2009 15:53:36 -0700 (PDT) Received: from chip3og51.obsmtp.com (chip3og51.obsmtp.com [64.18.14.167]) by core3.amsl.com (Postfix) with ESMTP id A4ACB3A63D3 for ; Fri, 24 Apr 2009 15:53:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob51.postini.com ([64.18.6.12]) with SMTP ID DSNKSfJDONhPaC9vK2Yy9/AOnJLI1Tu7XObT@postini.com; Fri, 24 Apr 2009 15:54:55 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 24 Apr 2009 15:53:57 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 15:53:57 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 15:53:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 15:53:56 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3OMrtM24188; Fri, 24 Apr 2009 15:53:56 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Fri, 24 Apr 2009 15:53:55 -0700 From: Rahul Aggarwal To: Maarten Vissers In-Reply-To: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> Message-ID: <20090424154900.X31703@sapphire.juniper.net> References: <001701c9c465$9e8c36e0$0800540a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: QUOTED-PRINTABLE X-OriginalArrivalTime: 24 Apr 2009 22:53:56.0423 (UTC) FILETIME=[8C44E570:01C9C52F] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 22:53:37 -0000 Maarten, On Fri, 24 Apr 2009, Maarten Vissers wrote: > Ben, > > Your company is one of the many operators in the world, and the number of > nodes outside your network is factors larger then the number of nodes ins= ide > your network. My experience is that different operators have different se= ts > of requirements. Those different operators then must present those different requirements to the MPLS WG. In the absence of that we have no choice but to work with the requirements presented by the set of SPs who are currently involved in formulating the MPLS-TP requirements. Personally I would very much like to see greater SP involvement in MPLS-TP requirements effort. And vendors should not proxy for SPs in defining MPLS-TP requirements. rahul Manufacturers have to support the superset of those > requirements. Each operator will then deploy the subset of provided featu= res > that fits its needs (and turn off or don't use the others). Your company = for > some years has been asking for less, other operators have been asking for > more. Manufacturers thus build their products with lots of configurabilit= y > to support all variations. > > It is my opinion that we should not remove well established features like > AIS, TCM, frame loss counting, delay measurement, loopback, etc before th= e > majority of operators have agreed that such features are not longer > necessary. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f > Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: Associate= d > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their opinions a= nd > no operator that I can see has disagreed with those opinions. > > I apologise for being direct (and possibly rude) but I am getting tired o= f > being told by folks who do not represent operators what functionality I n= eed > or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to 17= 3 > countries with over 200 000 customer ports I have (off the top of my head= ) > at least another 10 MPLS networks in specific countries covering at least= 3 > continents delivering dedicated services to particular market segments. > > I have an extremely large SDH network in the UK consisting of over 30 000 > switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in 110 > countries. > > I would like to think my BT colleagues and I might know a little somethin= g > about building large scale networks and the requirements of those network= s > and the needs of the customers that I deliver services to. > > Can we please stop these circular arguments which are IMO going nowhere a= nd > focus on the task in hand which is defining the requirements (and later > solutions) being asked for by myself, my company and my colleagues in oth= er > operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street Lon= don > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" wrot= e: > > > ben: > > I understand your meaning, you still wish to resign and make a more > > reliable and effective, easy to operator and easy to manage packet > > transport network like me. but why not apply this SDH/SONET in the > > future maybe the following cause: > > 1 it adopted circuit switching techonogy to bring lower useful of > > the resource than PTN network; > > 2 it can't bear all kinds of traffics like PTN networks it noted > > that we can't apply SDH/SONET network in the future not because it > > have a complex OAM functions. while more people like to move the > > advantages of the OAM functions in SDH/SONET to PTN networks. and > > AIS/FDI function is a kind of OAM functions of SDH/SONET . we should > > use and extend the AIS/FDI functions to MPLS-TP ; > > > > best regards > > liu > > > > > > > > Ben Niven-Jenkins > > 2009-04-23 07:58 > > > > =CA=D5=BC=FE=C8=CB > > , "BRUNGARD, DEBORAH A, ATTLABS" > > > > =B3=AD=CB=CD > > > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > > > > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > > wrote: > > > >> Deborah: > >> maybe what you said is right. but I can't completely agree your > > opinions. > >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it > >> should have AIS/FDI fuctions as SDH/SONET. > >> > >> do you think so. > > > > No we must assess the requirements for packet transport networks > > supporting the needs of operators today and in the future. We must not > > blindly recreate SDH/SONET. If we do so without consideration to how > > operators' needs and requirements may have evolved (and continue to > > evolve in future) we will have failed IMO and I would severely > > question the value of the work we will have produced. If we just > > recreate SDH/SONET then what is the purpose of the work an operator > > would be better off just deploying existing SDH/SONET equipment. > > > > > > Ben > > > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated to > > maintain secrecy and are not permitted to disclose the contents of this > communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please notify > > the originator of the message. Any views expressed in this message are > > those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > From rcallon@juniper.net Fri Apr 24 21:57:10 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CEEE3A6403 for ; Fri, 24 Apr 2009 21:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3BbGfzO9Q7T for ; Fri, 24 Apr 2009 21:57:09 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id 47E323A680E for ; Fri, 24 Apr 2009 21:56:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSfKYaKrwxmmCZ3yswvjPQIw9I0UWCL2F@postini.com; Fri, 24 Apr 2009 21:58:17 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 24 Apr 2009 21:52:14 -0700 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 21:52:14 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 21:52:14 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 00:52:13 -0400 Message-ID: <3525C9833C09ED418C6FD6CD9514668C0633387C@emailwf1.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) (fwd) Thread-Index: AcnFXvLlGiuYABIQSEymutQ0R3oYLwAAKa4Q From: Ross Callon To: "Shahram Davari" , X-OriginalArrivalTime: 25 Apr 2009 04:52:14.0391 (UTC) FILETIME=[9A0E7C70:01C9C561] Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) (fwd) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 04:57:10 -0000 > Hi Rahul, > > Although I agree with the spirit of your comment in general, but > in context of IETF, the IETF works are based on consensus of > individuals and not their affiliation. For example I don't > recall MPLS requirements being defined by operators more than 10 > years ago. > > Regards, > Shahram It is correct that in the IETF officially we are all acting as individuals, and not as representatives of whatever company happens to pay our salary.=20 However, there is some IETF precedent for having requirements documents written by experts who work for service providers (and/or network operators, since of course there are network operators in large enterprises in addition to service providers). There is also some precedent for actively seeking out comments from a wider range of service providers / network operators.=20 In this case, where people who do not work for providers are stating that "there are carrier requirements for X", and there are some people from service providers who are contradicting this, it would be particularly useful to hear from other folks from other service providers regarding whether or not there really are carrier requirements for X.=20 Ross From loa@pi.nu Sat Apr 25 05:14:30 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F151F3A6A85 for ; Sat, 25 Apr 2009 05:14:30 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InS6nAdQWX9v for ; Sat, 25 Apr 2009 05:14:30 -0700 (PDT) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id B2BEA3A688B for ; Sat, 25 Apr 2009 05:14:29 -0700 (PDT) Received: from [95.209.8.167] (95.209.8.167.bredband.tre.se [95.209.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 549D72D8288; Sat, 25 Apr 2009 14:15:44 +0200 (CEST) Message-ID: <49F2FEE8.2090700@pi.nu> Date: Sat, 25 Apr 2009 14:15:36 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ross Callon References: <3525C9833C09ED418C6FD6CD9514668C0633387C@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C0633387C@emailwf1.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org, Shahram Davari Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) (fwd) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 12:14:31 -0000 All, I did not see the mail from Sharam, but hunderstands what he is saying. Though what was discussed was the difference between - an individual saying I have the following bright idea ... - I know a lot of service providers that thinks the following is a bright idea ... The first may discussed on it technicl merit, the second is not possible to verify one way or the other, unless these service providers steps up and say so themselves. /Loa Ross Callon wrote: >> Hi Rahul, >> >> Although I agree with the spirit of your comment in general, but >> in context of IETF, the IETF works are based on consensus of >> individuals and not their affiliation. For example I don't >> recall MPLS requirements being defined by operators more than 10 >> years ago. >> >> Regards, >> Shahram > > It is correct that in the IETF officially we are all acting as > individuals, and not as representatives of whatever company happens to > pay our salary. > > However, there is some IETF precedent for having requirements documents > written by experts who work for service providers (and/or network > operators, since of course there are network operators in large > enterprises in addition to service providers). There is also some > precedent for actively seeking out comments from a wider range of > service providers / network operators. > > In this case, where people who do not work for providers are stating > that "there are carrier requirements for X", and there are some people > from service providers who are contradicting this, it would be > particularly useful to hear from other folks from other service > providers regarding whether or not there really are carrier requirements > for X. > > Ross > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From gnewsome@ieee.org Sat Apr 25 14:16:38 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10233A6940 for ; Sat, 25 Apr 2009 14:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K90TW79ddWI for ; Sat, 25 Apr 2009 14:16:37 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id D3F0F3A679C for ; Sat, 25 Apr 2009 14:15:42 -0700 (PDT) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 6351C11D0E; Sat, 25 Apr 2009 17:17:01 -0400 (EDT) Received: from [192.168.1.100] (unknown [72.169.170.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id A599711CFF; Sat, 25 Apr 2009 17:16:53 -0400 (EDT) Message-ID: <49F37DBA.10100@ieee.org> Date: Sat, 25 Apr 2009 17:16:42 -0400 From: George Newsome User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ben Niven-Jenkins References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 6A76FD9A-31DE-11DE-BEEF-D766E3C8547C-03525878!a-sasl-quonix.pobox.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 21:16:38 -0000 Ben, In the original "Associated bidirectional transport path requirements" thread, Maarten wrote: -------- Original Message -------- > Maarten Vissers wrote: > > ......... > AIS/FDI does give additional information. Let me explain: > > .......... > > AIS has been introduced and is used to help differentiate between the > two fault cases. > ........ As I think Neil reminded us, AIS was not "introduced" at all. It was the name given to the signal that came out of a PDH equipment when the input signal failed. It happens because clocks continue to generate output bits whether there is input or not. Once we had it, we found things to use it for. Returning to Ben's "We appear to be going round in circles", it seems to me that AIS is a cheap, clever, happenstance solution because of the way that PDH, SDH and OTN work. The requirements that we need are "solve the problems that AIS solves." "We need AIS" is specifying a solution to an unstated problem. The principle thing we used AIS for was to distinguish between equipment local faults and remote faults. If we received AIS, then the incoming signal to us was OK and the fault must be remote. The AIS signal acts as crude OAM for the media; not as OAM for the client. This is clearly an interaction between the client and its server, and so the requirement is not a single layer requirement. It is an equipment (and network) requirement. The requirements that Ben needs are the things that we accomplished with AIS that pertain to the mpls-tp layer only. This is true for all the signals we defined in SDH and OTN OAM. In the case of AIS, it doesn't seem possible to create a requirement in the mpls-tp layer only that has an AIS signal as its solution. Regards, George Ben Niven-Jenkins wrote: > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their opinions and > no operator that I can see has disagreed with those opinions. > > I apologies for being direct (and possibly rude) but I am getting tired of > being told by folks who do not represent operators what functionality I need > or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to 173 > countries with over 200 000 customer ports > I have (off the top of my head) at least another 10 MPLS networks in > specific countries covering at least 3 continents delivering dedicated > services to particular market segments. > > I have an extremely large SDH network in the UK consisting of over 30 000 > switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in 110 > countries. > > I would like to think my BT colleagues and I might know a little something > about building large scale networks and the requirements of those networks > and the needs of the customers that I deliver services to. > > Can we please stop these circular arguments which are IMO going nowhere and > focus on the task in hand which is defining the requirements (and later > solutions) being asked for by myself, my company and my colleagues in other > operators on this list. > > Thanks > Ben > > From maarten.vissers@huawei.com Sun Apr 26 23:48:32 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52AD3A6B6A for ; Sun, 26 Apr 2009 23:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.428 X-Spam-Level: ** X-Spam-Status: No, score=2.428 tagged_above=-999 required=5 tests=[AWL=-1.986, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyFAxzjv645V for ; Sun, 26 Apr 2009 23:48:31 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6CDFF3A6B29 for ; Sun, 26 Apr 2009 23:48:31 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIQ0016TYYT02@szxga01-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 14:49:41 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIQ00E67YYSLD@szxga01-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 14:49:40 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIQ0098SYYMQY@szxml02-in.huawei.com>; Mon, 27 Apr 2009 14:49:40 +0800 (CST) Date: Mon, 27 Apr 2009 08:49:34 +0200 From: Maarten Vissers In-reply-to: <20090424154900.X31703@sapphire.juniper.net> To: 'Rahul Aggarwal' Message-id: <000001c9c704$5843ba40$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcnFMEMAyRdFWKIrTFes6UJKGqlwYgB0q6Ag Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 06:48:32 -0000 Rahul, > Personally I would very much like to see greater SP involvement in = MPLS-TP requirements effort. Please read draft-bhh-mpls-tp-oam-y1731. This draft is co-authored by representatives of DT, FT, KPN, KDDI and CT. Regards, Maarten=20 -----Original Message----- From: Rahul Aggarwal [mailto:rahul@juniper.net]=20 Sent: zaterdag 25 april 2009 0:54 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maarten, On Fri, 24 Apr 2009, Maarten Vissers wrote: > Ben, > > Your company is one of the many operators in the world, and the number = > of nodes outside your network is factors larger then the number of=20 > nodes inside your network. My experience is that different operators=20 > have different sets of requirements. Those different operators then must present those different requirements = to the MPLS WG. In the absence of that we have no choice but to work with = the requirements presented by the set of SPs who are currently involved in formulating the MPLS-TP requirements. Personally I would very much like to see greater SP involvement in = MPLS-TP requirements effort. And vendors should not proxy for SPs in defining MPLS-TP requirements. rahul Manufacturers have to support the superset of those > requirements. Each operator will then deploy the subset of provided=20 > features that fits its needs (and turn off or don't use the others).=20 > Your company for some years has been asking for less, other operators=20 > have been asking for more. Manufacturers thus build their products=20 > with lots of configurability to support all variations. > > It is my opinion that we should not remove well established features=20 > like AIS, TCM, frame loss counting, delay measurement, loopback, etc=20 > before the majority of operators have agreed that such features are=20 > not longer necessary. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re:=20 > Associated bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving = > nothing of value IMO. Two major operators have expressed their=20 > opinions and no operator that I can see has disagreed with those = opinions. > > I apologise for being direct (and possibly rude) but I am getting=20 > tired of being told by folks who do not represent operators what=20 > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to = > 173 countries with over 200 000 customer ports I have (off the top of=20 > my head) at least another 10 MPLS networks in specific countries=20 > covering at least 3 continents delivering dedicated services to = particular market segments. > > I have an extremely large SDH network in the UK consisting of over 30=20 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in=20 > 110 countries. > > I would like to think my BT colleagues and I might know a little=20 > something about building large scale networks and the requirements of=20 > those networks and the needs of the customers that I deliver services = to. > > Can we please stop these circular arguments which are IMO going=20 > nowhere and focus on the task in hand which is defining the=20 > requirements (and later > solutions) being asked for by myself, my company and my colleagues in=20 > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" wrote: > > > ben: > > I understand your meaning, you still wish to resign and make a more = > > reliable and effective, easy to operator and easy to manage packet=20 > > transport network like me. but why not apply this SDH/SONET in the=20 > > future maybe the following cause: > > 1 it adopted circuit switching techonogy to bring lower useful of = > > the resource than PTN network; > > 2 it can't bear all kinds of traffics like PTN networks it noted=20 > > that we can't apply SDH/SONET network in the future not because it=20 > > have a complex OAM functions. while more people like to move the=20 > > advantages of the OAM functions in SDH/SONET to PTN networks. and=20 > > AIS/FDI function is a kind of OAM functions of SDH/SONET . we should = > > use and extend the AIS/FDI functions to MPLS-TP ; > > > > best regards > > liu > > > > > > > > Ben Niven-Jenkins > > 2009-04-23 07:58 > > > > =CA=D5=BC=FE=C8=CB > > , "BRUNGARD, DEBORAH A, ATTLABS" > > > > =B3=AD=CB=CD > > > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > > > > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > > wrote: > > > >> Deborah: > >> maybe what you said is right. but I can't completely agree your > > opinions. > >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it=20 > >> should have AIS/FDI fuctions as SDH/SONET. > >> > >> do you think so. > > > > No we must assess the requirements for packet transport networks=20 > > supporting the needs of operators today and in the future. We must=20 > > not blindly recreate SDH/SONET. If we do so without consideration to = > > how operators' needs and requirements may have evolved (and continue = > > to evolve in future) we will have failed IMO and I would severely=20 > > question the value of the work we will have produced. If we just=20 > > recreate SDH/SONET then what is the purpose of the work an operator=20 > > would be better off just deploying existing SDH/SONET equipment. > > > > > > Ben > > > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this=20 > > mail is solely property of the sender's organization. This mail=20 > > communication is confidential. Recipients named above are obligated=20 > > to maintain secrecy and are not permitted to disclose the contents=20 > > of this > communication to others. > > This email and any files transmitted with it are confidential and=20 > > intended solely for the use of the individual or entity to whom they = > > are addressed. If you have received this email in error please=20 > > notify the originator of the message. Any views expressed in this=20 > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > From maarten.vissers@huawei.com Sun Apr 26 23:48:48 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8753A6F02 for ; Sun, 26 Apr 2009 23:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.564 X-Spam-Level: X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kImwolHzyoQd for ; Sun, 26 Apr 2009 23:48:47 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 1A7EF3A6A78 for ; Sun, 26 Apr 2009 23:48:46 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIQ007PWYZFFT@szxga02-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 14:50:04 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIQ000VCYZF7C@szxga02-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 14:50:03 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIQ0098SYYMQY@szxml02-in.huawei.com>; Mon, 27 Apr 2009 14:50:03 +0800 (CST) Date: Mon, 27 Apr 2009 08:49:34 +0200 From: Maarten Vissers In-reply-to: <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com> To: 'Thomas Nadeau' Message-id: <000501c9c704$5cf7cc70$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_+DvtfYZWj9Sg8OSj2RdX0Q)" Thread-index: AcnE4nfmDisldMC8TTSA48rkzWYbjQAAaPxA Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 06:48:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+DvtfYZWj9Sg8OSj2RdX0Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM.=20 The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number = > of nodes outside your network is factors larger then the number of=20 > nodes inside your network. My experience is that different operators=20 > have different sets of requirements. Manufacturers have to support the = > superset of those requirements. Each operator will then deploy the=20 > subset of provided features that fits its needs (and turn off or don't = > use the others). Your company for some years has been asking for less, = > other operators have been asking for more. Manufacturers thus build=20 > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features=20 > like AIS, TCM, frame loss counting, delay measurement, loopback, etc=20 > before the majority of operators have agreed that such features are=20 > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: =20 > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving = > nothing of value IMO. Two major operators have expressed their=20 > opinions and no operator that I can see has disagreed with those=20 > opinions. > > I apologise for being direct (and possibly rude) but I am getting=20 > tired of being told by folks who do not represent operators what=20 > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to = > 173 countries with over 200 000 customer ports I have (off the top of=20 > my > head) > at least another 10 MPLS networks in specific countries covering at=20 > least 3 continents delivering dedicated services to particular market=20 > segments. > > I have an extremely large SDH network in the UK consisting of over 30=20 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in=20 > 110 countries. > > I would like to think my BT colleagues and I might know a little=20 > something about building large scale networks and the requirements of=20 > those networks and the needs of the customers that I deliver services=20 > to. > > Can we please stop these circular arguments which are IMO going=20 > nowhere and focus on the task in hand which is defining the=20 > requirements (and later > solutions) being asked for by myself, my company and my colleagues in=20 > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street=20 > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more=20 >> reliable and effective, easy to operator and easy to manage packet=20 >> transport network like me. but why not apply this SDH/SONET in the=20 >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of=20 >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted=20 >> that we can't apply SDH/SONET network in the future not because it=20 >> have a complex OAM functions. while more people like to move the=20 >> advantages of the OAM functions in SDH/SONET to PTN networks. and=20 >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should=20 >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it=20 >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks=20 >> supporting the needs of operators today and in the future. We must=20 >> not blindly recreate SDH/SONET. If we do so without consideration to=20 >> how operators' needs and requirements may have evolved (and continue=20 >> to evolve in future) we will have failed IMO and I would severely=20 >> question the value of the work we will have produced. If we just=20 >> recreate SDH/SONET then what is the purpose of the work an operator=20 >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this=20 >> mail is solely property of the sender's organization. This mail=20 >> communication is confidential. Recipients named above are obligated=20 >> to maintain secrecy and are not permitted to disclose the contents of = >> this > communication to others. >> This email and any files transmitted with it are confidential and=20 >> intended solely for the use of the individual or entity to whom they=20 >> are addressed. If you have received this email in error please notify = >> the originator of the message. Any views expressed in this message=20 >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_+DvtfYZWj9Sg8OSj2RdX0Q) Content-type: application/vnd.ms-powerpoint; name=message-file-stream-00.ppt Content-transfer-encoding: base64 Content-disposition: attachment; filename=message-file-stream-00.ppt 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAcAAAAAAAAAAA EAAAQQAAAAEAAAD+////AAAAAHEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////bwAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAA/v////7///9uAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA ZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAA/v////7////+//////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAHA5ZKH/xskB QgAAAAADAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAV30AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAAAAkVQAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgCAAAAAAAADwDo AzglAAABAOkDKAAAAEIaAACwEwAA4BAAAIAWAAAFAAAACgAAAAUAAAAsAAAAAQAGAAAAAAEPAPID kgIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB8gBAAAAALcPRAAAAEEAcgBpAGEAbAAAAE4AZQB3 ACAAUgBvAG0AYQBuAAAAVKkTAFSpEwCIrlkM3JYTAHg6CzDclhMAAAAAAA8A1QcAAAQiEAC3D0QA AABNAFMAIABQAEcAbwB0AGgAaQBjAAAAbwBtAGEAbgAAAFSpEwBUqRMAiK5ZDNyWEwB4Ogsw3JYT AAAAAAAPANUHgAAEIiAAtw9EAAAAi1tTTwAAUABHAG8AdABoAGkAYwAAAG8AbQBhAG4AAABUqRMA VKkTAIiuWQzclhMAeDoLMNyWEwAAAAAADwDVB4YABAIwALcPRAAAAFcAaQBuAGcAZABpAG4AZwBz AAAAAABvAG0AYQBuAAAAVKkTAFSpEwCIrlkM3JYTAHg6CzDclhMAAAAAAA8A1QcCAAQCQAC3D0QA AABUAHIAZQBiAHUAYwBoAGUAdAAgAE0AUwAAAGEAbgAAAFSpEwBUqRMAiK5ZDNyWEwB4Ogsw3JYT AAAAAAAPANUHAAAEIlAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABUqRMA VKkTAIiuWQzclhMAeDoLMNyWEwAAAAAADwDVBwAABBIAAKQPCgAAAIEAQgABAAAAGQAAAKUPDAAA AAAAAAguAAAAAgAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA AABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEWBYAAA8AAPBQFgAAAAAG8NAV AAB04AoAuQIAADoAAAAEAAAAAAAAAA8AAAAAAAAAFgAAAAsAAAAIAAAAAAAAAAQAAAAAAAAAEAAA AAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAATAAAAAAAAAAQAAAAAAAAADQAAAAAAAAAEAAAA AAAAAAoAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABwAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAA AAAeAAAAAAAAAAwAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABQAAAAAAAAAHAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACgAAAAAAAAAHAAAAAAAAAAcAAAAAAAAA BwAAAAAAAAAGAAAAAAAAABEAAAAuAAAABgAAAC8AAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAACQAAAAAAAAAEAAAAAAAAAGMA AAAAAAAABAAAAAAAAACVAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAIAAAAAAAAAAcAAAAAAAAACAAA AAAAAAAHAAAAAAAAAAgAAAAAAAAAOwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAA AAAACAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABQAAAAAA AAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAACAAAAAAAAAAEAAAAXgAAAA0AAAAAAAAABwAAAAAAAAAHAAAAAAAAACMAAAAAAAAA BwAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAL AAAAAAAAAAYAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAgA AAAAAAAACgAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAPwAAAAAAAAA9AAAAAAAAAG8AAAAAAAAABAAA AAAAAAAGAAAAAAAAAJkAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAAAAAAQAAAAAAAAAAIAAAA AAAAAAQAAAAAAAAABAAAAAAAAAA/AAAAAAAAAAYAAAAAAAAACAAAAAAAAAAFAAAAAAAAAIgAAAAA AAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAHgAAAAAA AAAEAAAAAAAAADYAAAAAAAAABAAAAAAAAAA3AAAAAAAAAAQAAAAAAAAANwAAAAAAAAAEAAAAAAAA ADwAAAAAAAAARgAAAAAAAAAzAAAAAAAAAEgAAAAAAAAAOAAAAAAAAABIAAAAAAAAAFkBAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAcAAAAAAAAACAAAAAAAAAAI AAAAAAAAAAYAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAAJAAAAAAAAAAGAAAAAAAAAAgA AAAAAAAAEgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAFAAAAAAAAAAQAAAAAAAAAGgAAAAAAAAAdAAAAAAAAABEAAAAAAAAABAAAAAAAAABGAAAA AAAAABwAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADIAAAAAAAAAMAAAAAAAAAAqAAAAAAAAADcAAAAA AAAAMwAAAAAAAABTAAAAAAAAAEgAAAAAAAAA7QAAAAAAAAA+AQAAAAAAAAUAAAAAAAAARwAAAAAA AAAEAAAAAAAAAIMAAAAAAAAABAAAAAAAAADYAQAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAA AJwAAAAAAAAArAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAHAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAuAAAAAAAAAAQAAAAAAAAAkwAAAAAAAAB/ AAAAAAAAAFYAAAAAAAAANgAAAAAAAACTAAAAAAAAAGQAAAAAAAAAHgAAAAAAAABQAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAFAAAAAAAAAAkAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAA AAAAAAAEAAAAAAAAAIwAAAAAAAAAOQAAAAAAAAAoAAAAAAAAACMAAAAAAAAACAAAAAAAAAAEAAAA AAAAAAwBAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAKQAAAAA AAAACAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAawAAAAAAAABLAAAAAAAAAFUAAAAAAAAABgAAAAAA AAAIAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA ABoAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAUAAAAAAAAACEAAAAAAAAAAQAAAAAAAAA BgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAF AAAAAAAAAAYAAAAAAAAACAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYA AAAAAAAAHAAAAAAAAABLAAAAAAAAAFUAAAAAAAAATAAAAAAAAADEAAAAAAAAAAcAAAAAAAAACAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAAowAAAAAAAAAEAAAAAAAAADkAAAAAAAAABQAAAAAAAAAIAAAA AAAAAAcAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA8AAAAAAAAAC8AAAAA AAAALAAAAAAAAAAOAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAGAAAAAAAAAM8AAAAAAAAABAAAAAAA AAAEAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA0QAAAAAAAAAEAAAAAAAA AAUAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAADgAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAHEAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAABAAAAAAAAAAG AAAAAAAAAAgAAAAAAAAA9gAAAAAAAAAGAAAAAAAAAAQAAAAAAAAAPQAAAAAAAAAEAAAAAAAAAAUA AAAAAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAALwAAAAAAAAABAAA AAAAAAAGAAAAAAAAAB0BAAAAAAAACAAAAAAAAAAEAAAAAAAAADkBAAAAAAAATQAAAAAAAAANAQAA AAAAAKYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAABTAQAAAAAAAAQAAAAA AAAABQAAAAAAAAAIAAAAAAAAAM4AAAAAAAAAqwAAAAAAAADpAAAAAAAAAFoAAAAAAAAAWgAAAAAA AAByAAAAAAAAAAQAAAAAAAAABAAAAAAAAADFAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAA AAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAAAAADgAQAAAAAAAAQAAAAAAAAA BgAAAAAAAABsAAAAAAAAALYBAAAAAAAAagAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAACV AAAAAAAAAAQAAAAAAAAAowAAAAAAAACfAAAAAAAAAJ4AAAAAAAAAoQAAAAAAAAC/AAAAAAAAAAYA AAAAAAAABQAAAAAAAAAEAAAAAAAAAKUAAAAAAAAABAAAAAAAAABXAAAAAAAAAJ0AAAAAAAAABAAA AAAAAACVAAAAAAAAAAQAAAAAAAAAewAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAABHAAAA AAAAAMoAAAAAAAAAggAAAAAAAABjAAAAAAAAAI8AAAAAAAAATwAAAAAAAABwAAAAAAAAAE0AAAAA AAAAOAAAAAAAAABvAAAAAAAAAKcAAAAAAAAABAAAAAAAAABpAAAAAAAAAMcAAAAAAAAAawAAAAAA AACVAAAAAAAAALEAAAAAAAAANQAAAAAAAAB7AAAAAAAAAJAAAAAAAAAASQAAAAAAAAAqAAAAAAAA AAQAAAAAAAAAMwAAAAAAAAAuAAAAAAAAADoAAAAAAAAAZQAAAAAAAABPAAAAAAAAAOEAAAAAAAAA BwAAAAAAAAA7AAAAAAAAAEcAAAAAAAAAtAAAAAAAAABLAAAAAAAAAE4AAAAAAAAABgAAAAAAAAAG AAAAAAAAAEsAAAAAAAAAEgAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAFAAAAAAAAABEA AAAAAAAAFgAAAAAAAAAFAAAAAAAAAAgAAAAAAAAALAAAAAAAAAAEAAAAAAAAADkAAAAAAAAABAAA AAAAAABdAAAAAAAAAFYAAAAAAAAABAAAAAAAAAAWAAAAAAAAAAQAAAAAAAAA1AAAAAAAAAAsAQAA AAAAABwAAAAAAAAAXAAAAAAAAAAEAAAAAAAAAFwAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAA AAAABgAAAAAAAABtAAAAAAAAADgAAAAAAAAABAAAAAAAAAAWAAAAAAAAAAQAAAAAAAAABAAAAAAA AACBAAAAAAAAAFoAAAAAAAAAXQAAAAAAAACAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAXAAAAAAAAABYAAAAAAAAADgAAAAAAAAAXAAAAAAAAADwAAAAAAAAA LAAAAAAAAAAcAAAAAAAAAEQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAGgAAAAAAAAAm AAAAAAAAABoAAAAAAAAAKwAAAAAAAABkAAAAAAAAAAQAAAAAAAAAGgAAAAAAAAAnAAAAAAAAAEAA AAAAAAAABAAAAAAAAABvAAAAAAAAAFoAAAAAAAAABAAAAAAAAABsAAAAAAAAAEAAAAAAAAAAjAAA AAAAAABaAAAAAAAAAEUAAAAAAAAAgwAAAAAAAABLAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAFsAAAAAAAAAdwAAAAAAAAAGAAAAAAAAAAgAAAAAAAAAYwAAAAAAAABXAAAAAAAAAAQAAAAA AAAAfQAAAAAAAAAxAAAAAAAAADIAAAAAAAAABAAAAAAAAABDAAAAAAAAAAQAAAAAAAAANAAAAAAA AAAEAAAAAAAAACUAAAAAAAAAKwAAAAAAAABFAAAAAAAAAAQAAAAAAAAANgAAAAAAAABBAAAAAAAA ACQAAAAAAAAAJAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABgAAAAAAAABYAAAAAAAAAFgAAAAAAAAA fgAAAAAAAACAAAAAAAAAAEAAAAAAAAAAWAAAAAAAAABAAAAAAAAAAE4AAAAAAAAAaAAAAAAAAAAv AAAAAAAAAGQAAAAAAAAABAAAAAAAAAALAAAAAAAAAAsAAAAAAAAARgAAAAAAAAA2AAAAAAAAAD4A AAAAAAAAPgAAAAAAAADWAAAAAAAAAAQAAAAAAAAAWgAAAAAAAACHAAAAAAAAAJkAAAAAAAAAsgAA AAAAAAAUAQAAAAAAAFYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAEEAAAAAAAAAVwAAAAAAAAAEAAAA AAAAAFEAAAAAAAAAXAAAAAAAAABiAAAAAAAAAFYAAAAAAAAAdwAAAAAAAAAxAAAAAAAAAEgAAAAA AAAAOQAAAAAAAAChAAAAAAAAALoAAAAAAAAArgAAAAAAAABDAAAAAAAAAD4AAAAAAAAAQAAAAAAA AAAEAAAAAAAAADgAAAAAAAAAOAAAAAAAAAAvAAAAAAAAADsAAAAAAAAAcQAAAAAAAAAEAAAAAAAA AF4AAAAAAAAAeAAAAAAAAACXAAAAAAAAAIoAAAAAAAAAegAAAAAAAACdAAAAAAAAACsBAAAAAAAA MwEAAAAAAAA+AAAAAAAAACYAAAAAAAAAJgAAAAAAAAAYAAAAAAAAAEsAAAAAAAAAQAAAAAAAAAA6 AAAAAAAAADsAAAAAAAAAVwAAAAAAAABDAAAAAAAAABwAAAAAAAAALQAAAAAAAAAhAAAAAAAAAEYA AAAAAAAAGwAAAAAAAAAYAAAAAAAAABgAAAAAAAAAHwAAAAAAAAA4AAAAAAAAADgAAAAAAAAAFgAA AAAAAAAqAAAAAAAAACcAAAAAAAAAIgAAAAAAAAAjAAAAAAAAACMAAAAAAAAABAAAAAAAAABQAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAAAFAAAAAAAAAABQAAAAAAAABfAAAAAAAAAC8AAAAA AAAAKAAAAAAAAAAuAAAAAAAAAAQAAAAAAAAAUQAAAAAAAABpAAAAAAAAAFgAAAAAAAAAWgAAAAAA AAAbAAAAZAIAAGQAAAAAAAAA9gAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA ABAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAXgAAAAAAAAAEAAAAAAAAAMwAAAAAAAAA BAAAAAAAAAAHAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAG AAAAAAAAAAYAAAAAAAAAAwAAAAAAAAAEAAAAAAAAAEIAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAYA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAHwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAACAAA AAAAAADIAAAAAAAAADgAAAAAAAAABwAAAAAAAABYAAAAAAAAAAQAAAAAAAAABAAAAAAAAAB0AAAA gwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ARAAEADAAQEAAAjFQQAAAAD/AQgACAABAgIAAAiA ABrxIAAAAP9m/wD/AAAAzP+ZAP/MAACWlpYATU1NAGb/MwAAgAAAQAAe8RAAAAD/Zv8A//////// ////////HwDwDxwAAAAAAPMDFAAAAEAAAAAEAAAAAAAAAAMAAIAAAAAADwDQB3ALAAAfABQEHAAA AAAAFQQUAAAAJPpKCQDKmjsFwN8jAMqaOwACAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABh AAAAZAAAAGEAAABkAAAAAAAAAGz8WQz0lhMAeDoLMAAAAAAAAAAAcPn//5r///8BABMAcAD7AwgA AAAAAAAA2AkAAHAA+wMIAAAAAQAAACENAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwD6 A0cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAEAAAA8wVkM9JYTAHg6CzAA AAAAAAAAAAAAAAAAAAAAAQATAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAIJcTABL0 CjBUqRMAZK5ZDAAAAAAAAAAAAAAAAAAAAAAAARMAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAA AGQAAAAglxMAEvQKMFSpEwBkrlkMAAAAAAAAAAAAAAAAAAAAAAAAEwAPAIgT4gkAAA8AihNoAAAA AAC6DxQAAABfAF8AXwBQAFAAVAAyADAAMAAxAAAAixNEAAAADwCIFzwAAAAAAIkXNAAAAAAAAAAA AAAAAAAAAFgCAAAAAQEAAQEAAAEBAQABAAAAAAAAAIjZAAAAAAAAAAAAAIACAeAPAIoT+AgAAAAA ug8WAAAAXwBfAF8AUABQAFQATQBhAGMAMQAxAAAAixPSCAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAA BAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAA AAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEA AAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAA AGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAA JgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEH AAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAA AAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAA AAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAAD AAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUA IABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAO AAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA 6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAAB AAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoA QQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABv AGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoA AQAAHBAUAQAAAAAACAwBAAAAAAACAAABDAAAAAAAAAAUAAAAIAAAAAEAAAABAAAAAAAAAAEAAADo AAAACAAAAAQAAAAAAAABAAAAAAEAAAAAAAABAQAAAAEAAAAAAAABAgAAAAEAAAAAAAABAwAAAAEA AAAAAAABBAAAAAEAAAAAAAABBQAAAGhuYW1kAAAAYAAAAAIAAAAEAAAAAAAAAAMAAAAAAAAACgBB AHIAaQBhAGwAAAAAAAgAAAAAAAAAAwAAAAAAAAAmAE0AbwBuAG8AdAB5AHAAZQAgAFQAeQBwAG8A ZwByAGEAcABoAHkAAAAAAQYAAAAEABgAAAAAAQcAAAAGAAAAAAAAAAAABAAAAA4ACQARAAAAGgAB DwAbEEACAAAQAK8PCAAAAAABAAAFAAAAAAAZECgCAAAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQA AAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAA AAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAA AgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBv AG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYA AAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAA AAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAA AQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAA AAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkA cABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAE AAAADgAJABEAAAAaAAEPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAAN BAgAAABwtQAAcLUAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAALwDIDwwA AAAwANIPBAAAAAAAAAA/ANkPDAAAAAAA2g8EAAAAAAAlAE8A2Q8MAAAAAADaDwQAAAANAD0ADwDw DzoAAAAAAPMDFAAAAOEBAAAEAAAAAQAAAKMBAAAAAAAAAACfDwQAAAAAAAAAAACqDwoAAAABAAAA AQAAAAAAAADqAwAAAAAPAPgDAQkAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAswYADw ByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYA AAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAAAP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACv Z/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAA AAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABgAPAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/H AAD//wAA/wAAYADwByAAAACAAAAA////AFwfAADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAA AACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAA M5kARopLAGbM/wDw5QAAYADwByAAAABoa10A////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA 8AcgAAAAZmaZAP///wA+PlwA////AGBZewBmZv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAV AN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAA AABAAgAAAAAHAAAA///vAAEAAAACAAAA//8jAJkAAP4AABAAow+WAAAABQD//T8AAAAiIAAAZAAA AAD/AABkAEYAAAAAAAAAQAIAAAAABwAAAP//7wABAAAAAgAAAP//GQAAAAABAACzNQAAAwBxAAMA AAAAAVUAIwAnAiABAQACAAAAFgCANQAA2ABkABQAXQORAgAAAgAUALIFAAABABMgAAAAAAD/tATO AwAAQAD//4AFAAC7AAsGJQUAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAA AABAAgAAAAAHAAAA///vAAAAAAACAAAA//8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9OAAAABQAAAAAIAAABAAAAAAABAAEJAAACAAEA IAEAAAAAAgABCQAAAgABAJECAAAAAAMAAQkAAAAAAQDOAwAAAAAEAAEJAAAAAAEAJQUAAAAAYACj DwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABYAAQAAAAAAAAACABQAAgAAAAAA AAACABIAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgATAAEAAAAA AAAAAgASAAIAAAAAAAAAAgAQAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAA8ADASwAwAADwAC8KgD AADgBQjwCAAAAAQAAAAMeAEADwAD8EADAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAAHgBAAUAAAAPAATw/gAAABIACvAIAAAAAngBAAAKAADjAAvwVAAAAH8AAQAFAIAA CHNRDIEA8mQBAIIAe7IAAIMA8mQBAIQAe7IAAIcAAQAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQAR AMABAQAACP8BAQAJAAECAgAACBMAIvEGAAAAvwMAAAAEAAAQ8AgAAAAZAFAB8hiUAg8AEfAQAAAA AADDCwgAAAAAAAAAAQBRDA8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0 IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8EIB AAASAArwCAAAAAN4AQAACgAA0wAL8E4AAAB/AAEABQCAAGxtUQyBAPJkAQCCAHuyAACDAPJkAQCE AHuyAAC/ABAAHwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgTACLxBgAAAL8D AAAABAAAEPAIAAAAmARQAfIYlhEPABHwEAAAAAAAwwsIAAAAAQAAAAIAUQwPAA3wngAAAAAAnw8E AAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxl dmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAA AAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LgAAACiDArwCAAAAAx4 AQAACgAAowAL8DwAAACAAPDmUQyFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADA AQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8DAAQABAAAEPAIAAAA8xIIAOcAlxMPAA3wPgAAAAAA nw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAsAAADYDwQAAAAA AAAADwAE8EgAAAASAArwCAAAAAF4AQAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTARXtogCUAbYu egC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZ AACZmQCZzAAADwCIE50AAAAPAIoTlQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixN1AAAA AADqLgQAAAABAAAAAADrLggAAABLzcgB8JsSsAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAAAUwz/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisA AAAAIAC6DyQAAABoAHUAYQB3AGUAaQAtAHQAZQBtAHAAbABhAHQAZQAtAG0AdgAPAPADKAYAAAEA 8QMIAAAAAwAAgAAACzAPAAwEqAUAAA8AAvCgBQAAsAAI8AgAAAAHAAAABwwAAA8AA/A4BQAADwAE 8CgAAAABAAnwEAAAAAEAAAACAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAADwAE8NQAAAASAArw CAAAAAIMAAAACgAAcwAL8CoAAAB/AAEAAQCAAOQ9GgqBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/ AQEACQAAABDwCAAAAAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAKAu4LDwAN8GIAAAAAAJ8P BAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+Q8EAAAAAAAA AAAAqg8cAAAAAQAAAAcAAAAAAAQICQQBAAAABwAAAAAACQQECA8ABPDWAAAAEgAK8AgAAAADDAAA AAoAAHMAC/AqAAAAfwABAAEAgAC8OhoKgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ 8AgAAAAAAJAJ4BAgAQ8AEfAQAAAAAADDCwgAAAABAAAABwDuCw8ADfBkAAAAAACfDwQAAAAEAAAA AACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA+A8EAAAAAAAAAAAAqg8c AAAAAQAAAAcAAAAAAAQICQQBAAAABwAAAAAACQQECA8ABPBkAAAAEgAK8AgAAAAEDAAAAAoAAGMA C/AkAAAAfwAEAAQAhwABAAAAfwEAAAEAvwERABEA/wEIAAkAPwIBAAEAAAAQ8AgAAACwAdACEA4g Cg8AEfAQAAAAAADDCwgAAAACAAAABQDuCw8ABPAUAQAAEgAK8AgAAAAFDAAAAAoAAHMAC/AqAAAA fwABAAEAgADwQxoKgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACwCkACoA7Q FA8AEfAQAAAAAADDCwgAAAADAAAABgLuCw8ADfCiAAAAAACfDwQAAAACAAAAAACoD1IAAABDbGlj ayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91 cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAA BAAAAKoPDgAAAFMAAAAHAAAAAAAJBAQIDwAE8NoAAAASAArwCAAAAAYMAAAACgAAgwAL8DAAAAB/ AAEAAQCAAHRiGgqHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAGAV AABQB4AWDwAR8BAAAAAAAMMLCAAAAAQAAAAJAu4LDwAN8GIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAA ACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAAqg8cAAAAAQAAAAcA AAAAAAQICQQBAAAABwAAAAAACQQECA8ABPDcAAAAEgAK8AgAAAAHDAAAAAoAAIMAC/AwAAAAfwAB AAEAgACgGRoKhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABgFZAJ 4BCAFg8AEfAQAAAAAADDCwgAAAAFAAAACAIaCg8ADfBkAAAAAACfDwQAAAAEAAAAAACgDwIAAAAq AAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8cAAAAAQAAAAcA AAAAAAQICQQBAAAABwAAAAAACQQECA8ABPBIAAAAEgAK8AgAAAABDAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAsKZyAIAkqnMPAMkPoAQAAA8ADAQwBAAADwAC8CgE AADgAgjwCAAAAAUAAAAFsAAADwAD8MADAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAALAAAAUAAAAPAATw2AAAABIACvAIAAAAArAAAAAKAACDAAvwMAAAAH8AAQAFAIAA 0JiPCYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAAAAAAFAHIAEP ABHwEAAAAAAAwwsIAAAAAAAAAAoCGgoPAA3wYAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEP FAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD5DwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAABAgJ BAEAAAAGAAAACQQECA8ABPDaAAAAEgAK8AgAAAADsAAAAAoAAIMAC/AwAAAAfwABAAUAgABMno8J gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAAAAAI8J3xAgAQ8AEfAQ AAAAAADDCwgAAAABAAAABwKPCQ8ADfBiAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAA AgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA+A8EAAAAAAAAAAAAqg8aAAAAAQAAAAcAAAAAAAQICQQB AAAABgAAAAkEBAgPAATw3gAAABIACvAIAAAABLAAAAAKAACTAAvwNgAAAH8AAQAFAIAAyKKPCYcA AgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXxUAAFAHfxYP ABHwEAAAAAAAwwsIAAAAAgAAAAkCjwkPAA3wYAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEP FAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD6DwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAABAgJ BAEAAAAGAAAACQQECA8ABPDgAAAAEgAK8AgAAAAFsAAAAAoAAJMAC/A2AAAAfwABAAUAgAAUpo8J hwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABfFY8J3xB/ Fg8AEfAQAAAAAADDCwgAAAADAAAACAKPCQ8ADfBiAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAA oQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8aAAAAAQAAAAcAAAAA AAQICQQBAAAABgAAAAkEBAgPAATwSAAAABIACvAIAAAAAbAAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMB3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACA gIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAA VAAxADAAAACLExAAAAAAAOsuCAAAAFxrxgFwz400DwDuA9pDAAACAO8DGAAAAAcAAAANAAAAAAAA AAMAAIAAAAAABwALMAAA+QMQAAAAAAAAAAAAAAACAAEAAtxMMA8ADATpQgAADwAC8OFCAABAJgjw CAAAACMAAABjPAoAIAAY8QgAAAABAAAAAgAAAA8AA/ABQgAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAAA8CgAFAAAADwAE8MABAAASAArwCAAAABE8CgAACgAAkwEL8JYA AAB/AIAAhACAACylTAyBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAEAAAC/ABAAHwAM AfMDMxA/AQAABgCBAerq6gC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMD ZhAFApwxAAAGApwxAAA/AgAAAwC/AgkADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABg AP8BAADAAb8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAcAvYBUEP UwwPAA3wvAAAAAAAnw8EAAAABAAAAAAAqA8+AAAATDEgQ3VzdG9tZXJzIChMMywgTDIsIGJ1c2lu ZXNzLCBjYXJyaWVyKQtjb25uZWN0aXZpdHkgc2VydmljZXMAAKEPKAAAAD8AAAAAABZYAAAGAAUA AQBaAJD/PwAAAAEARwABAAQABAAOAAAAAAAAAKoPFAAAAD4AAAAAAAAAAQAAAAYAAAAJCAQIAACm DxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8PAAAAASAArwCAAAABs8CgAACgAAcwEL8IoA AACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACHAAEAAAC/AAAADwAMAfMDMxA/AQAABgCB AYAAAAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwx AAA/AgAAAwC/AgkADwD/AhYAHwB/AwAADwCTACLxNgAAAD8BAABAAL8BAABgAP8BAADAAb8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA7wKdAckPagUPAATwSQEAABIA CvAIAAAABDwKAAAKAABzAQvwigAAAH8AgACEAIAA2LpMDIEADqQAAIIAAAAAAIMADqQAAIQAAAAA AIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzEIEBADMAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAAC BQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAAADAL8CCQAPAP8CBAAEAAAAEPAIAAAAEgid AckPjQoPAA3wjwAAAAAAnw8EAAAABAAAAAAAqA8bAAAATDIgUGFja2V0C1RyYW5zcG9ydAtOZXR3 b3JrAAChDyYAAAAcAAAAAAAWUAAABgAFAFoAkP8cAAAAAABnAAQAAgAEABAAAAAAAAAAqg8MAAAA HAAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8EoBAAASAArwCAAA AAY8CgAACgAAcwEL8IoAAAB/AIAAhACAAHi8TAyBAA6kAACCAAAAAACDAA6kAACEAAAAAACFAAIA AACHAAEAAAC/ABAAHwAMAfMDMxCBAQAAmQC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAAB AvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgAAAwC/AgkADwD/AgQABAAAABDwCAAAAPUMnQHJD4MP DwAN8JAAAAAAAJ8PBAAAAAQAAAAAAKgPHAAAAEwxIE9wdGljYWwLVHJhbnNwb3J0C05ldHdvcmsA AKEPJgAAAB0AAAAAABZQAAAGAAUAWgCQ/x0AAAAAAGcABAACAAQAEAAAAAAAAACqDwwAAAAdAAAA BgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwowEAABIACvAIAAAACTwK AAAKAACTAQvwlgAAAH8AgACEAIAAJA9MDIEAAAAAAIIAAAAAAIMAwEsDAIQAAAAAAIUAAgAAAIcA AQAAAL8AEAAfAAwB8wMzED8BAAAGAIEB/8wAAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAA AAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAA PwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ 8AgAAAAcA7AFQg/8Aw8ADfCfAAAAAACfDwQAAAAEAAAAAACoDxMAAABMMyBTZXJ2aWNlcy9DaGFu bmVsAAChDzYAAAAUAAAAAAAWWAAABgAFAAIAWgCQ/xMAAAABAEMAAQAEAAQAFAABAAAAAQRjAAEE BAACAAQAFAAAAKoPFAAAABMAAAAAAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKg AvAD8ANABUAFDwAE8FwBAAASAArwCAAAAAo8CgAACgAAYwEL8IQAAAB/AIAAhACAAAzcTAyBAAAA AACCAAAAAACDAMBLAwCEAAAAAACFAAIAAACHAAEAAAC/ABAAHwAMAfMDMxCBAf9mAAC/ARwAHgDA AQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEA DwATACLxBgAAAL8BAABgAAAAEPAIAAAAJwSwBUIPDwUPAA3wmgAAAAAAnw8EAAAABAAAAAAAqA8O AAAATDMgVHVubmVsL1BhdGgAAKEPNgAAAA8AAAAAABZYAAAGAAUAAgBaAJD/DgAAAAEAQwABAAQA BAAUAAEAAAABBGMAAQQEAAIABAAUAAAAqg8UAAAADgAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAA APEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwowEAABIACvAIAAAACzwKAAAKAACTAQvwlgAAAH8A gACEAIAALL5MDIEAAAAAAIIAAAAAAIMAwEsDAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMz ED8BAAAGAIEBmf9mAL8BHAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUC nDEAAAYCnDEAAD8CAgADAL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEA AMABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAA/CLAFQg8hCQ8A DfCfAAAAAACfDwQAAAAEAAAAAACoDxMAAABMMiBTZXJ2aWNlcy9DaGFubmVsAAChDzYAAAAUAAAA AAAWWAAABgAFAAIAWgCQ/xMAAAABAEMAAQAEAAQAFAABAAAAAQRjAAEEBAACAAQAFAAAAKoPFAAA ABMAAAAAAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8FwB AAASAArwCAAAAAw8CgAACgAAYwEL8IQAAAB/AIAAhACAAMRRTAyBAAAAAACCAAAAAACDAMBLAwCE AAAAAACFAAIAAACHAAEAAAC/ABAAHwAMAfMDMxCBAQD/AAC/ARwAHgDAAQEAAAjLAWpKAAD/AQYA DgAAAgUAAAABAvEBmRACAvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwATACLxBgAAAL8BAABg AAAAEPAIAAAAWwmwBUIPMgoPAA3wmgAAAAAAnw8EAAAABAAAAAAAqA8OAAAATDIgVHVubmVsL1Bh dGgAAKEPNgAAAA8AAAAAABZYAAAGAAUAAgBaAJD/DgAAAAEAQwABAAQABAAUAAEAAAABBGMAAQQE AAIABAAUAAAAqg8UAAAADgAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC 8APwA0AFQAUPAATwowEAABIACvAIAAAADTwKAAAKAACTAQvwlgAAAH8AgACEAIAAIPxMDIEAAAAA AIIAAAAAAIMAwEsDAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzED8BAAAGAIEBZsz/AL8B HAAeAMABAQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAgAD AL8CAQAPAP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4A vwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAAAoDbAFQg8YDg8ADfCfAAAAAACfDwQAAAAE AAAAAACoDxMAAABMMSBTZXJ2aWNlcy9DaGFubmVsAAChDzYAAAAUAAAAAAAWWAAABgAFAAIAWgCQ /xMAAAABAEMAAQAEAAQAFAABAAAAAQRjAAEEBAACAAQAFAAAAKoPFAAAABMAAAAAAAAAAQAAAAYA AAAJCAQIAACmDxYAAADxHgAAoAJQAVABoAKgAvAD8ANABUAFDwAE8FwBAAASAArwCAAAAA48CgAA CgAAYwEL8IQAAAB/AIAAhACAANQ4TAyBAAAAAACCAAAAAACDAMBLAwCEAAAAAACFAAIAAACHAAEA AAC/ABAAHwAMAfMDMxCBAQCZ/wC/ARwAHgDAAQEAAAjLAWpKAAD/AQYADgAAAgUAAAABAvEBmRAC AvMDZhAFApwxAAAGApwxAAA/AgIAAwC/AgEADwATACLxBgAAAL8BAABgAAAAEPAIAAAAUg6wBUIP KA8PAA3wmgAAAAAAnw8EAAAABAAAAAAAqA8OAAAATDEgVHVubmVsL1BhdGgAAKEPNgAAAA8AAAAA ABZYAAAGAAUAAgBaAJD/DgAAAAEAQwABAAQABAAUAAEAAAABBGMAAQQEAAIABAAUAAAAqg8UAAAA DgAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwkAEA ABIACvAIAAAADzwKAAAKAABzAQvwigAAAH8AgACEAIAABJU0CoEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzEIEB6urqAL8BHAAeAMABAQAACMsBakoAAP8BBgAO AAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAAADAL8CCQAPAP8CBAAEAAAAEPAIAAAA VwGwBUEPZwIPAA3w1gAAAAAAnw8EAAAABAAAAAAAqA9CAAAATDMgU3Vic2NyaWJlcnMgJiBDb250 ZW50IFByb3ZpZGVycwtjb25uZWN0aXZpdHkgJiBjb250ZW50IHNlcnZpY2VzAAChDz4AAABDAAAA AAAWWAAABgAFAAEAWgCQ/0IAAAABAEcAAQAEAAQADgAAAAAAAQAAAAEEZwABBAQAAgAEAA4AAAAA AAAAqg8UAAAAQgAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AF QAUPAATwvQEAABIACvAIAAAAEDwKAAAKAACTAQvwlgAAAH8AgACEAIAAcAk0CoEAAAAAAIIAAAAA AIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzED8BAAAGAIEB6urqAL8BHAAeAMAB AQAACMsBakoAAP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAAADAL8CCQAP AP8CFgAfAH8DAAAPAJMAIvE2AAAAPwEAAEAAvwEAAGAA/wEAAMABvwMAggCCfwUGAE4AvwUGAE4A /wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAACoBrAFQQ+KBw8ADfC5AAAAAACfDwQAAAAEAAAAAACo DzsAAABMMiBDdXN0b21lcnMgKEwzLCBidXNpbmVzcywgY2FycmllcnMpC2Nvbm5lY3Rpdml0eSBz ZXJ2aWNlcwAAoQ8oAAAAPAAAAAAAFlgAAAYABQABAFoAkP88AAAAAQBHAAEABAAEAA4AAAAAAAAA qg8UAAAAOwAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUP AATwXAEAABIACvAIAAAAEjwKAAAKAABzAQvwigAAAH8AgACEAIAAxAA0CoEADqQAAIIAAAAAAIMA DqQAAIQAAAAAAIUAAgAAAIcAAQAAAL8AEAAfAAwB8wMzEIEBZjMAAL8BHAAeAMABAQAACMsBakoA AP8BBgAOAAACBQAAAAEC8QGZEAIC8wNmEAUCnDEAAAYCnDEAAD8CAAADAL8CCQAPAP8CBAAEAAAA EPAIAAAA2hCdAckPtBIPAA3wogAAAAAAnw8EAAAABAAAAAAAqA8SAAAAVHJhbnNtaXNzaW9uC01l ZGlhAAChDzoAAAATAAAAAAAWUAAABgAFAFoAkP8SAAAAAABHAAQABAAQAAAAAAABAAAAAARnAAAE BAACAAQAEAAAAAAAAACqDxQAAAASAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQ AaACoALwA/ADQAVABQ8ABPDGAQAAEgAK8AgAAAATPAoAAAoAANMBC/DUAAAAfwCAAIQAgADYEDQK gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwABAAAAvwAQAB8ADAHzAzMQgAEHAAAAgQH/ 8gAAgwFNCAgAiwEAAKb/jAFkAAAAlgGQAAAAl8EmAAAAnAEAAAAAvwEcAB4AwAEBAAAIywFqSgAA /wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8ABAAIAAgA//IA AAAAAAD/egAAM3MAAP8DAAAzswAATQgIAAAAAQAAABDwCAAAAAURsAUUD7IRDwAN8MIAAAAAAJ8P BAAAAAQAAAAAAKgPEgAAAFtMMSxMMixMM10gU2VjdGlvbgAAoQ9aAAAAEwAAAAAAFlgAAAYABQAB AFoAkP8KAAAAAQBDAAEABAAEABAAAQAAAAEARwABAAQABAAQAAAAAAAHAAAAAQBDAAEABAAEABAA AQAAAAEEYwABBAQAAgAEABAAAACqDxQAAAASAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4A AKACUAFQAaACoALwA/ADQAVABQ8ABPDTAQAAEgAK8AgAAAAUPAoAAAoAANMBC/DcAAAAfwCAAIQA gABcFDQKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhwABAAAAvwAQAB8ADAHzAzMQgAEH AAAAgQH/M5kAgwEzZv8AiwEAAKb/jAFkAAAAlgGYAAAAl8EuAAAAnAEAAAAAvwEcAB4AwAEBAAAI ywFqSgAA/wEGAA4AAAIFAAAAAQLxAZkQAgLzA2YQBQKcMQAABgKcMQAAPwICAAMAvwIBAA8ABQAI AAgA/zOZAAAAAAD/ZjMAAEAAAP//AAAAgAAAAaePAADAAAAzZv8AAAABAAAAEPAIAAAA3RGwBRQP ihIPAA3wxwAAAAAAnw8EAAAABAAAAAAAqA8rAAAAUGh5c2ljYWwgTWVkaWEgKEcuNzAzLCBHLjcw NywgRy43MDksIDgwMi4zKQAAoQ9GAAAALAAAAAAAFlgAAAYABQABAFoAkP8PAAAAAQBDAAEABAAE ABAAHAAAAAEAQwABAAQABAAMAAEAAAABBGMAAQQEAAIABAAMAAAAqg8UAAAAKwAAAAAAAAABAAAA BgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwZgEAAKIMCvAIAAAAGDwK AAAKAAAjAQvwbAAAAH8AgACAAIAA2B40CoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8AEgAfAIEB BAAACIMBAAAACL8BDAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAACUAhsHfA0OAw8ADfC8AAAAAACfDwQAAAAEAAAA AACgDygAAABWAG8AaQBjAGUAIAATICAARABhAHQAYQAgAC0AIABWAGkAZABlAG8AAAChDz4AAAAV AAAAAAAWWAAABgAFAAEAWgCQ/xQAAAADAEcAAwAEAAQADgAAAAAAAQAAAAMEZwADBAQAAgAEAA4A AAAAAAAAqg8UAAAAFAAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APw A0AFQAUPAATwMBQAAKIECvAIAAAAGTwKAAAKAABTAQvwyhMAAIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAgAAAIcAAQAAAL8AAAAPAIEBBAAACIMBAAAACL8BDAAeAMABAQAACMsBakoAAP8BDgAO AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIDDGgAAAIHDMhMAAL8DAgACAEQAdABzAFMA aABhAHAAZQBOAGEAbQBlAAAAMwA0ADkAQwAzADIAQAAwAEcAOAA5AEcANQBDADQAMgBAAEAANwBE AEUANwA4ADAANQA5AEcAOAA4AEIANQA0ADAAOQA7ADMAOQA4ADkAOwA0AEYAVABMADEAMQA4ADEA MQAxADEAMwAhACEAIQBCAEkASABPAEAAXQBMADEAMQA4ADEAMQAxADEAMwAhACEAIQAhACEAIQAh ADEAMQAxADAARwAyAEMAOQBDADQAMAAxADIAMQAxADAARwAyAEMAOQBDADQAMAAxADIAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQA5AD0AQAA/ADEAOAA1AEoA OQA+AEwAMQAxADgAMQAxADEAMQAzACEAIQAhAEIASQBIAE8AQABdAEwAMQAxADgAMQAxADEAMQAz ACEAIQAhACEAIQAhACEAMQAxADEAMABCADMANABDADkAMABDAEcARwBsAGQAcgByAGAAZgBkACwA ZwBoAG0AZAAsAHIAdQBzAGQAYABsACwAMQAxAC8AcQBxAHUAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhADEAIQAxAAAAkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/ AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAAAAAAABAAEADwAE8AYB AAASAArwCAAAABw8CgAACgAA8wAL8FoAAAB/AAAABACAANRpNAqBACFlAQCCAJCyAACDACFlAQCE AJCyAACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA AAgAABDwCAAAACgDmgE2BTYFDwAN8HwAAAAAAJ8PBAAAAAQAAAAAAKgPHAAAAEwzIE5leHQgR2Vu C1NlcnZpY2VzC05ldHdvcmsAAKEPIAAAAB0AAAAAABZQAAAGAAUAWgCQ/x0AAAAAAAYAEgAAAAAA AACqDwwAAAAdAAAABgAAAAkIBAgAAKYPCAAAAEAIAABfA18DDwAE8HwBAACiDArwCAAAAB08CgAA CgAAIwEL8GwAAAB/AIAAgACAANglNAqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/ABIAHwCBAQQA AAiDAQAAAAi/AQwAHgDAAQEAAAjLAWpKAAD/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/ AwAADwATACLxBgAAAL8DAIIAggAAEPAIAAAAtwcbB3wNMQgPAA3w0gAAAAAAnw8EAAAABAAAAAAA oA8+AAAARQB0AGgAZQByAG4AZQB0ACAAEyAgAFQARABNACAAEyAgAEEAVABNACAAEyAgAEYAUgAg AC0AIAAuAC4ALgAAAKEPPgAAACAAAAAAABZYAAAGAAUAAQBaAJD/HwAAAAMARwADAAQABAAOAAAA AAABAAAAAwRnAAMEBAACAAQADgAAAAAAAACqDxQAAAAfAAAAAAAAAAEAAAAGAAAACQgECAAApg8W AAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPDKAQAAogwK8AgAAAAePAoAAAoAACMBC/BsAAAA fwCAAIAAgACQNDQKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwASAB8AgQEEAAAIgwEAAAAIvwEM AB4AwAEBAAAIywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYA AAC/AwCCAIIAABDwCAAAAI8MzQQjEAgNDwAN8CABAAAAAJ8PBAAAAAQAAAAAAKAPYAAAAFMAVABN AC0ATgAgABMgIAB4AEcARQAgABMgIABGAEMAIAATICAAeABHACAAUwBEAEkAIAAtACAALgAuAC4A IAATICAAUABhAGMAawBlAHQAcwAvAEYAcgBhAG0AZQBzAAAAoQ8+AAAAMQAAAAAAFlgAAAYABQAB AFoAkP8wAAAAAwBHAAMABAAEAA4AAAAAAAEAAAADBGcAAwQEAAIABAAOAAAAAAAAAKoPQAAAAAgA AAAGAAAACQgECAMAAAAHAAAAAwAJCAQICAAAAAYAAAAJCAQIAgAAAAcAAAADAAkIBAgcAAAABgAA AAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwdAEAAKIMCvAIAAAAHzwKAAAK AAAjAQvwbAAAAH8AgACAAIAA2Do0CoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8AEgAfAIEBBAAA CIMBAAAACL8BDAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPABMAIvEGAAAAvwMAggCCAAAQ8AgAAAB1EKMHBQ7uEA8ADfDKAAAAAACfDwQAAAAEAAAAAACg DzYAAABMAGEAeQBlAHIAIAAxACAAEyAgAEwAYQB5AGUAcgAgADIAIAATICAATABhAHkAZQByACAA MwAAAKEPPgAAABwAAAAAABZYAAAGAAUAAQBaAJD/GwAAAAMARwADAAQABAAOAAAAAAABAAAAAwRn AAMEBAACAAQADgAAAAAAAACqDxQAAAAbAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4AAKAC UAFQAaACoALwA/ADQAVABQ8ABPBeAQAAogwK8AgAAAAgPAoAAAoAACMBC/BsAAAAfwCAAIAAgACE ezQKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI ywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIA ABDwCAAAAD8IsAWzCDEJDwAN8LQAAAAAAJ8PBAAAAAQAAAAAAKgPFgAAAHAycCAtIHAybXALcm1w IC0gbXAybXAAAKEPNgAAABcAAAAAABZYAAAGAAUAAQBaAJD/FgAAAAMAQwADAAQABAAOAAEAAAAD BGMAAwQEAAIABAAOAAAAqg8mAAAACwAAAAAAAAADAAAAAQAAAAMACAAAAAAAAAABAAAABgAAAAkI BAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwQAEAAKIMCvAIAAAAITwKAAAKAAAj AQvwbAAAAH8AgACAAIAATCg0CoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8AEgAfAIEBBAAACIMB AAAACL8BDAAeAMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP ABMAIvEGAAAAvwMAggCCAAAQ8AgAAABACbAFswi5CQ8ADfCWAAAAAACfDwQAAAAEAAAAAACoDwoA AABwMnAgLSBwMm1wAAChDzYAAAALAAAAAAAWWAAABgAFAAEAWgCQ/woAAAADAEMAAwAEAAQADgAB AAAAAwRjAAMEBAACAAQADgAAAKoPFAAAAAoAAAAAAAAAAQAAAAYAAAAJCAQIAACmDxYAAADxHgAA oAJQAVABoAKgAvAD8ANABUAFDwAE8EABAACiDArwCAAAACI8CgAACgAAIwEL8GwAAAB/AIAAgACA AJS2gAqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEA AAjLAWpKAAD/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwATACLxBgAAAL8DAIIA ggAAEPAIAAAAJg2wBbMInw0PAA3wlgAAAAAAnw8EAAAABAAAAAAAqA8KAAAAcDJwIC0gcDJtcAAA oQ82AAAACwAAAAAAFlgAAAYABQABAFoAkP8KAAAAAwBDAAMABAAEAA4AAQAAAAMEYwADBAQAAgAE AA4AAACqDxQAAAAKAAAAAAAAAAEAAAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/AD QAVABQ8ABPA5AQAAogwK8AgAAAAjPAoAAAoAACMBC/BsAAAAfwCAAIAAgAAswIAKgQAAAAAAggAA AAAAgwAAAAAAhAAAAAAAvwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywFqSgAA/wEGAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAFQOsAUb B80ODwAN8I8AAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAHAycAAAoQ82AAAABAAAAAAAFlgAAAYABQAB AFoAkP8DAAAAAwBDAAMABAAEAA4AAQAAAAMEYwADBAQAAgAEAA4AAACqDxQAAAADAAAAAAAAAAEA AAAGAAAACQgECAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBFAQAAogwK8AgAAAAk PAoAAAoAACMBC/BsAAAAfwCAAIAAgACQyYAKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwASAB8A gQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AEwAi8QYAAAC/AwCCAIIAABDwCAAAAC0EsAWzCB4FDwAN8JsAAAAAAJ8PBAAAAAQA AAAAAKgPDwAAAHAycCAtIHAybXALbXAycAAAoQ82AAAAEAAAAAAAFlgAAAYABQABAFoAkP8PAAAA AwBDAAMABAAEAA4AAQAAAAMEYwADBAQAAgAEAA4AAACqDxQAAAAPAAAAAAAAAAEAAAAGAAAACQgE CAAApg8WAAAA8R4AAKACUAFQAaACoALwA/ADQAVABQ8ABPBGAQAAogwK8AgAAAAlPAoAAAoAACMB C/BsAAAAfwCAAIAAgADwuYAKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwASAB8AgQEEAAAIgwEA AAAIvwEMAB4AwAEBAAAIywFqSgAA/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A EwAi8QYAAAC/AwCCAIIAABDwCAAAABwDsAWzCA4EDwAN8JwAAAAAAJ8PBAAAAAQAAAAAAKgPEAAA AHAycCAtIHAybXALbXAybXAAAKEPNgAAABEAAAAAABZYAAAGAAUAAQBaAJD/EAAAAAMAQwADAAQA BAAOAAEAAAADBGMAAwQEAAIABAAOAAAAqg8UAAAAEAAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAA APEeAACgAlABUAGgAqAC8APwA0AFQAUPAATwOQEAAKIMCvAIAAAAJjwKAAAKAAAjAQvwbAAAAH8A gACAAIAAnN2ACoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8AEgAfAIEBBAAACIMBAAAACL8BDAAe AMABAQAACMsBakoAAP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPABMAIvEGAAAA vwMAggCCAAAQ8AgAAAD9ELAFGwd2EQ8ADfCPAAAAAACfDwQAAAAEAAAAAACoDwMAAABwMnAAAKEP NgAAAAQAAAAAABZYAAAGAAUAAQBaAJD/AwAAAAMAQwADAAQABAAOAAEAAAADBGMAAwQEAAIABAAO AAAAqg8UAAAAAwAAAAAAAAABAAAABgAAAAkIBAgAAKYPFgAAAPEeAACgAlABUAGgAqAC8APwA0AF QAUPAATw/gAAAAIDCvAIAAAAXTwKAAAKAAATAQvwZgAAAIAAYOCACr8AAAACAEcBIun//0gBAxgA AEkB1fP//0oBAxgAAEsBJP7//0wBAxgAAE0BIun//04BAxgAAIEB/2b/AIMBAAAACL8BEAAQAMAB AQAACP8BCAAIAAECAgAACH8DAAAMAAAAEPAIAAAAagFiEeMZZwIPAA3waAAAAAAAnw8EAAAABAAA AAAAqA8YAAAATWVzc2FnZSwgZmlsZSBhbmQgc3RyZWFtAAChDxgAAAAZAAAAAAAACAAAAQAZAAAA AQACAAEAEwAAAKoPFAAAABgAAAAGAAAACQgAAAEAAAAAAAAADwAE8BEBAAACAwrwCAAAAF48CgAA CgAAEwEL8GYAAACAALDjgAq/AAAAAgBHASLp//9IAZ4PAABJAdXz//9KAZ4PAABLAST+//9MAZ4P AABNASLp//9OAZ4PAACBAf9m/wCDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAh/AwAADAAA ABDwCAAAALoGYhHjGT8IDwAN8HsAAAAAAJ8PBAAAAAQAAAAAAKgPKwAAAEUtTGluZSwgRS1UcmVl LCBFLUxBTiwgUERIIENFUywgQVRNLCBGUiwgLi4AAKEPGAAAACwAAAAAAAAIAAABACwAAAABAAIA AQATAAAAqg8UAAAAKwAAAAYAAAAJCAAAAQAAAAAAAAAPAATwBgEAAAIDCvAIAAAAXzwKAAAKAAAT AQvwZgAAAIAAFOiACr8AAAACAEcBIun//0gB5A4AAEkB1fP//0oB5A4AAEsBJP7//0wB5A4AAE0B Iun//04B5A4AAIEB/2b/AIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACH8DAAAMAAAAEPAI AAAAngtiEeMZNg0PAA3wcAAAAAAAnw8EAAAABAAAAAAAqA8gAAAAU1RNLU4sIDgwMi4zL3hHRSwg RkMsIEhEIFNESSwgLi4AAKEPGAAAACEAAAAAAAAIAAABACEAAAABAAIAAQATAAAAqg8UAAAAIAAA AAYAAAAJCAAAAQAAAAAAAAAPAATwAgEAAAIDCvAIAAAAYDwKAAAKAAAjAQvwbAAAAIAAgOyACr8A AAACAEcBIun//0gBAxgAAEkB1fP//0oBAxgAAEsBJP7//0wBAxgAAE0BIun//04BAxgAAIEBAAAA CIMBAAAACL8BEAAQAMABAQAACM4BBwAAAP8BCAAIAAECAgAACH8DAAAMAAAAEPAIAAAAQARiEeMZ PQUPAA3wZgAAAAAAnw8EAAAABAAAAAAAqA8WAAAAVkxBTiwgTVBMUyBMU1AsIExPIE9EVQAAoQ8Y AAAAFwAAAAAAAAgAAAEAFwAAAAEAAgABABEAAACqDxQAAAAWAAAABgAAAAkIAAABAAAAAAAAAA8A BPAFAQAAAgMK8AgAAABhPAoAAAoAACMBC/BsAAAAgADcJIAKvwAAAAIARwEi6f//SAEDGAAASQHV 8///SgEDGAAASwEk/v//TAEDGAAATQEi6f//TgEDGAAAgQEAAAAIgwEAAAAIvwEQABAAwAEBAAAI zgEHAAAA/wEIAAgAAQICAAAIfwMAAAwAAAAQ8AgAAABjCWIR4xlgCg8ADfBpAAAAAACfDwQAAAAE AAAAAACoDxkAAABWTEFOLCBNUExTLVRQIExTUCwgTE8gT0RVAAChDxgAAAAaAAAAAAAACAAAAQAa AAAAAQACAAEAEQAAAKoPFAAAABkAAAAGAAAACQgAAAEAAAAAAAAADwAE8PIAAAACAwrwCAAAAGI8 CgAACgAAIwEL8GwAAACAADAogAq/AAAAAgBHASLp//9IAQMYAABJAdXz//9KAQMYAABLAST+//9M AQMYAABNASLp//9OAQMYAACBAQAAAAiDAQAAAAi/ARAAEADAAQEAAAjOAQcAAAD/AQgACAABAgIA AAh/AwAADAAAABDwCAAAAIcOYhHjGYQPDwAN8FYAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAEhPIE9E VQAAoQ8YAAAABwAAAAAAAAgAAAEABwAAAAEAAgABABEAAACqDxQAAAAGAAAABgAAAAkIAAABAAAA AAAAAA8ABPBIAAAAEgAK8AgAAAABPAoAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwEV7aIAlAG2 LnoAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAbwAF8GAAAAAAABfwCAAAAAIAAABdPAoAAAAX8AgA AAADAAAAXjwKAAAAF/AIAAAABAAAAF88CgAAABfwCAAAAAUAAABgPAoAAAAX8AgAAAAGAAAAYTwK AAAAF/AIAAAABwAAAGI8CgAQAPAHIAAAAP///wAAAAAAsrKyAAAAAAD/zAAAmcwAAAAA/wDMADMA DwCIE4EAAAAPAIoTeQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNZAAAAAAAAKwQAAAAA AAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAD1C/////8SAAAADwA98Q0A AABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIXKAAAAAEAEAAAAAAABQAQAEkuAAAsABAAeTQAAEAA EABAJQAA4QEQACE5AAAAAPUPHAAAAKMBAACkGQADAAAAAAN9AAABAAAAAgIAAAEAxTEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAAD AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAP7////+//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////+/wAABQECAAAA AAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuSAIA AAQCAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACgAAAABAAAAMgAAAAGAAAA0AAAAAcAAADYAAAA CAAAAOAAAAAJAAAA6AAAAAoAAADwAAAAFwAAAPgAAAALAAAAAAEAABAAAAAIAQAAEwAAABABAAAW AAAAGAEAAA0AAAAgAQAADAAAAKIBAAACAAAA6f0AAB4AAAAIAAAAQ3VzdG9tAAAeAAAAIAAAAEh1 YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4AAAAAAwAAAFd9AAADAAAAIAAAAAMAAAABAAAAAwAA AAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAGQfCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAB4QAAAIAAAABgAAAEFyaWFsAAsAAABNUyBQR290aGljAAcAAADlrovkvZMACgAAAFdpbmdk aW5ncwANAAAAVHJlYnVjaGV0IE1TABAAAABUaW1lcyBOZXcgUm9tYW4AEwAAAGh1YXdlaS10ZW1w bGF0ZS1tdgAIAAAAU2xpZGUgMQAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZP7/AAAFAQIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAPRUAAAMAAAAAQAAAGgAAAACAAAA cAAAAAQAAACwAAAABwAAAMAAAAAIAAAA3AAAAAkAAADsAAAAEgAAAPgAAAAKAAAAGAEAAAwAAAAk AQAADQAAADABAAAPAAAAPAEAABEAAABEAQAAAgAAAOQEAAAeAAAAOAAAAG1lc3NhZ2UsIGZpbGUs IHN0cmVhbSBsb2NhdGlvbiBpbiB0aGUgTDEsIEwyLCBMMyBzdGFjawAAHgAAAAgAAABWaXNzZXJz AB4AAAAUAAAAaHVhd2VpLXRlbXBsYXRlLW12AAAeAAAACAAAAFZpc3NlcnMAHgAAAAQAAAA3MDkA HgAAABgAAABNaWNyb3NvZnQgUG93ZXJQb2ludAAAAABAAAAAMF8OHg8IAABAAAAAoL5Nck7NyAFA AAAAoJdTof/GyQEDAAAAeAAAAEcAAACoUwAA/////wMAAAAIAIkQZwwAAAEACQAAA8wpAAABAKEn AAAAAAQAAAADAQgABQAAAAsCAAAAAAUAAAAMAtECwQMJAgAA9wAAAwIBAAAAAIAAAAAAgAAAgIAA AAAAgACAAIAAAICAAMDAwADA3MAApsrwAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIiIgApKSkA VVVVAE1NTQBCQkIAOTk5AP98gAD/UFAA1gCTAMzs/wDv1sYA5+fWAK2pkAAzAAAAZgAAAJkAAADM AAAAADMAADMzAABmMwAAmTMAAMwzAAD/MwAAAGYAADNmAABmZgAAmWYAAMxmAAD/ZgAAAJkAADOZ AABmmQAAmZkAAMyZAAD/mQAAAMwAADPMAABmzAAAmcwAAMzMAAD/zAAAZv8AAJn/AADM/wAAAAAz ADMAMwBmADMAmQAzAMwAMwD/ADMAADMzADMzMwBmMzMAmTMzAMwzMwD/MzMAAGYzADNmMwBmZjMA mWYzAMxmMwD/ZjMAAJkzADOZMwBmmTMAmZkzAMyZMwD/mTMAAMwzADPMMwBmzDMAmcwzAMzMMwD/ zDMAM/8zAGb/MwCZ/zMAzP8zAP//MwAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZgAAM2YAMzNmAGYz ZgCZM2YAzDNmAP8zZgAAZmYAM2ZmAGZmZgCZZmYAzGZmAACZZgAzmWYAZplmAJmZZgDMmWYA/5lm AADMZgAzzGYAmcxmAMzMZgD/zGYAAP9mADP/ZgCZ/2YAzP9mAP8AzADMAP8AAJmZAJkzmQCZAJkA zACZAAAAmQAzM5kAZgCZAMwzmQD/AJkAAGaZADNmmQBmM5kAmWaZAMxmmQD/M5kAM5mZAGaZmQCZ mZkAzJmZAP+ZmQAAzJkAM8yZAGbMZgCZzJkAzMyZAP/MmQAA/5kAM/+ZAGbMmQCZ/5kAzP+ZAP// mQAAAMwAMwCZAGYAzACZAMwAzADMAAAzmQAzM8wAZjPMAJkzzADMM8wA/zPMAABmzAAzZswAZmaZ AJlmzADMZswA/2aZAACZzAAzmcwAZpnMAJmZzADMmcwA/5nMAADMzAAzzMwAZszMAJnMzADMzMwA /8zMAAD/zAAz/8wAZv+ZAJn/zADM/8wA///MADMAzABmAP8AmQD/AAAzzAAzM/8AZjP/AJkz/wDM M/8A/zP/AABm/wAzZv8AZmbMAJlm/wDMZv8A/2bMAACZ/wAzmf8AZpn/AJmZ/wDMmf8A/5n/AADM /wAzzP8AZsz/AJnM/wDMzP8A/8z/ADP//wBm/8wAmf//AMz//wD/ZmYAZv9mAP//ZgBmZv8A/2b/ AGb//wClACEAX19fAHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx8QD4+PgA //vwAKCgpACAgIAA/wAAAAD/AAD//wAAAAD/AP8A/wD///8AAAAAAAAAAAGoARUABAAAADQCAAAE AAAABwEDAKEnAABBCyAAzAB4AKAAAAAAANACwAMAAAAAKAAAAKAAAAB4AAAAAQAIAAAAAAAASwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAE BAQACAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wAADP/ AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADMAAAAzDMA AMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwAMwD/ADMzAAAz MzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZAAAzmTMAM5lmADOZ mQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YAM/+ZADP/zAAz//8AZgAA AGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYzzABmM/8AZmYAAGZmMwBmZmYA ZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAAZswzAGbMmQBmzMwAZsz/AGb/AABm /zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkAzACZAAAAmTMzAJkAZgCZM8wAmQD/AJlm AACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYAmZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZ AJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAA zDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAAzGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDM mZkAzJnMAMyZ/wDMzAAAzMwzAMzMZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz/ /wDMADMA/wBmAP8AmQDMMwAA/zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bM AMxm/wD/mQAA/5kzAP+ZZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMA zP9mAP//mQD//8wAZmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDL y8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8A AAD/AP8A//8AAP///wD///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////HSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0j HSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0jHSMi//////////////// //////////////////////////////////////////////////////////////////////////// /////yMiIyIjIiMjIyIjIiMiIyMjIiMiIyIjI7ePsY+xagBq42rjTeNN401TTVNTUzJZOFk4Xvv7 +147XVddV3hWl3eWcZaBlYG5gbOys7PUrdTOzs4jIiMiIyP///////////////////////////// //////////////////////////////////////////////////////////////////8dIx0jHSMd Ix0jHSMdIx0jHSMdIx0jHSOxjwCPAAAAagAAAOMATQBNTVMAUwAAADg4AAAAAAAAADcAAAAAlwAA cQAAAACBAACKAAAAAAAAzq3OHSMdIx0jIv////////////////////////////////////////// ////////////////////////////////////////////////////IyL/Iv8i//8jIiMiIyIjIiMi IyIjIiMit48AAABq4wAAAONNAE0ATQAAADJZAAA4WTj7OPv7+zddV1xXfZeXd5ZxloGVgbKBs7Kz rNSt1K3OziMiIyIjIyP///////////////////////////////////////////////////////// /////////////////////////////////////////yP/I///HSMdIx0jHSMdIx0jHSMdI7GPao9q amrjR+NH40dNTU0sUyxTMlMyWTg4OPs4+ztdNl1XV1aXVZdxd3CVgYGBsoqyrLOsrazOrM4dIx0j IiMd//////////////////////////////////////////////////////////////////////// //////////////////////8jIiMiIyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMi IyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMiIyIjIiMjI/////////// //////////////////////////////////////////////////////////////////////////// ////////HSMdIx0jHSMdIx0jHSMdIx0jHSMdIx0j5fs4+zg4ODg4ODI4MjgyMjIyMjIyMiwyLDIs LCwsJiwmJiYm+Sb5+fn5ICAgIB8gHx8fHx4fHh4dHh0jHSMdIyL///////////////////////// /////////////////////////////////////////////////////////////////////yMi//8j /yP//yL//////yL/IiMiIyIjIuX7+zj7OPs4ODg4ODgyODIAMjIyMjIyLDIsMiwsLCwALCYmJib5 Jvkm+fkg+SAgH0YfHx8kHh4eRB4jIiMiIyMj//////////////////////////////////////// ////////////////////////////////////////////////////////I///HSMd/x3///////8j HSMdIx0jHSN6+zj7ODg4ODg4ODgyODI4AAAyMjIyADIAMiwALCwAACYAJgAAJgAAAAAAACAgICAf Hx8fHh4eHh0eHSMdIyIjHf////////////////////////////////////////////////////// ////////////////////////////////////////IyIjIiMiIyMjIiMiIyIjIyMiIyIjIiMj5fsA AAA4AAA4ODg4ODI4MgAAOAAyMgAyACwyACwALAAsACwAJvkAAAD5JiD5IEYgIB9FHx8eRR4jHSMi IyIjIyP///////////////////////////////////////////////////////////////////// /////////////////////////x0jHSMdIx0jHSMdIx0jHSMdIx0jHSMdI3rlAOV6AADleuV65Xrl euV65XrleuV65XrleuV65XrleuV65XrleuV65XrleuV65XrleuV65XrleuUdIx0jHSMi//////// //////////////////////////////////////////////////////////////////////////// //////////8jHSIdIx0iHSMdIh0jHSIdIx0iHSMdIh0jHSIdIx0iHSMdIh0jHSIdIx3/HSMdIh0j HSIdIx3/HSMdIh0jHSIdIx3/HSMdIh0jHSIdIx0iHSMdIh0jHSIjI/////////////////////// /////////////////////////////////////////////////////////////////////////yId Ih0iHSIdIh0iHSIdIh0iHSIdIh0iHSIdIh0iHSIdIh0iHSL/Iv8i//8d/x0iHSId//8i//8d/x3/ HSId/x3//yL/Iv//HSIdIh0iHSIdIh0iHSIdIh3///////////////////////////////////// ////////////////////////////////////////////////////////////IyIjHSMiIh0jIiMd IyIiHSMiIx0jIiIdIyIjHSMiIh0jIiMd/yIi////I/8jIiId//8j////Iv8jIv8d//8iHf//Ix3/ Iv8dIyIjHSMiIh0jIiMdIyIi//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////hf//////////AAAAAAAAAP///wAAAAAAAAAA////AAAAAAAAAAD///8AAAAAAAAAAP// /wAAAAAAAAAA//////////////////9fX1+FX19fX19fX4VfX19fX19fhV9fX19fX1+FX19fX19f X4VfX19fX19fhV9fX19fX1+FX19fX19fX4VfX19fX19fhV9fX19fX1+FX19fX19fX4VfX1+F//// /////wD///////////////////////////////////////////////////////////////////// ////////////////hV+FX4VfhV+FX4VfhV+FX4VfhV+FX4VfhYqKioqKioqKioqKioqKioqKioqK ioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiopfhV+FhYX///////8A//////// ////////////////////////////////////////////////////////////AP////////////// /19fX19fX19fX19fX19fX19fX19fX19fX9XT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT 09PT09PT09PT09PT09PT09PT09PT09PT09PTX19fX4Vf////////AP////////////////////// //8AAAD//wD//wAAAAD//////////////////////////wD///////////////////9f/////4X/ /1+FX4VfhV+FX4VfhV/b09PT09PT09PT09PT09PT09PT09PT09PT09MA09MA09PTAADTANMA0wAA AADTANMAAADTANPT09PTAAAAAAAAAAD///8AAAD/////////////////////////AAAA//8A//8A /wAA//////////////////////////8A////////////////////X/9fX/9f/19fX19fhV9fX19f X1+F1dPT09PT09PT09PT09PT09PT09PT09PT09PTANPTANMA0wDT0wAAAAAAAAAA0wAA0wAA0wAA 09PT09NfX19fhV////////8A//////////////////////////////////////////////////// ////////////////AP///////////////4VfhV+FX4VfhV+FX4VfhV+FX4VfhV+FX9vTAAAA0wAA 09PT09PT09PT09PT09PT09PT0wDT0wDTAADT09PT09PT09MAANMAANPTANMA09PT09PTX4VfhYWF /////////wAA////AAAAAAAAAAD///8AAAAAAAAAAP///wAAAAAAAAAA////AAAAAAAAAAD///8A AAD///////////////9fX19fX19fX19fX19fX19fX19fX19fX1/V0wDT0wAA09PT09PT09PT09PT 09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT019fX1+FX/////////////// //////////////////////////////////////////////////////////////////////////// ////hV///4X/hf////9f//+FX4VfhV+FX4VfhV+FX4VfhV+FX4VfhV+FX4VfhV+FX4VfhV+FX4Vf hV+FX4VfhV+FX4VfhV+FX4VfhV+FX4VfhV+FX4VfhV+FX4X///////////////////////////// //////////////////////////////////////////////////////////////////9f//9fX1// X1//hf//X19fX1+FX19fX9zb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb 29vb29vb29vb29vb29vb29vbhV9fX4Vf//////////////////////////////////////////// //////////////////////////////////////////////////+FX4VfhV+FX4VfhV+FX4VfhV+F X4VfhV/i29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb 29vb29vb21+FX4WFhf////////////////////////////////////////////////////////// /////////////////////////////////////19fX1////////////9fX19fX19fX19f3Nvb29vb 29vb29vb29vb29vb2wDb2wDbAAAAAADb29sAAAAAAAAAANsAAADbAAAA2wDb2wAAANvb29tfX19f hV////////////////////////////////////////////////////////////////////////// //////////////////////9f/1+F//9fhf//////hV+FX4VfhV+FX+Lb29vb29vb29vb29vb29vb 29sA29sA2wDbAAAA2wAAAADbAAAA2wDbANsAANsAAAAAANsAAADb29vbX4VfhV+F//////////// //////////////////////////////////////////////////////////////////////////// //////9fX19fX19fhV9fX19fX1+FX19fX19fX4XcAAAA2wAA29sAAADbAAAAANvbANvbANsAANvb 29vb2wDb29vb29sA29sAANvb29vb29vb29sA29vb219fX1+FX/////////////////////////// ////////////////////////////////////////////////////////////////////hV+FX4Vf hV+FX4VfhV+FX4VfhV+FX4Vf4gDb2wAA29sAANvbAADbANvb29vb29vb29vb29vb29vb29vb29vb 29vb29vb29vb29vb29vb29vb29tfhV+FhYX///////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX4Vf////////AOfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fnAOfn5+fn5+fn 5+fn5+fn5+fn5+fn5+fn5wD///////////////9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fhf///////wDn5+fn5+fn5+fn5+fn5+fn5+fnAOfnAOfnAADnAADn5+fn5+fn5+fn5+fn5+fn 5+fn5+cA/////////////////19fXzxfPF88X19fPF88XzxfX188X/9fPF///zz//188/1////88 Xzz/X/88Xzz/PP///zz//188X////188/zz/X////zz/////X///PP///1//PF88X1////////8A 5+fn5+fn5+fn5+fn5+fn5+fn5+cA5wDnAADn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fnAP////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9f////////AOfn5+fn5+fn5+fn 5+fn5+fn5+cAAOcAAOcA5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5wD///////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wDn5+fn5+fn5+fn5+fnAOfn5+fn5+fn 5+fn5+fn5+fn5+cA5+fn5+fnAOfn5+fn5+fn5+cA//////////////////////////////////// //////////////+8krySvJK8krySvJK8krySvJK8krySvJK8krySvP+8krySvJK8krySvJK8kryS vJK8krySvJK8kry8//////////////8A5wDn5+cAAADn5wDnAADnAAAAAAAAAAAAAAAAAOcAAOfn AOcA5wDnAADnAOcAAOfn5+fnAP////////////////////////////////////////////////// krySvJK8krySvJK8krz/vP////////+8//+S////krz/vP//kv+S/5L/krySvJK8krySvJK8kryS vLz/////////////AOfnAOfnAAAA5+cAAADn5+cAAADnAOfnAAAAAADnAAAA5+fnAAAA5+fn5wAA AADnAOfn5wD//////////////////////////////////////////////////7ySvJK8krySvJK8 krySvJL/krySvP+8kv//////kv+S/5L/kv//vP+8/7ySvJK8krySvJK8krySAAAAAAAAAAAAAAAA AADnAADnAAAA5wDnAOcA5+cAAAAAAADnAADn5+fnAAAAAOfn5wAA5wDn5+cA5wAAAOfn5+cA//// //////////////////////////////////////////////+SvJK8krySvJK8krySvJK8krySvJK8 krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8vP////////////8A5+fn5+fn5+fn 5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fnAP////////////////// ////////////////////////////////vJL/krySvP////////+8kv+S//+8//+S/5L/kv+SvP// ////////kv//vJL//7z///////+SvJK8vLz//////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////////////////////// /////////////////22S/5L/km3///////+S/5L/kv//bf///22S/5L/km3/bf////+S/5L//22S bf9t////////km2SbZK8//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////kpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKS kpKSkv////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////9tkm2SbZJt km2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2S//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8AIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQD///////////8AAAAAAAD///8AAAAAAAAAAP///wAAAAAAAAAA////AAAAAAAAAAD/ //8AAAAAAAAAAP//////////////////ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhIf// //////8A//////////////////////////////////////////////////////////////////// /////////////////wAhACEAIQAhACEAIQAhACEAIQAhACEAIeT6+vr6+vr6+vr6+vr6+vr6+vr6 +vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6IQAhISEA////////AP////// /////////////////////////////////////////////////////////////wD///////////// //////8h/////yH//yEhISEhISEhISEhISHk+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+voA+gD6 +vr6AAD6APoA+gAAAAD6APoAAAD6APr6+vr6+iEhISEhIf///////wD/////AP8AAAAA//8AAP8A /wD/AAD///8A//8A//8AAAD///8A/wD///8A/wAAAAD///8A////////////////////If8hAP8A /wAhACEAIQAhACEAIQAh5Pr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6APr6APoA+gD6+gAAAAAA AAAA+gAA+gAA+gAA+vr6+vohACEAISH///////8A//8AAAD//wAA////AAD/AAAA/wD/////AAD/ AP//AP8AAP//AP8A////AP8A/wAA////AP///////////////yEhISEhISEhISEhISEhISEhISEh ISEhIeT6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+gD6AAD6AAD6+vr6+vr6+voAAPoAAPr6APoA +vr6+voAAAAAAAAAAP///wAAAP////////////////////////////////////////////////// /////////////////wD///////////////8AIQAhACEAIQAhACEAIQAhACEAIQAhACHkAAAA+gAA +voAAAD6AAAAAPr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+iEAISEh AP///////wAAAP///wAAAAAAAAAA////AAAAAAAAAAD///8AAAAAAAAAAP///wAAAAAAAAAA//// AAAA////////////////ISH//yH/If////8h//8hISEhISEhISEhIQAhIQAAISEAACEhAAAhACEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISH///////////// //////////////////////////////////////////////////////////////////////////// //////8h//8AIQD/ACH/If//ACEAIQAhACEAIQB9fX19fX19fX19fX19fX19fX19fX19fX19fX19 fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19IQAhACEh//////////////////////////// //////////////////////////////////////////////////////////////////8hISEhISEh ISEhISEhISEhISEhISEhISEAAAAAAH19fQAAAAAAfQAAAAB9fX19fX19fX19fX19fX19fX19fX19 fX19fX19fX19fX19fX19fX19fSEhISEhIf////////////////////////////////////////// /////////////////////////////////////////////////////yH/IQD/AP8A////AP8AIQAh ACEAIQAhAAB9AH19AH0AfQB9fQAAfQB9fQB9AH19AAAAAAB9fX0AAAAAAAAAAH0AAAB9AAAAfQB9 fQAAAH19fX0hACEhIQD///////////////////////////////////////////////////////// //////////////////////////////////////8h/yEh////If8h/yH/ISEhISEhISEhIcJ9fX19 fX19fX19fX19fX19fX0AfX0AfQB9AAAAfQAAAAB9AAAAfQB9AH0AAH0AAAAAAH0AAAB9fX19ISEh ISEh//////////////////////////////////////////////////////////////////////// //////////////////////8AIQAhACEAIQAhACEAIQAhACEAIQAhACGeAAAAfQAAfX0AAAB9AAAA AH19AH0AAH0AAH19fX19fQB9fX19fX0AfX0AAH19fX19fX19fX0AfX19fSEAIQAhIf////////// //////////////////////////////////////////////////////////////////////////// ////////ISEhISEhISEhISEhISEhISEhISEhISEhwgB9fQAAfX0AAH19AAB9AH19fX19fX19fX19 fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX0hISEhISH/////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhISEA////////AOfn5+fn5+fn5+fn5+fn5+fn5+cA5+fn 5+fn5+cA5+fn5+fnAOfn5+fn5+fn5+fn5+fn5wD/////////////////ACEhIQAhISEAISEhACEh IQAhISEAISEhACEhIQAhIf8A//8h/yH/If8h/yEAISEh/////wAh//8AIf//ACH/If8hISH///8h ACEhIQAhISEAISEhACEhIf///////wDn5+fn5+fn5+fnAOcAAOfnAOfnAADnAOcAAADnAOcA5wDn AADnAADn5+fn5+fn5+fn5+cA//////////////////8AIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACH/If//ACEA//8hAP8A/wD/AP//IQD/ACEA/wAhACH//wD///8AIQAhACEAIQAhACEAIQAh ACEAISH///////8A5+fn5+fn5+fn5wDn5wAA5+cA5+fn5+fnAAAA5+fnAAAAAOfn5+fn5+fn5+fn 5+fn5+fnAP////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////8h//////// AOfn5+fn5+fn5+fnAOcAAOcAAOfn5wDnAAAA5wDn5wAAAAAA5+fn5+fn5+fn5+fn5+fn5wD///// ////////////////////////////////////////////vJK8krySvJK8krySvJK8krySvJK8kryS vJK8kryS/5K8krySvJK8krySvJK8krySvJK8krySvJK8krz//////////////wDn5+fn5+fn5+fn 5wDn5+fn5+fn5+fn5+fnAOfn5+fn5+fn5+fn5+cA5+fn5+fn5+fn5+cA//////////////////// /////////////////////////////5K8krySvJK8krySvJK8kv+S/////////5L//7z///+8kv+S //+8/7z/vP+8krySvJK8krySvJK8kry8vP////////////8AAOfn5wDnAADnAAAA5wDn5+fnAADn AAAAAADnAOfn5wDnAOcAAOcAAOcA5wDn5wDnAOfnAP////////////////////////////////// //////////////+8krySvJK8krySvJK8krySvP+8kryS/5K8//////+8/7z/vP+8//+S/5L/kryS vJK8krySvJK8krySvLy8////////////AAAA5+cA5wAA5wAA5+cAAOfn5wAA5wAAAADn5wAA5+cA 5+fn5wAAAOfnAAAA5wAAAADn5wD///////////////////////////////////////////////// krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8kryS AAAAAAAAAAAAAAAAAAAAAOfnAOcA5+fn5+fnAADn5wAA5+fn5+fn5+cAAOfnAOfnAOcA5wDn5wAA AADnAOcA5+cA/////////////////////////////////////////////////7ySvJK8/7z/vJL/ ////////krz/vP//kv//vP+8kv////////+S//+8kv//vP////////+8krySvJK8vP////////// //8A5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fnAP// //////////////////////////////////////////////+SkpKSkv+S/5KS////////kv+S/5L/ /5L///+SkpL//////5L/kv//kpKS/5L/////////kpKSkpKSkrz//////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////// /////////////////////////////////22SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2S bZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJt//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////kpKSkm2SkpKSkpKSbZKSkpKSkpJtkpKSkpKSkm2SkpKSkpKSbZKSkpKS kpJtkpKSkpKSkm2SkpKSkv////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////Hh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4f//////////////////////////////////////////////////////////////// /////////////////////////////////x4eHR4eHh0eHh4dHh4eHR4eHh0eHh4dHh4eHR4eHh0e Hh4dHh4eHR4eHh0eHh4dHh4eHR4eHh0eHh4dHh4eHR4eHh0eHh4dHh4eHR4eHh0eHh4dHh4eHh7/ ////////AAAAAAAAAP///wAAAAAAAAAA////AAAAAAAAAAD///8AAAAAAAAAAP///wAAAAAAAAAA //////////////////8eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh56LCwsLCwsLCwsLCwsLCwsLCws LCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLB4eHh4eH////////wD///// //////////////////////////////////////////////////////////////8A//////////// ////Hf///x7/////////Hh4eHh0eHh4eHh4edSwsLCwAAAAAACwAACwsLCwsLCwsLCwsLCwsLCws LCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCweHh4eHh7///////8A////////AP8AAAAA//8A AP8A/wD/AAD/AP8AAAD///8A//8A//8A//8AAAAA////////AP///////////////x7/Hv8e/x4e /x4eHh4eHh4eHh4eHh4eHnosLCwsACwALCwAACwsLCwsLCwsLCwsLCwsLAAsAAAsLCwAACwALAAs AAAAACwALAAAACwALCwsLCwsHh4eHx4f////////AP////8AAAD//wAA////AAD/AAAA/wD//wD/ AP8AAP//AP//AP//AP//AP8AAP///////wD///////////////8eHh0eHh4dHh4eHR4eHh0eHh4d Hh4eHR51LCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwALCwALAAsACwsAAAAAAAAAAAsAAAsAAAs AAAsLCwsAAAAAAAAAAD///8A/wD///////////////////////////////////////////////// //////////////////8A////////////////Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eegAAACwA ACwsAAAALAAAAAAsLCwsLCwsLCwsACwAACwAACwsLCwsLCwsLAAALAAALCwALAAsLCwsLCweHh4f Hh////////8A//////////////////////////////////////////////////////////////// ////AP///////////////x7///8d//8e//8e/x3/Hh4eHh4eHR4eHnUALCwAACwsAAAsLAAALAAs LCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsHh0eHh4e/////////wAA ////AAAAAAAAAAD///8AAAAAAAAAAP///wAAAAAAAAAA////AAAAAAAAAAD///8AAAD///////// //////8e/x7/Hh4eHv//Hv8e/x4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh8eH/////////////////////////// ////////////////////////////////////////////////////////////////////Hh4dHh4e HR4eHh0eHh4dHh4eHR4eHh0eejg4OAAAAAAAOAAAAAA4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4 ODg4ODg4ODg4ODg4ODg4ODg4ODgeHh4eHh7///////////////////////////////////////// /////////////////////////////////////////////////////x7/Hv//Hv///x7/Hv8e//// Hv8eHh4eHuU4ODgAOAA4OAAAOAA4ODg4ODgAOAAAOAAAAAAAODg4AAAAAAAAAAA4AAAAOAAAADgA ODgAAAA4ODg4Hh4eHh4f//////////////////////////////////////////////////////// //////////////////////////////////////8d/x7/Hh7/Hv8eHh7/Hv///x4eHh4eHh56ODg4 ODg4ODg4ODg4ODg4ODg4ADg4ADgAOAAAADgAAAAAOAAAADgAOAA4AAA4AAAAAAA4AAAAODg4OB4e Hh4eHv////////////////////////////////////////////////////////////////////// ////////////////////////Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e5QAAADgAADg4AAAAOAAA AAA4OAA4AAA4AAA4ODg4ODgAODg4ODg4ADg4AAA4ODg4ODg4ODg4ADg4ODgeHh4fHh////////// //////////////////////////////////////////////////////////////////////////// /////////x4eHR4eHh0eHh4dHh4eHR4eHh0eHh4dHnoAODgAADg4AAA4OAAAOAA4ODg4ODg4ODg4 ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4Hh4eHh4e//////////////////////// //////////////////////////////////////////////////////////////////////8eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh8eH/////////////////////////////////////// ////////////////////////////////////////////////////////HR4dHh0eHR4dHh0eHR4d Hh0eHR4dHh0eHR4dHh0eHR4dHh0eHR4dHv//////Hh0eHf//Hv//HR4dHh3///8d//8eHR4dHh0e HR4dHh0eHR4dHh0eHR4dHh7///////////////////////////////////////////////////// //////////////////////////////////////////8dHh0eHR4dHh0eHR4dHh0eHR4dHh0eHR4d Hh0eHR4dHh0eHR4d//8eHf8dHh0e/x7/////Hf8d/////x7/Hh0eHR4dHh0eHR4dHh0eHR4dHh0e HR4dHh0f//////////////////////////////////////////////////////////////////// /////////////////////////////x0eHR4dHR0eHR4dHh0dHR4dHh0eHR0dHh0eHR4dHR0eHR4d Hh0dHR4dHh0eHR0dHh0eHR4dHR0eHR4dHh0dHR4dHh0eHR0dHh0eHR4dHR0eHR4dHh0dHf////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////5K8krySvJK8krySvJK8krySvJK8kryS vJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8kry8//////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////////// //////////////////////////////+8krySvJK8krySvJK8krySvJK8krySvP+8krySvJK8kryS vJK8krySvJK8krySvJK8krySvJK8krySvLz/////////////AOfn5+fn5+fn5+fn5+fnAADn5wDn 5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5wD///////////////////////////////// ////////////////krySvJK8krz/vP////////+8//+S////kv//vP///////5L///+S//+8/7z/ vP+8/7ySvJK8krySvLy8vP///////////wDn5+cAAOcAAAAAAAAAAAAAAAAA5wAAAAAA5wAAAOfn AADnAAAAAOcAAAAAAADn5+fn5+cA//////////////////////////////////////////////// /7ySvJK8krySvJL/krySvP+8kv//////kv///5K8/7ySvP+8krz/vP//kv///5L/kv+SvJK8kryS vJK8vP////////////8A5+fnAADnAAAAAAAAAAAA5wAA5+cAAAAAAOcAAADn5wDn5wAAAADnAAAA AAAA5+fn5+fnAP////////////////////////////////////////////////+SvJK8krySvJK8 krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJK8krySvJIAAAAAAAAAAAAA AAAAAOfn5wDnAOfn5+fn5+fn5+fn5+fnAAAA5+fn5+fn5+fn5+fn5wDn5+fn5+fn5+fn5+fn5wD/ ////////////////////////////////////////////////vJK8kryS/5K8//+S//////+S//// /7z//5L//7z/////////////kv+S////kv//////krySvJK8kry8/////////////wDn5+fn5+fn 5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+cA//////////////// /////////////////////////////////5K8krySvP+8/7z/vP///7z/vP////+S//+8//+S//+8 krz//5K8/7z///+8kv///////7ySvJK8kry8vP//////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////////////////////// //////////////////+SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2SbZJtkm2S bZJtkm2SbZJtkm2SbZJtkrz///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////5KSkpKSbZKSkpKSkpJtkpKSkpKSkm2SkpKSkpKSbZKSkpKSkpJtkpKSkpKSkm2SkpKSkpKS bZKSkpKS//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////5L///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////8DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAMAAAAGAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRl IFRpdGxlcwADAAAAAQAAAAAAUAAAAAMAAAAAAAAAIAAAAAEAAAAyAAAAAgAAADoAAAABAAAAAgAA AAYAAABzZmxhZwACAAAA6f0AAB4AAAAMAAAAMTI0MDMzODEwMgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2Dx8AAAAUAAAAX8CR4zN9AAAHAPQDAwAAAFZpc3Nl cnMIAAAAVgBpAHMAcwBlAHIAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAsAAAA1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAKB4owkC x8kBcgAAAAADAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAV30AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAAAAkVQAAAAAAAAUARABvAGMAdQBtAGUA bgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgCAAAAAAAA //////////8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAP AAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0A AAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAA ACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAA OgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAP7////+/////////0QAAABFAAAARgAAAEcAAABI AAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYA AABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAA AGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAP7//////////v///28AAAD9//// cwAAAP7////////////////////////////////////////////////////////////////////+ /wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOX CAArLPmuSAIAAAQCAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACgAAAABAAAAMgAAAAGAAAA0AAA AAcAAADYAAAACAAAAOAAAAAJAAAA6AAAAAoAAADwAAAAFwAAAPgAAAALAAAAAAEAABAAAAAIAQAA EwAAABABAAAWAAAAGAEAAA0AAAAgAQAADAAAAKIBAAACAAAA6f0AAB4AAAAIAAAAQ3VzdG9tAAAe AAAAIAAAAEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4AAAAAAwAAAFd9AAADAAAAIAAAAAMA AAABAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAGQfCwALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAAIAAAABgAAAEFyaWFsAAsAAABNUyBQR290aGljAAcAAADlrovkvZMA CgAAAFdpbmdkaW5ncwANAAAAVHJlYnVjaGV0IE1TABAAAABUaW1lcyBOZXcgUm9tYW4AEwAAAGh1 YXdlaS10ZW1wbGF0ZS1tdgAIAAAAU2xpZGUgMQAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAAD AAAABgAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRs ZXMAAwAAAAEAAAAAAFAAAAADAAAAAAAAACAAAAABAAAANAAAAAIAAAA8AAAAAQAAAAIAAAAGAAAA c2ZsYWcAAgACAAAA6f0AAB4AAAAMAAAAMTI0MDMzODEwMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8fAAAAFAAAAF/AkeMzfQAABwD0AwMAAABWaXNzZXJzCAAA AFYAaQBzAHMAZQByAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --Boundary_(ID_+DvtfYZWj9Sg8OSj2RdX0Q)-- From andy.bd.reid@bt.com Mon Apr 27 03:48:29 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D331B28C0EF for ; Mon, 27 Apr 2009 03:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.002 X-Spam-Level: *** X-Spam-Status: No, score=3.002 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBAYCFJyufVL for ; Mon, 27 Apr 2009 03:48:23 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id B24583A685A for ; Mon, 27 Apr 2009 03:48:22 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 11:49:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C725.DDE9C7B0" Date: Mon, 27 Apr 2009 11:49:39 +0100 Message-ID: In-Reply-To: <000a01c9c508$8f5bd420$1100000a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fA= From: To: X-OriginalArrivalTime: 27 Apr 2009 10:49:41.0377 (UTC) FILETIME=[DE485710:01C9C725] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 10:48:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C725.DDE9C7B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, =20 It is of course true that adding a boolean input to a logical system = increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you = identify below. There are=20 =20 - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these input = states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly. =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is = because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below). =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS = forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending = on the exact scope of the forwarding labels, a protection switch may = well require the proactive purging of entries from the AIS forwarding = label injection table following the protection switch (this could = equivalently been seen as the forwarding function proactively dropping = the AIS packets). =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a forwarding = function. But it could equally arise from a misconfiguration of the AIS = forwarding label injection table. In fact, the latter actually seems = just as likely and particularly problematic for maintenance. Unlike = normal forwarding, any mismatch between the forwarding configuration and = the AIS forwarding label injection table will lie dormant and until a = server fault arises. Then this generates a false and misunderstood fault = condition with maintenance looking for the fault in the wrong place. =20 The first two states can be reliably diagnosed with CC alone. The second = two arise from the introduction of the AIS/FDI. However, any possible = benefit that might arise is completely masked by the fact that the AIS = itself must be configured and there is no reason for this to be more = reliable than what it is supposed to be monitoring. Indeed, there seems = good reason to think that it will be less reliable. =20 There is no avoiding that AIS in circuit switching is fundamentally = different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something and = the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the = operational systems and processes are the same. =20 The simple CC replicates all the triggers to management systems made by = SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data plane AIS requires a whole new area of configuration and generates = a whole new set of fault conditions which cannot be localised by = SONET/SDH processes. So, ironically, packet AIS is directly opposed to = backwards compatibility you claim is the main drive. =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of = continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a = connection function (fabric) in the connection, which interrupts the = forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is = supported. It requires that the organization responsible for the layer = network takes action (i.e. locate the layer's connection function that = includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such = connection (due to a fault in a server layer) will also interrupt the = forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient = information to determine if the configuration in the layer's connection = functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. = This server layer fault is already reported by the server layer MEP = detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer = network fault (i.e. continuity fault). Fault localization must be = started to locate the misconfigured or failed connection function. Once = this faulty connection function is located, the configuration fault (or = hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both = fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the = performance against the SLA for the connection. =20 Regards, Maarten =09 =09 ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only = adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network = management system). A problem occuring in admin domain A will be unknown = in admin domain B. The loss of continuaity alarms that are activated in = admin domain B due to the fault in admin domain A will appear as primary = alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different = things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server = layer. AIS suppresses the LOC alarm in those cases so that the = maintenance guys don't get triggered and start looking for a fault that = is outside their area. =20 Regards, Maarten =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg = misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. If, at an end equipment, = I have a good server/section layer and a loss of CC at the client layer, = I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service = guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions = will bring some complexity . but if we have no functions, it is more = complex and difcult for operators to maintence and administrator the = network. so I think every new functions and things may have positive and = negative effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network = (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the = performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper = connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on = balance we considered not a good idea for PBB-TE OAM because it requires = a conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim.=20 =20 regards, Neil=20 =20 =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 =09 =09 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an = operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will = not be able to understand that as long as you refuse to accept that = "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated = connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro = 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated = by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and = OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to have = to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a return = > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could = be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements = > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or = management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs = seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the = pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is = a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM = packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM = MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for = performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements = section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by = > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms = of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane = content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, = but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated = > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C725.DDE9C7B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, It is of course true that adding a boolean = input to a=20 logical system increases the number of possible input states. So adding = an AIS=20 boolean to CC boolean creates four possible states not = just the=20 three you identify below. There are - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no=20 AIS We must ask what practical scenarios could = generate=20 each of these input states. Good CC, no AIS One hopes this is because this is because the = service is=20 working properly. CC fault, AIS present One hopes this is because the service is faulty = and one=20 hopes this is because of a fault in a server layer. In fact, the = presence=20 of the AIS could be misleading (see below). Good=20 CC, AIS present This=20 situation could arise because of a misconfiguration of the AIS = forwarding label=20 injection table. And there are a number of scenarios which make this = quite=20 likely when protection switching occurs. Depending on the exact scope of = the=20 forwarding labels, a protection switch may well require the proactive = purging of=20 entries from the AIS forwarding label injection table following the = protection=20 switch (this could equivalently been seen as the forwarding function = proactively=20 dropping the AIS packets). CC=20 fault, no AIS As you=20 suggest, this could arise from a misconfiguration of a forwarding = function. But=20 it could equally arise from a misconfiguration of the AIS forwarding = label=20 injection table. In fact, the latter actually seems just as likely = and=20 particularly problematic for maintenance. Unlike normal forwarding, = any=20 mismatch between the forwarding configuration and the AIS forwarding = label=20 injection table will lie dormant and until a server fault arises. Then = this=20 generates a false and misunderstood fault condition with maintenance = looking for=20 the fault in the wrong place. The=20 first two states can be reliably diagnosed with CC alone. The = second two=20 arise from the introduction of the AIS/FDI. However, any possible = benefit that=20 might arise is completely masked by the fact that the AIS itself must be = configured and there is no reason for this to be more reliable than what = it is=20 supposed to be monitoring. Indeed, there seems good reason to think that = it will=20 be less reliable. There=20 is no avoiding that AIS in circuit switching is fundamentally different = from AIS=20 in packet switching. - in circuit switching, you must fill = the bit=20 stream with something and the information injected requires no = configuration=20 whatsoever. - in packet switching, no packets is a = perfectly=20 valid condition and the injection of AIS requires individual client = connection=20 specific information to be configured. The=20 objective is not to replicate the data plane primitives of SONET/SDH, = but the=20 triggers to the operational systems so that the operational systems and=20 processes are the same. The=20 simple CC replicates all the triggers to management systems made by = SONET/SDH=20 and gives maximum compatibility. Conversely, the inclusion of data plane = AIS=20 requires a whole new area of configuration and generates a whole new set = of=20 fault conditions which cannot be localised by SONET/SDH processes. So,=20 ironically, packet AIS is directly opposed to backwards compatibility = you claim=20 is the main drive. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = =20 British=20 Telecommunications plc Registered office: 81 Newgate Street London = EC1A=20 7AJ Registered in England no. 1800000 This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 24 April 2009=20 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI does give additional information. Let = me=20 explain: The need for AIS/FDI is a consequence of the = deployment=20 of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). = The=20 objective of such CCM OAM is to be able to detect a misconfiguration = or fault=20 of a connection function (fabric) in the connection, which interrupts = the=20 forwarding of traffic in the connection. This is a fault condition = that can=20 only be discovered by the layer network in which the connection is = supported.=20 It requires that the organization responsible for the layer network = takes=20 action (i.e. locate the layer's connection function that includes = the=20 fault) to restore the connection. Unfortunately, an interruption of one of = the link connections of such connection (due to a fault in a = server=20 layer) will also interrupt the forwarding of traffic in the=20 connection. As such, loss of CC messages (LOC defect) = does not=20 provide sufficient information to determine if the configuration in = the=20 layer's connection functions along the connection have to be checked = and=20 corrected. AIS has been introduced and is used to help = differentiate=20 between the two fault cases. 1) if LOC and AIS are detected, then there is = a server=20 layer fault. This server layer fault is already reported by the server = layer=20 MEP detecting this fault. No action is required, so no alarm to=20 generate. 2) if LOC is detected and there is no AIS, = then there is=20 a layer network fault (i.e. continuity fault). Fault localization must = be=20 started to locate the misconfigured or failed connection function. = Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is=20 retored. The interruption of the forwarding of traffic = in the=20 connection in both fault cases is however registered as part of = performance=20 monitoring. This performance monitoring information is used to verify = the=20 performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points I = made. My=20 point is that AIS/FDI gives no information above what is already known = - it is=20 only adds complexity and fault liability. Neither of your points = change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009=20 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of alarm = suppression=20 in the data plane - that information is readily=20 available. I don't = believe that=20 this is a correct statement in a multi-operator transport network, = or in=20 transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring=20 in admin domain A will be unknown in admin domain B. The loss of = continuaity=20 alarms that are activated in admin domain B due to the fault in = admin domain=20 A will appear as primary alarms, suggesting connectivity problems in = admin=20 domain B. > The issue=20 arises because the two sides of maintenance want different things. = The fault=20 fixing > guys want to locate the fault and don't want any = other=20 information. The service=20 maintenance > guys want to know whether their customer service = is=20 working. This is addressed in SDH, OTN, Ethernet = and T-MPLS=20 recommendations by means of the additional SSF alarm. The SSF = alarm is=20 for the service guys telling them that the service was interrupted = due to a=20 fault in a server layer. AIS suppresses the LOC alarm in those cases = so that=20 the maintenance guys don't get triggered and start looking for a = fault that=20 is outside their area. Regards, Maarten From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two=20 things which are separate and for which AIS/FDI is no help. = Maintenance=20 operations are concerned with two separate = things. 1) Identifying faults in equipment, = line plant,=20 and other systems (eg misconfigurations) and fixing them (equipment=20 maintenance). 2) Identifying the health of end to = end=20 connections, especially when they are directly supporting customer = services=20 (service maintenance). The problem is *not* about a lack of alarm = suppression=20 in the data plane - that information is readily available. If, at an = end=20 equipment, I have a good server/section layer and a loss of CC at = the client=20 layer, I *know* the fault is elsewhere - I don't need AIS/FDI to = tell me.=20 (Indeed, if you think about, if the fault is in the end equipment, = it is=20 quite likely that the fault means it cannot report the traffic loss = to the=20 management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the = fault and=20 don't want any other information. The service maintenance guys want = to know=20 whether their customer service is working. This arose in the early days of SONET/SDH, = when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know=20 about the alarms. The normal practice is for the equipment = to report=20 the alarms *including* AIS and then a filter is applied in the = management=20 system to suppress alarms to the fault fixing guys. As I'm = aware, there=20 are many different techniques applied for the filtering algorithms,=20 especially when you consider multiple concurrent faults in a = network,=20 however, the existance of AIS/FDI doesn't add anything to these = that's not=20 already known. In fact, I believe simple time-stamp correlation = is one=20 of the most powerful and widely used techniques. And if the = equipment starts=20 messing up the reporting of loss of CC because it waiting = for/persistence=20 checking AIS/FDI, it could end up messing up simple time-stamp=20 correlation! In practice, it is often not quite a simple = as this, as=20 the service guys like to be able to 'localise' the fault. However, = under=20 most circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter = hasn't worked=20 for some reason. But the bottom line is, whatever operations = process you=20 want to use, AIS/FDI doesn't add anything other than complexity = and=20 fault liability to the equipment. Remember AIS goes back to the = TDM=20 world where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000=20 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Neil: = thank you for wasting more time = in=20 describling the problems. but I think some of what you said is no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense in=20 cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI = functions,=20 when there is a defects in a given layer network, it can cause = multiple=20 alarm events to be raised. it is diffcult for operators to = locate=20 and diagnose the faults. though I completely agree you on adding new = things and=20 functions will bring some complexity . but if we have no = functions, it is=20 more complex and difcult for operators to maintence and = administrator the=20 network. so I think every new functions and things may have = positive and=20 negative effects. but we should consider it very much, don't = delete some=20 functions at random. best=20 regards liu = <neil.2.harrison@bt.com> 2009-04-21 20:30 = =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If MPLS-TP is going to be taken seriously as a transport = network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are = these.=20 1 Provide a transparent = client/server=20 relationship...which means: - all client bits treated = equally=20 - = client=20 bit ordering preserved - no attempt to infer client symbol (ie = sequence of=20 client bits) meaning and no attempt to change client = symbols=20 - = the=20 traffic behaviour of client X must not impact the performance = experienced=20 by client Y A key corollary of = the above is=20 that MPLS-TP must only support proper connections (ie single = source=20 constructs) 2=20 Since MPLS-TP is a transport network it is not a = top-of-stack=20 network (ie it does not support directly external = message/file/stream=20 applications). MPLS-TP therefore does not require an E-NNI=20 specification. A key corollary of this is that MPLS-TP will = not have=20 any peer interworking relationship with any other network=20 mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. You = could argue=20 this should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE = (also a=20 co-ps mode network) should have FDI/AIS we concluded that on = balance it=20 was not a good idea.....and note that initially I was in favour of = having=20 AIS, but my colleagues provided strong technical arguments that = convinced=20 me otherwise. AIS/FDI is = historically linked=20 to the early PDH co-cs mode layer networks that used TTL logic. = When=20 this died it put out a +5V (all 1s) signal by default, ie it = required no=20 conscious effort to generate it.....this is key point. = Further, in=20 these networks there is a fairly static/long-holding client server = relationship. Clearly this is not true in the cl-ps mode and = it's=20 why IETF have never specified AIS for IP and its why IEEE had the = good=20 sense to throw-out AIS in 802.1ag for Ethernet (though ITU have = unwisely=20 IMO retained it in Y.1731....but I suspect any operator planning = to use=20 Ethernet equipment would always look to IEEE stds and not ITU=20 ones). AIS/FDI and the = co-ps mode is=20 debatable. As I noted above, on balance we considered not a = good=20 idea for PBB-TE OAM because it requires a conscious effort to = generate it=20 (unlike the co-cs mode) so there are likely to be scaling problems = and its=20 one more thing to go wrong. =20 You = should also have=20 seen me make the point many times in the past that the always-on = defect=20 detection/handling OAM needs to be as simple/sparse as possible = with as=20 little config as possible because we need super = reliability......TCM goes=20 completely against the grain here. Also note that the OAM = required=20 for each of the 3 network modes is not the same, despite what some = claim. regards, = Neil From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Deborah: maybe=20 what you said is right. but I can't completely agree your = opinions. IMO.=20 mpls-tp is regard as transport network like SDH/SONET. so it = should have=20 AIS/FDI fuctions as SDH/SONET. = do you think so.=20 best = regards liu = "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org 2009-04-20 = 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with Neil, = it is very=20 questionable the value of AIS/FDI in a packet network- any = mode. It can=20 result in a DoS attack by an operator on themselves so even = Y1731=20 recommends not to block data frames: "A MEP can decide whether = it=20 blocks data frames when it detects dAIS. The principle=20 requirement that influences this decision is that data frames = ought to=20 be forwarded as much as possible, without the possibility of = forwarding wrong data frames downstream." Table I.7-2 shows for = AIS,=20 not to block. And as Y1731 states, AIS can only be used = under very=20 constrained architectures - if required for MPLS-TP, it needs = to have=20 the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a point-to-point ETH connection, a MEP has = only a=20 single peer MEP. Therefore, there is no ambiguity regarding = the peer=20 MEP for which it should suppress alarms when it receives = the ETH-AIS=20 information." So should only be within one domain - then no=20 need. Deborah -----Original Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] = On Behalf Of=20 Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the = cl=20 mode?...do me a favour! Ethernet AIS is indeed a = requirement and a=20 necessity. And you will not be able to understand that as = long as=20 you refuse to accept that "cl-mode" is a forwarding mode = within a=20 **transport entity**. G.800 amendment 1 = has finally reintroduced=20 this transport entity into G.800. Besides that, it = also introduced the=20 **differentiated connection**: [G.800 am1] "A = differentiated=20 connection is a transport entity that transfers information = belonging=20 to multiple communications between ports across a subnetwork.=20 <..> In a differentiated connection = message contents are=20 interpreted to identify (sets of) communications which=20 receive different treatment. The sets of = communications may be=20 distinguished by the forwarding identifier or other layer = information.=20 Order is not necessarily preserved between messages = belonging=20 to sets of communications receiving different treatment. = Sets of=20 communications may be identified for purposes such as = traffic=20 conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 = "differentiated=20 connections". Ethernet AIS provides AIS within the scope of = such=20 "differentiated connection". If you apply this to my = proposed PTN=20 layer stack, then the EVC layer topology will consists of = EVC links=20 supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails = inside=20 metro and core domains interconnecting EVC = matrices. When one of=20 those EVC links is interrupted, e.g. in the core between metro=20 1 and metro 4 (see attached slide), then the EVC = differentiated=20 connection that is present on this link will be interrupted. = At the=20 EVC switch/bridge node in metro 4 this interruption is = noticed and=20 EVC-AIS is inserted in the downstream direction to suppress the = EVC-LOC=20 alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet=20 AIS) frame has a reserved multicast address, which guarantees = that the=20 AIS is broadcast to the endpoints of the EVC. I believe = that it is=20 time for you to adapt your view on co and cl = modes and relate it to=20 the forwarding mode **INSIDE** a transport entity. What we = know as=20 the internet is essentially an "IP differentiated connection" = with a=20 billion or more ports. What we know as an IP VPN is essentially = an "IP=20 differentiated connection" with e.g. n ports (n in the range = of e.g.=20 2 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in the = range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is = essentially an=20 "MPLS differentiated connection" with 2 ports. What we know = as a p2p=20 SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport = network=20 OAM applies to transport entities, which are (in = terms of G.800 am1)=20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; = maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp] Associated bidirectional transport=20 path requirements John, Thanks this is a great = platform to=20 explain why OAM for the 3 network modes needs to be = different.=20 I am getting a wee bit tired of folks trying to make = all 3=20 network modes look alike (and then, even worse, = interwork them as as=20 peers...esp when not not top-of-stack networks...I mean how = silly can=20 we get?). I am even more frustrated by the fact those = peddling=20 this FUD only ever seem to consider OAM and forget all other = DP/CP/MP components (esp top-of-stack = message/file/stream application=20 adaptations). How wrong can this get! In the co = modes a=20 *connection* is a very specific and = *constraining* construct.....I am=20 assuming here we respect the rules of a = connection (ie single=20 source) though some folks don't even bother to respect this,=20 and this is despite the fact that we all know what problems=20 multiple-source constructs can cause (from LDP/PHP....ergo=20 MPLS-TP). When we have a connection this restricts *all* DP = (ie=20 traffic and OAM) to stay within the bounds of the = connection.=20 Which is fine under defect-free conditions, but if we = have=20 leaking traffic then the constraining nature of the = connection=20 construct is broken. In a nutshell what this means = is that OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity defects.....indeed, why = should a=20 leaking DP have a symmetric go/return defect = behaviour?....very=20 likely it won't. So whilst request/response OAM is right for = the cl=20 mode it is not right for the co mode under misconnectivity = defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) observation = that if=20 IP (cl mode) could do it all then why have IETF found it = necessary=20 to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies=20 in the physics...and G.800 attempts to explain = that physics....G.805=20 does not. So, the 3 modes are different...please = accept/rejoice in=20 this fact as they all offer something different/important. = But=20 do not be hoodwinked by those who peddle a story that that = tries to=20 make the OAM of the 3 modes the same. regards, Neil=20 > -----Original Message----- > From:=20 mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] = On=20 Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > = To: BUSI=20 ITALO; Alexander Vainshtein; Maarten Vissers > Cc:=20 mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path > requirements > > = Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, = virtually all=20 of the > OAM functions require a return path, and in the = absence=20 of a return > path they are disabled. > > As = described=20 in David Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to be = used to=20 instantiate this forwarding. > > As an aside, the = issue of=20 return path for unidirectional LSPs could be > = charaterized as=20 the elephant in the room. In the MPLS TP OAM > = Framework I-D,=20 unicast LSPs are only mentioned three times and return > = paths not=20 at all. > > Thanks, > > John > = >=20 -----Original Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April 17,=20 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; = Maarten=20 Vissers > > Cc: mpls-tp@ietf.org > > Subject: = RE:=20 [mpls-tp] Associated bidirectional transport path > >=20 requirements > > > > John, > > = > > I=20 might have missed the agreement of MPLS-TP being capable of = > >=20 sending replies to OAM requests sent on uni-directional = LSPs. > >=20 > > This requirement does not belong to the first set of = requirements > > ITU-T is expecting to be met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken into = account=20 (at worst in a > subsequent phase). > > > = > I=20 think that this requirement needs to be evaluated versus other = >=20 > more important requirements (e.g. the possibility to work w/o = IP=20 > > forwarding and the need for OAM to continue to = monitor the=20 data > > plane also in case of failures affecting the = control or=20 management > > plane). > > > > I am = open to=20 discuss it but not sure this is the right time because > = > I=20 wish to avoid delaying the first phase of the design = solution. >=20 > > > Thanks, Italo > > > > >=20 -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E > >=20 > Sent: Thursday, April 16, 2009 8:00 PM > > > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc:=20 mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > = requirements > >=20 > > > > At the meeting last fall at Juniper in=20 Massachusetts, I > > think it was > > > = agreed that=20 an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM = packets=20 (e.g., sending > > replies to OAM > > > = requests sent=20 on uni-directional LSPs) even if it does not > > have an=20 IP > > > forwarding data plane. > > > = >=20 > > > -----Original Message----- > > > > = From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = >=20 > > > requirements > > > > > > = > >=20 Maarten, > > > > It seems that you've just = (implicitly and,=20 probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will = not ever=20 support MIP loopback function > > (and fault > > = >=20 > localization which requires this function ) for > >=20 unidirectional P2MP > > > > and P2P paths. > = >=20 > > > > > > If this statement is correct, = this (IMHO=20 and FWIW) > raises a valid > > > > = question: >=20 > > > > > > > = =20 Is MPLS-TP an appropriate solution for=20 these > types of transport > > > > = paths? >=20 > > > > > > > For the reference, IP/MPLS = provides=20 this kind of > > functionality today > > > = > for=20 (unidirectional - but it does not know any other > > = type) P2P=20 LSPs > > > > as described in RFC 4379. And its = extension to=20 P2MP LSPs seems > > > > easy... > > > = >=20 > > > > > > > > > = > >=20 > Regards, > > > > > > > > = =20 Sasha > > > > > > > > = > >=20 > > > > > >=20 ________________________________________ > > > > = From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > = On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: = Thursday, April=20 16, 2009 3:24 PM > > > > To: 'Adrian = Farrel' > >=20 > > Cc: mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp] Associated bidirectional transport path > > = > >=20 requirements > > > > > > > >=20 Adrian, > > > > > > > > >>=20 <quote> > > > > >> = The=20 intermediate nodes (including MEPs, MIPs and > > > = > other=20 internal > > > > >> = functions as=20 appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> = path at=20 each (sub-)layer MUST be aware of the pairing > > > = >=20 >> relationship of the forward and the=20 backward > > > > directions of that > > = > >=20 >> transport path. > > > = >=20 >> <end quote> > > > > > > = > >=20 > > There is no way this is a functional requirement. = That >=20 > > is, there is > > > > > *nothing* that = can be=20 observed from a black box point of > > > view = that >=20 > > > > results from adhering to this = requirement. >=20 > > > > > > > Your understanding is not = correct.=20 It is very much > observable if > > > > this=20 requirement is met from a black box point of view. > > = > >=20 The MIP functions can only perform the Loopback when there is a = >=20 > > > co-routed bidirectional transport path. The MPLS-TP = LBM=20 packet > > > > received at a MIP needs to be = returned (as=20 LBR > > > > packet) to the originating MEP function = via the=20 other > > direction of > > > > the = co-routed=20 bidirectional transport path. This other > direction > = >=20 > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > = >=20 > would fail. > > > > > > > > = Similarly,=20 when we have to apply TCM MEPs to monitor a > > segment,=20 then > > > > this is possible in a co-routed bidir=20 transport path > but not in a > > > > = associated=20 bidir transport path. In the first case the TCM MEP > > = >=20 > Source and Sink functions are co-located and can > = exchange=20 what is > > > > called "remote information" which = is=20 necessary for performance > > > > = monitoring. > >=20 > > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > > = >=20 > The entirety of the bracketted text "(including MEPs, > = >=20 > MIPs and other > > > > internal > > = > >=20 > functions as appropriate)" should be deleted. It does = not >=20 > > > add to "The > > > > > = intermediate=20 nodes." > > > > > > > > Your = understanding=20 is not correct. This text must not be > > deleted = at > >=20 > > all. > > > > > > > > > = Actually, I am quite fed up about this persistent > > = >=20 insistence on the > > > > inclusion > > = > >=20 > of "Tandem Connection." The definition within the ITU-T = of >=20 > > > this term > > > > > is > = > >=20 > poorly > > > > > specified and comes from = the=20 monitoring of a path that is > > > > parallel = (i.e. >=20 > > > tandem) > > > > > to the data = path being=20 monitored. This definition of TC > > > > seems to = be=20 at > > > > variance, > > > > > = and would=20 be if the ACH was actually in band. > > > > = > >=20 > > I don't understand where your interpretation of = tandem >=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of = a > >=20 > > path that is parallel (i.e. tandem) to the data path = being=20 > > > > monitored."? > > > > = > >=20 > > There is a "network connection" and this network > = >=20 connection is a set > > > > of interconnected "link = connections" and "matrix > connections". A > > > = >=20 subset of those interconnected link connections and matrix = > >=20 > > connections can be monitored and is then referred to = as >=20 a "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There is=20 only additional OAM inserted inside the data > path by = the >=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM = MEP_Sk=20 function. > > > > > > > > = Regards, >=20 > > > Maarten > > > > > > > = >=20 > > > > -----Original Message----- > > = > >=20 From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel > >=20 > > Sent: donderdag 16 april 2009 11:59 > > > = > To:=20 Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > >=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > = > >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > = Unfortunately I=20 cannot fully agree with your statement: > > > >=20 > > > > > > <quote> > > > = > >=20 From the point of view of hardware, = co-routed > >=20 > bidirectional LSPs > > > > > = are a=20 special case of associated bidirectional LSPs. > > > = > >=20 <end quote> > > > > > > > > = > >=20 This statement would be obviously correct, were it not for > = >=20 > > Requirement > > > > > 34 in the latest = MPLS-TP=20 requirements draft > > > > > > > > = OK. Got=20 it. > > > > > > > > But what is = this doing=20 in the data plane requirements section? > > > > = >=20 > > > In fact, what is this requirement actually = saying? >=20 > > > > > > > > <quote> > = >=20 > > > The intermediate nodes = (including MEPs,=20 MIPs and > > > other internal > > > > = >=20 functions as appropriate) of a = co-routed > >=20 > > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the=20 pairing > > > > > = relationship of=20 the forward and the backward > > > > directions of=20 that > > > > > transport=20 path. > > > > > <end quote> > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > is, there is > > > > *nothing* = that can=20 be observed from a black box point of > > view = that > >=20 > > results from adhering to this requirement. > > = >=20 > > > > > Therefore it could be assumed that = this=20 requirement is met by > > > > configuring some = data plane=20 database component through the > > > > management = plane.=20 The database component is not used > for anything > = > >=20 > except to satisfy this requirement for "awareness". > = > >=20 > > > > > Ben! Can we please try to rewrite = this=20 requirement in terms of > > > > behavior? > = >=20 > > > > > > > Please note that = Requirement 34 is=20 the ONLY item in the > > > > list that is > = > >=20 > > specific for co-routed bidirectional LSPs. (The = pairing >=20 > > > requirements > > > > > at end = points for=20 co-routed and associated bidirectional > > > paths = are >=20 > > > > exactly the same even if they appear in two=20 different > > > items in the > > > > = >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > = > >=20 bidirectional paths would be void of any data plane = content. > >=20 > > > > > > > > The somewhat vague = scope of=20 this requirement ("other internal > > > > > = functions=20 as appropriate") creates a suspicion that HW > > > = >=20 support of the > > > > > pairing awareness may = be=20 required in order to comply with it. > > > > = > >=20 > > The entirety of the bracketted text "(including = MEPs, >=20 > MIPs and other > > > > internal functions as=20 appropriate)" should be deleted. It > > does not > = >=20 > > add to "The intermediate nodes." > > > > = >=20 > > > > The following text in the draft increases this = suspicion: > > > > > > > > > > = <quote> > > > > > Tandem = Connection: A=20 tandem connection is an > > arbitrary part of a > = > >=20 > > transport path that can be monitored (via = OAM) >=20 > > > independently from the > > > > > = =20 end-to-end monitoring (OAM). It may be a monitored > = >=20 segment or a > > > > > monitored = concatenated=20 segment of a transport path. > > The = tandem > >=20 > > > connection may also include the forwarding = engine(s)=20 of > > > > the node(s) > > > > > = =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = > >=20 Actually, I am quite fed up about this persistent > > = insistence=20 on the > > > > inclusion of "Tandem Connection." = The=20 definition within > > the ITU-T of > > > > = this=20 term is poorly specified and comes from the > monitoring of=20 a > > > > path that is parallel (i.e. tandem) to = the data=20 path being > > > > monitored. This definition of = TC seems=20 to be at variance, > > and would > > > > = be if the=20 ACH was actually in band. > > > > > > = > >=20 > Doesn't "forwarding engine" sound like hardware to = you? > >=20 > > > > > > Yes, but so what? > > = > >=20 > > > > > IMHO it is worth noting that neither = the=20 MPLS-TP > > > Requirements draft > > > = > >=20 nor the MPLS-TP OAM requirements one > > > > > = >=20 > > > > > > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > > = > >=20 > > > > But tandem connections are discussed in the = MPLS-TP=20 OAM > > Framework > > > > > = draft > >=20 > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > = > >=20 > > > > > Right. > > > > Let's = just get=20 rid of an unnecessary term and bring all > the I-Ds > = >=20 > > into line. > > > > > > > = > >=20 The bottom line, IMHO, is that some clarity regarding > > = >=20 co-routed vs. > > > > > associated > > = >=20 > > bidirectional paths is still required. One way to=20 provide > > > > that could > > > > = > be=20 by explicitly limiting Requirement 34 to specific > > = >=20 functionality. > > > > > > > >=20 Agreed. > > > > > > > > = Adrian > >=20 > > > > > > > > > > > = >=20 > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: = Thursday,=20 April 16, 2009 12:13 AM > > > > To: Alexander = Vainshtein;=20 Lou Berger; BUSI ITALO > > > > Cc: = mpls-tp@ietf.org >=20 > > > Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path > > > > requirements > > > > = >=20 > > > Hi Sasha, > > > > > > > = >=20 Not really sure whether you are misrepresenting anyone, = but... >=20 > > > > > > > > 1. My reading of = one of=20 Ben's messages is that associated > > > > = >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will=20 have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > > = This is=20 clearly nonsense! > > > > From the point of view of = hardware, co-routed > > bidirectional LSPs are > = > >=20 > a special case of associated bidirectional LSPs. > > = >=20 > > > > > If you can set up two unidirectional = LSPs=20 (e.g. using the > > management > > > > = plane) you=20 can surely set up a co-routed > > > bidirectional = LSP. >=20 > > > > > > > There are shipping = solutions that=20 achieve co-routed > bidirectional > > > > = LSPs using=20 the control plane. These either use the GMPLS > > (which=20 is > > > > cleaner) or non-standard proprietary = solutions=20 (which is > > messy but > > > >=20 functional). > > > > > > > > But = (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are = software > >=20 > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the actual > = >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > > = transport networks rather than any specific benefit. > > = >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, > >=20 > > feel, and behavioral characteristics of a = "legacy" > >=20 > > transport network. > > > > > > = >=20 > > Based on these observations, I'd guess (FWIW) = that: > >=20 > > > * associated bidirectional paths are, at least for = the=20 time > > > > > being, the most = important=20 type of bidirectional paths in > > > > > =20 MPLS-TP > > > > > > > > I = think that=20 is wrong both given my statement above, and > > given=20 that > > > > other upgrades to existing MPLS = solutions will=20 be > needed to reach > > > > the full = function level=20 of MPLS-TP. > > > > > > > > > * = they had=20 a good chance to remain the only type of > >=20 bidirectional > > > > > paths in = real=20 deployments. > > > > > > > > I = don't see=20 what that follows from. > > > > > > > = >=20 Cheers, > > > > Adrian > > > > = > >=20 > > _______________________________________________ > = >=20 > > mpls-tp mailing list > > > >=20 mpls-tp@ietf.org > > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = >=20 > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > = > >=20 > > > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = >=20 > > = _______________________________________________ >=20 mpls-tp mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy and=20 are not permitted to disclose the contents of this communication = to=20 others. This email and any files transmitted with it are = confidential=20 and intended solely for the use of the individual or entity to = whom they=20 are addressed. If you have received this email in error please = notify the=20 originator of the message. Any views expressed in this message are = those=20 of the individual sender. This message has been scanned for = viruses and=20 Spam by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9C725.DDE9C7B0-- From andy.bd.reid@bt.com Mon Apr 27 04:18:49 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A686B3A68DF for ; Mon, 27 Apr 2009 04:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.427 X-Spam-Level: **** X-Spam-Status: No, score=4.427 tagged_above=-999 required=5 tests=[AWL=-1.909, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltWa6+Bu8EY5 for ; Mon, 27 Apr 2009 04:18:43 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 63B8D3A6857 for ; Mon, 27 Apr 2009 04:18:41 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 12:20:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C72A.1AF100C2" Date: Mon, 27 Apr 2009 12:19:58 +0100 Message-ID: In-Reply-To: <005601c9c6d9$38ce0b00$c302020a@lihan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAHRYX7AAEIvGoA== From: To: , X-OriginalArrivalTime: 27 Apr 2009 11:20:01.0846 (UTC) FILETIME=[1B5DDD60:01C9C72A] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:18:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C72A.1AF100C2 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Han, =20 In his post below, Maarten is not claiming that AIS is needed for alarm = suppression. He is saying that he sees it being used to distinguish = faults in a server layer from faults in the client layer. As you will = see in my post back to Maarten, this cannot be practically achieved. =20 I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, = in the packet world of MPLS-TP, AIS/FDI cannot be simple and therefore = cannot be the same as in SONET/SDH. =20 The objective is to reuse the same basic fault detection, alarm = suppression, and fault localisation as SONET/SDH. This is readily = achieved with the CC messages in the dataplane. =20 However, adding AIS/FDI would require a completely new configuration = management system and a completely new set of fault conditions requiring = localisation. Ironically, adding a packet AIS/FDI effectively removes = the compatibility with SONET/SDH management systems and processes. =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: lihan [mailto:lihan@chinamobile.com]=20 Sent: 27 April 2009 02:41 To: 'Maarten Vissers'; Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: =B4=F0=B8=B4: [mpls-tp] Associated bidirectional transport = path requirements =09 =09 Support! AIS/FDI is very importance for network management. MPLS-TP is divided = into three layers in order to enhance the scalability and OAM. It is = very important to distinguish the failure is belong to server layer or = client layer. AIS/FDI is a simple and well-known mechanism to realize = alarm suppression and fault localization.=20 =20 =20 Best regards, Han Li ***************************************************** Han Li, Ph.D. R&D, CHINA MOBILE COMMUNICATIONS CORPORATION Tel: +86 10 66006688 ext. 3092 Fax: +86 10 63601087 MOBILE: 13501093385 ***************************************************** =09 ________________________________ =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] =B4=FA=B1=ED Maarten Vissers =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C225=C8=D5 2:15 =CA=D5=BC=FE=C8=CB: andy.bd.reid@bt.com =B3=AD=CB=CD: mpls-tp@ietf.org =D6=F7=CC=E2: Re: [mpls-tp] Associated bidirectional transport path = requirements =20 Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of = continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a = connection function (fabric) in the connection, which interrupts the = forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is = supported. It requires that the organization responsible for the layer = network takes action (i.e. locate the layer's connection function that = includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such = connection (due to a fault in a server layer) will also interrupt the = forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient = information to determine if the configuration in the layer's connection = functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. = This server layer fault is already reported by the server layer MEP = detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer = network fault (i.e. continuity fault). Fault localization must be = started to locate the misconfigured or failed connection function. Once = this faulty connection function is located, the configuration fault (or = hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both = fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the = performance against the SLA for the connection. =20 Regards, Maarten =20 =09 ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only = adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 =20 =09 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network = management system). A problem occuring in admin domain A will be unknown = in admin domain B. The loss of continuaity alarms that are activated in = admin domain B due to the fault in admin domain A will appear as primary = alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different = things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server = layer. AIS suppresses the LOC alarm in those cases so that the = maintenance guys don't get triggered and start looking for a fault that = is outside their area. =20 Regards, Maarten =20 =20 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg = misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. If, at an end equipment, = I have a good server/section layer and a loss of CC at the client layer, = I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service = guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 =20 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions = will bring some complexity . but if we have no functions, it is more = complex and difcult for operators to maintence and administrator the = network. so I think every new functions and things may have positive and = negative effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements =20 =20 =20 =09 =09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network = (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the = performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper = connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on = balance we considered not a good idea for PBB-TE OAM because it requires = a conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim.=20 =20 regards, Neil=20 =20 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements =20 =20 =20 =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an = operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will = not be able to understand that as long as you refuse to accept that = "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated = connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro = 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated = by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and = OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to have = to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a return = > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could = be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements = > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or = management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs = seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the = pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is = a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM = packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM = MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for = performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements = section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by = > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms = of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane = content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, = but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated = > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C72A.1AF100C2 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Han, In his post below, Maarten is not claiming that = AIS is=20 needed for alarm suppression. He is saying that he sees it = being used=20 to distinguish faults in a server layer from faults in the client layer. = As you=20 will see in my post back to Maarten, this cannot be practically=20 achieved. I agree, in SONET/SDH, AIS/FDI is simple and = well known.=20 Unfortunately, in the packet world of MPLS-TP, AIS/FDI cannot be simple = and=20 therefore cannot be the same as in SONET/SDH. The objective is to reuse the same basic fault = detection,=20 alarm suppression, and fault localisation as SONET/SDH. This is readily = achieved=20 with the CC messages in the dataplane. However, adding AIS/FDI would require a = completely new=20 configuration management system and a completely new set of fault=20 conditions requiring localisation. Ironically, adding a packet AIS/FDI=20 effectively removes the compatibility with SONET/SDH management systems = and=20 processes. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = =20 British=20 Telecommunications plc Registered office: 81 Newgate Street London = EC1A=20 7AJ Registered in England no. 1800000 This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: lihan = [mailto:lihan@chinamobile.com]=20 Sent: 27 April 2009 02:41 To: 'Maarten Vissers';=20 Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: = =B4=F0=B8=B4:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Support! AIS/FDI is = very=20 importance for network management. MPLS-TP is divided into three = layers in=20 order to enhance the scalability and OAM. It is very important to = distinguish=20 the failure is belong to server layer or client layer. AIS/FDI is a = simple and=20 well-known mechanism to realize alarm suppression and fault = localization.=20 Best=20 regards,     Han=20 Li *****************************************************<= /SPAN> Han Li,=20 Ph.D. R&D,=20 CHINA MOBILE COMMUNICATIONS CORPORATION Tel:=20 +86 10 66006688 ext. 3092 Fax:=20 +86 10 63601087 MOBILE<= /ns0:place>: = 13501093385 ***************************************************** =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] =B4=FA=B1=ED = Maarten=20 Vissers =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C225=C8=D5 = 2:15 =CA=D5=BC=FE=C8=CB: = andy.bd.reid@bt.com =B3=AD=CB=CD: mpls-tp@ietf.org =D6=F7=CC=E2: Re: [mpls-tp] Associated bidirectional = transport path=20 requirements Andy, AIS/FDI = does give=20 additional information. Let me explain: The need = for AIS/FDI=20 is a consequence of the deployment of loss of continuity checking OAM = (e.g.=20 CCM in ethernet, CC in ATM). The objective of such CCM OAM is to be = able to=20 detect a misconfiguration or fault of a connection function (fabric) = in the=20 connection, which interrupts the forwarding of traffic in the = connection. This=20 is a fault condition that can only be discovered by the layer network = in which=20 the connection is supported. It requires that the organization = responsible for=20 the layer network takes action (i.e. locate the layer's = connection=20 function that includes the fault) to restore the=20 connection. Unfortunately, an=20 interruption of one of the link connections of such = connection (due=20 to a fault in a server layer) will also interrupt the forwarding of = traffic in=20 the connection. As such, = loss of CC=20 messages (LOC defect) does not provide sufficient information to = determine if=20 the configuration in the layer's connection functions along the = connection=20 have to be checked and corrected. AIS has = been=20 introduced and is used to help differentiate between the two fault=20 cases. 1) if LOC = and AIS are=20 detected, then there is a server layer fault. This server layer fault = is=20 already reported by the server layer MEP detecting this fault. No = action is=20 required, so no alarm to generate. 2) if LOC = is detected=20 and there is no AIS, then there is a layer network fault (i.e. = continuity=20 fault). Fault localization must be started to locate the misconfigured = or=20 failed connection function. Once this faulty connection function = is=20 located, the configuration fault (or hardware fault) can be = corrected,=20 after which the connection is retored. The = interruption of=20 the forwarding of traffic in the connection in both fault cases is = however=20 registered as part of performance monitoring. This performance = monitoring=20 information is used to verify the performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To:=20 maarten.vissers@huawei.com Cc: = mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements Maarten, These = points are=20 irrelevant to the points I made. My point is that AIS/FDI gives no = information=20 above what is already known - it is only adds complexity and fault = liability.=20 Neither of your points change this. Andy Andy=20 Reid Chief=20 Network Services Strategist = BT = Innovate            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Office: +44 (0)1277=20 322038 Mobile: +44 (0)7917=20 025451 Fax :      =20 +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com = British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no.=20 1800000 This = electronic=20 message contains information from British Telecommunications plc which = may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity = and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009 = 20:42 To: Reid,ABD,Andy,CXM = R Cc: = mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements Andy, > The = problem is=20 *not* about a lack of alarm suppression in the data plane - that = information=20 is readily available. I don't = believe=20 that this is a correct statement in a multi-operator transport = network, or=20 in transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring=20 in admin domain A will be unknown in admin domain B. The loss of = continuaity=20 alarms that are activated in admin domain B due to the fault in = admin domain=20 A will appear as primary alarms, suggesting connectivity problems in = admin=20 domain B. > The = issue=20 arises because the two sides of maintenance want different things. = The fault=20 fixing > guys want=20 to locate the fault and don't want any other information. The = service=20 maintenance > guys want=20 to know whether their customer service is = working. This is = addressed=20 in SDH, OTN, Ethernet and T-MPLS recommendations by means of the=20 additional SSF alarm. The SSF alarm is for the service guys = telling=20 them that the service was interrupted due to a fault in a server = layer. AIS=20 suppresses the LOC alarm in those cases so that the maintenance guys = don't=20 get triggered and start looking for a fault that is outside their=20 area. Regards, Maarten From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To:=20 liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path requirements Liu, Allow me = to jump=20 in. You are bringing together two things which are separate and for = which=20 AIS/FDI is no help. Maintenance operations are concerned with two = separate=20 things. 1) =20 Identifying faults in equipment, line plant, and other systems (eg=20 misconfigurations) and fixing them (equipment=20 maintenance). 2) =20 Identifying the health of end to end connections, especially when = they are=20 directly supporting customer services (service=20 maintenance). The = problem is=20 *not* about a lack of alarm suppression in the data plane - that = information=20 is readily available. If, at an end equipment, I have a good = server/section=20 layer and a loss of CC at the client layer, I *know* the fault is = elsewhere=20 - I don't need AIS/FDI to tell me. (Indeed, if you think about, if = the fault=20 is in the end equipment, it is quite likely that the fault means it = cannot=20 report the traffic loss to the management = system!) The issue = arises=20 because the two sides of maintenance want different things. The = fault fixing=20 guys want to locate the fault and don't want any other information. = The=20 service maintenance guys want to know whether their customer service = is=20 working. This = arose in the=20 early days of SONET/SDH, when the operations guys demanded that the=20 equipment did *not* suppress the traffic alarm even when AIS was = being=20 received as the service guys want to know about the alarms. The = normal=20 practice is for the equipment to report the alarms *including* = AIS and=20 then a filter is applied in the management system to suppress = alarms to=20 the fault fixing guys. As I'm aware, there are many different = techniques=20 applied for the filtering algorithms, especially when you consider = multiple=20 concurrent faults in a network, however, the existance of AIS/FDI = doesn't=20 add anything to these that's not already known. In fact, I believe=20 simple time-stamp correlation is one of the most powerful and = widely=20 used techniques. And if the equipment starts messing up the = reporting of=20 loss of CC because it waiting for/persistence checking AIS/FDI, = it=20 could end up messing up simple time-stamp=20 correlation! In = practice, it is=20 often not quite a simple as this, as the service guys like to be = able to=20 'localise' the fault. However, under most circumstances, the = filter has=20 automatically done this. So localisation you describe is = only when=20 the filter hasn't worked for some reason. But the = bottom line=20 is, whatever operations process you want to use, AIS/FDI = doesn't add=20 anything other than complexity and fault liability to the equipment. = Remember AIS goes back to the TDM world where you *have to fill = the bit=20 stream with something*. Andy Andy=20 Reid Chief=20 Network Services Strategist = BT = Innovate            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Office: +44 (0)1277=20 322038 Mobile: +44 (0)7917=20 025451 Fax :      =20 +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com = British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no.=20 1800000 This = electronic=20 message contains information from British Telecommunications plc = which may=20 be privileged or confidential. The information is intended to be for = the use=20 of the individual(s) or entity named above. If you are not the = intended=20 recipient be aware that any disclosure, copying, distribution or use = of the=20 contents of this information is prohibited. If you have received = this=20 electronic message in error, please notify us by telephone or email = (to the=20 numbers or address above) immediately. Activity = and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 = 09:15 To: Harrison,N,Neil,CXM = R Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path requirements Neil:=20 thank you for wasting = more time in=20 describling the problems. but I think some of what you said is no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense in=20 cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI = functions,=20 when there is a defects in a given layer network, it can cause = multiple=20 alarm events to be raised. it is diffcult for operators to = locate=20 and diagnose the faults. = though I completely agree = you on=20 adding new things and functions will bring some complexity . = but if=20 we have no functions, it is more complex and difcult for operators = to=20 maintence and administrator the network. so I think every new = functions=20 and things may have positive and negative effects. but we should = consider=20 it very much, don't delete some functions at = random. best regards liu=20 <neil.2.harrison@bt.com>=20 2009-04-21=20 20:30 = =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org> =D6=F7=CC=E2 RE:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Liu, If=20 MPLS-TP is going to be taken seriously as a transport network = (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. = 1=20 Provide a transparent client/server = relationship...which=20 means: -=20 all client bits treated equally -=20 client bit ordering preserved=20 -=20 no attempt to infer client symbol (ie sequence of = client=20 bits) meaning and no attempt to change client = symbols -=20 the traffic behaviour of client X must not impact the = performance experienced by client Y=20 A key=20 corollary of the above is that MPLS-TP must only support proper=20 connections (ie single source constructs)=20 2=20 Since MPLS-TP is a transport network it is not a = top-of-stack=20 network (ie it does not support directly external = message/file/stream=20 applications). MPLS-TP therefore does not require an E-NNI=20 specification. A key corollary of this is that MPLS-TP will = not have=20 any peer interworking relationship with any other network=20 mode/technology. = =20 Now=20 wrt OAM MPLS-TP is a co-ps mode network. You could argue = this should=20 have FDI/AIS....however, the merit of this is highly questionable. = When I and colleagues discussed whether PBB-TE (also a co-ps = mode=20 network) should have FDI/AIS we concluded that on balance it was = not a=20 good idea.....and note that initially I was in favour of having = AIS, but=20 my colleagues provided strong technical arguments that convinced = me=20 otherwise. = AIS/FDI=20 is historically linked to the early PDH co-cs mode layer networks = that=20 used TTL logic. When this died it put out a +5V (all 1s) = signal by=20 default, ie it required no conscious effort to generate = it.....this is key=20 point. Further, in these networks there is a fairly=20 static/long-holding client server relationship. Clearly this = is not=20 true in the cl-ps mode and it's why IETF have never specified AIS = for IP=20 and its why IEEE had the good sense to throw-out AIS in 802.1ag = for=20 Ethernet (though ITU have unwisely IMO retained it in = Y.1731....but I=20 suspect any operator planning to use Ethernet equipment would = always look=20 to IEEE stds and not ITU ones). = =20 AIS/FDI=20 and the co-ps mode is debatable. As I noted above, on = balance we=20 considered not a good idea for PBB-TE OAM because it requires a = conscious=20 effort to generate it (unlike the co-cs mode) so there are likely = to be=20 scaling problems and its one more thing to go = wrong. You=20 should also have seen me make the point many times in the past = that the=20 always-on defect detection/handling OAM needs to be as = simple/sparse as=20 possible with as little config as possible because we need super=20 reliability......TCM goes completely against the grain here. = Also=20 note that the OAM required for each of the 3 network modes is not = the=20 same, despite what some claim. = =20 regards,=20 Neil = From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 = 02:59 To: BRUNGARD, DEBORAH = A,=20 ATTLABS Cc:=20 mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Deborah: maybe what = you said=20 is right. but I can't completely agree your opinions. IMO. mpls-tp = is=20 regard as transport network like SDH/SONET. so it should have = AIS/FDI=20 fuctions as SDH/SONET. = do you = think=20 so. best=20 regards liu=20 "BRUNGARD,=20 DEBORAH A, ATTLABS" = <dbrungard@att.com>=20 =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org=20 2009-04-20=20 23:47 = =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com>=20 =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements I=20 agree with Neil, it is very questionable the value of AIS/FDI in=20 a packet network- any = mode. It can result=20 in a DoS attack by an operator on=20 themselves so even Y1731 recommends not to block data=20 frames: "A MEP can = decide whether it=20 blocks data frames when it detects dAIS. The principle = requirement that=20 influences this decision is that data frames ought to be=20 forwarded as much as = possible,=20 without the = possibility of forwarding=20 wrong data frames downstream." Table=20 I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used = under very=20 constrained architectures - if required=20 for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a = point-to-point ETH=20 connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity=20 regarding the peer MEP for which it should=20 suppress alarms when = it receives=20 the ETH-AIS=20 information." So = should only be within=20 one domain - then no need. Deborah -----Original=20 Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of Maarten=20 Vissers Sent: Monday, = April 20, 2009=20 10:05 AM To:=20 neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path requirements Neil, > but AIS/FDI in the=20 cl mode?...do me a favour! Ethernet=20 AIS is indeed a requirement and a necessity. And you will=20 not be able to understand that as long as you refuse = to accept that=20 "cl-mode" is = a forwarding mode within a **transport entity**. = G.800 amendment 1=20 has finally reintroduced this transport entity into G.800. = Besides that, it=20 also introduced the = **differentiated=20 connection**: [G.800 am1] "A=20 differentiated connection is a transport entity=20 that transfers = information belonging to=20 multiple communications between ports across a subnetwork. <..> In a = differentiated connection=20 message contents are interpreted to identify (sets of) = communications which=20 receive different treatment. The=20 sets of communications may be distinguished by=20 the forwarding = identifier or other layer=20 information. Order is not necessarily preserved between=20 messages belonging to sets of communications=20 receiving different = treatment. Sets=20 of communications may be identified for purposes such as traffic=20 conditioning or preserving communication message=20 order." Ethernet VLANs are in=20 terms of G.800 "differentiated = connections". Ethernet AIS provides AIS within=20 the scope of such "differentiated = connection". If you apply this to my proposed=20 PTN layer stack, then the EVC layer topology will consists of EVC=20 links supported by MPLS-TP, Ethernet, PBB-TE = and P-OTN VP trails inside metro and=20 core domains interconnecting EVC = matrices. When one of those EVC links is=20 interrupted, e.g. in the core between metro = 1 and metro 4 (see attached slide),=20 then the EVC differentiated connection that is present on this link will=20 be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is=20 noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC = alarms at EVC=20 endpoints D4 and D5. The EVC-AIS (i.e.=20 Ethernet AIS) frame has a reserved multicast=20 address, which = guarantees that the AIS is=20 broadcast to the endpoints of the = EVC. I believe that it is time for you to adapt = your view on co and cl=20 modes and relate it to the forwarding mode **INSIDE** a = transport entity.=20 What we know as = the internet is=20 essentially an "IP differentiated connection" with a billion or more = ports. What we know as an IP VPN is essentially an = "IP=20 differentiated connection" with e.g. n ports (n=20 in the range of e.g. 2 to 1000). What we=20 know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n=20 ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is = essentially an "MPLS=20 differentiated connection" with 2=20 ports. What we know = as a p2p SDH VC-n is=20 a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport = entities, which are (in=20 terms of G.800 am1) connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: = neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent:=20 vrijdag 17 april 2009 22:00 To:=20 John.E.Drake2@boeing.com;=20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am = getting a wee bit tired of=20 folks trying to make all 3 network modes look alike (and = then, even worse,=20 interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly=20 can we get?). I am even more frustrated = by the fact those peddling this FUD only ever = seem to consider OAM=20 and forget all other DP/CP/MP components (esp = top-of-stack=20 message/file/stream application=20 adaptations). How wrong can this get! = In the co modes a *connection* is a very = specific and=20 *constraining* construct.....I am=20 assuming here we respect the rules of a=20 connection (ie single source) though some folks don't even = bother to respect=20 this, and this is despite the fact that we all know what = problems=20 multiple-source constructs can cause=20 (from LDP/PHP....ergo MPLS-TP). When=20 we have a connection this restricts *all* DP (ie traffic and=20 OAM) to stay within the bounds of the connection. = Which is fine=20 under defect-free conditions, but if we=20 have leaking traffic then the constraining = nature of the connection construct is=20 broken. In a nutshell what this means = is that OAM that is of a=20 request/response nature cannot be trusted in co=20 mode networks under = misconnectivity=20 defects.....indeed, why should a leaking DP have a symmetric go/return=20 defect behaviour?....very likely it = won't. So whilst request/response OAM is=20 right for the cl mode it is not right for the co mode under misconnectivity=20 defect conditions. More generally the=20 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl = mode?...do me a favour!...at=20 least IEEE had the = good sense to bin this=20 for Ethernet even though it remains in Y.1731. And which is why=20 I often trot-out the rather silly (to have = to say this) observation that if IP=20 (cl mode) could do it all then why have IETF found it necessary to create=20 MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 = attempts to explain=20 that physics....G.805 = does=20 not. So, the 3 = modes are=20 different...please accept/rejoice in this fact = as they all offer something=20 different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the 3 modes=20 the same. = regards, Neil >=20 -----Original Message----- > From:=20 mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > Sent: 17 April = 2009=20 20:02 > To: BUSI = ITALO; Alexander=20 Vainshtein; Maarten Vissers > Cc:=20 mpls-tp@ietf.org > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 >=20 requirements >=20 > = Italo, > > As described in the=20 MPLS TP OAM Requirements I-D, virtually all of=20 the > OAM = functions require a=20 return path, and in the absence of a return = > path they are = disabled. >=20 > As described in = David Sinicrope's=20 meeting minutes > = = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no >=20 tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network = needs to be capable=20 of getting IP packets from >=20 destination to source; neither the minutes nor I stipulate that a=20 > control plane = needs to be used to=20 instantiate this forwarding. >=20 > As an aside, = the issue of return=20 path for unidirectional LSPs could be > charaterized as the elephant in the room. = In the MPLS=20 TP OAM > = Framework I-D, unicast LSPs=20 are only mentioned three times and return = > paths not at = all. >=20 > = Thanks, > >=20 John > > = -----Original=20 Message----- > = > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59=20 AM > > To: = Drake, John E; Alexander=20 Vainshtein; Maarten Vissers > > Cc:=20 mpls-tp@ietf.org > = > Subject: RE:=20 [mpls-tp] Associated bidirectional transport path=20 > >=20 requirements > = >=20 > > = John, > > > > I might have=20 missed the agreement of MPLS-TP being capable of = > > sending replies to OAM requests sent = on uni-directional=20 LSPs. > > = > > This requirement does not belong to = the first set of=20 requirements > = > ITU-T is=20 expecting to be met by October. > >=20 > > However, I = think this in a=20 potential interesting additional >=20 > requirement to be taken into account (at worst in=20 a > subsequent=20 phase). > >=20 > > I think = that this requirement=20 needs to be evaluated versus other >=20 > more important requirements (e.g. the possibility to work w/o = IP=20 > > forwarding = and the need for=20 OAM to continue to monitor the data >=20 > plane also in case of failures affecting the control or = management=20 > >=20 plane). > >=20 > > I am open = to discuss it but=20 not sure this is the right time because > > I wish to avoid delaying the first = phase of the design=20 solution. > >=20 > > Thanks,=20 Italo > > = > > > -----Original = Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > > > = Sent: Thursday, April=20 16, 2009 8:00 PM > = > > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc: = mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated bidirectional=20 transport path > = > >=20 requirements > = > >=20 > > > At = the meeting last fall=20 at Juniper in Massachusetts,=20 I > > think it=20 was > > > = agreed that an MPLS TP=20 network needs to have a forwarding >=20 > capability > = > > for=20 management, control, and OAM packets (e.g.,=20 sending > > = replies to=20 OAM > > > = requests sent on=20 uni-directional LSPs) even if it does not > > have an IP > >=20 > forwarding data plane. > >=20 > > > > = > -----Original=20 Message----- > = > > > From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, = 2009 9:57=20 AM > > > = > To: Maarten=20 Vissers > > = > > Cc:=20 mpls-tp@ietf.org > = > > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > >=20 requirements > = > > >=20 > > > >=20 Maarten, > > = > > It seems=20 that you've just (implicitly and, = probably, > > > > inadvertently) stated the=20 following: > > = > >=20 > > > > = =20 MPLS-TP OAM will not ever = support=20 MIP loopback function > > (and=20 fault > > > = > localization=20 which requires this function ) for >=20 > unidirectional P2MP > > >=20 > and P2P paths. > > > >=20 > > > > = If this statement is=20 correct, this (IMHO and FWIW) > raises=20 a valid > > = > >=20 question: > > = > >=20 > > > > = =20 Is MPLS-TP an appropriate = solution for these > types of=20 transport > > = > >=20 paths? > > > = >=20 > > > > = For the reference,=20 IP/MPLS provides this kind of > >=20 functionality today > > > >=20 for (unidirectional - but it does not know any=20 other > > type) = P2P=20 LSPs > > > = > as described in=20 RFC 4379. And its extension to P2MP LSPs seems = > > > > = easy... >=20 > > > > = > > >=20 > > > = >=20 > > > >=20 Regards, > > = > >=20 > > > > = =20 Sasha > > = > >=20 > > > >=20 > > > >=20 > > > >=20 ________________________________________ > > > > From: = mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > = > Of Maarten=20 Vissers [maarten.vissers@huawei.com] >=20 > > > Sent: Thursday, April 16, 2009 3:24=20 PM > > > = > To:=20 'Adrian=20 Farrel' > > >=20 > Cc: mpls-tp@ietf.org > > >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > >=20 requirements > = > > >=20 > > > > = Adrian, > > > > > >=20 > > >> <quote> >=20 > > > >> The intermediate nodes = (including MEPs, MIPs and > > >=20 > other internal > > > >=20 >> functions as appropriate) of a=20 co-routed > > = > >=20 bidirectional transport > > >=20 > >> path at each (sub-)layer MUST = be aware=20 of the pairing > = > > >=20 >> relationship of the forward and the=20 backward > > = > > directions=20 of that > > = > > >>=20 transport path. >=20 > > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > = is, there=20 is > > > = > > *nothing*=20 that can be observed from a black box point = of > > > view = that >=20 > > > > results from adhering to this=20 requirement. > = > > >=20 > > > > = Your understanding=20 is not correct. It is very much >=20 observable if > = > > > this=20 requirement is met from a black box point of=20 view. > > > = > The MIP=20 functions can only perform the Loopback when there is a=20 > > > > = co-routed=20 bidirectional transport path. The MPLS-TP LBM packet=20 > > > > = received at a MIP=20 needs to be returned (as LBR > >=20 > > packet) to the originating MEP function via the=20 other > > = direction=20 of > > > = > the co-routed=20 bidirectional transport path. This other > direction > > >=20 > would not be available in an associated bidirectional = transport=20 > > > > = path... and thus the=20 loopback test > = > > would=20 fail. > > > = >=20 > > > > = Similarly, when we=20 have to apply TCM MEPs to monitor a >=20 > segment, then > > > >=20 this is possible in a co-routed bidir transport=20 path > but not in=20 a > > > > = associated bidir=20 transport path. In the first case the TCM MEP = > > > > Source and Sink functions = are co-located and=20 can > exchange = what=20 is > > > = > called "remote=20 information" which is necessary for performance = > > > > = monitoring. > > > > In the latter case the TCM = MEP Source and Sink=20 functions > > = are in e.g.=20 > > > > = different nodes in=20 the network and TCM would not be able > > to provide > >=20 > > performance monitoring. >=20 > > > > = > > > >=20 The entirety of the bracketted text "(including=20 MEPs, > > > = MIPs and=20 other > > > = >=20 internal > > = > > >=20 functions as appropriate)" should be deleted. It does=20 not > > > = > add to=20 "The > > > = > >=20 intermediate nodes." > > > >=20 > > > > = Your understanding=20 is not correct. This text must not be > > deleted at > >=20 > > all. > = > > >=20 > > > > = > Actually, I am=20 quite fed up about this persistent >=20 > > insistence on the > >=20 > > inclusion > > > >=20 > of "Tandem Connection." The definition within the ITU-T=20 of > > > = > this=20 term > > > = > >=20 is > > > = >=20 poorly > > > = > > specified=20 and comes from the monitoring of a path that = is > > > > parallel = (i.e. > > > > = tandem) >=20 > > > > to the data path being monitored. This = definition of=20 TC > > > = > seems to be=20 at > > > = >=20 variance, > > = > > > and=20 would be if the ACH was actually in band. > > > > > >=20 > > I don't understand where your interpretation of=20 tandem > > = connection=20 is > > > = > described in ITU-T=20 recommendations. I.e. "from the > >=20 monitoring of a > = > > > path=20 that is parallel (i.e. tandem) to the data path being=20 > > > >=20 monitored."? > = > > >=20 > > > > = There is a "network=20 connection" and this network > >=20 connection is a set > > > >=20 of interconnected "link connections" and = "matrix > connections". A > >=20 > > subset of those interconnected link connections and = matrix=20 > > > > = connections can be=20 monitored and is then referred to as >=20 a "tandem > > = > >=20 connection". There is no "path that is parallel to=20 the > > data = path".=20 > > > > = There is only=20 additional OAM inserted inside the data > path by the > > >=20 > TCM MEP_So function and this OAM is extracted from=20 the > > data = path=20 by > > > = > the TCM MEP_Sk=20 function. > > = > >=20 > > > >=20 Regards, > > = > >=20 Maarten > > = > >=20 > > > >=20 > > > > = -----Original=20 Message----- > = > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Adrian = Farrel > > > > Sent: donderdag 16 april = 2009=20 11:59 > > > = > To: Alexander=20 Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO;=20 mpls-tp@ietf.org > = > > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > >=20 requirements > = > > >=20 > > > > = Hi=20 Sasha, > > > = >=20 > > > > = > Unfortunately I=20 cannot fully agree with your statement: > > > > = > >=20 > > > > <quote> >=20 > > > > From the point of view of = hardware,=20 co-routed > > = > bidirectional=20 LSPs > > > = > > =20 are a special case of associated bidirectional=20 LSPs. > > > = > > <end=20 quote> > > = > >=20 > > > > = > > This=20 statement would be obviously correct, were it not=20 for > > > = >=20 Requirement > > = > > >=20 34 = in the latest=20 MPLS-TP requirements draft > > >=20 > > > > = > OK. Got=20 it. > > > = >=20 > > > > = But what is this=20 doing in the data plane requirements = section? > > > > > >=20 > > In fact, what is this requirement actually=20 saying? > > = > >=20 > > > > = >=20 <quote> > = > > > >=20 The intermediate nodes (including MEPs, MIPs=20 and > > > = other=20 internal > > = > > > =20 functions as appropriate) of a=20 co-routed > > = > >=20 bidirectional transport > > >=20 > > path at each (sub-)layer MUST be = aware of=20 the pairing > > = > > >=20 relationship of the forward and the=20 backward > > = > > directions=20 of that > > = > > > =20 transport path. > >=20 > > > <end quote> >=20 > > > > = > > > There=20 is no way this is a functional requirement. = That > > is, there = is > >=20 > > *nothing* that can be observed from a black box point=20 of > > view=20 that > > > = > results from=20 adhering to this requirement. > >=20 > > > > = > > Therefore=20 it could be assumed that this requirement is met by=20 > > > > = configuring some=20 data plane database component through the = > > > > management plane. The = database component is=20 not used > for=20 anything > > = > > except to=20 satisfy this requirement for "awareness". > > > > > >=20 > > Ben! Can we please try to rewrite this requirement in = terms of=20 > > > >=20 behavior? > > = > >=20 > > > > = > Please note=20 that Requirement 34 is the ONLY item in = the > > > > list that = is > > > > > specific for = co-routed bidirectional=20 LSPs. (The pairing > > > >=20 requirements > = > > > > at=20 end points for co-routed and associated=20 bidirectional > = > > paths=20 are > > > = > > exactly the=20 same even if they appear in two different > > > items in = the >=20 > > > > requirements' list). > > > > > In other words, = without Requirement 34=20 the notion of >=20 co-routed > > = > > >=20 bidirectional paths would be void of any data plane=20 content. > > = > >=20 > > > > = > > The=20 somewhat vague scope of this requirement ("other internal=20 > > > > = > functions as=20 appropriate") creates a suspicion that HW > > > > support of = the > > > > > pairing awareness may = be required in=20 order to comply with it. > > >=20 > > > > = > The entirety of=20 the bracketted text "(including MEPs, > > MIPs and = other >=20 > > > internal functions as appropriate)" should be = deleted.=20 It > > does=20 not > > > = > add to "The=20 intermediate nodes." > > > >=20 > > > > = > The following=20 text in the draft increases this = suspicion: > > > > = > >=20 > > > > <quote> >=20 > > > > Tandem Connection: A tandem connection = is=20 an > > = arbitrary part of=20 a > > > > = > =20 transport path that can be monitored (via = OAM) > > > > independently from=20 the > > > = > > =20 end-to-end monitoring (OAM). It may be a=20 monitored > > = segment or=20 a > > > > = > =20 monitored concatenated segment of a transport path.=20 > > The=20 tandem > > > = > > =20 connection may also include the forwarding engine(s)=20 of > > > = > the=20 node(s) > > = > > > =20 at the edge(s) of the segment or concatenated=20 segment. > > = > > > <end=20 quote> > > = > >=20 > > > > = Actually, I am quite=20 fed up about this persistent > >=20 insistence on the > > > >=20 inclusion of "Tandem Connection." The definition=20 within > > the = ITU-T=20 of > > > = > this term is=20 poorly specified and comes from the >=20 monitoring of a > = > > > path=20 that is parallel (i.e. tandem) to the data path being=20 > > > > = monitored. This=20 definition of TC seems to be at variance, > > and would > >=20 > > be if the ACH was actually in = band. > > > > > >=20 > > > Doesn't "forwarding engine" sound like hardware to=20 you? > > > = >=20 > > > > = Yes, but so=20 what? > > > = >=20 > > > > = > IMHO it is=20 worth noting that neither the MPLS-TP > > > Requirements = draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > = > >=20 > > > >=20 > > > = > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain = any requirements=20 dealing with tandem > > >=20 connections. > = > > >=20 > > > > = > > But tandem=20 connections are discussed in the MPLS-TP = OAM > > Framework > >=20 > > > draft > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > = amework-00.txt > > > > = ). > >=20 > > > > = > >=20 Right. > > > = > Let's just get=20 rid of an unnecessary term and bring all > the I-Ds > > > >=20 into line. > > = > >=20 > > > > = > The bottom=20 line, IMHO, is that some clarity = regarding > > > co-routed = vs. >=20 > > > > associated > >=20 > > > bidirectional paths is still required. One way to=20 provide > > = > > that=20 could > > > = > > be by=20 explicitly limiting Requirement 34 to = specific > > > = functionality. > > > > > >=20 > > Agreed. > > > >=20 > > > > = Adrian > > > > > >=20 > > > > = > >=20 > > > >=20 > > > >=20 ________________________________________ > > > > From: Adrian=20 Farrel = [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, = 2009 12:13=20 AM > > > = > To: Alexander=20 Vainshtein; Lou Berger; BUSI ITALO >=20 > > > Cc: mpls-tp@ietf.org >=20 > > > Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path > > > = >=20 requirements > = > > >=20 > > > > = Hi=20 Sasha, > > > = >=20 > > > > = Not really sure=20 whether you are misrepresenting anyone, = but... > > > > > >=20 > > > 1. My reading of one of Ben's messages = is that=20 associated > > = > > >=20 bidirectional paths are the only types of paths that can=20 be > > > = > created=20 in > > > = > > the existing=20 networks; "true" co-routed bidirectional = paths > > > > will = have > > > > > to wait until (if = ever) new equipment=20 becomes available. > > > >=20 > > > > = This is clearly=20 nonsense! > > = > > From the=20 point of view of hardware, co-routed >=20 > bidirectional LSPs are > >=20 > > a special case of associated bidirectional=20 LSPs. > > > = >=20 > > > > = If you can set up=20 two unidirectional LSPs (e.g. using the > > management > >=20 > > plane) you can surely set up a=20 co-routed > > = > bidirectional=20 LSP. > > > = >=20 > > > > = There are shipping=20 solutions that achieve co-routed >=20 bidirectional > = > > > LSPs=20 using the control plane. These either use the=20 GMPLS > > = (which=20 is > > > = > cleaner) or=20 non-standard proprietary solutions (which = is > > messy but > >=20 > > functional). > > >=20 > > > > = > But (of course)=20 the management plane or control plane > > solutions = have >=20 > > > nothing to do with availability of equipment as=20 they > are=20 software > > = > >=20 solutions. > > = > >=20 > > > > = > 2. My reading=20 of one of Neil's messages is that the = actual > > > > driver = for > > > > > co-routed = bidirectional paths may be=20 experience with existing > > >=20 > > transport networks rather than any specific=20 benefit. > > = > >=20 > > > > = Isn't that the case=20 with 75% of the MPLS-TP requirements? > > > > Which is not to say it is = a bad=20 thing. > > > = >=20 > > > > = A large driver for=20 MPLS-TP is to give the packet network > > the look, > >=20 > > feel, and behavioral characteristics of a=20 "legacy" > > = > > transport=20 network. > > = > >=20 > > > > = > Based on these=20 observations, I'd guess (FWIW) that: >=20 > > > > * associated bidirectional paths are, at least = for the=20 time > > > = > > =20 being, the most important type of bidirectional paths=20 in > > > = > > =20 MPLS-TP > = > > >=20 > > > > = I think that is=20 wrong both given my statement above, and > > given that > >=20 > > other upgrades to existing MPLS solutions will=20 be > needed to=20 reach > > > = > the full=20 function level of MPLS-TP. > > >=20 > > > > = > > * they had=20 a good chance to remain the only type of > > = bidirectional > >=20 > > > paths in real=20 deployments. > = > > >=20 > > > > = I don't see what=20 that follows from. > > > >=20 > > > >=20 Cheers, > > = > > Adrian > > > > > >=20 > >=20 = _______________________________________________ > > > > mpls-tp mailing = list > > > > = mpls-tp@ietf.org > > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > >=20 > >=20 = _______________________________________________ > > > > mpls-tp mailing = list > > > > = mpls-tp@ietf.org > > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > >=20 > > > > = >=20 = _______________________________________________ > > > mpls-tp mailing = list > > > = mpls-tp@ietf.org > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 >=20 = _______________________________________________ > mpls-tp mailing = list >=20 mpls-tp@ietf.org > = = https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp<= /TT> -----------------------------------------------------= --- ZTE Information Security Notice: The = information contained in this=20 mail is solely property of the sender's organization. This mail=20 communication is confidential. Recipients named above are = obligated to=20 maintain secrecy and are not permitted to disclose the contents of = this=20 communication to others. This email and=20 any files transmitted with it are confidential and intended solely = for the=20 use of the individual or entity to whom they are addressed. If you = have=20 received this email in error please notify the originator of the = message.=20 Any views expressed in this message are those of the individual=20 sender. This message = has been scanned for=20 viruses and Spam by ZTE Anti-Spam=20 system. --------------------------------------------------------= ZTE Information Security Notice: The infor= mation contained in this mail is solely&nbs= p;property of the sender's organization. This&nb= sp;mail communication is confidential. Recipients&nbs= p;named above are obligated to maintain sec= recy and are not permitted to disclose = ;the contents of this communication to othe= rs. This email and any files transmitted = with it are confidential and intended solel= y for the use of the individual or&nbs= p;entity to whom they are addressed. If&nbs= p;you have received this email in error&nbs= p;please notify the originator of the messa= ge. Any views expressed in this message&nbs= p;are those of the individual sender.= This message has been scanned for vir= uses and Spam by ZTE Anti-Spam system.= ------_=_NextPart_001_01C9C72A.1AF100C2-- From Rolf.Winter@nw.neclab.eu Mon Apr 27 04:27:51 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4283A6CEE for ; Mon, 27 Apr 2009 04:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[AWL=-2.266, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_93=0.6, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsIfmDfvIg0f for ; Mon, 27 Apr 2009 04:27:46 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4E7573A6B29 for ; Mon, 27 Apr 2009 04:27:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id CE93A2C00030D; Mon, 27 Apr 2009 13:29:05 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7JV2jACb6up; Mon, 27 Apr 2009 13:29:05 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 76E542C000305; Mon, 27 Apr 2009 13:28:55 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9C72B.59891A4C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 27 Apr 2009 13:28:48 +0200 Message-ID: <547F018265F92642B577B986577D671C882000@VENUS.office> In-Reply-To: <60ac7f5a82d1903674568d2f0daf4bd0.squirrel@webmail.elverljung.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] updated process draft Thread-Index: AcnBqmKodvTlteRQRQCyGHDMpuwWkwFZ7qRA References: <60ac7f5a82d1903674568d2f0daf4bd0.squirrel@webmail.elverljung.se> From: "Rolf Winter" To: , Subject: Re: [mpls-tp] updated process draft X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:27:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C72B.59891A4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Loa, Here are a bunch of comments and edits. They are all in the file that I = attached. I am not a native English speaker myself so feel free to = ignore the changes. I also added a diff output for your convenience. Points to look out for in particular: There was some text weirdness in point 13 in the list. Please check I = got it right. I think it was some copy&paste incident and I removed some = text as it re-appears later. Also please check point 15 for similar reasons carefully. In section 3, I added point 13 and 14 where IETF and ITU-T processes = intersect (maybe you disagree). I personally find the wording in section 4 misleading as it can be read = in a way as to suggest that the ITU-T might work on MPLS-TP according to = its own processes within the ITU-T. But I don't think that this is = permissible. If you like, I can come up with an alternative wording for = that section. With respect to the recent TCM discussion, maybe it would be worth = noting down in the document that the JWT decision is not to be followed = religiously but might need re-consideration in certain aspects. As long = as rough consensus is reach within the WG and the ITU-T has no = objections, divergence from the JWT decision is regarded as appropriate. = If you like I could provide text for this as well. I hope I didn't add more errors than I fixed. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Loa Andersson > Sent: Montag, 20. April 2009 13:23 > To: mpls-tp@ietf.org > Subject: [mpls-tp] updated process draft >=20 > All, >=20 > I've updated the MPLS-TP draft >=20 > http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process- > 01.txt >=20 > This draft is still woek in progress, and I'm not sure I intend to > progress it to wg draft or RFC, nevertheless this document is the > document that guides how the MPLS-TP drafts are managed- >=20 > The document is in need of a grammar and spelling review, anyone that > wants to undertaken that task is welcome. >=20 > /Loa >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp ------_=_NextPart_001_01C9C72B.59891A4C Content-Type: text/plain; name="draft-andersson-mpls-tp-process-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-andersson-mpls-tp-process-01.txt Content-Disposition: attachment; filename="draft-andersson-mpls-tp-process-01.txt" DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEwuIEFuZGVyc3Nvbg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSZWRiYWNrIE5ldHdvcmtzDQpJbnRlbmRlZCBzdGF0dXM6IFN0 YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEQuIFdhcmQNCkV4 cGlyZXM6IE9jdG9iZXIgMjIsIDIwMDkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Q2lzY28gU3lzdGVtcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE0uIEJldHRzDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3J0ZWwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAy MCwgMjAwOQ0KDQoNCiBKb2ludCBJRVRGIGFuZCBJVFUtVCBNdWx0aS1Qcm90b2NvbCAgTGFiZWwg U3dpdGNoaW5nIChNUExTKSBUcmFuc3BvcnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQ cm9maWxlIHByb2Nlc3MNCiAgICAgICAgICAgICAgICAgZHJhZnQtYW5kZXJzc29uLW1wbHMtdHAt cHJvY2Vzcy0wMS50eHQNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIEludGVybmV0 LURyYWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUN CiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90 ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQg bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRz IGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy YWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYv MWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRv dyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gT2N0 b2JlciAyMiwgMjAwOS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIw MDkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3Vt ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0K ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvKS4NCiAgIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIGNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cw0KICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRo IHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4NCg0KDQoNCg0KDQpBbmRlcnNzb24sIGV0IGFsLiAg ICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgIE1QTFMtVFAgZG9jdW1lbnQgcHJvY2VzcyAgICAgICAg ICAgICAgQXByaWwgMjAwOQ0KDQoNCkFic3RyYWN0DQoNCiAgIFRoZSBlZmZvcnQgdG8gZGV2ZWxv cCBhIE11bHRpLXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykNCiAgIFRyYW5zcG9ydCBQ cm9maWxlIGluIGNvb3BlcmF0aW9uIGJldHdlZW4gdGhlIElFVEYgYW5kIHRoZSBJVFUtVCBsYWNr cw0KICAgYSB3ZWxsIGRlZmluZWQgcHJvY2VzcyBmb3IgdGhlIGRldmVsb3BtZW50IG9mIHRoZSBy ZXF1aXJlZCBSRkNzLg0KDQogICBUaGlzIGRvY3VtZW50IGNvbXBsZW1lbnRzIHRoZSBwcm9jZXNz IGFzIGRvY3VtZW50ZWQgaW4gdGhlIEpXVA0KICAgZGVjaXNpb24gd2l0aCBhIGNvdXBsZSBvZiBh ZGRpdGlvbmFsIGVsZW1lbnRzDQoNCiAgIG8gIEFuIGFkYXB0YXRpb24gb2YgdGhlIElFVEYgd29y a2luZyBncm91cCBwcm9jZXNzLg0KDQogICBvICBUaGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIGV4 cGVjdGVkIElUVS1UIHBhcnRpY2lwYXRpb24gZHVyaW5nIHRoaXMgcHJvY2Vzcy4NCg0KICAgbyAg QSBjbGFyaWZpY2F0aW9uIG9mIHRoZSBkZWNpc2lvbiBydWxlcyByZWdhcmRpbmcgTVBMUy1UUCBk b2N1bWVudHMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW50ZW5kIHRvIHNwZWNpZnkg YW55IElUVS1UIHByb2Nlc3MuIFRvIHRoZQ0KICAgZXh0ZW50IHRoYXQgaXMgbmVjZXNzYXJ5IGl0 IHdpbGwgYmUgZG9uZSBieSB0aGUgSVRVLVQgYWNjb3JkaW5nDQogICB0byBpdHMgb3duIHByb2Nl c3Nlcy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkFuZGVyc3NvbiwgZXQgYWwuICAgICAgIEV4cGlyZXMgT2N0b2JlciAy MiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNzICAgICAgICAgICAgICBBcHJpbCAyMDA5DQoNCg0K VGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDEuMS4gIFRlcm1pbm9s b2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAg ICAgICAxLjEuMS4gIElFVEYgdGVybXMgYW5kIGFiYnJldmlhdGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNA0KICAgICAgIDEuMS4yLiAgSVRVLVQgdGVybXMgYW5kIGFiYnJldmlhdGlv bnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAyLiAgQWRhcHRhdGlvbiBvZiB0aGUg SUVURiB3b3JraW5nIGdyb3VwIHByb2Nlc3MgLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgMi4x LiAgQWRhcHRhdGlvbiBvZiB0aGUgSUVURiB3b3JraW5nIGdyb3VwIHByb2Nlc3MgLiAuIC4gLiAu IC4gLiAgNg0KICAgICAyLjIuICBUaGUgSUVURiBNUExTLVRQIHByb2Nlc3MgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgICAgMi4yLjEuICBEZXZlbG9waW5nIGEgTVBM Uy1UUCBkb2N1bWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIDMuICBFeHBlY3Rh dGlvbnMgb24gSVRVLVQgcGFydGljaXBhdGlvbiBpbiB0aGUgcHJvY2VzcyAuIC4gLiAuIC4gLiAx Mg0KICAgICAzLjEuICBCZWNvbWluZyBhIE1FQUQgdGVhbSBkb2N1bWVudCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEyDQogICAgIDMuMi4gIENvbW1lbnRzIG9uIE1FQUQgdGVhbSBkb2N1 bWVudHMgYnkgcGFydGljaXBhbnRzIGluIHRoZQ0KICAgICAgICAgICBJVFUtVCAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAgIDMuMy4g IFBvbGwgZm9yIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTINCiAgICAgMy40LiAgUmVzcG9uZGluZyB0byBhbiBJRVRGIFdvcmtpbmcgR3JvdXAgTGFz dCBDYWxsICAuIC4gLiAuIC4gLiAxMw0KICAgNC4gIFNwZWNpZmljIGd1aWRlbGluZXMgdGhhdCBh cHBseSB0byB3b3JrIG9uIE1QTFMtVFAgaW4gdGhlDQogICAgICAgSVRVLVQgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgIDUuICBJ QU5BIGNvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNQ0KICAgNi4gIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICA3LiAgQWNrbm93bGVkZ21lbnRzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgIDguICBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx OA0KICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE4DQogICAgIDguMi4gIEluZm9ybWF0aXZlIHJlZmVyZW5jZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgIEF1dGhvcnMnIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFuZGVyc3Nv biwgZXQgYWwuICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwOSAgICAgICAgICAgICAgICBb UGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgTVBMUy1UUCBkb2N1bWVudCBwcm9j ZXNzICAgICAgICAgICAgICBBcHJpbCAyMDA5DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBX aGVuIHRoZSBJRVRGIGFuZCB0aGUgSVRVLVQgZW50ZXJlZCBpbnRvIGFuIGFncmVlbWVudCB0byBk ZXZlbG9wIE1QTFMtVFAgDQogICAtIHRoZSBKV1QgYWdyZWVtZW50IC0gaXQgd2FzIGRlY2lkZWQg dGhhdCB0aGUgTVBMUy1UUA0KICAgZG9jdW1lbnRzIHNob3VsZCBiZSBkZXZlbG9wZWQgImFjY29y ZGluZyB0byBJRVRGIHByb2Nlc3NlcyIuICBBZGRpdGlvbmFsbHksIA0KICAgYSBjbG9zZSBjb29w ZXJhdGlvbiBmb3IgdGhlIHJldmlldyBwcm9jZXNzIG9mIHRoZXNlIElFVEYNCiAgIGRvY3VtZW50 cyB3YXMgYXNzdW1lZC4gVGhlIEpXVCBkZWNpc2lvbiBpcyBkb2N1bWVudGVkIGluIFJGQyA1MzE3 IFtSRkM1MzE3XS4NCg0KICAgSG93ZXZlciwgdGhlIHByb2Nlc3MgZm9yIHRoaXMgY2xvc2UgY29v cGVyYXRpdmUgcmV2aWV3IHdhcyBtb3N0bHkNCiAgIGxlZnQgdG8gYmUgZGVjaWRlZCBhcyB0aGUg ZG9jdW1lbnRzIGV2b2x2ZS4gIFRoZSBJVFUtVCBjb21taXR0ZWQgdG8NCiAgIHJlc3BvbmRpbmcg cHJvbXB0bHkgdG8gSUVURiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbHMsIHdoaWNoIG1pZ2h0DQog ICByZXF1aXJlIHRoZSBkZXZlbG9wbWVudCBvZiBzdWNoIHJlc3BvbnNlcyB2aWEgRW1haWwgY29y cmVzcG9uZGVuY2UuDQoNCiAgIFRoaXMgZG9jdW1lbnQgY29tcGxlbWVudHMgdGhlIHByb2Nlc3Mg YXMgZG9jdW1lbnRlZCBpbiB0aGUgSldUDQogICBkZWNpc2lvbiB3aXRoIGEgZmV3IG9mIGFkZGl0 aW9uYWwgZWxlbWVudHM6DQoNCiAgIG8gIEFuIGFkYXB0YXRpb24gb2YgdGhlIElFVEYgd29ya2lu ZyBncm91cCBwcm9jZXNzIHdpdGggcmVzcGVjdCB0bw0KICAgICAgdGhlIHJvbGUgb2YgdGhlIE1F QUQgKE1QTFMgSW50ZXJvcGVyYWJpbGl0eSBEZXNpZ24pIHRlYW0sIHRoZSANCiAgICAgIEpvaW50 IFdvcmtpbmcgVGVhbSAoSldUKSBhbmQgdGhlIElUVS1UIE1QTFMtVFAgYWQgaG9jDQogICAgICB0 ZWFtIHRoYXQgaGF2ZSBiZWVuIHNldCB1cCB0byBmYWNpbGl0YXRlIHRoZSBkZXZlbG9wbWVudCBv Zg0KICAgICAgTVBMUy1UUDsgc2VlIFNlY3Rpb24gMi4NCg0KICAgbyAgVGhlIGlkZW50aWZpY2F0 aW9uIG9mIHRoZSBleHBlY3RlZCBJVFUtVCBwYXJ0aWNpcGF0aW9uIGR1cmluZyB0aGUgZG9jdW1l bnQNCiAgICAgIGRldmVsb3BtZW50IHByb2Nlc3M7IHNlZSBTZWN0aW9uIDMuDQogICAgICANCg0K ICAgbyAgQSBjbGFyaWZpY2F0aW9uIG9mIHRoZSBkZWNpc2lvbiBydWxlcyByZWdhcmRpbmcgTVBM Uy1UUCBkb2N1bWVudHM7DQogICAgICBzZWUgU2VjdGlvbiA0Lg0KDQogICBUaGUga2V5IHdvcmRz ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQog ICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJ T05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2Ny aWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoNCjEuMS4gIFRlcm1pbm9sb2d5DQoNCiAgIFRo aXMgc2VjdGlvbiBpbmNsdWRlcyBhIG51bWJlciBvZiB0ZXJtcyBhbmQgYWJicmV2aWF0aW9ucyB0 aGF0IGFyZQ0KICAgdXNlZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhlIHNlY3Rpb24gaXMgc3BsaXQg aW50byB0d28gc3Vic2VjdGlvbnM7DQogICBJRVRGIHRlcm1zIGFuZCBJVFUtVCB0ZXJtcy4NCg0K MS4xLjEuICBJRVRGIHRlcm1zIGFuZCBhYmJyZXZpYXRpb25zDQoNCiAgIG8gIEpXVCAtIEpvaW50 IFdvcmtpbmcgVGVhbSwgYSB0ZWFtIG9mIGV4cGVydHMgd2l0aCBleHBlcmllbmNlDQogICAgICBp biBib3RoLCBzdGFuZGFyZHMgZGV2ZWxvcG1lbnQgaW4gdGhlIElFVEYgYW5kIHRoZSBJVFUtVC4N Cg0KICAgICAgTm90ZTogVGhlIEpXVCBpcyBub3QgcGFydCBvZiBlaXRoZXIgdGhlIElFVEYgb3Ig SVRVLVQsIGJ1dCBhIGdyb3VwDQogICAgICB0aGF0IGhhcyBiZWVuIHNldCB1cCB0byBmYWNpbGl0 YXRlIGNvb3BlcmF0aW9uIG9uIE1QTFMtVFAgYmV0d2Vlbg0KICAgICAgdGhlIHR3byBvcmdhbml6 YXRpb25zLg0KDQoNCg0KDQoNCkFuZGVyc3NvbiwgZXQgYWwuICAgICAgIEV4cGlyZXMgT2N0b2Jl ciAyMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNzICAgICAgICAgICAgICBBcHJpbCAyMDA5DQoN Cg0KICAgbyAgSldUIGRvY3VtZW50cyAtIHRoZSBzZXQgb2YgZG9jdW1lbnRzIHRoYXQgd2VyZSBl bnZpc2lvbmVkIGF0IHRoZQ0KICAgICAgdGltZSB0aGUgSldUIGRlY2lzaW9uIHdhcyB3cml0dGVu IGRvd24NCg0KICAgbyAgTUVBRCB0ZWFtIC0gTVBMUyBJbnRlcm9wZXJhYmlsaXR5IERlc2lnbiBU ZWFtLCBhIHRlbXBvcmFyeSB0ZWFtDQogICAgICBvZiBleHBlcnRzIHdpdGggZXhwZXJpZW5jZSBp biBzdGFuZGFyZHMgZGV2ZWxvcG1lbnQgZm9yDQogICAgICBNUExTIGFuZCB0cmFuc3BvcnQgbmV0 d29ya3MuICBUaGUgTUVBRCB0ZWFtIGlzIGNoYXJ0ZXJlZCB0bw0KICAgICAgY29vcmRpbmF0ZSB0 aGUgZGV2ZWxvcG1lbnQgb2YgTVBMUy1UUCB3aXRoaW4gdGhlIElFVEYgYW5kIHRvDQogICAgICBj b29yZGluYXRlIHRoZSBjb29wZXJhdGlvbiB3aXRoIHRoZSBJVFUtVCBvbiBNUExTLVRQLg0KDQog ICBvICBNUExTLVRQIGRvY3VtZW50cyAtIHRoZSBmb2xsb3dpbmcgc2V0cyBvZiBkb2N1bWVudHMg YXJlIGNvbnNpZGVyZWQgdG8gYmUNCiAgICAgIE1QTFMtVFAgZG9jdW1lbnRzOg0KDQogICAgICAq ICBJbnRlcm5ldCBEcmFmdHMgdGhhdCBhcmUgY29vcmRpbmF0ZWQgYnkgdGhlIE1FQUQgdGVhbS4N Cg0KICAgICAgKiAgSW5kaXZpZHVhbCBJbnRlcm5ldCBEcmFmdHMgdGhhdCBhZGRyZXNzIHRoZSBN UExTLVRQIHByb2JsZW0NCiAgICAgICAgIHNwYWNlLg0KDQogICAgICAqICBXb3JraW5nIGdyb3Vw IEludGVybmV0IERyYWZ0cyB0aGF0IGFkZHJlc3MgdGhlIE1QTFMtVFANCiAgICAgICAgIHByb2Js ZW0gc3BhY2UuDQoNCiAgICAgICogIEludGVybmV0IERyYWZ0cyB0aGF0IGFyZSBjb25zaWRlcmVk IGZvciBwdWJsaWNhdGlvbiBieSB0aGUgSUVTRw0KICAgICAgICAgYW5kIHRoYXQgYWRkcmVzcyB0 aGUgTVBMUy1UUCBwcm9ibGVtIHNwYWNlLg0KDQogICAgICAqICBJbnRlcm5ldCBEcmFmdHMgdGhh dCBhcmUgYXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9uIGJ5IHRoZSBJRVNHDQogICAgICAgICBhbmQg dGhhdCBhZGRyZXNzIHRoZSBNUExTLVRQIHByb2JsZW0gc3BhY2UuDQoNCiAgICAgICogIFB1Ymxp c2hlZCBSRkNzIHRoYXQgYWRkcmVzcyB0aGUgTVBMUy1UUCBwcm9ibGVtIHNwYWNlLg0KDQogICAg ICAqICBJVFUtVCBSZWNvbW1lbmRhdGlvbnMgYW5kIGRyYWZ0IFJlY29tbWVuZGF0aW9ucyBpbiB2 YXJpb3VzDQogICAgICAgICBzdGFnZXMgb2YgZGV2ZWxvcG1lbnQgdGhhdCBhZGRyZXNzIHRoZSBN UExTLVRQIHByb2JsZW0gc3BhY2UuDQoNCiAgIERvY3VtZW50cyB0aGF0IG9yaWdpbmF0ZSBmcm9t IHRoZSBJUlRGIFJGQyBzdHJlYW0gYXJlIE5PVCBjb25zaWRlcmVkDQogICB0byBiZSBNUExTLVRQ IGRvY3VtZW50cy4NCg0KMS4xLjIuICBJVFUtVCB0ZXJtcyBhbmQgYWJicmV2aWF0aW9ucw0KDQog ICBvICBBZCBIb2Mgb24gTVBMUy1UUCAtIEEgdGVhbSBlc3RhYmxpc2hlZCBieSBTRyAxNSBvZiB0 aGUgSVRVLVQgdG8NCiAgICAgIGNvb3JkaW5hdGUgdGhlIHdvcmsgb24gTVBMUy1UUCB3aXRoaW4g dGhlIElUVS1UIGFuZCB0byBhY3QgYXMgYQ0KICAgICAgZm9jYWwgcG9pbnQgZm9yIGNvbW11bmlj YXRpb24gd2l0aCB0aGUgSUVURi4NCg0KICAgbyAgQ29udHJpYnV0aW9uIC0gYSBjb250cmlidXRp b24gaXMgYSBkb2N1bWVudCB0aGF0IGlzIHN1Ym1pdHRlZCB0bw0KICAgICAgdGhlIElUVS1UIHRv IGFkdmFuY2Ugd29yayBvbiB0aGUgZGV2ZWxvcG1lbnQgb2YgYSBSZWNvbW1lbmRhdGlvbg0KICAg ICAgb3IgdG8gcHJvcG9zZSB0aGUgZGV2ZWxvcG1lbnQgb2YgYSBuZXcgUmVjb21tZW5kYXRpb24u DQoNCiAgIG8gIFJlY29tbWVuZGF0aW9uIC0gYSBSZWNvbW1lbmRhdGlvbiBpcyBhbiBJVFUtVCBz dGFuZGFyZHMgZG9jdW1lbnQuDQoNCg0KDQoNCg0KDQpBbmRlcnNzb24sIGV0IGFsLiAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgIE1QTFMtVFAgZG9jdW1lbnQgcHJvY2VzcyAgICAgICAgICAgICAg QXByaWwgMjAwOQ0KDQoNCjIuICBBZGFwdGF0aW9uIG9mIHRoZSBJRVRGIHdvcmtpbmcgZ3JvdXAg cHJvY2Vzcw0KDQogICBGb3IgdGhlIHB1cnBvc2Ugb2YgTVBMUy1UUCwgdGhlIElFVEYgd29ya2lu ZyBncm91cCBwcm9jZXNzZXMgYXMgDQogICBkZWZpbmVkIGluIFJGQyAyMDI2IFtSRkMyMDI2XSBh cmUgdXBkYXRlZCBhcyBmb2xsb3dzLg0KDQogICBUaGUgSUVURiB3b3JrcyBhY2NvcmRpbmcgdG8g dGhlICdyb3VnaCBjb25zZW5zdXMnIG1vZGVsIHdoZXJlIHRoZQ0KICAgd29ya2luZyBncm91cCBj aGFpcnMgZGV0ZXJtaW5lIHRoZSBjb25zZW5zdXMgYWZ0ZXIgZGlzY3Vzc2lvbnMgb24NCiAgIHRo ZSBtYWlsaW5nIGxpc3RzLiAgVGhpcyBpcyBhbHNvIGFwcGxpY2FibGUgdG8gdGhlIE1QTFMtVFAg d29yay4NCiAgIG1wbHMtdHBAaWV0Zi5vcmcgaXMgdGhlIG1haWxpbmcgbGlzdCB1c2VkIHRvIGZp bmQgb3V0IGNvbnNlbnN1cyBhbmQNCiAgIGNvbnNlbnN1cyBpcyBkZWNpZGVkIGJ5IHRoZSBNRUFE IHRlYW0gY2hhaXIuICBBZnRlciBhIGRvY3VtZW50DQogICBoYXMgYmVjb21lIGEgd29ya2luZyBn cm91cCBkb2N1bWVudCwgdGhlIGNvbnNlbnN1cyBpcyBkZWNpZGVkIGJ5IHRoZQ0KICAgV0cgY2hh aXJzIGFuZCB0aGUgTUVBRCB0ZWFtIGNoYWlyIGpvaW50bHkuDQoNCiAgIEEgdml0YWxseSBpbXBv cnRhbnQgcGFydCBvZiB0aGlzIHByb2Nlc3MgaXMgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlDQog ICBiZXR3ZWVuIHRoZSBJRVRGIGFuZCB0aGUgSVRVLVQuICBUaGlzIGluZm9ybWF0aW9uIGV4Y2hh bmdlIGNvbnNpc3RzIG9mDQogICB0d28gZXF1YWxseSBpbXBvcnRhbnQgcGllY2VzOg0KDQogICBv ICBpbmZvcm1hbCBpbmZvcm1hdGlvbiBleGNoYW5nZQ0KDQogICAgICB0aGlzIGlzIGRvbmUgcHJp bWFyaWx5IGJ5IEVtYWlscyB0byB0aGUgcmVsZXZhbnQgbWFpbGluZyBsaXN0cy4NCg0KICAgbyAg Zm9ybWFsIGluZm9ybWF0aW9uIGV4Y2hhbmdlDQoNCiAgICAgIEluIGFkZGl0aW9uIHRvIEVtYWls cyB0byB0aGUgcmVsZXZhbnQgbWFpbGluZyBsaXN0cywgdGhlIGZvcm1hbA0KICAgICAgaW5mb3Jt YXRpb24gZXhjaGFuZ2UgaW5jbHVkZXMgYSBmb3JtYWwgbGlhaXNvbiBiZXR3ZWVuIHRoZSB0d28N CiAgICAgIG9yZ2FuaXNhdGlvbnMuICBFeGNoYW5nZSBvZiBsaWFpc29uIHN0YXRlbWVudHMgbWFr ZXMgaXQgcG9zc2libGUgdG8gZm9sbG93DQogICAgICB0aGUgcmVxdWVzdC9yZXNwb25zZSBleGNo YW5nZSBiZXR3ZWVuIHRoZSB0d28gb3JnYW5pc2F0aW9ucyBpbiBtb3JlDQogICAgICBkZXRhaWwu DQoNCjIuMS4gIEFkYXB0YXRpb24gb2YgdGhlIElFVEYgd29ya2luZyBncm91cCBwcm9jZXNzDQoN CiAgIFRoZSBmbG93IGNoYXJ0IGJlbG93IGRlc2NyaWJlcyB0aGUgYWRhcHRpb24gb2YgdGhlIHdv cmtpbmcgZ3JvdXANCiAgIHByb2Nlc3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpBbmRlcnNzb24sIGV0IGFsLiAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDkgICAg ICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIE1QTFMtVFAg ZG9jdW1lbnQgcHJvY2VzcyAgICAgICAgICAgICAgQXByaWwgMjAwOQ0KDQoNCiAgICAgICAuLi4u Li4uLi4uLi4uICAgICAgICAgICAgICAgICAgICAgICAgIC4uLi4uLi4uLi4uLi4NCiAgICAgICA6 IEluZCBEb2NzICA6LS0tLS0tLS0tLSsgICAgICAgICAgICAgIDogSldUIGRvY3MgIDoNCiAgICAg ICAuLi4uLi4uLi4uLi4uICAgICAgICAgIHwgICAgICAgICAgICAgIC4uLi4uLi4uLi4uLi4NCiAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICB8IGluZC0wMCAoMSkgICAgIHwgIGluZC0wMCAoMikgICAgICAgIHwgaW5kLTAwICgz KQ0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgdg0KICAg ICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgfCAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0rICAgKDQpICArLS0tLS0tLSsNCiAgICAgICB8ICBXRyBwcm9jICB8ICAgICAgICAgICstLS0t LS0tLS0tLS0tPnwgTUVBRCB0ZWFtIHByb2MgfDwtLS0tLS0+fCBJVFUtVCB8DQogICAgICAgfCAg ICAgICAgICAgfC0tLS0tLS0tKyAgICAgICAgICstLS0tLS18ICAgICAgICAgICAgICAgIHwgICAg ICAgICstLS0tLS0tKw0KICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgIHwgICAgICAgICB8ICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAoNSkgfA0KICstPiBpbmQtMDAsIGluZC0wMSwg ZXRjICAgIHwgICAgICAgICB8ICAgICAgIGluZC0wMCwgaW5kLTAxLCBldGMgPC0rPC0tLS0tKw0K IHwgICAgICAgICAgfCAoNikgICAgICAgICAgICstLS0tKy0tLS0rICAgICAgICAgICg2KSB8ICAg ICAgICAgICAgICB8DQogKy0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICB8KDcpICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsNCiAgIHJldmlldyAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHJldmlldw0KICAgICAgICAgICAgICAgICAgICAg ICAgICBwb2xsIGZvciB3ZyBkb2MgLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgKDdhKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgICB2DQog ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAoOCkgICAgKy0t LS0tLS0rDQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tPiB8ICAgd2cgZG9jICAgIHw8LS0tLS0t LS0tLS0tPnwgSVRVLVQgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICArLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICAgICstLS0tLS0tKw0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwg Ky0+IHdnLTAwLCB3Zy0wMSwgZXRjICAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAg ICAgfCB8ICAgICAgICAgIHwgKDkpICAgICAgICAgICAgIHwgKDEwKQ0KICAgICAgICAgICAgIHwg ICAgICAgICAgICAgIHwgKy0tLS0tLS0tLS0rPC0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAg ICAgfCAgICAgICAgICgxMSkgfCAgICByZXZpZXcNCiAgICAgICAgICAgICB8ICAgICAgICAgICAg ICB2DQogICAgICAgICAgICAgfCAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgKDEyKSAgICAr LS0tLS0tLS0tKw0KICAgICAgICgxNGIpIHwgICAgIHwgIHdnIGxhc3QgY2FsbCAgIHw8LS0tLS0t LS0tLS0+fCAgSVRVLVQgIHwNCiAgICAgICAgICAgICB8ICAgICArLS0tLS0tLS0tLS0tLS0tLS0r ICAgICAgICAgICAgICstLS0tLS0tLS0rDQogICAgICAgICAgICAgfCAgICAgICAgfCAgICAgXiAg ICAgIHwNCiAgICAgICAgICAgICB8ICAgICgxMyl8ICAgICB8KDE0YSkgfCAoMTUpDQogICAgICAg ICAgICAgfCAgICAgICAgdiAgICAgfCAgICAgIHwNCiAgICAgICAgICAgICB8ICAgICAgICstLS0t LS0tLS0rICAgfA0KICAgICAgICAgICAgICstLS0tLS0tfCAgSVRVLVQgIHwgICB8DQogICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2DQogICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAg ICAgICAgIHwgIHJlcSBmb3IgcHVibCAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0rDQoNCg0KMi4yLiAgVGhlIElFVEYgTVBMUy1UUCBwcm9jZXNzDQoNCiAg IFRoaXMgc2VjdGlvbiBnaXZlcyBndWlkZWxpbmVzIGZvciBob3cgdGhlIGZsb3cgY2hhcnQgYWJv dmUgY291bGQgYmUNCiAgIHRyYXZlcnNlZC4NCg0KDQoNCg0KDQpBbmRlcnNzb24sIGV0IGFsLiAg ICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgIE1QTFMtVFAgZG9jdW1lbnQgcHJvY2VzcyAgICAgICAg ICAgICAgQXByaWwgMjAwOQ0KDQoNCjIuMi4xLiAgRGV2ZWxvcGluZyBhIE1QTFMtVFAgZG9jdW1l bnQNCg0KICAgSW5kaXZpZHVhbCBNUExTLVRQIGRvY3VtZW50cyBtYXkgdGFrZSBkaWZmZXJlbnQg cGF0aHMgdGhyb3VnaCB0aGUNCiAgIHByb2Nlc3MuIE5vdGUgdGhhdCB0aGUgbnVtYmVycyBpbiB0 aGUgbGlzdCBiZWxvdyBjb3JyZXNwb25kIHRvIHRoZSANCiAgIG51bWJlcnMgaW4gdGhlIGZsb3cg Y2hhcnQgYWJvdmUuDQoNCiAgIEFsdGhvdWdoIHRoZSBkaWZmZXJlbnQgcGF0aHMgdGhyb3VnaCB0 aGUgZmxvdyBjaGFydCBhcmUgZ2l2ZW4gYXMNCiAgICdvcHRpb25zJyBpdCBpcyBhbHdheXMgcG9z c2libGUgZm9yIHRoZSBNRUFEIHRlYW0gdG8gc3RlcCBpbiBhbmQNCiAgIHRha2Ugb3ZlciB0aGUg c2hlcGhlcmRpbmcgb2YgYSBwYXJ0aWN1bGFyIGRvY3VtZW50LiAgVGhpcyBpcyBkb25lIGluDQog ICBjb29wZXJhdGlvbiBiZXR3ZWVuIHRoZSBNRUFEIHRlYW0gY2hhaXIsIHRoZSByZWxldmFudCB3 b3JraW5nIGdyb3VwDQogICBjaGFpcnMgYW5kIHRoZSBkb2N1bWVudCBlZGl0b3JzL2F1dGhvcnMu DQoNCiAgIDEuICAgVGhlIGRvY3VtZW50IG1heSBiZSBpbnRlbmRlZCBmb3IgYW5kIG1hbmFnZWQg YnkgYSB3b3JraW5nIGdyb3VwLg0KDQogICAgICAgIFRoaXMgbWVhbnMgdGhhdCB0aGUgYXV0aG9y KHMpIG9mIHN1Y2ggYSBkb2N1bWVudCBoYXMgY2hvc2VuIHRvDQogICAgICAgIHNlbmQgdGhlIGRv Y3VtZW50IHRvIHRoZSB3b3JraW5nIGdyb3VwIGluc3RlYWQgb2YgcnVubmluZyB0aHJvdWdoDQog ICAgICAgIHRoZSBNRUFEIHRlYW0uICBUaGUgbm9ybWFsIElFVEYgcHJvY2VzcyB3aWxsIGtpY2sg aW4gaW4gc3VjaCBjYXNlcw0KICAgICAgICBhbmQgdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIHdp bGwgZGVjaWRlIHRvIHdoaWNoIHdvcmtpbmcgZ3JvdXAocykNCiAgICAgICAgc3VjaCBhIGRvY3Vt ZW50IHdpbGwgYmUgdGFrZW4uDQoNCiAgIDIuICAgVGhlIGRvY3VtZW50IG1heSBiZSBjb29yZGlu YXRlZCBieSB0aGUgTUVBRCB0ZWFtLg0KDQogICAgICAgIFRoaXMgbWVhbnMgdGhhdCB0aGUgYXV0 aG9yKHMpIG9mIHN1Y2ggYSBkb2N1bWVudCBoYXMgY2hvc2VuIHRvDQogICAgICAgIHNlbmQgdGhl IGRvY3VtZW50IHRvIHRoZSBNRUFEIHRlYW0gdG8gYmUgY29vcmRpbmF0ZWQgd2l0aCB0aGUNCiAg ICAgICAgcmVzdCBvZiB0aGUgTVBMUy1UUCBkb2N1bWVudHMgdGhhdCBhcmUgaW4gdGhlIHB1cnZp ZXcgb2YgdGhlIE1FQUQNCiAgICAgICAgdGVhbS4NCg0KICAgMy4gICBUaGUgZG9jdW1lbnQgY29t ZSBmcm9tIHRoZSBNRUFEIHRlYW0gYmFzZWQgb24gdGhlIEpXVCBkZWNpc2lvbi4NCg0KICAgICAg ICBGb3IgdGhlIGRvY3VtZW50YXRpb24gb2YgdGhlIHdvcmsgb2YgdGhlIEpXVCwgdGhlcmUgaXMg YSBwcm9wb3NlZA0KICAgICAgICBkb2N1bWVudCBzdHJ1Y3R1cmUuICBUaGUgTUVBRCB0ZWFtIHVz ZWQgdGhpcyBzdHJ1Y3R1cmUgdG8gZGVjaWRlDQogICAgICAgIG9uIGEgc2V0IG9mIGRvY3VtZW50 cyB0aGF0IHdpbGwsIHdoZW4gY29tcGxldGVkLCBjb25zdGl0dXRlIHRoZQ0KICAgICAgICBNUExT LVRQIHN0YW5kYXJkLiAgVGhpcyBzZXQgb2YgZG9jdW1lbnRzIGlzIHNsaWdodGx5IGNoYW5naW5n LA0KICAgICAgICBlLmcuIGJlY2F1c2UgaXQgYmVjb21lcyBtb3JlIGFwcHJvcHJpYXRlIHRvIHNw bGl0IGEgc2luZ2xlDQogICAgICAgIGRvY3VtZW50IGludG8gdHdvIG9yIG1vcmUsIG9yIGJlY2F1 c2UgbmV3IGFzcGVjdHMgb2YgTVBMUy1UUCBuZWVkIHRvDQogICAgICAgIGJlIHNwZWNpZmllZC4N Cg0KICAgNC4gICBFdmVyeSB0aW1lIGEgZG9jdW1lbnQgaXMgYWNjZXB0ZWQgYnkgdGhlIE1FQUQg dGVhbSBpbnRvIHRoZSBzZXQNCiAgICAgICAgb2YgZG9jdW1lbnRzIGNvb3JkaW5hdGVkIGJ5IHRo ZSBNRUFEIHRlYW0sIGEgbGlhaXNvbiBpcyBzZW50IHRvDQogICAgICAgIHRoZSBJVFUtVCB3aXRo IGEgcG9pbnRlciB0byB0aGUgZG9jdW1lbnQuICBBdCB0aGUgc2FtZSB0aW1lIGEgbm90ZQ0KICAg ICAgICBpcyBzZW50IHRvIHRoZSBNUExTLVRQIGFkIGhvYyB0ZWFtIG1haWxpbmcgbGlzdCBpbmZv cm1pbmcgdGhlDQogICAgICAgIHJlY2lwaWVudHMgdGhhdCB0aGUgZG9jdW1lbnQgaGFzIGJlY29t ZSBhIE1FQUQgdGVhbSBkb2N1bWVudC4NCg0KICAgICAgICBUaGUgSVRVLVQgbWF5IGNob3NlIHRv IHJlc3BvbmQgdG8gdGhlIGxpYWlzb24gYnV0IGlzIG5vdA0KICAgICAgICByZXF1aXJlZCB0byBk byBzbywgc2VlIFNlY3Rpb24gMyBhbmQgU2VjdGlvbiA0Lg0KDQoNCg0KDQoNCkFuZGVyc3Nvbiwg ZXQgYWwuICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFn ZSA4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNz ICAgICAgICAgICAgICBBcHJpbCAyMDA5DQoNCg0KICAgNS4gICBBdCBhbnkgdGltZSBpdCBpcyBw b3NzaWJsZSBmb3IgdGhlIElUVS1UIFNHcyBhbmQgUXVlc3Rpb25zIHRvDQogICAgICAgIHNlbmQg cmV2aWV3IGNvbW1lbnRzIG9uIE1FQUQgdGVhbSBkb2N1bWVudHMuICBJdCBpcyBhbHNvDQogICAg ICAgIHBvc3NpYmxlIGZvciB0aGUgTUVBRCB0ZWFtIHRvIGFzayBmb3Igc3VjaCByZXZpZXdzIGFu ZCBjb21tZW50cw0KICAgICAgICBleHBsaWNpdGx5Lg0KDQogICAgICAgIEFueSB0aW1lIHN1Y2gg YW4gaW5wdXQgb3IgcmVxdWVzdHMgYXJlIHNlbnQgYmV0d2VlbiB0aGUgdHdvDQogICAgICAgIG9y Z2FuaXphdGlvbnMgaXQgU0hBTEwgYmUgYWNjb21wYW5pZWQgYnkgYSBub3RlIGZyb20gdGhlIE1Q TFMtVFANCiAgICAgICAgYWQgaG9jIHRlYW0gY2hhaXIocykgdG8gdGhlIE1FQUQgdGVhbSBtYWls aW5nIGxpc3QsIG9yIGZyb20gdGhlDQogICAgICAgIE1FQUQgdGVhbSBjaGFpciB0byB0aGUgTVBM Uy1UUCBhZCBob2MgdGVhbSBtYWlsaW5nIGxpc3QuICBUaGlzDQogICAgICAgIGlzIGRvbmUgdG8g ZW5oYW5jZSB0aGUgZWZmaWNpZW5jeSBvZiB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2UuDQoNCiAg IDYuICAgQSB3b3JraW5nIGdyb3VwIG9yIHRoZSBNRUFEIHRlYW0gbWF5IGlzc3VlIHJlcXVlc3Rz IGZvciBnZW5lcmFsDQogICAgICAgIGNvbW1lbnRzIG9uIE1QTFMtVFAgZG9jdW1lbnRzIGF0IGFu eSB0aW1lLCBpZiBpdCBpcyBkZWVtZWQNCiAgICAgICAgYXBwcm9wcmlhdGUgdG8gZXh0ZW5kIHRo ZXNlIHJlcXVlc3RzIHRvIHRoZSBNUExTLVRQIGFkIGhvYyB0ZWFtDQogICAgICAgIHRoaXMgaXMg ZG9uZSB2aWEgYSBub3RlIGFjY29yZGluZyB0byBlbnRyeSAoNSkgaW4gdGhpcyBsaXN0Lg0KDQog ICA3LiAgIElmIGEgTVBMUy1UUCBkb2N1bWVudCBpcyBtYXR1cmUgZW5vdWdoIHRvIGJlY29tZSBh IHdvcmtpbmcgZ3JvdXANCiAgICAgICAgZG9jdW1lbnQgYSBwb2xsIGlzIGRvbmUgb24gdGhlIG1w bHMtdHAgbWFpbGluZyBsaXN0IGFuZCB0aGUNCiAgICAgICAgYXBwcm9wcmlhdGUgV0cgbWFpbGlu ZyBsaXN0LiBUaGlzIHJlcXVlc3Qgd2lsbCBhbHNvIGJlIHNlbnQgdG8NCiAgICAgICAgdGhlIElU VS1UIGFzIGEgbGlhaXNvbi4gIEEgbm90ZSB3aWxsIGFsc28gYmUgc2VudCB0byB0aGUgTVBMUy1U UA0KICAgICAgICBhZCBob2MgdGVhbS4NCg0KICAgICAgICBXaGljaCB3b3JraW5nIGdyb3VwIGEg ZG9jdW1lbnQgZ29lcyBpbnRvIGlzIGRlY2lkZWQgam9pbnRseQ0KICAgICAgICBiZXR3ZWVuIHRo ZSBNRUFEIHRlYW0sIHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBvZiB0aGUgcG90ZW50aWFsDQog ICAgICAgIHdvcmtpbmcgZ3JvdXBzIGFuZCB0aGUgZG9jdW1lbnQgZWRpdG9ycy9hdXRob3JzLg0K DQogICAgICAgIElmIHRoZSBkb2N1bWVudCBpcyBhY2NlcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnQsIHRoZQ0KICAgICAgICB3b3JraW5nIGdyb3VwIHRha2VzIG92ZXIgdGhlIHJldmlz aW9uIGNvbnRyb2wgb2YgdGhlIGRvY3VtZW50Lg0KDQogICAgICAgIFRoZSBJVFUtVCBpcyBleHBl Y3RlZCB0byByZXNwb25kIHRvIHRoZSBsaWFpc29uIHdpdGhpbiBpbiB0aGUNCiAgICAgICAgdGlt ZSBpbmRpY2F0ZWQgaW4gdGhlIGxpYWlzb24sIHNlZSBTZWN0aW9uIDMgYW5kIFNlY3Rpb24gNC4N Cg0KICAgOC4gICBFdmVyeSB0aW1lIGEgTVBMUy1UUCBkb2N1bWVudCBpcyBhY2NlcHRlZCBhcyBh IHdvcmtpbmcgZ3JvdXANCiAgICAgICAgZG9jdW1lbnQgYnkgYW55IElFVEYgd29ya2luZyBncm91 cCBhIGxpYWlzb24gaXMgc2VudCB0byB0aGUNCiAgICAgICAgSVRVLVQgd2l0aCBhIHBvaW50ZXIg dG8gdGhlIGRvY3VtZW50LiAgQXQgdGhlIHNhbWUgdGltZSBhIG5vdGUgaXMNCiAgICAgICAgc2Vu dCB0byB0aGUgTVBMUy1UUCBhZCBob2MgdGVhbSBtYWlsaW5nIGxpc3QgaW5mb3JtaW5nIHRoYXQg dGhlDQogICAgICAgIGRvY3VtZW50IGhhcyBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 Lg0KDQogICA5LiAgIFdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIG1heSBiZSByZXZpZXdlZCBpbiBz ZXZlcmFsIHN0ZXBzLCBldmVyeQ0KICAgICAgICB0aW1lIHN1Y2ggYSByZXZpZXcgaXMgaW5pdGlh dGVkIHRoZSBNUExTLVRQIGFkIGhvYyB0ZWFtIGlzDQogICAgICAgIG5vdGlmaWVkICgxMCkuDQoN CiAgICAgICAgTm90ZSB0aGF0IG1vc3QgcmV2aWV3cyB0aGF0IGxlYWQgdG8gdXBkYXRlcyBvZiB3 b3JraW5nIGdyb3VwDQogICAgICAgIGRvY3VtZW50cyBhcmUgc3BvbnRhbmVvdXMgaW5kaXZpZHVh bCBjb21tZW50cyBmcm9tIHBhcnRpY2lwYW50cw0KICAgICAgICBpbiB0aGUgTVBMUy1UUCBlZmZv cnQuDQoNCiAgIDEwLiAgRXZlcnkgdGltZSBhIHJldmlldyBpcyBpbml0aWF0ZWQgYnkgYSB3b3Jr aW5nIGdyb3VwIHRoZQ0KICAgICAgICBhcHByb3ByaWF0ZSBJVFUtVCBTR3MgYW5kIFF1ZXN0aW9u cyB3aWxsIGJlIG5vdGlmaWVkIGJ5IGEgbWFpbA0KICAgICAgICB0byB0aGUgTVBMUy1UUCBhZCBo b2MgdGVhbS4NCg0KDQoNCkFuZGVyc3NvbiwgZXQgYWwuICAgICAgIEV4cGlyZXMgT2N0b2JlciAy MiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNzICAgICAgICAgICAgICBBcHJpbCAyMDA5DQoNCg0K ICAgICAgICBPcHRpb25hbGx5LCB0aGUgcmVxdWVzdCBmb3IgcmV2aWV3IG1heSBiZSBhY2NvbXBh bmllZCBieSBhDQogICAgICAgIGxpYWlzb24gdG8gZm9ybWFsaXplIHRoZSByZXF1ZXN0Lg0KDQog ICAgICAgIFRoZSBNUExTLVRQIGFkIGhvYyB0ZWFtIGlzIHJlc3BvbnNpYmxlIGZvciBlbnN1cmlu ZyB0aGF0IGFsbA0KICAgICAgICBFbWFpbCByZXF1ZXN0cyBhcmUgY29waWVkL2ZvcndhcmRlZCB0 aGUgcmVsZXZhbnQgU0dzIGFuZA0KICAgICAgICBRdWVzdGlvbnMuDQoNCiAgIDExLiAgV2hlbiBh IGRvY3VtZW50IGlzIGRlZW1lZCB0byBiZSBtYXR1cmUgZW5vdWdoLCBhIHdvcmtpbmcgZ3JvdXAg bGFzdA0KICAgICAgICBjYWxsIGlzIGluaXRpYXRlZC4gIEF0IHRoaXMgdGltZSwgdGhlIGFjdGlv biBkZXNjcmliZWQgdW5kZXIgaXRlbQ0KICAgICAgICAxMiBpbiB0aGlzIGxpc3QgTVVTVCBiZSBl eGVjdXRlZC4NCg0KICAgMTIuICBQcm9jZWR1cmVzIHRvIGJlIGZvbGxvd2VkIHdoZW4gYSB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBpcw0KICAgICAgICBpbml0aWF0ZWQuDQoNCiAgICAgICAgKiAg QSBsaWFpc29uIGNvbnRhaW5pbmcgYSByZXF1ZXN0IGZvciBwYXJ0aWNpcGF0aW9uIGluIHRoZQ0K ICAgICAgICAgICB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCB3aWxsIGJlIHNlbnQgdG8gdGhlIGFw cHJvcHJpYXRlIElUVS1UDQogICAgICAgICAgIFNHIGFuZCBRdWVzdGlvbnMuDQoNCiAgICAgICAg KiAgQSBtYWlsIHdpdGggYSBub3RpZmljYXRpb24gdGhhdCB0aGUgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgaXMNCiAgICAgICAgICAgdGFraW5nIHBsYWNlIHdpbGwgYmUgc2VudCB0byB0aGUgTVBM Uy1UUCBhZCBob2MgdGVhbS4NCg0KICAgICAgICAqICBUaGUgSVRVLVQgaXMgUkVRVUlSRUQgdG8g cmVzcG9uZCB0byB0aGUgbGlhaXNvbiB3aXRoaW4gdGhlIHRpbWUNCiAgICAgICAgICAgZnJhbWUg aW5kaWNhdGVkLiAgVGhlIE1QTFMtVFAgYWQgaG9jIHRlYW0gaXMgZXhwZWN0ZWQgdG8gdmVyaWZ5 DQogICAgICAgICAgIHRoYXQgYWxsIHRoZSBTR3MgYW5kIFF1ZXN0aW9ucyB3aXRoIHRoZSBJVFUt VCB0aGF0IG5lZWQgdG8NCiAgICAgICAgICAgcmVzcG9uZCB0byB0aGUgd29ya2luZyBncm91cCBs YXN0IGNhbGwgYXJlIGF3YXJlIHRoYXQgaXQgaGFzDQogICAgICAgICAgIGJlZW4gaXNzdWVkLg0K DQogICAxMy4gIFdoZW4gYWxsIGxhc3QgY2FsbCBjb21tZW50cyBhcmUgYWRkcmVzc2VkIGFuZCBy ZXNwb25kZWQgdG8sIHRoZQ0KICAgICAgICBkb2N1bWVudCB3aWxsIGJlIHNlbnQgdG8gdGhlIElU VS1UIGFza2luZyBpZiB0aGUgZG9jdW1lbnQNCiAgICAgICAgaXMgcmVhZHkgdG8gYmUgc2VudCB0 byB0aGUgSUVTRyB3aXRoIGEgcmVxdWVzdCBmb3INCiAgICAgICAgcHVibGljYXRpb24uIFRoZSBJ VFUtVCBjYW4gZWl0aGVyIHNlbmQgYW4gYWNrbm93bGVkZ21lbnQgdGhhdCANCiAgICAgICAgdGhl IGRvY3VtZW50IGlzIHJlYWR5IHRvIG9yIGl0IGNhbiBleHByZXNzIHRoYXQgdGhlcmUgaXMgZnVy dGhlciB3b3JrIA0KICAgICAgICB0aGF0IG5lZWRzIHRvIGJlIGRvbmUuDQoNCiAgICAgICAgTm90 ZTogV0cgbGFzdCBjYWxsIG1heSBiZSByZS1pdGVyYXRlZCwgZm9yIHRoZSBlbnRpcmUgZG9jdW1l bnQNCiAgICAgICAgb3IgbGltaXRlZCB0byBvbmx5IHZlcmlmeSB0aGUgdXBkYXRlcyBtYWRlIGJl Y2F1c2Ugb2YgYW4gZWFybGllcg0KICAgICAgICB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0K ICAgMTQuICBUaGUgSVRVLVQgaGFzIG9uZSB3ZWVrIHRvIHJlc3BvbmQgeWVzIG9yIG5vIHRvIHRo ZSBxdWVzdGlvbg0KICAgICAgICBwb3NlZCBpbiAoMTMpLg0KDQogICAgICAgIFRoZSBhbnN3ZXIg Y2FuIGJlIGVpdGhlciAieWVzIC0gZ28gYWhlYWQiLCBpbiB3aGljaCBjYXNlIHRoZQ0KICAgICAg ICBXb3JraW5nIEdyb3VwIHdpbGwgcmVxdWVzdCBwdWJsaWNhdGlvbjsgb3IgLi4uDQoNCiAgICAg ICAgLi4uIGl0IGNhbiBiZSAibm8gLSBtb3JlIHdvcmsgaXMgbmVlZGVkIiwgaW4gd2hpY2ggY2Fz ZSBpdCB3aWxsDQogICAgICAgIGdvIGJhY2sgaW50byB0aGUgbm9ybWFsIHdvcmtpbmcgZ3JvdXAg cHJvY2VzcyB0byBpZGVudGlmeSB3aGF0DQogICAgICAgIGlzIG5lZWRlZC4NCg0KDQoNCkFuZGVy c3NvbiwgZXQgYWwuICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwOSAgICAgICAgICAgICAg IFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgTVBMUy1UUCBkb2N1bWVudCBw cm9jZXNzICAgICAgICAgICAgICBBcHJpbCAyMDA5DQoNCg0KICAgMTUuICBXaGVuIHRoZSBJVFUt VCBnaXZlcyB0aGUgZmluYWwgYWNrbm93bGVkZ2VtZW50IGEgcmVxdWVzdCBmb3INCiAgICAgICAg cHVibGljYXRpb24gd2lsbCBiZSBzZW50IHRvIHRoZSBJRVNHLiAgQXQgdGhpcyBzdGFnZSwgdGhl IElUVS1UIA0KICAgICAgICBoYXMgbm8gbW9yZSBpbmZsdWVuY2Ugb24gdGhlIGRldmVsb3BtZW50 IHRoZSBkb2N1bWVudC4gIA0KICAgICAgICBGcm9tIHRoaXMgcG9pbnQgb24gdGhlIGRvY3VtZW50 IHdpbGwgYmUgaGFuZGxlZCBhcyBhbnkgb3RoZXINCiAgICAgICAgSUVURiBkb2N1bWVudC4NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFuZGVyc3NvbiwgZXQgYWwuICAgICAgIEV4 cGlyZXMgT2N0b2JlciAyMiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNzICAgICAgICAgICAgICBB cHJpbCAyMDA5DQoNCg0KMy4gIEV4cGVjdGF0aW9ucyBvbiBJVFUtVCBwYXJ0aWNpcGF0aW9uIGlu IHRoZSBwcm9jZXNzDQoNCiAgIFRoZSBJRVRGIGFuZCBJVFUtVCBwcm9jZXNzZXMgZm9yIHRoZSBk ZXZlbG9wbWVudCBvZiB0aGUgTVBMUy1UUA0KICAgc3RhbmRhcmRzIGludGVyc2VjdCBhdCB0aGUg cG9pbnRzICg0KSwgKDUpLCAoN2EpLCAoOCksICgxMCksICgxMiksIA0KICAgKDEzKSBhbmQgKDE0 KSBpbiB0aGUgZmxvdyBjaGFydCBhYm92ZS4gIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaW4gc2hv cnQNCiAgIHdoYXQgaXMgZXhwZWN0ZWQgdG8gaGFwcGVuIG9uIHRoZSBJVFUtVCBzaWRlIGF0IHRo ZSBpbnRlcmFjdGlvbg0KICAgcG9pbnRzLg0KDQozLjEuICBCZWNvbWluZyBhIE1FQUQgdGVhbSBk b2N1bWVudA0KDQogICAoNCkgaXMgYSBwb2ludCB3aGVyZSB0aGUgTUVBRCB0ZWFtIGNvbW11bmlj YXRlcyB0byB0aGUgSVRVLVQgdGhhdCBhDQogICBkb2N1bWVudCBpcyBjb25zaWRlcmVkIHRvIGJl IGFjY2VwdGVkIHRvIGJlIGNvb3JkaW5hdGVkIGJ5IHRoZSBNRUFEDQogICB0ZWFtLg0KDQogICBU aGUgSVRVLVQgaXMgZXhwZWN0ZWQgdG8gcmVzcG9uZCB3aXRoIGEgc2ltcGxlIEFDSyBvciBOQUss IGhvd2V2ZXIgDQogICBhIG5vbi1yZXNwb25zZSBpcyBpbXBsaWNpdGx5IGNvdW50ZWQgYXMgYW4g QUNLLg0KDQogICBBbiBBQ0sgbWVhbnMgdGhhdCB0aGUgSVRVLVQgYWNjZXB0cyB0aGF0IHRoZSBk b2N1bWVudHMgaGFzIGJlY29tZSBhIE1FQUQNCiAgIHRlYW0gZG9jdW1lbnQsIGEgTkFLIG1lYW5z IHRoYXQgSVRVLVQgaGFzIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUNCiAgIHJlc29sdmVkIGJlZm9y ZSB0aGUgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcy4NCg0KMy4yLiAgQ29tbWVudHMg b24gTUVBRCB0ZWFtIGRvY3VtZW50cyBieSBwYXJ0aWNpcGFudHMgaW4gdGhlIElUVS1UDQoNCiAg ICg1KSBhbmQgKDEwKSBvZmZlcnMgcG9zc2liaWxpdGllcyBmb3IgdGhlIElUVS1UIG9yIHBlb3Bs ZSBhY3RpdmUgaW4gdGhlDQogICBJVFUtVCB0byBzZW5kIHVuLXRyaWdnZXJlZCBjb21tZW50cyBv biBNRUFEIHRlYW0gb3Igd29ya2luZyBncm91cA0KICAgZG9jdW1lbnRzLiAgU3VjaCBjb21tZW50 cyBzaGFsbCBiZSBzZW50IHRvIHRoZSBtcGxzLXRwIGxpc3QgYW5kIGZvcg0KICAgd29ya2luZyBn cm91cCBkb2N1bWVudHMgYWxzbyB0byB0aGUgYXBwcm9wcmlhdGUgd29ya2luZyBncm91cCBtYWls aW5nDQogICBsaXN0LiAgQ29tbWVudHMgcmVjZWl2ZWQgaW4gdGhpcyB3YXkgd2lsbCBiZSB0cmVh dGVkIHRoZSBzYW1lIHdheQ0KICAgYXMgYW55IG90aGVyIGluZGl2aWR1YWwgY29tbWVudHMgcmVj ZWl2ZWQgb24gdGhlIElFVEYgZG9jdW1lbnRzLg0KDQozLjMuICBQb2xsIGZvciB3b3JraW5nIGdy b3VwIGRvY3VtZW50cw0KDQogICAoN2EpIGlzIHRoZSBwb2ludCB3aGVyZSBhbiBJRVRGIHdvcmtp bmcgZ3JvdXAgaW5mb3JtcyB0aGUgSVRVLVQgdGhhdA0KICAgYSBwb2xsIHRvIHByb2dyZXNzIGEg ZG9jdW1lbnQgdG8gYW4gSUVURiB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGhhcw0KICAgYmVlbiBz dGFydGVkLg0KDQogICBJdCBpcyBub3QgbmVjZXNzYXJ5IG9yIHJlcXVpcmVkIGZvciB0aGUgSVRV LVQgdG8gcmVzcG9uZCB0byB0aGlzDQogICBtZXNzYWdlLiAgSWYgdGhlIElUVS1UIGhhcyBzZXJp b3VzIGNvbmNlcm5zIHRoZXNlIHNob3VsZCBiZSBwcm92aWRlZA0KICAgdmlhIGEgbGlhaXNvbiBz dGF0ZW1lbnQuICBJZiB0aGUgSVRVLVQgaGFzIG5vIHNlcmlvdXMgY29uY2VybnMgaXQgaXMNCiAg IGFsbG93ZWQgYW5kIGVuY291cmFnZWQgdGhhdCBpbmRpdmlkdWFsIHBhcnRpY2lwYW50cyBwcm92 aWRlIGNvbW1lbnRzLg0KICAgU3VjaCByZXNwb25zZXMgc2hhbGwgYmUgc2VudCB0byB0aGUgYXBw cm9wcmlhdGUgd29ya2luZyBncm91cCBhbmQNCiAgIG1wbHMtdHAgbWFpbGluZyBsaXN0cyBhbmQg cmVwcmVzZW50IHRoZSB2aWV3IG9mIHRoZSBwZXJzb24gc2VuZGluZw0KICAgdGhlIG1haWwuDQoN CiAgIEFuIEludGVybmV0IERyYWZ0IGlzIHJlYWR5IHRvIGJlY29tZSBhIHdvcmtpbmcgZ3JvdXAg ZHJhZnQgaWYgaXQNCiAgIG1lZXRzIGF0IGxlYXN0IHRoZSB0aHJlZSBjcml0ZXJpYSBiZWxvdy4N Cg0KDQoNCg0KDQpBbmRlcnNzb24sIGV0IGFsLiAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIw MDkgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIE1Q TFMtVFAgZG9jdW1lbnQgcHJvY2VzcyAgICAgICAgICAgICAgQXByaWwgMjAwOQ0KDQoNCiAgIG8g IGl0IGlzIHdpdGhpbiB0aGUgY2hhcnRlciBvZiB0aGUgd29ya2luZyBncm91cA0KDQogICBvICBp dCBhZGRyZXNzZXMgYSBwcm9ibGVtIHRoYXQgbmVlZHMgdG8gYmUgc29sdmVkDQoNCiAgIG8gIGl0 IGlzIGEgZ29vZCBlbm91Z2ggc3RhcnQgdG8gc29sdmUgdGhpcyBwcm9ibGVtDQoNCiAgIFJlc3Bv bnNlcyB0byBwb2xscyBmb3IgY2hlY2tpbmcgaWYgYSBkb2N1bWVudCBpcyByZWFkeSB0byBiZWNv bWUgYQ0KICAgd29ya2luZyBncm91cCBkb2N1bWVudCBzaG91bGQgYmUgbGltaXRlZCB0byBhbnN3 ZXIgaWYgdGhlIGRvY3VtZW50DQogICBtZWV0cyB0aG9zZSB0aHJlZSBjcml0ZXJpYS4NCg0KMy40 LiAgUmVzcG9uZGluZyB0byBhbiBJRVRGIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsDQoNCiAgICgx MikgaXMgdGhlIHBvaW50IGluIHRoZSBwcm9jZXNzIHdoZXJlIElUVS1UIGlzIG1hZGUgYXdhcmUg b2YgdGhlIGZhY3QgdGhhdCBhbg0KICAgSUVURiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMg YmVlbiBzdGFydGVkLiAgVGhlIHdvcmtpbmcgZ3JvdXANCiAgIGxhc3QgY2FsbCBpcyBpc3N1ZWQg d2hlbiBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgaXMgZ2V0dGluZyBjbG9zZSB0bw0KICAgYmUg cmVhZHkgZm9yIHB1YmxpY2F0aW9uLiAgVGhlIGludGVudGlvbiBpcyB0byBtYWtlIHN1cmUgdGhh dCB0aGVyZQ0KICAgYXJlIG5vIGltcG9ydGFudCBwaWVjZXMgbWlzc2luZyBhbmQgdGhhdCB0ZWNo bmljYWwgZGV0YWlscyBhcmUNCiAgIGNvcnJlY3QuDQoNCiAgIEFjY29yZGluZyB0byB0aGUgSldU IGRlY2lzaW9uLCB0aGUgSVRVLVQgaXMgcmVxdWlyZWQgdG8gcmVzcG9uZCB0byBhDQogICB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCB3aXRoaW4gdGhlIHRpbWUgc2V0IGZvciB0aGUgd29ya2luZyBn cm91cA0KICAgbGFzdC4NCg0KICAgVGhlIGNoYWlyIG9mIGFuIElFVEYgd29ya2luZyBncm91cCB0 aGF0IHN0YXJ0cyBhIHdvcmtpbmcgZ3JvdXAgbGFzdA0KICAgY2FsbCB3aWxsIHNlbmQgYSBsaWFp c29uIHRvIHRoZSBJVFUtVCBhbm5vdW5jaW5nIHRoZSB3b3JraW5nIGdyb3VwDQogICBsYXN0IGNh bGwuICBBIG1lc3NhZ2Ugd2lsbCBhbHNvIGJlIHNlbnQgdG8gdGhlIE1QTFMtVFAgYWQgaG9jIHRl YW0uDQogICBUaGUgSUVURiB3aWxsIHRyeSB0byBlbnN1cmUgdGhhdCBhbGwgU0dzIGFuZCBRdWVz dGlvbnMgdGhhdA0KICAgc2hvdWxkIGJlIGludm9sdmVkIGluIHJlc3BvbmRpbmcgdG8gdGhlIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGFyZSBhZGRyZXNzZWQuDQogICBIb3dldmVyLCB1bHRpbWF0 ZWx5IHRoZSBJVFUtVCBoYXMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGFwcHJvcHJpYXRlIGVudGl0 aWVzDQogICB3aXRoaW4gdGhlIElUVS1UIHBhcnRpY2lwYXRlIGluIHJlc3BvbmRpbmcgdG8gdGhl IHdvcmtpbmcgZ3JvdXAgbGFzdA0KICAgY2FsbC4gIFRoZSBJVFUtVCBNUExTLVRQIGFkIGhvYyB0 ZWFtIGNvb3JkaW5hdGVzIHRoZSBkZXZlbG9wbWVudCBvZg0KICAgdGhlIElUVS1UIHJlc3BvbnNl IHRvIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KQW5kZXJzc29uLCBldCBhbC4gICAgICAgRXhwaXJlcyBPY3RvYmVyIDIy LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICBNUExTLVRQIGRvY3VtZW50IHByb2Nlc3MgICAgICAgICAgICAgIEFwcmlsIDIwMDkNCg0KDQo0 LiAgU3BlY2lmaWMgZ3VpZGVsaW5lcyB0aGF0IGFwcGx5IHRvIHdvcmsgb24gTVBMUy1UUCBpbiB0 aGUgSVRVLVQNCg0KICAgVGhlc2UgZ3VpZGVsaW5lcyBhcHBseSB0byBwcm9ncmVzc2luZyB3b3Jr IG9uIE1QTFMtVFAgaW4gdGhlIElUVS1ULg0KDQogICAgICBBbnkgbWVtYmVyIG9mIHRoZSBJVFUt VCBtYXkgc2VuZCBhIE1QTFMtVFAgY29udHJpYnV0aW9uIHRvIGEgSVRVLVQNCiAgICAgIFN0dWR5 IEdyb3VwIG9yIFF1ZXN0aW9uLg0KDQogICAgICBCZWZvcmUgdGhlIElUVS1UIGluaXRpYXRlcyBh bnkgbmV3IHdvcmsgKGkuZS4gaXRlbXMgbm90IHByZXZpb3VzbHkNCiAgICAgIGlkZW50aWZpZWQg YnkgdGhlIEpXVCkgYmFzZWQgb24gc3VjaCBjb250cmlidXRpb25zIHRoZSBJVFUtVCBzaGFsbA0K ICAgICAgc2VuZCBhIGxpYWlzb24gdG8gdGhlIElFVEYuICBUaGUgbWVzc2FnZSB3aWxsIGdvIHRv IHRoZSBNRUFEIHRlYW0sDQogICAgICB0aGUgdGVhbSBpcyByZXNwb25zaWJsZSBmb3IgY3JlYXRp bmcgYSBjb25zb2xpZGF0ZWQgSUVURiByZXNwb25zZS4NCg0KICAgICAgVGhlIElFVEYgaXMgZXhw ZWN0ZWQgdG8gcmVzcG9uZCB0byB0aGUgaW5mb3JtYXRpb24gdGhhdCBhIG5ldw0KICAgICAgTVBM Uy1UUCB3b3JrIGl0ZW0gaGFzIGJlZW4gcHJvcG9zZWQgd2l0aCBhbiBBQ0sgb3IgTkFLLg0KDQog ICAgICBJZiB0aGUgcmVzcG9uc2UgaXMgYSBOQUsgdGhhdCB3b3JrIGl0ZW0gaXMgaGVsZCB1bnRp bCB0aGUgaXNzdWVzDQogICAgICBpcyByZXNvbHZlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQW5kZXJzc29uLCBl dCBhbC4gICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2Ug MTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBNUExTLVRQIGRvY3VtZW50IHByb2Nlc3Mg ICAgICAgICAgICAgIEFwcmlsIDIwMDkNCg0KDQo1LiAgSUFOQSBjb25zaWRlcmF0aW9ucw0KDQog ICBUaGVyZSBhcmUgbm8gcmVxdWVzdHMgZm9yIElBTkEgYWxsb2NhdGlvbiBvZiBjb2RlIHBvaW50 cyBpbiB0aGlzDQogICBkb2N1bWVudC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpBbmRlcnNzb24sIGV0IGFsLiAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDkgICAg ICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIE1QTFMtVFAg ZG9jdW1lbnQgcHJvY2VzcyAgICAgICAgICAgICAgQXByaWwgMjAwOQ0KDQoNCjYuICBTZWN1cml0 eSBjb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBwcm9jZXNzIGFk YXB0YXRpb24gZm9yIHRoZSBjb29wZXJhdGlvbg0KICAgYmV0d2VlbiBJRVRGIGFuZCBJVFUtVCBh bmQgdGh1cyBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eQ0KICAgY29uc2lkZXJh dGlvbnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFuZGVyc3NvbiwgZXQg YWwuICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDE2 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNzICAg ICAgICAgICAgICBBcHJpbCAyMDA5DQoNCg0KNy4gIEFja25vd2xlZGdtZW50cw0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFuZGVyc3NvbiwgZXQgYWwuICAgICAg IEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNzICAgICAgICAgICAg ICBBcHJpbCAyMDA5DQoNCg0KOC4gIFJlZmVyZW5jZXMNCg0KOC4xLiAgTm9ybWF0aXZlIFJlZmVy ZW5jZXMNCg0KICAgW1JGQzIwMjZdICBCcmFkbmVyLCBTLiwgIlRoZSBJbnRlcm5ldCBTdGFuZGFy ZHMgUHJvY2VzcyAtLSBSZXZpc2lvbg0KICAgICAgICAgICAgICAzIiwgQkNQIDksIFJGQyAyMDI2 LCBPY3RvYmVyIDE5OTYuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMg Zm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExl dmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkM1MzE3XSAgQnJ5 YW50LCBTLiBhbmQgTC4gQW5kZXJzc29uLCAiSm9pbnQgV29ya2luZyBUZWFtIChKV1QpDQogICAg ICAgICAgICAgIFJlcG9ydCBvbiBNUExTIEFyY2hpdGVjdHVyYWwgQ29uc2lkZXJhdGlvbnMgZm9y IGENCiAgICAgICAgICAgICAgVHJhbnNwb3J0IFByb2ZpbGUiLCBSRkMgNTMxNywgRmVicnVhcnkg MjAwOS4NCg0KOC4yLiAgSW5mb3JtYXRpdmUgcmVmZXJlbmNlcw0KDQogICBbUkZDNDM3OV0gIEtv bXBlbGxhLCBLLiBhbmQgRy4gU3dhbGxvdywgIkRldGVjdGluZyBNdWx0aS1Qcm90b2NvbA0KICAg ICAgICAgICAgICBMYWJlbCBTd2l0Y2hlZCAoTVBMUykgRGF0YSBQbGFuZSBGYWlsdXJlcyIsIFJG QyA0Mzc5LA0KICAgICAgICAgICAgICBGZWJydWFyeSAyMDA2Lg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFuZGVyc3Nvbiwg ZXQgYWwuICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdl IDE4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgTVBMUy1UUCBkb2N1bWVudCBwcm9jZXNz ICAgICAgICAgICAgICBBcHJpbCAyMDA5DQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIExv YSBBbmRlcnNzb24NCiAgIFJlZGJhY2sgTmV0d29ya3MNCg0KICAgRW1haWw6IGxvYUBwaS5udQ0K DQoNCiAgIERhdmlkIFdhcmQNCiAgIENpc2NvIFN5c3RlbXMNCg0KICAgRW1haWw6IGR3YXJkQGNp c2NvLmNvbQ0KDQoNCiAgIE1hbGNvbG0gQmV0dHMNCiAgIE5vcnRlbA0KDQogICBFbWFpbDogYmV0 dHMwMUBub3J0ZWwuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpBbmRlcnNzb24sIGV0IGFsLiAgICAgICBFeHBpcmVz IE9jdG9iZXIgMjIsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCg0K ------_=_NextPart_001_01C9C72B.59891A4C Content-Type: text/html; name="Diff draft-andersson-mpls-tp-process-01_txt - draft-andersson-mpls-tp-process-01_txt.htm" Content-Transfer-Encoding: base64 Content-Description: Diff draft-andersson-mpls-tp-process-01_txt - draft-andersson-mpls-tp-process-01_txt.htm Content-Disposition: attachment; filename="Diff draft-andersson-mpls-tp-process-01_txt - draft-andersson-mpls-tp-process-01_txt.htm" CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25h bC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9u YWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS4zNTogcmZjZGlmZiAgLS0+IAo8 IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRp b25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGdhbWF5LnRvb2xzLmlldGYub3JnIDIuNi4y NC0xLTY4NiAjMSBTTVAgVGh1IE1heSA4IDAyOjE2OjM5IFVUQyAyMDA4IGk2ODYgR05VL0xpbnV4 IC0tPiAKPCEtLSBVc2luZyBhd2s6IC91c3IvYmluL2dhd2s6IEdOVSBBd2sgMy4xLjUgLS0+IAo8 IS0tIFVzaW5nIGRpZmY6IC91c3IvYmluL2RpZmY6IGRpZmYgKEdOVSBkaWZmdXRpbHMpIDIuOC4x IC0tPiAKPCEtLSBVc2luZyB3ZGlmZjogL3Vzci9iaW4vd2RpZmY6IEdOVSB3ZGlmZiAwLjUgLS0+ IAo8aHRtbD4gCjxoZWFkPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRl bnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiAvPiAKICA8bWV0YSBodHRwLWVxdWl2 PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8dGl0bGU+RGlm ZjogZHJhZnQtYW5kZXJzc29uLW1wbHMtdHAtcHJvY2Vzcy0wMS50eHQgLSBkcmFmdC1hbmRlcnNz b24tbXBscy10cC1wcm9jZXNzLTAxLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2Nz cyI+IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAK ICAgIHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFt aWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30g CiAgICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1z aXplOiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNF RUU7IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZm ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQt Y29sb3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAK ICAgIC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJh Y2tncm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjog I0ZGQjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxp bmViciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJl ZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjog cmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6 ICNBQUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAg ICAucmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAu Y29udCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFj a2dyb3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNv bG9yOiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7 IH0gCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjog I0VFRTsgcGFkZGluZzogMnB4IDA7IH0gCiAgPC9zdHlsZT4gCjwvaGVhZD4gCjxib2R5ID4gCiAg PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gCiAgPHRy IGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPiZuYnNwO2RyYWZ0LWFuZGVyc3Nvbi1tcGxz LXRwLXByb2Nlc3MtMDEudHh0Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwO2RyYWZ0LWFu ZGVyc3Nvbi1tcGxzLXRwLXByb2Nlc3MtMDEudHh0Jm5ic3A7PC90aD48dGg+PC90aD48L3RyPiAK ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0 LWwxIiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAyLCBs aW5lIDc8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIxIiAvPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAyLCBsaW5lIDc8L2VtPjwvdGg+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJl c2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBM ZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlzaW9ucyBS ZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYg RG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKGh0 dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBsZWFzZSByZXZpZXcgdGhlc2Ug ZG9jdW1lbnRzIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0czwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRz IGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0czwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgcmVzdHJpY3Rpb25z IHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwMDEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+ZWZmb3J0PC9zcGFuPiB0byBkZXZlbG9wIGEgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+TXVsdGktcHJvdG9jb2w8L3NwYW4+IExhYmVsIFN3aXRjaGluZyAoTVBMUyk8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRlY2lz aW9uPC9zcGFuPiB0byBkZXZlbG9wIGEgPHNwYW4gY2xhc3M9Imluc2VydCI+TXVsdGlwcm90b2Nv bDwvc3Bhbj4gTGFiZWwgU3dpdGNoaW5nIChNUExTKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRyYW5zcG9ydCBQcm9maWxlIGluIGNv b3BlcmF0aW9uIGJldHdlZW4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGhlPC9zcGFuPiBJRVRGIGFu ZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj50aGU8L3NwYW4+IElUVS1UIDxzcGFuIGNsYXNzPSJkZWxl dGUiPmxhY2tzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUcmFu c3BvcnQgUHJvZmlsZSBpbiBjb29wZXJhdGlvbiBiZXR3ZWVuIElFVEYgYW5kIElUVS1UIDxzcGFu IGNsYXNzPSJpbnNlcnQiPmRvZXMgbm90PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGEg d2VsbCBkZWZpbmVkPC9zcGFuPiBwcm9jZXNzIGZvciA8c3BhbiBjbGFzcz0iZGVsZXRlIj50aGU8 L3NwYW4+IGRldmVsb3BtZW50IDxzcGFuIGNsYXNzPSJkZWxldGUiPm9mPC9zcGFuPiB0aGUgcmVx dWlyZWQgUkZDcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgZnVsbHkgZGVmaW5lcyBhbmQgZG9jdW1lbnQ8L3NwYW4+IHByb2Nlc3MgZm9y IGRldmVsb3BtZW50IHRoZSByZXF1aXJlZCBSRkNzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgVGhpcyBkb2N1bWVudCBjb21wbGVtZW50cyB0aGUgcHJvY2VzcyBhcyBkb2N1bWVudGVk IGluIHRoZSBKV1Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3Vt ZW50IGNvbXBsZW1lbnRzIHRoZSBwcm9jZXNzIGFzIGRvY3VtZW50ZWQgaW4gdGhlIEpXVDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwMDIiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBkZWNpc2lvbiB3aXRo IGEgY291cGxlIG9mIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFkZGl0aW9uYWw8L3NwYW4+IGVsZW1l bnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGRlY2lzaW9uIHdpdGggYSBj b3VwbGUgb2YgPHNwYW4gY2xhc3M9Imluc2VydCI+c2VwYXJhdGU8L3NwYW4+IGVsZW1lbnRzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBBbiBhZGFwdGF0aW9uIG9mIHRoZSBJRVRG IHdvcmtpbmcgZ3JvdXAgcHJvY2Vzcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBvICBBbiBhZGFwdGF0aW9uIG9mIHRoZSBJRVRGIHdvcmtpbmcgZ3JvdXAgcHJvY2Vzcy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMyIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIG8gIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRoZSBpZGVudGlmaWNh dGlvbiBvZiB0aGUgZXhwZWN0ZWQgSVRVLVQgcGFydGljaXBhdGlvbiBkdXJpbmcgdGhpcyBwcm9j ZXNzPC9zcGFuPi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbyAgPHNwYW4g Y2xhc3M9Imluc2VydCI+SWRlbnRpZmllcyB0aGUgZXhwZWN0ZWQgcGFydGljaXBhdGlvbiBpbiB0 aGUgcHJvY2VzcyBieSB0aGUgSVRVLVQ8L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgbyAgQSBjbGFyaWZpY2F0aW9uIG9mIHRoZSBkZWNpc2lvbiBydWxlcyByZWdhcmRpbmcg TVBMUy1UUCBkb2N1bWVudHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAg QSBjbGFyaWZpY2F0aW9uIG9mIHRoZSBkZWNpc2lvbiBydWxlcyByZWdhcmRpbmcgTVBMUy1UUCBk b2N1bWVudHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwMDQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGlu dGVuZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj50bzwvc3Bhbj4gc3BlY2lmeSBhbnkgSVRVLVQgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+cHJvY2Vzcy4gVG88L3NwYW4+IHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludGVuZCBzcGVjaWZ5 IGFueSBJVFUtVCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wcm9jZXNzLCB0bzwvc3Bhbj4gdGhlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ZXh0ZW50IHRoYXQgaXMgbmVjZXNzYXJ5IGl0IHdpbGwgYmUgZG9uZSA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5ieSB0aGUgSVRVLVQ8L3NwYW4+IGFjY29yZGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBleHRlbnQgdGhhdCBpcyBuZWNlc3NhcnkgaXQgd2lsbCBiZSBkb25lIGFj Y29yZGluZyB0byA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5JVFUtVDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0byA8c3BhbiBj bGFzcz0iZGVsZXRlIj5pdHMgb3duPC9zcGFuPiBwcm9jZXNzZXMuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIHByb2Nlc3Nlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGFibGUg b2YgQ29udGVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEuICBJbnRyb2R1Y3Rp b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDEuMS4gIFRl cm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDEuMS4gIFRlcm1pbm9sb2d5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDEu MS4xLiAgSUVURiB0ZXJtcyBhbmQgYWJicmV2aWF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDEuMS4xLiAgSUVU RiB0ZXJtcyBhbmQgYWJicmV2aWF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAxLjEuMi4gIElUVS1UIHRlcm1zIGFuZCBhYmJyZXZpYXRpb25zICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAxLjEuMi4g IElUVS1UIHRlcm1zIGFuZCBhYmJyZXZpYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAyLiAgQWRhcHRhdGlvbiBvZiB0aGUgSUVURiB3b3JraW5nIGdyb3VwIHByb2Nlc3MgLiAuIC4g LiAuIC4gLiAuIC4gIDY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAyLiAgQWRh cHRhdGlvbiBvZiB0aGUgSUVURiB3b3JraW5nIGdyb3VwIHByb2Nlc3MgLiAuIC4gLiAuIC4gLiAu IC4gIDY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAyLjEuICBBZGFwdGF0aW9uIG9mIHRoZSBJRVRGIHdvcmtpbmcgZ3JvdXAgcHJvY2Vz cyAuIC4gLiAuIC4gLiAuICA2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAy LjEuICBBZGFwdGF0aW9uIG9mIHRoZSBJRVRGIHdvcmtpbmcgZ3JvdXAgcHJvY2VzcyAuIC4gLiAu IC4gLiAuICA2PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgMi4yLiAgVGhlIElFVEYgTVBMUy1UUCBwcm9jZXNzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgMi4yLiAgVGhlIElFVEYgTVBMUy1UUCBwcm9jZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0i cGFydC1sMiIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2Ug NCwgbGluZSA3PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMiIgLz48c21h bGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNCwgbGluZSA3PC9lbT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA1LiAgSUFOQSBjb25zaWRlcmF0aW9ucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICA1LiAgSUFOQSBjb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNi4gIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNi4gIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDcuICBBY2tub3dsZWRnbWVudHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDcuICBBY2tub3dsZWRnbWVudHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA4LiAgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTg8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA4LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTg8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA4LjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA4LjEuICBOb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgOC4yLiAg SW5mb3JtYXRpdmUgcmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgOC4yLiAgSW5mb3JtYXRp dmUgcmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxODwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRo b3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRob3JzJyBBZGRy ZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTk8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDUiIC8+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBXaGVuIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZTwvc3Bhbj4gSUVURiBhbmQgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+dGhlPC9zcGFuPiBJVFUtVCBlbnRlcmVkIGludG8gPHNwYW4gY2xhc3M9ImRl bGV0ZSI+YW48L3NwYW4+IGFncmVlbWVudCB0byBkZXZlbG9wIE1QTFMtVFA8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgV2hlbiBJRVRGIGFuZCBJVFUtVCBlbnRlcmVkIGludG8g PHNwYW4gY2xhc3M9Imluc2VydCI+dGhlPC9zcGFuPiBhZ3JlZW1lbnQgdG8gZGV2ZWxvcCBNUExT LVRQIDxzcGFuIGNsYXNzPSJpbnNlcnQiPndhczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAtIHRoZSBKV1QgYWdyZWVtZW50 IC0gaXQgd2FzIGRlY2lkZWQgdGhhdCB0aGUgTVBMUy1UUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhZ3JlZWQgb248L3NwYW4+IC0gdGhl IEpXVCBhZ3JlZW1lbnQgLSBpdCB3YXMgZGVjaWRlZCB0aGF0IHRoZSBNUExTLVRQPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZG9jdW1l bnRzIHNob3VsZCBiZSBkZXZlbG9wZWQgImFjY29yZGluZyB0byBJRVRGIHByb2Nlc3NlcyIuICA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5BZGRpdGlvbmFsbHksPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBkb2N1bWVudHMgc2hvdWxkIGJlIGRldmVsb3BlZCAiYWNjb3Jk aW5nIHRvIElFVEYgcHJvY2Vzc2VzIi4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkl0IHdhczwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBhIGNsb3NlIGNvb3BlcmF0aW9uIDxzcGFuIGNsYXNzPSJkZWxldGUiPmZvciB0aGUgcmV2 aWV3IHByb2Nlc3Mgb2Y8L3NwYW4+IHRoZXNlIElFVEY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYWxzbyBhc3N1bWVkIHRoYXQ8L3NwYW4+ IGEgY2xvc2UgY29vcGVyYXRpb24gPHNwYW4gY2xhc3M9Imluc2VydCI+aW4gcmV2aWV3aW5nPC9z cGFuPiB0aGVzZSBJRVRGPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZG9jdW1lbnRzIHdhcyBhc3N1 bWVkLjwvc3Bhbj4gVGhlIEpXVCBkZWNpc2lvbiBpcyBkb2N1bWVudGVkIGluIFJGQyA1MzE3IFtS RkM1MzE3XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9 Imluc2VydCI+ZG9jdW1lbnRzLjwvc3Bhbj4gIFRoZSBKV1QgZGVjaXNpb24gaXMgZG9jdW1lbnRl ZCBpbiBSRkMgNTMxNyBbUkZDNTMxN10uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBI b3dldmVyLCB0aGUgcHJvY2VzcyBmb3IgdGhpcyBjbG9zZSBjb29wZXJhdGl2ZSByZXZpZXcgd2Fz IG1vc3RseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhvd2V2ZXIsIHRoZSBw cm9jZXNzIGZvciB0aGlzIGNsb3NlIGNvb3BlcmF0aXZlIHJldmlldyB3YXMgbW9zdGx5PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDAwNiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGxlZnQgdG8gYmUgZGVj aWRlZCBhcyB0aGUgZG9jdW1lbnRzIDxzcGFuIGNsYXNzPSJkZWxldGUiPmV2b2x2ZS48L3NwYW4+ ICBUaGUgSVRVLVQgY29tbWl0dGVkIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIGxlZnQgdG8gYmUgZGVjaWRlZCBhcyB0aGUgZG9jdW1lbnRzIDxzcGFuIGNsYXNzPSJpbnNl cnQiPmV2b2x2ZWQuPC9zcGFuPiAgVGhlIElUVS1UIGNvbW1pdHRlZCB0bzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlc3BvbmRpbmcg cHJvbXB0bHkgdG8gSUVURiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbHMsIDxzcGFuIGNsYXNzPSJk ZWxldGUiPndoaWNoIG1pZ2h0PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICByZXNwb25kaW5nIHByb21wdGx5IHRvIElFVEYgd29ya2luZyBncm91cCBsYXN0IGNhbGxz LCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGlzIG1heTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByZXF1aXJlIHRoZSBkZXZl bG9wbWVudCBvZiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zdWNoIHJlc3BvbnNlczwvc3Bhbj4gdmlh IDxzcGFuIGNsYXNzPSJkZWxldGUiPkVtYWlsPC9zcGFuPiBjb3JyZXNwb25kZW5jZS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcmVxdWlyZSB0aGUgZGV2ZWxvcG1lbnQgb2Yg PHNwYW4gY2xhc3M9Imluc2VydCI+dGhlIHJlc3BvbnNlPC9zcGFuPiB2aWEgY29ycmVzcG9uZGVu Y2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGNvbXBsZW1l bnRzIHRoZSBwcm9jZXNzIGFzIGRvY3VtZW50ZWQgaW4gdGhlIEpXVDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgY29tcGxlbWVudHMgdGhlIHByb2Nlc3Mg YXMgZG9jdW1lbnRlZCBpbiB0aGUgSldUPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNyIgLz48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIGRlY2lzaW9uIHdpdGggYSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5mZXcg b2YgYWRkaXRpb25hbDwvc3Bhbj4gZWxlbWVudHM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIGRlY2lzaW9uIHdpdGggYSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5jb3VwbGUgb2Yg c2VwYXJhdGU8L3NwYW4+IGVsZW1lbnRzOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDA4IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgQW4gYWRh cHRhdGlvbiBvZiB0aGUgSUVURiB3b3JraW5nIGdyb3VwIDxzcGFuIGNsYXNzPSJkZWxldGUiPnBy b2Nlc3M8L3NwYW4+IHdpdGggcmVzcGVjdCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBvICBBbiBhZGFwdGF0aW9uIG9mIHRoZSBJRVRGIHdvcmtpbmcgZ3JvdXAgPHNwYW4g Y2xhc3M9Imluc2VydCI+cHJvY2Vzcyw8L3NwYW4+IHdpdGggcmVzcGVjdCB0bzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIHRoZSBy b2xlIG9mIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5NRUFEPC9zcGFuPiAoTVBMUyBJbnRlcm9w ZXJhYmlsaXR5IDxzcGFuIGNsYXNzPSJkZWxldGUiPkRlc2lnbikgdGVhbSw8L3NwYW4+IHRoZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICB0aGUgcm9sZSBvZiB0aGUgPHNw YW4gY2xhc3M9Imluc2VydCI+dGVhbXM8L3NwYW4+IChNUExTIEludGVyb3BlcmFiaWxpdHkgPHNw YW4gY2xhc3M9Imluc2VydCI+RGVzaWduIFRlYW0gKE1FQUQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgSm9pbnQgV29y a2luZyBUZWFtIChKV1QpIGFuZCB0aGUgSVRVLVQgTVBMUy1UUCBhZCBob2M8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgVGVhbSksPC9z cGFuPiB0aGUgSm9pbnQgV29ya2luZyBUZWFtIChKV1QpIGFuZCB0aGUgSVRVLVQgTVBMUy1UUCBh ZCBob2M8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj50ZWFtPC9zcGFuPiB0aGF0IDxzcGFuIGNs YXNzPSJkZWxldGUiPmhhdmU8L3NwYW4+IGJlZW4gc2V0IHVwIHRvIGZhY2lsaXRhdGUgdGhlIGRl dmVsb3BtZW50IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIDxzcGFu IGNsYXNzPSJpbnNlcnQiPnRlYW0pPC9zcGFuPiB0aGF0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmhh czwvc3Bhbj4gYmVlbiBzZXQgdXAgdG8gZmFjaWxpdGF0ZSB0aGUgZGV2ZWxvcG1lbnQgb2Y8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg TVBMUy1UUDsgc2VlIFNlY3Rpb24gMi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICBNUExTLVRQOyBzZWUgU2VjdGlvbiAyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA5IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+VGhlIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBleHBlY3RlZCBJVFUt VCBwYXJ0aWNpcGF0aW9uIGR1cmluZzwvc3Bhbj4gdGhlIGRvY3VtZW50PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIG8gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPklkZW50aWZpZXMg dGhlIGV4cGVjdGVkIHBhcnRpY2lwYXRpb24gYnkgdGhlIElUVS1UIGluPC9zcGFuPiB0aGUgZG9j dW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgZGV2ZWxvcG1lbnQgcHJvY2Vzczsgc2VlIFNlY3Rpb24gMy48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBkZXZlbG9wbWVudCBwcm9jZXNzOyBzZWUgU2VjdGlv biAzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEw IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+QSBjPC9z cGFuPmxhcmlmaWNhdGlvbiBvZiB0aGUgZGVjaXNpb24gcnVsZXMgcmVnYXJkaW5nIE1QTFMtVFAg ZG9jdW1lbnRzOzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBvICA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5DPC9zcGFuPmxhcmlmaWNhdGlvbiBvZiB0aGUgZGVjaXNpb24gcnVsZXMg cmVnYXJkaW5nIE1QTFMtVFAgZG9jdW1lbnRzOzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBzZWUgU2VjdGlvbiA0LjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHNlZSBTZWN0aW9uIDQuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQg Ik9QVElPTkFMIiBpbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj cmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZD IDIxMTkgW1JGQzIxMTldLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4xLiAgVGVybWlu b2xvZ3k8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xLjEuICBUZXJtaW5vbG9neTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDExIiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBzZWN0aW9uIGluY2x1ZGVzIGEgbnVtYmVyIG9mIHRl cm1zIGFuZCBhYmJyZXZpYXRpb25zIHRoYXQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YXJlPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIHNlY3Rpb24gaW5jbHVk ZXMgYSBudW1iZXIgb2YgdGVybXMgYW5kIGFiYnJldmlhdGlvbnMgdGhhdCA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5pczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICB1c2VkIDxzcGFuIGNsYXNzPSJkZWxldGUiPmluPC9zcGFuPiB0 aGlzIGRvY3VtZW50LiAgVGhlIHNlY3Rpb24gaXMgc3BsaXQgaW50byB0d28gPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+c3Vic2VjdGlvbnM7PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICB1c2VkIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm9uPC9zcGFuPiB0aGlzIGRvY3VtZW50 LiAgVGhlIHNlY3Rpb24gaXMgc3BsaXQgaW50byB0d28gPHNwYW4gY2xhc3M9Imluc2VydCI+c3Vi c2VjdGlvbjs8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIElFVEYgdGVybXMgYW5kIElUVS1UIHRlcm1zLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIElFVEYgdGVybXMgYW5kIElUVS1UIHRlcm1zLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4xLjEuICBJRVRGIHRlcm1zIGFuZCBhYmJyZXZpYXRpb25z PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4xLjEuICBJRVRGIHRlcm1zIGFuZCBh YmJyZXZpYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMTIiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBvICBKV1QgLSBKb2ludCBXb3JraW5n IFRlYW0sIGEgdGVhbSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5vZiBleHBlcnRzPC9zcGFuPiB3aXRo IGV4cGVyaWVuY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbyAgSldUIC0g Sm9pbnQgV29ya2luZyBUZWFtLCBhIHRlYW0gPHNwYW4gY2xhc3M9Imluc2VydCI+d2l0aCBwYXJ0 aWNpcGFudHM8L3NwYW4+IHdpdGggZXhwZXJpZW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUi PmluIGJvdGgsPC9zcGFuPiBzdGFuZGFyZHMgZGV2ZWxvcG1lbnQgaW4gdGhlIElFVEYgYW5kIHRo ZSBJVFUtVC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgPHNwYW4gY2xh c3M9Imluc2VydCI+ZnJvbTwvc3Bhbj4gc3RhbmRhcmRzIGRldmVsb3BtZW50IGluIHRoZSBJRVRG IGFuZCB0aGUgSVRVLVQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBOb3RlOiBU aGUgSldUIGlzIG5vdCBwYXJ0IG9mIGVpdGhlciB0aGUgSUVURiBvciBJVFUtVCwgYnV0IGEgZ3Jv dXA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBOb3RlOiBUaGUgSldUIGlz IG5vdCBwYXJ0IG9mIGVpdGhlciB0aGUgSUVURiBvciBJVFUtVCwgYnV0IGEgZ3JvdXA8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdGhh dCBoYXMgYmVlbiBzZXQgdXAgdG8gZmFjaWxpdGF0ZSBjb29wZXJhdGlvbiBvbiBNUExTLVRQIGJl dHdlZW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0aGF0IGhhcyBiZWVu IHNldCB1cCB0byBmYWNpbGl0YXRlIGNvb3BlcmF0aW9uIG9uIE1QTFMtVFAgYmV0d2VlbjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0 aGUgdHdvIG9yZ2FuaXphdGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgdGhlIHR3byBvcmdhbml6YXRpb25zLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDEzIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgSldUIGRv Y3VtZW50cyAtIHRoZSBzZXQgb2YgZG9jdW1lbnRzIHRoYXQgd2VyZSBlbnZpc2lvbmVkIDxzcGFu IGNsYXNzPSJkZWxldGUiPmF0PC9zcGFuPiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgbyAgSldUIGRvY3VtZW50cyAtIHRoZSBzZXQgb2YgZG9jdW1lbnRzIHRoYXQgd2Vy ZSBlbnZpc2lvbmVkIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmluPC9zcGFuPiB0aGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA8c3Bh biBjbGFzcz0iZGVsZXRlIj50aW1lPC9zcGFuPiB0aGUgSldUIGRlY2lzaW9uIDxzcGFuIGNsYXNz PSJkZWxldGUiPndhcyB3cml0dGVuIGRvd248L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRvY3VtZW50YXRpb24gb2Y8L3Nw YW4+IHRoZSBKV1QgZGVjaXNpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIE1F QUQgdGVhbSAtIE1QTFMgSW50ZXJvcGVyYWJpbGl0eSBEZXNpZ24gVGVhbSwgYSB0ZW1wb3Jhcnkg dGVhbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIE1FQUQgdGVhbSAtIE1Q TFMgSW50ZXJvcGVyYWJpbGl0eSBEZXNpZ24gVGVhbSwgYSB0ZW1wb3JhcnkgdGVhbTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAwMTQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5vZiBleHBlcnRzIHdpdGggZXhwZXJpZW5jZSBpbjwvc3Bhbj4gc3RhbmRhcmRzIGRl dmVsb3BtZW50IGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij53aXRoIHBhcnRpY2lwYW50cyB3aXRoIGV4cGVyaWVuY2UgZnJvbTwv c3Bhbj4gc3RhbmRhcmRzIGRldmVsb3BtZW50IGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBNUExTIGFuZCB0cmFuc3BvcnQgbmV0 d29ya3MuICBUaGUgTUVBRCB0ZWFtIGlzIGNoYXJ0ZXJlZCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIE1QTFMgYW5kIHRyYW5zcG9ydCBuZXR3b3Jrcy4gIFRoZSBNRUFE IHRlYW0gaXMgY2hhcnRlcmVkIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNSIgLz48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPmNvb3JkaW5hdGU8L3NwYW4+IHRo ZSBkZXZlbG9wbWVudCBvZiBNUExTLVRQIHdpdGhpbiB0aGUgSUVURiBhbmQgdG88L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Y29vcmRp bmF0ZWQ8L3NwYW4+IHRoZSBkZXZlbG9wbWVudCBvZiBNUExTLVRQIHdpdGhpbiB0aGUgSUVURiBh bmQgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICAgICBjb29yZGluYXRlIHRoZSBjb29wZXJhdGlvbiB3aXRoIHRoZSA8c3BhbiBjbGFz cz0iZGVsZXRlIj5JVFUtVCBvbiBNUExTLVRQLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgICAgY29vcmRpbmF0ZSB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+b24g TVBMUy1UUDwvc3Bhbj4gY29vcGVyYXRpb24gd2l0aCB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+ SVRVLVQuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDE2IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgTVBMUy1UUCBkb2N1bWVudHMg LSB0aGUgZm9sbG93aW5nIHNldHMgb2YgZG9jdW1lbnRzIGFyZSBjbzxzcGFuIGNsYXNzPSJkZWxl dGUiPm5zaWRlcmVkIHRvIGJlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBvICBNUExTLVRQIGRvY3VtZW50cyAtIHRoZSBmb2xsb3dpbmcgc2V0cyBvZiBkb2N1bWVu dHMgYXJlIGNvPHNwYW4gY2xhc3M9Imluc2VydCI+dW50ZWQgYXM8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE1QTFMtVFAg ZG9jdW1lbnRzOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE1QTFMtVFAg ZG9jdW1lbnRzOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgKiAgSW50ZXJuZXQg RHJhZnRzIHRoYXQgYXJlIGNvb3JkaW5hdGVkIGJ5IHRoZSBNRUFEIHRlYW0uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKiAgSW50ZXJuZXQgRHJhZnRzIHRoYXQgYXJlIGNv b3JkaW5hdGVkIGJ5IHRoZSBNRUFEIHRlYW0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTciIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAqICBJ bmRpdmlkdWFsIEludGVybmV0IERyYWZ0cyB0aGF0IGFkZHJlc3MgdGhlIE1QTFMtVFAgcHJvYmxl bTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAqICBJbmRpdmlkdWFsIElu dGVybmV0IERyYWZ0cyB0aGF0IGFkZHJlc3M8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5lczwvc3Bhbj4g dGhlIE1QTFMtVFAgcHJvYmxlbTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBzcGFjZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICBzcGFjZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAxOCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICogIFdvcmtp bmcgZ3JvdXAgSW50ZXJuZXQgRHJhZnRzIHRoYXQgYWRkcmVzcyB0aGUgTVBMUy1UUDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAqICBXb3JraW5nIGdyb3VwIEludGVybmV0 IERyYWZ0cyB0aGF0IGFkZHJlc3M8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5lczwvc3Bhbj4gdGhlIE1Q TFMtVFA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgcHJvYmxlbSBzcGFjZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICBwcm9ibGVtIHNwYWNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgKiAgSW50ZXJuZXQgRHJhZnRzIHRoYXQgYXJlIGNvbnNpZGVyZWQgZm9yIHB1YmxpY2F0aW9u IGJ5IHRoZSBJRVNHPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKiAgSW50 ZXJuZXQgRHJhZnRzIHRoYXQgYXJlIGNvbnNpZGVyZWQgZm9yIHB1YmxpY2F0aW9uIGJ5IHRoZSBJ RVNHPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxOSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAg IGFuZCB0aGF0IGFkZHJlc3MgdGhlIE1QTFMtVFAgcHJvYmxlbSBzcGFjZS48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgYW5kIHRoYXQgYWRkcmVzczxzcGFuIGNsYXNz PSJpbnNlcnQiPmVzPC9zcGFuPiB0aGUgTVBMUy1UUCBwcm9ibGVtIHNwYWNlLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgKiAgSW50ZXJuZXQgRHJhZnRzIHRoYXQgYXJlIGFwcHJv dmVkIGZvciBwdWJsaWNhdGlvbiBieSB0aGUgSUVTRzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICogIEludGVybmV0IERyYWZ0cyB0aGF0IGFyZSBhcHByb3ZlZCBmb3IgcHVi bGljYXRpb24gYnkgdGhlIElFU0c8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDIwIiAvPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgYW5kIHRoYXQgYWRkcmVzcyB0aGUgTVBMUy1UUCBwcm9ibGVtIHNw YWNlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICBhbmQgdGhhdCBh ZGRyZXNzPHNwYW4gY2xhc3M9Imluc2VydCI+ZXM8L3NwYW4+IHRoZSBNUExTLVRQIHByb2JsZW0g c3BhY2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MjEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAqICBQdWJsaXNoZWQgUkZDcyB0aGF0IGFk ZHJlc3MgdGhlIE1QTFMtVFAgcHJvYmxlbSBzcGFjZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgKiAgUHVibGlzaGVkIFJGQ3MgdGhhdCBhZGRyZXNzPHNwYW4gY2xhc3M9 Imluc2VydCI+ZXM8L3NwYW4+IHRoZSBNUExTLVRQIHByb2JsZW0gc3BhY2UuPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAqICBJVFUtVCBSZWNvbW1lbmRhdGlvbnMgYW5kIGRyYWZ0 IFJlY29tbWVuZGF0aW9ucyBpbiB2YXJpb3VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgKiAgSVRVLVQgUmVjb21tZW5kYXRpb25zIGFuZCBkcmFmdCBSZWNvbW1lbmRhdGlv bnMgaW4gdmFyaW91czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjIiIC8+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICBzdGFnZXMgb2YgZGV2ZWxvcG1lbnQgdGhhdCBhZGRyZXNzIHRoZSBNUExTLVRQ IHByb2JsZW0gc3BhY2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAg IHN0YWdlcyBvZiBkZXZlbG9wbWVudCB0aGF0IGFkZHJlc3M8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5l czwvc3Bhbj4gdGhlIE1QTFMtVFAgcHJvYmxlbSBzcGFjZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyMyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IERvY3VtZW50cyB0aGF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPm9yaWdpbmF0ZTwvc3Bhbj4gZnJv bSB0aGUgSVJURiBSRkMgc3RyZWFtIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFyZTwvc3Bhbj4gTk9U IGNvbnNpZGVyZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgRG9jdW1lbnRz IHRoYXQgPHNwYW4gY2xhc3M9Imluc2VydCI+b3JpZ2luYXRlczwvc3Bhbj4gZnJvbSB0aGUgSVJU RiBSRkMgc3RyZWFtIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmlzPC9zcGFuPiBOT1QgY29uc2lkZXJl ZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRvIGJlPC9zcGFuPiBNUExTLVRQIGRvY3VtZW50cy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ YXM8L3NwYW4+IE1QTFMtVFAgZG9jdW1lbnRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ MS4xLjIuICBJVFUtVCB0ZXJtcyBhbmQgYWJicmV2aWF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjEuMS4yLiAgSVRVLVQgdGVybXMgYW5kIGFiYnJldmlhdGlvbnM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyNCIgLz48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIG8gIEFkIEhvYyBvbiBNUExTLVRQIC0gQSB0ZWFtIGVzdGFibGlzaGVk IGJ5IFNHIDE1IG9mIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZSA8L3NwYW4+SVRVLVQgdG88L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbyAgQWQgSG9jIG9uIE1QTFMtVFAgLSBB IHRlYW0gZXN0YWJsaXNoZWQgYnkgU0cgMTUgb2YgSVRVLVQgdG88L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgY29vcmRpbmF0ZSB0aGUg d29yayBvbiBNUExTLVRQIHdpdGhpbiB0aGUgSVRVLVQgYW5kIHRvIGFjdCBhcyBhPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgY29vcmRpbmF0ZSB0aGUgd29yayBvbiBNUExT LVRQIHdpdGhpbiB0aGUgSVRVLVQgYW5kIHRvIGFjdCBhcyBhPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGZvY2FsIHBvaW50IGZvciBj b21tdW5pY2F0aW9uIHdpdGggdGhlIElFVEYuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgZm9jYWwgcG9pbnQgZm9yIGNvbW11bmljYXRpb24gd2l0aCB0aGUgSUVURi48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIENvbnRyaWJ1dGlvbiAtIGEgY29udHJpYnV0 aW9uIGlzIGEgZG9jdW1lbnQgdGhhdCBpcyBzdWJtaXR0ZWQgdG88L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBvICBDb250cmlidXRpb24gLSBhIGNvbnRyaWJ1dGlvbiBpcyBhIGRv Y3VtZW50IHRoYXQgaXMgc3VibWl0dGVkIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRoZSBJVFUtVCB0byBhZHZhbmNlIHdvcmsg b24gdGhlIGRldmVsb3BtZW50IG9mIGEgUmVjb21tZW5kYXRpb248L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICB0aGUgSVRVLVQgdG8gYWR2YW5jZSB3b3JrIG9uIHRoZSBkZXZl bG9wbWVudCBvZiBhIFJlY29tbWVuZGF0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIG9yIHRvIHByb3Bvc2UgdGhlIGRldmVsb3Bt ZW50IG9mIGEgbmV3IFJlY29tbWVuZGF0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgIG9yIHRvIHByb3Bvc2UgdGhlIGRldmVsb3BtZW50IG9mIGEgbmV3IFJlY29tbWVu ZGF0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYw MDI1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgUmVjb21tZW5kYXRpb24gLSBhIFJlY29t bWVuZGF0aW9uIGlzIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFuPC9zcGFuPiBJVFUtVCBzdGFuZGFy ZHMgZG9jdW1lbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG8gIFJlY29t bWVuZGF0aW9uIC0gYSBSZWNvbW1lbmRhdGlvbiBpcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGU8 L3NwYW4+IElUVS1UIHN0YW5kYXJkcyBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjIuICBBZGFwdGF0aW9uIG9mIHRoZSBJRVRGIHdvcmtpbmcgZ3JvdXAgcHJvY2VzczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuICBBZGFwdGF0aW9uIG9mIHRoZSBJRVRGIHdv cmtpbmcgZ3JvdXAgcHJvY2VzczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDI2IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+Rm9yIHRoZSBwdXJwb3NlIG9mIE1QTFMtVFAsIHRoZTwvc3Bhbj4gSUVURiB3b3JraW5n IGdyb3VwIHByb2Nlc3NlcyBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGU8L3NwYW4+IElFVEYgd29ya2luZyBncm91cCBwcm9jZXNz ZXMgYXMgZGVmaW5lZCBpbiBSRkMgMjAyNiBbUkZDMjAyNl0gYXJlPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZGVmaW5lZCBpbiBSRkMg MjAyNiBbUkZDMjAyNl0gYXJlIHVwZGF0ZWQgYXMgZm9sbG93cy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Zm9yIHRoZSBwdXJwb3NlIG9m IHRoZSBNUExTLVRQPC9zcGFuPiB1cGRhdGVkIGFzIGZvbGxvd3MuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjciIC8+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGU8L3NwYW4+IElFVEYgd29ya3MgYWNjb3JkaW5n IDxzcGFuIGNsYXNzPSJkZWxldGUiPnRvPC9zcGFuPiB0aGUgJ3JvdWdoIGNvbnNlbnN1cycgbW9k ZWwgd2hlcmUgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIElFVEYgd29y a3MgYWNjb3JkaW5nIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZTwvc3Bhbj4gdGhlICdyb3VnaCBj b25zZW5zdXMnIG1vZGVsIHdoZXJlIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIDxzcGFuIGNs YXNzPSJkZWxldGUiPmRldGVybWluZTwvc3Bhbj4gdGhlIGNvbnNlbnN1cyBhZnRlciBkaXNjdXNz aW9ucyBvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB3b3JraW5nIGdyb3Vw IGNoYWlycyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kZXRlcm1pbmVzPC9zcGFuPiB0aGUgY29uc2Vu c3VzIGFmdGVyIGRpc2N1c3Npb25zIG9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdGhlIG1haWxpbmcgbGlzdHMuICBUaGlzIGlzIDxz cGFuIGNsYXNzPSJkZWxldGUiPmFsc288L3NwYW4+IGFwcGxpY2FibGUgdG8gdGhlIE1QTFMtVFAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+d29yay48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIHRoZSBtYWlsaW5nIGxpc3RzLiAgVGhpcyBpcyBhcHBsaWNhYmxlIHRvIHRo ZSBNUExTLVRQIDxzcGFuIGNsYXNzPSJpbnNlcnQiPndvcmsgYWxzby4gIFRoZTwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbXBs cy10cEBpZXRmLm9yZyBpcyB0aGUgbWFpbGluZyBsaXN0IHVzZWQgdG8gZmluZCBvdXQgY29uc2Vu c3VzIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1wbHMtdHBAaWV0Zi5v cmcgaXMgdGhlIG1haWxpbmcgbGlzdCB1c2VkIHRvIGZpbmQgb3V0IGNvbnNlbnN1cyBhbmQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk PjxhIG5hbWU9ImRpZmYwMDI4IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgY29uc2Vuc3VzIGlz IGRlY2lkZWQgYnkgdGhlIE1FQUQgdGVhbSBjaGFpci4gIEFmdGVyIGEgZG9jdW1lbnQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+dGhlPC9z cGFuPiBjb25zZW5zdXMgaXMgZGVjaWRlZCBieSB0aGUgTUVBRCB0ZWFtIGNoYWlyLiAgQWZ0ZXIg YSBkb2N1bWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIGhhcyBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIDxzcGFuIGNsYXNzPSJkZWxl dGUiPmRvY3VtZW50LDwvc3Bhbj4gdGhlIGNvbnNlbnN1cyBpcyBkZWNpZGVkIGJ5IHRoZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBoYXMgYmVjb21lIGEgd29ya2luZyBncm91 cCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kb2N1bWVudDwvc3Bhbj4gdGhlIGNvbnNlbnN1cyBpcyBk ZWNpZGVkIGJ5IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBXRyBjaGFpcnMgYW5kIHRoZSBNRUFEIHRlYW0gY2hhaXIgam9pbnRseS48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBXRyBjaGFpcnMgYW5kIHRoZSBNRUFE IHRlYW0gY2hhaXIgam9pbnRseS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDAyOSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEEgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+dml0YWxseTwvc3Bhbj4gaW1wb3J0YW50IHBhcnQgb2YgdGhpcyBwcm9jZXNzIGlz IHRoZSBpbmZvcm1hdGlvbiBleGNoYW5nZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBBIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm1vc3Q8L3NwYW4+IGltcG9ydGFudCBwYXJ0IG9m IHRoaXMgcHJvY2VzcyBpcyB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2U8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBiZXR3ZWVuIHRoZSBJ RVRGIGFuZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj50aGU8L3NwYW4+IElUVS1ULiAgVGhpcyBpbmZv cm1hdGlvbiBleGNoYW5nZSBjb25zaXN0cyBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBiZXR3ZWVuIHRoZSBJRVRGIGFuZCBJVFUtVC4gIFRoaXMgaW5mb3JtYXRpb24gZXhj aGFuZ2UgY29uc2lzdHMgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgdHdvIGVxdWFsbHkgaW1wb3J0YW50IHBpZWNlczo8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0d28gZXF1YWxseSBpbXBvcnRhbnQgcGllY2VzOjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgaW5mb3JtYWwgaW5mb3JtYXRpb24gZXhj aGFuZ2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBpbmZvcm1hbCBpbmZv cm1hdGlvbiBleGNoYW5nZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDMwIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgdGhpcyBpcyBkb25lIHBy aW1hcmlseSBieSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5FPC9zcGFuPm1haWxzIHRvIHRoZSByZWxl dmFudCBtYWlsaW5nIGxpc3RzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAg ICB0aGlzIGlzIGRvbmUgcHJpbWFyaWx5IGJ5IG1haWxzIHRvIHRoZSByZWxldmFudCBtYWlsaW5n IGxpc3RzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgZm9ybWFsIGluZm9ybWF0 aW9uIGV4Y2hhbmdlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgZm9ybWFs IGluZm9ybWF0aW9uIGV4Y2hhbmdlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+ PGEgbmFtZT0iZGlmZjAwMzEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBJbiBhZGRpdGlv biB0byA8c3BhbiBjbGFzcz0iZGVsZXRlIj5FbWFpbHM8L3NwYW4+IHRvIHRoZSByZWxldmFudCBt YWlsaW5nIGxpc3RzLCB0aGUgZm9ybWFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgIEluIGFkZGl0aW9uIHRvIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmEgbWFpbDwvc3Bhbj4g dG8gdGhlIHJlbGV2YW50IG1haWxpbmcgbGlzdHMsIHRoZSBmb3JtYWw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBpbmZvcm1hdGlv biBleGNoYW5nZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5pbmNsdWRlczwvc3Bhbj4gYSA8c3BhbiBj bGFzcz0iZGVsZXRlIj5mb3JtYWw8L3NwYW4+IGxpYWlzb24gYmV0d2VlbiB0aGUgdHdvPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIGluZm9ybWF0aW9uIGV4Y2hhbmdlIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmlzIGFjY29tcGFuaWVkIGJ5PC9zcGFuPiBhIGxpYWlzb24gYmV0 d2VlbiB0aGUgdHdvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICAgb3JnYW5pc2F0aW9ucy4gIEV4Y2hhbmdlIG9mIDxzcGFuIGNsYXNz PSJkZWxldGUiPmxpYWlzb24gc3RhdGVtZW50czwvc3Bhbj4gbWFrZXMgaXQgcG9zc2libGUgdG8g Zm9sbG93PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIG9yZ2FuaXNhdGlv bnMuICBFeGNoYW5nZSBvZiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5saWFpc29uczwvc3Bhbj4gbWFr ZXMgaXQgcG9zc2libGUgdG8gZm9sbG93PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgdGhlIHJlcXVlc3QvcmVzcG9uc2UgZXhjaGFu Z2UgYmV0d2VlbiB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dHdvPC9zcGFuPiBvcmdhbmlzYXRp b25zIDxzcGFuIGNsYXNzPSJkZWxldGUiPmluPC9zcGFuPiBtb3JlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgIHRoZSByZXF1ZXN0L3Jlc3BvbnNlIGV4Y2hhbmdlIGJldHdl ZW4gdGhlIG9yZ2FuaXNhdGlvbnMgPHNwYW4gY2xhc3M9Imluc2VydCI+aSBuPC9zcGFuPiBtb3Jl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIGRldGFpbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBkZXRhaWwu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4yLjEuICBBZGFwdGF0aW9uIG9mIHRoZSBJRVRG IHdvcmtpbmcgZ3JvdXAgcHJvY2VzczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIu MS4gIEFkYXB0YXRpb24gb2YgdGhlIElFVEYgd29ya2luZyBncm91cCBwcm9jZXNzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZmxvdyBjaGFydCBiZWxvdyBkZXNjcmliZXMgdGhl IGFkYXB0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVGhlIGZsb3cgY2hhcnQgYmVsb3cgZGVzY3JpYmVzIHRoZSBhZGFwdGlvbiBvZiB0 aGUgd29ya2luZyBncm91cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMzIiIC8+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5wcm9jZXNzLjwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+cHJvY2Vzczwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg Li4uLi4uLi4uLi4uLiAgICAgICAgICAgICAgICAgICAgICAgICAuLi4uLi4uLi4uLi4uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIC4uLi4uLi4uLi4uLi4gICAgICAgICAg ICAgICAgICAgICAgICAgLi4uLi4uLi4uLi4uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgOiBJbmQgRG9jcyAgOi0tLS0tLS0tLS0r ICAgICAgICAgICAgICA6IEpXVCBkb2NzICA6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgIDogSW5kIERvY3MgIDotLS0tLS0tLS0tKyAgICAgICAgICAgICAgOiBKV1QgZG9j cyAgOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgLi4uLi4uLi4uLi4uLiAgICAgICAgICB8ICAgICAgICAgICAgICAuLi4uLi4uLi4u Li4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIC4uLi4uLi4uLi4uLi4g ICAgICAgICAgfCAgICAgICAgICAgICAgLi4uLi4uLi4uLi4uLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg fDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgfCBpbmQtMDAgKDEpICAgICB8ICBpbmQtMDAgKDIpICAgICAgICB8IGluZC0w MCAoMyk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgfCBpbmQt MDAgKDEpICAgICB8ICBpbmQtMDAgKDIpICAgICAgICB8IGluZC0wMCAoMyk8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg djwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICB2ICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAg fCAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgKDQpICArLS0tLS0tLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICB8 ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAoNCkgICstLS0tLS0tKzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgfCAg V0cgcHJvYyAgfCAgICAgICAgICArLS0tLS0tLS0tLS0tLSZndDt8IE1FQUQgdGVhbSBwcm9jIHwm bHQ7LS0tLS0tJmd0O3wgSVRVLVQgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICB8ICBXRyBwcm9jICB8ICAgICAgICAgICstLS0tLS0tLS0tLS0tJmd0O3wgTUVBRCB0ZWFt IHByb2MgfCZsdDstLS0tLS0mZ3Q7fCBJVFUtVCB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICB8ICAgICAgICAgICB8LS0tLS0tLS0r ICAgICAgICAgKy0tLS0tLXwgICAgICAgICAgICAgICAgfCAgICAgICAgKy0tLS0tLS0rPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIHwgICAgICAgICAgIHwtLS0tLS0tLSsg ICAgICAgICArLS0tLS0tfCAgICAgICAgICAgICAgICB8ICAgICAgICArLS0tLS0tLSs8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBi Z2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDMiIC8+PHNtYWxsPnNr aXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDgsIGxpbmUgODwvZW0+PC90aD48 dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjMiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5n ZSBhdDwvc21hbGw+PGVtPiBwYWdlIDgsIGxpbmUgODwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4yLiAgVGhlIElFVEYg TVBMUy1UUCBwcm9jZXNzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Mi4yLiAgVGhl IElFVEYgTVBMUy1UUCBwcm9jZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlz IHNlY3Rpb24gZ2l2ZXMgZ3VpZGVsaW5lcyBmb3IgaG93IHRoZSBmbG93IGNoYXJ0IGFib3ZlIGNv dWxkIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBzZWN0aW9uIGdp dmVzIGd1aWRlbGluZXMgZm9yIGhvdyB0aGUgZmxvdyBjaGFydCBhYm92ZSBjb3VsZCBiZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmF2 ZXJzZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdHJhdmVyc2VkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4yLjEuICBEZXZlbG9waW5nIGEgTVBMUy1UUCBkb2N1 bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuMi4xLiAgRGV2ZWxvcGluZyBh IE1QTFMtVFAgZG9jdW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluZGl2aWR1 YWwgTVBMUy1UUCBkb2N1bWVudHMgbWF5IHRha2UgZGlmZmVyZW50IHBhdGhzIHRocm91Z2ggdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW5kaXZpZHVhbCBNUExTLVRQIGRv Y3VtZW50cyBtYXkgdGFrZSBkaWZmZXJlbnQgcGF0aHMgdGhyb3VnaCB0aGU8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDMzIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ cHJvY2Vzcy4gTm90ZSB0aGF0PC9zcGFuPiB0aGUgbnVtYmVycyBpbiB0aGUgbGlzdCBiZWxvdyA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5jb3JyZXNwb25kPC9zcGFuPiB0byB0aGU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+dGhpcyBwcm9jZXNz LDwvc3Bhbj4gdGhlIG51bWJlcnMgaW4gdGhlIGxpc3QgYmVsb3cgPHNwYW4gY2xhc3M9Imluc2Vy dCI+aXMgbWFwcGVkPC9zcGFuPiB0byB0aGUgbnVtYmVyczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG51bWJlcnMgaW4gdGhlIGZsb3cg Y2hhcnQgYWJvdmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGluIHRoZSBm bG93IGNoYXJ0IGFib3ZlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDM0IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQWx0aG91Z2ggdGhlIGRpZmZl cmVudCBwYXRocyB0aHJvdWdoIHRoZSBmbG93IGNoYXJ0IDxzcGFuIGNsYXNzPSJkZWxldGUiPmFy ZTwvc3Bhbj4gZ2l2ZW4gYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQWx0 aG91Z2ggdGhlIGRpZmZlcmVudCBwYXRocyB0aHJvdWdoIHRoZSBmbG93IGNoYXJ0IDxzcGFuIGNs YXNzPSJpbnNlcnQiPmlzPC9zcGFuPiBnaXZlbiBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICdvcHRpb25zJyBpdCBpcyBhbHdheXMg cG9zc2libGUgZm9yIHRoZSBNRUFEIHRlYW0gdG8gc3RlcCBpbiA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5hbmQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICdvcHRpb25z JyBpdCBpcyBhbHdheXMgcG9zc2libGUgZm9yIHRoZSBNRUFEIHRlYW0gdG8gc3RlcCBpbiA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5hYW5kPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRha2Ugb3ZlciB0aGUgc2hlcGhlcmRpbmcg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+b2Y8L3NwYW4+IGEgcGFydGljdWxhciBkb2N1bWVudC4gIFRo aXMgaXMgZG9uZSBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0YWtlIG92 ZXIgdGhlIHNoZXBoZXJkaW5nIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmFmPC9zcGFuPiBhIHBhcnRp Y3VsYXIgZG9jdW1lbnQuICBUaGlzIGlzIGRvbmUgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29vcGVyYXRpb24gYmV0d2VlbiB0aGUg TUVBRCB0ZWFtIGNoYWlyLCB0aGUgcmVsZXZhbnQgd29ya2luZyBncm91cDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvb3BlcmF0aW9uIGJldHdlZW4gdGhlIE1FQUQgdGVhbSBj aGFpciwgdGhlIHJlbGV2YW50IHdvcmtpbmcgZ3JvdXA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2hhaXJzIGFuZCB0aGUgZG9jdW1lbnQg ZWRpdG9ycy9hdXRob3JzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNoYWly cyBhbmQgdGhlIGRvY3VtZW50IGVkaXRvcnMvYXV0aG9ycy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAzNSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IDEuICAgVGhlPHNwYW4gY2xhc3M9ImRlbGV0ZSI+IGRvY3VtZW50PC9zcGFuPiBtYXkgYmUgaW50 ZW5kZWQgZm9yIGFuZCBtYW5hZ2VkIGJ5IGEgd29ya2luZyBncm91cC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgMS4gICBUaGU8c3BhbiBjbGFzcz0iaW5zZXJ0Ij55PC9zcGFu PiBtYXkgYmUgaW50ZW5kZWQgZm9yIGFuZCBtYW5hZ2VkIGJ5IGEgd29ya2luZyBncm91cC48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgVGhpcyBtZWFucyB0aGF0IHRoZSBhdXRo b3Iocykgb2Ygc3VjaCBhIGRvY3VtZW50IGhhcyBjaG9zZW4gdG88L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgIFRoaXMgbWVhbnMgdGhhdCB0aGUgYXV0aG9yKHMpIG9mIHN1 Y2ggYSBkb2N1bWVudCBoYXMgY2hvc2VuIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAzNiIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgICAgICAgc2VuZCB0aGUgZG9jdW1lbnQgdG8gPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+dGhlPC9zcGFuPiB3b3JraW5nIGdyb3VwIGluc3RlYWQgb2YgcnVubmluZyB0aHJv dWdoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgc2VuZCB0aGUgZG9j dW1lbnQgdG8gPHNwYW4gY2xhc3M9Imluc2VydCI+YTwvc3Bhbj4gd29ya2luZyBncm91cCBpbnN0 ZWFkIG9mIHJ1bm5pbmcgdGhyb3VnaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgdGhlIE1FQUQgdGVhbS4gIDxzcGFuIGNsYXNz PSJkZWxldGUiPlRoZSBub3JtYWw8L3NwYW4+IElFVEYgcHJvY2VzcyB3aWxsIGtpY2sgaW4gaW4g c3VjaCBjYXNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgIHRoZSBN RUFEIHRlYW0uICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Ob3JtYWw8L3NwYW4+IElFVEYgcHJvY2Vz cyB3aWxsIGtpY2sgaW4gaW4gc3VjaCBjYXNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgYW5kIDxzcGFuIGNsYXNzPSJkZWxl dGUiPnRoZTwvc3Bhbj4gd29ya2luZyBncm91cCBjaGFpcnMgd2lsbCA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5kZWNpZGU8L3NwYW4+IHRvIHdoaWNoIHdvcmtpbmcgZ3JvdXAocyk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICBhbmQgd29ya2luZyBncm91cCBjaGFpcnMgd2ls bCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hZ3JlZTwvc3Bhbj4gdG8gd2hpY2ggd29ya2luZyBncm91 cChzKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgIHN1Y2ggYSBkb2N1bWVudCB3aWxsIGJlIHRha2VuLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgc3VjaCBhIGRvY3VtZW50IHdpbGwgYmUgdGFrZW4uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMzciIC8+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAyLiAgIFRoZTxzcGFuIGNsYXNzPSJkZWxldGUiPiBkb2N1bWVu dDwvc3Bhbj4gbWF5IGJlIGNvb3JkaW5hdGVkIGJ5IHRoZSBNRUFEIHRlYW0uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDIuICAgVGhlPHNwYW4gY2xhc3M9Imluc2VydCI+eTwv c3Bhbj4gbWF5IGJlIGNvb3JkaW5hdGVkIGJ5IHRoZSBNRUFEIHRlYW0uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgIFRoaXMgbWVhbnMgdGhhdCB0aGUgYXV0aG9yKHMpIG9mIHN1 Y2ggYSBkb2N1bWVudCBoYXMgY2hvc2VuIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICBUaGlzIG1lYW5zIHRoYXQgdGhlIGF1dGhvcihzKSBvZiBzdWNoIGEgZG9jdW1l bnQgaGFzIGNob3NlbiB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgIHNlbmQgdGhlIGRvY3VtZW50IHRvIHRoZSBNRUFEIHRlYW0g dG8gYmUgY29vcmRpbmF0ZWQgd2l0aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgIHNlbmQgdGhlIGRvY3VtZW50IHRvIHRoZSBNRUFEIHRlYW0gdG8gYmUgY29vcmRp bmF0ZWQgd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDM4IiAvPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICByZXN0IG9mIHRoZSBNUExTLVRQIGRvY3VtZW50cyB0aGF0IDxzcGFuIGNsYXNz PSJkZWxldGUiPmFyZTwvc3Bhbj4gaW4gdGhlIHB1cnZpZXcgb2YgdGhlIE1FQUQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICByZXN0IG9mIHRoZSBNUExTLVRQIGRvY3Vt ZW50cyB0aGF0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmlzPC9zcGFuPiBpbiB0aGUgcHVydmlldyBv ZiB0aGUgTUVBRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgIHRlYW0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICB0ZWFtLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRp ZmYwMDM5IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMy4gICA8c3BhbiBjbGFzcz0iZGVsZXRl Ij5UaGUgZG9jdW1lbnQgY29tZSBmcm9tPC9zcGFuPiB0aGUgTUVBRCB0ZWFtIGJhc2VkIG9uIHRo ZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5KV1Q8L3NwYW4+IGRlY2lzaW9uLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAzLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoZXkgbWF5 IGJlIG9yaWdpbmF0ZWQgYnk8L3NwYW4+IHRoZSBNRUFEIHRlYW0gYmFzZWQgb24gdGhlIDxzcGFu IGNsYXNzPSJpbnNlcnQiPmp3dDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICAgICBkZWNpc2lvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDA0MCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+Rm9yIHQ8L3NwYW4+aGUgZG9jdW1lbnRhdGlvbiBvZiB0aGUgd29yayBvZiB0 aGUgSldULCB0aGVyZSBpcyBhIHByb3Bvc2VkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+VDwvc3Bhbj5oZSBkb2N1bWVudGF0aW9u IG9mIHRoZSB3b3JrIG9mIHRoZSBKV1QsIHRoZXJlIGlzIGEgcHJvcG9zZWQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBkb2N1bWVu dCBzdHJ1Y3R1cmUuICBUaGUgTUVBRCB0ZWFtIHVzZWQgdGhpcyBzdHJ1Y3R1cmUgdG8gZGVjaWRl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBkb2N1bWVudCBzdHJ1Y3R1 cmUuICBUaGUgTUVBRCB0ZWFtIHVzZWQgdGhpcyBzdHJ1Y3R1cmUgdG8gZGVjaWRlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgb24g YSBzZXQgb2YgZG9jdW1lbnRzIHRoYXQgd2lsbCwgd2hlbiBjb21wbGV0ZWQsIGNvbnN0aXR1dGUg dGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBvbiBhIHNldCBvZiBk b2N1bWVudHMgdGhhdCB3aWxsLCB3aGVuIGNvbXBsZXRlZCwgY29uc3RpdHV0ZSB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDQxIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICBNUExTLVRQIHN0 YW5kYXJkLiAgVGhpcyBzZXQgb2YgZG9jdW1lbnRzIDxzcGFuIGNsYXNzPSJkZWxldGUiPmlzPC9z cGFuPiBzbGlnaHRseSBjaGFuZ2luZyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgICBNUExTLVRQIHN0YW5kYXJkLiAgVGhpcyBzZXQgb2YgZG9jdW1lbnRzIDxzcGFuIGNs YXNzPSJpbnNlcnQiPmFyZTwvc3Bhbj4gc2xpZ2h0bHkgY2hhbmdpbmcsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgZS5nLiBiZWNh dXNlIGl0IGJlY29tZXMgbW9yZSBhcHByb3ByaWF0ZSB0byBzcGxpdCBhIHNpbmdsZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgZS5nLiBiZWNhdXNlIGl0IGJlY29tZXMg bW9yZSBhcHByb3ByaWF0ZSB0byBzcGxpdCBhIHNpbmdsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNDIi IC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgIGRvY3VtZW50IGludG8gdHdvIG9yIG1vcmUs IG9yIDxzcGFuIGNsYXNzPSJkZWxldGUiPmJlY2F1c2UgbmV3IGFzcGVjdHMgb2YgTVBMUy1UUCBu ZWVkPC9zcGFuPiB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgIGRv Y3VtZW50IGludG8gdHdvIG9yIG1vcmUsIG9yIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmlmIG5ldyBh c3BlY3RzIG9mIE1QTFMtVFAgbmVlZHM8L3NwYW4+IHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgYmUgc3BlY2lmaWVkLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgYmUgc3BlY2lmaWVkLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNC4gICBFdmVyeSB0aW1lIGEgZG9jdW1lbnQgaXMgYWNj ZXB0ZWQgYnkgdGhlIE1FQUQgdGVhbSBpbnRvIHRoZSBzZXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICA0LiAgIEV2ZXJ5IHRpbWUgYSBkb2N1bWVudCBpcyBhY2NlcHRlZCBieSB0 aGUgTUVBRCB0ZWFtIGludG8gdGhlIHNldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNDMiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgICAgIG9mIGRvY3VtZW50cyBjb29yZGluYXRlZCBieSB0aGUgTUVB RCA8c3BhbiBjbGFzcz0iZGVsZXRlIj50ZWFtLDwvc3Bhbj4gYSBsaWFpc29uIGlzIHNlbnQgdG88 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICBvZiBkb2N1bWVudHMgY29v cmRpbmF0ZWQgYnkgdGhlIE1FQUQgPHNwYW4gY2xhc3M9Imluc2VydCI+dGVhbTwvc3Bhbj4gYSBs aWFpc29uIGlzIHNlbnQgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgIHRoZSBJVFUtVCB3aXRoIGEgcG9pbnRlciB0byB0aGUg ZG9jdW1lbnQuICBBdCB0aGUgc2FtZSB0aW1lIDxzcGFuIGNsYXNzPSJkZWxldGUiPmE8L3NwYW4+ IG5vdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICB0aGUgSVRVLVQg d2l0aCBhIHBvaW50ZXIgdG8gdGhlIGRvY3VtZW50LiAgQXQgdGhlIHNhbWUgdGltZSBub3RlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICAgICBpcyBzZW50IHRvIHRoZSBNUExTLVRQIGFkIGhvYyB0ZWFtIG1haWxpbmcgbGlzdCBpbmZv cm1pbmcgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGhlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgIGlzIHNlbnQgdG8gdGhlIE1QTFMtVFAgYWQgaG9jIHRlYW0g bWFpbGluZyBsaXN0IGluZm9ybWluZyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICBy ZWNpcGllbnRzPC9zcGFuPiB0aGF0IHRoZSBkb2N1bWVudCBoYXMgYmVjb21lIGEgTUVBRCB0ZWFt IGRvY3VtZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgIHRoZSBk b2N1bWVudCBoYXMgYmVjb21lIGEgTUVBRCB0ZWFtIGRvY3VtZW50LjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICBUaGUgSVRVLVQgbWF5IGNob3NlIHRvIHJlc3BvbmQgdG8gdGhl IGxpYWlzb24gYnV0IGlzIG5vdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgVGhlIElUVS1UIG1heSBjaG9zZSB0byByZXNwb25kIHRvIHRoZSBsaWFpc29uIGJ1dCBpcyBu b3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICByZXF1aXJlZCB0byBkbyBzbywgc2VlIFNlY3Rpb24gMyBhbmQgU2VjdGlvbiA0Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgcmVxdWlyZWQgdG8gZG8gc28s IHNlZSBTZWN0aW9uIDMgYW5kIFNlY3Rpb24gNC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIDUuICAgQXQgYW55IHRpbWUgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBJVFUtVCBTR3MgYW5k IFF1ZXN0aW9ucyB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDUuICAgQXQg YW55IHRpbWUgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBJVFUtVCBTR3MgYW5kIFF1ZXN0aW9ucyB0 bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgIHNlbmQgcmV2aWV3IGNvbW1lbnRzIG9uIE1FQUQgdGVhbSBkb2N1bWVudHMuICBJdCBp cyBhbHNvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBzZW5kIHJldmll dyBjb21tZW50cyBvbiBNRUFEIHRlYW0gZG9jdW1lbnRzLiAgSXQgaXMgYWxzbzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFt ZT0iZGlmZjAwNDQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgIHBvc3NpYmxlIGZvciB0 aGUgTUVBRCB0ZWFtIHRvIGFzayBmb3Igc3VjaCByZXZpZXdzIGFuZCA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5jb21tZW50czwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgICBwb3NzaWJsZSBmb3IgdGhlIE1FQUQgdGVhbSB0byBhc2sgZm9yIHN1Y2ggcmV2aWV3cyBh bmQgPHNwYW4gY2xhc3M9Imluc2VydCI+Y29tbWVudHMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgICAgICAgZXhwbGljaXRseS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBBbnkgdGltZSBzdWNo IGFuIGlucHV0IG9yIHJlcXVlc3RzIGFyZSBzZW50IGJldHdlZW4gdGhlIHR3bzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgQW55IHRpbWUgc3VjaCBhbiBpbnB1dCBvciBy ZXF1ZXN0cyBhcmUgc2VudCBiZXR3ZWVuIHRoZSB0d288L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBvcmdhbml6YXRpb25zIGl0IFNI QUxMIGJlIGFjY29tcGFuaWVkIGJ5IGEgbm90ZSBmcm9tIHRoZSBNUExTLVRQPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBvcmdhbml6YXRpb25zIGl0IFNIQUxMIGJlIGFj Y29tcGFuaWVkIGJ5IGEgbm90ZSBmcm9tIHRoZSBNUExTLVRQPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgYWQgaG9jIHRlYW0gY2hh aXIocykgdG8gdGhlIE1FQUQgdGVhbSBtYWlsaW5nIGxpc3QsIG9yIGZyb20gdGhlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBhZCBob2MgdGVhbSBjaGFpcihzKSB0byB0 aGUgTUVBRCB0ZWFtIG1haWxpbmcgbGlzdCwgb3IgZnJvbSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBNRUFEIHRlYW0gY2hh aXIgdG8gdGhlIE1QTFMtVFAgYWQgaG9jIHRlYW0gbWFpbGluZyBsaXN0LiAgVGhpczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgTUVBRCB0ZWFtIGNoYWlyIHRvIHRoZSBN UExTLVRQIGFkIGhvYyB0ZWFtIG1haWxpbmcgbGlzdC4gIFRoaXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBpcyBkb25lIHRvIGVu aGFuY2UgdGhlIGVmZmljaWVuY3kgb2YgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgaXMgZG9uZSB0byBlbmhhbmNlIHRoZSBl ZmZpY2llbmN5IG9mIHRoZSBpbmZvcm1hdGlvbiBleGNoYW5nZS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIDYuICAgQSB3b3JraW5nIGdyb3VwIG9yIHRoZSBNRUFEIHRlYW0gbWF5IGlz c3VlIHJlcXVlc3RzIGZvciBnZW5lcmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgNi4gICBBIHdvcmtpbmcgZ3JvdXAgb3IgdGhlIE1FQUQgdGVhbSBtYXkgaXNzdWUgcmVxdWVz dHMgZm9yIGdlbmVyYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICBjb21tZW50cyBvbiBNUExTLVRQIGRvY3VtZW50cyBhdCBhbnkg dGltZSwgaWYgaXQgaXMgZGVlbWVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICBjb21tZW50cyBvbiBNUExTLVRQIGRvY3VtZW50cyBhdCBhbnkgdGltZSwgaWYgaXQgaXMg ZGVlbWVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICAgYXBwcm9wcmlhdGUgdG8gZXh0ZW5kIHRoZXNlIHJlcXVlc3RzIHRvIHRoZSBN UExTLVRQIGFkIGhvYyB0ZWFtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICBhcHByb3ByaWF0ZSB0byBleHRlbmQgdGhlc2UgcmVxdWVzdHMgdG8gdGhlIE1QTFMtVFAgYWQg aG9jIHRlYW08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICB0aGlzIGlzIGRvbmUgdmlhIGEgbm90ZSBhY2NvcmRpbmcgdG8gZW50cnkg KDUpIGluIHRoaXMgbGlzdC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg IHRoaXMgaXMgZG9uZSB2aWEgYSBub3RlIGFjY29yZGluZyB0byBlbnRyeSAoNSkgaW4gdGhpcyBs aXN0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNy4gICBJZiBhIE1QTFMtVFAgZG9j dW1lbnQgaXMgbWF0dXJlIGVub3VnaCB0byBiZWNvbWUgYSB3b3JraW5nIGdyb3VwPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNy4gICBJZiBhIE1QTFMtVFAgZG9jdW1lbnQgaXMg bWF0dXJlIGVub3VnaCB0byBiZWNvbWUgYSB3b3JraW5nIGdyb3VwPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgZG9jdW1lbnQgYSBw b2xsIGlzIGRvbmUgb24gdGhlIG1wbHMtdHAgbWFpbGluZyBsaXN0IGFuZCB0aGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIGRvY3VtZW50IGEgcG9sbCBpcyBkb25lIG9u IHRoZSBtcGxzLXRwIG1haWxpbmcgbGlzdCBhbmQgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA0NSIg Lz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgYXBwcm9wcmlhdGUgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+V0cgbWFpbGluZyBsaXN0LiBUPC9zcGFuPmhpcyByZXF1ZXN0IHdpbGwgYWxzbyBiZSBz ZW50IHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgYXBwcm9wcmlh dGUgPHNwYW4gY2xhc3M9Imluc2VydCI+d2cgbWFpbGluZyBsaXN0LCB0PC9zcGFuPmhpcyByZXF1 ZXN0IHdpbGwgYWxzbyBiZSBzZW50IHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgdGhlIElUVS1UIGFzIGEgbGlhaXNvbi4gIEEg bm90ZSB3aWxsIGFsc28gYmUgc2VudCB0byB0aGUgTVBMUy1UUDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgdGhlIElUVS1UIGFzIGEgbGlhaXNvbi4gIEEgbm90ZSB3aWxs IGFsc28gYmUgc2VudCB0byB0aGUgTVBMUy1UUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIGFkIGhvYyB0ZWFtLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgYWQgaG9jIHRlYW0uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgIFdoaWNoIHdvcmtpbmcgZ3JvdXAgYSBkb2N1bWVudCBnb2Vz IGludG8gaXMgZGVjaWRlZCBqb2ludGx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICBXaGljaCB3b3JraW5nIGdyb3VwIGEgZG9jdW1lbnQgZ29lcyBpbnRvIGlzIGRlY2lk ZWQgam9pbnRseTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNDYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICAgIGJldHdlZW4gdGhlIE1FQUQgdGVhbSwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGhlIDwv c3Bhbj53b3JraW5nIGdyb3VwIGNoYWlycyBvZiB0aGUgcG90ZW50aWFsPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgYmV0d2VlbiB0aGUgTUVBRCB0ZWFtLCB3b3JraW5n IGdyb3VwIGNoYWlycyBvZiB0aGUgcG90ZW50aWFsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgd29ya2luZyBncm91cHMgYW5kIHRo ZSBkb2N1bWVudCBlZGl0b3JzL2F1dGhvcnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICB3b3JraW5nIGdyb3VwcyBhbmQgdGhlIGRvY3VtZW50IGVkaXRvcnMvYXV0aG9y cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA0NyIg Lz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgSWYgdGhlIGRvY3VtZW50IGlzIGFjY2VwdGVk IGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudDxzcGFuIGNsYXNzPSJkZWxldGUiPiw8L3NwYW4+ IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgIElmIHRoZSBkb2N1 bWVudCBpcyBhY2NlcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgd29y a2luZyBncm91cCB0YWtlcyBvdmVyIHRoZSByZXZpc2lvbiBjb250cm9sIG9mIHRoZSBkb2N1bWVu dC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIHdvcmtpbmcgZ3JvdXAg dGFrZXMgb3ZlciB0aGUgcmV2aXNpb24gY29udHJvbCBvZiB0aGUgZG9jdW1lbnQuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIFRoZSBJVFUtVCBpcyBleHBlY3RlZCB0byByZXNw b25kIHRvIHRoZSBsaWFpc29uIHdpdGhpbiBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgIFRoZSBJVFUtVCBpcyBleHBlY3RlZCB0byByZXNwb25kIHRvIHRoZSBs aWFpc29uIHdpdGhpbiBpbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICB0aW1lIGluZGljYXRlZCBpbiB0aGUgbGlhaXNvbiwg c2VlIFNlY3Rpb24gMyBhbmQgU2VjdGlvbiA0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgdGltZSBpbmRpY2F0ZWQgaW4gdGhlIGxpYWlzb24sIHNlZSBTZWN0aW9uIDMg YW5kIFNlY3Rpb24gNC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDguICAgRXZlcnkg dGltZSBhIE1QTFMtVFAgZG9jdW1lbnQgaXMgYWNjZXB0ZWQgYXMgYSB3b3JraW5nIGdyb3VwPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgOC4gICBFdmVyeSB0aW1lIGEgTVBMUy1U UCBkb2N1bWVudCBpcyBhY2NlcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXA8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBkb2N1bWVudCBi eSBhbnkgSUVURiB3b3JraW5nIGdyb3VwIGEgbGlhaXNvbiBpcyBzZW50IHRvIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgZG9jdW1lbnQgYnkgYW55IElFVEYgd29y a2luZyBncm91cCBhIGxpYWlzb24gaXMgc2VudCB0byB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDQ4 IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICBJVFUtVCB3aXRoIGEgcG9pbnRlciB0byB0 aGUgZG9jdW1lbnQuICBBdCB0aGUgc2FtZSB0aW1lIDxzcGFuIGNsYXNzPSJkZWxldGUiPmEgPC9z cGFuPm5vdGUgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICBJVFUt VCB3aXRoIGEgcG9pbnRlciB0byB0aGUgZG9jdW1lbnQuICBBdCB0aGUgc2FtZSB0aW1lIG5vdGUg aXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICBzZW50IHRvIHRoZSBNUExTLVRQIGFkIGhvYyB0ZWFtIG1haWxpbmcgbGlzdCBpbmZv cm1pbmcgdGhhdCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIHNl bnQgdG8gdGhlIE1QTFMtVFAgYWQgaG9jIHRlYW0gbWFpbGluZyBsaXN0IGluZm9ybWluZyB0aGF0 IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgIGRvY3VtZW50IGhhcyBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgZG9jdW1lbnQgaGFzIGJlY29t ZSBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICA5LiAgIFdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIG1heSBiZSByZXZpZXdlZCBpbiBzZXZlcmFs IHN0ZXBzLCBldmVyeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDkuICAgV29y a2luZyBncm91cCBkb2N1bWVudHMgbWF5IGJlIHJldmlld2VkIGluIHNldmVyYWwgc3RlcHMsIGV2 ZXJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgdGltZSBzdWNoIGEgcmV2aWV3IGlzIGluaXRpYXRlZCB0aGUgTVBMUy1UUCBhZCBo b2MgdGVhbSBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgdGltZSBz dWNoIGEgcmV2aWV3IGlzIGluaXRpYXRlZCB0aGUgTVBMUy1UUCBhZCBob2MgdGVhbSBpczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg IG5vdGlmaWVkICgxMCkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBu b3RpZmllZCAoMTApLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDQ5IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICBOb3RlIHRoYXQgbW9zdCBy ZXZpZXdzIHRoYXQgbGVhZCB0byB1cGRhdGVzIG9mIHdvcmtpbmcgZ3JvdXA8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICBOb3RlIHRoYXQgbW9zdCByZXZpZXdzIHRoYXQg bGVhZDxzcGFuIGNsYXNzPSJpbnNlcnQiPnM8L3NwYW4+IHRvIHVwZGF0ZXMgb2Ygd29ya2luZyBn cm91cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgIGRvY3VtZW50cyBhcmUgc3BvbnRhbmVvdXMgaW5kaXZpZHVhbCBjb21tZW50cyBm cm9tIHBhcnRpY2lwYW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ZG9jdW1lbnRzIGFyZSBzcG9udGFuZW91cyBpbmRpdmlkdWFsIGNvbW1lbnRzIGZyb20gcGFydGlj aXBhbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICAgaW4gdGhlIE1QTFMtVFAgZWZmb3J0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgaW4gdGhlIE1QTFMtVFAgZWZmb3J0LjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgMTAuICBFdmVyeSB0aW1lIGEgcmV2aWV3IGlzIGluaXRpYXRlZCBieSBh IHdvcmtpbmcgZ3JvdXAgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMTAu ICBFdmVyeSB0aW1lIGEgcmV2aWV3IGlzIGluaXRpYXRlZCBieSBhIHdvcmtpbmcgZ3JvdXAgdGhl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgYXBwcm9wcmlhdGUgSVRVLVQgU0dzIGFuZCBRdWVzdGlvbnMgd2lsbCBiZSBub3RpZmll ZCBieSBhIG1haWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIGFwcHJv cHJpYXRlIElUVS1UIFNHcyBhbmQgUXVlc3Rpb25zIHdpbGwgYmUgbm90aWZpZWQgYnkgYSBtYWls PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgdG8gdGhlIE1QTFMtVFAgYWQgaG9jIHRlYW0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICB0byB0aGUgTVBMUy1UUCBhZCBob2MgdGVhbS48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA1MCIgLz48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgICAgICAgT3B0aW9uYWxseTxzcGFuIGNsYXNzPSJkZWxldGUiPiw8L3NwYW4+IHRo ZSByZXF1ZXN0IGZvciByZXZpZXcgbWF5IGJlIGFjY29tcGFuaWVkIGJ5IGE8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICBPcHRpb25hbGx5IHRoZSByZXF1ZXN0IGZvciBy ZXZpZXcgbWF5IGJlIGFjY29tcGFuaWVkIGJ5IGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBsaWFpc29uIHRvIGZvcm1hbGl6ZSB0 aGUgcmVxdWVzdC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIGxpYWlz b24gdG8gZm9ybWFsaXplIHRoZSByZXF1ZXN0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDUxIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICBU aGUgTVBMUy1UUCBhZCBob2MgdGVhbSBpcyByZXNwb25zaWJsZSBmb3IgZW5zdXJpbmcgdGhhdCA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5hbGw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgICAgVGhlIE1QTFMtVFAgYWQgaG9jIHRlYW0gaXMgcmVzcG9uc2libGUgZm9y IGVuc3VyaW5nIHRoYXQgPHNwYW4gY2xhc3M9Imluc2VydCI+YW55PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgICAgICAgRW1haWw8L3NwYW4+IHJlcXVlc3RzIGFyZSBjb3BpZWQvZm9yd2Fy ZGVkIHRoZSByZWxldmFudCBTR3MgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgZS1tYWlsPC9zcGFuPiByZXF1ZXN0cyBhcmUg Y29waWVkL2ZvcndhcmRlZCB0aGUgcmVsZXZhbnQgU0dzIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIFF1ZXN0aW9ucy48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIFF1ZXN0aW9ucy48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA1MiIgLz48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIDExLiAgV2hlbiBhIGRvY3VtZW50IGlzIGRlZW1lZCB0byA8c3BhbiBjbGFz cz0iZGVsZXRlIj5iZTwvc3Bhbj4gbWF0dXJlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmVub3VnaCw8 L3NwYW4+IGEgd29ya2luZyBncm91cCBsYXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIDExLiAgV2hlbiBhIGRvY3VtZW50IGlzIGRlZW1lZCB0byBtYXR1cmUgPHNwYW4gY2xh c3M9Imluc2VydCI+ZW5vdWdoPC9zcGFuPiBhIHdvcmtpbmcgZ3JvdXAgbGFzdDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgY2Fs bCBpcyBpbml0aWF0ZWQuICBBdCB0aGlzIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRpbWUsPC9zcGFu PiB0aGUgYWN0aW9uIDxzcGFuIGNsYXNzPSJkZWxldGUiPmRlc2NyaWJlZDwvc3Bhbj4gdW5kZXIg aXRlbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgIGNhbGwgaXMgaW5p dGlhdGVkLiAgQXQgdGhpcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aW1lPC9zcGFuPiB0aGUgYWN0 aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRlc2NyaWJlPC9zcGFuPiB1bmRlciBpdGVtPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg MTIgaW4gdGhpcyBsaXN0IE1VU1QgYmUgZXhlY3V0ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAxMiBpbiB0aGlzIGxpc3QgTVVTVCBiZSBleGVjdXRlZC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEyLiAgUHJvY2VkdXJlcyB0byBiZSBmb2xsb3dlZCB3 aGVuIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAxMi4gIFByb2NlZHVyZXMgdG8gYmUgZm9sbG93ZWQgd2hlbiBhIHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA1MyIgLz48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgICAgICAgaW5pdGlhdGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgIGluaXRpPHNwYW4gY2xhc3M9Imluc2VydCI+dDwvc3Bhbj5hdGVkLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAqICBBIGxpYWlzb24gY29udGFpbmluZyBhIHJl cXVlc3QgZm9yIHBhcnRpY2lwYXRpb24gaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAqICBBIGxpYWlzb24gY29udGFpbmluZyBhIHJlcXVlc3QgZm9yIHBhcnRp Y2lwYXRpb24gaW4gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgd29ya2luZyBncm91cCBsYXN0IGNhbGwgd2lsbCBiZSBz ZW50IHRvIHRoZSBhcHByb3ByaWF0ZSBJVFUtVDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgd29ya2luZyBncm91cCBsYXN0IGNhbGwgd2lsbCBiZSBzZW50IHRvIHRo ZSBhcHByb3ByaWF0ZSBJVFUtVDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNTQiIC8+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgICAgICAgIFNHIGFuZCBRdWVzdGlvbnM8c3BhbiBjbGFzcz0iZGVsZXRlIj4u PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgIFNHIGFu ZCBRdWVzdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJk aWZmMDA1NSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgKiAgQSBtYWlsIHdpdGggYSBu b3RpZmljYXRpb24gdGhhdCB0aGUgd29ya2luZyBncm91cCBsPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ YTwvc3Bhbj5zdCBjYWxsIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAgKiAgQSBtYWlsIHdpdGggYSBub3RpZmljYXRpb24gdGhhdCB0aGUgd29ya2luZyBncm91cCBs c3QgY2FsbCBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgIHRha2luZyBwbGFjZSB3aWxsIGJlIHNlbnQgdG8gdGhlIE1QTFMt VFAgYWQgaG9jIHRlYW0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICB0YWtpbmcgcGxhY2Ugd2lsbCBiZSBzZW50IHRvIHRoZSBNUExTLVRQIGFkIGhvYyB0ZWFtLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDU2IiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAqICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGU8L3Nw YW4+IElUVS1UIGlzIFJFUVVJUkVEIHRvIHJlc3BvbmQgdG8gdGhlIGxpYWlzb24gd2l0aGluIHRo ZSB0aW1lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgKiAgSVRVLVQg aXMgUkVRVUlSRUQgdG8gcmVzcG9uZCB0byB0aGUgbGlhaXNvbiB3aXRoaW4gdGhlIHRpbWU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPmZyYW1lPC9zcGFuPiBpbmRpY2F0ZWQuICBUaGUg TVBMUy1UUCBhZCBob2MgdGVhbSBpcyBleHBlY3RlZCB0byB2ZXJpZnk8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICBpbmRpY2F0ZWQuICBUaGUgTVBMUy1UUCBhZCBo b2MgdGVhbSBpcyBleHBlY3RlZCB0byB2ZXJpZnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgIHRoYXQgYWxsIHRoZSBTR3Mg YW5kIFF1ZXN0aW9ucyB3aXRoIHRoZSBJVFUtVCB0aGF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPm5l ZWQ8L3NwYW4+IHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAg dGhhdCBhbGwgdGhlIFNHcyBhbmQgUXVlc3Rpb25zIHdpdGggdGhlIElUVS1UIHRoYXQgPHNwYW4g Y2xhc3M9Imluc2VydCI+bmVlZHM8L3NwYW4+IHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgcmVzcG9uZCB0byB0aGUgd29y a2luZyBncm91cCBsYXN0IGNhbGwgYXJlIGF3YXJlIHRoYXQgaXQgaGFzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICByZXNwb25kIHRvIHRoZSB3b3JraW5nIGdyb3Vw IGxhc3QgY2FsbCBhcmUgYXdhcmUgdGhhdCBpdCBoYXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICBiZWVuIGlzc3VlZC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgIGJlZW4gaXNzdWVkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDU3IiAvPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgMTMuICBXaGVuIGFsbCBsYXN0IGNhbGwgY29tbWVudHMgYXJlIGFk ZHJlc3NlZCBhbmQgcmVzcG9uZGVkIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRvLDwvc3Bhbj4gdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDEzLiAgV2hlbiBhbGwgbGFzdCBj YWxsIGNvbW1lbnRzIGFyZSBhZGRyZXNzZWQgYW5kIHJlc3BvbmRlZCB0aGU8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgIGRvY3Vt ZW50IHdpbGwgYmUgc2VudCB0byB0aGUgSVRVLVQgYXNraW5nIGlmIHRoZSBkb2N1bWVudDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgIGRvY3VtZW50IHdpbGwgYmUgc2Vu dCB0byB0aGUgSVRVLVQgPHNwYW4gY2xhc3M9Imluc2VydCI+d2l0aCBhPC9zcGFuPiBhc2tpbmcg aWYgdGhlIGRvY3VtZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5pczwvc3Bhbj4gcmVh ZHkgdG8gYmUgc2VudCB0byB0aGUgSUVTRyB3aXRoIGEgcmVxdWVzdCBmb3I8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hcmU8L3Nw YW4+IHJlYWR5IHRvIGJlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmJlPC9zcGFuPiBzZW50IHRvIHRo ZSBJRVNHIHdpdGggYSByZXF1ZXN0IGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgcHVibGljYXRpb24uIDxzcGFuIGNsYXNz PSJkZWxldGUiPlRoZSBJVFUtVCBjYW4gZWl0aGVyIHNlbmQgYW4gYWNrbm93bGVkZ21lbnQ8L3Nw YW4+IHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICBwdWJsaWNh dGlvbi4gPHNwYW4gY2xhc3M9Imluc2VydCI+cHVibGlzaGVkLmZvciBhIGFja25vd2xlZG1lbnQ8 L3NwYW4+IHRoYXQgdGhlIGRvY3VtZW50IGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICB0aGUgZG9jdW1lbnQgaXMgcmVhZHkg dG8gb3IgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aXQgY2FuIGV4cHJlc3MgdGhhdCB0aGVyZTwvc3Bh bj4gaXMgZnVydGhlciB3b3JrPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAgcmVhZHkgdG8gb3IgPHNwYW4gY2xhc3M9Imluc2VydCI+dGh0IHRocmU8L3NwYW4+IGlzIGZ1 cnRoZXIgd29yayB0aGF0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPm5lZXM8L3NwYW4+IHRvIGJlIGRv bmUuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICB0aGF0IDxzcGFuIGNsYXNz PSJkZWxldGUiPm5lZWRzPC9zcGFuPiB0byBiZSBkb25lLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgIHJlcXVlc3QgZm9yIHB1Ymxp Y2F0aW9uIHdpbGwgYmUgc2VudCB0byB0aGUgSUVTRy4gIFRoZSBkb2N1bWVudDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg ICBhZnRlciB0aGlzIHBvaW50IGluIHRpbWUgaGFuZGxlZCBhcyBhbnkgb3RoZXIgSUVURiBkb2N1 bWVudC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIE5vdGU6IFdH IGxhc3QgY2FsbCBtYXkgYmUgcmUtaXRlcmF0ZWQsIGZvciB0aGUgZW50aXJlIGRvY3VtZW50PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBOb3RlOiBXRyBsYXN0IGNhbGwg bWF5IGJlIHJlLWl0ZXJhdGVkLCBmb3IgdGhlIGVudGlyZSBkb2N1bWVudDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIG9yIGxpbWl0 ZWQgdG8gb25seSB2ZXJpZnkgdGhlIHVwZGF0ZXMgbWFkZSBiZWNhdXNlIG9mIGFuIGVhcmxpZXI8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIG9yIGxpbWl0ZWQgdG8gb25s eSB2ZXJpZnkgdGhlIHVwZGF0ZXMgbWFkZSBiZWNhdXNlIG9mIGFuIGVhcmxpZXI8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgMTQuICBUaGUgSVRVLVQgaGFzIG9uZSB3ZWVrIHRvIHJlc3BvbmQgeWVzIG9yIG5vIHRvIHRo ZSBxdWVzdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDE0LiAgVGhlIElU VS1UIGhhcyBvbmUgd2VlayB0byByZXNwb25kIHllcyBvciBubyB0byB0aGUgcXVlc3Rpb248L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICBwb3NlZCBpbiAoMTMpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg cG9zZWQgaW4gKDEzKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgVGhlIGFu c3dlciBjYW4gYmUgZWl0aGVyICJ5ZXMgLSBnbyBhaGVhZCIsIGluIHdoaWNoIGNhc2UgdGhlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBUaGUgYW5zd2VyIGNhbiBiZSBl aXRoZXIgInllcyAtIGdvIGFoZWFkIiwgaW4gd2hpY2ggY2FzZSB0aGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBXb3JraW5nIEdy b3VwIHdpbGwgcmVxdWVzdCBwdWJsaWNhdGlvbjsgb3IgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICBXb3JraW5nIEdyb3VwIHdpbGwgcmVxdWVzdCBwdWJsaWNhdGlv bjsgb3IgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIC4uLiBpdCBjYW4g YmUgIm5vIC0gbW9yZSB3b3JrIGlzIG5lZWRlZCIsIGluIHdoaWNoIGNhc2UgaXQgd2lsbDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgLi4uIGl0IGNhbiBiZSAibm8gLSBt b3JlIHdvcmsgaXMgbmVlZGVkIiwgaW4gd2hpY2ggY2FzZSBpdCB3aWxsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgZ28gYmFjayBp bnRvIHRoZSBub3JtYWwgd29ya2luZyBncm91cCBwcm9jZXNzIHRvIGlkZW50aWZ5IHdoYXQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIGdvIGJhY2sgaW50byB0aGUgbm9y bWFsIHdvcmtpbmcgZ3JvdXAgcHJvY2VzcyB0byBpZGVudGlmeSB3aGF0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgaXMgbmVlZGVk LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgaXMgbmVlZGVkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTUuICBXaGVuIHRoZSBJVFUtVCBnaXZlcyB0aGUg ZmluYWwgYWNrbm93bGVkZ2VtZW50IGEgcmVxdWVzdCBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAxNS4gIFdoZW4gdGhlIElUVS1UIGdpdmVzIHRoZSBmaW5hbCBhY2tub3ds ZWRnZW1lbnQgYSByZXF1ZXN0IGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNTgiIC8+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPnB1YmxpY2F0aW9uPC9zcGFu PiB3aWxsIGJlIHNlbnQgdG8gdGhlIElFU0cuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5BdDwvc3Bh bj4gdGhpcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zdGFnZSwgdGhlPC9zcGFuPiBJVFUtVDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQi PnBpYmxpY2F0aW9uPC9zcGFuPiB3aWxsIGJlIHNlbnQgdG8gdGhlIElFU0cuICA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5PbmNlPC9zcGFuPiB0aGlzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnJlcXVlc3Qg Zm9yPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aGFzIG5vIG1vcmU8L3NwYW4+ IGluZmx1ZW5jZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5vbjwvc3Bhbj4gdGhlIGRldmVsb3BtZW50 IDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZSBkb2N1bWVudC48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgcHVibGljYXRp b24gaXMgc2VudCB0byBsYXN0IHBvaW50IGluIHRoaXMgcHJvY2VzcyB3aGVyZSBpdCBpczwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgIEZyb208L3NwYW4+IHRoaXMgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+cG9pbnQgb248L3NwYW4+IHRoZSBkb2N1bWVudCB3aWxsIGJlIGhhbmRsZWQg YXMgYW55IG90aGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICAgICAgYWRvcHRlZCB0byBhbGxvdzwvc3Bhbj4gSVRVLVQgaW5mbHVlbmNl IHRoZSBkZXZlbG9wbWVudCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5vZiBhIGRvY3VtZW50PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgICAgIGlzIHBhYXNlZC4gIEFmdGVyPC9zcGFuPiB0aGlzIHRoZSBkb2N1bWVudCB3aWxsIGJl IGhhbmRsZWQgYXMgYW55IG90aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgSUVURiBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgIElFVEYgZG9jdW1lbnQuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4zLiAgRXhwZWN0YXRpb25zIG9uIElUVS1UIHBhcnRpY2lwYXRpb24gaW4gdGhl IHByb2Nlc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLiAgRXhwZWN0YXRpb25z IG9uIElUVS1UIHBhcnRpY2lwYXRpb24gaW4gdGhlIHByb2Nlc3M8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFRoZSBJRVRGIGFuZCBJVFUtVCBwcm9jZXNzZXMgZm9yIHRoZSBkZXZlbG9w bWVudCBvZiB0aGUgTVBMUy1UUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRo ZSBJRVRGIGFuZCBJVFUtVCBwcm9jZXNzZXMgZm9yIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgTVBM Uy1UUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNTkiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzdGFu ZGFyZHMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aW50ZXJzZWN0PC9zcGFuPiBhdCB0aGUgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+cG9pbnRzPC9zcGFuPiAoNCksICg1KSwgKDdhKSwgKDgpLCA8c3BhbiBj bGFzcz0iZGVsZXRlIj4oMTApLCAoMTIpLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgc3RhbmRhcmRzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmludGVyY29ubmVjdDwv c3Bhbj4gYXQgdGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmZvbGxvd2luZyBwb2ludCBpbiB0aGUg ZmxvdyBjaGFydCBhYm92ZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAoMTMpPC9zcGFu PiBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+KDE0KSBpbiB0aGUgZmxvdyBjaGFydCBhYm92ZS48 L3NwYW4+ICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGluIHNob3J0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICg0KSwgKDUpLCAoN2EpLCAoOCksIDxzcGFuIGNsYXNzPSJpbnNl cnQiPigxMCk8L3NwYW4+IGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4oMTIpLjwvc3Bhbj4gIFRo aXMgc2VjdGlvbiBkZXNjcmliZXMgaW4gc2hvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2hhdCBpcyBleHBlY3RlZCB0byBoYXBwZW4g b24gdGhlIElUVS1UIHNpZGUgYXQgdGhlIGludGVyYWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgd2hhdCBpcyBleHBlY3RlZCB0byBoYXBwZW4gb24gdGhlIElUVS1UIHNp ZGUgYXQgdGhlIGludGVyYWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBvaW50cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBwb2ludHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4zLjEuICBCZWNvbWlu ZyBhIE1FQUQgdGVhbSBkb2N1bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMu MS4gIEJlY29taW5nIGEgTUVBRCB0ZWFtIGRvY3VtZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAoNCkgaXMgYSBwb2ludCB3aGVyZSB0aGUgTUVBRCB0ZWFtIGNvbW11bmljYXRlcyB0 byB0aGUgSVRVLVQgdGhhdCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKDQp IGlzIGEgcG9pbnQgd2hlcmUgdGhlIE1FQUQgdGVhbSBjb21tdW5pY2F0ZXMgdG8gdGhlIElUVS1U IHRoYXQgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBkb2N1bWVudCBpcyBjb25zaWRlcmVkIHRvIGJlIGFjY2VwdGVkIHRvIGJlIGNvb3Jk aW5hdGVkIGJ5IHRoZSBNRUFEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9j dW1lbnQgaXMgY29uc2lkZXJlZCB0byBiZSBhY2NlcHRlZCB0byBiZSBjb29yZGluYXRlZCBieSB0 aGUgTUVBRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB0ZWFtLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRlYW0uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNjAiIC8+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgSVRVLVQgaXMgZXhwZWN0ZWQgdG8gcmVzcG9uZCB3aXRo IGEgc2ltcGxlIEFDSyBvciBOQUssIGhvd2V2ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgVGhlIElUVS1UIGlzIGV4cGVjdGVkIHRvIHJlc3BvbmQgPHNwYW4gY2xhc3M9Imlu c2VydCI+dG8gdGhlIGNvbW11bmljYXRpb248L3NwYW4+IHdpdGggYSBzaW1wbGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhIG5vbi1y ZXNwb25zZSBpcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5pbXBsaWNpdGx5PC9zcGFuPiBjb3VudGVk IGFzIGFuIEFDSy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQUNLIG9yIE5B SywgaG93ZXZlciBhIG5vbi1yZXNwb25zZSBpcyBjb3VudGVkIGFzIGFuIEFDSy48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA2MSIgLz48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIEFuIEFDSyBtZWFucyB0aGF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZTwv c3Bhbj4gSVRVLVQgYWNjZXB0cyB0aGF0IHRoZSBkb2N1bWVudHMgaGFzIGJlY29tZSBhIE1FQUQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQW4gQUNLIG1lYW5zIHRoYXQgSVRV LVQgYWNjZXB0cyB0aGF0IHRoZSBkb2N1bWVudHMgaGFzIGJlY29tZSBhIE1FQUQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0ZWFtIGRv Y3VtZW50LCBhIE5BSyBtZWFucyB0aGF0IElUVS1UIGhhcyBpc3N1ZXMgdGhhdCA8c3BhbiBjbGFz cz0iZGVsZXRlIj5uZWVkPC9zcGFuPiB0byBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICB0ZWFtIGRvY3VtZW50LCBhIE5BSyBtZWFucyB0aGF0IElUVS1UIGhhcyBpc3N1ZXMg dGhhdCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5uZWVkczwvc3Bhbj4gdG8gYmU8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVzb2x2ZWQgYmVm b3JlIHRoZSBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHJlc29sdmVkIGJlZm9yZSB0aGUgZG9jdW1lbnQgaXMgYWxsb3dl ZCB0byBwcm9ncmVzcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuMi4gIENvbW1lbnRz IG9uIE1FQUQgdGVhbSBkb2N1bWVudHMgYnkgcGFydGljaXBhbnRzIGluIHRoZSBJVFUtVDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuMi4gIENvbW1lbnRzIG9uIE1FQUQgdGVhbSBk b2N1bWVudHMgYnkgcGFydGljaXBhbnRzIGluIHRoZSBJVFUtVDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDYyIiAvPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgKDUpIGFuZCAoMTApIG9mZmVycyBwb3NzaWJpbGl0aWVzIGZvciA8c3BhbiBjbGFzcz0iZGVs ZXRlIj50aGUgPC9zcGFuPklUVS1UIG9yIHBlb3BsZSBhY3RpdmUgaW4gdGhlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICg1KSBhbmQgKDEwKSBvZmZlcnMgcG9zc2liaWxpdGll cyBmb3IgSVRVLVQgb3IgcGVvcGxlIGFjdGl2ZSBpbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSVRVLVQgdG8gc2VuZCB1bi10cmln Z2VyZWQgY29tbWVudHMgb24gTUVBRCB0ZWFtIG9yIHdvcmtpbmcgZ3JvdXA8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJVFUtVCB0byBzZW5kIHVuLXRyaWdnZXJlZCBjb21tZW50 cyBvbiBNRUFEIHRlYW0gb3Igd29ya2luZyBncm91cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudHMuICBTdWNoIGNvbW1lbnRz IHNoYWxsIGJlIHNlbnQgdG8gdGhlIG1wbHMtdHAgbGlzdCBhbmQgZm9yPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnRzLiAgU3VjaCBjb21tZW50cyBzaGFsbCBiZSBz ZW50IHRvIHRoZSBtcGxzLXRwIGxpc3QgYW5kIGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3JraW5nIGdyb3VwIGRvY3VtZW50cyBh bHNvIHRvIHRoZSBhcHByb3ByaWF0ZSB3b3JraW5nIGdyb3VwIG1haWxpbmc8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGdyb3VwIGRvY3VtZW50cyBhbHNvIHRvIHRo ZSBhcHByb3ByaWF0ZSB3b3JraW5nIGdyb3VwIG1haWxpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDYz IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbGlzdC4gIENvbW1lbnRzIHJlY2VpdmVkIGluIHRo aXMgd2F5IHdpbGwgYmUgdHJlYXRlZCB0aGUgc2FtZSB3YXk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgbGlzdC4gIENvbW1lbnRzIHJlY2VpdmVkIGluIHRoaXMgd2F5IHdpbGwg YmUgdHJlYXRlZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hczwvc3Bhbj4gdGhlIHNhbWUgd2F5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+YXM8L3NwYW4+IGFueSBvdGhlciBpbmRpdmlkdWFsIGNvbW1l bnRzIHJlY2VpdmVkIG9uIHRoZSBJRVRGIGRvY3VtZW50cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgYW55IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmFzPC9zcGFuPiBvdGhlciBp bmRpdmlkdWFsIGNvbW1lbnRzIHJlY2VpdmVkIG9uIHRoZSBJRVRGIGRvY3VtZW50cy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuMy4gIFBvbGwgZm9yIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+My4zLiAgUG9sbCBmb3Igd29ya2lu ZyBncm91cCBkb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICg3YSkgaXMg dGhlIHBvaW50IHdoZXJlIGFuIElFVEYgd29ya2luZyBncm91cCBpbmZvcm1zIHRoZSBJVFUtVCB0 aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKDdhKSBpcyB0aGUgcG9pbnQg d2hlcmUgYW4gSUVURiB3b3JraW5nIGdyb3VwIGluZm9ybXMgdGhlIElUVS1UIHRoYXQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYSBwb2xs IHRvIHByb2dyZXNzIGEgZG9jdW1lbnQgdG8gYW4gSUVURiB3b3JraW5nIGdyb3VwIGRvY3VtZW50 IGhhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGEgcG9sbCB0byBwcm9ncmVz cyBhIGRvY3VtZW50IHRvIGFuIElFVEYgd29ya2luZyBncm91cCBkb2N1bWVudCBoYXM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmVlbiBz dGFydGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJlZW4gc3RhcnRlZC48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEl0IGlzIG5vdCBuZWNlc3Nhcnkgb3IgcmVx dWlyZWQgZm9yIHRoZSBJVFUtVCB0byByZXNwb25kIHRvIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBJdCBpcyBub3QgbmVjZXNzYXJ5IG9yIHJlcXVpcmVkIGZvciB0aGUg SVRVLVQgdG8gcmVzcG9uZCB0byB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1lc3NhZ2UuICBJZiB0aGUgSVRVLVQgaGFzIHNlcmlv dXMgY29uY2VybnMgdGhlc2Ugc2hvdWxkIGJlIHByb3ZpZGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgbWVzc2FnZS4gIElmIHRoZSBJVFUtVCBoYXMgc2VyaW91cyBjb25jZXJu cyB0aGVzZSBzaG91bGQgYmUgcHJvdmlkZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdmlhIGEgbGlhaXNvbiBzdGF0ZW1lbnQuICBJZiB0 aGUgSVRVLVQgaGFzIG5vIHNlcmlvdXMgY29uY2VybnMgaXQgaXM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB2aWEgYSBsaWFpc29uIHN0YXRlbWVudC4gIElmIHRoZSBJVFUtVCBo YXMgbm8gc2VyaW91cyBjb25jZXJucyBpdCBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90 ZD48dGg+PGEgbmFtZT0icGFydC1sNCIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9z bWFsbD48ZW0+IHBhZ2UgMTMsIGxpbmUgMTc8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1l PSJwYXJ0LXI0IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFn ZSAxMywgbGluZSAxNzwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgaXQgYWRk cmVzc2VzIGEgcHJvYmxlbSB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIG8gIGl0IGFkZHJlc3NlcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0 byBiZSBzb2x2ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIGl0IGlzIGEgZ29v ZCBlbm91Z2ggc3RhcnQgdG8gc29sdmUgdGhpcyBwcm9ibGVtPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgbyAgaXQgaXMgYSBnb29kIGVub3VnaCBzdGFydCB0byBzb2x2ZSB0aGlz IHByb2JsZW08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJlc3BvbnNlcyB0byBwb2xs cyBmb3IgY2hlY2tpbmcgaWYgYSBkb2N1bWVudCBpcyByZWFkeSB0byBiZWNvbWUgYTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJlc3BvbnNlcyB0byBwb2xscyBmb3IgY2hlY2tp bmcgaWYgYSBkb2N1bWVudCBpcyByZWFkeSB0byBiZWNvbWUgYTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50IHNob3VsZCBiZSBsaW1pdGVkIHRvIGFuc3dlciBpZiB0aGUgZG9jdW1lbnQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHNob3VsZCBi ZSBsaW1pdGVkIHRvIGFuc3dlciBpZiB0aGUgZG9jdW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWVldHMgdGhvc2UgdGhyZWUgY3Jp dGVyaWEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWVldHMgdGhvc2UgdGhy ZWUgY3JpdGVyaWEuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4zLjQuICBSZXNwb25kaW5n IHRvIGFuIElFVEYgV29ya2luZyBHcm91cCBMYXN0IENhbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4zLjQuICBSZXNwb25kaW5nIHRvIGFuIElFVEYgV29ya2luZyBHcm91cCBMYXN0 IENhbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDA2 NCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICgxMikgaXMgdGhlIHBvaW50IGluIHRoZSBwcm9j ZXNzIHdoZXJlIElUVS1UIGlzIG1hZGUgYXdhcmUgb2YgdGg8c3BhbiBjbGFzcz0iZGVsZXRlIj5l IGZhY3QgdGg8L3NwYW4+YXQgYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg KDEyKSBpcyB0aGUgcG9pbnQgaW4gdGhlIHByb2Nlc3Mgd2hlcmUgSVRVLVQgaXMgbWFkZSBhd2Fy ZSBvZiB0aGF0IGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIElFVEYgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gc3RhcnRl ZC4gIFRoZSB3b3JraW5nIGdyb3VwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg SUVURiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiBzdGFydGVkLiAgVGhlIHdvcmtp bmcgZ3JvdXA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgbGFzdCBjYWxsIGlzIGlzc3VlZCB3aGVuIGEgd29ya2luZyBncm91cCBkb2N1bWVu dCBpcyBnZXR0aW5nIGNsb3NlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg bGFzdCBjYWxsIGlzIGlzc3VlZCB3aGVuIGEgd29ya2luZyBncm91cCBkb2N1bWVudCBpcyBnZXR0 aW5nIGNsb3NlIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGJlIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gIFRoZSBpbnRlbnRpb24gaXMg dG8gbWFrZSBzdXJlIHRoYXQgdGhlcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBiZSByZWFkeSBmb3IgcHVibGljYXRpb24uICBUaGUgaW50ZW50aW9uIGlzIHRvIG1ha2Ugc3Vy ZSB0aGF0IHRoZXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGFyZSBubyBpbXBvcnRhbnQgcGllY2VzIG1pc3NpbmcgYW5kIHRoYXQgdGVj aG5pY2FsIGRldGFpbHMgYXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXJl IG5vIGltcG9ydGFudCBwaWVjZXMgbWlzc2luZyBhbmQgdGhhdCB0ZWNobmljYWwgZGV0YWlscyBh cmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgY29ycmVjdC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb3JyZWN0Ljwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDY1IiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgQWNjb3JkaW5nIHRvIHRoZSBKV1QgZGVjaXNpb248c3BhbiBj bGFzcz0iZGVsZXRlIj4sIHRoZTwvc3Bhbj4gSVRVLVQgaXMgcmVxdWlyZWQgdG8gcmVzcG9uZCB0 byBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEFjY29yZGluZyB0byB0aGUg SldUIGRlY2lzaW9uIElUVS1UIGlzIHJlcXVpcmVkIHRvIHJlc3BvbmQgdG8gYTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCB3aXRoaW4gdGhlIHRpbWUgc2V0IGZvciB0aGUgd29ya2luZyBncm91cDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IHdpdGhpbiB0aGUgdGltZSBzZXQgZm9yIHRoZSB3b3JraW5nIGdyb3VwPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxhc3QuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbGFzdC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFRoZSBjaGFpciBvZiBhbiBJRVRGIHdvcmtpbmcgZ3JvdXAgdGhhdCBzdGFydHMgYSB3 b3JraW5nIGdyb3VwIGxhc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUg Y2hhaXIgb2YgYW4gSUVURiB3b3JraW5nIGdyb3VwIHRoYXQgc3RhcnRzIGEgd29ya2luZyBncm91 cCBsYXN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGNhbGwgd2lsbCBzZW5kIGEgbGlhaXNvbiB0byB0aGUgSVRVLVQgYW5ub3VuY2luZyB0 aGUgd29ya2luZyBncm91cDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNhbGwg d2lsbCBzZW5kIGEgbGlhaXNvbiB0byB0aGUgSVRVLVQgYW5ub3VuY2luZyB0aGUgd29ya2luZyBn cm91cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBsYXN0IGNhbGwuICBBIG1lc3NhZ2Ugd2lsbCBhbHNvIGJlIHNlbnQgdG8gdGhlIE1QTFMt VFAgYWQgaG9jIHRlYW0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbGFzdCBj YWxsLiAgQSBtZXNzYWdlIHdpbGwgYWxzbyBiZSBzZW50IHRvIHRoZSBNUExTLVRQIGFkIGhvYyB0 ZWFtLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwNjYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUg SUVURiB3aWxsIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRyeTwvc3Bhbj4gdG8gPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ZW5zdXJlIHRoYXQgYWxsPC9zcGFuPiBTR3MgYW5kIFF1ZXN0aW9ucyB0aGF0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoZSBJRVRGIHdpbGwgPHNwYW4gY2xh c3M9Imluc2VydCI+bWFrZSBhIGJlc3QgZWZmb3J0PC9zcGFuPiB0byA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij50YXJnZXQgdGhlPC9zcGFuPiBTR3MgYW5kIFF1ZXN0aW9ucyB0aGF0PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2hvdWxkIGJl IGludm9sdmVkIGluIHJlc3BvbmRpbmcgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCA8c3BhbiBj bGFzcz0iZGVsZXRlIj5jYWxsIGFyZSBhZGRyZXNzZWQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBzaG91bGQgYmUgaW52b2x2ZWQgaW4gcmVzcG9uZGluZyB0byB0 aGUgd29ya2luZyBncm91cCBsYXN0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNhbGwuPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IEhvd2V2ZXIsIDxzcGFuIGNsYXNzPSJkZWxldGUiPnVsdGltYXRlbHk8L3NwYW4+IHRoZSBJVFUt VCBoYXMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGFwcHJvcHJpYXRlIGVudGl0aWVzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEhvd2V2ZXIsIHRoZSBJVFUtVCBoYXMgdG8gbWFr ZSBzdXJlIHRoYXQgdGhlIGFwcHJvcHJpYXRlIGVudGl0aWVzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdpdGhpbiB0aGUgSVRVLVQgcGFy dGljaXBhdGUgaW4gcmVzcG9uZGluZyB0byB0aGUgd29ya2luZyBncm91cCBsYXN0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2l0aGluIHRoZSBJVFUtVCBwYXJ0aWNpcGF0ZSBp biByZXNwb25kaW5nIHRvIHRoZSB3b3JraW5nIGdyb3VwIGxhc3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FsbC4gIFRoZSBJVFUtVCBN UExTLVRQIGFkIGhvYyB0ZWFtIGNvb3JkaW5hdGVzIHRoZSBkZXZlbG9wbWVudCBvZjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNhbGwuICBUaGUgSVRVLVQgTVBMUy1UUCBhZCBo b2MgdGVhbSBjb29yZGluYXRlcyB0aGUgZGV2ZWxvcG1lbnQgb2Y8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIElUVS1UIHJlc3BvbnNl IHRvIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0aGUgSVRVLVQgcmVzcG9uc2UgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4gIFNwZWNpZmljIGd1aWRlbGluZXMg dGhhdCBhcHBseSB0byB3b3JrIG9uIE1QTFMtVFAgaW4gdGhlIElUVS1UPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+NC4gIFNwZWNpZmljIGd1aWRlbGluZXMgdGhhdCBhcHBseSB0byB3 b3JrIG9uIE1QTFMtVFAgaW4gdGhlIElUVS1UPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBUaGVzZSBndWlkZWxpbmVzIGFwcGx5IHRvIHByb2dyZXNzaW5nIHdvcmsgb24gTVBMUy1UUCBp biB0aGUgSVRVLVQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlc2UgZ3Vp ZGVsaW5lcyBhcHBseSB0byBwcm9ncmVzc2luZyB3b3JrIG9uIE1QTFMtVFAgaW4gdGhlIElUVS1U LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgQW55IG1lbWJlciBvZiB0aGUgSVRV LVQgbWF5IHNlbmQgYSBNUExTLVRQIGNvbnRyaWJ1dGlvbiB0byBhIElUVS1UPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgQW55IG1lbWJlciBvZiB0aGUgSVRVLVQgbWF5IHNl bmQgYSBNUExTLVRQIGNvbnRyaWJ1dGlvbiB0byBhIElUVS1UPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFN0dWR5IEdyb3VwIG9yIFF1 ZXN0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFN0dWR5IEdyb3Vw IG9yIFF1ZXN0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgYmdjb2xvcj0iZ3Jh eSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5hbWU9ImVuZCI+Jm5ic3A7RW5k IG9mIGNoYW5nZXMuIDY2IGNoYW5nZSBibG9ja3MuJm5ic3A7PC9hPjwvdGg+PC90cj4KICAgICA8 dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+MTE5IGxpbmVzIGNoYW5nZWQgb3IgZGVs ZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwvdGg+PHRoPjxpPjEyMCBsaW5lcyBjaGFuZ2VkIG9y IGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFs aWduPSJjZW50ZXIiIGNsYXNzPSJzbWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVj ZWQgYnkgcmZjZGlmZiAxLjM1LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20g PGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyIgPmh0dHA6 Ly90b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3RhYmxl PgogICA8L2JvZHk+CiAgIDwvaHRtbD4K ------_=_NextPart_001_01C9C72B.59891A4C-- From neil.2.harrison@bt.com Mon Apr 27 04:44:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222F53A68E1 for ; Mon, 27 Apr 2009 04:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[AWL=-3.022, BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auS1ZC2rjhyB for ; Mon, 27 Apr 2009 04:44:30 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 3AA533A68CC for ; Mon, 27 Apr 2009 04:44:28 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 12:45:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C72D.B4DE7D38" Date: Mon, 27 Apr 2009 12:45:47 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0479D833@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAAvBCIA== From: To: , X-OriginalArrivalTime: 27 Apr 2009 11:45:48.0270 (UTC) FILETIME=[B51B70E0:01C9C72D] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:44:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C72D.B4DE7D38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 V2hhdCBhIGdvb2QgYW5hbHlzaXMgQW5keS4gIFRoaXMgb24gaXRzIG93biBzaG91bGQgYmUgY29t cGVsbGluZyBlbm91Z2ggdG8gbWFrZSBpdCBjbGVhciB0aGF0IHdlIGNhbid0IHNpbXBseSB0YWtl IEZESS9BSVMgZnJvbSBpdHMgUERIL1NESCBjby1jcyBURE0gb3JpZ2lucyBhbmQgYmxpbmRseSBh cHBseSBpdCB0byBwYWNrZXQtc3dpdGNoZWQgbmV0d29ya3MuICBCdXQgZm9yIGFueW9uZSBzdGls bCBub3QgY29udmluY2VkIGhlcmUgYXJlIHNvbWUgZnVydGhlciByZWFzb25zIHdoeSBBSVMgKGFu ZCBUQ00pIG1ha2Ugbm8gc2Vuc2UuDQogDQpJZiBvbmUgd2FudHMgdG8gaW5qZWN0IGFuIEFJUyBz aWduYWwgaW50byBhIGNsaWVudCBmcm9tIGEgc2VydmVyIG9uZSAqbXVzdCogaGF2ZSBhIHBlcm1h bmVudCBiaW5kaW5nIG9mIHNlcnZlcl9wYXRoPD0+Y2xpZW50X2xpbmtfY29ubmVjdGlvbi4gIElm IHlvdSBkb24ndCBoYXZlIHRoaXMgdGhlbiB0aGVyZSBpcyBubyBvbmUgdG8gc2VuZCB0aGUgQUlT IHRvISAgU28sIGluIGFueSBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IGxheWVyIG5ldHdvcmsgY2Fu IGR5bmFtaWNhbGx5IGNoYW5nZSBpdHMgcm91dGluZyAoaWUgdG8gc2VsZWN0IGRpZmZlcmVudCBz ZXJ2ZXJzIGZvciBlYWNoIG9mIGl0cyBsaW5rIGNvbm5lY3Rpb25zKSB0aGVuIGl0IGlzIGEgcG9p bnRsZXNzIGV4ZXJjaXNlIGF0dGVtcHRpbmcgdG8gc2VuZCBBSVMgdG8gdGhlIGNsaWVudC4uLmFz IHRoZSBjbGllbnQgaGFzICdtb3ZlZCBzb21ld2hlcmUgZWxzZScuDQogDQpDbC1wcyBuZXR3b3Jr cyBsaWtlIElQIGFyZSBvYnZpb3VzbHkgbGlrZSB0aGlzLCBhbmQgaW4gdGhlIGxpbWl0IHRoZSBj bGllbnQ8PT5zZXJ2ZXIgYmluZGluZyBjYW4gY2hhbmdlIGZvciBlYWNoIHBhY2tldCBvZiB0aGUg SVAgY2xpZW50LCBpZSBuZXcgSUdQIHJvdXRlLiAgVGhlIGNvLWNzIFBTVE4gaXMgYWxzbyBsaWtl IHRoaXMgYmVjYXVzZSBpdCBpcyBiYXNlZCBvbiBTVkNzLiAgQW5kIGhlcmUgaWYgb25lIGdldHMg YSBzZXJ2ZXIgbGF5ZXIgZmFpbHVyZSB0aGUgY2xpZW50IGNhbGxzIGdldCBjbGVhcmVkIGRvd24g YW5kIHJlLWVzdGFibGlzaGVkIHZpYSBvdGhlciBzZXJ2ZXJzIHRoYW4gdGhlIG9uZSB0aGF0IGhh cyBmYWlsZWQuICBTbyB3aG8gaXMgdGhlIGJyb2tlbiBzZXJ2ZXIgZ29pbmcgdG8gc2VuZCBBSVMg dG8gbm93Pw0KIA0KTW92aW5nIG9uIHRvIGNvbnNpZGVyIFRDTSwgd2hhdCB0aGlzIGlzIGRvaW5n IGlzIGNyZWF0aW5nIGFuIGFydGlmaWNpYWwgY2xpZW50L3NlcnZlciBzdWJsYXllciBoaWVyYXJj aHkuICBBbmQgYXMgbm90ZWQgYWJvdmUsIGZvciBhIGxvd2VyIFRDTSBsZXZlbCB0byBtZWFuaW5n ZnVsbHkgaW5qZWN0IEFJUyB0b3dhcmRzIGEgaGlnaGVyIFRDTSBsZXZlbCB0aGUgVENNIGNsaWVu dC9zZXJ2ZXIgYmluZGluZ3MgbXVzdCBiZSBwZXJtYW5lbnQuICBCdXQgdGhpcyBpcyByYXRoZXIg c2lsbHkgYmVjYXVzZSBpdCBpcyAqbm90KiB0aGUgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFRD TSBsZXZlbHMgdGhhdCBpdCBrZXkgYnV0IHRoZSAqcmVhbCB0cmFmZmljIHJlbGF0aW9uc2hpcHMg YmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyKi4uLi4uaW4gb3RoZXIgd29yZHMgd2Ug Km11c3QqIGJlIGFibGUgdG8gcmUtcm91dGUgcmVhbCBjbGllbnQgdHJhZmZpYyBhcm91bmQgc2Vy dmVyIGxheWVyIGZhaWx1cmVzIChhbmQgdGhpcyBpbmNsdWRlcyBkeW5hbWljIHJlc3RvcmF0aW9u LCBub3Qgc2ltcGx5IHByZS1jb25maWd1cmVkIHByb3RlY3Rpb24gcGF0aHMpLiAgDQogDQpOb3Rl IHRoYXQgdGhlIG9ubHkgd2F5IG9uZSBjb3VsZCBrZWVwIHRoZSBleGlzdGluZyBUQ00gaGllcmFy Y2h5IHZhbGlkIGFjcm9zcyBmYWlsdXJlcyByZWxhdGl2ZSB0byB0aGUgY2xpZW50IHRyYWZmaWMg cm91dGluZyB3b3VsZCBiZSB0byBjcmVhdGUgcGluY2gtcG9pbnRzIGF0IHRoZSBUQ00gbGV2ZWxz IGFuZCBmb3JjZSB0aGUgY2xpZW50IHRyYWZmaWMgdG8gYWx3YXlzIHVzZSB0aGVzZS4gIEJ1dCBu b3cgb2YgY291cnNlIG9uZSB3b3VsZCBiZSByZWR1Y2luZyB0aGUgYXZhaWxhYmlsaXR5IHBvdGVu dGlhbCBvZiB0aGUgbmV0d29yay4uLnNvIHRoaXMgaXMgbm90IGEgc21hcnQgaWRlYSBhdCBhbGwu DQogDQpUaGUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gbW92ZSB0aGUgVENNIGxldmVscyBpbiBh Y2NvcmRhbmNlIHRvIHdoZXJlIHRoZSByZWFsIHRyYWZmaWMgaGFkIG1vdmVkIHRvIHRvIGVmZmVj dCByZXN0b3JhdGlvbi4gIFNvIHRoZSBkeW5hbWljIGFjdC9kZWFjdCBjb25maWd1cmF0aW9uIG9m IFRDTSBsZXZlbHMgd291bGQgaGF2ZSB0byBiZSBkZWZpbmVkIHRvIHRyYWNrIHJlYWwgdHJhZmZp YyBtb3ZlbWVudHMgKGFuZCBpdCBuZXZlciBoYXMgYmVlbiBkZWZpbmVkKS4gIE5vdGUgYWxzbyB0 aGF0IGluIGNoYW5naW5nIHRoZSBsb2NhdGlvbiBvZiB0aGUgbmVzdGVkIFRDTSBsZXZlbHMgd2Ug aGF2ZSByZW1vdmVkIHRoZWlyIHJlcXVpcmVtZW50IGZvciBhIHBlcm1hbmVudCBjbGllbnQvc2Vy dmVyIGJpbmRpbmcgYW5kIHNvIHRoZSBzZW5kaW5nIG9mIEFJUyBmcm9tIGxvd2VyIHRvIGhpZ2hl ciBUQ00gbGV2ZWxzIHdvdWxkIGJlIHBvaW50bGVzcy4uLi5hcyB0aGV5IHRvbyBoYXZlIG1vdmVk IGF3YXkgZnJvbSB0aGUgc2VydmVyIGxheWVyIGZhaWx1cmUganVzdCBsaWtlIHdlIG5lZWQgdGhl IHJlYWwgdHJhZmZpYyB0byBkbyBzbyAoaWYgbm90IGNsZWFyIHdoYXQgSSBtZWFuIGhlcmUgcmVm ZXIgYmFjayB0byB0aGUgUFNUTiBleGFtcGxlIGFib3ZlLi4uaXRzIHRoZSBzYW1lIGlzc3VlKS4N CiANClNvIGluIGFkZGl0aW9uIHRvIEFuZHkncyBvYnNlcnZhdGlvbnMgb2Ygd2h5IGl0IGlzIG5v dCBzZW5zaWJsZSBzaW1wbHkgdG8gcmVwbGljYXRlIFBESC9TREggQUlTIGJlaGF2aW91ciBpbiBw YWNrZXQtc3dpdGNoZWQgbmV0d29ya3Mgd2UgY2FuIGFsc28gc2VlIGZyb20gdGhlIGFib3ZlIGFy Z3VtZW50cyB0aGF0IHRyeWluZyB0byBzZW5kIEFJUyBiZXR3ZWVuIGFuIGFydGlmaWNpYWwgc2V0 IG9mIG5lc3RlZCBUQ00gbGV2ZWxzIGlzIGFsc28gcG9pbnRsZXNzLi4uLmFuZCB0aGlzIGFwcGxp ZXMgdG8gYW55IG5ldHdvcmsgbW9kZSB3aGVyZSB0aGUgY2xpZW50IHRyYWZmaWMgY2FuIG1vdmUg aXRzIHJvdXRpbmcgYW5kIHRodXMgZG9lcyBub3QgaGF2ZSBhIHBlcm1hbmVudCBjbGllbnQ8PT5z ZXJ2ZXIgYmluZGluZyByZWxhdGlvbnNoaXAuDQogDQpyZWdhcmRzLCBOZWlsDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGFuZHku YmQucmVpZEBidC5jb20NCglTZW50OiAyNyBBcHJpbCAyMDA5IDExOjUwDQoJVG86IG1hYXJ0ZW4u dmlzc2Vyc0BodWF3ZWkuY29tDQoJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCglTdWJqZWN0OiBSZTog W21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJl bWVudHMNCgkNCgkNCglNYWFydGVuLA0KCSANCglJdCBpcyBvZiBjb3Vyc2UgdHJ1ZSB0aGF0IGFk ZGluZyBhIGJvb2xlYW4gaW5wdXQgdG8gYSBsb2dpY2FsIHN5c3RlbSBpbmNyZWFzZXMgdGhlIG51 bWJlciBvZiBwb3NzaWJsZSBpbnB1dCBzdGF0ZXMuIFNvIGFkZGluZyBhbiBBSVMgYm9vbGVhbiB0 byBDQyBib29sZWFuIGNyZWF0ZXMgZm91ciBwb3NzaWJsZSBzdGF0ZXMgbm90IGp1c3QgdGhlIHRo cmVlIHlvdSBpZGVudGlmeSBiZWxvdy4gVGhlcmUgYXJlIA0KCSANCgktIGdvb2QgQ0MsIG5vIEFJ Uw0KCQ0KCS0gQ0MgZmF1bHQsIEFJUyBwcmVzZW50DQoJLSBnb29kIENDLCBBSVMgcHJlc2VudA0K CS0gQ0MgZmF1bHQsIG5vIEFJUw0KCSANCglXZSBtdXN0IGFzayB3aGF0IHByYWN0aWNhbCBzY2Vu YXJpb3MgY291bGQgZ2VuZXJhdGUgZWFjaCBvZiB0aGVzZSBpbnB1dCBzdGF0ZXMuDQoJIA0KCUdv b2QgQ0MsIG5vIEFJUw0KCU9uZSBob3BlcyB0aGlzIGlzIGJlY2F1c2UgdGhpcyBpcyBiZWNhdXNl IHRoZSBzZXJ2aWNlIGlzIHdvcmtpbmcgcHJvcGVybHkuDQoJIA0KCUNDIGZhdWx0LCBBSVMgcHJl c2VudA0KCU9uZSBob3BlcyB0aGlzIGlzIGJlY2F1c2UgdGhlIHNlcnZpY2UgaXMgZmF1bHR5IGFu ZCBvbmUgaG9wZXMgdGhpcyBpcyBiZWNhdXNlIG9mIGEgZmF1bHQgaW4gYSBzZXJ2ZXIgbGF5ZXIu IEluIGZhY3QsIHRoZSBwcmVzZW5jZSBvZiB0aGUgQUlTIGNvdWxkIGJlIG1pc2xlYWRpbmcgKHNl ZSBiZWxvdykuDQoJIA0KCUdvb2QgQ0MsIEFJUyBwcmVzZW50DQoJVGhpcyBzaXR1YXRpb24gY291 bGQgYXJpc2UgYmVjYXVzZSBvZiBhIG1pc2NvbmZpZ3VyYXRpb24gb2YgdGhlIEFJUyBmb3J3YXJk aW5nIGxhYmVsIGluamVjdGlvbiB0YWJsZS4gQW5kIHRoZXJlIGFyZSBhIG51bWJlciBvZiBzY2Vu YXJpb3Mgd2hpY2ggbWFrZSB0aGlzIHF1aXRlIGxpa2VseSB3aGVuIHByb3RlY3Rpb24gc3dpdGNo aW5nIG9jY3Vycy4gRGVwZW5kaW5nIG9uIHRoZSBleGFjdCBzY29wZSBvZiB0aGUgZm9yd2FyZGlu ZyBsYWJlbHMsIGEgcHJvdGVjdGlvbiBzd2l0Y2ggbWF5IHdlbGwgcmVxdWlyZSB0aGUgcHJvYWN0 aXZlIHB1cmdpbmcgb2YgZW50cmllcyBmcm9tIHRoZSBBSVMgZm9yd2FyZGluZyBsYWJlbCBpbmpl Y3Rpb24gdGFibGUgZm9sbG93aW5nIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCAodGhpcyBjb3VsZCBl cXVpdmFsZW50bHkgYmVlbiBzZWVuIGFzIHRoZSBmb3J3YXJkaW5nIGZ1bmN0aW9uIHByb2FjdGl2 ZWx5IGRyb3BwaW5nIHRoZSBBSVMgcGFja2V0cykuDQoJIA0KCUNDIGZhdWx0LCBubyBBSVMNCglB cyB5b3Ugc3VnZ2VzdCwgdGhpcyBjb3VsZCBhcmlzZSBmcm9tIGEgbWlzY29uZmlndXJhdGlvbiBv ZiBhIGZvcndhcmRpbmcgZnVuY3Rpb24uIEJ1dCBpdCBjb3VsZCBlcXVhbGx5IGFyaXNlIGZyb20g YSBtaXNjb25maWd1cmF0aW9uIG9mIHRoZSBBSVMgZm9yd2FyZGluZyBsYWJlbCBpbmplY3Rpb24g dGFibGUuIEluIGZhY3QsIHRoZSBsYXR0ZXIgYWN0dWFsbHkgc2VlbXMganVzdCBhcyBsaWtlbHkg YW5kIHBhcnRpY3VsYXJseSBwcm9ibGVtYXRpYyBmb3IgbWFpbnRlbmFuY2UuIFVubGlrZSBub3Jt YWwgZm9yd2FyZGluZywgYW55IG1pc21hdGNoIGJldHdlZW4gdGhlIGZvcndhcmRpbmcgY29uZmln dXJhdGlvbiBhbmQgdGhlIEFJUyBmb3J3YXJkaW5nIGxhYmVsIGluamVjdGlvbiB0YWJsZSB3aWxs IGxpZSBkb3JtYW50IGFuZCB1bnRpbCBhIHNlcnZlciBmYXVsdCBhcmlzZXMuIFRoZW4gdGhpcyBn ZW5lcmF0ZXMgYSBmYWxzZSBhbmQgbWlzdW5kZXJzdG9vZCBmYXVsdCBjb25kaXRpb24gd2l0aCBt YWludGVuYW5jZSBsb29raW5nIGZvciB0aGUgZmF1bHQgaW4gdGhlIHdyb25nIHBsYWNlLg0KCSAN CglUaGUgZmlyc3QgdHdvIHN0YXRlcyBjYW4gYmUgcmVsaWFibHkgZGlhZ25vc2VkIHdpdGggQ0Mg YWxvbmUuIFRoZSBzZWNvbmQgdHdvIGFyaXNlIGZyb20gdGhlIGludHJvZHVjdGlvbiBvZiB0aGUg QUlTL0ZESS4gSG93ZXZlciwgYW55IHBvc3NpYmxlIGJlbmVmaXQgdGhhdCBtaWdodCBhcmlzZSBp cyBjb21wbGV0ZWx5IG1hc2tlZCBieSB0aGUgZmFjdCB0aGF0IHRoZSBBSVMgaXRzZWxmIG11c3Qg YmUgY29uZmlndXJlZCBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIGZvciB0aGlzIHRvIGJlIG1vcmUg cmVsaWFibGUgdGhhbiB3aGF0IGl0IGlzIHN1cHBvc2VkIHRvIGJlIG1vbml0b3JpbmcuIEluZGVl ZCwgdGhlcmUgc2VlbXMgZ29vZCByZWFzb24gdG8gdGhpbmsgdGhhdCBpdCB3aWxsIGJlIGxlc3Mg cmVsaWFibGUuDQoJIA0KCVRoZXJlIGlzIG5vIGF2b2lkaW5nIHRoYXQgQUlTIGluIGNpcmN1aXQg c3dpdGNoaW5nIGlzIGZ1bmRhbWVudGFsbHkgZGlmZmVyZW50IGZyb20gQUlTIGluIHBhY2tldCBz d2l0Y2hpbmcuDQoJIC0gaW4gY2lyY3VpdCBzd2l0Y2hpbmcsIHlvdSBtdXN0IGZpbGwgdGhlIGJp dCBzdHJlYW0gd2l0aCBzb21ldGhpbmcgYW5kIHRoZSBpbmZvcm1hdGlvbiBpbmplY3RlZCByZXF1 aXJlcyBubyBjb25maWd1cmF0aW9uIHdoYXRzb2V2ZXIuDQoJIC0gaW4gcGFja2V0IHN3aXRjaGlu Zywgbm8gcGFja2V0cyBpcyBhIHBlcmZlY3RseSB2YWxpZCBjb25kaXRpb24gYW5kIHRoZSBpbmpl Y3Rpb24gb2YgQUlTIHJlcXVpcmVzIGluZGl2aWR1YWwgY2xpZW50IGNvbm5lY3Rpb24gc3BlY2lm aWMgaW5mb3JtYXRpb24gdG8gYmUgY29uZmlndXJlZC4NCgkgDQoJVGhlIG9iamVjdGl2ZSBpcyBu b3QgdG8gcmVwbGljYXRlIHRoZSBkYXRhIHBsYW5lIHByaW1pdGl2ZXMgb2YgU09ORVQvU0RILCBi dXQgdGhlIHRyaWdnZXJzIHRvIHRoZSBvcGVyYXRpb25hbCBzeXN0ZW1zIHNvIHRoYXQgdGhlIG9w ZXJhdGlvbmFsIHN5c3RlbXMgYW5kIHByb2Nlc3NlcyBhcmUgdGhlIHNhbWUuDQoJIA0KCVRoZSBz aW1wbGUgQ0MgcmVwbGljYXRlcyBhbGwgdGhlIHRyaWdnZXJzIHRvIG1hbmFnZW1lbnQgc3lzdGVt cyBtYWRlIGJ5IFNPTkVUL1NESCBhbmQgZ2l2ZXMgbWF4aW11bSBjb21wYXRpYmlsaXR5LiBDb252 ZXJzZWx5LCB0aGUgaW5jbHVzaW9uIG9mIGRhdGEgcGxhbmUgQUlTIHJlcXVpcmVzIGEgd2hvbGUg bmV3IGFyZWEgb2YgY29uZmlndXJhdGlvbiBhbmQgZ2VuZXJhdGVzIGEgd2hvbGUgbmV3IHNldCBv ZiBmYXVsdCBjb25kaXRpb25zIHdoaWNoIGNhbm5vdCBiZSBsb2NhbGlzZWQgYnkgU09ORVQvU0RI IHByb2Nlc3Nlcy4gU28sIGlyb25pY2FsbHksIHBhY2tldCBBSVMgaXMgZGlyZWN0bHkgb3Bwb3Nl ZCB0byBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSB5b3UgY2xhaW0gaXMgdGhlIG1haW4gZHJpdmUu DQoJIA0KCUFuZHkNCgkgDQoJIA0KCSANCgkgDQoNCglBbmR5IFJlaWQgDQoJQ2hpZWYgTmV0d29y ayBTZXJ2aWNlcyBTdHJhdGVnaXN0IA0KCUJUIElubm92YXRlIA0KCSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCglPZmZpY2U6ICs0NCAoMCkxMjc3IDMyMjAzOCANCglNb2JpbGU6 ICs0NCAoMCk3OTE3IDAyNTQ1MSANCglGYXggOiAgICAgICArNDQgKDApMTI3NyAzMjQwMTUgDQoJ RW1haWw6ICBhbmR5LmJkLnJlaWRAYnQuY29tIA0KDQoJDQoJQnJpdGlzaCBUZWxlY29tbXVuaWNh dGlvbnMgcGxjDQoJUmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBF QzFBIDdBSg0KCVJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBuby4gMTgwMDAwMCANCglUaGlzIGVsZWN0 cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIEJyaXRpc2ggVGVsZWNvbW11 bmljYXRpb25zIHBsYyB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRo ZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB1cyBieSB0ZWxlcGhvbmUgb3IgZW1haWwgKHRvIHRoZSBudW1i ZXJzIG9yIGFkZHJlc3MgYWJvdmUpIGltbWVkaWF0ZWx5Lg0KDQoJQWN0aXZpdHkgYW5kIHVzZSBv ZiB0aGUgQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjIGVtYWlsIHN5c3RlbSBpcyBtb25p dG9yZWQgdG8gc2VjdXJlIGl0cyBlZmZlY3RpdmUgb3BlcmF0aW9uIGFuZCBmb3Igb3RoZXIgbGF3 ZnVsIGJ1c2luZXNzIHB1cnBvc2VzLiBDb21tdW5pY2F0aW9ucyB1c2luZyB0aGlzIHN5c3RlbSB3 aWxsIGFsc28gYmUgbW9uaXRvcmVkIGFuZCBtYXkgYmUgcmVjb3JkZWQgdG8gc2VjdXJlIGVmZmVj dGl2ZSBvcGVyYXRpb24gYW5kIGZvciBvdGhlciBsYXdmdWwgYnVzaW5lc3MgcHVycG9zZXMuDQoN CgkgDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCQlGcm9tOiBNYWFy dGVuIFZpc3NlcnMgW21haWx0bzptYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbV0gDQoJCVNlbnQ6 IDI0IEFwcmlsIDIwMDkgMTk6MTUNCgkJVG86IFJlaWQsQUJELEFuZHksQ1hNIFINCgkJQ2M6IG1w bHMtdHBAaWV0Zi5vcmcNCgkJU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoJCQ0KCQkNCgkJQW5keSwNCgkJ IA0KCQlBSVMvRkRJIGRvZXMgZ2l2ZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLiBMZXQgbWUgZXhw bGFpbjoNCgkJIA0KCQlUaGUgbmVlZCBmb3IgQUlTL0ZESSBpcyBhIGNvbnNlcXVlbmNlIG9mIHRo ZSBkZXBsb3ltZW50IG9mIGxvc3Mgb2YgY29udGludWl0eSBjaGVja2luZyBPQU0gKGUuZy4gQ0NN IGluIGV0aGVybmV0LCBDQyBpbiBBVE0pLiBUaGUgb2JqZWN0aXZlIG9mIHN1Y2ggQ0NNIE9BTSBp cyB0byBiZSBhYmxlIHRvIGRldGVjdCBhIG1pc2NvbmZpZ3VyYXRpb24gb3IgZmF1bHQgb2YgYSBj b25uZWN0aW9uIGZ1bmN0aW9uIChmYWJyaWMpIGluIHRoZSBjb25uZWN0aW9uLCB3aGljaCBpbnRl cnJ1cHRzIHRoZSBmb3J3YXJkaW5nIG9mIHRyYWZmaWMgaW4gdGhlIGNvbm5lY3Rpb24uIFRoaXMg aXMgYSBmYXVsdCBjb25kaXRpb24gdGhhdCBjYW4gb25seSBiZSBkaXNjb3ZlcmVkIGJ5IHRoZSBs YXllciBuZXR3b3JrIGluIHdoaWNoIHRoZSBjb25uZWN0aW9uIGlzIHN1cHBvcnRlZC4gSXQgcmVx dWlyZXMgdGhhdCB0aGUgb3JnYW5pemF0aW9uIHJlc3BvbnNpYmxlIGZvciB0aGUgbGF5ZXIgbmV0 d29yayB0YWtlcyBhY3Rpb24gKGkuZS4gbG9jYXRlIHRoZSBsYXllcidzIGNvbm5lY3Rpb24gZnVu Y3Rpb24gdGhhdCBpbmNsdWRlcyB0aGUgZmF1bHQpIHRvIHJlc3RvcmUgdGhlIGNvbm5lY3Rpb24u DQoJCSANCgkJVW5mb3J0dW5hdGVseSwgYW4gaW50ZXJydXB0aW9uIG9mIG9uZSBvZiB0aGUgbGlu ayBjb25uZWN0aW9ucyBvZiBzdWNoIGNvbm5lY3Rpb24gKGR1ZSB0byBhIGZhdWx0IGluIGEgc2Vy dmVyIGxheWVyKSB3aWxsIGFsc28gaW50ZXJydXB0IHRoZSBmb3J3YXJkaW5nIG9mIHRyYWZmaWMg aW4gdGhlIGNvbm5lY3Rpb24uDQoJCSANCgkJQXMgc3VjaCwgbG9zcyBvZiBDQyBtZXNzYWdlcyAo TE9DIGRlZmVjdCkgZG9lcyBub3QgcHJvdmlkZSBzdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIGRl dGVybWluZSBpZiB0aGUgY29uZmlndXJhdGlvbiBpbiB0aGUgbGF5ZXIncyBjb25uZWN0aW9uIGZ1 bmN0aW9ucyBhbG9uZyB0aGUgY29ubmVjdGlvbiBoYXZlIHRvIGJlIGNoZWNrZWQgYW5kIGNvcnJl Y3RlZC4NCgkJIA0KCQlBSVMgaGFzIGJlZW4gaW50cm9kdWNlZCBhbmQgaXMgdXNlZCB0byBoZWxw IGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGUgdHdvIGZhdWx0IGNhc2VzLg0KCQkxKSBpZiBMT0Mg YW5kIEFJUyBhcmUgZGV0ZWN0ZWQsIHRoZW4gdGhlcmUgaXMgYSBzZXJ2ZXIgbGF5ZXIgZmF1bHQu IFRoaXMgc2VydmVyIGxheWVyIGZhdWx0IGlzIGFscmVhZHkgcmVwb3J0ZWQgYnkgdGhlIHNlcnZl ciBsYXllciBNRVAgZGV0ZWN0aW5nIHRoaXMgZmF1bHQuIE5vIGFjdGlvbiBpcyByZXF1aXJlZCwg c28gbm8gYWxhcm0gdG8gZ2VuZXJhdGUuIA0KCQkyKSBpZiBMT0MgaXMgZGV0ZWN0ZWQgYW5kIHRo ZXJlIGlzIG5vIEFJUywgdGhlbiB0aGVyZSBpcyBhIGxheWVyIG5ldHdvcmsgZmF1bHQgKGkuZS4g Y29udGludWl0eSBmYXVsdCkuIEZhdWx0IGxvY2FsaXphdGlvbiBtdXN0IGJlIHN0YXJ0ZWQgdG8g bG9jYXRlIHRoZSBtaXNjb25maWd1cmVkIG9yIGZhaWxlZCBjb25uZWN0aW9uIGZ1bmN0aW9uLiBP bmNlIHRoaXMgZmF1bHR5IGNvbm5lY3Rpb24gZnVuY3Rpb24gaXMgbG9jYXRlZCwgdGhlIGNvbmZp Z3VyYXRpb24gZmF1bHQgKG9yIGhhcmR3YXJlIGZhdWx0KSBjYW4gYmUgY29ycmVjdGVkLCBhZnRl ciB3aGljaCB0aGUgY29ubmVjdGlvbiBpcyByZXRvcmVkLg0KCQkgDQoJCVRoZSBpbnRlcnJ1cHRp b24gb2YgdGhlIGZvcndhcmRpbmcgb2YgdHJhZmZpYyBpbiB0aGUgY29ubmVjdGlvbiBpbiBib3Ro IGZhdWx0IGNhc2VzIGlzIGhvd2V2ZXIgcmVnaXN0ZXJlZCBhcyBwYXJ0IG9mIHBlcmZvcm1hbmNl IG1vbml0b3JpbmcuIFRoaXMgcGVyZm9ybWFuY2UgbW9uaXRvcmluZyBpbmZvcm1hdGlvbiBpcyB1 c2VkIHRvIHZlcmlmeSB0aGUgcGVyZm9ybWFuY2UgYWdhaW5zdCB0aGUgU0xBIGZvciB0aGUgY29u bmVjdGlvbi4NCgkJIA0KCQlSZWdhcmRzLA0KCQlNYWFydGVuDQoJCQ0KCQkNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCgkJRnJvbTogYW5keS5iZC5yZWlkQGJ0LmNvbSBbbWFp bHRvOmFuZHkuYmQucmVpZEBidC5jb21dIA0KCQlTZW50OiB2cmlqZGFnIDI0IGFwcmlsIDIwMDkg MTI6MzQNCgkJVG86IG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tDQoJCUNjOiBtcGxzLXRwQGll dGYub3JnDQoJCVN1YmplY3Q6IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KCQkNCgkJDQoJCU1hYXJ0ZW4sDQoJCSANCgkJ VGhlc2UgcG9pbnRzIGFyZSBpcnJlbGV2YW50IHRvIHRoZSBwb2ludHMgSSBtYWRlLiBNeSBwb2lu dCBpcyB0aGF0IEFJUy9GREkgZ2l2ZXMgbm8gaW5mb3JtYXRpb24gYWJvdmUgd2hhdCBpcyBhbHJl YWR5IGtub3duIC0gaXQgaXMgb25seSBhZGRzIGNvbXBsZXhpdHkgYW5kIGZhdWx0IGxpYWJpbGl0 eS4gTmVpdGhlciBvZiB5b3VyIHBvaW50cyBjaGFuZ2UgdGhpcy4NCgkJIA0KCQlBbmR5DQoJCSAN CgkJIA0KDQoJCUFuZHkgUmVpZCANCgkJQ2hpZWYgTmV0d29yayBTZXJ2aWNlcyBTdHJhdGVnaXN0 IA0KCQlCVCBJbm5vdmF0ZSANCgkJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K CQlPZmZpY2U6ICs0NCAoMCkxMjc3IDMyMjAzOCANCgkJTW9iaWxlOiArNDQgKDApNzkxNyAwMjU0 NTEgDQoJCUZheCA6ICAgICAgICs0NCAoMCkxMjc3IDMyNDAxNSANCgkJRW1haWw6ICBhbmR5LmJk LnJlaWRAYnQuY29tIA0KDQoJCQ0KCQlCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNCgkJ UmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSg0KCQlS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm8uIDE4MDAwMDAgDQoJCVRoaXMgZWxlY3Ryb25pYyBtZXNz YWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIGZyb20gQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMg cGxjIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0 aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG9y IGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3Ig dXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHVzIGJ5IHRlbGVwaG9uZSBvciBlbWFpbCAodG8gdGhlIG51bWJlcnMgb3IgYWRk cmVzcyBhYm92ZSkgaW1tZWRpYXRlbHkuDQoNCgkJQWN0aXZpdHkgYW5kIHVzZSBvZiB0aGUgQnJp dGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjIGVtYWlsIHN5c3RlbSBpcyBtb25pdG9yZWQgdG8g c2VjdXJlIGl0cyBlZmZlY3RpdmUgb3BlcmF0aW9uIGFuZCBmb3Igb3RoZXIgbGF3ZnVsIGJ1c2lu ZXNzIHB1cnBvc2VzLiBDb21tdW5pY2F0aW9ucyB1c2luZyB0aGlzIHN5c3RlbSB3aWxsIGFsc28g YmUgbW9uaXRvcmVkIGFuZCBtYXkgYmUgcmVjb3JkZWQgdG8gc2VjdXJlIGVmZmVjdGl2ZSBvcGVy YXRpb24gYW5kIGZvciBvdGhlciBsYXdmdWwgYnVzaW5lc3MgcHVycG9zZXMuDQoNCgkJIA0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCgkJCUZyb206IE1hYXJ0ZW4gVmlz c2VycyBbbWFpbHRvOm1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXSANCgkJCVNlbnQ6IDIzIEFw cmlsIDIwMDkgMjA6NDINCgkJCVRvOiBSZWlkLEFCRCxBbmR5LENYTSBSDQoJCQlDYzogbXBscy10 cEBpZXRmLm9yZw0KCQkJU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoJCQkNCgkJCQ0KCQkJQW5keSwNCgkJ CSANCgkJCT4gVGhlIHByb2JsZW0gaXMgKm5vdCogYWJvdXQgYSBsYWNrIG9mIGFsYXJtIHN1cHBy ZXNzaW9uIGluIHRoZSBkYXRhIHBsYW5lIC0gdGhhdCBpbmZvcm1hdGlvbiBpcyByZWFkaWx5IGF2 YWlsYWJsZS4NCgkJCSANCgkJCUkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgYSBjb3JyZWN0 IHN0YXRlbWVudCBpbiBhIG11bHRpLW9wZXJhdG9yIHRyYW5zcG9ydCBuZXR3b3JrLCBvciBpbiB0 cmFuc3BvcnQgbmV0d29ya3Mgb2Ygb25lIG9wZXJhdG9yIHRoYXQgaGF2ZSBtb3JlIHRoZW4gb25l IGFkbWluaXN0cmF0aXZlIHN1YmRvbWFpbiAoZWFjaCB3aXRoIGl0cyBvd24gbmV0d29yayBtYW5h Z2VtZW50IHN5c3RlbSkuIEEgcHJvYmxlbSBvY2N1cmluZyBpbiBhZG1pbiBkb21haW4gQSB3aWxs IGJlIHVua25vd24gaW4gYWRtaW4gZG9tYWluIEIuIFRoZSBsb3NzIG9mIGNvbnRpbnVhaXR5IGFs YXJtcyB0aGF0IGFyZSBhY3RpdmF0ZWQgaW4gYWRtaW4gZG9tYWluIEIgZHVlIHRvIHRoZSBmYXVs dCBpbiBhZG1pbiBkb21haW4gQSB3aWxsIGFwcGVhciBhcyBwcmltYXJ5IGFsYXJtcywgc3VnZ2Vz dGluZyBjb25uZWN0aXZpdHkgcHJvYmxlbXMgaW4gYWRtaW4gZG9tYWluIEIuDQoJCQkgDQoJCQk+ IFRoZSBpc3N1ZSBhcmlzZXMgYmVjYXVzZSB0aGUgdHdvIHNpZGVzIG9mIG1haW50ZW5hbmNlIHdh bnQgZGlmZmVyZW50IHRoaW5ncy4gVGhlIGZhdWx0IGZpeGluZw0KCQkJPiBndXlzIHdhbnQgdG8g bG9jYXRlIHRoZSBmYXVsdCBhbmQgZG9uJ3Qgd2FudCBhbnkgb3RoZXIgaW5mb3JtYXRpb24uIFRo ZSBzZXJ2aWNlIG1haW50ZW5hbmNlDQoJCQk+IGd1eXMgd2FudCB0byBrbm93IHdoZXRoZXIgdGhl aXIgY3VzdG9tZXIgc2VydmljZSBpcyB3b3JraW5nLg0KCQkJIA0KCQkJVGhpcyBpcyBhZGRyZXNz ZWQgaW4gU0RILCBPVE4sIEV0aGVybmV0IGFuZCBULU1QTFMgcmVjb21tZW5kYXRpb25zIGJ5IG1l YW5zIG9mIHRoZSBhZGRpdGlvbmFsIFNTRiBhbGFybS4gVGhlIFNTRiBhbGFybSBpcyBmb3IgdGhl IHNlcnZpY2UgZ3V5cyB0ZWxsaW5nIHRoZW0gdGhhdCB0aGUgc2VydmljZSB3YXMgaW50ZXJydXB0 ZWQgZHVlIHRvIGEgZmF1bHQgaW4gYSBzZXJ2ZXIgbGF5ZXIuIEFJUyBzdXBwcmVzc2VzIHRoZSBM T0MgYWxhcm0gaW4gdGhvc2UgY2FzZXMgc28gdGhhdCB0aGUgbWFpbnRlbmFuY2UgZ3V5cyBkb24n dCBnZXQgdHJpZ2dlcmVkIGFuZCBzdGFydCBsb29raW5nIGZvciBhIGZhdWx0IHRoYXQgaXMgb3V0 c2lkZSB0aGVpciBhcmVhLg0KCQkJIA0KCQkJUmVnYXJkcywNCgkJCU1hYXJ0ZW4NCgkJCSANCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCQkJRnJvbTogbXBscy10cC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgYW5keS5iZC5yZWlkQGJ0LmNvbQ0KCQkJU2VudDogd29lbnNkYWcgMjIgYXByaWwgMjAwOSAx MjoxNA0KCQkJVG86IGxpdS5ndW9tYW5AenRlLmNvbS5jbjsgbmVpbC4yLmhhcnJpc29uQGJ0LmNv bQ0KCQkJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCVN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cw0KCQkJDQoJ CQkNCgkJCUxpdSwNCgkJCSANCgkJCUFsbG93IG1lIHRvIGp1bXAgaW4uIFlvdSBhcmUgYnJpbmdp bmcgdG9nZXRoZXIgdHdvIHRoaW5ncyB3aGljaCBhcmUgc2VwYXJhdGUgYW5kIGZvciB3aGljaCBB SVMvRkRJIGlzIG5vIGhlbHAuIE1haW50ZW5hbmNlIG9wZXJhdGlvbnMgYXJlIGNvbmNlcm5lZCB3 aXRoIHR3byBzZXBhcmF0ZSB0aGluZ3MuDQoJCQkgDQoJCQkxKSAgSWRlbnRpZnlpbmcgZmF1bHRz IGluIGVxdWlwbWVudCwgbGluZSBwbGFudCwgYW5kIG90aGVyIHN5c3RlbXMgKGVnIG1pc2NvbmZp Z3VyYXRpb25zKSBhbmQgZml4aW5nIHRoZW0gKGVxdWlwbWVudCBtYWludGVuYW5jZSkuDQoJCQky KSAgSWRlbnRpZnlpbmcgdGhlIGhlYWx0aCBvZiBlbmQgdG8gZW5kIGNvbm5lY3Rpb25zLCBlc3Bl Y2lhbGx5IHdoZW4gdGhleSBhcmUgZGlyZWN0bHkgc3VwcG9ydGluZyBjdXN0b21lciBzZXJ2aWNl cyAoc2VydmljZSBtYWludGVuYW5jZSkuDQoJCQkgDQoJCQlUaGUgcHJvYmxlbSBpcyAqbm90KiBh Ym91dCBhIGxhY2sgb2YgYWxhcm0gc3VwcHJlc3Npb24gaW4gdGhlIGRhdGEgcGxhbmUgLSB0aGF0 IGluZm9ybWF0aW9uIGlzIHJlYWRpbHkgYXZhaWxhYmxlLiBJZiwgYXQgYW4gZW5kIGVxdWlwbWVu dCwgSSBoYXZlIGEgZ29vZCBzZXJ2ZXIvc2VjdGlvbiBsYXllciBhbmQgYSBsb3NzIG9mIENDIGF0 IHRoZSBjbGllbnQgbGF5ZXIsIEkgKmtub3cqIHRoZSBmYXVsdCBpcyBlbHNld2hlcmUgLSBJIGRv bid0IG5lZWQgQUlTL0ZESSB0byB0ZWxsIG1lLiAoSW5kZWVkLCBpZiB5b3UgdGhpbmsgYWJvdXQs IGlmIHRoZSBmYXVsdCBpcyBpbiB0aGUgZW5kIGVxdWlwbWVudCwgaXQgaXMgcXVpdGUgbGlrZWx5 IHRoYXQgdGhlIGZhdWx0IG1lYW5zIGl0IGNhbm5vdCByZXBvcnQgdGhlIHRyYWZmaWMgbG9zcyB0 byB0aGUgbWFuYWdlbWVudCBzeXN0ZW0hKQ0KCQkJIA0KCQkJVGhlIGlzc3VlIGFyaXNlcyBiZWNh dXNlIHRoZSB0d28gc2lkZXMgb2YgbWFpbnRlbmFuY2Ugd2FudCBkaWZmZXJlbnQgdGhpbmdzLiBU aGUgZmF1bHQgZml4aW5nIGd1eXMgd2FudCB0byBsb2NhdGUgdGhlIGZhdWx0IGFuZCBkb24ndCB3 YW50IGFueSBvdGhlciBpbmZvcm1hdGlvbi4gVGhlIHNlcnZpY2UgbWFpbnRlbmFuY2UgZ3V5cyB3 YW50IHRvIGtub3cgd2hldGhlciB0aGVpciBjdXN0b21lciBzZXJ2aWNlIGlzIHdvcmtpbmcuDQoJ CQkgDQoJCQlUaGlzIGFyb3NlIGluIHRoZSBlYXJseSBkYXlzIG9mIFNPTkVUL1NESCwgd2hlbiB0 aGUgb3BlcmF0aW9ucyBndXlzIGRlbWFuZGVkIHRoYXQgdGhlIGVxdWlwbWVudCBkaWQgKm5vdCog c3VwcHJlc3MgdGhlIHRyYWZmaWMgYWxhcm0gZXZlbiB3aGVuIEFJUyB3YXMgYmVpbmcgcmVjZWl2 ZWQgYXMgdGhlIHNlcnZpY2UgZ3V5cyB3YW50IHRvIGtub3cgYWJvdXQgdGhlIGFsYXJtcy4gVGhl IG5vcm1hbCBwcmFjdGljZSBpcyBmb3IgdGhlIGVxdWlwbWVudCB0byByZXBvcnQgdGhlIGFsYXJt cyAqaW5jbHVkaW5nKiBBSVMgYW5kIHRoZW4gYSBmaWx0ZXIgaXMgYXBwbGllZCBpbiB0aGUgbWFu YWdlbWVudCBzeXN0ZW0gdG8gc3VwcHJlc3MgYWxhcm1zIHRvIHRoZSBmYXVsdCBmaXhpbmcgZ3V5 cy4gQXMgSSdtIGF3YXJlLCB0aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgdGVjaG5pcXVlcyBhcHBs aWVkIGZvciB0aGUgZmlsdGVyaW5nIGFsZ29yaXRobXMsIGVzcGVjaWFsbHkgd2hlbiB5b3UgY29u c2lkZXIgbXVsdGlwbGUgY29uY3VycmVudCBmYXVsdHMgaW4gYSBuZXR3b3JrLCBob3dldmVyLCB0 aGUgZXhpc3RhbmNlIG9mIEFJUy9GREkgZG9lc24ndCBhZGQgYW55dGhpbmcgdG8gdGhlc2UgdGhh dCdzIG5vdCBhbHJlYWR5IGtub3duLiBJbiBmYWN0LCBJIGJlbGlldmUgc2ltcGxlIHRpbWUtc3Rh bXAgY29ycmVsYXRpb24gaXMgb25lIG9mIHRoZSBtb3N0IHBvd2VyZnVsIGFuZCB3aWRlbHkgdXNl ZCB0ZWNobmlxdWVzLiBBbmQgaWYgdGhlIGVxdWlwbWVudCBzdGFydHMgbWVzc2luZyB1cCB0aGUg cmVwb3J0aW5nIG9mIGxvc3Mgb2YgQ0MgYmVjYXVzZSBpdCB3YWl0aW5nIGZvci9wZXJzaXN0ZW5j ZSBjaGVja2luZyBBSVMvRkRJLCBpdCBjb3VsZCBlbmQgdXAgbWVzc2luZyB1cCBzaW1wbGUgdGlt ZS1zdGFtcCBjb3JyZWxhdGlvbiEgDQoJCQkgDQoJCQlJbiBwcmFjdGljZSwgaXQgaXMgb2Z0ZW4g bm90IHF1aXRlIGEgc2ltcGxlIGFzIHRoaXMsIGFzIHRoZSBzZXJ2aWNlIGd1eXMgbGlrZSB0byBi ZSBhYmxlIHRvICdsb2NhbGlzZScgdGhlIGZhdWx0LiBIb3dldmVyLCB1bmRlciBtb3N0IGNpcmN1 bXN0YW5jZXMsIHRoZSBmaWx0ZXIgaGFzIGF1dG9tYXRpY2FsbHkgZG9uZSB0aGlzLiBTbyBsb2Nh bGlzYXRpb24geW91IGRlc2NyaWJlIGlzIG9ubHkgd2hlbiB0aGUgZmlsdGVyIGhhc24ndCB3b3Jr ZWQgZm9yIHNvbWUgcmVhc29uLg0KCQkJIA0KCQkJQnV0IHRoZSBib3R0b20gbGluZSBpcywgd2hh dGV2ZXIgb3BlcmF0aW9ucyBwcm9jZXNzIHlvdSB3YW50IHRvIHVzZSwgQUlTL0ZESSBkb2Vzbid0 IGFkZCBhbnl0aGluZyBvdGhlciB0aGFuIGNvbXBsZXhpdHkgYW5kIGZhdWx0IGxpYWJpbGl0eSB0 byB0aGUgZXF1aXBtZW50LiBSZW1lbWJlciBBSVMgZ29lcyBiYWNrIHRvIHRoZSBURE0gd29ybGQg d2hlcmUgeW91ICpoYXZlIHRvIGZpbGwgdGhlIGJpdCBzdHJlYW0gd2l0aCBzb21ldGhpbmcqLg0K CQkJIA0KCQkJIA0KCQkJIA0KCQkJQW5keQ0KCQkJIA0KDQoJCQlBbmR5IFJlaWQgDQoJCQlDaGll ZiBOZXR3b3JrIFNlcnZpY2VzIFN0cmF0ZWdpc3QgDQoJCQlCVCBJbm5vdmF0ZSANCgkJCSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCgkJCU9mZmljZTogKzQ0ICgwKTEyNzcgMzIy MDM4IA0KCQkJTW9iaWxlOiArNDQgKDApNzkxNyAwMjU0NTEgDQoJCQlGYXggOiAgICAgICArNDQg KDApMTI3NyAzMjQwMTUgDQoJCQlFbWFpbDogIGFuZHkuYmQucmVpZEBidC5jb20gDQoNCgkJCQ0K CQkJQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQoJCQlSZWdpc3RlcmVkIG9mZmljZTog ODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQoJCQlSZWdpc3RlcmVkIGluIEVuZ2xh bmQgbm8uIDE4MDAwMDAgDQoJCQlUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZv cm1hdGlvbiBmcm9tIEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYyB3aGljaCBtYXkgYmUg cHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0 byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJv dmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBh bnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVu dHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBieSB0 ZWxlcGhvbmUgb3IgZW1haWwgKHRvIHRoZSBudW1iZXJzIG9yIGFkZHJlc3MgYWJvdmUpIGltbWVk aWF0ZWx5Lg0KDQoJCQlBY3Rpdml0eSBhbmQgdXNlIG9mIHRoZSBCcml0aXNoIFRlbGVjb21tdW5p Y2F0aW9ucyBwbGMgZW1haWwgc3lzdGVtIGlzIG1vbml0b3JlZCB0byBzZWN1cmUgaXRzIGVmZmVj dGl2ZSBvcGVyYXRpb24gYW5kIGZvciBvdGhlciBsYXdmdWwgYnVzaW5lc3MgcHVycG9zZXMuIENv bW11bmljYXRpb25zIHVzaW5nIHRoaXMgc3lzdGVtIHdpbGwgYWxzbyBiZSBtb25pdG9yZWQgYW5k IG1heSBiZSByZWNvcmRlZCB0byBzZWN1cmUgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90 aGVyIGxhd2Z1bCBidXNpbmVzcyBwdXJwb3Nlcy4NCg0KCQkJIA0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCgkJCQlGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaXUuZ3VvbWFu QHp0ZS5jb20uY24NCgkJCQlTZW50OiAyMiBBcHJpbCAyMDA5IDA5OjE1DQoJCQkJVG86IEhhcnJp c29uLE4sTmVpbCxDWE0gUg0KCQkJCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJCQkJU3ViamVjdDog UmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVx dWlyZW1lbnRzDQoJCQkJDQoJCQkJDQoNCgkJCQlOZWlsOiANCgkJCQkgIHRoYW5rIHlvdSBmb3Ig d2FzdGluZyBtb3JlIHRpbWUgaW4gZGVzY3JpYmxpbmcgdGhlIHByb2JsZW1zLiBidXQgSSB0aGlu ayBzb21lIG9mIHdoYXQgeW91IHNhaWQgaXMgbm8gcmVsYXRpb25zIHdpdGggb3VyIHByb2JsZW0u Zm9yIG1lLCBtYXliZSBBSVMvRkRJIGZ1bmN0aW9ucyBpcyBubyBzZW5zZSBpbiBjbC1wcyAsZWcu IElQLiBidXQgZm9yIENPLVBTIG5ldHdvcmtzLmlmIHRoZXJlIGlzIG5vIEFJUy9GREkgZnVuY3Rp b25zLCB3aGVuIHRoZXJlIGlzIGEgZGVmZWN0cyBpbiBhIGdpdmVuIGxheWVyIG5ldHdvcmssIGl0 IGNhbiBjYXVzZSBtdWx0aXBsZSBhbGFybSBldmVudHMgdG8gYmUgcmFpc2VkLiBpdCBpcyBkaWZm Y3VsdCAgZm9yIG9wZXJhdG9ycyB0byBsb2NhdGUgYW5kIGRpYWdub3NlIHRoZSBmYXVsdHMuIA0K CQkJCSB0aG91Z2ggSSBjb21wbGV0ZWx5IGFncmVlIHlvdSBvbiAgYWRkaW5nIG5ldyB0aGluZ3Mg YW5kIGZ1bmN0aW9ucyB3aWxsIGJyaW5nIHNvbWUgY29tcGxleGl0eSAuIGJ1dCBpZiB3ZSBoYXZl IG5vIGZ1bmN0aW9ucywgaXQgaXMgbW9yZSBjb21wbGV4IGFuZCBkaWZjdWx0IGZvciBvcGVyYXRv cnMgdG8gbWFpbnRlbmNlIGFuZCBhZG1pbmlzdHJhdG9yIHRoZSBuZXR3b3JrLiBzbyBJIHRoaW5r IGV2ZXJ5IG5ldyBmdW5jdGlvbnMgYW5kIHRoaW5ncyBtYXkgaGF2ZSBwb3NpdGl2ZSBhbmQgbmVn YXRpdmUgZWZmZWN0cy4gYnV0IHdlIHNob3VsZCBjb25zaWRlciBpdCB2ZXJ5IG11Y2gsIGRvbid0 IGRlbGV0ZSBzb21lIGZ1bmN0aW9ucyBhdCByYW5kb20uIA0KCQkJCQ0KCQkJCQ0KCQkJCWJlc3Qg cmVnYXJkcyANCgkJCQlsaXUgDQoJCQkJDQoJCQkJDQoJCQkJDQo8bmVpbC4yLmhhcnJpc29uQGJ0 LmNvbT4gDQoNCjIwMDktMDQtMjEgMjA6MzAgDQoNCuaUtuS7tuS6ug0KPGxpdS5ndW9tYW5AenRl LmNvbS5jbj4sIDxkYnJ1bmdhcmRAYXR0LmNvbT4gDQrmioTpgIENCjxtcGxzLXRwQGlldGYub3Jn PiANCuS4u+mimA0KUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggcmVxdWlyZW1lbnRzCQ0KDQoJCQ0KDQoNCg0KDQoJCQkJTGl1LCANCgkJCQkgIA0K CQkJCUlmIE1QTFMtVFAgaXMgZ29pbmcgdG8gYmUgdGFrZW4gc2VyaW91c2x5IGFzIGEgdHJhbnNw b3J0IG5ldHdvcmsgKGxpa2UgU0RIL1NPTkVUKSB0aGVuIHRoZSAyIGtleSBNVVNUIEhBVkUgcmVx dWlyZW1lbnRzIGFyZSB0aGVzZS4gDQoJCQkJICANCgkJCQkxICAgIFByb3ZpZGUgYSB0cmFuc3Bh cmVudCBjbGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcC4uLndoaWNoIG1lYW5zOiANCgkJCQktICAg IGFsbCBjbGllbnQgYml0cyB0cmVhdGVkIGVxdWFsbHkgDQoJCQkJLSAgICBjbGllbnQgYml0IG9y ZGVyaW5nIHByZXNlcnZlZCANCgkJCQktICAgIG5vIGF0dGVtcHQgdG8gaW5mZXIgY2xpZW50IHN5 bWJvbCAoaWUgc2VxdWVuY2Ugb2YgY2xpZW50IGJpdHMpIG1lYW5pbmcgYW5kIG5vIGF0dGVtcHQg dG8gY2hhbmdlIGNsaWVudCBzeW1ib2xzIA0KCQkJCS0gICAgdGhlIHRyYWZmaWMgYmVoYXZpb3Vy IG9mIGNsaWVudCBYIG11c3Qgbm90IGltcGFjdCB0aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQg YnkgY2xpZW50IFkgDQoJCQkJICANCgkJCQlBIGtleSBjb3JvbGxhcnkgb2YgdGhlIGFib3ZlIGlz IHRoYXQgTVBMUy1UUCBtdXN0IG9ubHkgc3VwcG9ydCBwcm9wZXIgY29ubmVjdGlvbnMgKGllIHNp bmdsZSBzb3VyY2UgY29uc3RydWN0cykgDQoJCQkJICANCgkJCQkgIA0KCQkJCTIgICBTaW5jZSBN UExTLVRQIGlzIGEgdHJhbnNwb3J0IG5ldHdvcmsgaXQgaXMgbm90IGEgdG9wLW9mLXN0YWNrIG5l dHdvcmsgKGllIGl0IGRvZXMgbm90IHN1cHBvcnQgZGlyZWN0bHkgZXh0ZXJuYWwgbWVzc2FnZS9m aWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMpLiAgTVBMUy1UUCB0aGVyZWZvcmUgZG9lcyBub3QgcmVx dWlyZSBhbiBFLU5OSSBzcGVjaWZpY2F0aW9uLiAgQSBrZXkgY29yb2xsYXJ5IG9mIHRoaXMgaXMg dGhhdCBNUExTLVRQIHdpbGwgbm90IGhhdmUgYW55IHBlZXIgaW50ZXJ3b3JraW5nIHJlbGF0aW9u c2hpcCB3aXRoIGFueSBvdGhlciBuZXR3b3JrIG1vZGUvdGVjaG5vbG9neS4gDQoJCQkJICANCgkJ CQkgIA0KCQkJCU5vdyB3cnQgT0FNIE1QTFMtVFAgaXMgYSBjby1wcyBtb2RlIG5ldHdvcmsuICBZ b3UgY291bGQgYXJndWUgdGhpcyBzaG91bGQgaGF2ZSBGREkvQUlTLi4uLmhvd2V2ZXIsIHRoZSBt ZXJpdCBvZiB0aGlzIGlzIGhpZ2hseSBxdWVzdGlvbmFibGUuICBXaGVuIEkgYW5kIGNvbGxlYWd1 ZXMgZGlzY3Vzc2VkIHdoZXRoZXIgUEJCLVRFIChhbHNvIGEgY28tcHMgbW9kZSBuZXR3b3JrKSBz aG91bGQgaGF2ZSBGREkvQUlTIHdlIGNvbmNsdWRlZCB0aGF0IG9uIGJhbGFuY2UgaXQgd2FzIG5v dCBhIGdvb2QgaWRlYS4uLi4uYW5kIG5vdGUgdGhhdCBpbml0aWFsbHkgSSB3YXMgaW4gZmF2b3Vy IG9mIGhhdmluZyBBSVMsIGJ1dCBteSBjb2xsZWFndWVzIHByb3ZpZGVkIHN0cm9uZyB0ZWNobmlj YWwgYXJndW1lbnRzIHRoYXQgY29udmluY2VkIG1lIG90aGVyd2lzZS4gDQoJCQkJICANCgkJCQlB SVMvRkRJIGlzIGhpc3RvcmljYWxseSBsaW5rZWQgdG8gdGhlIGVhcmx5IFBESCBjby1jcyBtb2Rl IGxheWVyIG5ldHdvcmtzIHRoYXQgdXNlZCBUVEwgbG9naWMuICBXaGVuIHRoaXMgZGllZCBpdCBw dXQgb3V0IGEgKzVWIChhbGwgMXMpIHNpZ25hbCBieSBkZWZhdWx0LCBpZSBpdCByZXF1aXJlZCBu byBjb25zY2lvdXMgZWZmb3J0IHRvIGdlbmVyYXRlIGl0Li4uLi50aGlzIGlzIGtleSBwb2ludC4g IEZ1cnRoZXIsIGluIHRoZXNlIG5ldHdvcmtzIHRoZXJlIGlzIGEgZmFpcmx5IHN0YXRpYy9sb25n LWhvbGRpbmcgY2xpZW50IHNlcnZlciByZWxhdGlvbnNoaXAuICBDbGVhcmx5IHRoaXMgaXMgbm90 IHRydWUgaW4gdGhlIGNsLXBzIG1vZGUgYW5kIGl0J3Mgd2h5IElFVEYgaGF2ZSBuZXZlciBzcGVj aWZpZWQgQUlTIGZvciBJUCBhbmQgaXRzIHdoeSBJRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byB0 aHJvdy1vdXQgQUlTIGluIDgwMi4xYWcgZm9yIEV0aGVybmV0ICh0aG91Z2ggSVRVIGhhdmUgdW53 aXNlbHkgSU1PIHJldGFpbmVkIGl0IGluIFkuMTczMS4uLi5idXQgSSBzdXNwZWN0IGFueSBvcGVy YXRvciBwbGFubmluZyB0byB1c2UgRXRoZXJuZXQgZXF1aXBtZW50IHdvdWxkIGFsd2F5cyBsb29r IHRvIElFRUUgc3RkcyBhbmQgbm90IElUVSBvbmVzKS4gDQoJCQkJICANCgkJCQlBSVMvRkRJIGFu ZCB0aGUgY28tcHMgbW9kZSBpcyBkZWJhdGFibGUuICBBcyBJIG5vdGVkIGFib3ZlLCBvbiBiYWxh bmNlIHdlIGNvbnNpZGVyZWQgbm90IGEgZ29vZCBpZGVhIGZvciBQQkItVEUgT0FNIGJlY2F1c2Ug aXQgcmVxdWlyZXMgYSBjb25zY2lvdXMgZWZmb3J0IHRvIGdlbmVyYXRlIGl0ICh1bmxpa2UgdGhl IGNvLWNzIG1vZGUpIHNvIHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUgc2NhbGluZyBwcm9ibGVtcyBh bmQgaXRzIG9uZSBtb3JlIHRoaW5nIHRvIGdvIHdyb25nLiANCgkJCQkgIA0KCQkJCVlvdSBzaG91 bGQgYWxzbyBoYXZlIHNlZW4gbWUgbWFrZSB0aGUgcG9pbnQgbWFueSB0aW1lcyBpbiB0aGUgcGFz dCB0aGF0IHRoZSBhbHdheXMtb24gZGVmZWN0IGRldGVjdGlvbi9oYW5kbGluZyBPQU0gbmVlZHMg dG8gYmUgYXMgc2ltcGxlL3NwYXJzZSBhcyBwb3NzaWJsZSB3aXRoIGFzIGxpdHRsZSBjb25maWcg YXMgcG9zc2libGUgYmVjYXVzZSB3ZSBuZWVkIHN1cGVyIHJlbGlhYmlsaXR5Li4uLi4uVENNIGdv ZXMgY29tcGxldGVseSBhZ2FpbnN0IHRoZSBncmFpbiBoZXJlLiAgQWxzbyBub3RlIHRoYXQgdGhl IE9BTSByZXF1aXJlZCBmb3IgZWFjaCBvZiB0aGUgMyBuZXR3b3JrIG1vZGVzIGlzIG5vdCB0aGUg c2FtZSwgZGVzcGl0ZSB3aGF0IHNvbWUgY2xhaW0uIA0KCQkJCSAgDQoJCQkJcmVnYXJkcywgTmVp bCANCgkJCQkgIA0KCQkJCQ0KCQkJCQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KCQkJCUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGxpdS5ndW9tYW5AenRlLmNvbS5jbg0KCQkJCVNl bnQ6IDIxIEFwcmlsIDIwMDkgMDI6NTkNCgkJCQlUbzogQlJVTkdBUkQsIERFQk9SQUggQSwgQVRU TEFCUw0KCQkJCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJCQkJU3ViamVjdDogUmU6IFttcGxzLXRw XSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzDQoJ CQkJDQoJCQkJDQoJCQkJRGVib3JhaDogDQoJCQkJbWF5YmUgd2hhdCB5b3Ugc2FpZCBpcyByaWdo dC4gYnV0IEkgY2FuJ3QgY29tcGxldGVseSBhZ3JlZSB5b3VyIG9waW5pb25zLiBJTU8uIG1wbHMt dHAgaXMgcmVnYXJkIGFzIHRyYW5zcG9ydCBuZXR3b3JrIGxpa2UgU0RIL1NPTkVULiBzbyBpdCBz aG91bGQgaGF2ZSBBSVMvRkRJIGZ1Y3Rpb25zIGFzIFNESC9TT05FVC4gDQoJCQkJDQoJCQkJZG8g eW91IHRoaW5rIHNvLiANCgkJCQkNCgkJCQliZXN0IHJlZ2FyZHMgDQoJCQkJbGl1IA0KCQkJCQ0K CQkJCQ0KIkJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMiIDxkYnJ1bmdhcmRAYXR0LmNvbT4g DQrlj5Hku7bkuro6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQoNCjIwMDktMDQtMjAgMjM6 NDcgDQoNCg0KDQrmlLbku7bkuroNCiJNYWFydGVuIFZpc3NlcnMiIDxtYWFydGVuLnZpc3NlcnNA aHVhd2VpLmNvbT4sIDxuZWlsLjIuaGFycmlzb25AYnQuY29tPiANCuaKhOmAgQ0KbXBscy10cEBp ZXRmLm9yZyANCuS4u+mimA0KUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg dHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzCQ0KDQoNCgkJDQoNCg0KCQkJCQ0KCQkJCQ0KCQkJ CQ0KCQkJCUkgYWdyZWUgd2l0aCBOZWlsLCBpdCBpcyB2ZXJ5IHF1ZXN0aW9uYWJsZSB0aGUgdmFs dWUgb2YgQUlTL0ZESSBpbiBhDQoJCQkJcGFja2V0IG5ldHdvcmstIGFueSBtb2RlLiBJdCBjYW4g cmVzdWx0IGluIGEgRG9TIGF0dGFjayBieSBhbiBvcGVyYXRvcg0KCQkJCW9uIHRoZW1zZWx2ZXMg c28gZXZlbiBZMTczMSByZWNvbW1lbmRzIG5vdCB0byBibG9jayBkYXRhIGZyYW1lczoNCgkJCQki QSBNRVAgY2FuIGRlY2lkZSB3aGV0aGVyIGl0IGJsb2NrcyBkYXRhIGZyYW1lcyB3aGVuIGl0IGRl dGVjdHMgZEFJUy4NCgkJCQlUaGUgcHJpbmNpcGxlIHJlcXVpcmVtZW50DQoJCQkJdGhhdCBpbmZs dWVuY2VzIHRoaXMgZGVjaXNpb24gaXMgdGhhdCBkYXRhIGZyYW1lcyBvdWdodCB0byBiZSBmb3J3 YXJkZWQNCgkJCQlhcyBtdWNoIGFzIHBvc3NpYmxlLCB3aXRob3V0DQoJCQkJdGhlIHBvc3NpYmls aXR5IG9mIGZvcndhcmRpbmcgd3JvbmcgZGF0YSBmcmFtZXMgZG93bnN0cmVhbS4iDQoJCQkJVGFi bGUgSS43LTIgc2hvd3MgZm9yIEFJUywgbm90IHRvIGJsb2NrLg0KCQkJCQ0KCQkJCUFuZCBhcyBZ MTczMSBzdGF0ZXMsIEFJUyBjYW4gb25seSBiZSB1c2VkIHVuZGVyIHZlcnkgY29uc3RyYWluZWQN CgkJCQlhcmNoaXRlY3R1cmVzIC0gaWYgcmVxdWlyZWQgZm9yIE1QTFMtVFAsIGl0IG5lZWRzIHRv IGhhdmUgdGhlIHNhbWUNCgkJCQlndWlkYW5jZSBhcyBpbiBZMTczMSwgaS5lLiBwb2ludC10by1w b2ludCBhbmQgc2VydmVyL2NsaWVudCBvbmUtdG8tb25lOg0KCQkJCSJmb3IgYSBwb2ludC10by1w b2ludCBFVEggY29ubmVjdGlvbiwgYSBNRVAgaGFzIG9ubHkgYSBzaW5nbGUgcGVlciBNRVAuDQoJ CQkJVGhlcmVmb3JlLCB0aGVyZQ0KCQkJCWlzIG5vIGFtYmlndWl0eSByZWdhcmRpbmcgdGhlIHBl ZXIgTUVQIGZvciB3aGljaCBpdCBzaG91bGQgc3VwcHJlc3MNCgkJCQlhbGFybXMgd2hlbiBpdCBy ZWNlaXZlcyB0aGUNCgkJCQlFVEgtQUlTIGluZm9ybWF0aW9uLiINCgkJCQlTbyBzaG91bGQgb25s eSBiZSB3aXRoaW4gb25lIGRvbWFpbiAtIHRoZW4gbm8gbmVlZC4NCgkJCQkNCgkJCQlEZWJvcmFo DQoJCQkJDQoJCQkJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJCQlGcm9tOiBtcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQoJ CQkJQmVoYWxmIE9mIE1hYXJ0ZW4gVmlzc2Vycw0KCQkJCVNlbnQ6IE1vbmRheSwgQXByaWwgMjAs IDIwMDkgMTA6MDUgQU0NCgkJCQlUbzogbmVpbC4yLmhhcnJpc29uQGJ0LmNvbQ0KCQkJCUNjOiBt cGxzLXRwQGlldGYub3JnDQoJCQkJU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCgkJCQlyZXF1aXJlbWVudHMNCgkJCQkNCgkJCQlO ZWlsLA0KCQkJCQ0KCQkJCT4gYnV0IEFJUy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBm YXZvdXIhDQoJCQkJDQoJCQkJRXRoZXJuZXQgQUlTIGlzIGluZGVlZCBhIHJlcXVpcmVtZW50IGFu ZCBhIG5lY2Vzc2l0eS4gQW5kIHlvdSB3aWxsIG5vdA0KCQkJCWJlDQoJCQkJYWJsZSB0byB1bmRl cnN0YW5kIHRoYXQgYXMgbG9uZyBhcyB5b3UgcmVmdXNlIHRvIGFjY2VwdCB0aGF0ICJjbC1tb2Rl Ig0KCQkJCWlzIGENCgkJCQlmb3J3YXJkaW5nIG1vZGUgd2l0aGluIGEgKip0cmFuc3BvcnQgZW50 aXR5KiouIEcuODAwIGFtZW5kbWVudCAxIGhhcw0KCQkJCWZpbmFsbHkNCgkJCQlyZWludHJvZHVj ZWQgdGhpcyB0cmFuc3BvcnQgZW50aXR5IGludG8gRy44MDAuIEJlc2lkZXMgdGhhdCwgaXQgYWxz bw0KCQkJCWludHJvZHVjZWQgdGhlICoqZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbioqOg0KCQkJ CQ0KCQkJCVtHLjgwMCBhbTFdICJBIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24gaXMgYSB0cmFu c3BvcnQgZW50aXR5IHRoYXQNCgkJCQl0cmFuc2ZlcnMgaW5mb3JtYXRpb24gYmVsb25naW5nIHRv IG11bHRpcGxlIGNvbW11bmljYXRpb25zIGJldHdlZW4gcG9ydHMNCgkJCQlhY3Jvc3MgYSBzdWJu ZXR3b3JrLiA8Li4+IEluIGEgZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiBtZXNzYWdlDQoJCQkJ Y29udGVudHMNCgkJCQlhcmUgaW50ZXJwcmV0ZWQgdG8gaWRlbnRpZnkgKHNldHMgb2YpIGNvbW11 bmljYXRpb25zIHdoaWNoIHJlY2VpdmUNCgkJCQlkaWZmZXJlbnQNCgkJCQl0cmVhdG1lbnQuICBU aGUgc2V0cyBvZiBjb21tdW5pY2F0aW9ucyBtYXkgYmUgZGlzdGluZ3Vpc2hlZCBieSB0aGUNCgkJ CQlmb3J3YXJkaW5nIGlkZW50aWZpZXIgb3Igb3RoZXIgbGF5ZXIgaW5mb3JtYXRpb24uICBPcmRl ciBpcyBub3QNCgkJCQluZWNlc3NhcmlseQ0KCQkJCXByZXNlcnZlZCBiZXR3ZWVuIG1lc3NhZ2Vz IGJlbG9uZ2luZyB0byBzZXRzIG9mIGNvbW11bmljYXRpb25zIHJlY2VpdmluZw0KCQkJCWRpZmZl cmVudCB0cmVhdG1lbnQuICBTZXRzIG9mIGNvbW11bmljYXRpb25zIG1heSBiZSBpZGVudGlmaWVk IGZvcg0KCQkJCXB1cnBvc2VzDQoJCQkJc3VjaCBhcyB0cmFmZmljIGNvbmRpdGlvbmluZyBvciBw cmVzZXJ2aW5nIGNvbW11bmljYXRpb24gbWVzc2FnZSBvcmRlci4iDQoJCQkJDQoJCQkJDQoJCQkJ RXRoZXJuZXQgVkxBTnMgYXJlIGluIHRlcm1zIG9mIEcuODAwICJkaWZmZXJlbnRpYXRlZCBjb25u ZWN0aW9ucyIuDQoJCQkJRXRoZXJuZXQNCgkJCQlBSVMgcHJvdmlkZXMgQUlTIHdpdGhpbiB0aGUg c2NvcGUgb2Ygc3VjaCAiZGlmZmVyZW50aWF0ZWQgY29ubmVjdGlvbiIuDQoJCQkJSWYNCgkJCQl5 b3UgYXBwbHkgdGhpcyB0byBteSBwcm9wb3NlZCBQVE4gbGF5ZXIgc3RhY2ssIHRoZW4gdGhlIEVW QyBsYXllcg0KCQkJCXRvcG9sb2d5DQoJCQkJd2lsbCBjb25zaXN0cyBvZiBFVkMgbGlua3Mgc3Vw cG9ydGVkIGJ5IE1QTFMtVFAsIEV0aGVybmV0LCBQQkItVEUgYW5kDQoJCQkJUC1PVE4NCgkJCQlW UCB0cmFpbHMgaW5zaWRlIG1ldHJvIGFuZCBjb3JlIGRvbWFpbnMgaW50ZXJjb25uZWN0aW5nIEVW QyBtYXRyaWNlcy4NCgkJCQlXaGVuDQoJCQkJb25lIG9mIHRob3NlIEVWQyBsaW5rcyBpcyBpbnRl cnJ1cHRlZCwgZS5nLiBpbiB0aGUgY29yZSBiZXR3ZWVuIG1ldHJvIDENCgkJCQlhbmQNCgkJCQlt ZXRybyA0IChzZWUgYXR0YWNoZWQgc2xpZGUpLCB0aGVuIHRoZSBFVkMgZGlmZmVyZW50aWF0ZWQg Y29ubmVjdGlvbg0KCQkJCXRoYXQgaXMNCgkJCQlwcmVzZW50IG9uIHRoaXMgbGluayB3aWxsIGJl IGludGVycnVwdGVkLiBBdCB0aGUgRVZDIHN3aXRjaC9icmlkZ2Ugbm9kZQ0KCQkJCWluDQoJCQkJ bWV0cm8gNCB0aGlzIGludGVycnVwdGlvbiBpcyBub3RpY2VkIGFuZCBFVkMtQUlTIGlzIGluc2Vy dGVkIGluIHRoZQ0KCQkJCWRvd25zdHJlYW0gZGlyZWN0aW9uIHRvIHN1cHByZXNzIHRoZSBFVkMt TE9DIGFsYXJtcyBhdCBFVkMgZW5kcG9pbnRzIEQ0DQoJCQkJYW5kDQoJCQkJRDUuDQoJCQkJDQoJ CQkJVGhlIEVWQy1BSVMgKGkuZS4gRXRoZXJuZXQgQUlTKSBmcmFtZSBoYXMgYSByZXNlcnZlZCBt dWx0aWNhc3QgYWRkcmVzcywNCgkJCQl3aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIEFJUyBpcyBi cm9hZGNhc3QgdG8gdGhlIGVuZHBvaW50cyBvZiB0aGUgRVZDLg0KCQkJCQ0KCQkJCUkgYmVsaWV2 ZSB0aGF0IGl0IGlzIHRpbWUgZm9yIHlvdSB0byBhZGFwdCB5b3VyIHZpZXcgb24gY28gYW5kIGNs IG1vZGVzDQoJCQkJYW5kDQoJCQkJcmVsYXRlIGl0IHRvIHRoZSBmb3J3YXJkaW5nIG1vZGUgKipJ TlNJREUqKiBhIHRyYW5zcG9ydCBlbnRpdHkuIA0KCQkJCQ0KCQkJCVdoYXQgd2Uga25vdyBhcyB0 aGUgaW50ZXJuZXQgaXMgZXNzZW50aWFsbHkgYW4gIklQIGRpZmZlcmVudGlhdGVkDQoJCQkJY29u bmVjdGlvbiIgd2l0aCBhIGJpbGxpb24gb3IgbW9yZSBwb3J0cy4NCgkJCQlXaGF0IHdlIGtub3cg YXMgYW4gSVAgVlBOIGlzIGVzc2VudGlhbGx5IGFuICJJUCBkaWZmZXJlbnRpYXRlZA0KCQkJCWNv bm5lY3Rpb24iDQoJCQkJd2l0aCBlLmcuIG4gcG9ydHMgKG4gaW4gdGhlIHJhbmdlIG9mIGUuZy4g MiB0byAxMDAwKS4NCgkJCQlXaGF0IHdlIGtub3cgYXMgYW4gRXRoZXJuZXQgVkxBTiBpcyBlc3Nl bnRpYWxseSBhbiAiRXRoZXJuZXQNCgkJCQlkaWZmZXJlbnRpYXRlZA0KCQkJCWNvbm5lY3Rpb24i IHdpdGggbiBwb3J0cyAobiBpbiB0aGUgcmFuZ2Ugb2YgZS5nLiAyIHRvIDEwMDApLg0KCQkJCVdo YXQgd2Uga25vdyBhcyBhIHAycCBNUExTIEUtTFNQIGlzIGVzc2VudGlhbGx5IGFuICJNUExTIGRp ZmZlcmVudGlhdGVkDQoJCQkJY29ubmVjdGlvbiIgd2l0aCAyIHBvcnRzLg0KCQkJCVdoYXQgd2Ug a25vdyBhcyBhIHAycCBTREggVkMtbiBpcyBhICJTREggVkMtbiBjb25uZWN0aW9uIiB3aXRoIDIg cG9ydHMuDQoJCQkJDQoJCQkJVHJhbnNwb3J0IG5ldHdvcmsgT0FNIGFwcGxpZXMgdG8gdHJhbnNw b3J0IGVudGl0aWVzLCB3aGljaCBhcmUgKGluIHRlcm1zDQoJCQkJb2YNCgkJCQlHLjgwMCBhbTEp IGNvbm5lY3Rpb25zIGFuZCBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9ucy4NCgkJCQkNCgkJCQlS ZWdhcmRzLA0KCQkJCU1hYXJ0ZW4NCgkJCQkNCgkJCQktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KCQkJCUZyb206IG5laWwuMi5oYXJyaXNvbkBidC5jb20gW21haWx0bzpuZWlsLjIuaGFycmlz b25AYnQuY29tXSANCgkJCQlTZW50OiB2cmlqZGFnIDE3IGFwcmlsIDIwMDkgMjI6MDANCgkJCQlU bzogSm9obi5FLkRyYWtlMkBib2VpbmcuY29tOyBJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0 Ow0KCQkJCUFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBtYWFydGVuLnZpc3NlcnNA aHVhd2VpLmNvbQ0KCQkJCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJCQkJU3ViamVjdDogUkU6IFtt cGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgNCgkJCQlyZXF1 aXJlbWVudHMNCgkJCQkNCgkJCQlKb2huLCAgVGhhbmtzIHRoaXMgaXMgYSBncmVhdCBwbGF0Zm9y bSB0byBleHBsYWluIHdoeSBPQU0gZm9yIHRoZSAzDQoJCQkJbmV0d29yaw0KCQkJCW1vZGVzIG5l ZWRzIHRvIGJlIGRpZmZlcmVudC4gIEkgYW0gZ2V0dGluZyBhIHdlZSBiaXQgdGlyZWQgb2YgZm9s a3MNCgkJCQl0cnlpbmcNCgkJCQl0byBtYWtlIGFsbCAzIG5ldHdvcmsgbW9kZXMgbG9vayBhbGlr ZSAoYW5kIHRoZW4sIGV2ZW4gd29yc2UsIGludGVyd29yaw0KCQkJCXRoZW0NCgkJCQlhcyBhcyBw ZWVycy4uLmVzcCB3aGVuIG5vdCBub3QgdG9wLW9mLXN0YWNrDQoJCQkJbmV0d29ya3MuLi5JIG1l YW4gaG93IHNpbGx5IGNhbiB3ZSBnZXQ/KS4gICBJIGFtIGV2ZW4gbW9yZSBmcnVzdHJhdGVkIGJ5 DQoJCQkJdGhlIGZhY3QgdGhvc2UgcGVkZGxpbmcgdGhpcyBGVUQgb25seSBldmVyIHNlZW0gdG8g Y29uc2lkZXIgT0FNIGFuZA0KCQkJCWZvcmdldA0KCQkJCWFsbCBvdGhlciBEUC9DUC9NUCBjb21w b25lbnRzIChlc3AgdG9wLW9mLXN0YWNrIG1lc3NhZ2UvZmlsZS9zdHJlYW0NCgkJCQlhcHBsaWNh dGlvbiBhZGFwdGF0aW9ucykuICBIb3cgd3JvbmcgY2FuIHRoaXMgZ2V0ISANCgkJCQkNCgkJCQlJ biB0aGUgY28gbW9kZXMgYSAqY29ubmVjdGlvbiogaXMgYSB2ZXJ5IHNwZWNpZmljIGFuZCAqY29u c3RyYWluaW5nKg0KCQkJCWNvbnN0cnVjdC4uLi4uSSBhbSBhc3N1bWluZyBoZXJlIHdlIHJlc3Bl Y3QgdGhlIHJ1bGVzIG9mIGEgY29ubmVjdGlvbg0KCQkJCShpZQ0KCQkJCXNpbmdsZSBzb3VyY2Up IHRob3VnaCBzb21lIGZvbGtzIGRvbid0IGV2ZW4gYm90aGVyIHRvIHJlc3BlY3QgdGhpcywgYW5k DQoJCQkJdGhpcw0KCQkJCWlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3ZSBhbGwga25vdyB3aGF0 IHByb2JsZW1zIG11bHRpcGxlLXNvdXJjZQ0KCQkJCWNvbnN0cnVjdHMgY2FuIGNhdXNlIChmcm9t IExEUC9QSFAuLi4uZXJnbyBNUExTLVRQKS4NCgkJCQkNCgkJCQlXaGVuIHdlIGhhdmUgYSBjb25u ZWN0aW9uIHRoaXMgcmVzdHJpY3RzICphbGwqIERQIChpZSB0cmFmZmljIGFuZCBPQU0pDQoJCQkJ dG8NCgkJCQlzdGF5IHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBjb25uZWN0aW9uLiAgV2hpY2gg aXMgZmluZSB1bmRlcg0KCQkJCWRlZmVjdC1mcmVlDQoJCQkJY29uZGl0aW9ucywgYnV0IGlmIHdl IGhhdmUgbGVha2luZyB0cmFmZmljIHRoZW4gdGhlIGNvbnN0cmFpbmluZyBuYXR1cmUNCgkJCQlv Zg0KCQkJCXRoZSBjb25uZWN0aW9uIGNvbnN0cnVjdCBpcyBicm9rZW4uICBJbiBhIG51dHNoZWxs IHdoYXQgdGhpcyBtZWFucyBpcw0KCQkJCXRoYXQNCgkJCQlPQU0gdGhhdCBpcyBvZiBhIHJlcXVl c3QvcmVzcG9uc2UgbmF0dXJlIGNhbm5vdCBiZSB0cnVzdGVkIGluIGNvIG1vZGUNCgkJCQluZXR3 b3JrcyB1bmRlciBtaXNjb25uZWN0aXZpdHkgZGVmZWN0cy4uLi4uaW5kZWVkLCB3aHkgc2hvdWxk IGEgbGVha2luZw0KCQkJCURQDQoJCQkJaGF2ZSBhIHN5bW1ldHJpYyBnby9yZXR1cm4gZGVmZWN0 IGJlaGF2aW91cj8uLi4udmVyeSBsaWtlbHkgaXQgd29uJ3QuDQoJCQkJU28NCgkJCQl3aGlsc3Qg cmVxdWVzdC9yZXNwb25zZSBPQU0gaXMgcmlnaHQgZm9yIHRoZSBjbCBtb2RlIGl0IGlzIG5vdCBy aWdodCBmb3INCgkJCQl0aGUNCgkJCQljbyBtb2RlIHVuZGVyIG1pc2Nvbm5lY3Rpdml0eSBkZWZl Y3QgY29uZGl0aW9ucy4NCgkJCQkNCgkJCQlNb3JlIGdlbmVyYWxseSB0aGUgMyBtb2RlcyBhcmUg ZGlmZmVyZW50IGFuZCBub3QganVzdCBpbiBPQU0NCgkJCQlyZXF1aXJlbWVudHMuLi4uYnV0IEFJ Uy9GREkgaW4gdGhlIGNsIG1vZGU/Li4uZG8gbWUgYSBmYXZvdXIhLi4uYXQgbGVhc3QNCgkJCQlJ RUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRoZXJuZXQgZXZlbiB0aG91 Z2ggaXQgcmVtYWlucw0KCQkJCWluDQoJCQkJWS4xNzMxLiAgQW5kIHdoaWNoIGlzIHdoeSBJIG9m dGVuIHRyb3Qtb3V0IHRoZSByYXRoZXIgc2lsbHkgKHRvIGhhdmUgdG8NCgkJCQlzYXkNCgkJCQl0 aGlzKSBvYnNlcnZhdGlvbiB0aGF0IGlmIElQIChjbCBtb2RlKSBjb3VsZCBkbyBpdCBhbGwgdGhl biB3aHkgaGF2ZQ0KCQkJCUlFVEYNCgkJCQlmb3VuZCBpdCBuZWNlc3NhcnkgdG8gY3JlYXRlIE1Q TFMgKGNvLXBzKSBhbmQgR01QTFMgKENQIGZvciBjby1jcykuICBUaGUNCgkJCQlhbnN3ZXIgbGll cyBpbiB0aGUgcGh5c2ljcy4uLmFuZCBHLjgwMCBhdHRlbXB0cyB0byBleHBsYWluIHRoYXQNCgkJ CQlwaHlzaWNzLi4uLkcuODA1IGRvZXMgbm90Lg0KCQkJCQ0KCQkJCVNvLCB0aGUgMyBtb2RlcyBh cmUgZGlmZmVyZW50Li4ucGxlYXNlIGFjY2VwdC9yZWpvaWNlIGluIHRoaXMgZmFjdCBhcw0KCQkJ CXRoZXkNCgkJCQlhbGwgb2ZmZXIgc29tZXRoaW5nIGRpZmZlcmVudC9pbXBvcnRhbnQuICBCdXQg ZG8gbm90IGJlIGhvb2R3aW5rZWQgYnkNCgkJCQl0aG9zZQ0KCQkJCXdobyBwZWRkbGUgYSBzdG9y eSB0aGF0IHRoYXQgdHJpZXMgdG8gbWFrZSB0aGUgT0FNIG9mIHRoZSAzIG1vZGVzIHRoZQ0KCQkJ CXNhbWUuIA0KCQkJCQ0KCQkJCXJlZ2FyZHMsIE5laWwgDQoJCQkJDQoJCQkJPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KCQkJCT4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoJ CQkJPiBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERyYWtl LCBKb2huIEUNCgkJCQk+IFNlbnQ6IDE3IEFwcmlsIDIwMDkgMjA6MDINCgkJCQk+IFRvOiBCVVNJ IElUQUxPOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgTWFhcnRlbiBWaXNzZXJzDQoJCQkJPiBDYzog bXBscy10cEBpZXRmLm9yZw0KCQkJCT4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQoJCQkJPiByZXF1aXJlbWVudHMNCgkJCQk+ IA0KCQkJCT4gSXRhbG8sDQoJCQkJPiANCgkJCQk+IEFzIGRlc2NyaWJlZCBpbiB0aGUgTVBMUyBU UCBPQU0gUmVxdWlyZW1lbnRzIEktRCwgdmlydHVhbGx5IGFsbCBvZiB0aGUNCgkJCQkNCgkJCQk+ IE9BTSBmdW5jdGlvbnMgcmVxdWlyZSBhIHJldHVybiBwYXRoLCBhbmQgaW4gdGhlIGFic2VuY2Ug b2YgYSByZXR1cm4gDQoJCQkJPiBwYXRoIHRoZXkgYXJlIGRpc2FibGVkLg0KCQkJCT4gDQoJCQkJ PiBBcyBkZXNjcmliZWQgaW4gRGF2aWQgU2luaWNyb3BlJ3MgbWVldGluZyBtaW51dGVzIA0KCQkJ CT4gKGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL21pc2MvbXBscy1pbnRlcm9wL2F0dGFjaG1l bnQvd2lraS8NCgkJCQk+IG1lZXRpbmctbm8NCgkJCQk+IHRlcy8yMDA4MTAxNS5tcGxzLWludGVy b3AtZHQtbm90ZXMuemlwKSwgaWYgSVAgYWRkcmVzc2luZyBpcyB1c2VkLCBhbiANCgkJCQk+IE1Q TFMgVFAgbmV0d29yayBuZWVkcyB0byBiZSBjYXBhYmxlIG9mIGdldHRpbmcgSVAgcGFja2V0cyBm cm9tIA0KCQkJCT4gZGVzdGluYXRpb24gdG8gc291cmNlOyBuZWl0aGVyIHRoZSBtaW51dGVzIG5v ciBJIHN0aXB1bGF0ZSB0aGF0IGEgDQoJCQkJPiBjb250cm9sIHBsYW5lIG5lZWRzIHRvIGJlIHVz ZWQgdG8gaW5zdGFudGlhdGUgdGhpcyBmb3J3YXJkaW5nLg0KCQkJCT4gDQoJCQkJPiBBcyBhbiBh c2lkZSwgdGhlIGlzc3VlIG9mIHJldHVybiBwYXRoIGZvciB1bmlkaXJlY3Rpb25hbCBMU1BzIGNv dWxkIGJlDQoJCQkJDQoJCQkJPiBjaGFyYXRlcml6ZWQgYXMgdGhlIGVsZXBoYW50IGluIHRoZSBy b29tLiAgSW4gdGhlIE1QTFMgVFAgT0FNIA0KCQkJCT4gRnJhbWV3b3JrIEktRCwgdW5pY2FzdCBM U1BzIGFyZSBvbmx5IG1lbnRpb25lZCB0aHJlZSB0aW1lcyBhbmQgcmV0dXJuIA0KCQkJCT4gcGF0 aHMgbm90IGF0IGFsbC4NCgkJCQk+IA0KCQkJCT4gVGhhbmtzLA0KCQkJCT4gDQoJCQkJPiBKb2hu DQoJCQkJPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJCQkJPiA+IEZyb206IEJVU0kg SVRBTE8gW21haWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0XQ0KCQkJCT4gPiBTZW50 OiBGcmlkYXksIEFwcmlsIDE3LCAyMDA5IDE6NTkgQU0NCgkJCQk+ID4gVG86IERyYWtlLCBKb2hu IEU7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFydGVuIFZpc3NlcnMNCgkJCQk+ID4gQ2M6IG1w bHMtdHBAaWV0Zi5vcmcNCgkJCQk+ID4gU3ViamVjdDogUkU6IFttcGxzLXRwXSBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQoJCQkJPiA+IHJlcXVpcmVtZW50cw0KCQkJ CT4gPiANCgkJCQk+ID4gSm9obiwNCgkJCQk+ID4gDQoJCQkJPiA+IEkgbWlnaHQgaGF2ZSBtaXNz ZWQgdGhlIGFncmVlbWVudCBvZiBNUExTLVRQIGJlaW5nIGNhcGFibGUgb2YgDQoJCQkJPiA+IHNl bmRpbmcgcmVwbGllcyB0byBPQU0gcmVxdWVzdHMgc2VudCBvbiB1bmktZGlyZWN0aW9uYWwgTFNQ cy4NCgkJCQk+ID4gDQoJCQkJPiA+IFRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3QgYmVsb25nIHRv IHRoZSBmaXJzdCBzZXQgb2YgcmVxdWlyZW1lbnRzIA0KCQkJCT4gPiBJVFUtVCBpcyBleHBlY3Rp bmcgdG8gYmUgbWV0IGJ5IE9jdG9iZXIuDQoJCQkJPiA+IA0KCQkJCT4gPiBIb3dldmVyLCBJIHRo aW5rIHRoaXMgaW4gYSBwb3RlbnRpYWwgaW50ZXJlc3RpbmcgYWRkaXRpb25hbCANCgkJCQk+ID4g cmVxdWlyZW1lbnQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IChhdCB3b3JzdCBpbiBhDQoJCQkJ PiBzdWJzZXF1ZW50IHBoYXNlKS4NCgkJCQk+ID4gDQoJCQkJPiA+IEkgdGhpbmsgdGhhdCB0aGlz IHJlcXVpcmVtZW50IG5lZWRzIHRvIGJlIGV2YWx1YXRlZCB2ZXJzdXMgb3RoZXIgDQoJCQkJPiA+ IG1vcmUgaW1wb3J0YW50IHJlcXVpcmVtZW50cyAoZS5nLiB0aGUgcG9zc2liaWxpdHkgdG8gd29y ayB3L28gSVAgDQoJCQkJPiA+IGZvcndhcmRpbmcgYW5kIHRoZSBuZWVkIGZvciBPQU0gdG8gY29u dGludWUgdG8gbW9uaXRvciB0aGUgZGF0YSANCgkJCQk+ID4gcGxhbmUgYWxzbyBpbiBjYXNlIG9m IGZhaWx1cmVzIGFmZmVjdGluZyB0aGUgY29udHJvbCBvciBtYW5hZ2VtZW50IA0KCQkJCT4gPiBw bGFuZSkuDQoJCQkJPiA+IA0KCQkJCT4gPiBJIGFtIG9wZW4gdG8gZGlzY3VzcyBpdCBidXQgbm90 IHN1cmUgdGhpcyBpcyB0aGUgcmlnaHQgdGltZSBiZWNhdXNlIA0KCQkJCT4gPiBJIHdpc2ggdG8g YXZvaWQgZGVsYXlpbmcgdGhlIGZpcnN0IHBoYXNlIG9mIHRoZSBkZXNpZ24gc29sdXRpb24uDQoJ CQkJPiA+IA0KCQkJCT4gPiBUaGFua3MsIEl0YWxvDQoJCQkJPiA+IA0KCQkJCT4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJCQkJPiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGll dGYub3JnDQoJCQkJPiA+ID4gW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBEcmFrZSwgSm9obiBFDQoJCQkJPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2 LCAyMDA5IDg6MDAgUE0NCgkJCQk+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IE1hYXJ0 ZW4gVmlzc2Vycw0KCQkJCT4gPiA+IENjOiBtcGxzLXRwQGlldGYub3JnDQoJCQkJPiA+ID4gU3Vi amVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggDQoJCQkJPiA+ID4gcmVxdWlyZW1lbnRzDQoJCQkJPiA+ID4gDQoJCQkJPiA+ID4gQXQgdGhl IG1lZXRpbmcgbGFzdCBmYWxsIGF0IEp1bmlwZXIgaW4gTWFzc2FjaHVzZXR0cywgSQ0KCQkJCT4g PiB0aGluayBpdCB3YXMNCgkJCQk+ID4gPiBhZ3JlZWQgdGhhdCBhbiBNUExTIFRQIG5ldHdvcmsg bmVlZHMgdG8gaGF2ZSBhIGZvcndhcmRpbmcNCgkJCQk+ID4gY2FwYWJpbGl0eQ0KCQkJCT4gPiA+ IGZvciBtYW5hZ2VtZW50LCBjb250cm9sLCBhbmQgT0FNIHBhY2tldHMgKGUuZy4sIHNlbmRpbmcN CgkJCQk+ID4gcmVwbGllcyB0byBPQU0NCgkJCQk+ID4gPiByZXF1ZXN0cyBzZW50IG9uIHVuaS1k aXJlY3Rpb25hbCBMU1BzKSBldmVuIGlmIGl0IGRvZXMgbm90DQoJCQkJPiA+IGhhdmUgYW4gSVAN CgkJCQk+ID4gPiBmb3J3YXJkaW5nIGRhdGEgcGxhbmUuDQoJCQkJPiA+ID4gDQoJCQkJPiA+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCQkJCT4gPiA+ID4gRnJvbTogQWxleGFuZGVy IFZhaW5zaHRlaW4NCgkJCQk+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tXQ0KCQkJCT4gPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDk6NTcg QU0NCgkJCQk+ID4gPiA+IFRvOiBNYWFydGVuIFZpc3NlcnMNCgkJCQk+ID4gPiA+IENjOiBtcGxz LXRwQGlldGYub3JnDQoJCQkJPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCANCgkJCQk+ID4gPiA+IHJlcXVpcmVtZW50 cw0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiBNYWFydGVuLA0KCQkJCT4gPiA+ID4gSXQgc2Vl bXMgdGhhdCB5b3UndmUganVzdCAoaW1wbGljaXRseSBhbmQsIHByb2JhYmx5LA0KCQkJCT4gPiA+ ID4gaW5hZHZlcnRlbnRseSkgc3RhdGVkIHRoZSBmb2xsb3dpbmc6DQoJCQkJPiA+ID4gPiANCgkJ CQk+ID4gPiA+ICAgICAgICAgICAgICAgICAgTVBMUy1UUCBPQU0gd2lsbCBub3QgZXZlciBzdXBw b3J0IE1JUCBsb29wYmFjayBmdW5jdGlvbg0KCQkJCT4gPiAoYW5kIGZhdWx0DQoJCQkJPiA+ID4g PiBsb2NhbGl6YXRpb24gd2hpY2ggcmVxdWlyZXMgdGhpcyBmdW5jdGlvbiApIGZvcg0KCQkJCT4g PiB1bmlkaXJlY3Rpb25hbCBQMk1QDQoJCQkJPiA+ID4gPiBhbmQgUDJQIHBhdGhzLg0KCQkJCT4g PiA+ID4gDQoJCQkJPiA+ID4gPiBJZiB0aGlzIHN0YXRlbWVudCBpcyBjb3JyZWN0LCB0aGlzIChJ TUhPIGFuZCBGV0lXKQ0KCQkJCT4gcmFpc2VzIGEgdmFsaWQNCgkJCQk+ID4gPiA+IHF1ZXN0aW9u Og0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiAgICAgICAgICAgICAgICAgIElzIE1QTFMtVFAg YW4gYXBwcm9wcmlhdGUgc29sdXRpb24gZm9yIHRoZXNlDQoJCQkJPiB0eXBlcyBvZiB0cmFuc3Bv cnQNCgkJCQk+ID4gPiA+IHBhdGhzPw0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiBGb3IgdGhl IHJlZmVyZW5jZSwgSVAvTVBMUyBwcm92aWRlcyB0aGlzIGtpbmQgb2YNCgkJCQk+ID4gZnVuY3Rp b25hbGl0eSB0b2RheQ0KCQkJCT4gPiA+ID4gZm9yICh1bmlkaXJlY3Rpb25hbCAtIGJ1dCBpdCBk b2VzIG5vdCBrbm93IGFueSBvdGhlcg0KCQkJCT4gPiB0eXBlKSBQMlAgTFNQcw0KCQkJCT4gPiA+ ID4gYXMgZGVzY3JpYmVkIGluIFJGQyA0Mzc5LiBBbmQgaXRzIGV4dGVuc2lvbiB0byBQMk1QIExT UHMgc2VlbXMgDQoJCQkJPiA+ID4gPiBlYXN5Li4uDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+ ICANCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gUmVnYXJkcywNCgkJCQk+ID4gPiA+IA0KCQkJ CT4gPiA+ID4gICAgICBTYXNoYQ0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4g PiA+IA0KCQkJCT4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KCQkJCT4gPiA+ID4gRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttcGxzLXRwLWJv dW5jZXNAaWV0Zi5vcmddDQoJCQkJPiA+IE9uIEJlaGFsZg0KCQkJCT4gPiA+ID4gT2YgTWFhcnRl biBWaXNzZXJzIFttYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbV0NCgkJCQk+ID4gPiA+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAzOjI0IFBNDQoJCQkJPiA+ID4gPiBUbzogJ0Fkcmlh biBGYXJyZWwnDQoJCQkJPiA+ID4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KCQkJCT4gPiA+ID4g U3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0 IHBhdGggDQoJCQkJPiA+ID4gPiByZXF1aXJlbWVudHMNCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ ID4gQWRyaWFuLA0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiA+PiA8cXVvdGU+DQoJCQkJPiA+ ID4gPiA+PiAgICAgIFRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1ZGluZyBNRVBzLCBNSVBz IGFuZA0KCQkJCT4gPiA+ID4gb3RoZXIgaW50ZXJuYWwNCgkJCQk+ID4gPiA+ID4+ICAgICAgIGZ1 bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkgb2YgYSBjby1yb3V0ZWQNCgkJCQk+ID4gPiA+IGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0DQoJCQkJPiA+ID4gPiA+PiAgICAgICBwYXRoIGF0IGVhY2ggKHN1 Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0aGUgcGFpcmluZw0KCQkJCT4gPiA+ID4gPj4gICAg ICAgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQNCgkJCQk+ID4g PiA+IGRpcmVjdGlvbnMgb2YgdGhhdA0KCQkJCT4gPiA+ID4gPj4gICAgICAgdHJhbnNwb3J0IHBh dGguDQoJCQkJPiA+ID4gPiA+PiA8ZW5kIHF1b3RlPg0KCQkJCT4gPiA+ID4gPg0KCQkJCT4gPiA+ ID4gPiBUaGVyZSBpcyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRo YXQNCgkJCQk+ID4gPiBpcywgdGhlcmUgaXMNCgkJCQk+ID4gPiA+ID4gKm5vdGhpbmcqIHRoYXQg Y2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCgkJCQk+ID4gPiB2aWV3 IHRoYXQNCgkJCQk+ID4gPiA+ID4gcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgcmVxdWly ZW1lbnQuDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IFlvdXIgdW5kZXJzdGFuZGluZyBpcyBu b3QgY29ycmVjdC4gSXQgaXMgdmVyeSBtdWNoDQoJCQkJPiBvYnNlcnZhYmxlIGlmDQoJCQkJPiA+ ID4gPiB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBmcm9tIGEgYmxhY2sgYm94IHBvaW50IG9mIHZp ZXcuDQoJCQkJPiA+ID4gPiBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJmb3JtIHRoZSBM b29wYmFjayB3aGVuIHRoZXJlIGlzIGEgDQoJCQkJPiA+ID4gPiBjby1yb3V0ZWQgYmlkaXJlY3Rp b25hbCB0cmFuc3BvcnQgcGF0aC4gVGhlIE1QTFMtVFAgTEJNIHBhY2tldCANCgkJCQk+ID4gPiA+ IHJlY2VpdmVkIGF0IGEgTUlQIG5lZWRzIHRvIGJlIHJldHVybmVkIChhcyBMQlINCgkJCQk+ID4g PiA+IHBhY2tldCkgdG8gdGhlIG9yaWdpbmF0aW5nIE1FUCBmdW5jdGlvbiB2aWEgdGhlIG90aGVy DQoJCQkJPiA+IGRpcmVjdGlvbiBvZg0KCQkJCT4gPiA+ID4gdGhlIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoLiBUaGlzIG90aGVyDQoJCQkJPiBkaXJlY3Rpb24NCgkJCQk+ ID4gPiA+IHdvdWxkIG5vdCBiZSBhdmFpbGFibGUgaW4gYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCANCgkJCQk+ID4gPiA+IHBhdGguLi4gYW5kIHRodXMgdGhlIGxvb3BiYWNr IHRlc3QNCgkJCQk+ID4gPiB3b3VsZCBmYWlsLg0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiBT aW1pbGFybHksIHdoZW4gd2UgaGF2ZSB0byBhcHBseSBUQ00gTUVQcyB0byBtb25pdG9yIGENCgkJ CQk+ID4gc2VnbWVudCwgdGhlbg0KCQkJCT4gPiA+ID4gdGhpcyBpcyBwb3NzaWJsZSBpbiBhIGNv LXJvdXRlZCBiaWRpciB0cmFuc3BvcnQgcGF0aA0KCQkJCT4gYnV0IG5vdCBpbiBhDQoJCQkJPiA+ ID4gPiBhc3NvY2lhdGVkIGJpZGlyIHRyYW5zcG9ydCBwYXRoLiBJbiB0aGUgZmlyc3QgY2FzZSB0 aGUgVENNIE1FUCANCgkJCQk+ID4gPiA+IFNvdXJjZSBhbmQgU2luayBmdW5jdGlvbnMgYXJlIGNv LWxvY2F0ZWQgYW5kIGNhbg0KCQkJCT4gZXhjaGFuZ2Ugd2hhdCBpcw0KCQkJCT4gPiA+ID4gY2Fs bGVkICJyZW1vdGUgaW5mb3JtYXRpb24iIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgcGVyZm9ybWFu Y2UgDQoJCQkJPiA+ID4gPiBtb25pdG9yaW5nLg0KCQkJCT4gPiA+ID4gSW4gdGhlIGxhdHRlciBj YXNlIHRoZSBUQ00gTUVQIFNvdXJjZSBhbmQgU2luayBmdW5jdGlvbnMNCgkJCQk+ID4gYXJlIGlu IGUuZy4gDQoJCQkJPiA+ID4gPiBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgYW5kIFRD TSB3b3VsZCBub3QgYmUgYWJsZQ0KCQkJCT4gPiB0byBwcm92aWRlDQoJCQkJPiA+ID4gPiBwZXJm b3JtYW5jZSBtb25pdG9yaW5nLg0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiA+IFRoZSBlbnRp cmV0eSBvZiB0aGUgYnJhY2tldHRlZCB0ZXh0ICIoaW5jbHVkaW5nIE1FUHMsDQoJCQkJPiA+ID4g TUlQcyBhbmQgb3RoZXINCgkJCQk+ID4gPiA+IGludGVybmFsDQoJCQkJPiA+ID4gPiA+IGZ1bmN0 aW9ucyBhcyBhcHByb3ByaWF0ZSkiIHNob3VsZCBiZSBkZWxldGVkLiBJdCBkb2VzIG5vdA0KCQkJ CT4gPiA+ID4gYWRkIHRvICJUaGUNCgkJCQk+ID4gPiA+ID4gaW50ZXJtZWRpYXRlIG5vZGVzLiIN CgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gWW91ciB1bmRlcnN0YW5kaW5nIGlzIG5vdCBjb3Jy ZWN0LiBUaGlzIHRleHQgbXVzdCBub3QgYmUNCgkJCQk+ID4gZGVsZXRlZCBhdA0KCQkJCT4gPiA+ ID4gYWxsLg0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiA+IEFjdHVhbGx5LCBJIGFtIHF1aXRl IGZlZCB1cCBhYm91dCB0aGlzIHBlcnNpc3RlbnQNCgkJCQk+ID4gPiBpbnNpc3RlbmNlIG9uIHRo ZQ0KCQkJCT4gPiA+ID4gaW5jbHVzaW9uDQoJCQkJPiA+ID4gPiA+IG9mICJUYW5kZW0gQ29ubmVj dGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbiB0aGUgSVRVLVQgb2YNCgkJCQk+ID4gPiA+IHRo aXMgdGVybQ0KCQkJCT4gPiA+ID4gPiBpcw0KCQkJCT4gPiA+ID4gcG9vcmx5DQoJCQkJPiA+ID4g PiA+IHNwZWNpZmllZCBhbmQgY29tZXMgZnJvbSB0aGUgbW9uaXRvcmluZyBvZiBhIHBhdGggdGhh dCBpcw0KCQkJCT4gPiA+ID4gcGFyYWxsZWwgKGkuZS4NCgkJCQk+ID4gPiA+IHRhbmRlbSkNCgkJ CQk+ID4gPiA+ID4gdG8gdGhlIGRhdGEgcGF0aCBiZWluZyBtb25pdG9yZWQuIFRoaXMgZGVmaW5p dGlvbiBvZiBUQw0KCQkJCT4gPiA+ID4gc2VlbXMgdG8gYmUgYXQNCgkJCQk+ID4gPiA+IHZhcmlh bmNlLA0KCQkJCT4gPiA+ID4gPiBhbmQgd291bGQgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkg aW4gYmFuZC4NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gSSBkb24ndCB1bmRlcnN0YW5kIHdo ZXJlIHlvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGFuZGVtDQoJCQkJPiA+IGNvbm5lY3Rpb24gaXMN CgkJCQk+ID4gPiA+IGRlc2NyaWJlZCBpbiBJVFUtVCByZWNvbW1lbmRhdGlvbnMuIEkuZS4gImZy b20gdGhlDQoJCQkJPiA+IG1vbml0b3Jpbmcgb2YgYQ0KCQkJCT4gPiA+ID4gcGF0aCB0aGF0IGlz IHBhcmFsbGVsIChpLmUuIHRhbmRlbSkgdG8gdGhlIGRhdGEgcGF0aCBiZWluZyANCgkJCQk+ID4g PiA+IG1vbml0b3JlZC4iPw0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiBUaGVyZSBpcyBhICJu ZXR3b3JrIGNvbm5lY3Rpb24iIGFuZCB0aGlzIG5ldHdvcmsNCgkJCQk+ID4gY29ubmVjdGlvbiBp cyBhIHNldA0KCQkJCT4gPiA+ID4gb2YgaW50ZXJjb25uZWN0ZWQgImxpbmsgY29ubmVjdGlvbnMi IGFuZCAibWF0cml4DQoJCQkJPiBjb25uZWN0aW9ucyIuIEENCgkJCQk+ID4gPiA+IHN1YnNldCBv ZiB0aG9zZSBpbnRlcmNvbm5lY3RlZCBsaW5rIGNvbm5lY3Rpb25zIGFuZCBtYXRyaXggDQoJCQkJ PiA+ID4gPiBjb25uZWN0aW9ucyBjYW4gYmUgbW9uaXRvcmVkIGFuZCBpcyB0aGVuIHJlZmVycmVk IHRvIGFzDQoJCQkJPiBhICJ0YW5kZW0NCgkJCQk+ID4gPiA+IGNvbm5lY3Rpb24iLiBUaGVyZSBp cyBubyAicGF0aCB0aGF0IGlzIHBhcmFsbGVsIHRvIHRoZQ0KCQkJCT4gPiBkYXRhIHBhdGgiLiAN CgkJCQk+ID4gPiA+IFRoZXJlIGlzIG9ubHkgYWRkaXRpb25hbCBPQU0gaW5zZXJ0ZWQgaW5zaWRl IHRoZSBkYXRhDQoJCQkJPiBwYXRoIGJ5IHRoZQ0KCQkJCT4gPiA+ID4gVENNIE1FUF9TbyBmdW5j dGlvbiBhbmQgdGhpcyBPQU0gaXMgZXh0cmFjdGVkIGZyb20gdGhlDQoJCQkJPiA+IGRhdGEgcGF0 aCBieQ0KCQkJCT4gPiA+ID4gdGhlIFRDTSBNRVBfU2sgZnVuY3Rpb24uDQoJCQkJPiA+ID4gPiAN CgkJCQk+ID4gPiA+IFJlZ2FyZHMsDQoJCQkJPiA+ID4gPiBNYWFydGVuDQoJCQkJPiA+ID4gPiAN CgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJ CQk+ID4gPiA+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KCQkJCT4gPiA+ID4gW21h aWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVs DQoJCQkJPiA+ID4gPiBTZW50OiBkb25kZXJkYWcgMTYgYXByaWwgMjAwOSAxMTo1OQ0KCQkJCT4g PiA+ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0 LmNvbQ0KCQkJCT4gPiA+ID4gQ2M6IEJVU0kgSVRBTE87IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCQk+ ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoIA0KCQkJCT4gPiA+ID4gcmVxdWlyZW1lbnRzDQoJCQkJPiA+ID4gPiANCgkJ CQk+ID4gPiA+IEhpIFNhc2hhLA0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiA+IFVuZm9ydHVu YXRlbHkgSSBjYW5ub3QgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudDoNCgkJCQk+ID4g PiA+ID4NCgkJCQk+ID4gPiA+ID4gPHF1b3RlPg0KCQkJCT4gPiA+ID4gPiAgICAgRnJvbSB0aGUg cG9pbnQgb2YgdmlldyBvZiBoYXJkd2FyZSwgY28tcm91dGVkDQoJCQkJPiA+ID4gYmlkaXJlY3Rp b25hbCBMU1BzDQoJCQkJPiA+ID4gPiA+ICAgICBhcmUgYSBzcGVjaWFsIGNhc2Ugb2YgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIExTUHMuDQoJCQkJPiA+ID4gPiA+IDxlbmQgcXVvdGU+DQoJCQkJ PiA+ID4gPiA+DQoJCQkJPiA+ID4gPiA+IFRoaXMgc3RhdGVtZW50IHdvdWxkIGJlIG9idmlvdXNs eSBjb3JyZWN0LCB3ZXJlIGl0IG5vdCBmb3INCgkJCQk+ID4gPiA+IFJlcXVpcmVtZW50DQoJCQkJ PiA+ID4gPiA+IDM0IGluIHRoZSBsYXRlc3QgTVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQNCgkJ CQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gT0suIEdvdCBpdC4NCgkJCQk+ID4gPiA+IA0KCQkJCT4g PiA+ID4gQnV0IHdoYXQgaXMgdGhpcyBkb2luZyBpbiB0aGUgZGF0YSBwbGFuZSByZXF1aXJlbWVu dHMgc2VjdGlvbj8NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gSW4gZmFjdCwgd2hhdCBpcyB0 aGlzIHJlcXVpcmVtZW50IGFjdHVhbGx5IHNheWluZz8NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ ID4gPiA8cXVvdGU+DQoJCQkJPiA+ID4gPiA+ICAgICAgVGhlIGludGVybWVkaWF0ZSBub2RlcyAo aW5jbHVkaW5nIE1FUHMsIE1JUHMgYW5kDQoJCQkJPiA+ID4gb3RoZXIgaW50ZXJuYWwNCgkJCQk+ ID4gPiA+ID4gICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNvLXJvdXRlZA0K CQkJCT4gPiA+ID4gYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCgkJCQk+ID4gPiA+ID4gICAgICAg cGF0aCBhdCBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmcNCgkJ CQk+ID4gPiA+ID4gICAgICAgcmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFj a3dhcmQNCgkJCQk+ID4gPiA+IGRpcmVjdGlvbnMgb2YgdGhhdA0KCQkJCT4gPiA+ID4gPiAgICAg ICB0cmFuc3BvcnQgcGF0aC4NCgkJCQk+ID4gPiA+ID4gPGVuZCBxdW90ZT4NCgkJCQk+ID4gPiA+ IA0KCQkJCT4gPiA+ID4gVGhlcmUgaXMgbm8gd2F5IHRoaXMgaXMgYSBmdW5jdGlvbmFsIHJlcXVp cmVtZW50LiBUaGF0DQoJCQkJPiA+IGlzLCB0aGVyZSBpcw0KCQkJCT4gPiA+ID4gKm5vdGhpbmcq IHRoYXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2YNCgkJCQk+ID4g dmlldyB0aGF0DQoJCQkJPiA+ID4gPiByZXN1bHRzIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1 aXJlbWVudC4NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gVGhlcmVmb3JlIGl0IGNvdWxkIGJl IGFzc3VtZWQgdGhhdCB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBieSANCgkJCQk+ID4gPiA+IGNv bmZpZ3VyaW5nIHNvbWUgZGF0YSBwbGFuZSBkYXRhYmFzZSBjb21wb25lbnQgdGhyb3VnaCB0aGUg DQoJCQkJPiA+ID4gPiBtYW5hZ2VtZW50IHBsYW5lLiBUaGUgZGF0YWJhc2UgY29tcG9uZW50IGlz IG5vdCB1c2VkDQoJCQkJPiBmb3IgYW55dGhpbmcNCgkJCQk+ID4gPiA+IGV4Y2VwdCB0byBzYXRp c2Z5IHRoaXMgcmVxdWlyZW1lbnQgZm9yICJhd2FyZW5lc3MiLg0KCQkJCT4gPiA+ID4gDQoJCQkJ PiA+ID4gPiBCZW4hIENhbiB3ZSBwbGVhc2UgdHJ5IHRvIHJld3JpdGUgdGhpcyByZXF1aXJlbWVu dCBpbiB0ZXJtcyBvZiANCgkJCQk+ID4gPiA+IGJlaGF2aW9yPw0KCQkJCT4gPiA+ID4gDQoJCQkJ PiA+ID4gPiA+IFBsZWFzZSBub3RlIHRoYXQgUmVxdWlyZW1lbnQgMzQgaXMgdGhlIE9OTFkgaXRl bSBpbiB0aGUNCgkJCQk+ID4gPiA+IGxpc3QgdGhhdCBpcw0KCQkJCT4gPiA+ID4gPiBzcGVjaWZp YyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4gKFRoZSBwYWlyaW5nDQoJCQkJPiA+ ID4gPiByZXF1aXJlbWVudHMNCgkJCQk+ID4gPiA+ID4gYXQgZW5kIHBvaW50cyBmb3IgY28tcm91 dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCgkJCQk+ID4gPiBwYXRocyBhcmUNCgkJ CQk+ID4gPiA+ID4gZXhhY3RseSB0aGUgc2FtZSBldmVuIGlmIHRoZXkgYXBwZWFyIGluIHR3byBk aWZmZXJlbnQNCgkJCQk+ID4gPiBpdGVtcyBpbiB0aGUNCgkJCQk+ID4gPiA+ID4gcmVxdWlyZW1l bnRzJyBsaXN0KS4NCgkJCQk+ID4gPiA+ID4gSW4gb3RoZXIgd29yZHMsIHdpdGhvdXQgUmVxdWly ZW1lbnQgMzQgdGhlIG5vdGlvbiBvZg0KCQkJCT4gY28tcm91dGVkDQoJCQkJPiA+ID4gPiA+IGJp ZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBvZiBhbnkgZGF0YSBwbGFuZSBjb250ZW50 Lg0KCQkJCT4gPiA+ID4gPg0KCQkJCT4gPiA+ID4gPiBUaGUgc29tZXdoYXQgdmFndWUgc2NvcGUg b2YgdGhpcyByZXF1aXJlbWVudCAoIm90aGVyIGludGVybmFsIA0KCQkJCT4gPiA+ID4gPiBmdW5j dGlvbnMgYXMgYXBwcm9wcmlhdGUiKSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgSFcNCgkJCQk+ ID4gPiA+IHN1cHBvcnQgb2YgdGhlDQoJCQkJPiA+ID4gPiA+IHBhaXJpbmcgYXdhcmVuZXNzIG1h eSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBjb21wbHkgd2l0aCBpdC4NCgkJCQk+ID4gPiA+IA0K CQkJCT4gPiA+ID4gVGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQgIihpbmNsdWRp bmcgTUVQcywNCgkJCQk+ID4gTUlQcyBhbmQgb3RoZXINCgkJCQk+ID4gPiA+IGludGVybmFsIGZ1 bmN0aW9ucyBhcyBhcHByb3ByaWF0ZSkiIHNob3VsZCBiZSBkZWxldGVkLiBJdA0KCQkJCT4gPiBk b2VzIG5vdA0KCQkJCT4gPiA+ID4gYWRkIHRvICJUaGUgaW50ZXJtZWRpYXRlIG5vZGVzLiINCgkJ CQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gPiBUaGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIGRyYWZ0 IGluY3JlYXNlcyB0aGlzIHN1c3BpY2lvbjoNCgkJCQk+ID4gPiA+ID4NCgkJCQk+ID4gPiA+ID4g PHF1b3RlPg0KCQkJCT4gPiA+ID4gPiAgIFRhbmRlbSBDb25uZWN0aW9uOiBBIHRhbmRlbSBjb25u ZWN0aW9uIGlzIGFuDQoJCQkJPiA+IGFyYml0cmFyeSBwYXJ0IG9mIGENCgkJCQk+ID4gPiA+ID4g ICB0cmFuc3BvcnQgcGF0aCB0aGF0IGNhbiBiZSBtb25pdG9yZWQgKHZpYSBPQU0pDQoJCQkJPiA+ ID4gPiBpbmRlcGVuZGVudGx5IGZyb20gdGhlDQoJCQkJPiA+ID4gPiA+ICAgZW5kLXRvLWVuZCBt b25pdG9yaW5nIChPQU0pLiAgSXQgbWF5IGJlIGEgbW9uaXRvcmVkDQoJCQkJPiA+IHNlZ21lbnQg b3IgYQ0KCQkJCT4gPiA+ID4gPiAgIG1vbml0b3JlZCBjb25jYXRlbmF0ZWQgc2VnbWVudCBvZiBh IHRyYW5zcG9ydCBwYXRoLiAgDQoJCQkJPiA+IFRoZSB0YW5kZW0NCgkJCQk+ID4gPiA+ID4gICBj b25uZWN0aW9uIG1heSBhbHNvIGluY2x1ZGUgdGhlIGZvcndhcmRpbmcgZW5naW5lKHMpIG9mDQoJ CQkJPiA+ID4gPiB0aGUgbm9kZShzKQ0KCQkJCT4gPiA+ID4gPiAgIGF0IHRoZSBlZGdlKHMpIG9m IHRoZSBzZWdtZW50IG9yIGNvbmNhdGVuYXRlZCBzZWdtZW50Lg0KCQkJCT4gPiA+ID4gPiA8ZW5k IHF1b3RlPg0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiBBY3R1YWxseSwgSSBhbSBxdWl0ZSBm ZWQgdXAgYWJvdXQgdGhpcyBwZXJzaXN0ZW50DQoJCQkJPiA+IGluc2lzdGVuY2Ugb24gdGhlDQoJ CQkJPiA+ID4gPiBpbmNsdXNpb24gb2YgIlRhbmRlbSBDb25uZWN0aW9uLiIgVGhlIGRlZmluaXRp b24gd2l0aGluDQoJCQkJPiA+IHRoZSBJVFUtVCBvZg0KCQkJCT4gPiA+ID4gdGhpcyB0ZXJtIGlz IHBvb3JseSBzcGVjaWZpZWQgYW5kIGNvbWVzIGZyb20gdGhlDQoJCQkJPiBtb25pdG9yaW5nIG9m IGENCgkJCQk+ID4gPiA+IHBhdGggdGhhdCBpcyBwYXJhbGxlbCAoaS5lLiB0YW5kZW0pIHRvIHRo ZSBkYXRhIHBhdGggYmVpbmcgDQoJCQkJPiA+ID4gPiBtb25pdG9yZWQuIFRoaXMgZGVmaW5pdGlv biBvZiBUQyBzZWVtcyB0byBiZSBhdCB2YXJpYW5jZSwNCgkJCQk+ID4gYW5kIHdvdWxkDQoJCQkJ PiA+ID4gPiBiZSBpZiB0aGUgQUNIIHdhcyBhY3R1YWxseSBpbiBiYW5kLg0KCQkJCT4gPiA+ID4g DQoJCQkJPiA+ID4gPiA+IERvZXNuJ3QgImZvcndhcmRpbmcgZW5naW5lIiBzb3VuZCBsaWtlIGhh cmR3YXJlIHRvIHlvdT8NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gWWVzLCBidXQgc28gd2hh dD8NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gPiBJTUhPIGl0IGlzIHdvcnRoIG5vdGluZyB0 aGF0IG5laXRoZXIgdGhlIE1QTFMtVFANCgkJCQk+ID4gPiBSZXF1aXJlbWVudHMgZHJhZnQNCgkJ CQk+ID4gPiA+ID4gbm9yIHRoZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgb25lDQoJCQkJPiA+ ID4gPiA+IA0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gDQoJCQkJPiA+IA0KCQkJCT4gKGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVx dWlyZW1lbg0KCQkJCT4gPiA+ID4gPiB0cy0wMS50eHQpIGNvbnRhaW4gYW55IHJlcXVpcmVtZW50 cyBkZWFsaW5nIHdpdGggdGFuZGVtDQoJCQkJPiA+ID4gY29ubmVjdGlvbnMuDQoJCQkJPiA+ID4g PiA+DQoJCQkJPiA+ID4gPiA+IEJ1dCB0YW5kZW0gY29ubmVjdGlvbnMgYXJlIGRpc2N1c3NlZCBp biB0aGUgTVBMUy1UUCBPQU0NCgkJCQk+ID4gRnJhbWV3b3JrDQoJCQkJPiA+ID4gPiA+IGRyYWZ0 DQoJCQkJPiA+ID4gPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1tcGxzLXRwLW9hbS1mcg0KCQkJCT4gPiA+ID4gYW1ld29yay0wMC50eHQNCgkJCQk+ID4g PiA+ICkuDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IFJpZ2h0Lg0KCQkJCT4gPiA+ID4gTGV0 J3MganVzdCBnZXQgcmlkIG9mIGFuIHVubmVjZXNzYXJ5IHRlcm0gYW5kIGJyaW5nIGFsbA0KCQkJ CT4gdGhlIEktRHMNCgkJCQk+ID4gPiA+IGludG8gbGluZS4NCgkJCQk+ID4gPiA+IA0KCQkJCT4g PiA+ID4gPiBUaGUgYm90dG9tIGxpbmUsIElNSE8sIGlzIHRoYXQgc29tZSBjbGFyaXR5IHJlZ2Fy ZGluZw0KCQkJCT4gPiA+IGNvLXJvdXRlZCB2cy4NCgkJCQk+ID4gPiA+ID4gYXNzb2NpYXRlZA0K CQkJCT4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHBhdGhzIGlzIHN0aWxsIHJlcXVpcmVkLiBPbmUg d2F5IHRvIHByb3ZpZGUNCgkJCQk+ID4gPiA+IHRoYXQgY291bGQNCgkJCQk+ID4gPiA+ID4gYmUg YnkgZXhwbGljaXRseSBsaW1pdGluZyBSZXF1aXJlbWVudCAzNCB0byBzcGVjaWZpYw0KCQkJCT4g PiA+IGZ1bmN0aW9uYWxpdHkuDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IEFncmVlZC4NCgkJ CQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gQWRyaWFuDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+ IA0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCgkJCQk+ID4gPiA+IEZyb206IEFkcmlhbiBGYXJy ZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdDQoJCQkJPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgQXBy aWwgMTYsIDIwMDkgMTI6MTMgQU0NCgkJCQk+ID4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVp bjsgTG91IEJlcmdlcjsgQlVTSSBJVEFMTw0KCQkJCT4gPiA+ID4gQ2M6IG1wbHMtdHBAaWV0Zi5v cmcNCgkJCQk+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0KCQkJCT4gPiA+ID4gcmVxdWlyZW1lbnRzDQoJCQkJPiA+ ID4gPiANCgkJCQk+ID4gPiA+IEhpIFNhc2hhLA0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiBO b3QgcmVhbGx5IHN1cmUgd2hldGhlciB5b3UgYXJlIG1pc3JlcHJlc2VudGluZyBhbnlvbmUsIGJ1 dC4uLg0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiA+IDEuIE15IHJlYWRpbmcgb2YgIG9uZSBv ZiBCZW4ncyAgbWVzc2FnZXMgaXMgdGhhdCBhc3NvY2lhdGVkIA0KCQkJCT4gPiA+ID4gPiBiaWRp cmVjdGlvbmFsIHBhdGhzIGFyZSB0aGUgb25seSB0eXBlcyBvZiBwYXRocyB0aGF0IGNhbiBiZQ0K CQkJCT4gPiA+ID4gY3JlYXRlZCBpbg0KCQkJCT4gPiA+ID4gPiB0aGUgZXhpc3RpbmcgbmV0d29y a3M7ICJ0cnVlIiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRocw0KCQkJCT4gPiA+ID4gd2ls bCBoYXZlDQoJCQkJPiA+ID4gPiA+IHRvIHdhaXQgdW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1l bnQgYmVjb21lcyBhdmFpbGFibGUuDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IFRoaXMgaXMg Y2xlYXJseSBub25zZW5zZSENCgkJCQk+ID4gPiA+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2Yg aGFyZHdhcmUsIGNvLXJvdXRlZA0KCQkJCT4gPiBiaWRpcmVjdGlvbmFsIExTUHMgYXJlDQoJCQkJ PiA+ID4gPiBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4N CgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gSWYgeW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVj dGlvbmFsIExTUHMgKGUuZy4gdXNpbmcgdGhlDQoJCQkJPiA+IG1hbmFnZW1lbnQNCgkJCQk+ID4g PiA+IHBsYW5lKSB5b3UgY2FuIHN1cmVseSBzZXQgdXAgYSBjby1yb3V0ZWQNCgkJCQk+ID4gPiBi aWRpcmVjdGlvbmFsIExTUC4NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gVGhlcmUgYXJlIHNo aXBwaW5nIHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkDQoJCQkJPiBiaWRpcmVjdGlv bmFsDQoJCQkJPiA+ID4gPiBMU1BzIHVzaW5nIHRoZSBjb250cm9sIHBsYW5lLiBUaGVzZSBlaXRo ZXIgdXNlIHRoZSBHTVBMUw0KCQkJCT4gPiAod2hpY2ggaXMNCgkJCQk+ID4gPiA+IGNsZWFuZXIp IG9yIG5vbi1zdGFuZGFyZCBwcm9wcmlldGFyeSBzb2x1dGlvbnMgKHdoaWNoIGlzDQoJCQkJPiA+ IG1lc3N5IGJ1dA0KCQkJCT4gPiA+ID4gZnVuY3Rpb25hbCkuDQoJCQkJPiA+ID4gPiANCgkJCQk+ ID4gPiA+IEJ1dCAob2YgY291cnNlKSB0aGUgbWFuYWdlbWVudCBwbGFuZSBvciBjb250cm9sIHBs YW5lDQoJCQkJPiA+IHNvbHV0aW9ucyBoYXZlDQoJCQkJPiA+ID4gPiBub3RoaW5nIHRvIGRvIHdp dGggYXZhaWxhYmlsaXR5IG9mIGVxdWlwbWVudCBhcyB0aGV5IA0KCQkJCT4gYXJlIHNvZnR3YXJl DQoJCQkJPiA+ID4gPiBzb2x1dGlvbnMuDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+ID4gMi4g TXkgcmVhZGluZyBvZiBvbmUgb2YgTmVpbCdzIG1lc3NhZ2VzIGlzIHRoYXQgdGhlIGFjdHVhbA0K CQkJCT4gPiA+ID4gZHJpdmVyIGZvcg0KCQkJCT4gPiA+ID4gPiBjby1yb3V0ZWQgYmlkaXJlY3Rp b25hbCBwYXRocyBtYXkgYmUgZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIA0KCQkJCT4gPiA+ID4g PiB0cmFuc3BvcnQgbmV0d29ya3MgcmF0aGVyIHRoYW4gYW55IHNwZWNpZmljIGJlbmVmaXQuDQoJ CQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IElzbid0IHRoYXQgdGhlIGNhc2Ugd2l0aCA3NSUgb2Yg dGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPw0KCQkJCT4gPiA+ID4gV2hpY2ggaXMgbm90IHRvIHNh eSBpdCBpcyBhIGJhZCB0aGluZy4NCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gQSBsYXJnZSBk cml2ZXIgZm9yIE1QTFMtVFAgaXMgdG8gZ2l2ZSB0aGUgcGFja2V0IG5ldHdvcmsNCgkJCQk+ID4g dGhlIGxvb2ssDQoJCQkJPiA+ID4gPiBmZWVsLCBhbmQgYmVoYXZpb3JhbCBjaGFyYWN0ZXJpc3Rp Y3Mgb2YgYSAibGVnYWN5Ig0KCQkJCT4gPiA+ID4gdHJhbnNwb3J0IG5ldHdvcmsuDQoJCQkJPiA+ ID4gPiANCgkJCQk+ID4gPiA+ID4gQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vl c3MgKEZXSVcpIHRoYXQ6DQoJCQkJPiA+ID4gPiA+ICogYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IHBhdGhzIGFyZSwgYXQgbGVhc3QgZm9yIHRoZSB0aW1lDQoJCQkJPiA+ID4gPiA+ICAgIGJlaW5n LCB0aGUgbW9zdCBpbXBvcnRhbnQgdHlwZSBvZiBiaWRpcmVjdGlvbmFsIHBhdGhzIGluDQoJCQkJ PiA+ID4gPiA+ICAgIE1QTFMtVFANCgkJCQk+ID4gPiA+IA0KCQkJCT4gPiA+ID4gSSB0aGluayB0 aGF0IGlzIHdyb25nIGJvdGggZ2l2ZW4gbXkgc3RhdGVtZW50IGFib3ZlLCBhbmQNCgkJCQk+ID4g Z2l2ZW4gdGhhdA0KCQkJCT4gPiA+ID4gb3RoZXIgdXBncmFkZXMgdG8gZXhpc3RpbmcgTVBMUyBz b2x1dGlvbnMgd2lsbCBiZQ0KCQkJCT4gbmVlZGVkIHRvIHJlYWNoDQoJCQkJPiA+ID4gPiB0aGUg ZnVsbCBmdW5jdGlvbiBsZXZlbCBvZiBNUExTLVRQLg0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4g PiA+ICogdGhleSBoYWQgYSBnb29kIGNoYW5jZSB0byByZW1haW4gdGhlIG9ubHkgdHlwZSBvZg0K CQkJCT4gPiBiaWRpcmVjdGlvbmFsDQoJCQkJPiA+ID4gPiA+ICAgcGF0aHMgaW4gIHJlYWwgZGVw bG95bWVudHMuDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IEkgZG9uJ3Qgc2VlIHdoYXQgdGhh dCBmb2xsb3dzIGZyb20uDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiA+IENoZWVycywNCgkJCQk+ ID4gPiA+IEFkcmlhbg0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCQkJCT4gPiA+ID4gbXBscy10cCBtYWls aW5nIGxpc3QNCgkJCQk+ID4gPiA+IG1wbHMtdHBAaWV0Zi5vcmcNCgkJCQk+ID4gPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQkJCT4gPiA+ID4gDQoJ CQkJPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KCQkJCT4gPiA+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCgkJCQk+ID4gPiA+IG1wbHMtdHBA aWV0Zi5vcmcNCgkJCQk+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscy10cA0KCQkJCT4gPiA+ID4gDQoJCQkJPiA+ID4gPiANCgkJCQk+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCQkJCT4gPiA+IG1wbHMt dHAgbWFpbGluZyBsaXN0DQoJCQkJPiA+ID4gbXBscy10cEBpZXRmLm9yZw0KCQkJCT4gPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQkJCT4gPiA+IA0K CQkJCT4gPiANCgkJCQk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoJCQkJPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KCQkJCT4gbXBscy10cEBpZXRmLm9y Zw0KCQkJCT4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoJ CQkJPiANCgkJCQlfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KCQkJCW1wbHMtdHAgbWFpbGluZyBsaXN0DQoJCQkJbXBscy10cEBpZXRmLm9yZw0KCQkJCWh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQkJCQ0KCQkJCQ0K CQkJCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoJCQkJWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNv bW11bmljYXRpb24gdG8gb3RoZXJzLg0KCQkJCVRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCgkJCQlU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS4NCgkJCQkNCgkJCQkNCgkJCQkNCgkJCQktLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCQkJCVpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NCgkJCQlUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJCQkJVGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQoN Cg== ------_=_NextPart_001_01C9C72D.B4DE7D38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDUxNjU3MTAtMjcwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5XaGF0IGEgZ29vZCBhbmFseXNp cyBBbmR5LiZuYnNwOyBUaGlzIA0Kb24gaXRzIG93biBzaG91bGQgYmUgY29tcGVsbGluZyBlbm91 Z2ggdG8gbWFrZSBpdCBjbGVhciB0aGF0IHdlIGNhbid0IHNpbXBseSANCnRha2UgRkRJL0FJUyBm cm9tJm5ic3A7aXRzIFBESC9TREggY28tY3MgVERNIG9yaWdpbnMgYW5kIGJsaW5kbHkgYXBwbHkg aXQgdG8gDQpwYWNrZXQtc3dpdGNoZWQgbmV0d29ya3MuJm5ic3A7IEJ1dCBmb3IgYW55b25lIHN0 aWxsIG5vdCBjb252aW5jZWQgaGVyZSBhcmUgc29tZSANCmZ1cnRoZXIgcmVhc29ucyB3aHkgQUlT IChhbmQgVENNKSBtYWtlIG5vIHNlbnNlLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDUxNjU3MTAtMjcwNDIwMDk+PC9TUEFOPiZuYnNw OzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQ1MTY1NzEwLTI3 MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+ SWYgb25lIHdhbnRzIHRvIGluamVjdCBhbiBBSVMgc2lnbmFsIA0KaW50byBhIGNsaWVudCBmcm9t IGEgc2VydmVyIG9uZSZuYnNwOyptdXN0KiBoYXZlIGEgcGVybWFuZW50IGJpbmRpbmcgb2YgDQpz ZXJ2ZXJfcGF0aCZsdDs9Jmd0O2NsaWVudF9saW5rX2Nvbm5lY3Rpb24uJm5ic3A7IElmIHlvdSBk b24ndCBoYXZlIHRoaXMgdGhlbiANCnRoZXJlIGlzIG5vIG9uZSB0byBzZW5kIHRoZSBBSVMgdG8h Jm5ic3A7IFNvLCBpbiBhbnkgY2FzZXMgd2hlcmUgdGhlIGNsaWVudCANCmxheWVyIG5ldHdvcmsg Y2FuIGR5bmFtaWNhbGx5IGNoYW5nZSBpdHMgcm91dGluZyAoaWUgdG8gc2VsZWN0IGRpZmZlcmVu dCBzZXJ2ZXJzIA0KZm9yIGVhY2ggb2YgaXRzIGxpbmsgY29ubmVjdGlvbnMpIHRoZW4gaXQgaXMg YSBwb2ludGxlc3MgZXhlcmNpc2UgYXR0ZW1wdGluZyB0byANCnNlbmQgQUlTIHRvIHRoZSBjbGll bnQuLi5hcyB0aGUgY2xpZW50IGhhcyAnbW92ZWQgc29tZXdoZXJlIA0KZWxzZScuPC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0NTE2NTcx MC0yNzA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz05NDUxNjU3MTAtMjcwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1T IiBjb2xvcj0jODAwMDAwIHNpemU9Mj5DbC1wcyBuZXR3b3JrcyBsaWtlIElQIGFyZSBvYnZpb3Vz bHkgDQpsaWtlIHRoaXMsIGFuZCBpbiB0aGUgbGltaXQgdGhlIGNsaWVudCZsdDs9Jmd0O3NlcnZl ciBiaW5kaW5nIGNhbiBjaGFuZ2UgZm9yIA0KZWFjaCBwYWNrZXQgb2YgdGhlIElQIGNsaWVudCwg aWUgbmV3IElHUCByb3V0ZS4mbmJzcDsgVGhlIGNvLWNzIFBTVE4gaXMgYWxzbyANCmxpa2UgdGhp cyBiZWNhdXNlIGl0IGlzIGJhc2VkIG9uIFNWQ3MuJm5ic3A7IEFuZCBoZXJlIGlmIG9uZSBnZXRz IGEgc2VydmVyIGxheWVyIA0KZmFpbHVyZSB0aGUgY2xpZW50IGNhbGxzIGdldCBjbGVhcmVkIGRv d24gYW5kIHJlLWVzdGFibGlzaGVkIHZpYSBvdGhlciBzZXJ2ZXJzIA0KdGhhbiB0aGUgb25lIHRo YXQgaGFzIGZhaWxlZC4mbmJzcDsgU28gd2hvIGlzIHRoZSBicm9rZW4gc2VydmVyIGdvaW5nIHRv IHNlbmQgDQpBSVMgdG8gbm93PzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz05NDUxNjU3MTAtMjcwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21p YyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQ1MTY1NzEwLTI3MDQyMDA5 PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+TW92aW5n IG9uIHRvIGNvbnNpZGVyIFRDTSwgd2hhdCB0aGlzIA0KaXMgZG9pbmcgaXMgY3JlYXRpbmcgYW4g YXJ0aWZpY2lhbCBjbGllbnQvc2VydmVyIHN1YmxheWVyIGhpZXJhcmNoeS4mbmJzcDsgQW5kIA0K YXMgbm90ZWQgYWJvdmUsIGZvciBhIGxvd2VyIFRDTSBsZXZlbCB0byBtZWFuaW5nZnVsbHkgaW5q ZWN0IEFJUyB0b3dhcmRzIGEgDQpoaWdoZXIgVENNIGxldmVsIHRoZSBUQ00gY2xpZW50L3NlcnZl ciBiaW5kaW5ncyBtdXN0IGJlIHBlcm1hbmVudC4mbmJzcDsgQnV0IA0KdGhpcyBpcyByYXRoZXIg c2lsbHkgYmVjYXVzZSBpdCBpcyAqbm90KiB0aGUgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFRD TSBsZXZlbHMgDQp0aGF0IGl0IGtleSBidXQgdGhlICpyZWFsIHRyYWZmaWMgcmVsYXRpb25zaGlw cyBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSANCnNlcnZlciouLi4uLmluIG90aGVyIHdvcmRz IHdlICptdXN0KiBiZSBhYmxlIHRvIHJlLXJvdXRlIHJlYWwgY2xpZW50IHRyYWZmaWMgDQphcm91 bmQgc2VydmVyIGxheWVyIGZhaWx1cmVzIChhbmQgdGhpcyBpbmNsdWRlcyBkeW5hbWljIHJlc3Rv cmF0aW9uLCBub3Qgc2ltcGx5IA0KcHJlLWNvbmZpZ3VyZWQgcHJvdGVjdGlvbiBwYXRocykuJm5i c3A7IDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz05NDUxNjU3MTAtMjcwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQ1MTY1NzEwLTI3MDQyMDA5PjxGT05UIA0KZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+Tm90ZSB0aGF0IHRoZSBvbmx5IHdh eSBvbmUgY291bGQga2VlcCANCnRoZSBleGlzdGluZyBUQ00gaGllcmFyY2h5IHZhbGlkIGFjcm9z cyBmYWlsdXJlcyByZWxhdGl2ZSB0byB0aGUgY2xpZW50IHRyYWZmaWMgDQpyb3V0aW5nIHdvdWxk IGJlIHRvIGNyZWF0ZSBwaW5jaC1wb2ludHMgYXQgdGhlIFRDTSBsZXZlbHMgYW5kIGZvcmNlIHRo ZSBjbGllbnQgDQp0cmFmZmljIHRvIGFsd2F5cyB1c2UgdGhlc2UuJm5ic3A7IEJ1dCBub3cgb2Yg Y291cnNlIG9uZSB3b3VsZCBiZSByZWR1Y2luZyB0aGUgDQphdmFpbGFiaWxpdHkgcG90ZW50aWFs IG9mIHRoZSBuZXR3b3JrLi4uc28gdGhpcyBpcyBub3QgYSBzbWFydCBpZGVhIGF0IA0KYWxsLjwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05 NDUxNjU3MTAtMjcwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAw MDAwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9OTQ1MTY1NzEwLTI3MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMg U2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+VGhlIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRv IG1vdmUgdGhlIA0KVENNIGxldmVscyBpbiBhY2NvcmRhbmNlIHRvIHdoZXJlIHRoZSByZWFsIHRy YWZmaWMgaGFkIG1vdmVkIHRvIHRvIGVmZmVjdCANCnJlc3RvcmF0aW9uLiZuYnNwOyBTbyB0aGUg ZHluYW1pYyBhY3QvZGVhY3QgY29uZmlndXJhdGlvbiBvZiBUQ00gbGV2ZWxzIHdvdWxkIA0KaGF2 ZSB0byBiZSBkZWZpbmVkIHRvIHRyYWNrIHJlYWwgdHJhZmZpYyBtb3ZlbWVudHMgKGFuZCBpdCBu ZXZlciBoYXMgYmVlbiANCmRlZmluZWQpLiZuYnNwOyBOb3RlIGFsc28gdGhhdCBpbiBjaGFuZ2lu ZyB0aGUgbG9jYXRpb24gb2YgdGhlIG5lc3RlZCBUQ00gbGV2ZWxzIA0Kd2UgaGF2ZSByZW1vdmVk IHRoZWlyIHJlcXVpcmVtZW50IGZvciBhIHBlcm1hbmVudCBjbGllbnQvc2VydmVyIGJpbmRpbmcg YW5kIHNvIA0KdGhlIHNlbmRpbmcgb2YgQUlTIGZyb20gbG93ZXIgdG8gaGlnaGVyIFRDTSBsZXZl bHMgd291bGQgYmUgcG9pbnRsZXNzLi4uLmFzIA0KdGhleSZuYnNwO3RvbyBoYXZlIG1vdmVkIGF3 YXkgZnJvbSB0aGUgc2VydmVyIGxheWVyIGZhaWx1cmUganVzdCBsaWtlIHdlIG5lZWQgDQp0aGUg cmVhbCB0cmFmZmljIHRvIGRvIHNvIChpZiBub3QgY2xlYXIgd2hhdCBJIG1lYW4gaGVyZSByZWZl ciBiYWNrIHRvIHRoZSBQU1ROIA0KZXhhbXBsZSBhYm92ZS4uLml0cyB0aGUgc2FtZSBpc3N1ZSku PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTk0NTE2NTcxMC0yNzA0MjAwOT48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz05NDUxNjU3MTAtMjcwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21p YyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5TbyBpbiBhZGRpdGlvbiB0byBBbmR5J3Mg b2JzZXJ2YXRpb25zIA0Kb2Ygd2h5IGl0IGlzIG5vdCBzZW5zaWJsZSBzaW1wbHkgdG8gcmVwbGlj YXRlIFBESC9TREggQUlTIGJlaGF2aW91ciBpbiANCnBhY2tldC1zd2l0Y2hlZCBuZXR3b3JrcyB3 ZSBjYW4gYWxzbyBzZWUgZnJvbSB0aGUgYWJvdmUgYXJndW1lbnRzIHRoYXQgdHJ5aW5nIHRvIA0K c2VuZCBBSVMgYmV0d2VlbiBhbiBhcnRpZmljaWFsJm5ic3A7c2V0IG9mIG5lc3RlZCBUQ00gbGV2 ZWxzIGlzIGFsc28gDQpwb2ludGxlc3MuLi4uYW5kIHRoaXMgYXBwbGllcyB0byBhbnkgbmV0d29y ayBtb2RlIHdoZXJlIHRoZSBjbGllbnQgdHJhZmZpYyBjYW4gDQptb3ZlIGl0cyByb3V0aW5nIGFu ZCB0aHVzIGRvZXMgbm90IGhhdmUgYSBwZXJtYW5lbnQgY2xpZW50Jmx0Oz0mZ3Q7c2VydmVyIA0K YmluZGluZyByZWxhdGlvbnNoaXAuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBh bGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0NTE2NTcxMC0yNzA0MjAwOT48Rk9OVCANCmZhY2U9IkNv bWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9E SVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDUxNjU3MTAtMjcwNDIw MDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5yZWdh cmRzLCBOZWlsPC9GT05UPjwvU1BBTj48L0RJVj48QlI+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0K c3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDog IzgwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRs b29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRh YkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG1wbHMt dHAtYm91bmNlc0BpZXRmLm9yZyANCiAgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmdd IDxCPk9uIEJlaGFsZiBPZiANCiAgPC9CPmFuZHkuYmQucmVpZEBidC5jb208QlI+PEI+U2VudDo8 L0I+IDI3IEFwcmlsIDIwMDkgMTE6NTA8QlI+PEI+VG86PC9CPiANCiAgbWFhcnRlbi52aXNzZXJz QGh1YXdlaS5jb208QlI+PEI+Q2M6PC9CPiBtcGxzLXRwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6 PC9CPiANCiAgUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0 IHBhdGggDQogIHJlcXVpcmVtZW50czxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KICA8RElWPjwvRElW Pg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02NjAwODMzMDktMjcwNDIw MDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+TWFhcnRlbiw8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02 NjAwODMzMDktMjcwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPkl0IGlzIG9mIGNvdXJzZSB0cnVlIHRoYXQgYWRkaW5nIGEgYm9vbGVh biBpbnB1dCB0byBhIA0KICBsb2dpY2FsIHN5c3RlbSBpbmNyZWFzZXMgdGhlIG51bWJlciBvZiBw b3NzaWJsZSBpbnB1dCBzdGF0ZXMuIFNvIGFkZGluZyBhbiBBSVMgDQogIGJvb2xlYW4gdG8gQ0Mg Ym9vbGVhbiZuYnNwO2NyZWF0ZXMmbmJzcDtmb3VyIHBvc3NpYmxlJm5ic3A7c3RhdGVzIG5vdCBq dXN0IHRoZSANCiAgdGhyZWUgeW91IGlkZW50aWZ5IGJlbG93LiBUaGVyZSZuYnNwO2FyZSA8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02 NjAwODMzMDktMjcwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPi0gZ29vZCBDQywgbm8gQUlTPC9GT05UPjwvU1BBTj48L0RJVj4NCiAg PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5PjxG T05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPg0KICA8RElWIGRpcj1sdHIg YWxpZ249bGVmdD48U1BBTiBjbGFzcz02NjAwODMzMDktMjcwNDIwMDk+PEZPTlQgZmFjZT1Bcmlh bCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+LSBDQyBmYXVsdCwgQUlTIHByZXNlbnQ8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02NjAw ODMzMDktMjcwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+ LSBnb29kIENDLCBBSVMgcHJlc2VudDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT48Rk9OVCBmYWNlPUFy aWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4tIENDIGZhdWx0LCZuYnNwO25vIA0KICBBSVM8 L0ZPTlQ+PC9TUEFOPjwvRElWPjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBh bGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT48L1NQQU4+Jm5ic3A7PC9E SVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTY2MDA4MzMwOS0yNzA0 MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5XZSBtdXN0IGFz ayB3aGF0IHByYWN0aWNhbCBzY2VuYXJpb3MmbmJzcDtjb3VsZCBnZW5lcmF0ZSANCiAgZWFjaCBv ZiB0aGVzZSZuYnNwO2lucHV0IHN0YXRlcy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02NjAwODMzMDktMjcwNDIwMDk+PEZPTlQgZmFj ZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NjYwMDgzMzA5LTI3MDQy MDA5PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkdvb2QgQ0MsIG5v IEFJUzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAw MGZmIHNpemU9Mj5PbmUgaG9wZXMgdGhpcyBpcyBiZWNhdXNlIHRoaXMgaXMgYmVjYXVzZSB0aGUg c2VydmljZSBpcyANCiAgd29ya2luZyBwcm9wZXJseS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02NjAwODMzMDktMjcwNDIwMDk+PEZP TlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJz cDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NjYwMDgzMzA5 LTI3MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkNDIGZh dWx0LCBBSVMgcHJlc2VudDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0K ICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5PbmUgaG9wZXMgdGhpcyBpcyBiZWNhdXNlIHRoZSBzZXJ2 aWNlIGlzIGZhdWx0eSBhbmQgb25lIA0KICBob3BlcyB0aGlzIGlzIGJlY2F1c2Ugb2YgYSBmYXVs dCBpbiZuYnNwO2Egc2VydmVyIGxheWVyLiBJbiBmYWN0LCB0aGUgcHJlc2VuY2UgDQogIG9mIHRo ZSBBSVMgY291bGQgYmUgbWlzbGVhZGluZyAoc2VlIGJlbG93KS48L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02NjAwODMzMDktMjcwNDIw MDk+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5Pkdvb2QgDQogIENDLCBB SVMgcHJlc2VudDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz02NjAwODMzMDktMjcwNDIwMDk+VGhpcyAN CiAgc2l0dWF0aW9uIGNvdWxkIGFyaXNlIGJlY2F1c2Ugb2YgYSBtaXNjb25maWd1cmF0aW9uIG9m IHRoZSBBSVMgZm9yd2FyZGluZyANCiAgbGFiZWwgaW5qZWN0aW9uIHRhYmxlLiBBbmQgdGhlcmUg YXJlIGEgbnVtYmVyIG9mIHNjZW5hcmlvcyB3aGljaCBtYWtlIHRoaXMgDQogIHF1aXRlIGxpa2Vs eSB3aGVuIHByb3RlY3Rpb24gc3dpdGNoaW5nIG9jY3Vycy4gRGVwZW5kaW5nIG9uIHRoZSBleGFj dCBzY29wZSBvZiANCiAgdGhlIGZvcndhcmRpbmcgbGFiZWxzLCBhIHByb3RlY3Rpb24gc3dpdGNo IG1heSB3ZWxsIHJlcXVpcmUgdGhlIHByb2FjdGl2ZSANCiAgcHVyZ2luZyBvZiBlbnRyaWVzIGZy b20gdGhlIEFJUyBmb3J3YXJkaW5nIGxhYmVsIGluamVjdGlvbiB0YWJsZSBmb2xsb3dpbmcgdGhl IA0KICBwcm90ZWN0aW9uIHN3aXRjaCAodGhpcyBjb3VsZCBlcXVpdmFsZW50bHkgYmVlbiBzZWVu IGFzIHRoZSBmb3J3YXJkaW5nIA0KICBmdW5jdGlvbiBwcm9hY3RpdmVseSBkcm9wcGluZyB0aGUg QUlTIHBhY2tldHMpLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5 PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz02NjAwODMzMDktMjcwNDIwMDk+Q0MgDQogIGZh dWx0LCBubyBBSVM8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5PkFzIA0K ICB5b3Ugc3VnZ2VzdCwgdGhpcyBjb3VsZCBhcmlzZSBmcm9tIGEgbWlzY29uZmlndXJhdGlvbiBv ZiBhIGZvcndhcmRpbmcgDQogIGZ1bmN0aW9uLiBCdXQgaXQgY291bGQgZXF1YWxseSBhcmlzZSBm cm9tIGEgbWlzY29uZmlndXJhdGlvbiBvZiB0aGUgQUlTIA0KICBmb3J3YXJkaW5nIGxhYmVsIGlu amVjdGlvbiB0YWJsZS4gSW4gZmFjdCwgdGhlIGxhdHRlciBhY3R1YWxseSBzZWVtcyBqdXN0IA0K ICBhcyZuYnNwO2xpa2VseSBhbmQgcGFydGljdWxhcmx5IHByb2JsZW1hdGljIGZvciBtYWludGVu YW5jZS4mbmJzcDtVbmxpa2UgDQogIG5vcm1hbCBmb3J3YXJkaW5nLCBhbnkgbWlzbWF0Y2ggYmV0 d2VlbiB0aGUgZm9yd2FyZGluZyBjb25maWd1cmF0aW9uIGFuZCB0aGUgDQogIEFJUyBmb3J3YXJk aW5nIGxhYmVsIGluamVjdGlvbiB0YWJsZSB3aWxsIGxpZSBkb3JtYW50IGFuZCB1bnRpbCBhIHNl cnZlciBmYXVsdCANCiAgYXJpc2VzLiBUaGVuIHRoaXMgZ2VuZXJhdGVzIGEgZmFsc2UgYW5kIG1p c3VuZGVyc3Rvb2QgZmF1bHQgY29uZGl0aW9uIHdpdGggDQogIG1haW50ZW5hbmNlIGxvb2tpbmcg Zm9yIHRoZSBmYXVsdCBpbiB0aGUgd3JvbmcgcGxhY2UuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz02NjAwODMzMDktMjcwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTY2MDA4MzMw OS0yNzA0MjAwOT5UaGUgDQogIGZpcnN0IHR3byBzdGF0ZXMgY2FuIGJlIHJlbGlhYmx5IGRpYWdu b3NlZCB3aXRoIENDIGFsb25lLiZuYnNwO1RoZSBzZWNvbmQgdHdvIA0KICBhcmlzZSBmcm9tIHRo ZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIEFJUy9GREkuIEhvd2V2ZXIsIGFueSBwb3NzaWJsZSBiZW5l Zml0IHRoYXQgDQogIG1pZ2h0IGFyaXNlIGlzIGNvbXBsZXRlbHkgbWFza2VkIGJ5IHRoZSBmYWN0 IHRoYXQgdGhlIEFJUyBpdHNlbGYgbXVzdCBiZSANCiAgY29uZmlndXJlZCBhbmQgdGhlcmUgaXMg bm8gcmVhc29uIGZvciB0aGlzIHRvIGJlIG1vcmUgcmVsaWFibGUgdGhhbiB3aGF0IGl0IGlzIA0K ICBzdXBwb3NlZCB0byBiZSBtb25pdG9yaW5nLiBJbmRlZWQsIHRoZXJlIHNlZW1zIGdvb2QgcmVh c29uIHRvIHRoaW5rIHRoYXQgaXQgDQogIHdpbGwgYmUgbGVzcyByZWxpYWJsZS48L1NQQU4+PC9G T05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQogIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT48L1NQQU4+PC9GT05UPiZuYnNwOzwv RElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQogIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT5UaGVyZSBpcyBubyBhdm9pZGluZyB0aGF0IEFJ UyBpbiBjaXJjdWl0IHN3aXRjaGluZyBpcyANCiAgZnVuZGFtZW50YWxseSBkaWZmZXJlbnQgZnJv bSBBSVMgaW4mbmJzcDtwYWNrZXQgc3dpdGNoaW5nLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9 NjYwMDgzMzA5LTI3MDQyMDA5PiZuYnNwOy0gaW4gY2lyY3VpdCBzd2l0Y2hpbmcsIHlvdSBtdXN0 IGZpbGwgdGhlIGJpdCANCiAgc3RyZWFtIHdpdGggc29tZXRoaW5nIGFuZCB0aGUgaW5mb3JtYXRp b24gaW5qZWN0ZWQgcmVxdWlyZXMgbm8gY29uZmlndXJhdGlvbiANCiAgd2hhdHNvZXZlci48L1NQ QU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+PFNQQU4gDQogIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT4mbmJzcDstIGluIHBhY2tl dCBzd2l0Y2hpbmcsIG5vIHBhY2tldHMgaXMgYSANCiAgcGVyZmVjdGx5IHZhbGlkIGNvbmRpdGlv biBhbmQgdGhlIGluamVjdGlvbiBvZiBBSVMgcmVxdWlyZXMgaW5kaXZpZHVhbCBjbGllbnQgDQog IGNvbm5lY3Rpb24gc3BlY2lmaWMgaW5mb3JtYXRpb24gdG8gYmUgY29uZmlndXJlZC48L1NQQU4+ PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+PFNQQU4gDQogIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT48L1NQQU4+PC9GT05UPiZuYnNw OzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5PlRoZSANCiAgb2JqZWN0aXZlIGlzIG5vdCB0byBy ZXBsaWNhdGUgdGhlIGRhdGEgcGxhbmUgcHJpbWl0aXZlcyBvZiBTT05FVC9TREgsIGJ1dCB0aGUg DQogIHRyaWdnZXJzIHRvIHRoZSBvcGVyYXRpb25hbCBzeXN0ZW1zIHNvIHRoYXQgdGhlIG9wZXJh dGlvbmFsIHN5c3RlbXMgYW5kIA0KICBwcm9jZXNzZXMgYXJlIHRoZSBzYW1lLjwvU1BBTj48L0ZP TlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 U1BBTiANCiAgY2xhc3M9NjYwMDgzMzA5LTI3MDQyMDA5PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBj bGFzcz02NjAwODMzMDktMjcwNDIwMDk+VGhlIA0KICBzaW1wbGUgQ0MgcmVwbGljYXRlcyBhbGwg dGhlIHRyaWdnZXJzIHRvIG1hbmFnZW1lbnQgc3lzdGVtcyBtYWRlIGJ5IFNPTkVUL1NESCANCiAg YW5kIGdpdmVzIG1heGltdW0gY29tcGF0aWJpbGl0eS4gQ29udmVyc2VseSwgdGhlIGluY2x1c2lv biBvZiBkYXRhIHBsYW5lIEFJUyANCiAgcmVxdWlyZXMgYSB3aG9sZSBuZXcgYXJlYSBvZiBjb25m aWd1cmF0aW9uIGFuZCBnZW5lcmF0ZXMgYSB3aG9sZSBuZXcgc2V0IG9mIA0KICBmYXVsdCBjb25k aXRpb25zIHdoaWNoIGNhbm5vdCBiZSBsb2NhbGlzZWQgYnkgU09ORVQvU0RIIHByb2Nlc3Nlcy4g U28sIA0KICBpcm9uaWNhbGx5LCBwYWNrZXQgQUlTIGlzIGRpcmVjdGx5IG9wcG9zZWQgdG8gYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgeW91IA0KICBjbGFpbSBpcyB0aGUgbWFpbiBkcml2ZS48L1NQ QU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+PFNQQU4gDQogIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT48L1NQQU4+PC9GT05UPiZu YnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQogIGNsYXNzPTY2MDA4MzMwOS0yNzA0MjAwOT5BbmR5PC9TUEFOPjwvRk9OVD48L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0K ICBjbGFzcz02NjAwODMzMDktMjcwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz02NjAwODMzMDktMjcwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz02NjAw ODMzMDktMjcwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48IS0tIENv bnZlcnRlZCBmcm9tIHRleHQvcnRmIGZvcm1hdCAtLT4NCiAgPFA+PEI+PFNQQU4gbGFuZz1lbi11 cz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDgwODAgc2l6ZT0yPkFuZHkgDQogIFJlaWQ8L0ZP TlQ+PC9TUEFOPjwvQj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+Q2hpZWYgDQogIE5ldHdvcmsgU2VydmljZXMgU3RyYXRlZ2lzdDwvRk9OVD48L1NQQU4+IDxC Uj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIA0KICBmYWNlPUFyaWFsIHNpemU9Mj5CVCBJbm5vdmF0 ZTwvRk9OVD48L1NQQU4+IDxCUj48U1BBTiBsYW5nPWVuLXVzPjxVPjxGT05UIA0KICBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIA0KICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9G T05UPjwvVT48L1NQQU4+IA0KICA8QlI+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj5PZmZpY2U6ICs0NCAoMCkxMjc3IA0KICAzMjIwMzg8L0ZPTlQ+PC9TUEFOPiA8QlI+ PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Nb2JpbGU6ICs0NCANCiAg KDApNzkxNyAwMjU0NTE8L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBm YWNlPUFyaWFsIA0KICBzaXplPTI+RmF4Jm5ic3A7OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyArNDQgKDApMTI3NyANCiAgMzI0MDE1PC9GT05UPjwvU1BBTj48U1BBTiBsYW5n PWVuLXVzPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgDQogIGZhY2U9QXJpYWwg c2l6ZT0yPkVtYWlsOiZuYnNwOyBhbmR5LmJkLnJlaWRAYnQuY29tPC9GT05UPjwvU1BBTj4gPC9Q Pg0KICA8UD48U1BBTiBsYW5nPWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwODA4MCAN CiAgc2l6ZT0xPjwvRk9OVD48L1NQQU4+PEJSPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jODA4MDgwIA0KICBzaXplPTE+QnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMg cGxjPEJSPlJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCANCiAgTG9uZG9uIEVD MUEgN0FKPEJSPlJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBuby4gMTgwMDAwMDwvRk9OVD4gPC9TUEFO PjxCUj48U1BBTiANCiAgbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDgwODAg c2l6ZT0xPlRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIA0KICBjb250YWlucyBpbmZvcm1hdGlvbiBm cm9tIEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYyB3aGljaCBtYXkgYmUgDQogIHByaXZp bGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUg Zm9yIHRoZSB1c2Ugb2YgDQogIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92 ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCANCiAgYmUgYXdhcmUgdGhh dCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29u dGVudHMgb2YgDQogIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgDQogIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHVzIGJ5IHRlbGVwaG9uZSBvciBlbWFpbCAodG8gdGhlIG51bWJlcnMgb3IgYWRkcmVzcyAN CiAgYWJvdmUpIGltbWVkaWF0ZWx5LjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UD48U1BBTiBsYW5n PWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwODA4MCBzaXplPTE+QWN0aXZpdHkgYW5k IHVzZSBvZiANCiAgdGhlIEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYyBlbWFpbCBzeXN0 ZW0gaXMgbW9uaXRvcmVkIHRvIHNlY3VyZSBpdHMgDQogIGVmZmVjdGl2ZSBvcGVyYXRpb24gYW5k IGZvciBvdGhlciBsYXdmdWwgYnVzaW5lc3MgcHVycG9zZXMuIENvbW11bmljYXRpb25zIA0KICB1 c2luZyB0aGlzIHN5c3RlbSB3aWxsIGFsc28gYmUgbW9uaXRvcmVkIGFuZCBtYXkgYmUgcmVjb3Jk ZWQgdG8gc2VjdXJlIA0KICBlZmZlY3RpdmUgb3BlcmF0aW9uIGFuZCBmb3Igb3RoZXIgbGF3ZnVs IGJ1c2luZXNzIHB1cnBvc2VzLjwvRk9OVD48L1NQQU4+PC9QPg0KICA8RElWPiZuYnNwOzwvRElW PjxCUj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4 OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9 ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICAgIDxIUiB0YWJJbmRleD0tMT4NCiAgICA8Rk9O VCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IE1hYXJ0ZW4gVmlzc2VycyANCiAgICBb bWFpbHRvOm1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXSA8QlI+PEI+U2VudDo8L0I+IDI0IEFw cmlsIDIwMDkgDQogICAgMTk6MTU8QlI+PEI+VG86PC9CPiBSZWlkLEFCRCxBbmR5LENYTSBSPEJS PjxCPkNjOjwvQj4gDQogICAgbXBscy10cEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6 IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgDQogICAgdHJhbnNwb3J0IHBhdGgg cmVxdWlyZW1lbnRzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03OTYxMjUzMTctMjQwNDIwMDk+PEZP TlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5BbmR5LDwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Nzk2MTI1 MzE3LTI0MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz03OTYxMjUzMTctMjQwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xv cj0jMDAwMGZmIHNpemU9Mj5BSVMvRkRJIGRvZXMgZ2l2ZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9u LiBMZXQgbWUgDQogICAgZXhwbGFpbjo8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc5NjEyNTMxNy0yNDA0MjAwOT48Rk9OVCBmYWNl PUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9E SVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Nzk2MTI1MzE3LTI0 MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+VGhlIG5l ZWQgZm9yIEFJUy9GREkgaXMgYSBjb25zZXF1ZW5jZSBvZiB0aGUgZGVwbG95bWVudCANCiAgICBv ZiBsb3NzIG9mIGNvbnRpbnVpdHkgY2hlY2tpbmcgT0FNIChlLmcuIENDTSBpbiBldGhlcm5ldCwg Q0MgaW4gQVRNKS4gVGhlIA0KICAgIG9iamVjdGl2ZSBvZiBzdWNoIENDTSBPQU0gaXMgdG8gYmUg YWJsZSB0byBkZXRlY3QgYSBtaXNjb25maWd1cmF0aW9uIG9yIA0KICAgIGZhdWx0IG9mIGEgY29u bmVjdGlvbiBmdW5jdGlvbiAoZmFicmljKSBpbiB0aGUgY29ubmVjdGlvbiwgd2hpY2ggaW50ZXJy dXB0cyANCiAgICB0aGUgZm9yd2FyZGluZyBvZiB0cmFmZmljIGluIHRoZSBjb25uZWN0aW9uLiBU aGlzIGlzIGEgZmF1bHQgY29uZGl0aW9uIHRoYXQgDQogICAgY2FuIG9ubHkgYmUgZGlzY292ZXJl ZCBieSB0aGUgbGF5ZXIgbmV0d29yayBpbiB3aGljaCB0aGUgY29ubmVjdGlvbiBpcyANCiAgICBz dXBwb3J0ZWQuIEl0IHJlcXVpcmVzIHRoYXQgdGhlIG9yZ2FuaXphdGlvbiByZXNwb25zaWJsZSBm b3IgdGhlIGxheWVyIA0KICAgIG5ldHdvcmsgdGFrZXMgYWN0aW9uIChpLmUuIGxvY2F0ZSB0aGUm bmJzcDtsYXllcidzIGNvbm5lY3Rpb24gZnVuY3Rpb24gdGhhdCANCiAgICBpbmNsdWRlcyB0aGUg ZmF1bHQpJm5ic3A7dG8gcmVzdG9yZSB0aGUgY29ubmVjdGlvbi48L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc5NjEyNTMxNy0yNDA0 MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9Nzk2MTI1MzE3LTI0MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBm ZiBzaXplPTI+VW5mb3J0dW5hdGVseSwgYW4gaW50ZXJydXB0aW9uIG9mJm5ic3A7b25lIG9mIA0K ICAgIHRoZSZuYnNwO2xpbmsgY29ubmVjdGlvbnMgb2Ygc3VjaCBjb25uZWN0aW9uIChkdWUgdG8g YSBmYXVsdCBpbiBhIHNlcnZlciANCiAgICBsYXllcikgd2lsbCBhbHNvIGludGVycnVwdCB0aGUg Zm9yd2FyZGluZyBvZiB0cmFmZmljIGluIHRoZSANCiAgICBjb25uZWN0aW9uLjwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Nzk2MTI1 MzE3LTI0MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz03OTYxMjUzMTctMjQwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xv cj0jMDAwMGZmIHNpemU9Mj5BcyBzdWNoLCBsb3NzIG9mIENDIG1lc3NhZ2VzIChMT0MgZGVmZWN0 KSBkb2VzIG5vdCANCiAgICBwcm92aWRlIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gdG8gZGV0ZXJt aW5lIGlmIHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSANCiAgICBsYXllcidzIGNvbm5lY3Rpb24g ZnVuY3Rpb25zIGFsb25nIHRoZSBjb25uZWN0aW9uIGhhdmUgdG8gYmUgY2hlY2tlZCBhbmQgDQog ICAgY29ycmVjdGVkLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9Nzk2MTI1MzE3LTI0MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQog ICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03OTYxMjUzMTctMjQwNDIwMDk+PEZP TlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5BSVMgaGFzIGJlZW4gaW50 cm9kdWNlZCBhbmQgaXMgdXNlZCB0byBoZWxwIA0KICAgIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0 aGUgdHdvIGZhdWx0IGNhc2VzLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Nzk2MTI1MzE3LTI0MDQyMDA5PjxGT05UIGZhY2U9QXJp YWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+MSkgaWYgTE9DIGFuZCBBSVMgYXJlIGRldGVj dGVkLCB0aGVuIHRoZXJlIGlzIGEgc2VydmVyIA0KICAgIGxheWVyIGZhdWx0LiBUaGlzIHNlcnZl ciBsYXllciBmYXVsdCBpcyBhbHJlYWR5IHJlcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIgbGF5ZXIgDQog ICAgTUVQIGRldGVjdGluZyB0aGlzIGZhdWx0LiBObyBhY3Rpb24gaXMgcmVxdWlyZWQsIHNvIG5v IGFsYXJtIHRvIA0KICAgIGdlbmVyYXRlLiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAg PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Nzk2MTI1MzE3LTI0MDQyMDA5PjxG T05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+MikgaWYgTE9DIGlzIGRl dGVjdGVkIGFuZCB0aGVyZSBpcyBubyBBSVMsIHRoZW4gdGhlcmUgDQogICAgaXMgYSBsYXllciBu ZXR3b3JrIGZhdWx0IChpLmUuIGNvbnRpbnVpdHkgZmF1bHQpLiBGYXVsdCBsb2NhbGl6YXRpb24g bXVzdCBiZSANCiAgICBzdGFydGVkIHRvIGxvY2F0ZSB0aGUgbWlzY29uZmlndXJlZCBvciBmYWls ZWQgY29ubmVjdGlvbiBmdW5jdGlvbi4gT25jZSB0aGlzIA0KICAgIGZhdWx0eSZuYnNwO2Nvbm5l Y3Rpb24gZnVuY3Rpb24gaXMgbG9jYXRlZCwgdGhlIGNvbmZpZ3VyYXRpb24gZmF1bHQgKG9yIA0K ICAgIGhhcmR3YXJlIGZhdWx0KSZuYnNwO2NhbiBiZSBjb3JyZWN0ZWQsIGFmdGVyIHdoaWNoIHRo ZSBjb25uZWN0aW9uIGlzIA0KICAgIHJldG9yZWQuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03OTYxMjUzMTctMjQwNDIwMDk+PEZP TlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc5NjEy NTMxNy0yNDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PlRoZSBpbnRlcnJ1cHRpb24gb2YgdGhlIGZvcndhcmRpbmcgb2YgdHJhZmZpYyBpbiB0aGUgDQog ICAgY29ubmVjdGlvbiBpbiBib3RoIGZhdWx0IGNhc2VzIGlzIGhvd2V2ZXIgcmVnaXN0ZXJlZCBh cyBwYXJ0IG9mIHBlcmZvcm1hbmNlIA0KICAgIG1vbml0b3JpbmcuIFRoaXMgcGVyZm9ybWFuY2Ug bW9uaXRvcmluZyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIHZlcmlmeSB0aGUgDQogICAgcGVyZm9y bWFuY2UgYWdhaW5zdCB0aGUgU0xBIGZvciB0aGUgY29ubmVjdGlvbi48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc5NjEyNTMxNy0y NDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9Nzk2MTI1MzE3LTI0MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAw MDBmZiBzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc5NjEyNTMxNy0yNDA0MjAwOT48Rk9OVCBmYWNlPUFy aWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPk1hYXJ0ZW48L0ZPTlQ+PC9TUEFOPjwvRElW PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PEJSPg0KICAgIDxESVYg Y2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+ DQogICAgPEhSIHRhYkluZGV4PS0xPg0KICAgIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5G cm9tOjwvQj4gYW5keS5iZC5yZWlkQGJ0LmNvbSANCiAgICBbbWFpbHRvOmFuZHkuYmQucmVpZEBi dC5jb21dIDxCUj48Qj5TZW50OjwvQj4gdnJpamRhZyAyNCBhcHJpbCAyMDA5IA0KICAgIDEyOjM0 PEJSPjxCPlRvOjwvQj4gbWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb208QlI+PEI+Q2M6PC9CPiAN CiAgICBtcGxzLXRwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogW21wbHMtdHBdIEFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCANCiAgICB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHM8 QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgICA8RElWPjwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBh bGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTM2NTM0MDkxMC0yNDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFs IA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPk1hYXJ0ZW4sPC9GT05UPjwvU1BBTj48L0RJVj4N CiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0zNjUzNDA5MTAtMjQwNDIw MDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9T UEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTM2NTM0MDkxMC0yNDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPlRoZXNlIHBvaW50cyBhcmUgaXJyZWxldmFudCB0byB0aGUgcG9pbnRzIEkgbWFkZS4g TXkgDQogICAgcG9pbnQgaXMgdGhhdCBBSVMvRkRJIGdpdmVzIG5vIGluZm9ybWF0aW9uIGFib3Zl IHdoYXQgaXMgYWxyZWFkeSBrbm93biAtIGl0IA0KICAgIGlzIG9ubHkgYWRkcyBjb21wbGV4aXR5 IGFuZCBmYXVsdCBsaWFiaWxpdHkuIE5laXRoZXIgb2YgeW91ciBwb2ludHMgY2hhbmdlIA0KICAg IHRoaXMuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz0zNjUzNDA5MTAtMjQwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xv cj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTM2NTM0MDkxMC0yNDA0MjAwOT48Rk9OVCBmYWNl PUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkFuZHk8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTM2NTM0MDkxMC0yNDA0 MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj48IS0tIENvbnZlcnRlZCBm cm9tIHRleHQvcnRmIGZvcm1hdCAtLT4NCiAgICA8UD48Qj48U1BBTiBsYW5nPWVuLXVzPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzgwODA4MCBzaXplPTI+QW5keSANCiAgICBSZWlkPC9GT05UPjwv U1BBTj48L0I+IDxCUj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkNo aWVmIA0KICAgIE5ldHdvcmsgU2VydmljZXMgU3RyYXRlZ2lzdDwvRk9OVD48L1NQQU4+IDxCUj48 U1BBTiBsYW5nPWVuLXVzPjxGT05UIA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0yPkJUIElubm92YXRl PC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PFU+PEZPTlQgDQogICAgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiANCiAgICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9GT05UPjwvVT48L1NQQU4+IA0KICAgIDxCUj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPk9mZmljZTogKzQ0ICgwKTEyNzcgDQogICAgMzIyMDM4PC9GT05UPjwvU1BB Tj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+TW9iaWxlOiAN CiAgICArNDQgKDApNzkxNyAwMjU0NTE8L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1lbi1n Yj48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIHNpemU9Mj5GYXgmbmJzcDs6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICs0NCAoMCkxMjc3IA0KICAgIDMyNDAxNTwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+IDxCUj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIA0K ICAgIGZhY2U9QXJpYWwgc2l6ZT0yPkVtYWlsOiZuYnNwOyBhbmR5LmJkLnJlaWRAYnQuY29tPC9G T05UPjwvU1BBTj4gPC9QPg0KICAgIDxQPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jODA4MDgwIA0KICAgIHNpemU9MT48L0ZPTlQ+PC9TUEFOPjxCUj48U1BBTiBsYW5n PWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwODA4MCANCiAgICBzaXplPTE+QnJpdGlz aCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjPEJSPlJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRl IA0KICAgIFN0cmVldCBMb25kb24gRUMxQSA3QUo8QlI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIG5v LiAxODAwMDAwPC9GT05UPiANCiAgICA8L1NQQU4+PEJSPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jODA4MDgwIHNpemU9MT5UaGlzIA0KICAgIGVsZWN0cm9uaWMgbWVz c2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25z IHBsYyANCiAgICB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBp bmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSANCiAgICBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSANCiAg ICBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWlu ZywgZGlzdHJpYnV0aW9uIG9yIA0KICAgIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZv cm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCiAgICB0aGlzIGVs ZWN0cm9uaWMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBieSB0ZWxlcGhvbmUg b3IgZW1haWwgKHRvIA0KICAgIHRoZSBudW1iZXJzIG9yIGFkZHJlc3MgYWJvdmUpIGltbWVkaWF0 ZWx5LjwvRk9OVD48L1NQQU4+PC9QPg0KICAgIDxQPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jODA4MDgwIHNpemU9MT5BY3Rpdml0eSBhbmQgdXNlIA0KICAgIG9mIHRo ZSBCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMgZW1haWwgc3lzdGVtIGlzIG1vbml0b3Jl ZCB0byBzZWN1cmUgDQogICAgaXRzIGVmZmVjdGl2ZSBvcGVyYXRpb24gYW5kIGZvciBvdGhlciBs YXdmdWwgYnVzaW5lc3MgcHVycG9zZXMuIA0KICAgIENvbW11bmljYXRpb25zIHVzaW5nIHRoaXMg c3lzdGVtIHdpbGwgYWxzbyBiZSBtb25pdG9yZWQgYW5kIG1heSBiZSByZWNvcmRlZCANCiAgICB0 byBzZWN1cmUgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBidXNpbmVz cyANCiAgICBwdXJwb3Nlcy48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgICA8RElWPiZuYnNwOzwvRElW PjxCUj4NCiAgICA8QkxPQ0tRVU9URSBkaXI9bHRyIA0KICAgIHN0eWxlPSJQQURESU5HLUxFRlQ6 IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBN QVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVy IGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICAgICAgPEhSIHRhYkluZGV4PS0xPg0K ICAgICAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBNYWFydGVuIFZpc3Nl cnMgDQogICAgICBbbWFpbHRvOm1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXSA8QlI+PEI+U2Vu dDo8L0I+IDIzIEFwcmlsIDIwMDkgDQogICAgICAyMDo0MjxCUj48Qj5Ubzo8L0I+IFJlaWQsQUJE LEFuZHksQ1hNIFI8QlI+PEI+Q2M6PC9CPiANCiAgICAgIG1wbHMtdHBAaWV0Zi5vcmc8QlI+PEI+ U3ViamVjdDo8L0I+IFJFOiBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIA0KICAg ICAgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogICAg ICA8RElWPjwvRElWPg0KICAgICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9 NzgxNDI0OTE4LTIzMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgICBjb2xvcj0jMDAwMGZm IHNpemU9Mj5BbmR5LDwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz03ODE0MjQ5MTgtMjMwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCAN CiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQog ICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03ODE0MjQ5MTgtMjMwNDIw MDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZndDsgPFNQ QU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgICBjb2xv cj0jMDAwMGZmIHNpemU9Mj5UaGUgcHJvYmxlbSBpcyAqbm90KiBhYm91dCBhIGxhY2sgb2YgYWxh cm0gDQogICAgICBzdXBwcmVzc2lvbiBpbiB0aGUgZGF0YSBwbGFuZSAtIHRoYXQgaW5mb3JtYXRp b24gaXMgcmVhZGlseSANCiAgICAgIGF2YWlsYWJsZS48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03ODE0 MjQ5MTgtMjMwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjwvU1BBTj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9NzgxNDI0OTE4LTIzMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgICBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+SSBkb24ndCBiZWxp ZXZlIHRoYXQgDQogICAgICB0aGlzIGlzIGEgY29ycmVjdCBzdGF0ZW1lbnQgaW4gYSBtdWx0aS1v cGVyYXRvciB0cmFuc3BvcnQgbmV0d29yaywgb3IgaW4gDQogICAgICB0cmFuc3BvcnQgbmV0d29y a3Mgb2Ygb25lIG9wZXJhdG9yIHRoYXQgaGF2ZSBtb3JlIHRoZW4gb25lIGFkbWluaXN0cmF0aXZl IA0KICAgICAgc3ViZG9tYWluIChlYWNoIHdpdGggaXRzIG93biBuZXR3b3JrIG1hbmFnZW1lbnQg c3lzdGVtKS4gQSBwcm9ibGVtIA0KICAgICAgb2NjdXJpbmcgaW4gYWRtaW4gZG9tYWluIEEgd2ls bCBiZSB1bmtub3duIGluIGFkbWluIGRvbWFpbiBCLiBUaGUgbG9zcyBvZiANCiAgICAgIGNvbnRp bnVhaXR5IGFsYXJtcyB0aGF0IGFyZSBhY3RpdmF0ZWQgaW4gYWRtaW4gZG9tYWluIEIgZHVlIHRv IHRoZSBmYXVsdCANCiAgICAgIGluIGFkbWluIGRvbWFpbiBBIHdpbGwgYXBwZWFyIGFzIHByaW1h cnkgYWxhcm1zLCBzdWdnZXN0aW5nIGNvbm5lY3Rpdml0eSANCiAgICAgIHByb2JsZW1zIGluIGFk bWluIGRvbWFpbiBCLjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzgxNDI0OTE4LTIzMDQyMDA5PjxGT05UIGZhY2U9 QXJpYWwgDQogICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTE2 NDMwMjMwOS0yMjA0MjAwOT48L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAg IDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc4MTQyNDkxOC0yMzA0MjAwOT48 Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9 MTY0MzAyMzA5LTIyMDQyMDA5PiZndDsgPFNQQU4gDQogICAgICBjbGFzcz0xNjQzMDIzMDktMjIw NDIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGUgaXNzdWUgDQog ICAgICBhcmlzZXMgYmVjYXVzZSB0aGUgdHdvIHNpZGVzIG9mIG1haW50ZW5hbmNlIHdhbnQgZGlm ZmVyZW50IHRoaW5ncy4gVGhlIA0KICAgICAgZmF1bHQgZml4aW5nPC9GT05UPjwvU1BBTj48L1NQ QU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTc4MTQyNDkxOC0yMzA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgY29s b3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxTUEFOIA0K ICAgICAgY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiANCiAgICAgIHNpemU9Mj4mZ3Q7Jm5ic3A7Z3V5cyB3YW50IHRvIGxvY2F0ZSB0aGUgZmF1 bHQgYW5kIGRvbid0IHdhbnQgYW55IG90aGVyIA0KICAgICAgaW5mb3JtYXRpb24uIFRoZSBzZXJ2 aWNlIA0KICAgICAgbWFpbnRlbmFuY2U8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KICAgICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzgxNDI0 OTE4LTIzMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgICBjb2xvcj0jMDAwMGZmIHNpemU9 Mj48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PFNQQU4gDQogICAgICBjbGFzcz0xNjQz MDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6 ZT0yPiZndDsmbmJzcDtndXlzIHdhbnQgdG8ga25vdyB3aGV0aGVyIHRoZWlyIGN1c3RvbWVyIHNl cnZpY2UgaXMgDQogICAgICB3b3JraW5nLjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9NzgxNDI0OTE4 LTIzMDQyMDA5PlRoaXMgaXMgYWRkcmVzc2VkIGluIFNESCwgT1ROLCBFdGhlcm5ldCBhbmQgDQog ICAgICBULU1QTFMgcmVjb21tZW5kYXRpb25zIGJ5IG1lYW5zIG9mIHRoZSBhZGRpdGlvbmFsJm5i c3A7U1NGIGFsYXJtLiBUaGUgU1NGIA0KICAgICAgYWxhcm0gaXMgZm9yIHRoZSBzZXJ2aWNlIGd1 eXMgdGVsbGluZyB0aGVtIHRoYXQgdGhlIHNlcnZpY2Ugd2FzIA0KICAgICAgaW50ZXJydXB0ZWQg ZHVlIHRvIGEgZmF1bHQgaW4gYSBzZXJ2ZXIgbGF5ZXIuIEFJUyBzdXBwcmVzc2VzIHRoZSBMT0Mg YWxhcm0gDQogICAgICBpbiB0aG9zZSBjYXNlcyBzbyB0aGF0IHRoZSBtYWludGVuYW5jZSBndXlz IGRvbid0IGdldCB0cmlnZ2VyZWQgYW5kIHN0YXJ0IA0KICAgICAgbG9va2luZyBmb3IgYSBmYXVs dCB0aGF0IGlzIG91dHNpZGUgdGhlaXIgYXJlYS48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAg Y2xhc3M9NzgxNDI0OTE4LTIzMDQyMDA5PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAg ICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogICAg ICBjbGFzcz03ODE0MjQ5MTgtMjMwNDIwMDk+UmVnYXJkcyw8L1NQQU4+PC9GT05UPjwvRElWPg0K ICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0K ICAgICAgY2xhc3M9NzgxNDI0OTE4LTIzMDQyMDA5Pk1hYXJ0ZW48L1NQQU4+PC9GT05UPjwvRElW Pg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEJSPjwvRElWPg0KICAgICAgPERJViBjbGFzcz1P dXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgICAg IDxIUiB0YWJJbmRleD0tMT4NCiAgICAgIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9t OjwvQj4gbXBscy10cC1ib3VuY2VzQGlldGYub3JnIA0KICAgICAgW21haWx0bzptcGxzLXRwLWJv dW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAgICAgIDwvQj5hbmR5LmJkLnJlaWRA YnQuY29tPEJSPjxCPlNlbnQ6PC9CPiB3b2Vuc2RhZyAyMiBhcHJpbCAyMDA5IA0KICAgICAgMTI6 MTQ8QlI+PEI+VG86PC9CPiBsaXUuZ3VvbWFuQHp0ZS5jb20uY247IA0KICAgICAgbmVpbC4yLmhh cnJpc29uQGJ0LmNvbTxCUj48Qj5DYzo8L0I+IG1wbHMtdHBAaWV0Zi5vcmc8QlI+PEI+U3ViamVj dDo8L0I+IA0KICAgICAgUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGggDQogICAgICByZXF1aXJlbWVudHM8QlI+PC9GT05UPjxCUj48L0RJVj4NCiAg ICAgIDxESVY+PC9ESVY+DQogICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPkxpdSw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJViBkaXI9bHRyIGFs aWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwg DQogICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K ICAgICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQy MDA5PjxGT05UIGZhY2U9QXJpYWwgDQogICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5BbGxvdyBt ZSB0byBqdW1wIGluLiBZb3UgYXJlIGJyaW5naW5nIHRvZ2V0aGVyIHR3byANCiAgICAgIHRoaW5n cyB3aGljaCBhcmUgc2VwYXJhdGUgYW5kIGZvciB3aGljaCBBSVMvRkRJIGlzIG5vIGhlbHAuIE1h aW50ZW5hbmNlIA0KICAgICAgb3BlcmF0aW9ucyBhcmUgY29uY2VybmVkIHdpdGggdHdvIHNlcGFy YXRlIHRoaW5ncy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQog ICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAg ICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5 PjxGT05UIGZhY2U9QXJpYWwgDQogICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4xKSZuYnNwOyBJ ZGVudGlmeWluZyBmYXVsdHMgaW4gZXF1aXBtZW50LCBsaW5lIHBsYW50LCANCiAgICAgIGFuZCBv dGhlciBzeXN0ZW1zIChlZyBtaXNjb25maWd1cmF0aW9ucykgYW5kIGZpeGluZyB0aGVtIChlcXVp cG1lbnQgDQogICAgICBtYWludGVuYW5jZSkuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9O VCBmYWNlPUFyaWFsIA0KICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+MikmbmJzcDsgSWRlbnRp ZnlpbmcgdGhlIGhlYWx0aCBvZiBlbmQgdG8gZW5kIA0KICAgICAgY29ubmVjdGlvbnMsIGVzcGVj aWFsbHkgd2hlbiB0aGV5IGFyZSBkaXJlY3RseSBzdXBwb3J0aW5nIGN1c3RvbWVyIA0KICAgICAg c2VydmljZXMgKHNlcnZpY2UgbWFpbnRlbmFuY2UpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAg ICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+ PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQ QU4+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPlRoZSBwcm9ibGVtIGlzICpub3QqIGFib3V0IGEgbGFjayBvZiBhbGFybSANCiAg ICAgIHN1cHByZXNzaW9uIGluIHRoZSBkYXRhIHBsYW5lIC0gdGhhdCBpbmZvcm1hdGlvbiBpcyBy ZWFkaWx5IGF2YWlsYWJsZS4gSWYsIA0KICAgICAgYXQgYW4gZW5kIGVxdWlwbWVudCwgSSBoYXZl IGEgZ29vZCBzZXJ2ZXIvc2VjdGlvbiBsYXllciBhbmQgYSBsb3NzIG9mIENDIA0KICAgICAgYXQg dGhlIGNsaWVudCBsYXllciwgSSAqa25vdyogdGhlIGZhdWx0IGlzIGVsc2V3aGVyZSAtIEkgZG9u J3QgbmVlZCANCiAgICAgIEFJUy9GREkgdG8gdGVsbCBtZS4gKEluZGVlZCwgaWYgeW91IHRoaW5r IGFib3V0LCBpZiB0aGUgZmF1bHQgaXMgaW4gdGhlIA0KICAgICAgZW5kIGVxdWlwbWVudCwgaXQg aXMgcXVpdGUgbGlrZWx5IHRoYXQgdGhlIGZhdWx0IG1lYW5zIGl0IGNhbm5vdCByZXBvcnQgDQog ICAgICB0aGUgdHJhZmZpYyBsb3NzIHRvIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSEpPC9GT05UPjwv U1BBTj48L0RJVj4NCiAgICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2 NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgY29sb3I9IzAwMDBmZiBz aXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0K ICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+VGhlIGlzc3VlIGFyaXNlcyBiZWNhdXNlIHRoZSB0 d28gc2lkZXMgb2YgbWFpbnRlbmFuY2UgDQogICAgICB3YW50IGRpZmZlcmVudCB0aGluZ3MuIFRo ZSBmYXVsdCBmaXhpbmcgZ3V5cyB3YW50IHRvIGxvY2F0ZSB0aGUgZmF1bHQgYW5kIA0KICAgICAg ZG9uJ3Qgd2FudCBhbnkgb3RoZXIgaW5mb3JtYXRpb24uIFRoZSBzZXJ2aWNlIG1haW50ZW5hbmNl IGd1eXMgd2FudCB0byANCiAgICAgIGtub3cgd2hldGhlciB0aGVpciBjdXN0b21lciBzZXJ2aWNl IGlzIHdvcmtpbmcuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0K ICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAg ICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAw OT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+VGhpcyBhcm9z ZSBpbiB0aGUgZWFybHkgZGF5cyBvZiBTT05FVC9TREgsIHdoZW4gdGhlIA0KICAgICAgb3BlcmF0 aW9ucyBndXlzIGRlbWFuZGVkIHRoYXQgdGhlIGVxdWlwbWVudCBkaWQgKm5vdCogc3VwcHJlc3Mg dGhlIHRyYWZmaWMgDQogICAgICBhbGFybSBldmVuIHdoZW4gQUlTIHdhcyBiZWluZyByZWNlaXZl ZCBhcyB0aGUgc2VydmljZSBndXlzIHdhbnQgdG8ga25vdyANCiAgICAgIGFib3V0IHRoZSBhbGFy bXMuIFRoZSBub3JtYWwgcHJhY3RpY2UgaXMgZm9yIHRoZSBlcXVpcG1lbnQgdG8mbmJzcDtyZXBv cnQgDQogICAgICB0aGUgYWxhcm1zICppbmNsdWRpbmcqIEFJUyBhbmQgdGhlbiBhIGZpbHRlciBp cyBhcHBsaWVkIGluIHRoZSBtYW5hZ2VtZW50IA0KICAgICAgc3lzdGVtJm5ic3A7dG8gc3VwcHJl c3MgYWxhcm1zIHRvIHRoZSBmYXVsdCBmaXhpbmcgZ3V5cy4gQXMgSSdtIGF3YXJlLCANCiAgICAg IHRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB0ZWNobmlxdWVzIGFwcGxpZWQgZm9yIHRoZSBmaWx0 ZXJpbmcgYWxnb3JpdGhtcywgDQogICAgICBlc3BlY2lhbGx5IHdoZW4geW91IGNvbnNpZGVyIG11 bHRpcGxlIGNvbmN1cnJlbnQgZmF1bHRzIGluIGEgbmV0d29yaywgDQogICAgICBob3dldmVyLCB0 aGUgZXhpc3RhbmNlIG9mIEFJUy9GREkgZG9lc24ndCBhZGQgYW55dGhpbmcgdG8gdGhlc2UgdGhh dCdzIG5vdCANCiAgICAgIGFscmVhZHkga25vd24uIEluIGZhY3QsIEkgYmVsaWV2ZSBzaW1wbGUm bmJzcDt0aW1lLXN0YW1wIGNvcnJlbGF0aW9uIGlzIA0KICAgICAgb25lIG9mIHRoZSBtb3N0IHBv d2VyZnVsIGFuZCB3aWRlbHkgdXNlZCB0ZWNobmlxdWVzLiBBbmQgaWYgdGhlIGVxdWlwbWVudCAN CiAgICAgIHN0YXJ0cyBtZXNzaW5nIHVwIHRoZSByZXBvcnRpbmcgb2YgbG9zcyBvZiBDQyBiZWNh dXNlIGl0IHdhaXRpbmcgDQogICAgICBmb3IvcGVyc2lzdGVuY2UgY2hlY2tpbmcmbmJzcDtBSVMv RkRJLCBpdCBjb3VsZCBlbmQgdXAgbWVzc2luZyB1cCBzaW1wbGUgDQogICAgICB0aW1lLXN0YW1w IGNvcnJlbGF0aW9uISZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1B cmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9E SVY+DQogICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDkt MjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPklu IHByYWN0aWNlLCBpdCBpcyBvZnRlbiBub3QgcXVpdGUgYSBzaW1wbGUgYXMgdGhpcywgDQogICAg ICBhcyB0aGUgc2VydmljZSBndXlzIGxpa2UgdG8gYmUgYWJsZSB0byAnbG9jYWxpc2UnIHRoZSBm YXVsdC4gSG93ZXZlciwgDQogICAgICB1bmRlciBtb3N0IGNpcmN1bXN0YW5jZXMsJm5ic3A7dGhl IGZpbHRlciBoYXMgYXV0b21hdGljYWxseSBkb25lIHRoaXMuIA0KICAgICAgU28mbmJzcDtsb2Nh bGlzYXRpb24mbmJzcDt5b3UgZGVzY3JpYmUgaXMgb25seSB3aGVuIHRoZSBmaWx0ZXIgaGFzbid0 IA0KICAgICAgd29ya2VkIGZvciBzb21lIHJlYXNvbi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAg ICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MTY0MzAyMzA5LTIyMDQyMDA5 PjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTE2NDMwMjMwOS0yMjA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgY29sb3I9 IzAwMDBmZiBzaXplPTI+QnV0IHRoZSBib3R0b20gbGluZSBpcywgd2hhdGV2ZXIgb3BlcmF0aW9u cyBwcm9jZXNzIA0KICAgICAgeW91IHdhbnQgdG8gdXNlLCZuYnNwO0FJUy9GREkgZG9lc24ndCBh ZGQgYW55dGhpbmcgb3RoZXIgdGhhbiBjb21wbGV4aXR5IA0KICAgICAgYW5kIGZhdWx0IGxpYWJp bGl0eSB0byB0aGUgZXF1aXBtZW50LiBSZW1lbWJlciZuYnNwO0FJUyBnb2VzIGJhY2sgdG8gdGhl IA0KICAgICAgVERNIHdvcmxkIHdoZXJlIHlvdSAqaGF2ZSB0byBmaWxsIHRoZSBiaXQgc3RyZWFt IHdpdGggDQogICAgICBzb21ldGhpbmcqLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQg ZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQogICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQz MDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCiAg ICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAg ICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0xNjQzMDIzMDktMjIwNDIwMDk+ PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkFuZHk8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcnRmIGZv cm1hdCAtLT4NCiAgICAgIDxQPjxCPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jODA4MDgwIHNpemU9Mj5BbmR5IA0KICAgICAgUmVpZDwvRk9OVD48L1NQQU4+PC9CPiA8 QlI+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5DaGllZiANCiAgICAg IE5ldHdvcmsgU2VydmljZXMgU3RyYXRlZ2lzdDwvRk9OVD48L1NQQU4+IDxCUj48U1BBTiBsYW5n PWVuLXVzPjxGT05UIA0KICAgICAgZmFjZT1BcmlhbCBzaXplPTI+QlQgSW5ub3ZhdGU8L0ZPTlQ+ PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1lbi11cz48VT48Rk9OVCANCiAgICAgIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgDQogICAgICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9G T05UPjwvVT48L1NQQU4+IA0KICAgICAgPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+T2ZmaWNlOiArNDQgKDApMTI3NyANCiAgICAgIDMyMjAzODwvRk9OVD48L1NQ QU4+IDxCUj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPk1vYmlsZTog DQogICAgICArNDQgKDApNzkxNyAwMjU0NTE8L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1l bi1nYj48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgc2l6ZT0yPkZheCZuYnNwOzombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKzQ0ICgwKTEyNzcgDQogICAgICAzMjQwMTU8L0ZP TlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1lbi11cz48 Rk9OVCANCiAgICAgIGZhY2U9QXJpYWwgc2l6ZT0yPkVtYWlsOiZuYnNwOyBhbmR5LmJkLnJlaWRA YnQuY29tPC9GT05UPjwvU1BBTj4gPC9QPg0KICAgICAgPFA+PFNQQU4gbGFuZz1lbi1nYj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSM4MDgwODAgDQogICAgICBzaXplPTE+PC9GT05UPjwvU1BBTj48 QlI+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDgwODAgDQogICAg ICBzaXplPTE+QnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjPEJSPlJlZ2lzdGVyZWQgb2Zm aWNlOiA4MSBOZXdnYXRlIA0KICAgICAgU3RyZWV0IExvbmRvbiBFQzFBIDdBSjxCUj5SZWdpc3Rl cmVkIGluIEVuZ2xhbmQgbm8uIDE4MDAwMDA8L0ZPTlQ+IA0KICAgICAgPC9TUEFOPjxCUj48U1BB TiBsYW5nPWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwODA4MCBzaXplPTE+VGhpcyAN CiAgICAgIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIEJyaXRp c2ggVGVsZWNvbW11bmljYXRpb25zIA0KICAgICAgcGxjIHdoaWNoIG1heSBiZSBwcml2aWxlZ2Vk IG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIA0KICAgICAgdG8g YmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFib3Zl LiBJZiB5b3UgYXJlIA0KICAgICAgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUg dGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgDQogICAgICBkaXN0cmlidXRpb24gb3IgdXNl IG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIElmIA0K ICAgICAgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdXMgYnkgDQogICAgICB0ZWxlcGhvbmUgb3IgZW1haWwgKHRvIHRoZSBu dW1iZXJzIG9yIGFkZHJlc3MgYWJvdmUpIA0KICAgICAgaW1tZWRpYXRlbHkuPC9GT05UPjwvU1BB Tj48L1A+DQogICAgICA8UD48U1BBTiBsYW5nPWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzgwODA4MCBzaXplPTE+QWN0aXZpdHkgYW5kIHVzZSANCiAgICAgIG9mIHRoZSBCcml0aXNoIFRl bGVjb21tdW5pY2F0aW9ucyBwbGMgZW1haWwgc3lzdGVtIGlzIG1vbml0b3JlZCB0byBzZWN1cmUg DQogICAgICBpdHMgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBidXNp bmVzcyBwdXJwb3Nlcy4gDQogICAgICBDb21tdW5pY2F0aW9ucyB1c2luZyB0aGlzIHN5c3RlbSB3 aWxsIGFsc28gYmUgbW9uaXRvcmVkIGFuZCBtYXkgYmUgDQogICAgICByZWNvcmRlZCB0byBzZWN1 cmUgZWZmZWN0aXZlIG9wZXJhdGlvbiBhbmQgZm9yIG90aGVyIGxhd2Z1bCBidXNpbmVzcyANCiAg ICAgIHB1cnBvc2VzLjwvRk9OVD48L1NQQU4+PC9QPg0KICAgICAgPERJVj4mbmJzcDs8L0RJVj48 QlI+DQogICAgICA8QkxPQ0tRVU9URSBkaXI9bHRyIA0KICAgICAgc3R5bGU9IlBBRERJTkctTEVG VDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7 IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgICAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhl YWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgICAgICAgPEhSIHRhYkluZGV4 PS0xPg0KICAgICAgICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG1wbHMt dHAtYm91bmNlc0BpZXRmLm9yZyANCiAgICAgICAgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0 Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAgICAgICAgPC9CPmxpdS5ndW9tYW5AenRlLmNvbS5j bjxCUj48Qj5TZW50OjwvQj4gMjIgQXByaWwgMjAwOSANCiAgICAgICAgMDk6MTU8QlI+PEI+VG86 PC9CPiBIYXJyaXNvbixOLE5laWwsQ1hNIFI8QlI+PEI+Q2M6PC9CPiANCiAgICAgICAgbXBscy10 cEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIA0K ICAgICAgICBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50czxCUj48L0ZP TlQ+PEJSPjwvRElWPg0KICAgICAgICA8RElWPjwvRElWPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0zPk5laWw6PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICAgIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTM+Jm5ic3A7IHRoYW5rIHlvdSBmb3Igd2FzdGluZyBtb3JlIHRpbWUgaW4gDQogICAg ICAgIGRlc2NyaWJsaW5nIHRoZSBwcm9ibGVtcy4gYnV0IEkgdGhpbmsgc29tZSBvZiB3aGF0IHlv dSBzYWlkIGlzIG5vIA0KICAgICAgICByZWxhdGlvbnMgd2l0aCBvdXIgcHJvYmxlbS5mb3IgbWUs IG1heWJlIEFJUy9GREkgZnVuY3Rpb25zIGlzIG5vIHNlbnNlIA0KICAgICAgICBpbiBjbC1wcyAs ZWcuIElQLiBidXQgZm9yIENPLVBTIG5ldHdvcmtzLmlmIHRoZXJlIGlzIG5vIEFJUy9GREkgDQog ICAgICAgIGZ1bmN0aW9ucywgd2hlbiB0aGVyZSBpcyBhIGRlZmVjdHMgaW4gYSBnaXZlbiBsYXll ciBuZXR3b3JrLCBpdCBjYW4gDQogICAgICAgIGNhdXNlIG11bHRpcGxlIGFsYXJtIGV2ZW50cyB0 byBiZSByYWlzZWQuIGl0IGlzIGRpZmZjdWx0ICZuYnNwO2ZvciANCiAgICAgICAgb3BlcmF0b3Jz IHRvIGxvY2F0ZSBhbmQgZGlhZ25vc2UgdGhlIGZhdWx0cy48L0ZPTlQ+IDxCUj48Rk9OVCANCiAg ICAgICAgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mz4mbmJzcDt0aG91Z2ggSSBjb21wbGV0ZWx5IGFn cmVlIHlvdSBvbiANCiAgICAgICAgJm5ic3A7YWRkaW5nIG5ldyB0aGluZ3MgYW5kIGZ1bmN0aW9u cyB3aWxsIGJyaW5nIHNvbWUgY29tcGxleGl0eSAuIGJ1dCANCiAgICAgICAgaWYgd2UgaGF2ZSBu byBmdW5jdGlvbnMsIGl0IGlzIG1vcmUgY29tcGxleCBhbmQgZGlmY3VsdCBmb3Igb3BlcmF0b3Jz IHRvIA0KICAgICAgICBtYWludGVuY2UgYW5kIGFkbWluaXN0cmF0b3IgdGhlIG5ldHdvcmsuIHNv IEkgdGhpbmsgZXZlcnkgbmV3IGZ1bmN0aW9ucyANCiAgICAgICAgYW5kIHRoaW5ncyBtYXkgaGF2 ZSBwb3NpdGl2ZSBhbmQgbmVnYXRpdmUgZWZmZWN0cy4gYnV0IHdlIHNob3VsZCANCiAgICAgICAg Y29uc2lkZXIgaXQgdmVyeSBtdWNoLCBkb24ndCBkZWxldGUgc29tZSBmdW5jdGlvbnMgYXQgcmFu ZG9tLjwvRk9OVD4gDQogICAgICAgIDxCUj48QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTM+YmVzdCByZWdhcmRzPC9GT05UPiA8QlI+PEZPTlQgDQogICAgICAgIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTM+bGl1PC9GT05UPiA8QlI+PEJSPjxCUj4NCiAgICAgICAgPFRBQkxFIHdpZHRo PSIxMDAlIj4NCiAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQog ICAgICAgICAgICA8VEQgd2lkdGg9IjI2JSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAg ICAgICAgICBzaXplPTE+PEI+Jmx0O25laWwuMi5oYXJyaXNvbkBidC5jb20mZ3Q7PC9CPiA8L0ZP TlQ+DQogICAgICAgICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+MjAwOS0w NC0yMSAyMDozMDwvRk9OVD4gPC9QPg0KICAgICAgICAgICAgPFREIHdpZHRoPSI3MyUiPg0KICAg ICAgICAgICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICAgICAgICAgICAgICAgIDxUQk9EWT4N CiAgICAgICAgICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICAgICAgICAgIDxURD4N CiAgICAgICAgICAgICAgICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgDQogICAgICAgICAgICAgICAgICAgIHNpemU9MT7mlLbku7bkuro8L0ZPTlQ+PC9ESVY+DQog ICAgICAgICAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgICAgICAg ICAgICAgICBzaXplPTE+Jmx0O2xpdS5ndW9tYW5AenRlLmNvbS5jbiZndDssIA0KICAgICAgICAg ICAgICAgICAgICAmbHQ7ZGJydW5nYXJkQGF0dC5jb20mZ3Q7PC9GT05UPiANCiAgICAgICAgICAg ICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAg ICAgICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQpzaXplPTE+ 5oqE6YCBPC9GT05UPjwvRElWPg0KICAgICAgICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiANCiAgICAgICAgICAgICAgICAgICAgc2l6ZT0xPiZsdDttcGxzLXRwQGlldGYub3Jn Jmd0OzwvRk9OVD4gDQogICAgICAgICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAg ICAgICAgICA8VEQ+DQogICAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIA0Kc2l6ZT0xPuS4u+mimDwvRk9OVD48L0RJVj4NCiAgICAgICAgICAg ICAgICAgIDxURD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPlJFOiBbbXBscy10cF0gQXNz b2NpYXRlZCANCiAgICAgICAgICAgICAgICAgICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0 aCANCiAgICAgICAgICAgICAgICByZXF1aXJlbWVudHM8L0ZPTlQ+PC9URD48L1RSPjwvVEJPRFk+ PC9UQUJMRT48QlI+DQogICAgICAgICAgICAgIDxUQUJMRT4NCiAgICAgICAgICAgICAgICA8VEJP RFk+DQogICAgICAgICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgICAgICAgICA8 VEQ+DQogICAgICAgICAgICAgICAgICA8VEQ+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+ PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PEJSPjxCUj48Rk9OVCANCiAgICAgICAgZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+TGl1LDwvRk9OVD4gPEJSPjxG T05UIA0KICAgICAgICBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMg U2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgICAgICAgc2l6ZT0yPklmIE1QTFMtVFAgaXMgZ29p bmcgdG8gYmUgdGFrZW4gc2VyaW91c2x5IGFzIGEgdHJhbnNwb3J0IG5ldHdvcmsgDQogICAgICAg IChsaWtlIFNESC9TT05FVCkgdGhlbiB0aGUgMiBrZXkgTVVTVCBIQVZFIHJlcXVpcmVtZW50cyBh cmUgdGhlc2UuPC9GT05UPiANCiAgICAgICAgPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+ IDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgICAgICAgY29sb3I9IzgwMDAwMCBz aXplPTI+MSAmbmJzcDsgJm5ic3A7UHJvdmlkZSBhIHRyYW5zcGFyZW50IGNsaWVudC9zZXJ2ZXIg DQogICAgICAgIHJlbGF0aW9uc2hpcC4uLndoaWNoIG1lYW5zOjwvRk9OVD4gPEJSPjxGT05UIGZh Y2U9IkNvbWljIFNhbnMgTVMiIA0KICAgICAgICBjb2xvcj0jODAwMDAwIHNpemU9Mj4tICZuYnNw OyAmbmJzcDthbGwgY2xpZW50IGJpdHMgdHJlYXRlZCANCiAgICAgICAgZXF1YWxseTwvRk9OVD4g PEJSPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPi0gDQog ICAgICAgICZuYnNwOyAmbmJzcDtjbGllbnQgYml0IG9yZGVyaW5nIHByZXNlcnZlZDwvRk9OVD4g PEJSPjxGT05UIA0KICAgICAgICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNp emU9Mj4tICZuYnNwOyAmbmJzcDtubyBhdHRlbXB0IHRvIA0KICAgICAgICBpbmZlciBjbGllbnQg c3ltYm9sIChpZSBzZXF1ZW5jZSBvZiBjbGllbnQgYml0cykgbWVhbmluZyBhbmQgbm8gYXR0ZW1w dCANCiAgICAgICAgdG8gY2hhbmdlIGNsaWVudCBzeW1ib2xzPC9GT05UPiA8QlI+PEZPTlQgZmFj ZT0iQ29taWMgU2FucyBNUyIgDQogICAgICAgIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPi0gJm5ic3A7 ICZuYnNwO3RoZSB0cmFmZmljIGJlaGF2aW91ciBvZiBjbGllbnQgWCANCiAgICAgICAgbXVzdCBu b3QgaW1wYWN0IHRoZSBwZXJmb3JtYW5jZSBleHBlcmllbmNlZCBieSBjbGllbnQgWTwvRk9OVD4g PEJSPjxGT05UIA0KICAgICAgICBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgICAgICAgc2l6ZT0yPkEga2V5IGNvcm9s bGFyeSBvZiB0aGUgYWJvdmUgaXMgdGhhdCBNUExTLVRQIG11c3Qgb25seSBzdXBwb3J0IA0KICAg ICAgICBwcm9wZXIgY29ubmVjdGlvbnMgKGllIHNpbmdsZSBzb3VyY2UgY29uc3RydWN0cyk8L0ZP TlQ+IDxCUj48Rk9OVCANCiAgICAgICAgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIHNp emU9Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgICAgZmFjZT0iQ29taWMgU2FucyBN UyIgY29sb3I9IzgwMDAwMCBzaXplPTI+MiAmbmJzcDsgU2luY2UgTVBMUy1UUCBpcyBhIA0KICAg ICAgICB0cmFuc3BvcnQgbmV0d29yayBpdCBpcyBub3QgYSB0b3Atb2Ytc3RhY2sgbmV0d29yayAo aWUgaXQgZG9lcyBub3QgDQogICAgICAgIHN1cHBvcnQgZGlyZWN0bHkgZXh0ZXJuYWwgbWVzc2Fn ZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMpLiANCiAgICAgICAgJm5ic3A7TVBMUy1UUCB0aGVy ZWZvcmUgZG9lcyBub3QgcmVxdWlyZSBhbiBFLU5OSSBzcGVjaWZpY2F0aW9uLiAmbmJzcDtBIA0K ICAgICAgICBrZXkgY29yb2xsYXJ5IG9mIHRoaXMgaXMgdGhhdCBNUExTLVRQIHdpbGwgbm90IGhh dmUgYW55IHBlZXIgDQogICAgICAgIGludGVyd29ya2luZyByZWxhdGlvbnNoaXAgd2l0aCBhbnkg b3RoZXIgbmV0d29yayBtb2RlL3RlY2hub2xvZ3kuPC9GT05UPiANCiAgICAgICAgPEJSPjxGT05U IHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+ PEZPTlQgDQogICAgICAgIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0y Pk5vdyB3cnQgT0FNIE1QTFMtVFAgaXMgYSBjby1wcyANCiAgICAgICAgbW9kZSBuZXR3b3JrLiAm bmJzcDtZb3UgY291bGQgYXJndWUgdGhpcyBzaG91bGQgaGF2ZSBGREkvQUlTLi4uLmhvd2V2ZXIs IA0KICAgICAgICB0aGUgbWVyaXQgb2YgdGhpcyBpcyBoaWdobHkgcXVlc3Rpb25hYmxlLiAmbmJz cDtXaGVuIEkgYW5kIGNvbGxlYWd1ZXMgDQogICAgICAgIGRpc2N1c3NlZCB3aGV0aGVyIFBCQi1U RSAoYWxzbyBhIGNvLXBzIG1vZGUgbmV0d29yaykgc2hvdWxkIGhhdmUgRkRJL0FJUyANCiAgICAg ICAgd2UgY29uY2x1ZGVkIHRoYXQgb24gYmFsYW5jZSBpdCB3YXMgbm90IGEgZ29vZCBpZGVhLi4u Li5hbmQgbm90ZSB0aGF0IA0KICAgICAgICBpbml0aWFsbHkgSSB3YXMgaW4gZmF2b3VyIG9mIGhh dmluZyBBSVMsIGJ1dCBteSBjb2xsZWFndWVzIHByb3ZpZGVkIA0KICAgICAgICBzdHJvbmcgdGVj aG5pY2FsIGFyZ3VtZW50cyB0aGF0IGNvbnZpbmNlZCBtZSBvdGhlcndpc2UuPC9GT05UPiA8QlI+ PEZPTlQgDQogICAgICAgIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJDb21p YyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICAgICAgICBzaXplPTI+QUlTL0ZESSBpcyBoaXN0 b3JpY2FsbHkgbGlua2VkIHRvIHRoZSBlYXJseSBQREggY28tY3MgbW9kZSBsYXllciANCiAgICAg ICAgbmV0d29ya3MgdGhhdCB1c2VkIFRUTCBsb2dpYy4gJm5ic3A7V2hlbiB0aGlzIGRpZWQgaXQg cHV0IG91dCBhICs1ViAoYWxsIA0KICAgICAgICAxcykgc2lnbmFsIGJ5IGRlZmF1bHQsIGllIGl0 IHJlcXVpcmVkIG5vIGNvbnNjaW91cyBlZmZvcnQgdG8gZ2VuZXJhdGUgDQogICAgICAgIGl0Li4u Li50aGlzIGlzIGtleSBwb2ludC4gJm5ic3A7RnVydGhlciwgaW4gdGhlc2UgbmV0d29ya3MgdGhl cmUgaXMgYSANCiAgICAgICAgZmFpcmx5IHN0YXRpYy9sb25nLWhvbGRpbmcgY2xpZW50IHNlcnZl ciByZWxhdGlvbnNoaXAuICZuYnNwO0NsZWFybHkgDQogICAgICAgIHRoaXMgaXMgbm90IHRydWUg aW4gdGhlIGNsLXBzIG1vZGUgYW5kIGl0J3Mgd2h5IElFVEYgaGF2ZSBuZXZlciANCiAgICAgICAg c3BlY2lmaWVkIEFJUyBmb3IgSVAgYW5kIGl0cyB3aHkgSUVFRSBoYWQgdGhlIGdvb2Qgc2Vuc2Ug dG8gdGhyb3ctb3V0IA0KICAgICAgICBBSVMgaW4gODAyLjFhZyBmb3IgRXRoZXJuZXQgKHRob3Vn aCBJVFUgaGF2ZSB1bndpc2VseSBJTU8gcmV0YWluZWQgaXQgaW4gDQogICAgICAgIFkuMTczMS4u Li5idXQgSSBzdXNwZWN0IGFueSBvcGVyYXRvciBwbGFubmluZyB0byB1c2UgRXRoZXJuZXQgZXF1 aXBtZW50IA0KICAgICAgICB3b3VsZCBhbHdheXMgbG9vayB0byBJRUVFIHN0ZHMgYW5kIG5vdCBJ VFUgb25lcykuPC9GT05UPiA8QlI+PEZPTlQgDQogICAgICAgIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+ IDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICAgICAgICBz aXplPTI+QUlTL0ZESSBhbmQgdGhlIGNvLXBzIG1vZGUgaXMgZGViYXRhYmxlLiAmbmJzcDtBcyBJ IG5vdGVkIGFib3ZlLCANCiAgICAgICAgb24gYmFsYW5jZSB3ZSBjb25zaWRlcmVkIG5vdCBhIGdv b2QgaWRlYSBmb3IgUEJCLVRFIE9BTSBiZWNhdXNlIGl0IA0KICAgICAgICByZXF1aXJlcyBhIGNv bnNjaW91cyBlZmZvcnQgdG8gZ2VuZXJhdGUgaXQgKHVubGlrZSB0aGUgY28tY3MgbW9kZSkgc28g DQogICAgICAgIHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUgc2NhbGluZyBwcm9ibGVtcyBhbmQgaXRz IG9uZSBtb3JlIHRoaW5nIHRvIGdvIA0KICAgICAgICB3cm9uZy48L0ZPTlQ+IDxCUj48Rk9OVCBz aXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICAgIGZhY2U9IkNvbWljIFNhbnMg TVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPllvdSBzaG91bGQgYWxzbyBoYXZlIHNlZW4gbWUgDQog ICAgICAgIG1ha2UgdGhlIHBvaW50IG1hbnkgdGltZXMgaW4gdGhlIHBhc3QgdGhhdCB0aGUgYWx3 YXlzLW9uIGRlZmVjdCANCiAgICAgICAgZGV0ZWN0aW9uL2hhbmRsaW5nIE9BTSBuZWVkcyB0byBi ZSBhcyBzaW1wbGUvc3BhcnNlIGFzIHBvc3NpYmxlIHdpdGggYXMgDQogICAgICAgIGxpdHRsZSBj b25maWcgYXMgcG9zc2libGUgYmVjYXVzZSB3ZSBuZWVkIHN1cGVyIHJlbGlhYmlsaXR5Li4uLi4u VENNIA0KICAgICAgICBnb2VzIGNvbXBsZXRlbHkgYWdhaW5zdCB0aGUgZ3JhaW4gaGVyZS4gJm5i c3A7QWxzbyBub3RlIHRoYXQgdGhlIE9BTSANCiAgICAgICAgcmVxdWlyZWQgZm9yIGVhY2ggb2Yg dGhlIDMgbmV0d29yayBtb2RlcyBpcyBub3QgdGhlIHNhbWUsIGRlc3BpdGUgd2hhdCANCiAgICAg ICAgc29tZSBjbGFpbS48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+ PEZPTlQgDQogICAgICAgIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0y PnJlZ2FyZHMsIE5laWw8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgICAgc2l6ZT0zPiZuYnNwOzwv Rk9OVD4gPEJSPjxCUj4NCiAgICAgICAgPEhSPg0KICAgICAgICA8Rk9OVCBmYWNlPVRhaG9tYSBz aXplPTI+PEI+RnJvbTo8L0I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgICAgICAgW21h aWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAgICAgICAg PC9CPmxpdS5ndW9tYW5AenRlLmNvbS5jbjxCPjxCUj5TZW50OjwvQj4gMjEgQXByaWwgMjAwOSAN CiAgICAgICAgMDI6NTk8Qj48QlI+VG86PC9CPiBCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJT PEI+PEJSPkNjOjwvQj4gDQogICAgICAgIG1wbHMtdHBAaWV0Zi5vcmc8Qj48QlI+U3ViamVjdDo8 L0I+IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCANCiAgICAgICAgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCByZXF1aXJlbWVudHM8L0ZPTlQ+PEZPTlQgDQogICAgICAgIHNpemU9Mz48QlI+ PC9GT05UPjxCUj48Rk9OVCBzaXplPTI+PFRUPjxCUj5EZWJvcmFoPC9UVD48L0ZPTlQ+PEZPTlQg DQogICAgICAgIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+OjwvRk9OVD48Rk9OVCBzaXplPTM+IDwv Rk9OVD48Rk9OVCANCiAgICAgICAgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48QlI+bWF5YmUgd2hh dCB5b3Ugc2FpZCBpcyByaWdodC4gYnV0IEkgY2FuJ3QgDQogICAgICAgIGNvbXBsZXRlbHkgYWdy ZWUgeW91ciBvcGluaW9ucy4gSU1PLiBtcGxzLXRwIGlzIHJlZ2FyZCBhcyB0cmFuc3BvcnQgDQog ICAgICAgIG5ldHdvcmsgbGlrZSBTREgvU09ORVQuIHNvIGl0IHNob3VsZCBoYXZlIEFJUy9GREkg ZnVjdGlvbnMgYXMgDQogICAgICAgIFNESC9TT05FVC48L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8QlI+ PC9GT05UPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCiAgICAgICAgc2l6ZT0yPjxCUj5kbyB5b3Ug dGhpbmsgc28uPC9GT05UPjxGT05UIHNpemU9Mz4gPEJSPjwvRk9OVD48Rk9OVCANCiAgICAgICAg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48QlI+YmVzdCByZWdhcmRzPC9GT05UPjxGT05UIHNpemU9 Mz4gPC9GT05UPjxGT05UIA0KICAgICAgICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5saXUg PC9GT05UPjxGT05UIHNpemU9Mz48QlI+PEJSPjwvRk9OVD4NCiAgICAgICAgPFRBQkxFIHdpZHRo PSIxMDAlIj4NCiAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQog ICAgICAgICAgICA8VEQgd2lkdGg9IjQyJSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT48 Qj4iQlJVTkdBUkQsIERFQk9SQUggDQogICAgICAgICAgICAgIEEsIEFUVExBQlMiICZsdDtkYnJ1 bmdhcmRAYXR0LmNvbSZndDs8L0I+IDxCUj7lj5Hku7bkuro6IA0KICAgICAgICAgICAgICAmbmJz cDttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+DQog ICAgICAgICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+MjAwOS0wNC0yMCAy Mzo0NzwvRk9OVD48Rk9OVCANCiAgICAgICAgICAgICAgc2l6ZT0zPiA8L0ZPTlQ+PC9QPg0KICAg ICAgICAgICAgPFREIHdpZHRoPSI1NyUiPjxCUj4NCiAgICAgICAgICAgICAgPFRBQkxFIHdpZHRo PSIxMDAlIj4NCiAgICAgICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgICAgPFRSIHZB bGlnbj10b3A+DQogICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9IjclIj4NCiAgICAgICAgICAg ICAgICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQogICAgICAg ICAgICAgICAgICAgIHNpemU9MT7mlLbku7bkuro8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICAg ICAgICA8VEQgd2lkdGg9IjkyJSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4iTWFhcnRl biANCiAgICAgICAgICAgICAgICAgICAgVmlzc2VycyIgJmx0O21hYXJ0ZW4udmlzc2Vyc0BodWF3 ZWkuY29tJmd0OywgDQogICAgICAgICAgICAgICAgICAgICZsdDtuZWlsLjIuaGFycmlzb25AYnQu Y29tJmd0OzwvRk9OVD48Rk9OVCBzaXplPTM+IDwvRk9OVD4NCiAgICAgICAgICAgICAgICA8VFIg dkFsaWduPXRvcD4NCiAgICAgICAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgICAgICAg PERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQpzaXplPTE+5oqE6YCBPC9G T05UPjwvRElWPg0KICAgICAgICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiAN CiAgICAgICAgICAgICAgICAgICAgc2l6ZT0xPm1wbHMtdHBAaWV0Zi5vcmc8L0ZPTlQ+PEZPTlQg c2l6ZT0zPiA8L0ZPTlQ+DQogICAgICAgICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAg ICAgICAgICAgICA8VEQ+DQogICAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIA0Kc2l6ZT0xPuS4u+mimDwvRk9OVD48L0RJVj4NCiAgICAgICAg ICAgICAgICAgIDxURD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPlJlOiBbbXBscy10cF0g QXNzb2NpYXRlZCANCiAgICAgICAgICAgICAgICAgICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQg cGF0aCANCiAgICAgICAgICAgICAgICByZXF1aXJlbWVudHM8L0ZPTlQ+PC9URD48L1RSPjwvVEJP RFk+PC9UQUJMRT48QlI+PEJSPg0KICAgICAgICAgICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0K ICAgICAgICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICAgICAgICA8VFIgdkFsaWduPXRvcD4N CiAgICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNTAlIj4NCiAgICAgICAgICAgICAgICAgIDxU RCANCiAgICAgICAgd2lkdGg9IjUwJSI+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PC9U RD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PEZPTlQgDQogICAgICAgIHNpemU9Mz48QlI+PEJS PjwvRk9OVD48Rk9OVCBzaXplPTI+PFRUPjxCUj5JIGFncmVlIHdpdGggTmVpbCwgaXQgaXMgdmVy eSANCiAgICAgICAgcXVlc3Rpb25hYmxlIHRoZSB2YWx1ZSBvZiBBSVMvRkRJIGluIGE8QlI+cGFj a2V0IG5ldHdvcmstIGFueSBtb2RlLiBJdCANCiAgICAgICAgY2FuIHJlc3VsdCBpbiBhIERvUyBh dHRhY2sgYnkgYW4gb3BlcmF0b3I8QlI+b24gdGhlbXNlbHZlcyBzbyBldmVuIFkxNzMxIA0KICAg ICAgICByZWNvbW1lbmRzIG5vdCB0byBibG9jayBkYXRhIGZyYW1lczo8QlI+IkEgTUVQIGNhbiBk ZWNpZGUgd2hldGhlciBpdCANCiAgICAgICAgYmxvY2tzIGRhdGEgZnJhbWVzIHdoZW4gaXQgZGV0 ZWN0cyBkQUlTLjxCUj5UaGUgcHJpbmNpcGxlIA0KICAgICAgICByZXF1aXJlbWVudDxCUj50aGF0 IGluZmx1ZW5jZXMgdGhpcyBkZWNpc2lvbiBpcyB0aGF0IGRhdGEgZnJhbWVzIG91Z2h0IA0KICAg ICAgICB0byBiZSBmb3J3YXJkZWQ8QlI+YXMgbXVjaCBhcyBwb3NzaWJsZSwgd2l0aG91dDxCUj50 aGUgcG9zc2liaWxpdHkgb2YgDQogICAgICAgIGZvcndhcmRpbmcgd3JvbmcgZGF0YSBmcmFtZXMg ZG93bnN0cmVhbS4iPEJSPlRhYmxlIEkuNy0yIHNob3dzIGZvciBBSVMsIA0KICAgICAgICBub3Qg dG8gYmxvY2suPEJSPjxCUj5BbmQgYXMgWTE3MzEgc3RhdGVzLCBBSVMgY2FuIG9ubHkgYmUgdXNl ZCB1bmRlciANCiAgICAgICAgdmVyeSBjb25zdHJhaW5lZDxCUj5hcmNoaXRlY3R1cmVzIC0gaWYg cmVxdWlyZWQgZm9yIE1QTFMtVFAsIGl0IG5lZWRzIHRvIA0KICAgICAgICBoYXZlIHRoZSBzYW1l PEJSPmd1aWRhbmNlIGFzIGluIFkxNzMxLCBpLmUuIHBvaW50LXRvLXBvaW50IGFuZCANCiAgICAg ICAgc2VydmVyL2NsaWVudCBvbmUtdG8tb25lOjxCUj4iZm9yIGEgcG9pbnQtdG8tcG9pbnQgRVRI IGNvbm5lY3Rpb24sIGEgTUVQIA0KICAgICAgICBoYXMgb25seSBhIHNpbmdsZSBwZWVyIE1FUC48 QlI+VGhlcmVmb3JlLCB0aGVyZTxCUj5pcyBubyBhbWJpZ3VpdHkgDQogICAgICAgIHJlZ2FyZGlu ZyB0aGUgcGVlciBNRVAgZm9yIHdoaWNoIGl0IHNob3VsZCBzdXBwcmVzczxCUj5hbGFybXMgd2hl biBpdCANCiAgICAgICAgcmVjZWl2ZXMgdGhlPEJSPkVUSC1BSVMgaW5mb3JtYXRpb24uIjxCUj5T byBzaG91bGQgb25seSBiZSB3aXRoaW4gb25lIA0KICAgICAgICBkb21haW4gLSB0aGVuIG5vIG5l ZWQuPEJSPjxCUj5EZWJvcmFoPEJSPjxCUj4tLS0tLU9yaWdpbmFsIA0KICAgICAgICBNZXNzYWdl LS0tLS08QlI+RnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIA0KICAgICAgICBbbWFpbHRv Om1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT248QlI+QmVoYWxmIE9mIE1hYXJ0ZW4gDQogICAg ICAgIFZpc3NlcnM8QlI+U2VudDogTW9uZGF5LCBBcHJpbCAyMCwgMjAwOSAxMDowNSBBTTxCUj5U bzogDQogICAgICAgIG5laWwuMi5oYXJyaXNvbkBidC5jb208QlI+Q2M6IG1wbHMtdHBAaWV0Zi5v cmc8QlI+U3ViamVjdDogUmU6IFttcGxzLXRwXSANCiAgICAgICAgQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCANCiAgICAgICAgcGF0aDxCUj5yZXF1aXJlbWVudHM8QlI+PEJSPk5l aWwsPEJSPjxCUj4mZ3Q7IGJ1dCBBSVMvRkRJIGluIHRoZSBjbCANCiAgICAgICAgbW9kZT8uLi5k byBtZSBhIGZhdm91ciE8QlI+PEJSPkV0aGVybmV0IEFJUyBpcyBpbmRlZWQgYSByZXF1aXJlbWVu dCBhbmQgDQogICAgICAgIGEgbmVjZXNzaXR5LiBBbmQgeW91IHdpbGwgbm90PEJSPmJlPEJSPmFi bGUgdG8gdW5kZXJzdGFuZCB0aGF0IGFzIGxvbmcgDQogICAgICAgIGFzIHlvdSByZWZ1c2UgdG8g YWNjZXB0IHRoYXQgImNsLW1vZGUiPEJSPmlzIGE8QlI+Zm9yd2FyZGluZyBtb2RlIHdpdGhpbiAN CiAgICAgICAgYSAqKnRyYW5zcG9ydCBlbnRpdHkqKi4gRy44MDAgYW1lbmRtZW50IDEgaGFzPEJS PmZpbmFsbHk8QlI+cmVpbnRyb2R1Y2VkIA0KICAgICAgICB0aGlzIHRyYW5zcG9ydCBlbnRpdHkg aW50byBHLjgwMC4gQmVzaWRlcyB0aGF0LCBpdCBhbHNvPEJSPmludHJvZHVjZWQgDQogICAgICAg IHRoZSAqKmRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb24qKjo8QlI+PEJSPltHLjgwMCBhbTFdICJB IGRpZmZlcmVudGlhdGVkIA0KICAgICAgICBjb25uZWN0aW9uIGlzIGEgdHJhbnNwb3J0IGVudGl0 eSB0aGF0PEJSPnRyYW5zZmVycyBpbmZvcm1hdGlvbiBiZWxvbmdpbmcgDQogICAgICAgIHRvIG11 bHRpcGxlIGNvbW11bmljYXRpb25zIGJldHdlZW4gcG9ydHM8QlI+YWNyb3NzIGEgc3VibmV0d29y ay4gDQogICAgICAgICZsdDsuLiZndDsgSW4gYSBkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9uIG1l c3NhZ2U8QlI+Y29udGVudHM8QlI+YXJlIA0KICAgICAgICBpbnRlcnByZXRlZCB0byBpZGVudGlm eSAoc2V0cyBvZikgY29tbXVuaWNhdGlvbnMgd2hpY2ggDQogICAgICAgIHJlY2VpdmU8QlI+ZGlm ZmVyZW50PEJSPnRyZWF0bWVudC4gJm5ic3A7VGhlIHNldHMgb2YgY29tbXVuaWNhdGlvbnMgbWF5 IA0KICAgICAgICBiZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZTxCUj5mb3J3YXJkaW5nIGlkZW50aWZp ZXIgb3Igb3RoZXIgbGF5ZXIgDQogICAgICAgIGluZm9ybWF0aW9uLiAmbmJzcDtPcmRlciBpcyBu b3Q8QlI+bmVjZXNzYXJpbHk8QlI+cHJlc2VydmVkIGJldHdlZW4gDQogICAgICAgIG1lc3NhZ2Vz IGJlbG9uZ2luZyB0byBzZXRzIG9mIGNvbW11bmljYXRpb25zIHJlY2VpdmluZzxCUj5kaWZmZXJl bnQgDQogICAgICAgIHRyZWF0bWVudC4gJm5ic3A7U2V0cyBvZiBjb21tdW5pY2F0aW9ucyBtYXkg YmUgaWRlbnRpZmllZCANCiAgICAgICAgZm9yPEJSPnB1cnBvc2VzPEJSPnN1Y2ggYXMgdHJhZmZp YyBjb25kaXRpb25pbmcgb3IgcHJlc2VydmluZyANCiAgICAgICAgY29tbXVuaWNhdGlvbiBtZXNz YWdlIG9yZGVyLiI8QlI+PEJSPjxCUj5FdGhlcm5ldCBWTEFOcyBhcmUgaW4gdGVybXMgb2YgDQog ICAgICAgIEcuODAwICJkaWZmZXJlbnRpYXRlZCBjb25uZWN0aW9ucyIuPEJSPkV0aGVybmV0PEJS PkFJUyBwcm92aWRlcyBBSVMgDQogICAgICAgIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc3VjaCAiZGlm ZmVyZW50aWF0ZWQgY29ubmVjdGlvbiIuPEJSPklmPEJSPnlvdSBhcHBseSANCiAgICAgICAgdGhp cyB0byBteSBwcm9wb3NlZCBQVE4gbGF5ZXIgc3RhY2ssIHRoZW4gdGhlIEVWQyANCiAgICAgICAg bGF5ZXI8QlI+dG9wb2xvZ3k8QlI+d2lsbCBjb25zaXN0cyBvZiBFVkMgbGlua3Mgc3VwcG9ydGVk IGJ5IE1QTFMtVFAsIA0KICAgICAgICBFdGhlcm5ldCwgUEJCLVRFIGFuZDxCUj5QLU9UTjxCUj5W UCB0cmFpbHMgaW5zaWRlIG1ldHJvIGFuZCBjb3JlIGRvbWFpbnMgDQogICAgICAgIGludGVyY29u bmVjdGluZyBFVkMgbWF0cmljZXMuPEJSPldoZW48QlI+b25lIG9mIHRob3NlIEVWQyBsaW5rcyBp cyANCiAgICAgICAgaW50ZXJydXB0ZWQsIGUuZy4gaW4gdGhlIGNvcmUgYmV0d2VlbiBtZXRybyAx PEJSPmFuZDxCUj5tZXRybyA0IChzZWUgDQogICAgICAgIGF0dGFjaGVkIHNsaWRlKSwgdGhlbiB0 aGUgRVZDIGRpZmZlcmVudGlhdGVkIGNvbm5lY3Rpb248QlI+dGhhdCANCiAgICAgICAgaXM8QlI+ cHJlc2VudCBvbiB0aGlzIGxpbmsgd2lsbCBiZSBpbnRlcnJ1cHRlZC4gQXQgdGhlIEVWQyBzd2l0 Y2gvYnJpZGdlIA0KICAgICAgICBub2RlPEJSPmluPEJSPm1ldHJvIDQgdGhpcyBpbnRlcnJ1cHRp b24gaXMgbm90aWNlZCBhbmQgRVZDLUFJUyBpcyANCiAgICAgICAgaW5zZXJ0ZWQgaW4gdGhlPEJS PmRvd25zdHJlYW0gZGlyZWN0aW9uIHRvIHN1cHByZXNzIHRoZSBFVkMtTE9DIGFsYXJtcyANCiAg ICAgICAgYXQgRVZDIGVuZHBvaW50cyBENDxCUj5hbmQ8QlI+RDUuPEJSPjxCUj5UaGUgRVZDLUFJ UyAoaS5lLiBFdGhlcm5ldCBBSVMpIA0KICAgICAgICBmcmFtZSBoYXMgYSByZXNlcnZlZCBtdWx0 aWNhc3QgYWRkcmVzcyw8QlI+d2hpY2ggZ3VhcmFudGVlcyB0aGF0IHRoZSBBSVMgDQogICAgICAg IGlzIGJyb2FkY2FzdCB0byB0aGUgZW5kcG9pbnRzIG9mIHRoZSBFVkMuPEJSPjxCUj5JIGJlbGll dmUgdGhhdCBpdCBpcyANCiAgICAgICAgdGltZSBmb3IgeW91IHRvIGFkYXB0IHlvdXIgdmlldyBv biBjbyBhbmQgY2wgbW9kZXM8QlI+YW5kPEJSPnJlbGF0ZSBpdCANCiAgICAgICAgdG8gdGhlIGZv cndhcmRpbmcgbW9kZSAqKklOU0lERSoqIGEgdHJhbnNwb3J0IGVudGl0eS4gPEJSPjxCUj5XaGF0 IHdlIA0KICAgICAgICBrbm93IGFzIHRoZSBpbnRlcm5ldCBpcyBlc3NlbnRpYWxseSBhbiAiSVAg ZGlmZmVyZW50aWF0ZWQ8QlI+Y29ubmVjdGlvbiIgDQogICAgICAgIHdpdGggYSBiaWxsaW9uIG9y IG1vcmUgcG9ydHMuPEJSPldoYXQgd2Uga25vdyBhcyBhbiBJUCBWUE4gaXMgDQogICAgICAgIGVz c2VudGlhbGx5IGFuICJJUCBkaWZmZXJlbnRpYXRlZDxCUj5jb25uZWN0aW9uIjxCUj53aXRoIGUu Zy4gbiBwb3J0cyAobiANCiAgICAgICAgaW4gdGhlIHJhbmdlIG9mIGUuZy4gMiB0byAxMDAwKS48 QlI+V2hhdCB3ZSBrbm93IGFzIGFuIEV0aGVybmV0IFZMQU4gaXMgDQogICAgICAgIGVzc2VudGlh bGx5IGFuICJFdGhlcm5ldDxCUj5kaWZmZXJlbnRpYXRlZDxCUj5jb25uZWN0aW9uIiB3aXRoIG4g cG9ydHMgDQogICAgICAgIChuIGluIHRoZSByYW5nZSBvZiBlLmcuIDIgdG8gMTAwMCkuPEJSPldo YXQgd2Uga25vdyBhcyBhIHAycCBNUExTIEUtTFNQIA0KICAgICAgICBpcyBlc3NlbnRpYWxseSBh biAiTVBMUyBkaWZmZXJlbnRpYXRlZDxCUj5jb25uZWN0aW9uIiB3aXRoIDIgDQogICAgICAgIHBv cnRzLjxCUj5XaGF0IHdlIGtub3cgYXMgYSBwMnAgU0RIIFZDLW4gaXMgYSAiU0RIIFZDLW4gY29u bmVjdGlvbiIgd2l0aCANCiAgICAgICAgMiBwb3J0cy48QlI+PEJSPlRyYW5zcG9ydCBuZXR3b3Jr IE9BTSBhcHBsaWVzIHRvIHRyYW5zcG9ydCBlbnRpdGllcywgDQogICAgICAgIHdoaWNoIGFyZSAo aW4gdGVybXM8QlI+b2Y8QlI+Ry44MDAgYW0xKSBjb25uZWN0aW9ucyBhbmQgZGlmZmVyZW50aWF0 ZWQgDQogICAgICAgIGNvbm5lY3Rpb25zLjxCUj48QlI+UmVnYXJkcyw8QlI+TWFhcnRlbjxCUj48 QlI+LS0tLS1PcmlnaW5hbCANCiAgICAgICAgTWVzc2FnZS0tLS0tPEJSPkZyb206IG5laWwuMi5o YXJyaXNvbkBidC5jb20gDQogICAgICAgIFttYWlsdG86bmVpbC4yLmhhcnJpc29uQGJ0LmNvbV0g PEJSPlNlbnQ6IHZyaWpkYWcgMTcgYXByaWwgMjAwOSANCiAgICAgICAgMjI6MDA8QlI+VG86IEpv aG4uRS5EcmFrZTJAYm9laW5nLmNvbTsgDQogICAgICAgIEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNl bnQuaXQ7PEJSPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyANCiAgICAgICAgbWFh cnRlbi52aXNzZXJzQGh1YXdlaS5jb208QlI+Q2M6IG1wbHMtdHBAaWV0Zi5vcmc8QlI+U3ViamVj dDogUkU6IA0KICAgICAgICBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCANCiAgICAgICAgcGF0aDxCUj5yZXF1aXJlbWVudHM8QlI+PEJSPkpvaG4sICZuYnNwO1Ro YW5rcyB0aGlzIGlzIGEgZ3JlYXQgcGxhdGZvcm0gDQogICAgICAgIHRvIGV4cGxhaW4gd2h5IE9B TSBmb3IgdGhlIDM8QlI+bmV0d29yazxCUj5tb2RlcyBuZWVkcyB0byBiZSBkaWZmZXJlbnQuIA0K ICAgICAgICAmbmJzcDtJIGFtIGdldHRpbmcgYSB3ZWUgYml0IHRpcmVkIG9mIGZvbGtzPEJSPnRy eWluZzxCUj50byBtYWtlIGFsbCAzIA0KICAgICAgICBuZXR3b3JrIG1vZGVzIGxvb2sgYWxpa2Ug KGFuZCB0aGVuLCBldmVuIHdvcnNlLCBpbnRlcndvcms8QlI+dGhlbTxCUj5hcyANCiAgICAgICAg YXMgcGVlcnMuLi5lc3Agd2hlbiBub3Qgbm90IHRvcC1vZi1zdGFjazxCUj5uZXR3b3Jrcy4uLkkg bWVhbiBob3cgc2lsbHkgDQogICAgICAgIGNhbiB3ZSBnZXQ/KS4gJm5ic3A7IEkgYW0gZXZlbiBt b3JlIGZydXN0cmF0ZWQgYnk8QlI+dGhlIGZhY3QgdGhvc2UgDQogICAgICAgIHBlZGRsaW5nIHRo aXMgRlVEIG9ubHkgZXZlciBzZWVtIHRvIGNvbnNpZGVyIE9BTSBhbmQ8QlI+Zm9yZ2V0PEJSPmFs bCANCiAgICAgICAgb3RoZXIgRFAvQ1AvTVAgY29tcG9uZW50cyAoZXNwIHRvcC1vZi1zdGFjayAN CiAgICAgICAgbWVzc2FnZS9maWxlL3N0cmVhbTxCUj5hcHBsaWNhdGlvbiBhZGFwdGF0aW9ucyku ICZuYnNwO0hvdyB3cm9uZyBjYW4gDQogICAgICAgIHRoaXMgZ2V0ISA8QlI+PEJSPkluIHRoZSBj byBtb2RlcyBhICpjb25uZWN0aW9uKiBpcyBhIHZlcnkgc3BlY2lmaWMgYW5kIA0KICAgICAgICAq Y29uc3RyYWluaW5nKjxCUj5jb25zdHJ1Y3QuLi4uLkkgYW0gYXNzdW1pbmcgaGVyZSB3ZSByZXNw ZWN0IHRoZSBydWxlcyANCiAgICAgICAgb2YgYSBjb25uZWN0aW9uPEJSPihpZTxCUj5zaW5nbGUg c291cmNlKSB0aG91Z2ggc29tZSBmb2xrcyBkb24ndCBldmVuIA0KICAgICAgICBib3RoZXIgdG8g cmVzcGVjdCB0aGlzLCBhbmQ8QlI+dGhpczxCUj5pcyBkZXNwaXRlIHRoZSBmYWN0IHRoYXQgd2Ug YWxsIA0KICAgICAgICBrbm93IHdoYXQgcHJvYmxlbXMgbXVsdGlwbGUtc291cmNlPEJSPmNvbnN0 cnVjdHMgY2FuIGNhdXNlIChmcm9tIA0KICAgICAgICBMRFAvUEhQLi4uLmVyZ28gTVBMUy1UUCku PEJSPjxCUj5XaGVuIHdlIGhhdmUgYSBjb25uZWN0aW9uIHRoaXMgDQogICAgICAgIHJlc3RyaWN0 cyAqYWxsKiBEUCAoaWUgdHJhZmZpYyBhbmQgT0FNKTxCUj50bzxCUj5zdGF5IHdpdGhpbiB0aGUg Ym91bmRzIA0KICAgICAgICBvZiB0aGUgY29ubmVjdGlvbi4gJm5ic3A7V2hpY2ggaXMgZmluZSAN CiAgICAgICAgdW5kZXI8QlI+ZGVmZWN0LWZyZWU8QlI+Y29uZGl0aW9ucywgYnV0IGlmIHdlIGhh dmUgbGVha2luZyB0cmFmZmljIHRoZW4gDQogICAgICAgIHRoZSBjb25zdHJhaW5pbmcgbmF0dXJl PEJSPm9mPEJSPnRoZSBjb25uZWN0aW9uIGNvbnN0cnVjdCBpcyBicm9rZW4uIA0KICAgICAgICAm bmJzcDtJbiBhIG51dHNoZWxsIHdoYXQgdGhpcyBtZWFucyBpczxCUj50aGF0PEJSPk9BTSB0aGF0 IGlzIG9mIGEgDQogICAgICAgIHJlcXVlc3QvcmVzcG9uc2UgbmF0dXJlIGNhbm5vdCBiZSB0cnVz dGVkIGluIGNvIG1vZGU8QlI+bmV0d29ya3MgdW5kZXIgDQogICAgICAgIG1pc2Nvbm5lY3Rpdml0 eSBkZWZlY3RzLi4uLi5pbmRlZWQsIHdoeSBzaG91bGQgYSBsZWFraW5nPEJSPkRQPEJSPmhhdmUg YSANCiAgICAgICAgc3ltbWV0cmljIGdvL3JldHVybiBkZWZlY3QgYmVoYXZpb3VyPy4uLi52ZXJ5 IGxpa2VseSBpdCANCiAgICAgICAgd29uJ3QuPEJSPlNvPEJSPndoaWxzdCByZXF1ZXN0L3Jlc3Bv bnNlIE9BTSBpcyByaWdodCBmb3IgdGhlIGNsIG1vZGUgaXQgDQogICAgICAgIGlzIG5vdCByaWdo dCBmb3I8QlI+dGhlPEJSPmNvIG1vZGUgdW5kZXIgbWlzY29ubmVjdGl2aXR5IGRlZmVjdCANCiAg ICAgICAgY29uZGl0aW9ucy48QlI+PEJSPk1vcmUgZ2VuZXJhbGx5IHRoZSAzIG1vZGVzIGFyZSBk aWZmZXJlbnQgYW5kIG5vdCBqdXN0IA0KICAgICAgICBpbiBPQU08QlI+cmVxdWlyZW1lbnRzLi4u LmJ1dCBBSVMvRkRJIGluIHRoZSBjbCBtb2RlPy4uLmRvIG1lIGEgDQogICAgICAgIGZhdm91ciEu Li5hdCBsZWFzdDxCUj5JRUVFIGhhZCB0aGUgZ29vZCBzZW5zZSB0byBiaW4gdGhpcyBmb3IgRXRo ZXJuZXQgDQogICAgICAgIGV2ZW4gdGhvdWdoIGl0IHJlbWFpbnM8QlI+aW48QlI+WS4xNzMxLiAm bmJzcDtBbmQgd2hpY2ggaXMgd2h5IEkgb2Z0ZW4gDQogICAgICAgIHRyb3Qtb3V0IHRoZSByYXRo ZXIgc2lsbHkgKHRvIGhhdmUgdG88QlI+c2F5PEJSPnRoaXMpIG9ic2VydmF0aW9uIHRoYXQgDQog ICAgICAgIGlmIElQIChjbCBtb2RlKSBjb3VsZCBkbyBpdCBhbGwgdGhlbiB3aHkgaGF2ZTxCUj5J RVRGPEJSPmZvdW5kIGl0IA0KICAgICAgICBuZWNlc3NhcnkgdG8gY3JlYXRlIE1QTFMgKGNvLXBz KSBhbmQgR01QTFMgKENQIGZvciBjby1jcykuIA0KICAgICAgICAmbmJzcDtUaGU8QlI+YW5zd2Vy IGxpZXMgaW4gdGhlIHBoeXNpY3MuLi5hbmQgRy44MDAgYXR0ZW1wdHMgdG8gZXhwbGFpbiANCiAg ICAgICAgdGhhdDxCUj5waHlzaWNzLi4uLkcuODA1IGRvZXMgbm90LjxCUj48QlI+U28sIHRoZSAz IG1vZGVzIGFyZSANCiAgICAgICAgZGlmZmVyZW50Li4ucGxlYXNlIGFjY2VwdC9yZWpvaWNlIGlu IHRoaXMgZmFjdCBhczxCUj50aGV5PEJSPmFsbCBvZmZlciANCiAgICAgICAgc29tZXRoaW5nIGRp ZmZlcmVudC9pbXBvcnRhbnQuICZuYnNwO0J1dCBkbyBub3QgYmUgaG9vZHdpbmtlZCANCiAgICAg ICAgYnk8QlI+dGhvc2U8QlI+d2hvIHBlZGRsZSBhIHN0b3J5IHRoYXQgdGhhdCB0cmllcyB0byBt YWtlIHRoZSBPQU0gb2YgdGhlIA0KICAgICAgICAzIG1vZGVzIHRoZTxCUj5zYW1lLiA8QlI+PEJS PnJlZ2FyZHMsIE5laWwgPEJSPjxCUj4mZ3Q7IC0tLS0tT3JpZ2luYWwgDQogICAgICAgIE1lc3Nh Z2UtLS0tLTxCUj4mZ3Q7IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzxCUj4mZ3Q7IA0K ICAgICAgICBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERy YWtlLCBKb2huIEU8QlI+Jmd0OyANCiAgICAgICAgU2VudDogMTcgQXByaWwgMjAwOSAyMDowMjxC Uj4mZ3Q7IFRvOiBCVVNJIElUQUxPOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgDQogICAgICAgIE1h YXJ0ZW4gVmlzc2VyczxCUj4mZ3Q7IENjOiBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgU3ViamVj dDogUmU6IA0KICAgICAgICBbbXBscy10cF0gQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoIDxCUj4mZ3Q7IA0KICAgICAgICByZXF1aXJlbWVudHM8QlI+Jmd0OyA8QlI+Jmd0 OyBJdGFsbyw8QlI+Jmd0OyA8QlI+Jmd0OyBBcyBkZXNjcmliZWQgaW4gDQogICAgICAgIHRoZSBN UExTIFRQIE9BTSBSZXF1aXJlbWVudHMgSS1ELCB2aXJ0dWFsbHkgYWxsIG9mIHRoZTxCUj48QlI+ Jmd0OyBPQU0gDQogICAgICAgIGZ1bmN0aW9ucyByZXF1aXJlIGEgcmV0dXJuIHBhdGgsIGFuZCBp biB0aGUgYWJzZW5jZSBvZiBhIHJldHVybiA8QlI+Jmd0OyANCiAgICAgICAgcGF0aCB0aGV5IGFy ZSBkaXNhYmxlZC48QlI+Jmd0OyA8QlI+Jmd0OyBBcyBkZXNjcmliZWQgaW4gRGF2aWQgDQogICAg ICAgIFNpbmljcm9wZSdzIG1lZXRpbmcgbWludXRlcyA8QlI+Jmd0OyANCiAgICAgICAgKGh0dHA6 Ly93aWtpLnRvb2xzLmlldGYub3JnL21pc2MvbXBscy1pbnRlcm9wL2F0dGFjaG1lbnQvd2lraS88 QlI+Jmd0OyANCiAgICAgICAgbWVldGluZy1ubzxCUj4mZ3Q7IHRlcy8yMDA4MTAxNS5tcGxzLWlu dGVyb3AtZHQtbm90ZXMuemlwKSwgaWYgSVAgDQogICAgICAgIGFkZHJlc3NpbmcgaXMgdXNlZCwg YW4gPEJSPiZndDsgTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGJlIGNhcGFibGUgb2YgDQogICAg ICAgIGdldHRpbmcgSVAgcGFja2V0cyBmcm9tIDxCUj4mZ3Q7IGRlc3RpbmF0aW9uIHRvIHNvdXJj ZTsgbmVpdGhlciB0aGUgDQogICAgICAgIG1pbnV0ZXMgbm9yIEkgc3RpcHVsYXRlIHRoYXQgYSA8 QlI+Jmd0OyBjb250cm9sIHBsYW5lIG5lZWRzIHRvIGJlIHVzZWQgDQogICAgICAgIHRvIGluc3Rh bnRpYXRlIHRoaXMgZm9yd2FyZGluZy48QlI+Jmd0OyA8QlI+Jmd0OyBBcyBhbiBhc2lkZSwgdGhl IGlzc3VlIA0KICAgICAgICBvZiByZXR1cm4gcGF0aCBmb3IgdW5pZGlyZWN0aW9uYWwgTFNQcyBj b3VsZCBiZTxCUj48QlI+Jmd0OyBjaGFyYXRlcml6ZWQgDQogICAgICAgIGFzIHRoZSBlbGVwaGFu dCBpbiB0aGUgcm9vbS4gJm5ic3A7SW4gdGhlIE1QTFMgVFAgT0FNIDxCUj4mZ3Q7IEZyYW1ld29y ayANCiAgICAgICAgSS1ELCB1bmljYXN0IExTUHMgYXJlIG9ubHkgbWVudGlvbmVkIHRocmVlIHRp bWVzIGFuZCByZXR1cm4gPEJSPiZndDsgDQogICAgICAgIHBhdGhzIG5vdCBhdCBhbGwuPEJSPiZn dDsgPEJSPiZndDsgVGhhbmtzLDxCUj4mZ3Q7IDxCUj4mZ3Q7IEpvaG48QlI+Jmd0OyANCiAgICAg ICAgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgRnJvbTogQlVT SSBJVEFMTyANCiAgICAgICAgW21haWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0XTxC Uj4mZ3Q7ICZndDsgU2VudDogRnJpZGF5LCBBcHJpbCANCiAgICAgICAgMTcsIDIwMDkgMTo1OSBB TTxCUj4mZ3Q7ICZndDsgVG86IERyYWtlLCBKb2huIEU7IEFsZXhhbmRlciBWYWluc2h0ZWluOyAN CiAgICAgICAgTWFhcnRlbiBWaXNzZXJzPEJSPiZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9y ZzxCUj4mZ3Q7ICZndDsgU3ViamVjdDogDQogICAgICAgIFJFOiBbbXBscy10cF0gQXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIDxCUj4mZ3Q7ICZndDsgDQogICAgICAgIHJl cXVpcmVtZW50czxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBKb2huLDxCUj4mZ3Q7ICZndDsg PEJSPiZndDsgJmd0OyANCiAgICAgICAgSSBtaWdodCBoYXZlIG1pc3NlZCB0aGUgYWdyZWVtZW50 IG9mIE1QTFMtVFAgYmVpbmcgY2FwYWJsZSBvZiA8QlI+Jmd0OyANCiAgICAgICAgJmd0OyBzZW5k aW5nIHJlcGxpZXMgdG8gT0FNIHJlcXVlc3RzIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIA0KICAg ICAgICBMU1BzLjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBUaGlzIHJlcXVpcmVtZW50IGRv ZXMgbm90IGJlbG9uZyB0byB0aGUgDQogICAgICAgIGZpcnN0IHNldCBvZiByZXF1aXJlbWVudHMg PEJSPiZndDsgJmd0OyBJVFUtVCBpcyBleHBlY3RpbmcgdG8gYmUgbWV0IGJ5IA0KICAgICAgICBP Y3RvYmVyLjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBIb3dldmVyLCBJIHRoaW5rIHRoaXMg aW4gYSBwb3RlbnRpYWwgDQogICAgICAgIGludGVyZXN0aW5nIGFkZGl0aW9uYWwgPEJSPiZndDsg Jmd0OyByZXF1aXJlbWVudCB0byBiZSB0YWtlbiBpbnRvIA0KICAgICAgICBhY2NvdW50IChhdCB3 b3JzdCBpbiBhPEJSPiZndDsgc3Vic2VxdWVudCBwaGFzZSkuPEJSPiZndDsgJmd0OyA8QlI+Jmd0 OyANCiAgICAgICAgJmd0OyBJIHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlbWVudCBuZWVkcyB0byBi ZSBldmFsdWF0ZWQgdmVyc3VzIG90aGVyIA0KICAgICAgICA8QlI+Jmd0OyAmZ3Q7IG1vcmUgaW1w b3J0YW50IHJlcXVpcmVtZW50cyAoZS5nLiB0aGUgcG9zc2liaWxpdHkgdG8gd29yayANCiAgICAg ICAgdy9vIElQIDxCUj4mZ3Q7ICZndDsgZm9yd2FyZGluZyBhbmQgdGhlIG5lZWQgZm9yIE9BTSB0 byBjb250aW51ZSB0byANCiAgICAgICAgbW9uaXRvciB0aGUgZGF0YSA8QlI+Jmd0OyAmZ3Q7IHBs YW5lIGFsc28gaW4gY2FzZSBvZiBmYWlsdXJlcyBhZmZlY3RpbmcgDQogICAgICAgIHRoZSBjb250 cm9sIG9yIG1hbmFnZW1lbnQgPEJSPiZndDsgJmd0OyBwbGFuZSkuPEJSPiZndDsgJmd0OyA8QlI+ Jmd0OyANCiAgICAgICAgJmd0OyBJIGFtIG9wZW4gdG8gZGlzY3VzcyBpdCBidXQgbm90IHN1cmUg dGhpcyBpcyB0aGUgcmlnaHQgdGltZSBiZWNhdXNlIA0KICAgICAgICA8QlI+Jmd0OyAmZ3Q7IEkg d2lzaCB0byBhdm9pZCBkZWxheWluZyB0aGUgZmlyc3QgcGhhc2Ugb2YgdGhlIGRlc2lnbiANCiAg ICAgICAgc29sdXRpb24uPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IFRoYW5rcywgSXRhbG88 QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgRnJvbTogDQogICAgICAgIG1wbHMtdHAtYm91 bmNlc0BpZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgW21haWx0bzptcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEcmFrZSwgSm9obiBFPEJSPiZndDsgDQog ICAgICAgICZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgODowMCBQTTxC Uj4mZ3Q7ICZndDsgJmd0OyBUbzogDQogICAgICAgIEFsZXhhbmRlciBWYWluc2h0ZWluOyBNYWFy dGVuIFZpc3NlcnM8QlI+Jmd0OyAmZ3Q7ICZndDsgQ2M6IA0KICAgICAgICBtcGxzLXRwQGlldGYu b3JnPEJSPiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCAN CiAgICAgICAgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCA8QlI+Jmd0OyAmZ3Q7ICZndDsg cmVxdWlyZW1lbnRzPEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZn dDsgQXQgdGhlIG1lZXRpbmcgbGFzdCBmYWxsIGF0IEp1bmlwZXIgaW4gDQogICAgICAgIE1hc3Nh Y2h1c2V0dHMsIEk8QlI+Jmd0OyAmZ3Q7IHRoaW5rIGl0IHdhczxCUj4mZ3Q7ICZndDsgJmd0OyBh Z3JlZWQgdGhhdCANCiAgICAgICAgYW4gTVBMUyBUUCBuZXR3b3JrIG5lZWRzIHRvIGhhdmUgYSBm b3J3YXJkaW5nPEJSPiZndDsgJmd0OyANCiAgICAgICAgY2FwYWJpbGl0eTxCUj4mZ3Q7ICZndDsg Jmd0OyBmb3IgbWFuYWdlbWVudCwgY29udHJvbCwgYW5kIE9BTSBwYWNrZXRzIA0KICAgICAgICAo ZS5nLiwgc2VuZGluZzxCUj4mZ3Q7ICZndDsgcmVwbGllcyB0byBPQU08QlI+Jmd0OyAmZ3Q7ICZn dDsgcmVxdWVzdHMgDQogICAgICAgIHNlbnQgb24gdW5pLWRpcmVjdGlvbmFsIExTUHMpIGV2ZW4g aWYgaXQgZG9lcyBub3Q8QlI+Jmd0OyAmZ3Q7IGhhdmUgYW4gDQogICAgICAgIElQPEJSPiZndDsg Jmd0OyAmZ3Q7IGZvcndhcmRpbmcgZGF0YSBwbGFuZS48QlI+Jmd0OyAmZ3Q7ICZndDsgPEJSPiZn dDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogDQogICAgICAgIEFsZXhhbmRlciBWYWluc2h0ZWlu PEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tXTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IA0KICAgICAgICBUaHVy c2RheSwgQXByaWwgMTYsIDIwMDkgOTo1NyBBTTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBN YWFydGVuIA0KICAgICAgICBWaXNzZXJzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2M6IG1wbHMt dHBAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAgICZndDsgU3ViamVjdDogUmU6 IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQogICAg ICAgIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyBNYWFydGVuLDxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IEl0IHNlZW1zIHRoYXQgeW91J3ZlIGp1c3QgDQogICAgICAgIChpbXBs aWNpdGx5IGFuZCwgcHJvYmFibHksPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW5hZHZlcnRlbnRs eSkgc3RhdGVkIA0KICAgICAgICB0aGUgZm9sbG93aW5nOjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgICAgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01QTFMtVFAgT0FNIHdpbGwg DQogICAgICAgIG5vdCBldmVyIHN1cHBvcnQgTUlQIGxvb3BiYWNrIGZ1bmN0aW9uPEJSPiZndDsg Jmd0OyAoYW5kIGZhdWx0PEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IGxvY2FsaXph dGlvbiB3aGljaCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uICkgZm9yPEJSPiZndDsgDQogICAgICAg ICZndDsgdW5pZGlyZWN0aW9uYWwgUDJNUDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuZCBQMlAg cGF0aHMuPEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IElmIHRoaXMgc3RhdGVtZW50IGlzIGNvcnJlY3QsIA0KICAgICAgICB0aGlzIChJTUhP IGFuZCBGV0lXKTxCUj4mZ3Q7IHJhaXNlcyBhIHZhbGlkPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg DQogICAgICAgIHF1ZXN0aW9uOjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgDQogICAgICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lzIE1QTFMtVFAgYW4gDQogICAgICAgIGFwcHJvcHJp YXRlIHNvbHV0aW9uIGZvciB0aGVzZTxCUj4mZ3Q7IHR5cGVzIG9mIHRyYW5zcG9ydDxCUj4mZ3Q7 ICZndDsgDQogICAgICAgICZndDsgJmd0OyBwYXRocz88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGb3IgdGhlIA0KICAgICAgICByZWZlcmVuY2UsIElQL01Q TFMgcHJvdmlkZXMgdGhpcyBraW5kIG9mPEJSPiZndDsgJmd0OyBmdW5jdGlvbmFsaXR5IA0KICAg ICAgICB0b2RheTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZvciAodW5pZGlyZWN0aW9uYWwgLSBi dXQgaXQgZG9lcyBub3Qga25vdyANCiAgICAgICAgYW55IG90aGVyPEJSPiZndDsgJmd0OyB0eXBl KSBQMlAgTFNQczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFzIA0KICAgICAgICBkZXNjcmliZWQg aW4gUkZDIDQzNzkuIEFuZCBpdHMgZXh0ZW5zaW9uIHRvIFAyTVAgTFNQcyBzZWVtcyA8QlI+Jmd0 OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgZWFzeS4uLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICAmbmJzcDs8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWdhcmRzLDxCUj4mZ3Q7IA0KICAgICAg ICAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO1Nhc2hhPEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7 ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZn dDsgJmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9y ZyANCiAgICAgICAgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ108QlI+Jmd0OyAmZ3Q7IE9uIEJl aGFsZjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBPZiBNYWFydGVuIFZpc3NlcnMg W21hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tXTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgICBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMzoyNCBQTTxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFRvOiANCiAgICAgICAgJ0FkcmlhbiBGYXJyZWwnPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZn dDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNw b3J0IHBhdGggDQogICAgICAgIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50czxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyBB ZHJpYW4sPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQog ICAgICAgICZndDsmZ3Q7ICZsdDtxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7IA0KICAgICAgICAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIG5vZGVz IChpbmNsdWRpbmcgTUVQcywgTUlQcyBhbmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAgICZn dDsgb3RoZXIgaW50ZXJuYWw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyANCiAgICAgICAgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSBvZiBhIGNv LXJvdXRlZDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgDQog ICAgICAgICZuYnNwOyBwYXRoIGF0IGVhY2ggKHN1Yi0pbGF5ZXIgTVVTVCBiZSBhd2FyZSBvZiB0 aGUgcGFpcmluZzxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyByZWxhdGlvbnNoaXAgb2YgdGhlIGZvcndhcmQgDQogICAgICAgIGFu ZCB0aGUgYmFja3dhcmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8 QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgdHJhbnNwb3J0IHBhdGguPEJSPiZndDsgJmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZsdDtlbmQgcXVvdGUmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4m Z3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vIHdheSB0aGlzIGlz IGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gDQogICAgICAgIFRoYXQ8QlI+Jmd0OyAmZ3Q7ICZn dDsgaXMsIHRoZXJlIGlzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgKm5v dGhpbmcqIHRoYXQgY2FuIGJlIG9ic2VydmVkIGZyb20gYSBibGFjayBib3ggcG9pbnQgb2Y8QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7IHZpZXcgdGhhdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgcmVzdWx0cyBmcm9tIGFkaGVyaW5nIHRvIHRoaXMgDQogICAgICAgIHJlcXVpcmVtZW50 LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFlvdXIgDQog ICAgICAgIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIEl0IGlzIHZlcnkgbXVjaDxCUj4m Z3Q7IG9ic2VydmFibGUgDQogICAgICAgIGlmPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyBy ZXF1aXJlbWVudCBpcyBtZXQgZnJvbSBhIGJsYWNrIGJveCBwb2ludCANCiAgICAgICAgb2Ygdmll dy48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgTUlQIGZ1bmN0aW9ucyBjYW4gb25seSBwZXJm b3JtIHRoZSANCiAgICAgICAgTG9vcGJhY2sgd2hlbiB0aGVyZSBpcyBhIDxCUj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIA0KICAgICAgICB0cmFuc3BvcnQgcGF0 aC4gVGhlIE1QTFMtVFAgTEJNIHBhY2tldCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyByZWNlaXZl ZCANCiAgICAgICAgYXQgYSBNSVAgbmVlZHMgdG8gYmUgcmV0dXJuZWQgKGFzIExCUjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IHBhY2tldCkgdG8gDQogICAgICAgIHRoZSBvcmlnaW5hdGluZyBNRVAg ZnVuY3Rpb24gdmlhIHRoZSBvdGhlcjxCUj4mZ3Q7ICZndDsgZGlyZWN0aW9uIA0KICAgICAgICBv ZjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aC4gDQogICAgICAgIFRoaXMgb3RoZXI8QlI+Jmd0OyBkaXJlY3Rpb248QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyB3b3VsZCBub3QgYmUgDQogICAgICAgIGF2YWlsYWJsZSBpbiBhbiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IDxCUj4mZ3Q7ICZndDsgJmd0OyANCiAg ICAgICAgJmd0OyBwYXRoLi4uIGFuZCB0aHVzIHRoZSBsb29wYmFjayB0ZXN0PEJSPiZndDsgJmd0 OyAmZ3Q7IHdvdWxkIA0KICAgICAgICBmYWlsLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IFNpbWlsYXJseSwgd2hlbiB3ZSANCiAgICAgICAgaGF2ZSB0byBh cHBseSBUQ00gTUVQcyB0byBtb25pdG9yIGE8QlI+Jmd0OyAmZ3Q7IHNlZ21lbnQsIHRoZW48QlI+ Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgdGhpcyBpcyBwb3NzaWJsZSBpbiBhIGNvLXJv dXRlZCBiaWRpciB0cmFuc3BvcnQgDQogICAgICAgIHBhdGg8QlI+Jmd0OyBidXQgbm90IGluIGE8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhc3NvY2lhdGVkIGJpZGlyIA0KICAgICAgICB0cmFuc3Bv cnQgcGF0aC4gSW4gdGhlIGZpcnN0IGNhc2UgdGhlIFRDTSBNRVAgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgDQogICAgICAgIFNvdXJjZSBhbmQgU2luayBmdW5jdGlvbnMgYXJlIGNvLWxvY2F0ZWQg YW5kIGNhbjxCUj4mZ3Q7IGV4Y2hhbmdlIHdoYXQgDQogICAgICAgIGlzPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgY2FsbGVkICJyZW1vdGUgaW5mb3JtYXRpb24iIHdoaWNoIGlzIG5lY2Vzc2FyeSAN CiAgICAgICAgZm9yIHBlcmZvcm1hbmNlIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vbml0b3Jp bmcuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7IEluIHRoZSBsYXR0ZXIgY2FzZSB0 aGUgVENNIE1FUCBTb3VyY2UgYW5kIFNpbmsgZnVuY3Rpb25zPEJSPiZndDsgDQogICAgICAgICZn dDsgYXJlIGluIGUuZy4gPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgZGlmZmVyZW50IG5vZGVzIGlu IHRoZSBuZXR3b3JrIA0KICAgICAgICBhbmQgVENNIHdvdWxkIG5vdCBiZSBhYmxlPEJSPiZndDsg Jmd0OyB0byBwcm92aWRlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIHBlcmZvcm1h bmNlIG1vbml0b3JpbmcuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgDQogICAgICAgICZndDsgVGhlIGVudGlyZXR5IG9mIHRoZSBicmFja2V0dGVkIHRleHQg IihpbmNsdWRpbmcgTUVQcyw8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7IE1JUHMgYW5kIG90 aGVyPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgaW50ZXJuYWw8QlI+Jmd0OyAmZ3Q7ICZndDsgDQog ICAgICAgICZndDsgJmd0OyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIiBzaG91bGQgYmUgZGVs ZXRlZC4gSXQgZG9lcyANCiAgICAgICAgbm90PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgYWRkIHRv ICJUaGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBpbnRlcm1lZGlhdGUg bm9kZXMuIjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFlv dXIgDQogICAgICAgIHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuIFRoaXMgdGV4dCBtdXN0 IG5vdCBiZTxCUj4mZ3Q7ICZndDsgZGVsZXRlZCANCiAgICAgICAgYXQ8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyBhbGwuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7IA0K ICAgICAgICAmZ3Q7ICZndDsgQWN0dWFsbHksIEkgYW0gcXVpdGUgZmVkIHVwIGFib3V0IHRoaXMg cGVyc2lzdGVudDxCUj4mZ3Q7ICZndDsgDQogICAgICAgICZndDsgaW5zaXN0ZW5jZSBvbiB0aGU8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmNsdXNpb248QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAm Z3Q7ICZndDsgJmd0OyBvZiAiVGFuZGVtIENvbm5lY3Rpb24uIiBUaGUgZGVmaW5pdGlvbiB3aXRo aW4gdGhlIElUVS1UIA0KICAgICAgICBvZjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgdGVy bTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIGlzPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgcG9vcmx5PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBzcGVjaWZpZWQgDQog ICAgICAgIGFuZCBjb21lcyBmcm9tIHRoZSBtb25pdG9yaW5nIG9mIGEgcGF0aCB0aGF0IGlzPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIHBhcmFsbGVsIChpLmUuPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgdGFuZGVtKTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7 IHRvIHRoZSBkYXRhIHBhdGggYmVpbmcgbW9uaXRvcmVkLiBUaGlzIGRlZmluaXRpb24gb2YgVEM8 QlI+Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgc2VlbXMgdG8gYmUgYXQ8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyB2YXJpYW5jZSw8QlI+Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBhbmQgd291bGQgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gDQogICAgICAgIGJh bmQuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBkb24n dCB1bmRlcnN0YW5kIA0KICAgICAgICB3aGVyZSB5b3VyIGludGVycHJldGF0aW9uIG9mIHRhbmRl bTxCUj4mZ3Q7ICZndDsgY29ubmVjdGlvbiBpczxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsg Jmd0OyBkZXNjcmliZWQgaW4gSVRVLVQgcmVjb21tZW5kYXRpb25zLiBJLmUuICJmcm9tIA0KICAg ICAgICB0aGU8QlI+Jmd0OyAmZ3Q7IG1vbml0b3Jpbmcgb2YgYTxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IHBhdGggdGhhdCBpcyANCiAgICAgICAgcGFyYWxsZWwgKGkuZS4gdGFuZGVtKSB0byB0aGUg ZGF0YSBwYXRoIGJlaW5nIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBtb25pdG9y ZWQuIj88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVy ZSBpcyBhIA0KICAgICAgICAibmV0d29yayBjb25uZWN0aW9uIiBhbmQgdGhpcyBuZXR3b3JrPEJS PiZndDsgJmd0OyBjb25uZWN0aW9uIGlzIGEgDQogICAgICAgIHNldDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IG9mIGludGVyY29ubmVjdGVkICJsaW5rIGNvbm5lY3Rpb25zIiBhbmQgDQogICAgICAg ICJtYXRyaXg8QlI+Jmd0OyBjb25uZWN0aW9ucyIuIEE8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBz dWJzZXQgb2YgdGhvc2UgDQogICAgICAgIGludGVyY29ubmVjdGVkIGxpbmsgY29ubmVjdGlvbnMg YW5kIG1hdHJpeCA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgY29ubmVjdGlvbnMg Y2FuIGJlIG1vbml0b3JlZCBhbmQgaXMgdGhlbiByZWZlcnJlZCB0byBhczxCUj4mZ3Q7IGEgDQog ICAgICAgICJ0YW5kZW08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBjb25uZWN0aW9uIi4gVGhlcmUg aXMgbm8gInBhdGggdGhhdCBpcyANCiAgICAgICAgcGFyYWxsZWwgdG8gdGhlPEJSPiZndDsgJmd0 OyBkYXRhIHBhdGgiLiA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSANCiAgICAgICAgaXMg b25seSBhZGRpdGlvbmFsIE9BTSBpbnNlcnRlZCBpbnNpZGUgdGhlIGRhdGE8QlI+Jmd0OyBwYXRo IGJ5IA0KICAgICAgICB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUQ00gTUVQX1NvIGZ1bmN0 aW9uIGFuZCB0aGlzIE9BTSBpcyBleHRyYWN0ZWQgDQogICAgICAgIGZyb20gdGhlPEJSPiZndDsg Jmd0OyBkYXRhIHBhdGggYnk8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgVENNIE1FUF9TayAN CiAgICAgICAgZnVuY3Rpb24uPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgDQogICAgICAgIFJlZ2FyZHMsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgTWFhcnRl bjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0 OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIA0KICAgICAgICBNZXNzYWdl LS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGcm9tOiANCiAgICAgICAgbXBscy10cC1ib3Vu Y2VzQGlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIFttYWlsdG86bXBs cy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbDxCUj4mZ3Q7 IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyBTZW50OiBkb25kZXJkYWcgMTYgYXByaWwgMjAwOSAx MTo1OTxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgJmd0OyBUbzogQWxleGFuZGVyIFZhaW5z aHRlaW47IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPEJSPiZndDsgDQogICAgICAgICZn dDsgJmd0OyAmZ3Q7IENjOiBCVVNJIElUQUxPOyBtcGxzLXRwQGlldGYub3JnPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogICAgICAgIFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIDxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsg Jmd0OyByZXF1aXJlbWVudHM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZn dDsgDQogICAgICAgICZndDsgSGkgU2FzaGEsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBm dWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50OjxCUj4mZ3Q7ICZndDsgDQogICAgICAgICZn dDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7cXVvdGUmZ3Q7PEJS PiZndDsgJmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBGcm9tIHRo ZSBwb2ludCBvZiB2aWV3IG9mIGhhcmR3YXJlLCANCiAgICAgICAgY28tcm91dGVkPEJSPiZndDsg Jmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgICAmZ3Q7ICZuYnNwOyAmbmJzcDsgYXJlIGEgc3BlY2lhbCBjYXNlIG9mIGFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbCANCiAgICAgICAgTFNQcy48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZsdDtlbmQgcXVvdGUmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDs8 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoaXMgc3RhdGVtZW50IHdvdWxkIGJlIG9idmlv dXNseSANCiAgICAgICAgY29ycmVjdCwgd2VyZSBpdCBub3QgZm9yPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgUmVxdWlyZW1lbnQ8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyAz NCBpbiB0aGUgbGF0ZXN0IE1QTFMtVFAgcmVxdWlyZW1lbnRzIGRyYWZ0PEJSPiZndDsgJmd0OyAN CiAgICAgICAgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9LLiBHb3QgaXQuPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJ1 dCB3aGF0IGlzIHRoaXMgZG9pbmcgaW4gdGhlIGRhdGEgcGxhbmUgDQogICAgICAgIHJlcXVpcmVt ZW50cyBzZWN0aW9uPzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IEluIA0KICAgICAgICBmYWN0LCB3aGF0IGlzIHRoaXMgcmVxdWlyZW1lbnQgYWN0dWFsbHkg c2F5aW5nPzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICA8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZsdDtxdW90ZSZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0K ICAgICAgICAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBpbnRlcm1lZGlhdGUgbm9kZXMgKGluY2x1 ZGluZyBNRVBzLCBNSVBzIA0KICAgICAgICBhbmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgb3RoZXIgaW50 ZXJuYWw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAgICAgJm5ic3A7 ICZuYnNwOyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUpIG9mIGEgY28tcm91dGVkPEJSPiZndDsg Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0PEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IA0KICAgICAgICAmbmJzcDsgcGF0aCBh dCBlYWNoIChzdWItKWxheWVyIE1VU1QgYmUgYXdhcmUgb2YgdGhlIHBhaXJpbmc8QlI+Jmd0OyAN CiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGlv bnNoaXAgb2YgdGhlIGZvcndhcmQgYW5kIA0KICAgICAgICB0aGUgYmFja3dhcmQ8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBkaXJlY3Rpb25zIG9mIHRoYXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAg ICAgICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFuc3BvcnQgcGF0aC48QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0OzxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBUaGVyZSBp cyBubyB3YXkgdGhpcyBpcyBhIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnQuIFRoYXQ8QlI+Jmd0OyAm Z3Q7IGlzLCANCiAgICAgICAgdGhlcmUgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAqbm90aGlu ZyogdGhhdCBjYW4gYmUgb2JzZXJ2ZWQgZnJvbSBhIA0KICAgICAgICBibGFjayBib3ggcG9pbnQg b2Y8QlI+Jmd0OyAmZ3Q7IHZpZXcgdGhhdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlc3VsdHMg DQogICAgICAgIGZyb20gYWRoZXJpbmcgdG8gdGhpcyByZXF1aXJlbWVudC48QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgVGhlcmVmb3JlIGl0 IGNvdWxkIGJlIGFzc3VtZWQgdGhhdCB0aGlzIHJlcXVpcmVtZW50IGlzIG1ldCBieSANCiAgICAg ICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgY29uZmlndXJpbmcgc29tZSBkYXRhIHBsYW5lIGRh dGFiYXNlIGNvbXBvbmVudCANCiAgICAgICAgdGhyb3VnaCB0aGUgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgbWFuYWdlbWVudCBwbGFuZS4gVGhlIGRhdGFiYXNlIA0KICAgICAgICBjb21wb25lbnQg aXMgbm90IHVzZWQ8QlI+Jmd0OyBmb3IgYW55dGhpbmc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBl eGNlcHQgDQogICAgICAgIHRvIHNhdGlzZnkgdGhpcyByZXF1aXJlbWVudCBmb3IgImF3YXJlbmVz cyIuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIDxCUj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IEJlbiEgQ2FuIHdlIHBsZWFzZSB0cnkgdG8gcmV3cml0ZSB0aGlzIA0KICAgICAgICByZXF1 aXJlbWVudCBpbiB0ZXJtcyBvZiA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBiZWhhdmlvcj88QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBQbGVhc2Ugbm90ZSB0aGF0IFJlcXVpcmVtZW50IDM0IA0KICAgICAgICBpcyB0aGUgT05MWSBp dGVtIGluIHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxpc3QgdGhhdCBpczxCUj4mZ3Q7ICZn dDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IHNwZWNpZmljIGZvciBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1BzLiAoVGhlIA0KICAgICAgICBwYWlyaW5nPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgcmVxdWlyZW1lbnRzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgYXQg ZW5kIHBvaW50cyBmb3IgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWw8QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7IHBhdGhzIGFyZTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgZXhhY3RseSB0aGUgc2FtZSBldmVuIGlmIHRoZXkgDQogICAgICAgIGFwcGVhciBpbiB0 d28gZGlmZmVyZW50PEJSPiZndDsgJmd0OyAmZ3Q7IGl0ZW1zIGluIHRoZTxCUj4mZ3Q7ICZndDsg Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7IHJlcXVpcmVtZW50cycgbGlzdCkuPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBJbiBvdGhlciANCiAgICAgICAgd29yZHMsIHdpdGhvdXQgUmVxdWly ZW1lbnQgMzQgdGhlIG5vdGlvbiBvZjxCUj4mZ3Q7IGNvLXJvdXRlZDxCUj4mZ3Q7IA0KICAgICAg ICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgcGF0aHMgd291bGQgYmUgdm9pZCBv ZiBhbnkgZGF0YSBwbGFuZSANCiAgICAgICAgY29udGVudC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgDQogICAgICAgIHNvbWV3aGF0 IHZhZ3VlIHNjb3BlIG9mIHRoaXMgcmVxdWlyZW1lbnQgKCJvdGhlciBpbnRlcm5hbCA8QlI+Jmd0 OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyBmdW5jdGlvbnMgYXMgYXBwcm9wcmlhdGUi KSBjcmVhdGVzIGEgc3VzcGljaW9uIHRoYXQgDQogICAgICAgIEhXPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgc3VwcG9ydCBvZiB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAg ICBwYWlyaW5nIGF3YXJlbmVzcyBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIgdG8gY29tcGx5IHdp dGggaXQuPEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFRoZSBlbnRpcmV0eSBvZiB0aGUgYnJhY2tldHRlZCANCiAgICAgICAgdGV4dCAiKGlu Y2x1ZGluZyBNRVBzLDxCUj4mZ3Q7ICZndDsgTUlQcyBhbmQgb3RoZXI8QlI+Jmd0OyAmZ3Q7ICZn dDsgDQogICAgICAgICZndDsgaW50ZXJuYWwgZnVuY3Rpb25zIGFzIGFwcHJvcHJpYXRlKSIgc2hv dWxkIGJlIGRlbGV0ZWQuIEl0PEJSPiZndDsgDQogICAgICAgICZndDsgZG9lcyBub3Q8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyBhZGQgdG8gIlRoZSBpbnRlcm1lZGlhdGUgDQogICAgICAgIG5vZGVz LiI8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRo ZSANCiAgICAgICAgZm9sbG93aW5nIHRleHQgaW4gdGhlIGRyYWZ0IGluY3JlYXNlcyB0aGlzIHN1 c3BpY2lvbjo8QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAgICZndDsgJmd0OzxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJmx0O3F1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAg ICAgJmd0OyAmZ3Q7ICZuYnNwOyBUYW5kZW0gQ29ubmVjdGlvbjogQSB0YW5kZW0gY29ubmVjdGlv biBpcyBhbjxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7IGFyYml0cmFyeSBwYXJ0IG9mIGE8QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyB0cmFuc3BvcnQgDQogICAgICAgIHBhdGggdGhh dCBjYW4gYmUgbW9uaXRvcmVkICh2aWEgT0FNKTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAg ICAgICBpbmRlcGVuZGVudGx5IGZyb20gdGhlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgZW5kLXRvLWVuZCANCiAgICAgICAgbW9uaXRvcmluZyAoT0FNKS4gJm5ic3A7SXQgbWF5 IGJlIGEgbW9uaXRvcmVkPEJSPiZndDsgJmd0OyBzZWdtZW50IG9yIA0KICAgICAgICBhPEJSPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgbW9uaXRvcmVkIGNvbmNhdGVuYXRlZCBzZWdt ZW50IG9mIGEgDQogICAgICAgIHRyYW5zcG9ydCBwYXRoLiAmbmJzcDs8QlI+Jmd0OyAmZ3Q7IFRo ZSB0YW5kZW08QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgJmd0OyAmbmJzcDsgY29u bmVjdGlvbiBtYXkgYWxzbyBpbmNsdWRlIHRoZSBmb3J3YXJkaW5nIGVuZ2luZShzKSANCiAgICAg ICAgb2Y8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgbm9kZShzKTxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7IA0KICAgICAgICBhdCB0aGUgZWRnZShzKSBvZiB0aGUgc2VnbWVu dCBvciBjb25jYXRlbmF0ZWQgc2VnbWVudC48QlI+Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAgICZn dDsgJmd0OyAmbHQ7ZW5kIHF1b3RlJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7 ICZndDsgJmd0OyANCiAgICAgICAgJmd0OyBBY3R1YWxseSwgSSBhbSBxdWl0ZSBmZWQgdXAgYWJv dXQgdGhpcyBwZXJzaXN0ZW50PEJSPiZndDsgJmd0OyANCiAgICAgICAgaW5zaXN0ZW5jZSBvbiB0 aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmNsdXNpb24gb2YgIlRhbmRlbSANCiAgICAgICAg Q29ubmVjdGlvbi4iIFRoZSBkZWZpbml0aW9uIHdpdGhpbjxCUj4mZ3Q7ICZndDsgdGhlIElUVS1U IG9mPEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IHRoaXMgdGVybSBpcyBwb29ybHkg c3BlY2lmaWVkIGFuZCBjb21lcyBmcm9tIHRoZTxCUj4mZ3Q7IA0KICAgICAgICBtb25pdG9yaW5n IG9mIGE8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXRoIHRoYXQgaXMgcGFyYWxsZWwgKGkuZS4g DQogICAgICAgIHRhbmRlbSkgdG8gdGhlIGRhdGEgcGF0aCBiZWluZyA8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyBtb25pdG9yZWQuIFRoaXMgDQogICAgICAgIGRlZmluaXRpb24gb2YgVEMgc2VlbXMg dG8gYmUgYXQgdmFyaWFuY2UsPEJSPiZndDsgJmd0OyBhbmQgd291bGQ8QlI+Jmd0OyANCiAgICAg ICAgJmd0OyAmZ3Q7ICZndDsgYmUgaWYgdGhlIEFDSCB3YXMgYWN0dWFsbHkgaW4gYmFuZC48QlI+ Jmd0OyAmZ3Q7ICZndDsgDQogICAgICAgICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBEb2Vzbid0ICJmb3J3YXJkaW5nIGVuZ2luZSIgc291bmQgbGlrZSANCiAgICAgICAgaGFyZHdh cmUgdG8geW91PzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFllcywgYnV0IA0KICAgICAgICBzbyB3aGF0PzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSU1ITyBpdCBpcyANCiAgICAgICAgd29ydGggbm90aW5n IHRoYXQgbmVpdGhlciB0aGUgTVBMUy1UUDxCUj4mZ3Q7ICZndDsgJmd0OyBSZXF1aXJlbWVudHMg DQogICAgICAgIGRyYWZ0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBub3IgdGhlIE1QTFMt VFAgT0FNIHJlcXVpcmVtZW50cyANCiAgICAgICAgb25lPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7 IDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgDQogICAgICAgIChodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVtZW48QlI+Jmd0OyAN CiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0cy0wMS50eHQpIGNvbnRhaW4gYW55IHJlcXVp cmVtZW50cyBkZWFsaW5nIHdpdGggDQogICAgICAgIHRhbmRlbTxCUj4mZ3Q7ICZndDsgJmd0OyBj b25uZWN0aW9ucy48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgJmd0OzxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0IHRhbmRlbSBjb25uZWN0aW9ucyBhcmUgZGlzY3Vzc2Vk IGluIA0KICAgICAgICB0aGUgTVBMUy1UUCBPQU08QlI+Jmd0OyAmZ3Q7IEZyYW1ld29yazxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIGRyYWZ0PEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgDQogICAgICAgIChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLW1wbHMtdHAtb2FtLWZyPEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7IGFt ZXdvcmstMDAudHh0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgKS48QlI+Jmd0OyAmZ3Q7IA0KICAg ICAgICAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgUmlnaHQuPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgTGV0J3MgDQogICAgICAgIGp1c3QgZ2V0IHJpZCBvZiBhbiB1bm5lY2Vzc2Fy eSB0ZXJtIGFuZCBicmluZyBhbGw8QlI+Jmd0OyB0aGUgDQogICAgICAgIEktRHM8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBpbnRvIGxpbmUuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsg DQogICAgICAgICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGJvdHRvbSBsaW5lLCBJTUhPLCBpcyB0 aGF0IHNvbWUgY2xhcml0eSANCiAgICAgICAgcmVnYXJkaW5nPEJSPiZndDsgJmd0OyAmZ3Q7IGNv LXJvdXRlZCB2cy48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBhc3NvY2lh dGVkPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWRpcmVjdGlvbmFsIHBhdGhzIGlzIHN0 aWxsIA0KICAgICAgICByZXF1aXJlZC4gT25lIHdheSB0byBwcm92aWRlPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgdGhhdCBjb3VsZDxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGJlIGJ5IGV4cGxpY2l0bHkgbGltaXRpbmcgUmVxdWlyZW1lbnQgMzQgdG8gDQogICAgICAgIHNw ZWNpZmljPEJSPiZndDsgJmd0OyAmZ3Q7IGZ1bmN0aW9uYWxpdHkuPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgDQogICAgICAgIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFncmVlZC48QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgQWRyaWFuPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgDQog ICAgICAgICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7IA0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogDQogICAgICAgIEFkcmlhbiBGYXJy ZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogDQog ICAgICAgIFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAxMjoxMyBBTTxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFRvOiBBbGV4YW5kZXIgDQogICAgICAgIFZhaW5zaHRlaW47IExvdSBCZXJnZXI7IEJV U0kgSVRBTE88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBDYzogDQogICAgICAgIG1wbHMtdHBAaWV0 Zi5vcmc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIA0KICAg ICAgICBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggPEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDsgDQogICAgICAgIHJlcXVpcmVtZW50czxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpIA0KICAgICAgICBTYXNoYSw8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBOb3QgcmVhbGx5IHN1cmUgDQogICAg ICAgIHdoZXRoZXIgeW91IGFyZSBtaXNyZXByZXNlbnRpbmcgYW55b25lLCBidXQuLi48QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAx LiBNeSByZWFkaW5nIG9mICZuYnNwO29uZSBvZiBCZW4ncyANCiAgICAgICAgJm5ic3A7bWVzc2Fn ZXMgaXMgdGhhdCBhc3NvY2lhdGVkIDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAg ICAgIGJpZGlyZWN0aW9uYWwgcGF0aHMgYXJlIHRoZSBvbmx5IHR5cGVzIG9mIHBhdGhzIHRoYXQg Y2FuIGJlPEJSPiZndDsgJmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7IGNyZWF0ZWQgaW48QlI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBleGlzdGluZyBuZXR3b3JrczsgDQogICAgICAgICJ0 cnVlIiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwYXRoczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHdpbGwgDQogICAgICAgIGhhdmU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRvIHdhaXQg dW50aWwgKGlmIGV2ZXIpIG5ldyBlcXVpcG1lbnQgDQogICAgICAgIGJlY29tZXMgYXZhaWxhYmxl LjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoaXMgDQog ICAgICAgIGlzIGNsZWFybHkgbm9uc2Vuc2UhPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiANCiAgICAgICAgaGFyZHdhcmUsIGNvLXJvdXRlZDxCUj4mZ3Q7 ICZndDsgYmlkaXJlY3Rpb25hbCBMU1BzIGFyZTxCUj4mZ3Q7ICZndDsgDQogICAgICAgICZndDsg Jmd0OyBhIHNwZWNpYWwgY2FzZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy48QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYg eW91IGNhbiBzZXQgdXAgdHdvIHVuaWRpcmVjdGlvbmFsIA0KICAgICAgICBMU1BzIChlLmcuIHVz aW5nIHRoZTxCUj4mZ3Q7ICZndDsgbWFuYWdlbWVudDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0K ICAgICAgICBwbGFuZSkgeW91IGNhbiBzdXJlbHkgc2V0IHVwIGEgY28tcm91dGVkPEJSPiZndDsg Jmd0OyAmZ3Q7IGJpZGlyZWN0aW9uYWwgDQogICAgICAgIExTUC48QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgc2hpcHBpbmcgDQogICAgICAg IHNvbHV0aW9ucyB0aGF0IGFjaGlldmUgY28tcm91dGVkPEJSPiZndDsgYmlkaXJlY3Rpb25hbDxC Uj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgJmd0OyBMU1BzIHVzaW5nIHRoZSBjb250cm9sIHBs YW5lLiBUaGVzZSBlaXRoZXIgdXNlIHRoZSBHTVBMUzxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7ICh3 aGljaCBpczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNsZWFuZXIpIG9yIG5vbi1zdGFuZGFyZCAN CiAgICAgICAgcHJvcHJpZXRhcnkgc29sdXRpb25zICh3aGljaCBpczxCUj4mZ3Q7ICZndDsgbWVz c3kgYnV0PEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7IGZ1bmN0aW9uYWwpLjxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJ1dCAob2YgDQogICAg ICAgIGNvdXJzZSkgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3IgY29udHJvbCBwbGFuZTxCUj4mZ3Q7 ICZndDsgc29sdXRpb25zIA0KICAgICAgICBoYXZlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbm90 aGluZyB0byBkbyB3aXRoIGF2YWlsYWJpbGl0eSBvZiBlcXVpcG1lbnQgDQogICAgICAgIGFzIHRo ZXk8L1RUPjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj48VFQ+Jmd0OyBhcmUgc29mdHdhcmU8QlI+ Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgc29sdXRpb25zLjxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIDIuIE15IHJlYWRp bmcgb2Ygb25lIG9mIE5laWwncyBtZXNzYWdlcyBpcyB0aGF0IHRoZSBhY3R1YWw8QlI+Jmd0OyAm Z3Q7IA0KICAgICAgICAmZ3Q7ICZndDsgZHJpdmVyIGZvcjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgDQogICAgICAgIHBhdGhzIG1heSBiZSBleHBl cmllbmNlIHdpdGggZXhpc3RpbmcgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyANCiAgICAg ICAgdHJhbnNwb3J0IG5ldHdvcmtzIHJhdGhlciB0aGFuIGFueSBzcGVjaWZpYyBiZW5lZml0LjxC Uj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICAgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJ c24ndCB0aGF0IHRoZSBjYXNlIHdpdGggNzUlIG9mIHRoZSBNUExTLVRQIA0KICAgICAgICByZXF1 aXJlbWVudHM/PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgV2hpY2ggaXMgbm90IHRvIHNheSBpdCBp cyBhIGJhZCANCiAgICAgICAgdGhpbmcuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDsgQSBsYXJnZSBkcml2ZXIgZm9yIA0KICAgICAgICBNUExTLVRQIGlzIHRv IGdpdmUgdGhlIHBhY2tldCBuZXR3b3JrPEJSPiZndDsgJmd0OyB0aGUgbG9vayw8QlI+Jmd0OyAN CiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgZmVlbCwgYW5kIGJlaGF2aW9yYWwgY2hhcmFjdGVyaXN0 aWNzIG9mIGEgDQogICAgICAgICJsZWdhY3kiPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgdHJhbnNw b3J0IG5ldHdvcmsuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7IDxCUj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgQmFzZWQgb24gdGhlc2Ugb2JzZXJ2YXRpb25zLCBJJ2QgZ3Vlc3Mg DQogICAgICAgIChGV0lXKSB0aGF0OjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKiBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgDQogICAgICAgIHBhdGhzIGFyZSwgYXQgbGVhc3QgZm9yIHRo ZSB0aW1lPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgDQogICAgICAgICZuYnNw O2JlaW5nLCB0aGUgbW9zdCBpbXBvcnRhbnQgdHlwZSBvZiBiaWRpcmVjdGlvbmFsIHBhdGhzIGlu PEJSPiZndDsgDQogICAgICAgICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO01QTFMt VFA8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8QlI+Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZn dDsgSSB0aGluayB0aGF0IGlzIHdyb25nIGJvdGggZ2l2ZW4gbXkgc3RhdGVtZW50IGFib3ZlLCAN CiAgICAgICAgYW5kPEJSPiZndDsgJmd0OyBnaXZlbiB0aGF0PEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgb3RoZXIgdXBncmFkZXMgdG8gDQogICAgICAgIGV4aXN0aW5nIE1QTFMgc29sdXRpb25zIHdp bGwgYmU8QlI+Jmd0OyBuZWVkZWQgdG8gcmVhY2g8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICAmZ3Q7 ICZndDsgdGhlIGZ1bGwgZnVuY3Rpb24gbGV2ZWwgb2YgTVBMUy1UUC48QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyANCiAgICAgICAgPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAqIHRoZXkgaGFk IGEgZ29vZCBjaGFuY2UgdG8gcmVtYWluIHRoZSBvbmx5IA0KICAgICAgICB0eXBlIG9mPEJSPiZn dDsgJmd0OyBiaWRpcmVjdGlvbmFsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg DQogICAgICAgIHBhdGhzIGluICZuYnNwO3JlYWwgZGVwbG95bWVudHMuPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgPEJSPiZndDsgJmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7IEkgZG9uJ3Qgc2VlIHdo YXQgdGhhdCBmb2xsb3dzIGZyb20uPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIDxC Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IENoZWVycyw8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBBZHJp YW48QlI+Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7ICZn dDsgDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIG1wbHMtdHAgbWFpbGluZyBsaXN0 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7IA0KICAgICAg ICAmZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMtdHA8QlI+Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7 ICZndDsgDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgDQogICAgICAgIG1wbHMtdHAgbWFpbGluZyBs aXN0PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgbXBscy10cEBpZXRmLm9yZzxCUj4mZ3Q7IA0KICAg ICAgICAmZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtdHA8QlI+Jmd0OyANCiAgICAgICAgJmd0OyAmZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDsgPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7ICZndDsgJmd0OyANCiAgICAgICAg bXBscy10cCBtYWlsaW5nIGxpc3Q8QlI+Jmd0OyAmZ3Q7ICZndDsgbXBscy10cEBpZXRmLm9yZzxC Uj4mZ3Q7ICZndDsgDQogICAgICAgICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzLXRwPEJSPiZndDsgJmd0OyAmZ3Q7IA0KICAgICAgICA8QlI+Jmd0OyAmZ3Q7 IDxCUj4mZ3Q7IA0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxCUj4mZ3Q7IG1wbHMtdHAgbWFpbGluZyANCiAgICAgICAgbGlzdDxCUj4mZ3Q7 IG1wbHMtdHBAaWV0Zi5vcmc8QlI+Jmd0OyANCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPEJSPiZndDsgDQogICAgICAgIDxCUj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5tcGxzLXRwIG1haWxpbmcg DQogICAgICAgIGxpc3Q8QlI+bXBscy10cEBpZXRmLm9yZzxCUj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8L1RUPjwvRk9OVD48Rk9OVCANCiAgICAgICAgc2l6 ZT0zPjxCUj48QlI+PC9GT05UPjxCUj48Rk9OVCANCiAgICAgICAgc2l6ZT0zPjxUVD4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5aVEUg DQogICAgICAgIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQogICAgICAgIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUg c2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCiAgICAg ICAgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSANCiAgICAgICAgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQogICAgICAgIG90aGVy cy48QlI+VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCANCiAgICAgICAgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IA0KICAgICAgICBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgDQogICAgICAgIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgDQogICAgICAgIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci48QlI+VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIA0KICAgICAg ICB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxCUj48L1RUPjwvRk9O VD48QlI+PEJSPjxQUkU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L1BSRT48L0JMT0NLUVVPVEU+PC9C TE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C9C72D.B4DE7D38-- From maarten.vissers@huawei.com Mon Apr 27 05:26:56 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6873A69CC for ; Mon, 27 Apr 2009 05:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.341 X-Spam-Level: **** X-Spam-Status: No, score=4.341 tagged_above=-999 required=5 tests=[AWL=-3.215, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTMLKbNwV43Y for ; Mon, 27 Apr 2009 05:26:49 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B01513A68AF for ; Mon, 27 Apr 2009 05:26:48 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR004OSEMM9J@szxga01-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 20:27:59 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR00K1BEMMTA@szxga01-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 20:27:58 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIR00G4AEM28C@szxml01-in.huawei.com>; Mon, 27 Apr 2009 20:27:58 +0800 (CST) Date: Mon, 27 Apr 2009 14:27:41 +0200 From: Maarten Vissers In-reply-to: To: andy.bd.reid@bt.com Message-id: <002a01c9c733$92015470$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_K8ad5CbAgpMczYPcX2Hk2Q)" Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:26:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_K8ad5CbAgpMczYPcX2Hk2Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, =20 I have the impression that you do not have the correct understanding of = the SNC protection switching fucntional models and the location and control = of AIS insertion. Your understanding seems not aligned with the = specifications in our equipment and protection swithcing recommendations. See inline... _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 12:50 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 It is of course true that adding a boolean input to a logical system increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you identify below. There are=20 =20 - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these input states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly.=20 =20 [mv] I don't think that there is only "hope". This condition reflects = that there is no disconnect.=20 If every frame/packet arrives correctly is not checked by the reception = of CC and correct MEGID/MEPID. Frame/packet loss is checked by the = frame/packet loss measurement that is embedded in the CCM frames, and can be = activated.=20 =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below).=20 =20 [mv] With equipment that complies with the equipment standards this condition doesn't give you just "hope". It gives you "knowledge" that = the discontinutity experienced in the connection is due to a server layer = fault. =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending on = the exact scope of the forwarding labels, a protection switch may well = require the proactive purging of entries from the AIS forwarding label injection table following the protection switch (this could equivalently been seen = as the forwarding function proactively dropping the AIS packets).=20 =20 [mv] I don't think that those scenarios are likely scenarios. Equipment compliant with ITU-T's equipment recommendations will not have those scenarios. Only equipment that does not comply with those equipment recommendations could have such scenarios. Just do not deploy such equipment. =20 [mv] The AIS insertion in the functional models is performed in the Adaptation Sink functions. Those Adaptation Sink functions are connected = to the Connection function in which the SNC Protection process is located. = The AIS insertion in an Adaptation sink fucntion continues independent of = the state of the protection switch process in the Connection function; i.e. = the selector in the protection process will only receive frames/packets from either the working SNC, or the protection SNC (but never from both).=20 =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a forwarding function. But it could equally arise from a misconfiguration of the AIS forwarding label injection table. In fact, the latter actually seems = just as likely and particularly problematic for maintenance. Unlike normal forwarding, any mismatch between the forwarding configuration and the = AIS forwarding label injection table will lie dormant and until a server = fault arises. Then this generates a false and misunderstood fault condition = with maintenance looking for the fault in the wrong place.=20 =20 [mv] As indicated in the above comment, equipment compliant with the equipment and protection switching recommendation will not behave as you suggest. Only equipment not-compliant with our equipment/protection switching recommendation may do this, but such equipment should simply = not be deployed. =20 [mv] AIS generation is performed in the adaptation sink function for the = set of active client signals; i.e. for the set of connection/flow points = that are activated on the adaptation sink function (which are represented by = the set of active labels/VIDs/...). There is no "AIS forwarding label = injection table" in any of our equipment recommendations. AIS will be generated = for each client CI output on the set of CPs/FPs on the adaptation sink = function when aAIS consequent action condition is true. =20 =20 The first two states can be reliably diagnosed with CC alone. The second = two arise from the introduction of the AIS/FDI. However, any possible = benefit that might arise is completely masked by the fact that the AIS itself = must be configured and there is no reason for this to be more reliable than = what it is supposed to be monitoring. Indeed, there seems good reason to = think that it will be less reliable.=20 =20 [mv] You are turning things upside down... CC is present to detect continuity and connectivity problems introduced in the layer network's Connection functions. As such you can not diagnose the second state with = CC alone. With CC alone one of your colleagues will be requested to = initiate a number of Loopback tests to find out which connection function is misconfigured. This is the wrong action of course, as there is a server layer fault. =20 [mv] You do not understand the AIS "configuration" aspect. AIS = generation configuration is on the node, not on each individual connection. = Networks that deploy AIS have it active on all their NNIs.=20 =20 There is no avoiding that AIS in circuit switching is fundamentally different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something and = the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured.=20 =20 [mv] In packet transport networks with connectivity checking no packets = is not a valid condition.=20 =20 [mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require any individual client connection specific information.=20 =20 [mv] ATM VP AIS and ATM VC AIS does not require any individual client = (i.e. VP, VC) connection specific information.=20 =20 [mv] ETH AIS does not require any individual client connection identification specification, but it requires reuse of the client MEG = Level information which is also required for the ETH MIP functions on the interface port. =20 [mv] I.e. AIS insertion does not require individual client connection specific information. Either no additional information at all is = required, or additional information is required that is shared with other fucntions/processes in the interface. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the operational = systems and processes are the same.=20 =20 [mv] And that is exactly what we do with support of AIS in packet = transport networks (ATM, Ethernet, T-MPLS =3D> MPLS-TP).=20 =20 The simple CC replicates all the triggers to management systems made by SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data plane AIS requires a whole new area of configuration and generates a = whole new set of fault conditions which cannot be localised by SONET/SDH processes. So, ironically, packet AIS is directly opposed to backwards compatibility you claim is the main drive.=20 =20 [mv] I hope that you now understand that it is the opposite case is that = is present. Simple CC does **not** replicates all triggers... AIS is needed = in addition. =20 Regards, Maarten =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to = locate the misconfigured or failed connection function. Once this faulty = connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the performance = against the SLA for the connection. =20 Regards, Maarten _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin = domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server layer. = AIS suppresses the LOC alarm in those cases so that the maintenance guys = don't get triggered and start looking for a fault that is outside their area. =20 Regards, Maarten =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are concerned = with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* = the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you = think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even when AIS = was being received as the service guys want to know about the alarms. The = normal practice is for the equipment to report the alarms *including* AIS and = then a filter is applied in the management system to suppress alarms to the = fault fixing guys. As I'm aware, there are many different techniques applied = for the filtering algorithms, especially when you consider multiple = concurrent faults in a network, however, the existance of AIS/FDI doesn't add = anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And = if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up = simple time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation you describe is = only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to = fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, maybe = AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there = is no AIS/FDI functions, when there is a defects in a given layer network, = it can cause multiple alarm events to be raised. it is diffcult for = operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so I = think every new functions and things may have positive and negative effects. = but we should consider it very much, don't delete some functions at random.=20 best regards=20 liu=20 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Boundary_(ID_K8ad5CbAgpMczYPcX2Hk2Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, I have the impression that you do not have the = correct=20 understanding of the SNC protection switching fucntional models and the = location=20 and control of AIS insertion. Your understanding seems not aligned with = the=20 specifications in our equipment and protection swithcing = recommendations.=20 See=20 inline... From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 12:50 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, It is of course true that adding a boolean = input to a=20 logical system increases the number of possible input states. So adding = an AIS=20 boolean to CC boolean creates four possible states not = just the=20 three you identify below. There are - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no=20 AIS We must ask what practical scenarios could = generate=20 each of these input states. Good CC, no AIS One hopes this is because this is because = the service=20 is working properly. [mv]=20 I don't think that there is only "hope". This condition reflects = that there=20 is no disconnect. If=20 every frame/packet arrives correctly is not checked by the reception of = CC and=20 correct MEGID/MEPID. Frame/packet loss is checked by the frame/packet = loss=20 measurement that is embedded in the CCM frames, and can be activated.=20 CC fault, AIS present One hopes this is because the service is = faulty and=20 one hopes this is because of a fault in a server layer. In fact, = the=20 presence of the AIS could be misleading (see below). [mv]=20 With equipment that complies with the equipment standards this = condition=20 doesn't give you just "hope". It gives you "knowledge" that the = discontinutity=20 experienced in the connection is due to a server layer=20 fault. Good=20 CC, AIS present This situation could arise because of a misconfiguration of the = AIS=20 forwarding label injection table. And there are a number of scenarios = which make=20 this quite likely when protection switching occurs. Depending on the = exact scope=20 of the forwarding labels, a protection switch may well require the = proactive=20 purging of entries from the AIS forwarding label injection table = following the=20 protection switch (this could equivalently been seen as the forwarding = function=20 proactively dropping the AIS packets). [mv] I don't think that those = scenarios=20 are likely scenarios. Equipment compliant with ITU-T's equipment = recommendations=20 will not have those scenarios. Only equipment that does not comply with=20 those equipment recommendations could have such scenarios. Just do = not=20 deploy such equipment. [mv] The AIS=20 insertion in the functional models is performed in the Adaptation Sink=20 functions. Those Adaptation Sink functions are connected to the = Connection=20 function in which the SNC Protection process is located. The AIS = insertion=20 in an Adaptation sink fucntion continues independent of the state = of the=20 protection switch process in the Connection function; i.e. the = selector in=20 the protection process will only receive frames/packets from either the = working=20 SNC, or the protection SNC (but never from=20 both). CC=20 fault, no AIS As you suggest, this could arise from a misconfiguration of a = forwarding=20 function. But it could equally arise from a misconfiguration of the AIS=20 forwarding label injection table. In fact, the latter actually seems = just=20 as likely and particularly problematic for maintenance. Unlike = normal=20 forwarding, any mismatch between the forwarding configuration and the = AIS=20 forwarding label injection table will lie dormant and until a server = fault=20 arises. Then this generates a false and misunderstood fault condition = with=20 maintenance looking for the fault in the wrong place. [mv] As indicated in the=20 above comment, equipment compliant with the equipment and = protection=20 switching recommendation will not behave as you suggest. Only equipment=20 not-compliant with our equipment/protection = switching recommendation may do=20 this, but such equipment should simply not be=20 deployed. [mv] AIS generation is = performed in the=20 adaptation sink function for the set of active client signals; i.e. = for the=20 set of connection/flow points that are activated on the adaptation sink = function=20 (which are represented by the set of active labels/VIDs/...). There is = no "AIS=20 forwarding label injection table" in any of our equipment = recommendations. AIS=20 will be generated for each client CI output on the set of CPs/FPs on the = adaptation sink function when aAIS consequent action condition is=20 true. The first two states can be reliably diagnosed with CC = alone. The=20 second two arise from the introduction of the AIS/FDI. However, any = possible=20 benefit that might arise is completely masked by the fact that the AIS = itself=20 must be configured and there is no reason for this to be more reliable = than what=20 it is supposed to be monitoring. Indeed, there seems good reason to = think that=20 it will be less reliable. [mv] You are turning things = upside down...=20 CC is present to detect continuity and connectivity problems introduced = in the=20 layer network's Connection functions. As such you can not diagnose the = second=20 state with CC alone. With CC alone one of your colleagues will be = requested to=20 initiate a number of Loopback tests to find out which connection = function is=20 misconfigured. This is the wrong action of course, as there is a server = layer=20 fault. [mv] You do not understand the = AIS=20 "configuration" aspect. AIS generation configuration is on the node, not = on each=20 individual connection. Networks that deploy AIS have it active on all = their=20 NNIs. There=20 is no avoiding that AIS in circuit switching is fundamentally different = from AIS=20 in packet switching. - in circuit switching, you must fill = the bit=20 stream with something and the information injected requires no = configuration=20 whatsoever. - in packet switching, no packets is a perfectly valid = condition=20 and the injection of AIS requires individual client connection specific=20 information to be configured. [mv] In packet transport = networks with=20 connectivity checking no packets is not a valid condition.=20 [mv] = AIS/FDI insertion specified=20 in e.g. T-MPLS OAM does not require any individual client connection = specific=20 information. [mv] ATM VP AIS and ATM VC AIS = does not=20 require any individual client (i.e. VP, VC) connection specific = information.=20 [mv] ETH AIS does not require = any=20 individual client connection identification specification, but it = requires reuse=20 of the client MEG Level information which is also required for the ETH = MIP=20 functions on the interface = port. [mv] I.e. AIS insertion does = not require=20 individual client connection specific information. Either no additional=20 information at all is required, or additional information is required = that is=20 shared with other fucntions/processes in the=20 interface. The objective is not to replicate the data plane primitives of = SONET/SDH,=20 but the triggers to the operational systems so that the operational = systems and=20 processes are the same. [mv] And that is exactly what = we do with=20 support of AIS in packet transport networks (ATM, Ethernet, T-MPLS = =3D>=20 MPLS-TP). The simple CC replicates all the triggers to management systems = made by=20 SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data=20 plane AIS requires a whole new area of configuration and generates a = whole new=20 set of fault conditions which cannot be localised by SONET/SDH = processes. So,=20 ironically, packet AIS is directly opposed to backwards compatibility = you claim=20 is the main drive. [mv] I hope that you now=20 understand that it is the opposite case is that is = present. Simple CC=20 does **not** replicates all triggers... AIS is needed in=20 addition. Regards, Maarten Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 Newgate = Street=20 London EC1A 7AJ Registered in England no. 1800000 = This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 24 April 2009=20 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI does give additional information. Let = me=20 explain: The need for AIS/FDI is a consequence of the = deployment=20 of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). = The=20 objective of such CCM OAM is to be able to detect a misconfiguration = or fault=20 of a connection function (fabric) in the connection, which interrupts = the=20 forwarding of traffic in the connection. This is a fault condition = that can=20 only be discovered by the layer network in which the connection is = supported.=20 It requires that the organization responsible for the layer network = takes=20 action (i.e. locate the layer's connection function that includes = the=20 fault) to restore the connection. Unfortunately, an interruption of one of = the link connections of such connection (due to a fault in a = server=20 layer) will also interrupt the forwarding of traffic in the=20 connection. As such, loss of CC messages (LOC defect) = does not=20 provide sufficient information to determine if the configuration in = the=20 layer's connection functions along the connection have to be checked = and=20 corrected. AIS has been introduced and is used to help = differentiate=20 between the two fault cases. 1) if LOC and AIS are detected, then there is = a server=20 layer fault. This server layer fault is already reported by the server = layer=20 MEP detecting this fault. No action is required, so no alarm to=20 generate. 2) if LOC is detected and there is no AIS, = then there is=20 a layer network fault (i.e. continuity fault). Fault localization must = be=20 started to locate the misconfigured or failed connection function. = Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is=20 retored. The interruption of the forwarding of traffic = in the=20 connection in both fault cases is however registered as part of = performance=20 monitoring. This performance monitoring information is used to verify = the=20 performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points I = made. My=20 point is that AIS/FDI gives no information above what is already known = - it is=20 only adds complexity and fault liability. Neither of your points = change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009=20 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of alarm = suppression=20 in the data plane - that information is readily=20 available. I don't = believe that=20 this is a correct statement in a multi-operator transport network, = or in=20 transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring=20 in admin domain A will be unknown in admin domain B. The loss of = continuaity=20 alarms that are activated in admin domain B due to the fault in = admin domain=20 A will appear as primary alarms, suggesting connectivity problems in = admin=20 domain B. > The issue=20 arises because the two sides of maintenance want different things. = The fault=20 fixing > guys want to locate the fault and don't want any = other=20 information. The service=20 maintenance > guys want to know whether their customer service = is=20 working. This is addressed in SDH, OTN, Ethernet = and T-MPLS=20 recommendations by means of the additional SSF alarm. The SSF = alarm is=20 for the service guys telling them that the service was interrupted = due to a=20 fault in a server layer. AIS suppresses the LOC alarm in those cases = so that=20 the maintenance guys don't get triggered and start looking for a = fault that=20 is outside their area. Regards, Maarten From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two=20 things which are separate and for which AIS/FDI is no help. = Maintenance=20 operations are concerned with two separate = things. 1) Identifying faults in equipment, = line plant,=20 and other systems (eg misconfigurations) and fixing them (equipment=20 maintenance). 2) Identifying the health of end to = end=20 connections, especially when they are directly supporting customer = services=20 (service maintenance). The problem is *not* about a lack of alarm = suppression=20 in the data plane - that information is readily available. If, at an = end=20 equipment, I have a good server/section layer and a loss of CC at = the client=20 layer, I *know* the fault is elsewhere - I don't need AIS/FDI to = tell me.=20 (Indeed, if you think about, if the fault is in the end equipment, = it is=20 quite likely that the fault means it cannot report the traffic loss = to the=20 management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the = fault and=20 don't want any other information. The service maintenance guys want = to know=20 whether their customer service is working. This arose in the early days of SONET/SDH, = when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know=20 about the alarms. The normal practice is for the equipment = to report=20 the alarms *including* AIS and then a filter is applied in the = management=20 system to suppress alarms to the fault fixing guys. As I'm = aware, there=20 are many different techniques applied for the filtering algorithms,=20 especially when you consider multiple concurrent faults in a = network,=20 however, the existance of AIS/FDI doesn't add anything to these = that's not=20 already known. In fact, I believe simple time-stamp correlation = is one=20 of the most powerful and widely used techniques. And if the = equipment starts=20 messing up the reporting of loss of CC because it waiting = for/persistence=20 checking AIS/FDI, it could end up messing up simple time-stamp=20 correlation! In practice, it is often not quite a simple = as this, as=20 the service guys like to be able to 'localise' the fault. However, = under=20 most circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter = hasn't worked=20 for some reason. But the bottom line is, whatever operations = process you=20 want to use, AIS/FDI doesn't add anything other than complexity = and=20 fault liability to the equipment. Remember AIS goes back to the = TDM=20 world where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000=20 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Neil: = thank you for wasting more time = in=20 describling the problems. but I think some of what you said is no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense in=20 cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI = functions,=20 when there is a defects in a given layer network, it can cause = multiple=20 alarm events to be raised. it is diffcult for operators to = locate=20 and diagnose the faults. though I completely agree you on adding new = things and=20 functions will bring some complexity . but if we have no = functions, it is=20 more complex and difcult for operators to maintence and = administrator the=20 network. so I think every new functions and things may have = positive and=20 negative effects. but we should consider it very much, don't = delete some=20 functions at random. best=20 regards liu = <neil.2.harrison@bt.com> 2009-04-21 20:30 = =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If MPLS-TP is going to be taken seriously as a transport = network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are = these.=20 1 Provide a transparent = client/server=20 relationship...which means: - all client bits treated = equally=20 - = client=20 bit ordering preserved - no attempt to infer client symbol (ie = sequence of=20 client bits) meaning and no attempt to change client = symbols=20 - = the=20 traffic behaviour of client X must not impact the performance = experienced=20 by client Y A key corollary of = the above is=20 that MPLS-TP must only support proper connections (ie single = source=20 constructs) 2=20 Since MPLS-TP is a transport network it is not a = top-of-stack=20 network (ie it does not support directly external = message/file/stream=20 applications). MPLS-TP therefore does not require an E-NNI=20 specification. A key corollary of this is that MPLS-TP will = not have=20 any peer interworking relationship with any other network=20 mode/technology. Now wrt OAM MPLS-TP is a co-ps mode network. You = could argue=20 this should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether PBB-TE = (also a=20 co-ps mode network) should have FDI/AIS we concluded that on = balance it=20 was not a good idea.....and note that initially I was in favour of = having=20 AIS, but my colleagues provided strong technical arguments that = convinced=20 me otherwise. AIS/FDI is = historically linked=20 to the early PDH co-cs mode layer networks that used TTL logic. = When=20 this died it put out a +5V (all 1s) signal by default, ie it = required no=20 conscious effort to generate it.....this is key point. = Further, in=20 these networks there is a fairly static/long-holding client server = relationship. Clearly this is not true in the cl-ps mode and = it's=20 why IETF have never specified AIS for IP and its why IEEE had the = good=20 sense to throw-out AIS in 802.1ag for Ethernet (though ITU have = unwisely=20 IMO retained it in Y.1731....but I suspect any operator planning = to use=20 Ethernet equipment would always look to IEEE stds and not ITU=20 ones). AIS/FDI and the = co-ps mode is=20 debatable. As I noted above, on balance we considered not a = good=20 idea for PBB-TE OAM because it requires a conscious effort to = generate it=20 (unlike the co-cs mode) so there are likely to be scaling problems = and its=20 one more thing to go wrong. =20 You = should also have=20 seen me make the point many times in the past that the always-on = defect=20 detection/handling OAM needs to be as simple/sparse as possible = with as=20 little config as possible because we need super = reliability......TCM goes=20 completely against the grain here. Also note that the OAM = required=20 for each of the 3 network modes is not the same, despite what some = claim. regards, = Neil From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Deborah: maybe=20 what you said is right. but I can't completely agree your = opinions. IMO.=20 mpls-tp is regard as transport network like SDH/SONET. so it = should have=20 AIS/FDI fuctions as SDH/SONET. = do you think so.=20 best = regards liu = "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org 2009-04-20 = 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers"=20 <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with Neil, = it is very=20 questionable the value of AIS/FDI in a packet network- any = mode. It can=20 result in a DoS attack by an operator on themselves so even = Y1731=20 recommends not to block data frames: "A MEP can decide whether = it=20 blocks data frames when it detects dAIS. The principle=20 requirement that influences this decision is that data frames = ought to=20 be forwarded as much as possible, without the possibility of = forwarding wrong data frames downstream." Table I.7-2 shows for = AIS,=20 not to block. And as Y1731 states, AIS can only be used = under very=20 constrained architectures - if required for MPLS-TP, it needs = to have=20 the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a point-to-point ETH connection, a MEP has = only a=20 single peer MEP. Therefore, there is no ambiguity regarding = the peer=20 MEP for which it should suppress alarms when it receives = the ETH-AIS=20 information." So should only be within one domain - then no=20 need. Deborah -----Original Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] = On Behalf Of=20 Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the = cl=20 mode?...do me a favour! Ethernet AIS is indeed a = requirement and a=20 necessity. And you will not be able to understand that as = long as=20 you refuse to accept that "cl-mode" is a forwarding mode = within a=20 **transport entity**. G.800 amendment 1 = has finally reintroduced=20 this transport entity into G.800. Besides that, it = also introduced the=20 **differentiated connection**: [G.800 am1] "A = differentiated=20 connection is a transport entity that transfers information = belonging=20 to multiple communications between ports across a subnetwork.=20 <..> In a differentiated connection = message contents are=20 interpreted to identify (sets of) communications which=20 receive different treatment. The sets of = communications may be=20 distinguished by the forwarding identifier or other layer = information.=20 Order is not necessarily preserved between messages = belonging=20 to sets of communications receiving different treatment. = Sets of=20 communications may be identified for purposes such as = traffic=20 conditioning or preserving communication message=20 order." Ethernet VLANs are in terms of G.800 = "differentiated=20 connections". Ethernet AIS provides AIS within the scope of = such=20 "differentiated connection". If you apply this to my = proposed PTN=20 layer stack, then the EVC layer topology will consists of = EVC links=20 supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails = inside=20 metro and core domains interconnecting EVC = matrices. When one of=20 those EVC links is interrupted, e.g. in the core between metro=20 1 and metro 4 (see attached slide), then the EVC = differentiated=20 connection that is present on this link will be interrupted. = At the=20 EVC switch/bridge node in metro 4 this interruption is = noticed and=20 EVC-AIS is inserted in the downstream direction to suppress the = EVC-LOC=20 alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet=20 AIS) frame has a reserved multicast address, which guarantees = that the=20 AIS is broadcast to the endpoints of the EVC. I believe = that it is=20 time for you to adapt your view on co and cl = modes and relate it to=20 the forwarding mode **INSIDE** a transport entity. What we = know as=20 the internet is essentially an "IP differentiated connection" = with a=20 billion or more ports. What we know as an IP VPN is essentially = an "IP=20 differentiated connection" with e.g. n ports (n in the range = of e.g.=20 2 to 1000). What we know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n ports (n in the = range of=20 e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is = essentially an=20 "MPLS differentiated connection" with 2 ports. What we know = as a p2p=20 SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport = network=20 OAM applies to transport entities, which are (in = terms of G.800 am1)=20 connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; = maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: = [mpls-tp] Associated bidirectional transport=20 path requirements John, Thanks this is a great = platform to=20 explain why OAM for the 3 network modes needs to be = different.=20 I am getting a wee bit tired of folks trying to make = all 3=20 network modes look alike (and then, even worse, = interwork them as as=20 peers...esp when not not top-of-stack networks...I mean how = silly can=20 we get?). I am even more frustrated by the fact those = peddling=20 this FUD only ever seem to consider OAM and forget all other = DP/CP/MP components (esp top-of-stack = message/file/stream application=20 adaptations). How wrong can this get! In the co = modes a=20 *connection* is a very specific and = *constraining* construct.....I am=20 assuming here we respect the rules of a = connection (ie single=20 source) though some folks don't even bother to respect this,=20 and this is despite the fact that we all know what problems=20 multiple-source constructs can cause (from LDP/PHP....ergo=20 MPLS-TP). When we have a connection this restricts *all* DP = (ie=20 traffic and OAM) to stay within the bounds of the = connection.=20 Which is fine under defect-free conditions, but if we = have=20 leaking traffic then the constraining nature of the = connection=20 construct is broken. In a nutshell what this means = is that OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity defects.....indeed, why = should a=20 leaking DP have a symmetric go/return defect = behaviour?....very=20 likely it won't. So whilst request/response OAM is right for = the cl=20 mode it is not right for the co mode under misconnectivity = defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) observation = that if=20 IP (cl mode) could do it all then why have IETF found it = necessary=20 to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies=20 in the physics...and G.800 attempts to explain = that physics....G.805=20 does not. So, the 3 modes are different...please = accept/rejoice in=20 this fact as they all offer something different/important. = But=20 do not be hoodwinked by those who peddle a story that that = tries to=20 make the OAM of the 3 modes the same. regards, Neil=20 > -----Original Message----- > From:=20 mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] = On=20 Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > = To: BUSI=20 ITALO; Alexander Vainshtein; Maarten Vissers > Cc:=20 mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path > requirements > > = Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, = virtually all=20 of the > OAM functions require a return path, and in the = absence=20 of a return > path they are disabled. > > As = described=20 in David Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to be = used to=20 instantiate this forwarding. > > As an aside, the = issue of=20 return path for unidirectional LSPs could be > = charaterized as=20 the elephant in the room. In the MPLS TP OAM > = Framework I-D,=20 unicast LSPs are only mentioned three times and return > = paths not=20 at all. > > Thanks, > > John > = >=20 -----Original Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April 17,=20 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; = Maarten=20 Vissers > > Cc: mpls-tp@ietf.org > > Subject: = RE:=20 [mpls-tp] Associated bidirectional transport path > >=20 requirements > > > > John, > > = > > I=20 might have missed the agreement of MPLS-TP being capable of = > >=20 sending replies to OAM requests sent on uni-directional = LSPs. > >=20 > > This requirement does not belong to the first set of = requirements > > ITU-T is expecting to be met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken into = account=20 (at worst in a > subsequent phase). > > > = > I=20 think that this requirement needs to be evaluated versus other = >=20 > more important requirements (e.g. the possibility to work w/o = IP=20 > > forwarding and the need for OAM to continue to = monitor the=20 data > > plane also in case of failures affecting the = control or=20 management > > plane). > > > > I am = open to=20 discuss it but not sure this is the right time because > = > I=20 wish to avoid delaying the first phase of the design = solution. >=20 > > > Thanks, Italo > > > > >=20 -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E > >=20 > Sent: Thursday, April 16, 2009 8:00 PM > > > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc:=20 mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > = requirements > >=20 > > > > At the meeting last fall at Juniper in=20 Massachusetts, I > > think it was > > > = agreed that=20 an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM = packets=20 (e.g., sending > > replies to OAM > > > = requests sent=20 on uni-directional LSPs) even if it does not > > have an=20 IP > > > forwarding data plane. > > > = >=20 > > > -----Original Message----- > > > > = From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = >=20 > > > requirements > > > > > > = > >=20 Maarten, > > > > It seems that you've just = (implicitly and,=20 probably, > > > > inadvertently) stated the=20 following: > > > > > > > > = =20 MPLS-TP OAM will = not ever=20 support MIP loopback function > > (and fault > > = >=20 > localization which requires this function ) for > >=20 unidirectional P2MP > > > > and P2P paths. > = >=20 > > > > > > If this statement is correct, = this (IMHO=20 and FWIW) > raises a valid > > > > = question: >=20 > > > > > > > = =20 Is MPLS-TP an appropriate solution for=20 these > types of transport > > > > = paths? >=20 > > > > > > > For the reference, IP/MPLS = provides=20 this kind of > > functionality today > > > = > for=20 (unidirectional - but it does not know any other > > = type) P2P=20 LSPs > > > > as described in RFC 4379. And its = extension to=20 P2MP LSPs seems > > > > easy... > > > = >=20 > > > > > > > > > = > >=20 > Regards, > > > > > > > > = =20 Sasha > > > > > > > > = > >=20 > > > > > >=20 ________________________________________ > > > > = From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > = On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: = Thursday, April=20 16, 2009 3:24 PM > > > > To: 'Adrian = Farrel' > >=20 > > Cc: mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp] Associated bidirectional transport path > > = > >=20 requirements > > > > > > > >=20 Adrian, > > > > > > > > >>=20 <quote> > > > > >> = The=20 intermediate nodes (including MEPs, MIPs and > > > = > other=20 internal > > > > >> = functions as=20 appropriate) of a co-routed > > > > bidirectional=20 transport > > > > >> = path at=20 each (sub-)layer MUST be aware of the pairing > > > = >=20 >> relationship of the forward and the=20 backward > > > > directions of that > > = > >=20 >> transport path. > > > = >=20 >> <end quote> > > > > > > = > >=20 > > There is no way this is a functional requirement. = That >=20 > > is, there is > > > > > *nothing* that = can be=20 observed from a black box point of > > > view = that >=20 > > > > results from adhering to this = requirement. >=20 > > > > > > > Your understanding is not = correct.=20 It is very much > observable if > > > > this=20 requirement is met from a black box point of view. > > = > >=20 The MIP functions can only perform the Loopback when there is a = >=20 > > > co-routed bidirectional transport path. The MPLS-TP = LBM=20 packet > > > > received at a MIP needs to be = returned (as=20 LBR > > > > packet) to the originating MEP function = via the=20 other > > direction of > > > > the = co-routed=20 bidirectional transport path. This other > direction > = >=20 > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > = >=20 > would fail. > > > > > > > > = Similarly,=20 when we have to apply TCM MEPs to monitor a > > segment,=20 then > > > > this is possible in a co-routed bidir=20 transport path > but not in a > > > > = associated=20 bidir transport path. In the first case the TCM MEP > > = >=20 > Source and Sink functions are co-located and can > = exchange=20 what is > > > > called "remote information" which = is=20 necessary for performance > > > > = monitoring. > >=20 > > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > > = >=20 > The entirety of the bracketted text "(including MEPs, > = >=20 > MIPs and other > > > > internal > > = > >=20 > functions as appropriate)" should be deleted. It does = not >=20 > > > add to "The > > > > > = intermediate=20 nodes." > > > > > > > > Your = understanding=20 is not correct. This text must not be > > deleted = at > >=20 > > all. > > > > > > > > > = Actually, I am quite fed up about this persistent > > = >=20 insistence on the > > > > inclusion > > = > >=20 > of "Tandem Connection." The definition within the ITU-T = of >=20 > > > this term > > > > > is > = > >=20 > poorly > > > > > specified and comes from = the=20 monitoring of a path that is > > > > parallel = (i.e. >=20 > > > tandem) > > > > > to the data = path being=20 monitored. This definition of TC > > > > seems to = be=20 at > > > > variance, > > > > > = and would=20 be if the ACH was actually in band. > > > > = > >=20 > > I don't understand where your interpretation of = tandem >=20 > connection is > > > > described in ITU-T=20 recommendations. I.e. "from the > > monitoring of = a > >=20 > > path that is parallel (i.e. tandem) to the data path = being=20 > > > > monitored."? > > > > = > >=20 > > There is a "network connection" and this network > = >=20 connection is a set > > > > of interconnected "link = connections" and "matrix > connections". A > > > = >=20 subset of those interconnected link connections and matrix = > >=20 > > connections can be monitored and is then referred to = as >=20 a "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There is=20 only additional OAM inserted inside the data > path by = the >=20 > > > TCM MEP_So function and this OAM is extracted from=20 the > > data path by > > > > the TCM = MEP_Sk=20 function. > > > > > > > > = Regards, >=20 > > > Maarten > > > > > > > = >=20 > > > > -----Original Message----- > > = > >=20 From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel > >=20 > > Sent: donderdag 16 april 2009 11:59 > > > = > To:=20 Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > = > >=20 Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path > > = > >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > > = Unfortunately I=20 cannot fully agree with your statement: > > > >=20 > > > > > > <quote> > > > = > >=20 From the point of view of hardware, = co-routed > >=20 > bidirectional LSPs > > > > > = are a=20 special case of associated bidirectional LSPs. > > > = > >=20 <end quote> > > > > > > > > = > >=20 This statement would be obviously correct, were it not for > = >=20 > > Requirement > > > > > 34 in the latest = MPLS-TP=20 requirements draft > > > > > > > > = OK. Got=20 it. > > > > > > > > But what is = this doing=20 in the data plane requirements section? > > > > = >=20 > > > In fact, what is this requirement actually = saying? >=20 > > > > > > > > <quote> > = >=20 > > > The intermediate nodes = (including MEPs,=20 MIPs and > > > other internal > > > > = >=20 functions as appropriate) of a = co-routed > >=20 > > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the=20 pairing > > > > > = relationship of=20 the forward and the backward > > > > directions of=20 that > > > > > transport=20 path. > > > > > <end quote> > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > is, there is > > > > *nothing* = that can=20 be observed from a black box point of > > view = that > >=20 > > results from adhering to this requirement. > > = >=20 > > > > > Therefore it could be assumed that = this=20 requirement is met by > > > > configuring some = data plane=20 database component through the > > > > management = plane.=20 The database component is not used > for anything > = > >=20 > except to satisfy this requirement for "awareness". > = > >=20 > > > > > Ben! Can we please try to rewrite = this=20 requirement in terms of > > > > behavior? > = >=20 > > > > > > > Please note that = Requirement 34 is=20 the ONLY item in the > > > > list that is > = > >=20 > > specific for co-routed bidirectional LSPs. (The = pairing >=20 > > > requirements > > > > > at end = points for=20 co-routed and associated bidirectional > > > paths = are >=20 > > > > exactly the same even if they appear in two=20 different > > > items in the > > > > = >=20 requirements' list). > > > > > In other words, = without=20 Requirement 34 the notion of > co-routed > > > = > >=20 bidirectional paths would be void of any data plane = content. > >=20 > > > > > > > > The somewhat vague = scope of=20 this requirement ("other internal > > > > > = functions=20 as appropriate") creates a suspicion that HW > > > = >=20 support of the > > > > > pairing awareness may = be=20 required in order to comply with it. > > > > = > >=20 > > The entirety of the bracketted text "(including = MEPs, >=20 > MIPs and other > > > > internal functions as=20 appropriate)" should be deleted. It > > does not > = >=20 > > add to "The intermediate nodes." > > > > = >=20 > > > > The following text in the draft increases this = suspicion: > > > > > > > > > > = <quote> > > > > > Tandem = Connection: A=20 tandem connection is an > > arbitrary part of a > = > >=20 > > transport path that can be monitored (via = OAM) >=20 > > > independently from the > > > > > = =20 end-to-end monitoring (OAM). It may be a monitored > = >=20 segment or a > > > > > monitored = concatenated=20 segment of a transport path. > > The = tandem > >=20 > > > connection may also include the forwarding = engine(s)=20 of > > > > the node(s) > > > > > = =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = > >=20 Actually, I am quite fed up about this persistent > > = insistence=20 on the > > > > inclusion of "Tandem Connection." = The=20 definition within > > the ITU-T of > > > > = this=20 term is poorly specified and comes from the > monitoring of=20 a > > > > path that is parallel (i.e. tandem) to = the data=20 path being > > > > monitored. This definition of = TC seems=20 to be at variance, > > and would > > > > = be if the=20 ACH was actually in band. > > > > > > = > >=20 > Doesn't "forwarding engine" sound like hardware to = you? > >=20 > > > > > > Yes, but so what? > > = > >=20 > > > > > IMHO it is worth noting that neither = the=20 MPLS-TP > > > Requirements draft > > > = > >=20 nor the MPLS-TP OAM requirements one > > > > > = >=20 > > > > > > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > > = > >=20 > > > > But tandem connections are discussed in the = MPLS-TP=20 OAM > > Framework > > > > > = draft > >=20 > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > = > >=20 > > > > > Right. > > > > Let's = just get=20 rid of an unnecessary term and bring all > the I-Ds > = >=20 > > into line. > > > > > > > = > >=20 The bottom line, IMHO, is that some clarity regarding > > = >=20 co-routed vs. > > > > > associated > > = >=20 > > bidirectional paths is still required. One way to=20 provide > > > > that could > > > > = > be=20 by explicitly limiting Requirement 34 to specific > > = >=20 functionality. > > > > > > > >=20 Agreed. > > > > > > > > = Adrian > >=20 > > > > > > > > > > > = >=20 > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: = Thursday,=20 April 16, 2009 12:13 AM > > > > To: Alexander = Vainshtein;=20 Lou Berger; BUSI ITALO > > > > Cc: = mpls-tp@ietf.org >=20 > > > Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path > > > > requirements > > > > = >=20 > > > Hi Sasha, > > > > > > > = >=20 Not really sure whether you are misrepresenting anyone, = but... >=20 > > > > > > > > 1. My reading of = one of=20 Ben's messages is that associated > > > > = >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will=20 have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > > = This is=20 clearly nonsense! > > > > From the point of view of = hardware, co-routed > > bidirectional LSPs are > = > >=20 > a special case of associated bidirectional LSPs. > > = >=20 > > > > > If you can set up two unidirectional = LSPs=20 (e.g. using the > > management > > > > = plane) you=20 can surely set up a co-routed > > > bidirectional = LSP. >=20 > > > > > > > There are shipping = solutions that=20 achieve co-routed > bidirectional > > > > = LSPs using=20 the control plane. These either use the GMPLS > > (which=20 is > > > > cleaner) or non-standard proprietary = solutions=20 (which is > > messy but > > > >=20 functional). > > > > > > > > But = (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are = software > >=20 > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the actual > = >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > > = transport networks rather than any specific benefit. > > = >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, > >=20 > > feel, and behavioral characteristics of a = "legacy" > >=20 > > transport network. > > > > > > = >=20 > > Based on these observations, I'd guess (FWIW) = that: > >=20 > > > * associated bidirectional paths are, at least for = the=20 time > > > > > being, the most = important=20 type of bidirectional paths in > > > > > =20 MPLS-TP > > > > > > > > I = think that=20 is wrong both given my statement above, and > > given=20 that > > > > other upgrades to existing MPLS = solutions will=20 be > needed to reach > > > > the full = function level=20 of MPLS-TP. > > > > > > > > > * = they had=20 a good chance to remain the only type of > >=20 bidirectional > > > > > paths in = real=20 deployments. > > > > > > > > I = don't see=20 what that follows from. > > > > > > > = >=20 Cheers, > > > > Adrian > > > > = > >=20 > > _______________________________________________ > = >=20 > > mpls-tp mailing list > > > >=20 mpls-tp@ietf.org > > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = >=20 > > > >=20 _______________________________________________ > > > = >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/mpls-tp > = > >=20 > > > > > > > >=20 _______________________________________________ > > > = mpls-tp=20 mailing list > > > mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > > = >=20 > > = _______________________________________________ >=20 mpls-tp mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy and=20 are not permitted to disclose the contents of this communication = to=20 others. This email and any files transmitted with it are = confidential=20 and intended solely for the use of the individual or entity to = whom they=20 are addressed. If you have received this email in error please = notify the=20 originator of the message. Any views expressed in this message are = those=20 of the individual sender. This message has been scanned for = viruses and=20 Spam by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. --Boundary_(ID_K8ad5CbAgpMczYPcX2Hk2Q)-- From maarten.vissers@huawei.com Mon Apr 27 05:38:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B243B28C0FA for ; Mon, 27 Apr 2009 05:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.392 X-Spam-Level: **** X-Spam-Status: No, score=4.392 tagged_above=-999 required=5 tests=[AWL=-2.944, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFHjkBl+1SOC for ; Mon, 27 Apr 2009 05:38:22 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D0BB23A6929 for ; Mon, 27 Apr 2009 05:38:20 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR00JFEF62XU@szxga02-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 20:39:39 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR00KQ0F62NH@szxga02-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 20:39:38 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIR00GDTF5A8C@szxml01-in.huawei.com>; Mon, 27 Apr 2009 20:39:38 +0800 (CST) Date: Mon, 27 Apr 2009 14:39:04 +0200 From: Maarten Vissers In-reply-to: To: andy.bd.reid@bt.com, lihan@chinamobile.com Message-id: <003801c9c735$2eaeede0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_u1mq69FcHqzvyvFReqMYbQ)" Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAHRYX7AAEIvGoAAGn4jg Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:38:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_u1mq69FcHqzvyvFReqMYbQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, =20 Please read my response to your post. I have indicated that your understanding of existing equipment and protection switching = recommendations is incorrect.=20 =20 The use of AIS/FDI and the general agreement that AIS is mandatory (i.e. = not optional) will allow us to use the same fault detection, alarm = suppression and fault localisation as in other transport network technologies (SDH, = OTN, Ethernet). =20 If AIS is optional, then operators not using AIS must find other means = to distinguish between LOC alarm due to a continuity/connectivity fault in = the layer network, or in the server layer. If such other means are not = deployed then there are two alternatives: 1) ignore every LOC alarm (assume that it is a server layer fault), = until the customer complains that his/her connection is broken 2) start fault localisation on every LOC alarm, and conclude in 90-99% = of the cases that the problem was a server layer fault. =20 Regards, Maarten _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 13:20 To: lihan@chinamobile.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Han, =20 In his post below, Maarten is not claiming that AIS is needed for alarm suppression. He is saying that he sees it being used to distinguish = faults in a server layer from faults in the client layer. As you will see in my post back to Maarten, this cannot be practically achieved. =20 I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, = in the packet world of MPLS-TP, AIS/FDI cannot be simple and therefore = cannot be the same as in SONET/SDH. =20 The objective is to reuse the same basic fault detection, alarm = suppression, and fault localisation as SONET/SDH. This is readily achieved with the = CC messages in the dataplane. =20 However, adding AIS/FDI would require a completely new configuration management system and a completely new set of fault conditions requiring localisation. Ironically, adding a packet AIS/FDI effectively removes = the compatibility with SONET/SDH management systems and processes. =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: lihan [mailto:lihan@chinamobile.com]=20 Sent: 27 April 2009 02:41 To: 'Maarten Vissers'; Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: =B4=F0=B8=B4: [mpls-tp] Associated bidirectional transport path requirements Support! AIS/FDI is very importance for network management. MPLS-TP is divided = into three layers in order to enhance the scalability and OAM. It is very important to distinguish the failure is belong to server layer or client layer. AIS/FDI is a simple and well-known mechanism to realize alarm suppression and fault localization.=20 =20 =20 Best regards, Han Li ***************************************************** Han Li, Ph.D. R&D, CHINA MOBILE COMMUNICATIONS CORPORATION Tel: +86 10 66006688 ext. 3092 Fax: +86 10 63601087 MOBILE: 13501093385 ***************************************************** _____ =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] =B4=FA=B1=ED Maarten Vissers =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C225=C8=D5 2:15 =CA=D5=BC=FE=C8=CB: andy.bd.reid@bt.com =B3=AD=CB=CD: mpls-tp@ietf.org =D6=F7=CC=E2: Re: [mpls-tp] Associated bidirectional transport path = requirements =20 Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to = locate the misconfigured or failed connection function. Once this faulty = connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the performance = against the SLA for the connection. =20 Regards, Maarten =20 _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin = domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server layer. = AIS suppresses the LOC alarm in those cases so that the maintenance guys = don't get triggered and start looking for a fault that is outside their area. =20 Regards, Maarten =20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are concerned = with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* = the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you = think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even when AIS = was being received as the service guys want to know about the alarms. The = normal practice is for the equipment to report the alarms *including* AIS and = then a filter is applied in the management system to suppress alarms to the = fault fixing guys. As I'm aware, there are many different techniques applied = for the filtering algorithms, especially when you consider multiple = concurrent faults in a network, however, the existance of AIS/FDI doesn't add = anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And = if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up = simple time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation you describe is = only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to = fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, maybe = AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there = is no AIS/FDI functions, when there is a defects in a given layer network, = it can cause multiple alarm events to be raised. it is diffcult for = operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so I = think every new functions and things may have positive and negative effects. = but we should consider it very much, don't delete some functions at random.=20 best regards=20 liu=20 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements =20 =20 =20 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements =20 =20 =20 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Boundary_(ID_u1mq69FcHqzvyvFReqMYbQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, Please read my response to your post. I have = indicated that=20 your understanding of existing equipment and protection switching=20 recommendations is incorrect. The use of AIS/FDI and the general agreement = that AIS=20 is mandatory (i.e. not optional) will allow us to use the same = fault=20 detection, alarm suppression and fault localisation as in other = transport=20 network technologies (SDH, OTN, Ethernet). If AIS is optional, then operators not using = AIS must find=20 other means to distinguish between LOC alarm due to a = continuity/connectivity=20 fault in the layer network, or in the server layer. If such other means = are not=20 deployed then there are two alternatives: 1) ignore every LOC alarm (assume that it is a = server layer=20 fault), until the customer complains that his/her connection is=20 broken 2) start fault localisation on every LOC alarm, = and=20 conclude in 90-99% of the cases that the problem was a server layer=20 fault. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 13:20 To: lihan@chinamobile.com;=20 maarten.vissers@huawei.com Cc: = mpls-tp@ietf.org Subject: RE:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Han, In his post below, Maarten is not claiming that = AIS is=20 needed for alarm suppression. He is saying that he sees it = being used=20 to distinguish faults in a server layer from faults in the client layer. = As you=20 will see in my post back to Maarten, this cannot be practically=20 achieved. I agree, in SONET/SDH, AIS/FDI is simple and = well known.=20 Unfortunately, in the packet world of MPLS-TP, AIS/FDI cannot be simple = and=20 therefore cannot be the same as in SONET/SDH. The objective is to reuse the same basic fault = detection,=20 alarm suppression, and fault localisation as SONET/SDH. This is readily = achieved=20 with the CC messages in the dataplane. However, adding AIS/FDI would require a = completely new=20 configuration management system and a completely new set of fault=20 conditions requiring localisation. Ironically, adding a packet AIS/FDI=20 effectively removes the compatibility with SONET/SDH management systems = and=20 processes. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 Newgate = Street=20 London EC1A 7AJ Registered in England no. 1800000 = This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: lihan = [mailto:lihan@chinamobile.com]=20 Sent: 27 April 2009 02:41 To: 'Maarten Vissers';=20 Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: = =B4=F0=B8=B4:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Support! AIS/FDI is = very=20 importance for network management. MPLS-TP is divided into three = layers in=20 order to enhance the scalability and OAM. It is very important to = distinguish=20 the failure is belong to server layer or client layer. AIS/FDI is a = simple and=20 well-known mechanism to realize alarm suppression and fault = localization.=20 Best=20 regards,     Han=20 Li *****************************************************<= /SPAN> Han Li,=20 Ph.D. R&D,=20 CHINA MOBILE COMMUNICATIONS CORPORATION Tel:=20 +86 10 66006688 ext. 3092 Fax:=20 +86 10 63601087 MOBILE<= /ns0:place>: = 13501093385 ***************************************************** =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] =B4=FA=B1=ED = Maarten=20 Vissers =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C225=C8=D5 = 2:15 =CA=D5=BC=FE=C8=CB: = andy.bd.reid@bt.com =B3=AD=CB=CD: mpls-tp@ietf.org =D6=F7=CC=E2: Re: [mpls-tp] Associated bidirectional = transport path=20 requirements Andy, AIS/FDI = does give=20 additional information. Let me explain: The need = for AIS/FDI=20 is a consequence of the deployment of loss of continuity checking OAM = (e.g.=20 CCM in ethernet, CC in ATM). The objective of such CCM OAM is to be = able to=20 detect a misconfiguration or fault of a connection function (fabric) = in the=20 connection, which interrupts the forwarding of traffic in the = connection. This=20 is a fault condition that can only be discovered by the layer network = in which=20 the connection is supported. It requires that the organization = responsible for=20 the layer network takes action (i.e. locate the layer's = connection=20 function that includes the fault) to restore the=20 connection. Unfortunately, an=20 interruption of one of the link connections of such = connection (due=20 to a fault in a server layer) will also interrupt the forwarding of = traffic in=20 the connection. As such, = loss of CC=20 messages (LOC defect) does not provide sufficient information to = determine if=20 the configuration in the layer's connection functions along the = connection=20 have to be checked and corrected. AIS has = been=20 introduced and is used to help differentiate between the two fault=20 cases. 1) if LOC = and AIS are=20 detected, then there is a server layer fault. This server layer fault = is=20 already reported by the server layer MEP detecting this fault. No = action is=20 required, so no alarm to generate. 2) if LOC = is detected=20 and there is no AIS, then there is a layer network fault (i.e. = continuity=20 fault). Fault localization must be started to locate the misconfigured = or=20 failed connection function. Once this faulty connection function = is=20 located, the configuration fault (or hardware fault) can be = corrected,=20 after which the connection is retored. The = interruption of=20 the forwarding of traffic in the connection in both fault cases is = however=20 registered as part of performance monitoring. This performance = monitoring=20 information is used to verify the performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To:=20 maarten.vissers@huawei.com Cc: = mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements Maarten, These = points are=20 irrelevant to the points I made. My point is that AIS/FDI gives no = information=20 above what is already known - it is only adds complexity and fault = liability.=20 Neither of your points change this. Andy Andy=20 Reid Chief=20 Network Services Strategist = BT = Innovate            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Office: +44 (0)1277=20 322038 Mobile: +44 (0)7917=20 025451 Fax :      =20 +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com = British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no.=20 1800000 This = electronic=20 message contains information from British Telecommunications plc which = may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity = and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009 = 20:42 To: Reid,ABD,Andy,CXM = R Cc: = mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements Andy, > The = problem is=20 *not* about a lack of alarm suppression in the data plane - that = information=20 is readily available. I don't = believe=20 that this is a correct statement in a multi-operator transport = network, or=20 in transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring=20 in admin domain A will be unknown in admin domain B. The loss of = continuaity=20 alarms that are activated in admin domain B due to the fault in = admin domain=20 A will appear as primary alarms, suggesting connectivity problems in = admin=20 domain B. > The = issue=20 arises because the two sides of maintenance want different things. = The fault=20 fixing > guys want=20 to locate the fault and don't want any other information. The = service=20 maintenance > guys want=20 to know whether their customer service is = working. This is = addressed=20 in SDH, OTN, Ethernet and T-MPLS recommendations by means of the=20 additional SSF alarm. The SSF alarm is for the service guys = telling=20 them that the service was interrupted due to a fault in a server = layer. AIS=20 suppresses the LOC alarm in those cases so that the maintenance guys = don't=20 get triggered and start looking for a fault that is outside their=20 area. Regards, Maarten From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To:=20 liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path requirements Liu, Allow me = to jump=20 in. You are bringing together two things which are separate and for = which=20 AIS/FDI is no help. Maintenance operations are concerned with two = separate=20 things. 1) =20 Identifying faults in equipment, line plant, and other systems (eg=20 misconfigurations) and fixing them (equipment=20 maintenance). 2) =20 Identifying the health of end to end connections, especially when = they are=20 directly supporting customer services (service=20 maintenance). The = problem is=20 *not* about a lack of alarm suppression in the data plane - that = information=20 is readily available. If, at an end equipment, I have a good = server/section=20 layer and a loss of CC at the client layer, I *know* the fault is = elsewhere=20 - I don't need AIS/FDI to tell me. (Indeed, if you think about, if = the fault=20 is in the end equipment, it is quite likely that the fault means it = cannot=20 report the traffic loss to the management = system!) The issue = arises=20 because the two sides of maintenance want different things. The = fault fixing=20 guys want to locate the fault and don't want any other information. = The=20 service maintenance guys want to know whether their customer service = is=20 working. This = arose in the=20 early days of SONET/SDH, when the operations guys demanded that the=20 equipment did *not* suppress the traffic alarm even when AIS was = being=20 received as the service guys want to know about the alarms. The = normal=20 practice is for the equipment to report the alarms *including* = AIS and=20 then a filter is applied in the management system to suppress = alarms to=20 the fault fixing guys. As I'm aware, there are many different = techniques=20 applied for the filtering algorithms, especially when you consider = multiple=20 concurrent faults in a network, however, the existance of AIS/FDI = doesn't=20 add anything to these that's not already known. In fact, I believe=20 simple time-stamp correlation is one of the most powerful and = widely=20 used techniques. And if the equipment starts messing up the = reporting of=20 loss of CC because it waiting for/persistence checking AIS/FDI, = it=20 could end up messing up simple time-stamp=20 correlation! In = practice, it is=20 often not quite a simple as this, as the service guys like to be = able to=20 'localise' the fault. However, under most circumstances, the = filter has=20 automatically done this. So localisation you describe is = only when=20 the filter hasn't worked for some reason. But the = bottom line=20 is, whatever operations process you want to use, AIS/FDI = doesn't add=20 anything other than complexity and fault liability to the equipment. = Remember AIS goes back to the TDM world where you *have to fill = the bit=20 stream with something*. Andy Andy=20 Reid Chief=20 Network Services Strategist = BT = Innovate            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Office: +44 (0)1277=20 322038 Mobile: +44 (0)7917=20 025451 Fax :      =20 +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com = British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no.=20 1800000 This = electronic=20 message contains information from British Telecommunications plc = which may=20 be privileged or confidential. The information is intended to be for = the use=20 of the individual(s) or entity named above. If you are not the = intended=20 recipient be aware that any disclosure, copying, distribution or use = of the=20 contents of this information is prohibited. If you have received = this=20 electronic message in error, please notify us by telephone or email = (to the=20 numbers or address above) immediately. Activity = and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 = 09:15 To: Harrison,N,Neil,CXM = R Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path requirements Neil:=20 thank you for wasting = more time in=20 describling the problems. but I think some of what you said is no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense in=20 cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI = functions,=20 when there is a defects in a given layer network, it can cause = multiple=20 alarm events to be raised. it is diffcult for operators to = locate=20 and diagnose the faults. = though I completely agree = you on=20 adding new things and functions will bring some complexity . = but if=20 we have no functions, it is more complex and difcult for operators = to=20 maintence and administrator the network. so I think every new = functions=20 and things may have positive and negative effects. but we should = consider=20 it very much, don't delete some functions at = random. best regards liu=20 <neil.2.harrison@bt.com>=20 2009-04-21=20 20:30 = =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org> =D6=F7=CC=E2 RE:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Liu, If=20 MPLS-TP is going to be taken seriously as a transport network = (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. = 1=20 Provide a transparent client/server = relationship...which=20 means: -=20 all client bits treated equally -=20 client bit ordering preserved=20 -=20 no attempt to infer client symbol (ie sequence of = client=20 bits) meaning and no attempt to change client = symbols -=20 the traffic behaviour of client X must not impact the = performance experienced by client Y=20 A key=20 corollary of the above is that MPLS-TP must only support proper=20 connections (ie single source constructs)=20 2=20 Since MPLS-TP is a transport network it is not a = top-of-stack=20 network (ie it does not support directly external = message/file/stream=20 applications). MPLS-TP therefore does not require an E-NNI=20 specification. A key corollary of this is that MPLS-TP will = not have=20 any peer interworking relationship with any other network=20 mode/technology. = =20 Now=20 wrt OAM MPLS-TP is a co-ps mode network. You could argue = this should=20 have FDI/AIS....however, the merit of this is highly questionable. = When I and colleagues discussed whether PBB-TE (also a co-ps = mode=20 network) should have FDI/AIS we concluded that on balance it was = not a=20 good idea.....and note that initially I was in favour of having = AIS, but=20 my colleagues provided strong technical arguments that convinced = me=20 otherwise. = AIS/FDI=20 is historically linked to the early PDH co-cs mode layer networks = that=20 used TTL logic. When this died it put out a +5V (all 1s) = signal by=20 default, ie it required no conscious effort to generate = it.....this is key=20 point. Further, in these networks there is a fairly=20 static/long-holding client server relationship. Clearly this = is not=20 true in the cl-ps mode and it's why IETF have never specified AIS = for IP=20 and its why IEEE had the good sense to throw-out AIS in 802.1ag = for=20 Ethernet (though ITU have unwisely IMO retained it in = Y.1731....but I=20 suspect any operator planning to use Ethernet equipment would = always look=20 to IEEE stds and not ITU ones). = =20 AIS/FDI=20 and the co-ps mode is debatable. As I noted above, on = balance we=20 considered not a good idea for PBB-TE OAM because it requires a = conscious=20 effort to generate it (unlike the co-cs mode) so there are likely = to be=20 scaling problems and its one more thing to go = wrong. You=20 should also have seen me make the point many times in the past = that the=20 always-on defect detection/handling OAM needs to be as = simple/sparse as=20 possible with as little config as possible because we need super=20 reliability......TCM goes completely against the grain here. = Also=20 note that the OAM required for each of the 3 network modes is not = the=20 same, despite what some claim. = =20 regards,=20 Neil = From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 = 02:59 To: BRUNGARD, DEBORAH = A,=20 ATTLABS Cc:=20 mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Deborah: maybe what = you said=20 is right. but I can't completely agree your opinions. IMO. mpls-tp = is=20 regard as transport network like SDH/SONET. so it should have = AIS/FDI=20 fuctions as SDH/SONET. = do you = think=20 so. best=20 regards liu=20 "BRUNGARD,=20 DEBORAH A, ATTLABS" = <dbrungard@att.com>=20 =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org=20 2009-04-20=20 23:47 = =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com>=20 =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements I=20 agree with Neil, it is very questionable the value of AIS/FDI in=20 a packet network- any = mode. It can result=20 in a DoS attack by an operator on=20 themselves so even Y1731 recommends not to block data=20 frames: "A MEP can = decide whether it=20 blocks data frames when it detects dAIS. The principle = requirement that=20 influences this decision is that data frames ought to be=20 forwarded as much as = possible,=20 without the = possibility of forwarding=20 wrong data frames downstream." Table=20 I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used = under very=20 constrained architectures - if required=20 for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and = server/client=20 one-to-one: "for a = point-to-point ETH=20 connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity=20 regarding the peer MEP for which it should=20 suppress alarms when = it receives=20 the ETH-AIS=20 information." So = should only be within=20 one domain - then no need. Deborah -----Original=20 Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of Maarten=20 Vissers Sent: Monday, = April 20, 2009=20 10:05 AM To:=20 neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path requirements Neil, > but AIS/FDI in the=20 cl mode?...do me a favour! Ethernet=20 AIS is indeed a requirement and a necessity. And you will=20 not be able to understand that as long as you refuse = to accept that=20 "cl-mode" is = a forwarding mode within a **transport entity**. = G.800 amendment 1=20 has finally reintroduced this transport entity into G.800. = Besides that, it=20 also introduced the = **differentiated=20 connection**: [G.800 am1] "A=20 differentiated connection is a transport entity=20 that transfers = information belonging to=20 multiple communications between ports across a subnetwork. <..> In a = differentiated connection=20 message contents are interpreted to identify (sets of) = communications which=20 receive different treatment. The=20 sets of communications may be distinguished by=20 the forwarding = identifier or other layer=20 information. Order is not necessarily preserved between=20 messages belonging to sets of communications=20 receiving different = treatment. Sets=20 of communications may be identified for purposes such as traffic=20 conditioning or preserving communication message=20 order." Ethernet VLANs are in=20 terms of G.800 "differentiated = connections". Ethernet AIS provides AIS within=20 the scope of such "differentiated = connection". If you apply this to my proposed=20 PTN layer stack, then the EVC layer topology will consists of EVC=20 links supported by MPLS-TP, Ethernet, PBB-TE = and P-OTN VP trails inside metro and=20 core domains interconnecting EVC = matrices. When one of those EVC links is=20 interrupted, e.g. in the core between metro = 1 and metro 4 (see attached slide),=20 then the EVC differentiated connection that is present on this link will=20 be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is=20 noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC = alarms at EVC=20 endpoints D4 and D5. The EVC-AIS (i.e.=20 Ethernet AIS) frame has a reserved multicast=20 address, which = guarantees that the AIS is=20 broadcast to the endpoints of the = EVC. I believe that it is time for you to adapt = your view on co and cl=20 modes and relate it to the forwarding mode **INSIDE** a = transport entity.=20 What we know as = the internet is=20 essentially an "IP differentiated connection" with a billion or more = ports. What we know as an IP VPN is essentially an = "IP=20 differentiated connection" with e.g. n ports (n=20 in the range of e.g. 2 to 1000). What we=20 know as an Ethernet VLAN is essentially an=20 "Ethernet differentiated connection" with n=20 ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is = essentially an "MPLS=20 differentiated connection" with 2=20 ports. What we know = as a p2p SDH VC-n is=20 a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport = entities, which are (in=20 terms of G.800 am1) connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: = neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent:=20 vrijdag 17 april 2009 22:00 To:=20 John.E.Drake2@boeing.com;=20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the=20 3 network modes needs to be different. I am = getting a wee bit tired of=20 folks trying to make all 3 network modes look alike (and = then, even worse,=20 interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly=20 can we get?). I am even more frustrated = by the fact those peddling this FUD only ever = seem to consider OAM=20 and forget all other DP/CP/MP components (esp = top-of-stack=20 message/file/stream application=20 adaptations). How wrong can this get! = In the co modes a *connection* is a very = specific and=20 *constraining* construct.....I am=20 assuming here we respect the rules of a=20 connection (ie single source) though some folks don't even = bother to respect=20 this, and this is despite the fact that we all know what = problems=20 multiple-source constructs can cause=20 (from LDP/PHP....ergo MPLS-TP). When=20 we have a connection this restricts *all* DP (ie traffic and=20 OAM) to stay within the bounds of the connection. = Which is fine=20 under defect-free conditions, but if we=20 have leaking traffic then the constraining = nature of the connection construct is=20 broken. In a nutshell what this means = is that OAM that is of a=20 request/response nature cannot be trusted in co=20 mode networks under = misconnectivity=20 defects.....indeed, why should a leaking DP have a symmetric go/return=20 defect behaviour?....very likely it = won't. So whilst request/response OAM is=20 right for the cl mode it is not right for the co mode under misconnectivity=20 defect conditions. More generally the=20 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl = mode?...do me a favour!...at=20 least IEEE had the = good sense to bin this=20 for Ethernet even though it remains in Y.1731. And which is why=20 I often trot-out the rather silly (to have = to say this) observation that if IP=20 (cl mode) could do it all then why have IETF found it necessary to create=20 MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 = attempts to explain=20 that physics....G.805 = does=20 not. So, the 3 = modes are=20 different...please accept/rejoice in this fact = as they all offer something=20 different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the 3 modes=20 the same. = regards, Neil >=20 -----Original Message----- > From:=20 mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > Sent: 17 April = 2009=20 20:02 > To: BUSI = ITALO; Alexander=20 Vainshtein; Maarten Vissers > Cc:=20 mpls-tp@ietf.org > = Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 >=20 requirements >=20 > = Italo, > > As described in the=20 MPLS TP OAM Requirements I-D, virtually all of=20 the > OAM = functions require a=20 return path, and in the absence of a return = > path they are = disabled. >=20 > As described in = David Sinicrope's=20 meeting minutes > = = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no >=20 tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network = needs to be capable=20 of getting IP packets from >=20 destination to source; neither the minutes nor I stipulate that a=20 > control plane = needs to be used to=20 instantiate this forwarding. >=20 > As an aside, = the issue of return=20 path for unidirectional LSPs could be > charaterized as the elephant in the room. = In the MPLS=20 TP OAM > = Framework I-D, unicast LSPs=20 are only mentioned three times and return = > paths not at = all. >=20 > = Thanks, > >=20 John > > = -----Original=20 Message----- > = > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59=20 AM > > To: = Drake, John E; Alexander=20 Vainshtein; Maarten Vissers > > Cc:=20 mpls-tp@ietf.org > = > Subject: RE:=20 [mpls-tp] Associated bidirectional transport path=20 > >=20 requirements > = >=20 > > = John, > > > > I might have=20 missed the agreement of MPLS-TP being capable of = > > sending replies to OAM requests sent = on uni-directional=20 LSPs. > > = > > This requirement does not belong to = the first set of=20 requirements > = > ITU-T is=20 expecting to be met by October. > >=20 > > However, I = think this in a=20 potential interesting additional >=20 > requirement to be taken into account (at worst in=20 a > subsequent=20 phase). > >=20 > > I think = that this requirement=20 needs to be evaluated versus other >=20 > more important requirements (e.g. the possibility to work w/o = IP=20 > > forwarding = and the need for=20 OAM to continue to monitor the data >=20 > plane also in case of failures affecting the control or = management=20 > >=20 plane). > >=20 > > I am open = to discuss it but=20 not sure this is the right time because > > I wish to avoid delaying the first = phase of the design=20 solution. > >=20 > > Thanks,=20 Italo > > = > > > -----Original = Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > > > = Sent: Thursday, April=20 16, 2009 8:00 PM > = > > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc: = mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated bidirectional=20 transport path > = > >=20 requirements > = > >=20 > > > At = the meeting last fall=20 at Juniper in Massachusetts,=20 I > > think it=20 was > > > = agreed that an MPLS TP=20 network needs to have a forwarding >=20 > capability > = > > for=20 management, control, and OAM packets (e.g.,=20 sending > > = replies to=20 OAM > > > = requests sent on=20 uni-directional LSPs) even if it does not > > have an IP > >=20 > forwarding data plane. > >=20 > > > > = > -----Original=20 Message----- > = > > > From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, = 2009 9:57=20 AM > > > = > To: Maarten=20 Vissers > > = > > Cc:=20 mpls-tp@ietf.org > = > > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > >=20 requirements > = > > >=20 > > > >=20 Maarten, > > = > > It seems=20 that you've just (implicitly and, = probably, > > > > inadvertently) stated the=20 following: > > = > >=20 > > > > = =20 MPLS-TP OAM will not ever = support=20 MIP loopback function > > (and=20 fault > > > = > localization=20 which requires this function ) for >=20 > unidirectional P2MP > > >=20 > and P2P paths. > > > >=20 > > > > = If this statement is=20 correct, this (IMHO and FWIW) > raises=20 a valid > > = > >=20 question: > > = > >=20 > > > > = =20 Is MPLS-TP an appropriate = solution for these > types of=20 transport > > = > >=20 paths? > > > = >=20 > > > > = For the reference,=20 IP/MPLS provides this kind of > >=20 functionality today > > > >=20 for (unidirectional - but it does not know any=20 other > > type) = P2P=20 LSPs > > > = > as described in=20 RFC 4379. And its extension to P2MP LSPs seems = > > > > = easy... >=20 > > > > = > > >=20 > > > = >=20 > > > >=20 Regards, > > = > >=20 > > > > = =20 Sasha > > = > >=20 > > > >=20 > > > >=20 > > > >=20 ________________________________________ > > > > From: = mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > = > Of Maarten=20 Vissers [maarten.vissers@huawei.com] >=20 > > > Sent: Thursday, April 16, 2009 3:24=20 PM > > > = > To:=20 'Adrian=20 Farrel' > > >=20 > Cc: mpls-tp@ietf.org > > >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > >=20 requirements > = > > >=20 > > > > = Adrian, > > > > > >=20 > > >> <quote> >=20 > > > >> The intermediate nodes = (including MEPs, MIPs and > > >=20 > other internal > > > >=20 >> functions as appropriate) of a=20 co-routed > > = > >=20 bidirectional transport > > >=20 > >> path at each (sub-)layer MUST = be aware=20 of the pairing > = > > >=20 >> relationship of the forward and the=20 backward > > = > > directions=20 of that > > = > > >>=20 transport path. >=20 > > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > = is, there=20 is > > > = > > *nothing*=20 that can be observed from a black box point = of > > > view = that >=20 > > > > results from adhering to this=20 requirement. > = > > >=20 > > > > = Your understanding=20 is not correct. It is very much >=20 observable if > = > > > this=20 requirement is met from a black box point of=20 view. > > > = > The MIP=20 functions can only perform the Loopback when there is a=20 > > > > = co-routed=20 bidirectional transport path. The MPLS-TP LBM packet=20 > > > > = received at a MIP=20 needs to be returned (as LBR > >=20 > > packet) to the originating MEP function via the=20 other > > = direction=20 of > > > = > the co-routed=20 bidirectional transport path. This other > direction > > >=20 > would not be available in an associated bidirectional = transport=20 > > > > = path... and thus the=20 loopback test > = > > would=20 fail. > > > = >=20 > > > > = Similarly, when we=20 have to apply TCM MEPs to monitor a >=20 > segment, then > > > >=20 this is possible in a co-routed bidir transport=20 path > but not in=20 a > > > > = associated bidir=20 transport path. In the first case the TCM MEP = > > > > Source and Sink functions = are co-located and=20 can > exchange = what=20 is > > > = > called "remote=20 information" which is necessary for performance = > > > > = monitoring. > > > > In the latter case the TCM = MEP Source and Sink=20 functions > > = are in e.g.=20 > > > > = different nodes in=20 the network and TCM would not be able > > to provide > >=20 > > performance monitoring. >=20 > > > > = > > > >=20 The entirety of the bracketted text "(including=20 MEPs, > > > = MIPs and=20 other > > > = >=20 internal > > = > > >=20 functions as appropriate)" should be deleted. It does=20 not > > > = > add to=20 "The > > > = > >=20 intermediate nodes." > > > >=20 > > > > = Your understanding=20 is not correct. This text must not be > > deleted at > >=20 > > all. > = > > >=20 > > > > = > Actually, I am=20 quite fed up about this persistent >=20 > > insistence on the > >=20 > > inclusion > > > >=20 > of "Tandem Connection." The definition within the ITU-T=20 of > > > = > this=20 term > > > = > >=20 is > > > = >=20 poorly > > > = > > specified=20 and comes from the monitoring of a path that = is > > > > parallel = (i.e. > > > > = tandem) >=20 > > > > to the data path being monitored. This = definition of=20 TC > > > = > seems to be=20 at > > > = >=20 variance, > > = > > > and=20 would be if the ACH was actually in band. > > > > > >=20 > > I don't understand where your interpretation of=20 tandem > > = connection=20 is > > > = > described in ITU-T=20 recommendations. I.e. "from the > >=20 monitoring of a > = > > > path=20 that is parallel (i.e. tandem) to the data path being=20 > > > >=20 monitored."? > = > > >=20 > > > > = There is a "network=20 connection" and this network > >=20 connection is a set > > > >=20 of interconnected "link connections" and = "matrix > connections". A > >=20 > > subset of those interconnected link connections and = matrix=20 > > > > = connections can be=20 monitored and is then referred to as >=20 a "tandem > > = > >=20 connection". There is no "path that is parallel to=20 the > > data = path".=20 > > > > = There is only=20 additional OAM inserted inside the data > path by the > > >=20 > TCM MEP_So function and this OAM is extracted from=20 the > > data = path=20 by > > > = > the TCM MEP_Sk=20 function. > > = > >=20 > > > >=20 Regards, > > = > >=20 Maarten > > = > >=20 > > > >=20 > > > > = -----Original=20 Message----- > = > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Adrian = Farrel > > > > Sent: donderdag 16 april = 2009=20 11:59 > > > = > To: Alexander=20 Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO;=20 mpls-tp@ietf.org > = > > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > >=20 requirements > = > > >=20 > > > > = Hi=20 Sasha, > > > = >=20 > > > > = > Unfortunately I=20 cannot fully agree with your statement: > > > > = > >=20 > > > > <quote> >=20 > > > > From the point of view of = hardware,=20 co-routed > > = > bidirectional=20 LSPs > > > = > > =20 are a special case of associated bidirectional=20 LSPs. > > > = > > <end=20 quote> > > = > >=20 > > > > = > > This=20 statement would be obviously correct, were it not=20 for > > > = >=20 Requirement > > = > > >=20 34 = in the=20 latest MPLS-TP requirements draft >=20 > > > > = > > > OK.=20 Got it. > > = > >=20 > > > > = But what is this=20 doing in the data plane requirements = section? > > > > > >=20 > > In fact, what is this requirement actually=20 saying? > > = > >=20 > > > > = >=20 <quote> > = > > > >=20 The intermediate nodes (including MEPs, MIPs=20 and > > > = other=20 internal > > = > > > =20 functions as appropriate) of a=20 co-routed > > = > >=20 bidirectional transport > > >=20 > > path at each (sub-)layer MUST be = aware of=20 the pairing > > = > > >=20 relationship of the forward and the=20 backward > > = > > directions=20 of that > > = > > > =20 transport path. > >=20 > > > <end quote> >=20 > > > > = > > > There=20 is no way this is a functional requirement. = That > > is, there = is > >=20 > > *nothing* that can be observed from a black box point=20 of > > view=20 that > > > = > results from=20 adhering to this requirement. > >=20 > > > > = > > Therefore=20 it could be assumed that this requirement is met by=20 > > > > = configuring some=20 data plane database component through the = > > > > management plane. The = database component is=20 not used > for=20 anything > > = > > except to=20 satisfy this requirement for "awareness". > > > > > >=20 > > Ben! Can we please try to rewrite this requirement in = terms of=20 > > > >=20 behavior? > > = > >=20 > > > > = > Please note=20 that Requirement 34 is the ONLY item in = the > > > > list that = is > > > > > specific for = co-routed bidirectional=20 LSPs. (The pairing > > > >=20 requirements > = > > > > at=20 end points for co-routed and associated=20 bidirectional > = > > paths=20 are > > > = > > exactly the=20 same even if they appear in two different > > > items in = the >=20 > > > > requirements' list). > > > > > In other words, = without Requirement 34=20 the notion of >=20 co-routed > > = > > >=20 bidirectional paths would be void of any data plane=20 content. > > = > >=20 > > > > = > > The=20 somewhat vague scope of this requirement ("other internal=20 > > > > = > functions as=20 appropriate") creates a suspicion that HW > > > > support of = the > > > > > pairing awareness may = be required in=20 order to comply with it. > > >=20 > > > > = > The entirety of=20 the bracketted text "(including MEPs, > > MIPs and = other >=20 > > > internal functions as appropriate)" should be = deleted.=20 It > > does=20 not > > > = > add to "The=20 intermediate nodes." > > > >=20 > > > > = > The following=20 text in the draft increases this = suspicion: > > > > = > >=20 > > > > <quote> >=20 > > > > Tandem Connection: A tandem connection = is=20 an > > = arbitrary part of=20 a > > > > = > =20 transport path that can be monitored (via = OAM) > > > > independently from=20 the > > > = > > =20 end-to-end monitoring (OAM). It may be a=20 monitored > > = segment or=20 a > > > > = > =20 monitored concatenated segment of a transport path.=20 > > The=20 tandem > > > = > > =20 connection may also include the forwarding engine(s)=20 of > > > = > the=20 node(s) > > = > > > =20 at the edge(s) of the segment or concatenated=20 segment. > > = > > > <end=20 quote> > > = > >=20 > > > > = Actually, I am quite=20 fed up about this persistent > >=20 insistence on the > > > >=20 inclusion of "Tandem Connection." The definition=20 within > > the = ITU-T=20 of > > > = > this term is=20 poorly specified and comes from the >=20 monitoring of a > = > > > path=20 that is parallel (i.e. tandem) to the data path being=20 > > > > = monitored. This=20 definition of TC seems to be at variance, > > and would > >=20 > > be if the ACH was actually in = band. > > > > > >=20 > > > Doesn't "forwarding engine" sound like hardware to=20 you? > > > = >=20 > > > > = Yes, but so=20 what? > > > = >=20 > > > > = > IMHO it is=20 worth noting that neither the MPLS-TP > > > Requirements = draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > = > >=20 > > > >=20 > > > = > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain = any requirements=20 dealing with tandem > > >=20 connections. > = > > >=20 > > > > = > > But tandem=20 connections are discussed in the MPLS-TP = OAM > > Framework > >=20 > > > draft > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > = amework-00.txt > > > > = ). > >=20 > > > > = > >=20 Right. > > > = > Let's just get=20 rid of an unnecessary term and bring all > the I-Ds > > > >=20 into line. > > = > >=20 > > > > = > The bottom=20 line, IMHO, is that some clarity = regarding > > > co-routed = vs. >=20 > > > > associated > >=20 > > > bidirectional paths is still required. One way to=20 provide > > = > > that=20 could > > > = > > be by=20 explicitly limiting Requirement 34 to = specific > > > = functionality. > > > > > >=20 > > Agreed. > > > >=20 > > > > = Adrian > > > > > >=20 > > > > = > >=20 > > > >=20 > > > >=20 ________________________________________ > > > > From: Adrian=20 Farrel = [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, = 2009 12:13=20 AM > > > = > To: Alexander=20 Vainshtein; Lou Berger; BUSI ITALO >=20 > > > Cc: mpls-tp@ietf.org >=20 > > > Subject: Re: [mpls-tp] Associated bidirectional = transport=20 path > > > = >=20 requirements > = > > >=20 > > > > = Hi=20 Sasha, > > > = >=20 > > > > = Not really sure=20 whether you are misrepresenting anyone, = but... > > > > > >=20 > > > 1. My reading of one of Ben's messages = is that=20 associated > > = > > >=20 bidirectional paths are the only types of paths that can=20 be > > > = > created=20 in > > > = > > the existing=20 networks; "true" co-routed bidirectional = paths > > > > will = have > > > > > to wait until (if = ever) new equipment=20 becomes available. > > > >=20 > > > > = This is clearly=20 nonsense! > > = > > From the=20 point of view of hardware, co-routed >=20 > bidirectional LSPs are > >=20 > > a special case of associated bidirectional=20 LSPs. > > > = >=20 > > > > = If you can set up=20 two unidirectional LSPs (e.g. using the > > management > >=20 > > plane) you can surely set up a=20 co-routed > > = > bidirectional=20 LSP. > > > = >=20 > > > > = There are shipping=20 solutions that achieve co-routed >=20 bidirectional > = > > > LSPs=20 using the control plane. These either use the=20 GMPLS > > = (which=20 is > > > = > cleaner) or=20 non-standard proprietary solutions (which = is > > messy but > >=20 > > functional). > > >=20 > > > > = > But (of course)=20 the management plane or control plane > > solutions = have >=20 > > > nothing to do with availability of equipment as=20 they > are=20 software > > = > >=20 solutions. > > = > >=20 > > > > = > 2. My reading=20 of one of Neil's messages is that the = actual > > > > driver = for > > > > > co-routed = bidirectional paths may be=20 experience with existing > > >=20 > > transport networks rather than any specific=20 benefit. > > = > >=20 > > > > = Isn't that the case=20 with 75% of the MPLS-TP requirements? > > > > Which is not to say it is = a bad=20 thing. > > > = >=20 > > > > = A large driver for=20 MPLS-TP is to give the packet network > > the look, > >=20 > > feel, and behavioral characteristics of a=20 "legacy" > > = > > transport=20 network. > > = > >=20 > > > > = > Based on these=20 observations, I'd guess (FWIW) that: >=20 > > > > * associated bidirectional paths are, at least = for the=20 time > > > = > > =20 being, the most important type of bidirectional paths=20 in > > > = > > =20 MPLS-TP > = > > >=20 > > > > = I think that is=20 wrong both given my statement above, and > > given that > >=20 > > other upgrades to existing MPLS solutions will=20 be > needed to=20 reach > > > = > the full=20 function level of MPLS-TP. > > >=20 > > > > = > > * they had=20 a good chance to remain the only type of > > = bidirectional > >=20 > > > paths in real=20 deployments. > = > > >=20 > > > > = I don't see what=20 that follows from. > > > >=20 > > > >=20 Cheers, > > = > > Adrian > > > > > >=20 > >=20 = _______________________________________________ > > > > mpls-tp mailing = list > > > > = mpls-tp@ietf.org > > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > >=20 > >=20 = _______________________________________________ > > > > mpls-tp mailing = list > > > > = mpls-tp@ietf.org > > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > >=20 > > > > = >=20 = _______________________________________________ > > > mpls-tp mailing = list > > > = mpls-tp@ietf.org > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 >=20 = _______________________________________________ > mpls-tp mailing = list >=20 mpls-tp@ietf.org > = = https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp<= /TT> -----------------------------------------------------= --- ZTE Information Security Notice: The = information contained in this=20 mail is solely property of the sender's organization. This mail=20 communication is confidential. Recipients named above are = obligated to=20 maintain secrecy and are not permitted to disclose the contents of = this=20 communication to others. This email and=20 any files transmitted with it are confidential and intended solely = for the=20 use of the individual or entity to whom they are addressed. If you = have=20 received this email in error please notify the originator of the = message.=20 Any views expressed in this message are those of the individual=20 sender. This message = has been scanned for=20 viruses and Spam by ZTE Anti-Spam=20 system. --------------------------------------------------------= ZTE Information Security Notice: The infor= mation contained in this mail is solely&nbs= p;property of the sender's organization. This&nb= sp;mail communication is confidential. Recipients&nbs= p;named above are obligated to maintain sec= recy and are not permitted to disclose = ;the contents of this communication to othe= rs. This email and any files transmitted = with it are confidential and intended solel= y for the use of the individual or&nbs= p;entity to whom they are addressed. If&nbs= p;you have received this email in error&nbs= p;please notify the originator of the messa= ge. Any views expressed in this message&nbs= p;are those of the individual sender.= This message has been scanned for vir= uses and Spam by ZTE Anti-Spam system.= --Boundary_(ID_u1mq69FcHqzvyvFReqMYbQ)-- From andy.bd.reid@bt.com Mon Apr 27 05:57:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2253A6929 for ; Mon, 27 Apr 2009 05:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.379 X-Spam-Level: **** X-Spam-Status: No, score=4.379 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnbte4niRZVj for ; Mon, 27 Apr 2009 05:57:34 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7E1B93A6840 for ; Mon, 27 Apr 2009 05:57:33 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 13:58:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C737.E9908F78" Date: Mon, 27 Apr 2009 13:58:46 +0100 Message-ID: In-Reply-To: <002a01c9c733$92015470$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gAADv3tA From: To: X-OriginalArrivalTime: 27 Apr 2009 12:58:52.0949 (UTC) FILETIME=[EA945C50:01C9C737] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:57:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C737.E9908F78 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, =20 Snipped =20 "AIS generation is performed in the adaptation sink function for the set = of active client signals; i.e. for the set of connection/flow points = that are activated on the adaptation sink function (which are = represented by the set of active labels/VIDs/...)." =20 In your words, the adaptation sink function contains a set of label = values, one for each client connection. Different words, same thing. = This is a list of label values which requires configuration if it is to = be used for the injection of AIS and could be configured wrongly. It's = the same thing even in your ITU-T speak. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 27 April 2009 13:28 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 I have the impression that you do not have the correct understanding of = the SNC protection switching fucntional models and the location and = control of AIS insertion. Your understanding seems not aligned with the = specifications in our equipment and protection swithcing = recommendations. See inline... ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 12:50 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 It is of course true that adding a boolean input to a logical system = increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you = identify below. There are=20 =20 - good CC, no AIS =09 - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these input = states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly.=20 =20 [mv] I don't think that there is only "hope". This condition reflects = that there is no disconnect.=20 If every frame/packet arrives correctly is not checked by the reception = of CC and correct MEGID/MEPID. Frame/packet loss is checked by the = frame/packet loss measurement that is embedded in the CCM frames, and = can be activated.=20 =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is = because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below).=20 =20 [mv] With equipment that complies with the equipment standards this = condition doesn't give you just "hope". It gives you "knowledge" that = the discontinutity experienced in the connection is due to a server = layer fault.=20 =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS = forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending = on the exact scope of the forwarding labels, a protection switch may = well require the proactive purging of entries from the AIS forwarding = label injection table following the protection switch (this could = equivalently been seen as the forwarding function proactively dropping = the AIS packets).=20 =20 [mv] I don't think that those scenarios are likely scenarios. Equipment = compliant with ITU-T's equipment recommendations will not have those = scenarios. Only equipment that does not comply with those equipment = recommendations could have such scenarios. Just do not deploy such = equipment. =20 [mv] The AIS insertion in the functional models is performed in the = Adaptation Sink functions. Those Adaptation Sink functions are connected = to the Connection function in which the SNC Protection process is = located. The AIS insertion in an Adaptation sink fucntion continues = independent of the state of the protection switch process in the = Connection function; i.e. the selector in the protection process will = only receive frames/packets from either the working SNC, or the = protection SNC (but never from both).=20 =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a = forwarding function. But it could equally arise from a misconfiguration = of the AIS forwarding label injection table. In fact, the latter = actually seems just as likely and particularly problematic for = maintenance. Unlike normal forwarding, any mismatch between the = forwarding configuration and the AIS forwarding label injection table = will lie dormant and until a server fault arises. Then this generates a = false and misunderstood fault condition with maintenance looking for the = fault in the wrong place.=20 =20 [mv] As indicated in the above comment, equipment compliant with the = equipment and protection switching recommendation will not behave as you = suggest. Only equipment not-compliant with our equipment/protection = switching recommendation may do this, but such equipment should simply = not be deployed. =20 [mv] AIS generation is performed in the adaptation sink function for = the set of active client signals; i.e. for the set of connection/flow = points that are activated on the adaptation sink function (which are = represented by the set of active labels/VIDs/...). There is no "AIS = forwarding label injection table" in any of our equipment = recommendations. AIS will be generated for each client CI output on the = set of CPs/FPs on the adaptation sink function when aAIS consequent = action condition is true. =20 =20 The first two states can be reliably diagnosed with CC alone. The = second two arise from the introduction of the AIS/FDI. However, any = possible benefit that might arise is completely masked by the fact that = the AIS itself must be configured and there is no reason for this to be = more reliable than what it is supposed to be monitoring. Indeed, there = seems good reason to think that it will be less reliable.=20 =20 [mv] You are turning things upside down... CC is present to detect = continuity and connectivity problems introduced in the layer network's = Connection functions. As such you can not diagnose the second state with = CC alone. With CC alone one of your colleagues will be requested to = initiate a number of Loopback tests to find out which connection = function is misconfigured. This is the wrong action of course, as there = is a server layer fault. =20 [mv] You do not understand the AIS "configuration" aspect. AIS = generation configuration is on the node, not on each individual = connection. Networks that deploy AIS have it active on all their NNIs.=20 =20 There is no avoiding that AIS in circuit switching is fundamentally = different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something = and the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured.=20 =20 [mv] In packet transport networks with connectivity checking no packets = is not a valid condition.=20 =20 [mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require = any individual client connection specific information.=20 =20 [mv] ATM VP AIS and ATM VC AIS does not require any individual client = (i.e. VP, VC) connection specific information.=20 =20 [mv] ETH AIS does not require any individual client connection = identification specification, but it requires reuse of the client MEG = Level information which is also required for the ETH MIP functions on = the interface port. =20 [mv] I.e. AIS insertion does not require individual client connection = specific information. Either no additional information at all is = required, or additional information is required that is shared with = other fucntions/processes in the interface. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the = operational systems and processes are the same.=20 =20 [mv] And that is exactly what we do with support of AIS in packet = transport networks (ATM, Ethernet, T-MPLS =3D> MPLS-TP).=20 =20 The simple CC replicates all the triggers to management systems made by = SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data plane AIS requires a whole new area of configuration and generates = a whole new set of fault conditions which cannot be localised by = SONET/SDH processes. So, ironically, packet AIS is directly opposed to = backwards compatibility you claim is the main drive.=20 =20 [mv] I hope that you now understand that it is the opposite case is = that is present. Simple CC does **not** replicates all triggers... AIS = is needed in addition. =20 Regards, Maarten =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of = continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a = connection function (fabric) in the connection, which interrupts the = forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is = supported. It requires that the organization responsible for the layer = network takes action (i.e. locate the layer's connection function that = includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such = connection (due to a fault in a server layer) will also interrupt the = forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient = information to determine if the configuration in the layer's connection = functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. = This server layer fault is already reported by the server layer MEP = detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer = network fault (i.e. continuity fault). Fault localization must be = started to locate the misconfigured or failed connection function. Once = this faulty connection function is located, the configuration fault (or = hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in = both fault cases is however registered as part of performance = monitoring. This performance monitoring information is used to verify = the performance against the SLA for the connection. =20 Regards, Maarten =09 =09 ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only = adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network = management system). A problem occuring in admin domain A will be unknown = in admin domain B. The loss of continuaity alarms that are activated in = admin domain B due to the fault in admin domain A will appear as primary = alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want = different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server = layer. AIS suppresses the LOC alarm in those cases so that the = maintenance guys don't get triggered and start looking for a fault that = is outside their area. =20 Regards, Maarten =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems = (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. If, at an end equipment, = I have a good server/section layer and a loss of CC at the client layer, = I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service = guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system = is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions = will bring some complexity . but if we have no functions, it is more = complex and difcult for operators to maintence and administrator the = network. so I think every new functions and things may have positive and = negative effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network = (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means: = - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the = performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support = proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on = balance we considered not a good idea for PBB-TE OAM because it requires = a conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim.=20 =20 regards, Neil=20 =20 =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 =09 =09 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an = operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects = dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will = not be able to understand that as long as you refuse to accept that = "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated = connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE = and P-OTN VP trails inside metro and core domains interconnecting EVC = matrices. When one of those EVC links is interrupted, e.g. in the core between = metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more = frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a = connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and = OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means = is that OAM that is of a request/response nature cannot be trusted in co = mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it = won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to have = to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact = as they all offer something different/important. But do not be hoodwinked = by those who peddle a story that that tries to make the OAM of the 3 modes = the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a = return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs = could be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of = requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other = > > more important requirements (e.g. the possibility to work w/o IP = > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or = management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for = these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs = seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the = pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there = is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM = packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM = MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for = performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements = section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the = pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met = by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms = of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane = content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, = but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that = associated=20 > > > > > bidirectional paths are the only types of paths that can = be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional = paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the = time > > > > > being, the most important type of bidirectional paths = in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C737.E9908F78 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, Snipped "AIS generation is performed in the adaptation = sink=20 function for the set of active client signals; i.e. for the set of=20 connection/flow points that are activated on the adaptation sink = function (which=20 are represented by the set of active = labels/VIDs/...)." In your words, the adaptation sink = function=20 contains a set of label values, one for each client connection. = Different words,=20 same thing. This is a list of label values which requires = configuration if it is to be used for the injection of AIS and could be=20 configured wrongly. It's the same thing even in your ITU-T=20 speak. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = =20 British=20 Telecommunications plc Registered office: 81 Newgate Street London = EC1A=20 7AJ Registered in England no. 1800000 This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 27 April 2009=20 13:28 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, I have the = impression that=20 you do not have the correct understanding of the SNC protection = switching=20 fucntional models and the location and control of AIS insertion. Your=20 understanding seems not aligned with the specifications in our = equipment and=20 protection swithcing recommendations. See=20 inline... From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 12:50 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, It is of course true that adding a boolean = input to a=20 logical system increases the number of possible input states. So = adding an AIS=20 boolean to CC boolean creates four possible states not = just the=20 three you identify below. There are - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no=20 AIS We must ask what practical = scenarios could generate=20 each of these input states. Good CC, no AIS One hopes this is because this is = because the=20 service is working properly. [mv] I don't=20 think that there is only "hope". This condition reflects that = there is no=20 disconnect. If every=20 frame/packet arrives correctly is not checked by the reception of CC = and=20 correct MEGID/MEPID. Frame/packet loss is checked by the frame/packet = loss=20 measurement that is embedded in the CCM frames, and can be activated.=20 CC fault, AIS present One hopes this is because the service = is faulty and=20 one hopes this is because of a fault in a server layer. In fact, = the=20 presence of the AIS could be misleading (see below). [mv] With=20 equipment that complies with the equipment standards this = condition=20 doesn't give you just "hope". It gives you "knowledge" that the = discontinutity=20 experienced in the connection is due to a server layer=20 fault. Good=20 CC, AIS present This situation could arise because of a misconfiguration of = the AIS=20 forwarding label injection table. And there are a number of scenarios = which=20 make this quite likely when protection switching occurs. Depending on = the=20 exact scope of the forwarding labels, a protection switch may well = require the=20 proactive purging of entries from the AIS forwarding label injection = table=20 following the protection switch (this could equivalently been seen as = the=20 forwarding function proactively dropping the AIS packets). [mv] I don't = think that=20 those scenarios are likely scenarios. Equipment compliant with ITU-T's = equipment recommendations will not have those scenarios. Only = equipment that=20 does not comply with those equipment recommendations could have = such=20 scenarios. Just do not deploy such=20 equipment. [mv] The AIS insertion in the functional models = is=20 performed in the Adaptation Sink functions. Those Adaptation Sink = functions=20 are connected to the Connection function in which the SNC Protection = process=20 is located. The AIS insertion in an Adaptation sink fucntion = continues=20 independent of the state of the protection switch process in=20 the Connection function; i.e. the selector in the protection = process will=20 only receive frames/packets from either the working SNC, or the = protection SNC=20 (but never from = both). CC=20 fault, no AIS As you suggest, this could arise from a misconfiguration of a = forwarding function. But it could equally arise from a = misconfiguration of the=20 AIS forwarding label injection table. In fact, the latter actually = seems just=20 as likely and particularly problematic for = maintenance. Unlike=20 normal forwarding, any mismatch between the forwarding configuration = and the=20 AIS forwarding label injection table will lie dormant and until a = server fault=20 arises. Then this generates a false and misunderstood fault condition = with=20 maintenance looking for the fault in the wrong place. [mv] As = indicated in the=20 above comment, equipment compliant with the equipment and = protection=20 switching recommendation will not behave as you suggest. Only = equipment=20 not-compliant with our equipment/protection = switching recommendation may=20 do this, but such equipment should simply not be=20 deployed. [mv] AIS = generation is=20 performed in the adaptation sink function for the set of active = client=20 signals; i.e. for the set of connection/flow points that are activated = on the=20 adaptation sink function (which are represented by the set of active=20 labels/VIDs/...). There is no "AIS forwarding label injection table" = in any of=20 our equipment recommendations. AIS will be generated for each client = CI output=20 on the set of CPs/FPs on the adaptation sink function when aAIS = consequent=20 action condition is true. The first two states can be reliably diagnosed with CC = alone. The=20 second two arise from the introduction of the AIS/FDI. However, any = possible=20 benefit that might arise is completely masked by the fact that the AIS = itself=20 must be configured and there is no reason for this to be more reliable = than=20 what it is supposed to be monitoring. Indeed, there seems good reason = to think=20 that it will be less reliable. [mv] You are = turning=20 things upside down... CC is present to detect continuity and = connectivity=20 problems introduced in the layer network's Connection functions. As = such you=20 can not diagnose the second state with CC alone. With CC alone one of = your=20 colleagues will be requested to initiate a number of Loopback tests to = find=20 out which connection function is misconfigured. This is the wrong = action of=20 course, as there is a server layer=20 fault. [mv] You do = not understand=20 the AIS "configuration" aspect. AIS generation configuration is on the = node,=20 not on each individual connection. Networks that deploy AIS have it = active on=20 all their NNIs. There is no avoiding that AIS in circuit = switching is=20 fundamentally different from AIS in packet = switching. - in circuit switching, you must fill = the bit=20 stream with something and the information injected requires no = configuration=20 whatsoever. - in packet switching, no packets is a perfectly valid = condition=20 and the injection of AIS requires individual client connection = specific=20 information to be configured. [mv] In = packet transport=20 networks with connectivity checking no packets is not a valid = condition.=20 [mv]=20 AIS/FDI insertion specified in e.g. T-MPLS OAM does not = require any=20 individual client connection specific information.=20 [mv] ATM VP = AIS and ATM VC=20 AIS does not require any individual client (i.e. VP, VC) connection = specific=20 information. [mv] ETH AIS = does not=20 require any individual client connection identification specification, = but it=20 requires reuse of the client MEG Level information which is also = required for=20 the ETH MIP functions on the interface=20 port. [mv] I.e. = AIS insertion=20 does not require individual client connection specific information. = Either no=20 additional information at all is required, or additional information = is=20 required that is shared with other fucntions/processes in the=20 interface. The objective is not to replicate the data plane primitives = of=20 SONET/SDH, but the triggers to the operational systems so that the = operational=20 systems and processes are the same. [mv] And = that is exactly=20 what we do with support of AIS in packet transport networks (ATM, = Ethernet,=20 T-MPLS =3D> = MPLS-TP). The simple CC replicates all the triggers to management = systems made by=20 SONET/SDH and gives maximum compatibility. Conversely, the inclusion = of data=20 plane AIS requires a whole new area of configuration and generates a = whole new=20 set of fault conditions which cannot be localised by SONET/SDH = processes. So,=20 ironically, packet AIS is directly opposed to backwards compatibility = you=20 claim is the main drive. [mv] I hope = that you now=20 understand that it is the opposite case is that is = present. Simple=20 CC does **not** replicates all triggers... AIS is needed in=20 addition. Regards, Maarten Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 24 April 2009=20 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI does give additional information. = Let me=20 explain: The need for AIS/FDI is a consequence of = the deployment=20 of loss of continuity checking OAM (e.g. CCM in ethernet, CC in = ATM). The=20 objective of such CCM OAM is to be able to detect a misconfiguration = or=20 fault of a connection function (fabric) in the connection, which = interrupts=20 the forwarding of traffic in the connection. This is a fault = condition that=20 can only be discovered by the layer network in which the connection = is=20 supported. It requires that the organization responsible for the = layer=20 network takes action (i.e. locate the layer's connection = function that=20 includes the fault) to restore the = connection. Unfortunately, an interruption of one = of=20 the link connections of such connection (due to a fault in a = server=20 layer) will also interrupt the forwarding of traffic in the=20 connection. As such, loss of CC messages (LOC defect) = does not=20 provide sufficient information to determine if the configuration in = the=20 layer's connection functions along the connection have to be checked = and=20 corrected. AIS has been introduced and is used to help = differentiate between the two fault cases. 1) if LOC and AIS are detected, then there = is a server=20 layer fault. This server layer fault is already reported by the = server layer=20 MEP detecting this fault. No action is required, so no alarm to=20 generate. 2) if LOC is detected and there is no AIS, = then there=20 is a layer network fault (i.e. continuity fault). Fault localization = must be=20 started to locate the misconfigured or failed connection function. = Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is = retored. The interruption of the forwarding of = traffic in the=20 connection in both fault cases is however registered as part of = performance=20 monitoring. This performance monitoring information is used to = verify the=20 performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points I = made. My=20 point is that AIS/FDI gives no information above what is already = known - it=20 is only adds complexity and fault liability. Neither of your points = change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000=20 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009 = 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily=20 available. I don't = believe that=20 this is a correct statement in a multi-operator transport network, = or in=20 transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring in admin domain A will be unknown in admin domain B. The = loss of=20 continuaity alarms that are activated in admin domain B due to the = fault=20 in admin domain A will appear as primary alarms, suggesting = connectivity=20 problems in admin domain B. > = The issue=20 arises because the two sides of maintenance want different things. = The=20 fault fixing > guys want to locate the fault and don't want = any other=20 information. The service=20 maintenance > guys want to know whether their customer = service is=20 working. This is addressed in SDH, OTN, Ethernet = and=20 T-MPLS recommendations by means of the additional SSF alarm. = The SSF=20 alarm is for the service guys telling them that the service was=20 interrupted due to a fault in a server layer. AIS suppresses the = LOC alarm=20 in those cases so that the maintenance guys don't get triggered = and start=20 looking for a fault that is outside their = area. Regards, Maarten From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two=20 things which are separate and for which AIS/FDI is no help. = Maintenance=20 operations are concerned with two separate = things. 1) Identifying faults in equipment, = line plant,=20 and other systems (eg misconfigurations) and fixing them = (equipment=20 maintenance). 2) Identifying the health of end to = end=20 connections, especially when they are directly supporting customer = services (service maintenance). The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily = available. If,=20 at an end equipment, I have a good server/section layer and a loss = of CC=20 at the client layer, I *know* the fault is elsewhere - I don't = need=20 AIS/FDI to tell me. (Indeed, if you think about, if the fault is = in the=20 end equipment, it is quite likely that the fault means it cannot = report=20 the traffic loss to the management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the = fault and=20 don't want any other information. The service maintenance guys = want to=20 know whether their customer service is = working. This arose in the early days of = SONET/SDH, when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know=20 about the alarms. The normal practice is for the equipment = to report=20 the alarms *including* AIS and then a filter is applied in the = management=20 system to suppress alarms to the fault fixing guys. As I'm = aware,=20 there are many different techniques applied for the filtering = algorithms,=20 especially when you consider multiple concurrent faults in a = network,=20 however, the existance of AIS/FDI doesn't add anything to these = that's not=20 already known. In fact, I believe simple time-stamp = correlation is=20 one of the most powerful and widely used techniques. And if the = equipment=20 starts messing up the reporting of loss of CC because it waiting=20 for/persistence checking AIS/FDI, it could end up messing up = simple=20 time-stamp correlation! In practice, it is often not quite a = simple as this,=20 as the service guys like to be able to 'localise' the fault. = However,=20 under most circumstances, the filter has automatically done = this.=20 So localisation you describe is only when the filter = hasn't=20 worked for some reason. But the bottom line is, whatever = operations process=20 you want to use, AIS/FDI doesn't add anything other than = complexity=20 and fault liability to the equipment. Remember AIS goes back = to the=20 TDM world where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 = (0)1277=20 324015 Email: = andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000 = This=20 electronic message contains information from British = Telecommunications=20 plc which may be privileged or confidential. The information is = intended=20 to be for the use of the individual(s) or entity named above. If = you are=20 not the intended recipient be aware that any disclosure, copying,=20 distribution or use of the contents of this information is = prohibited. If=20 you have received this electronic message in error, please notify = us by=20 telephone or email (to the numbers or address above)=20 immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded to secure effective operation and for other lawful = business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil: = thank you for wasting more = time in=20 describling the problems. but I think some of what you said is = no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense=20 in cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI=20 functions, when there is a defects in a given layer network, it = can=20 cause multiple alarm events to be raised. it is diffcult = for=20 operators to locate and diagnose the faults. though I completely agree you = on=20 adding new things and functions will bring some complexity = . but=20 if we have no functions, it is more complex and difcult for = operators to=20 maintence and administrator the network. so I think every new = functions=20 and things may have positive and negative effects. but we should = consider it very much, don't delete some functions at = random.=20 best regards = liu <neil.2.harrison@bt.com> 2009-04-21 = 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If MPLS-TP is going to be taken seriously as a = transport network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are = these.=20 1 Provide a transparent = client/server=20 relationship...which means: - all client bits treated=20 equally -=20 client bit ordering preserved - = no attempt to=20 infer client symbol (ie sequence of client bits) meaning and no = attempt=20 to change client symbols - the traffic behaviour of = client X=20 must not impact the performance experienced by client Y = A key corollary of the above is that MPLS-TP must only = support=20 proper connections (ie single source constructs) = = 2 Since = MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does = not=20 support directly external message/file/stream applications).=20 MPLS-TP therefore does not require an E-NNI specification. = A=20 key corollary of this is that MPLS-TP will not have any peer=20 interworking relationship with any other network = mode/technology.=20 Now wrt OAM = MPLS-TP is a co-ps=20 mode network. You could argue this should have = FDI/AIS....however,=20 the merit of this is highly questionable. When I and = colleagues=20 discussed whether PBB-TE (also a co-ps mode network) should have = FDI/AIS=20 we concluded that on balance it was not a good idea.....and note = that=20 initially I was in favour of having AIS, but my colleagues = provided=20 strong technical arguments that convinced me otherwise. = AIS/FDI is historically linked to the early PDH co-cs = mode layer=20 networks that used TTL logic. When this died it put out a = +5V (all=20 1s) signal by default, ie it required no conscious effort to = generate=20 it.....this is key point. Further, in these networks there = is a=20 fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never=20 specified AIS for IP and its why IEEE had the good sense to = throw-out=20 AIS in 802.1ag for Ethernet (though ITU have unwisely IMO = retained it in=20 Y.1731....but I suspect any operator planning to use Ethernet = equipment=20 would always look to IEEE stds and not ITU ones). = AIS/FDI and the co-ps mode is debatable. As I = noted above,=20 on balance we considered not a good idea for PBB-TE OAM because = it=20 requires a conscious effort to generate it (unlike the co-cs = mode) so=20 there are likely to be scaling problems and its one more thing = to go=20 wrong. You should also = have seen me=20 make the point many times in the past that the always-on defect=20 detection/handling OAM needs to be as simple/sparse as possible = with as=20 little config as possible because we need super = reliability......TCM=20 goes completely against the grain here. Also note that the = OAM=20 required for each of the 3 network modes is not the same, = despite what=20 some claim. regards, = Neil From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Deborah: maybe what you said is right. but = I can't=20 completely agree your opinions. IMO. mpls-tp is regard as = transport=20 network like SDH/SONET. so it should have AIS/FDI fuctions as=20 SDH/SONET. do you think so. = best regards liu "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org = 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with = Neil, it is very=20 questionable the value of AIS/FDI in a packet network- any = mode. It=20 can result in a DoS attack by an operator on themselves so = even Y1731=20 recommends not to block data frames: "A MEP can decide = whether it=20 blocks data frames when it detects dAIS. The principle=20 requirement that influences this decision is that data frames = ought=20 to be forwarded as much as possible, without the = possibility of=20 forwarding wrong data frames downstream." Table I.7-2 shows = for AIS,=20 not to block. And as Y1731 states, AIS can only be used = under=20 very constrained architectures - if required for MPLS-TP, it = needs to=20 have the same guidance as in Y1731, i.e. point-to-point and=20 server/client one-to-one: "for a point-to-point ETH = connection, a MEP=20 has only a single peer MEP. Therefore, there is no = ambiguity=20 regarding the peer MEP for which it should suppress alarms = when it=20 receives the ETH-AIS information." So should only be = within one=20 domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the = cl=20 mode?...do me a favour! Ethernet AIS is indeed a = requirement and=20 a necessity. And you will not be able to understand that = as long=20 as you refuse to accept that "cl-mode" is a forwarding = mode within=20 a **transport entity**. G.800 amendment 1 = has finally reintroduced=20 this transport entity into G.800. Besides that, it = also introduced=20 the **differentiated connection**: [G.800 am1] "A = differentiated=20 connection is a transport entity that transfers information = belonging=20 to multiple communications between ports across a subnetwork. = <..> In a differentiated connection = message contents are=20 interpreted to identify (sets of) communications which=20 receive different treatment. The sets of = communications may=20 be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms of=20 G.800 "differentiated connections". Ethernet AIS provides = AIS=20 within the scope of such "differentiated = connection". If you apply=20 this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and core = domains=20 interconnecting EVC matrices. When one of those EVC links = is=20 interrupted, e.g. in the core between metro 1 and metro 4 = (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS = is=20 inserted in the downstream direction to suppress the EVC-LOC = alarms=20 at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet AIS)=20 frame has a reserved multicast address, which guarantees that = the AIS=20 is broadcast to the endpoints of the EVC. I believe that = it is=20 time for you to adapt your view on co and cl = modes and relate it=20 to the forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP = differentiated connection"=20 with a billion or more ports. What we know as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN is=20 essentially an "Ethernet differentiated connection" with n = ports=20 (n in the range of e.g. 2 to 1000). What we know as a p2p = MPLS E-LSP=20 is essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection" with=20 2 ports. Transport network OAM applies to transport = entities,=20 which are (in terms of G.800 am1) connections and = differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: = RE:=20 [mpls-tp] Associated bidirectional transport=20 path requirements John, Thanks this is a great = platform=20 to explain why OAM for the 3 network modes needs to be = different.=20 I am getting a wee bit tired of folks trying to make = all 3=20 network modes look alike (and then, even worse, = interwork them as=20 as peers...esp when not not top-of-stack networks...I mean = how silly=20 can we get?). I am even more frustrated by the fact = those=20 peddling this FUD only ever seem to consider OAM = and forget all=20 other DP/CP/MP components (esp top-of-stack=20 message/file/stream application adaptations). How wrong = can=20 this get! In the co modes a *connection* is a very = specific and=20 *constraining* construct.....I am assuming here we respect = the rules=20 of a connection (ie single source) though some folks don't = even=20 bother to respect this, and this is despite the fact that = we all=20 know what problems multiple-source constructs can cause (from = LDP/PHP....ergo MPLS-TP). When we have a connection this=20 restricts *all* DP (ie traffic and OAM) to stay within the = bounds=20 of the connection. Which is fine=20 under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is = broken.=20 In a nutshell what this means is that OAM that is of = a=20 request/response nature cannot be trusted in co mode networks = under=20 misconnectivity defects.....indeed, why should a = leaking DP have a=20 symmetric go/return defect behaviour?....very likely it=20 won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts to = explain=20 that physics....G.805 does not. So, the 3 modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the=20 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander = Vainshtein;=20 Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path >=20 requirements > > Italo, > > As = described in=20 the MPLS TP OAM Requirements I-D, virtually all of = the > OAM=20 functions require a return path, and in the absence of a return = >=20 path they are disabled. > > As described in David=20 Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the issue=20 of return path for unidirectional LSPs could be > = charaterized=20 as the elephant in the room. In the MPLS TP OAM > = Framework=20 I-D, unicast LSPs are only mentioned three times and return = >=20 paths not at all. > > Thanks, > > = John >=20 > -----Original Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April=20 17, 2009 1:59 AM > > To: Drake, John E; Alexander = Vainshtein;=20 Maarten Vissers > > Cc: mpls-tp@ietf.org > > = Subject:=20 RE: [mpls-tp] Associated bidirectional transport path > = >=20 requirements > > > > John, > > = > >=20 I might have missed the agreement of MPLS-TP being capable of = >=20 > sending replies to OAM requests sent on uni-directional=20 LSPs. > > > > This requirement does not = belong to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken = into=20 account (at worst in a > subsequent phase). > > = >=20 > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility = to work=20 w/o IP > > forwarding and the need for OAM to continue = to=20 monitor the data > > plane also in case of failures = affecting=20 the control or management > > plane). > > = >=20 > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = >=20 > > -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 > > Sent: Thursday, April 16, 2009 8:00 PM > > = > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc:=20 mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > = requirements >=20 > > > > > At the meeting last fall at Juniper = in=20 Massachusetts, I > > think it was > > > = agreed that=20 an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM = packets=20 (e.g., sending > > replies to OAM > > > = requests=20 sent on uni-directional LSPs) even if it does not > > = have an=20 IP > > > forwarding data plane. > > > = >=20 > > > -----Original Message----- > > > > = From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > = >=20 > > > Maarten, > > > > It seems that = you've just=20 (implicitly and, probably, > > > > inadvertently) = stated=20 the following: > > > > > > > > = =20 MPLS-TP = OAM will=20 not ever support MIP loopback function > > (and = fault >=20 > > > localization which requires this function ) = for >=20 > unidirectional P2MP > > > > and P2P = paths. >=20 > > > > > > > If this statement is = correct,=20 this (IMHO and FWIW) > raises a valid > > > = >=20 question: > > > > > > > > = =20 Is MPLS-TP an=20 appropriate solution for these > types of = transport > >=20 > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > = functionality=20 today > > > > for (unidirectional - but it does = not know=20 any other > > type) P2P LSPs > > > > as=20 described in RFC 4379. And its extension to P2MP LSPs seems = >=20 > > > easy... > > > > > > > = >=20 > > > > > > > > = Regards, >=20 > > > > > > > = Sasha >=20 > > > > > > > > > > > = >=20 > > > ________________________________________ > = >=20 > > From: mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On Behalf > > = > >=20 Of Maarten Vissers [maarten.vissers@huawei.com] > > = > >=20 Sent: Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional = transport path=20 > > > > requirements > > > > = >=20 > > > Adrian, > > > > > > > = >=20 >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > = > >=20 > other internal > > > > >> = =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of = that > >=20 > > >> transport path. > = >=20 > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > is, there is > > > > >=20 *nothing* that can be observed from a black box point of > = >=20 > view that > > > > > results from adhering = to this=20 requirement. > > > > > > > > Your = understanding is not correct. It is very much > observable = if > > > > this requirement is met from a black = box point=20 of view. > > > > The MIP functions can only = perform the=20 Loopback when there is a > > > > co-routed = bidirectional=20 transport path. The MPLS-TP LBM packet > > > > = received=20 at a MIP needs to be returned (as LBR > > > > = packet) to=20 the originating MEP function via the other > > = direction=20 of > > > > the co-routed bidirectional transport = path.=20 This other > direction > > > > would not be = available in an associated bidirectional transport > > = >=20 > path... and thus the loopback test > > > would=20 fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not in a > > > > associated = bidir=20 transport path. In the first case the TCM MEP > > > = >=20 Source and Sink functions are co-located and can > = exchange what=20 is > > > > called "remote information" which is = necessary=20 for performance > > > > monitoring. > > = >=20 > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, > >=20 > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = > Your=20 understanding is not correct. This text must not be > > = deleted=20 at > > > > all. > > > > > = > >=20 > > Actually, I am quite fed up about this = persistent > >=20 > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > >=20 is > > > > poorly > > > > > = specified=20 and comes from the monitoring of a path that is > > = > >=20 parallel (i.e. > > > > tandem) > > > = >=20 > to the data path being monitored. This definition of = TC >=20 > > > seems to be at > > > > = variance, >=20 > > > > and would be if the ACH was actually in=20 band. > > > > > > > > I don't = understand=20 where your interpretation of tandem > > connection = is >=20 > > > described in ITU-T recommendations. I.e. "from=20 the > > monitoring of a > > > > path = that is=20 parallel (i.e. tandem) to the data path being > > > = >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection is = a=20 set > > > > of interconnected "link connections" = and=20 "matrix > connections". A > > > > subset of = those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to as > = a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There=20 is only additional OAM inserted inside the data > path by=20 the > > > > TCM MEP_So function and this OAM is = extracted=20 from the > > data path by > > > > the = TCM MEP_Sk=20 function. > > > > > > > >=20 Regards, > > > > Maarten > > > > = >=20 > > > > > > > -----Original=20 Message----- > > > > From:=20 mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel >=20 > > > Sent: donderdag 16 april 2009 11:59 > > = >=20 > To: Alexander Vainshtein; = benjamin.niven-jenkins@bt.com >=20 > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = >=20 > > > requirements > > > > > > = >=20 > Hi Sasha, > > > > > > > > = >=20 Unfortunately I cannot fully agree with your statement: > = >=20 > > > > > > > > <quote> > = >=20 > > > From the point of view of hardware, = co-routed > > > bidirectional LSPs > > > = >=20 > are a special case of associated = bidirectional=20 LSPs. > > > > > <end quote> > > = >=20 > > > > > > > This statement would be = obviously=20 correct, were it not for > > > > = Requirement > >=20 > > > 34 in the latest MPLS-TP requirements = draft > >=20 > > > > > > OK. Got it. > > > = >=20 > > > > But what is this doing in the data plane = requirements section? > > > > > > > = > In=20 fact, what is this requirement actually saying? > > = > >=20 > > > > > <quote> > > > = > >=20 The intermediate nodes (including MEPs, MIPs = and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > = > >=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > > relationship of the = forward and=20 the backward > > > > directions of that > = > >=20 > > transport path. > > > = >=20 > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > = > is,=20 there is > > > > *nothing* that can be observed = from a=20 black box point of > > view that > > > > = results=20 from adhering to this requirement. > > > > = > >=20 > > Therefore it could be assumed that this requirement is = met by=20 > > > > configuring some data plane database = component=20 through the > > > > management plane. The = database=20 component is not used > for anything > > > = > except=20 to satisfy this requirement for "awareness". > > > = >=20 > > > > Ben! Can we please try to rewrite this=20 requirement in terms of > > > > = behavior? > >=20 > > > > > > > Please note that = Requirement 34=20 is the ONLY item in the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = >=20 > paths are > > > > > exactly the same even = if they=20 appear in two different > > > items in the > = > >=20 > > requirements' list). > > > > > In = other=20 words, without Requirement 34 the notion of > = co-routed >=20 > > > > bidirectional paths would be void of any = data plane=20 content. > > > > > > > > > > = The=20 somewhat vague scope of this requirement ("other internal = > >=20 > > > functions as appropriate") creates a suspicion = that=20 HW > > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with = it. >=20 > > > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > MIPs and other > > = >=20 > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate=20 nodes." > > > > > > > > > The=20 following text in the draft increases this suspicion: > = > >=20 > > > > > > > <quote> > > = >=20 > > Tandem Connection: A tandem connection is = an >=20 > arbitrary part of a > > > > > = transport=20 path that can be monitored (via OAM) > > > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of a=20 transport path. > > The tandem > > > = >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > > > > = > =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = >=20 > Actually, I am quite fed up about this persistent > = >=20 insistence on the > > > > inclusion of "Tandem=20 Connection." The definition within > > the ITU-T = of >=20 > > > this term is poorly specified and comes from = the >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > = >=20 > > > > > > Doesn't "forwarding engine" = sound like=20 hardware to you? > > > > > > > > = Yes, but=20 so what? > > > > > > > > > = IMHO it is=20 worth noting that neither the MPLS-TP > > > = Requirements=20 draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > > > > > > > > = >=20 > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed in=20 the MPLS-TP OAM > > Framework > > > > = >=20 draft > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > = >=20 > > > > > > Right. > > > > = Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some clarity=20 regarding > > > co-routed vs. > > > > = >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 to=20 specific > > > functionality. > > > > = > > > > Agreed. > > > > > = >=20 > > Adrian > > > > > > > > = >=20 > > > > > > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: = Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc:=20 mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > Not really = sure=20 whether you are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one of Ben's = messages is that associated > > > > >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will = have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > = > This=20 is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > = >=20 > > a special case of associated bidirectional = LSPs. > >=20 > > > > > > If you can set up two = unidirectional=20 LSPs (e.g. using the > > management > > > = >=20 plane) you can surely set up a co-routed > > > = bidirectional=20 LSP. > > > > > > > > There are = shipping=20 solutions that achieve co-routed > bidirectional > = > >=20 > LSPs using the control plane. These either use the = GMPLS >=20 > (which is > > > > cleaner) or non-standard=20 proprietary solutions (which is > > messy but > = > >=20 > functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are = software > >=20 > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the = actual > >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > = >=20 transport networks rather than any specific benefit. > = > >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, >=20 > > > feel, and behavioral characteristics of a=20 "legacy" > > > > transport network. > > = >=20 > > > > > > Based on these observations, = I'd guess=20 (FWIW) that: > > > > > * associated = bidirectional=20 paths are, at least for the time > > > > > = =20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = >=20 > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other = upgrades to=20 existing MPLS solutions will be > needed to reach > = >=20 > > the full function level of MPLS-TP. > > > = >=20 > > > > > * they had a good chance to remain = the only=20 type of > > bidirectional > > > > > = =20 paths in real deployments. > > > > > = >=20 > > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > mpls-tp@ietf.org > = >=20 > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy=20 and are not permitted to disclose the contents of this = communication to=20 others. This email and any files transmitted with it are = confidential=20 and intended solely for the use of the individual or entity to = whom they=20 are addressed. If you have received this email in error please = notify=20 the originator of the message. Any views expressed in this = message are=20 those of the individual sender. This message has been scanned = for=20 viruses and Spam by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9C737.E9908F78-- From maarten.vissers@huawei.com Mon Apr 27 06:42:30 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3263A6826 for ; Mon, 27 Apr 2009 06:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.642 X-Spam-Level: **** X-Spam-Status: No, score=4.642 tagged_above=-999 required=5 tests=[AWL=-2.914, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSJL5V8LRonw for ; Mon, 27 Apr 2009 06:42:23 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2CF833A6AFB for ; Mon, 27 Apr 2009 06:42:22 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR00EEKI4JA3@szxga03-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 21:43:32 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR0056DI4IVU@szxga03-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 21:43:31 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIR00LCOI3TY5@szxml02-in.huawei.com>; Mon, 27 Apr 2009 21:43:30 +0800 (CST) Date: Mon, 27 Apr 2009 15:43:08 +0200 From: Maarten Vissers In-reply-to: To: andy.bd.reid@bt.com Message-id: <005001c9c73e$1c17ee80$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_+k9y/YE2jJaJFuX9dfYIng)" Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gAADv3tAAADKjhA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:42:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+k9y/YE2jJaJFuX9dfYIng) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, =20 The configuration of this set of label values in the adaptation function = is locked to the configuration of the set of matrix connections/matrix forwarding processes. It is locked to the creation of the = "Connection/Flow Point" that interconnects the Matrix and Adaptation functions. I.e. a = sinlge action which result in configuration of both a Connection = function/Matrix and an Adaptation function/Link End. =20 If there would be any mistake in this configuration, you will notice = this immediately as the CC frames will not reach the MEP Sink functions at = the output ports of the connection (i.e. connection set up is not = succesful). =20 Regards, Maarten =20 _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 14:59 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 Snipped =20 "AIS generation is performed in the adaptation sink function for the set = of active client signals; i.e. for the set of connection/flow points that = are activated on the adaptation sink function (which are represented by the = set of active labels/VIDs/...)." =20 In your words, the adaptation sink function contains a set of label = values, one for each client connection. Different words, same thing. This is a = list of label values which requires configuration if it is to be used for the injection of AIS and could be configured wrongly. It's the same thing = even in your ITU-T speak. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 27 April 2009 13:28 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 I have the impression that you do not have the correct understanding of = the SNC protection switching fucntional models and the location and control = of AIS insertion. Your understanding seems not aligned with the = specifications in our equipment and protection swithcing recommendations. See inline... _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 12:50 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 It is of course true that adding a boolean input to a logical system increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you identify below. There are=20 =20 - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these input states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly.=20 =20 [mv] I don't think that there is only "hope". This condition reflects = that there is no disconnect.=20 If every frame/packet arrives correctly is not checked by the reception = of CC and correct MEGID/MEPID. Frame/packet loss is checked by the = frame/packet loss measurement that is embedded in the CCM frames, and can be = activated.=20 =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below).=20 =20 [mv] With equipment that complies with the equipment standards this condition doesn't give you just "hope". It gives you "knowledge" that = the discontinutity experienced in the connection is due to a server layer = fault. =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending on = the exact scope of the forwarding labels, a protection switch may well = require the proactive purging of entries from the AIS forwarding label injection table following the protection switch (this could equivalently been seen = as the forwarding function proactively dropping the AIS packets).=20 =20 [mv] I don't think that those scenarios are likely scenarios. Equipment compliant with ITU-T's equipment recommendations will not have those scenarios. Only equipment that does not comply with those equipment recommendations could have such scenarios. Just do not deploy such equipment. =20 [mv] The AIS insertion in the functional models is performed in the Adaptation Sink functions. Those Adaptation Sink functions are connected = to the Connection function in which the SNC Protection process is located. = The AIS insertion in an Adaptation sink fucntion continues independent of = the state of the protection switch process in the Connection function; i.e. = the selector in the protection process will only receive frames/packets from either the working SNC, or the protection SNC (but never from both).=20 =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a forwarding function. But it could equally arise from a misconfiguration of the AIS forwarding label injection table. In fact, the latter actually seems = just as likely and particularly problematic for maintenance. Unlike normal forwarding, any mismatch between the forwarding configuration and the = AIS forwarding label injection table will lie dormant and until a server = fault arises. Then this generates a false and misunderstood fault condition = with maintenance looking for the fault in the wrong place.=20 =20 [mv] As indicated in the above comment, equipment compliant with the equipment and protection switching recommendation will not behave as you suggest. Only equipment not-compliant with our equipment/protection switching recommendation may do this, but such equipment should simply = not be deployed. =20 [mv] AIS generation is performed in the adaptation sink function for the = set of active client signals; i.e. for the set of connection/flow points = that are activated on the adaptation sink function (which are represented by = the set of active labels/VIDs/...). There is no "AIS forwarding label = injection table" in any of our equipment recommendations. AIS will be generated = for each client CI output on the set of CPs/FPs on the adaptation sink = function when aAIS consequent action condition is true. =20 =20 The first two states can be reliably diagnosed with CC alone. The second = two arise from the introduction of the AIS/FDI. However, any possible = benefit that might arise is completely masked by the fact that the AIS itself = must be configured and there is no reason for this to be more reliable than = what it is supposed to be monitoring. Indeed, there seems good reason to = think that it will be less reliable.=20 =20 [mv] You are turning things upside down... CC is present to detect continuity and connectivity problems introduced in the layer network's Connection functions. As such you can not diagnose the second state with = CC alone. With CC alone one of your colleagues will be requested to = initiate a number of Loopback tests to find out which connection function is misconfigured. This is the wrong action of course, as there is a server layer fault. =20 [mv] You do not understand the AIS "configuration" aspect. AIS = generation configuration is on the node, not on each individual connection. = Networks that deploy AIS have it active on all their NNIs.=20 =20 There is no avoiding that AIS in circuit switching is fundamentally different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something and = the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured.=20 =20 [mv] In packet transport networks with connectivity checking no packets = is not a valid condition.=20 =20 [mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require any individual client connection specific information.=20 =20 [mv] ATM VP AIS and ATM VC AIS does not require any individual client = (i.e. VP, VC) connection specific information.=20 =20 [mv] ETH AIS does not require any individual client connection identification specification, but it requires reuse of the client MEG = Level information which is also required for the ETH MIP functions on the interface port. =20 [mv] I.e. AIS insertion does not require individual client connection specific information. Either no additional information at all is = required, or additional information is required that is shared with other fucntions/processes in the interface. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the operational = systems and processes are the same.=20 =20 [mv] And that is exactly what we do with support of AIS in packet = transport networks (ATM, Ethernet, T-MPLS =3D> MPLS-TP).=20 =20 The simple CC replicates all the triggers to management systems made by SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data plane AIS requires a whole new area of configuration and generates a = whole new set of fault conditions which cannot be localised by SONET/SDH processes. So, ironically, packet AIS is directly opposed to backwards compatibility you claim is the main drive.=20 =20 [mv] I hope that you now understand that it is the opposite case is that = is present. Simple CC does **not** replicates all triggers... AIS is needed = in addition. =20 Regards, Maarten =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to = locate the misconfigured or failed connection function. Once this faulty = connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the performance = against the SLA for the connection. =20 Regards, Maarten _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin = domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server layer. = AIS suppresses the LOC alarm in those cases so that the maintenance guys = don't get triggered and start looking for a fault that is outside their area. =20 Regards, Maarten =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are concerned = with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* = the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you = think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even when AIS = was being received as the service guys want to know about the alarms. The = normal practice is for the equipment to report the alarms *including* AIS and = then a filter is applied in the management system to suppress alarms to the = fault fixing guys. As I'm aware, there are many different techniques applied = for the filtering algorithms, especially when you consider multiple = concurrent faults in a network, however, the existance of AIS/FDI doesn't add = anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And = if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up = simple time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation you describe is = only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to = fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, maybe = AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there = is no AIS/FDI functions, when there is a defects in a given layer network, = it can cause multiple alarm events to be raised. it is diffcult for = operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so I = think every new functions and things may have positive and negative effects. = but we should consider it very much, don't delete some functions at random.=20 best regards=20 liu=20 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Boundary_(ID_+k9y/YE2jJaJFuX9dfYIng) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Andy, The configuration of this set of label values = in the=20 adaptation function is locked to the = configuration of=20 the set of matrix connections/matrix forwarding processes. It is = locked to=20 the creation of the "Connection/Flow Point" that interconnects the = Matrix and=20 Adaptation functions. I.e. a sinlge action which result in configuration = of both=20 a Connection function/Matrix and an Adaptation function/Link=20 End. If there would be any mistake in this = configuration, you=20 will notice this immediately as the CC frames will not reach the MEP = Sink=20 functions at the output ports of the connection (i.e. connection set up = is not=20 succesful). Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 14:59 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, Snipped "AIS generation is performed in the adaptation = sink=20 function for the set of active client signals; i.e. for the set of=20 connection/flow points that are activated on the adaptation sink = function (which=20 are represented by the set of active = labels/VIDs/...)." In your words, the adaptation sink = function=20 contains a set of label values, one for each client connection. = Different words,=20 same thing. This is a list of label values which requires = configuration if it is to be used for the injection of AIS and could be=20 configured wrongly. It's the same thing even in your ITU-T=20 speak. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277=20 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 Newgate = Street=20 London EC1A 7AJ Registered in England no. 1800000 = This electronic = message=20 contains information from British Telecommunications plc which may be = privileged=20 or confidential. The information is intended to be for the use of the=20 individual(s) or entity named above. If you are not the intended = recipient be=20 aware that any disclosure, copying, distribution or use of the contents = of this=20 information is prohibited. If you have received this electronic message = in=20 error, please notify us by telephone or email (to the numbers or address = above)=20 immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications using=20 this system will also be monitored and may be recorded to secure = effective=20 operation and for other lawful business purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 27 April 2009=20 13:28 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, I have the = impression that=20 you do not have the correct understanding of the SNC protection = switching=20 fucntional models and the location and control of AIS insertion. Your=20 understanding seems not aligned with the specifications in our = equipment and=20 protection swithcing recommendations. See=20 inline... From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 12:50 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, It is of course true that adding a boolean = input to a=20 logical system increases the number of possible input states. So = adding an AIS=20 boolean to CC boolean creates four possible states not = just the=20 three you identify below. There are - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no=20 AIS We must ask what practical = scenarios could generate=20 each of these input states. Good CC, no AIS One hopes this is because this is = because the=20 service is working properly. [mv] I don't=20 think that there is only "hope". This condition reflects that = there is no=20 disconnect. If every=20 frame/packet arrives correctly is not checked by the reception of CC = and=20 correct MEGID/MEPID. Frame/packet loss is checked by the frame/packet = loss=20 measurement that is embedded in the CCM frames, and can be activated.=20 CC fault, AIS present One hopes this is because the service = is faulty and=20 one hopes this is because of a fault in a server layer. In fact, = the=20 presence of the AIS could be misleading (see below). [mv] With=20 equipment that complies with the equipment standards this = condition=20 doesn't give you just "hope". It gives you "knowledge" that the = discontinutity=20 experienced in the connection is due to a server layer=20 fault. Good=20 CC, AIS present This situation could arise because of a misconfiguration of = the AIS=20 forwarding label injection table. And there are a number of scenarios = which=20 make this quite likely when protection switching occurs. Depending on = the=20 exact scope of the forwarding labels, a protection switch may well = require the=20 proactive purging of entries from the AIS forwarding label injection = table=20 following the protection switch (this could equivalently been seen as = the=20 forwarding function proactively dropping the AIS packets). [mv] I don't = think that=20 those scenarios are likely scenarios. Equipment compliant with ITU-T's = equipment recommendations will not have those scenarios. Only = equipment that=20 does not comply with those equipment recommendations could have = such=20 scenarios. Just do not deploy such=20 equipment. [mv] The AIS insertion in the functional models = is=20 performed in the Adaptation Sink functions. Those Adaptation Sink = functions=20 are connected to the Connection function in which the SNC Protection = process=20 is located. The AIS insertion in an Adaptation sink fucntion = continues=20 independent of the state of the protection switch process in=20 the Connection function; i.e. the selector in the protection = process will=20 only receive frames/packets from either the working SNC, or the = protection SNC=20 (but never from = both). CC=20 fault, no AIS As you suggest, this could arise from a misconfiguration of a = forwarding function. But it could equally arise from a = misconfiguration of the=20 AIS forwarding label injection table. In fact, the latter actually = seems just=20 as likely and particularly problematic for = maintenance. Unlike=20 normal forwarding, any mismatch between the forwarding configuration = and the=20 AIS forwarding label injection table will lie dormant and until a = server fault=20 arises. Then this generates a false and misunderstood fault condition = with=20 maintenance looking for the fault in the wrong place. [mv] As = indicated in the=20 above comment, equipment compliant with the equipment and = protection=20 switching recommendation will not behave as you suggest. Only = equipment=20 not-compliant with our equipment/protection = switching recommendation may=20 do this, but such equipment should simply not be=20 deployed. [mv] AIS = generation is=20 performed in the adaptation sink function for the set of active = client=20 signals; i.e. for the set of connection/flow points that are activated = on the=20 adaptation sink function (which are represented by the set of active=20 labels/VIDs/...). There is no "AIS forwarding label injection table" = in any of=20 our equipment recommendations. AIS will be generated for each client = CI output=20 on the set of CPs/FPs on the adaptation sink function when aAIS = consequent=20 action condition is true. The first two states can be reliably diagnosed with CC = alone. The=20 second two arise from the introduction of the AIS/FDI. However, any = possible=20 benefit that might arise is completely masked by the fact that the AIS = itself=20 must be configured and there is no reason for this to be more reliable = than=20 what it is supposed to be monitoring. Indeed, there seems good reason = to think=20 that it will be less reliable. [mv] You are = turning=20 things upside down... CC is present to detect continuity and = connectivity=20 problems introduced in the layer network's Connection functions. As = such you=20 can not diagnose the second state with CC alone. With CC alone one of = your=20 colleagues will be requested to initiate a number of Loopback tests to = find=20 out which connection function is misconfigured. This is the wrong = action of=20 course, as there is a server layer=20 fault. [mv] You do = not understand=20 the AIS "configuration" aspect. AIS generation configuration is on the = node,=20 not on each individual connection. Networks that deploy AIS have it = active on=20 all their NNIs. There is no avoiding that AIS in circuit = switching is=20 fundamentally different from AIS in packet = switching. - in circuit switching, you must fill = the bit=20 stream with something and the information injected requires no = configuration=20 whatsoever. - in packet switching, no packets is a perfectly valid = condition=20 and the injection of AIS requires individual client connection = specific=20 information to be configured. [mv] In = packet transport=20 networks with connectivity checking no packets is not a valid = condition.=20 [mv]=20 AIS/FDI insertion specified in e.g. T-MPLS OAM does not = require any=20 individual client connection specific information.=20 [mv] ATM VP = AIS and ATM VC=20 AIS does not require any individual client (i.e. VP, VC) connection = specific=20 information. [mv] ETH AIS = does not=20 require any individual client connection identification specification, = but it=20 requires reuse of the client MEG Level information which is also = required for=20 the ETH MIP functions on the interface=20 port. [mv] I.e. = AIS insertion=20 does not require individual client connection specific information. = Either no=20 additional information at all is required, or additional information = is=20 required that is shared with other fucntions/processes in the=20 interface. The objective is not to replicate the data plane primitives = of=20 SONET/SDH, but the triggers to the operational systems so that the = operational=20 systems and processes are the same. [mv] And = that is exactly=20 what we do with support of AIS in packet transport networks (ATM, = Ethernet,=20 T-MPLS =3D> = MPLS-TP). The simple CC replicates all the triggers to management = systems made by=20 SONET/SDH and gives maximum compatibility. Conversely, the inclusion = of data=20 plane AIS requires a whole new area of configuration and generates a = whole new=20 set of fault conditions which cannot be localised by SONET/SDH = processes. So,=20 ironically, packet AIS is directly opposed to backwards compatibility = you=20 claim is the main drive. [mv] I hope = that you now=20 understand that it is the opposite case is that is = present. Simple=20 CC does **not** replicates all triggers... AIS is needed in=20 addition. Regards, Maarten Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 24 April 2009=20 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI does give additional information. = Let me=20 explain: The need for AIS/FDI is a consequence of = the deployment=20 of loss of continuity checking OAM (e.g. CCM in ethernet, CC in = ATM). The=20 objective of such CCM OAM is to be able to detect a misconfiguration = or=20 fault of a connection function (fabric) in the connection, which = interrupts=20 the forwarding of traffic in the connection. This is a fault = condition that=20 can only be discovered by the layer network in which the connection = is=20 supported. It requires that the organization responsible for the = layer=20 network takes action (i.e. locate the layer's connection = function that=20 includes the fault) to restore the = connection. Unfortunately, an interruption of one = of=20 the link connections of such connection (due to a fault in a = server=20 layer) will also interrupt the forwarding of traffic in the=20 connection. As such, loss of CC messages (LOC defect) = does not=20 provide sufficient information to determine if the configuration in = the=20 layer's connection functions along the connection have to be checked = and=20 corrected. AIS has been introduced and is used to help = differentiate between the two fault cases. 1) if LOC and AIS are detected, then there = is a server=20 layer fault. This server layer fault is already reported by the = server layer=20 MEP detecting this fault. No action is required, so no alarm to=20 generate. 2) if LOC is detected and there is no AIS, = then there=20 is a layer network fault (i.e. continuity fault). Fault localization = must be=20 started to locate the misconfigured or failed connection function. = Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is = retored. The interruption of the forwarding of = traffic in the=20 connection in both fault cases is however registered as part of = performance=20 monitoring. This performance monitoring information is used to = verify the=20 performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points I = made. My=20 point is that AIS/FDI gives no information above what is already = known - it=20 is only adds complexity and fault liability. Neither of your points = change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000=20 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009 = 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily=20 available. I don't = believe that=20 this is a correct statement in a multi-operator transport network, = or in=20 transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring in admin domain A will be unknown in admin domain B. The = loss of=20 continuaity alarms that are activated in admin domain B due to the = fault=20 in admin domain A will appear as primary alarms, suggesting = connectivity=20 problems in admin domain B. > = The issue=20 arises because the two sides of maintenance want different things. = The=20 fault fixing > guys want to locate the fault and don't want = any other=20 information. The service=20 maintenance > guys want to know whether their customer = service is=20 working. This is addressed in SDH, OTN, Ethernet = and=20 T-MPLS recommendations by means of the additional SSF alarm. = The SSF=20 alarm is for the service guys telling them that the service was=20 interrupted due to a fault in a server layer. AIS suppresses the = LOC alarm=20 in those cases so that the maintenance guys don't get triggered = and start=20 looking for a fault that is outside their = area. Regards, Maarten From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two=20 things which are separate and for which AIS/FDI is no help. = Maintenance=20 operations are concerned with two separate = things. 1) Identifying faults in equipment, = line plant,=20 and other systems (eg misconfigurations) and fixing them = (equipment=20 maintenance). 2) Identifying the health of end to = end=20 connections, especially when they are directly supporting customer = services (service maintenance). The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily = available. If,=20 at an end equipment, I have a good server/section layer and a loss = of CC=20 at the client layer, I *know* the fault is elsewhere - I don't = need=20 AIS/FDI to tell me. (Indeed, if you think about, if the fault is = in the=20 end equipment, it is quite likely that the fault means it cannot = report=20 the traffic loss to the management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the = fault and=20 don't want any other information. The service maintenance guys = want to=20 know whether their customer service is = working. This arose in the early days of = SONET/SDH, when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know=20 about the alarms. The normal practice is for the equipment = to report=20 the alarms *including* AIS and then a filter is applied in the = management=20 system to suppress alarms to the fault fixing guys. As I'm = aware,=20 there are many different techniques applied for the filtering = algorithms,=20 especially when you consider multiple concurrent faults in a = network,=20 however, the existance of AIS/FDI doesn't add anything to these = that's not=20 already known. In fact, I believe simple time-stamp = correlation is=20 one of the most powerful and widely used techniques. And if the = equipment=20 starts messing up the reporting of loss of CC because it waiting=20 for/persistence checking AIS/FDI, it could end up messing up = simple=20 time-stamp correlation! In practice, it is often not quite a = simple as this,=20 as the service guys like to be able to 'localise' the fault. = However,=20 under most circumstances, the filter has automatically done = this.=20 So localisation you describe is only when the filter = hasn't=20 worked for some reason. But the bottom line is, whatever = operations process=20 you want to use, AIS/FDI doesn't add anything other than = complexity=20 and fault liability to the equipment. Remember AIS goes back = to the=20 TDM world where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 = (0)1277=20 324015 Email: = andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000 = This=20 electronic message contains information from British = Telecommunications=20 plc which may be privileged or confidential. The information is = intended=20 to be for the use of the individual(s) or entity named above. If = you are=20 not the intended recipient be aware that any disclosure, copying,=20 distribution or use of the contents of this information is = prohibited. If=20 you have received this electronic message in error, please notify = us by=20 telephone or email (to the numbers or address above)=20 immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded to secure effective operation and for other lawful = business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil: = thank you for wasting more = time in=20 describling the problems. but I think some of what you said is = no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense=20 in cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI=20 functions, when there is a defects in a given layer network, it = can=20 cause multiple alarm events to be raised. it is diffcult = for=20 operators to locate and diagnose the faults. though I completely agree you = on=20 adding new things and functions will bring some complexity = . but=20 if we have no functions, it is more complex and difcult for = operators to=20 maintence and administrator the network. so I think every new = functions=20 and things may have positive and negative effects. but we should = consider it very much, don't delete some functions at = random.=20 best regards = liu <neil.2.harrison@bt.com> 2009-04-21 = 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If MPLS-TP is going to be taken seriously as a = transport network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are = these.=20 1 Provide a transparent = client/server=20 relationship...which means: - all client bits treated=20 equally -=20 client bit ordering preserved - = no attempt to=20 infer client symbol (ie sequence of client bits) meaning and no = attempt=20 to change client symbols - the traffic behaviour of = client X=20 must not impact the performance experienced by client Y = A key corollary of the above is that MPLS-TP must only = support=20 proper connections (ie single source constructs) = = 2 Since = MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does = not=20 support directly external message/file/stream applications).=20 MPLS-TP therefore does not require an E-NNI specification. = A=20 key corollary of this is that MPLS-TP will not have any peer=20 interworking relationship with any other network = mode/technology.=20 Now wrt OAM = MPLS-TP is a co-ps=20 mode network. You could argue this should have = FDI/AIS....however,=20 the merit of this is highly questionable. When I and = colleagues=20 discussed whether PBB-TE (also a co-ps mode network) should have = FDI/AIS=20 we concluded that on balance it was not a good idea.....and note = that=20 initially I was in favour of having AIS, but my colleagues = provided=20 strong technical arguments that convinced me otherwise. = AIS/FDI is historically linked to the early PDH co-cs = mode layer=20 networks that used TTL logic. When this died it put out a = +5V (all=20 1s) signal by default, ie it required no conscious effort to = generate=20 it.....this is key point. Further, in these networks there = is a=20 fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never=20 specified AIS for IP and its why IEEE had the good sense to = throw-out=20 AIS in 802.1ag for Ethernet (though ITU have unwisely IMO = retained it in=20 Y.1731....but I suspect any operator planning to use Ethernet = equipment=20 would always look to IEEE stds and not ITU ones). = AIS/FDI and the co-ps mode is debatable. As I = noted above,=20 on balance we considered not a good idea for PBB-TE OAM because = it=20 requires a conscious effort to generate it (unlike the co-cs = mode) so=20 there are likely to be scaling problems and its one more thing = to go=20 wrong. You should also = have seen me=20 make the point many times in the past that the always-on defect=20 detection/handling OAM needs to be as simple/sparse as possible = with as=20 little config as possible because we need super = reliability......TCM=20 goes completely against the grain here. Also note that the = OAM=20 required for each of the 3 network modes is not the same, = despite what=20 some claim. regards, = Neil From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Deborah: maybe what you said is right. but = I can't=20 completely agree your opinions. IMO. mpls-tp is regard as = transport=20 network like SDH/SONET. so it should have AIS/FDI fuctions as=20 SDH/SONET. do you think so. = best regards liu "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org = 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with = Neil, it is very=20 questionable the value of AIS/FDI in a packet network- any = mode. It=20 can result in a DoS attack by an operator on themselves so = even Y1731=20 recommends not to block data frames: "A MEP can decide = whether it=20 blocks data frames when it detects dAIS. The principle=20 requirement that influences this decision is that data frames = ought=20 to be forwarded as much as possible, without the = possibility of=20 forwarding wrong data frames downstream." Table I.7-2 shows = for AIS,=20 not to block. And as Y1731 states, AIS can only be used = under=20 very constrained architectures - if required for MPLS-TP, it = needs to=20 have the same guidance as in Y1731, i.e. point-to-point and=20 server/client one-to-one: "for a point-to-point ETH = connection, a MEP=20 has only a single peer MEP. Therefore, there is no = ambiguity=20 regarding the peer MEP for which it should suppress alarms = when it=20 receives the ETH-AIS information." So should only be = within one=20 domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the = cl=20 mode?...do me a favour! Ethernet AIS is indeed a = requirement and=20 a necessity. And you will not be able to understand that = as long=20 as you refuse to accept that "cl-mode" is a forwarding = mode within=20 a **transport entity**. G.800 amendment 1 = has finally reintroduced=20 this transport entity into G.800. Besides that, it = also introduced=20 the **differentiated connection**: [G.800 am1] "A = differentiated=20 connection is a transport entity that transfers information = belonging=20 to multiple communications between ports across a subnetwork. = <..> In a differentiated connection = message contents are=20 interpreted to identify (sets of) communications which=20 receive different treatment. The sets of = communications may=20 be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms of=20 G.800 "differentiated connections". Ethernet AIS provides = AIS=20 within the scope of such "differentiated = connection". If you apply=20 this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and core = domains=20 interconnecting EVC matrices. When one of those EVC links = is=20 interrupted, e.g. in the core between metro 1 and metro 4 = (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS = is=20 inserted in the downstream direction to suppress the EVC-LOC = alarms=20 at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet AIS)=20 frame has a reserved multicast address, which guarantees that = the AIS=20 is broadcast to the endpoints of the EVC. I believe that = it is=20 time for you to adapt your view on co and cl = modes and relate it=20 to the forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP = differentiated connection"=20 with a billion or more ports. What we know as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN is=20 essentially an "Ethernet differentiated connection" with n = ports=20 (n in the range of e.g. 2 to 1000). What we know as a p2p = MPLS E-LSP=20 is essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection" with=20 2 ports. Transport network OAM applies to transport = entities,=20 which are (in terms of G.800 am1) connections and = differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: = RE:=20 [mpls-tp] Associated bidirectional transport=20 path requirements John, Thanks this is a great = platform=20 to explain why OAM for the 3 network modes needs to be = different.=20 I am getting a wee bit tired of folks trying to make = all 3=20 network modes look alike (and then, even worse, = interwork them as=20 as peers...esp when not not top-of-stack networks...I mean = how silly=20 can we get?). I am even more frustrated by the fact = those=20 peddling this FUD only ever seem to consider OAM = and forget all=20 other DP/CP/MP components (esp top-of-stack=20 message/file/stream application adaptations). How wrong = can=20 this get! In the co modes a *connection* is a very = specific and=20 *constraining* construct.....I am assuming here we respect = the rules=20 of a connection (ie single source) though some folks don't = even=20 bother to respect this, and this is despite the fact that = we all=20 know what problems multiple-source constructs can cause (from = LDP/PHP....ergo MPLS-TP). When we have a connection this=20 restricts *all* DP (ie traffic and OAM) to stay within the = bounds=20 of the connection. Which is fine=20 under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is = broken.=20 In a nutshell what this means is that OAM that is of = a=20 request/response nature cannot be trusted in co mode networks = under=20 misconnectivity defects.....indeed, why should a = leaking DP have a=20 symmetric go/return defect behaviour?....very likely it=20 won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts to = explain=20 that physics....G.805 does not. So, the 3 modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the=20 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander = Vainshtein;=20 Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path >=20 requirements > > Italo, > > As = described in=20 the MPLS TP OAM Requirements I-D, virtually all of = the > OAM=20 functions require a return path, and in the absence of a return = >=20 path they are disabled. > > As described in David=20 Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the issue=20 of return path for unidirectional LSPs could be > = charaterized=20 as the elephant in the room. In the MPLS TP OAM > = Framework=20 I-D, unicast LSPs are only mentioned three times and return = >=20 paths not at all. > > Thanks, > > = John >=20 > -----Original Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April=20 17, 2009 1:59 AM > > To: Drake, John E; Alexander = Vainshtein;=20 Maarten Vissers > > Cc: mpls-tp@ietf.org > > = Subject:=20 RE: [mpls-tp] Associated bidirectional transport path > = >=20 requirements > > > > John, > > = > >=20 I might have missed the agreement of MPLS-TP being capable of = >=20 > sending replies to OAM requests sent on uni-directional=20 LSPs. > > > > This requirement does not = belong to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken = into=20 account (at worst in a > subsequent phase). > > = >=20 > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility = to work=20 w/o IP > > forwarding and the need for OAM to continue = to=20 monitor the data > > plane also in case of failures = affecting=20 the control or management > > plane). > > = >=20 > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = >=20 > > -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 > > Sent: Thursday, April 16, 2009 8:00 PM > > = > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc:=20 mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > = requirements >=20 > > > > > At the meeting last fall at Juniper = in=20 Massachusetts, I > > think it was > > > = agreed that=20 an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM = packets=20 (e.g., sending > > replies to OAM > > > = requests=20 sent on uni-directional LSPs) even if it does not > > = have an=20 IP > > > forwarding data plane. > > > = >=20 > > > -----Original Message----- > > > > = From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > = >=20 > > > Maarten, > > > > It seems that = you've just=20 (implicitly and, probably, > > > > inadvertently) = stated=20 the following: > > > > > > > > = =20 MPLS-TP = OAM will=20 not ever support MIP loopback function > > (and = fault >=20 > > > localization which requires this function ) = for >=20 > unidirectional P2MP > > > > and P2P = paths. >=20 > > > > > > > If this statement is = correct,=20 this (IMHO and FWIW) > raises a valid > > > = >=20 question: > > > > > > > > = =20 Is MPLS-TP an=20 appropriate solution for these > types of = transport > >=20 > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > = functionality=20 today > > > > for (unidirectional - but it does = not know=20 any other > > type) P2P LSPs > > > > as=20 described in RFC 4379. And its extension to P2MP LSPs seems = >=20 > > > easy... > > > > > > > = >=20 > > > > > > > > = Regards, >=20 > > > > > > > = Sasha >=20 > > > > > > > > > > > = >=20 > > > ________________________________________ > = >=20 > > From: mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On Behalf > > = > >=20 Of Maarten Vissers [maarten.vissers@huawei.com] > > = > >=20 Sent: Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional = transport path=20 > > > > requirements > > > > = >=20 > > > Adrian, > > > > > > > = >=20 >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > = > >=20 > other internal > > > > >> = =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of = that > >=20 > > >> transport path. > = >=20 > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > is, there is > > > > >=20 *nothing* that can be observed from a black box point of > = >=20 > view that > > > > > results from adhering = to this=20 requirement. > > > > > > > > Your = understanding is not correct. It is very much > observable = if > > > > this requirement is met from a black = box point=20 of view. > > > > The MIP functions can only = perform the=20 Loopback when there is a > > > > co-routed = bidirectional=20 transport path. The MPLS-TP LBM packet > > > > = received=20 at a MIP needs to be returned (as LBR > > > > = packet) to=20 the originating MEP function via the other > > = direction=20 of > > > > the co-routed bidirectional transport = path.=20 This other > direction > > > > would not be = available in an associated bidirectional transport > > = >=20 > path... and thus the loopback test > > > would=20 fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not in a > > > > associated = bidir=20 transport path. In the first case the TCM MEP > > > = >=20 Source and Sink functions are co-located and can > = exchange what=20 is > > > > called "remote information" which is = necessary=20 for performance > > > > monitoring. > > = >=20 > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, > >=20 > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = > Your=20 understanding is not correct. This text must not be > > = deleted=20 at > > > > all. > > > > > = > >=20 > > Actually, I am quite fed up about this = persistent > >=20 > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > >=20 is > > > > poorly > > > > > = specified=20 and comes from the monitoring of a path that is > > = > >=20 parallel (i.e. > > > > tandem) > > > = >=20 > to the data path being monitored. This definition of = TC >=20 > > > seems to be at > > > > = variance, >=20 > > > > and would be if the ACH was actually in=20 band. > > > > > > > > I don't = understand=20 where your interpretation of tandem > > connection = is >=20 > > > described in ITU-T recommendations. I.e. "from=20 the > > monitoring of a > > > > path = that is=20 parallel (i.e. tandem) to the data path being > > > = >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection is = a=20 set > > > > of interconnected "link connections" = and=20 "matrix > connections". A > > > > subset of = those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to as > = a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There=20 is only additional OAM inserted inside the data > path by=20 the > > > > TCM MEP_So function and this OAM is = extracted=20 from the > > data path by > > > > the = TCM MEP_Sk=20 function. > > > > > > > >=20 Regards, > > > > Maarten > > > > = >=20 > > > > > > > -----Original=20 Message----- > > > > From:=20 mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel >=20 > > > Sent: donderdag 16 april 2009 11:59 > > = >=20 > To: Alexander Vainshtein; = benjamin.niven-jenkins@bt.com >=20 > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = >=20 > > > requirements > > > > > > = >=20 > Hi Sasha, > > > > > > > > = >=20 Unfortunately I cannot fully agree with your statement: > = >=20 > > > > > > > > <quote> > = >=20 > > > From the point of view of hardware, = co-routed > > > bidirectional LSPs > > > = >=20 > are a special case of associated = bidirectional=20 LSPs. > > > > > <end quote> > > = >=20 > > > > > > > This statement would be = obviously=20 correct, were it not for > > > > = Requirement > >=20 > > > 34 in the latest MPLS-TP requirements = draft > >=20 > > > > > > OK. Got it. > > > = >=20 > > > > But what is this doing in the data plane = requirements section? > > > > > > > = > In=20 fact, what is this requirement actually saying? > > = > >=20 > > > > > <quote> > > > = > >=20 The intermediate nodes (including MEPs, MIPs = and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > = > >=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > > relationship of the = forward and=20 the backward > > > > directions of that > = > >=20 > > transport path. > > > = >=20 > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > = > is,=20 there is > > > > *nothing* that can be observed = from a=20 black box point of > > view that > > > > = results=20 from adhering to this requirement. > > > > = > >=20 > > Therefore it could be assumed that this requirement is = met by=20 > > > > configuring some data plane database = component=20 through the > > > > management plane. The = database=20 component is not used > for anything > > > = > except=20 to satisfy this requirement for "awareness". > > > = >=20 > > > > Ben! Can we please try to rewrite this=20 requirement in terms of > > > > = behavior? > >=20 > > > > > > > Please note that = Requirement 34=20 is the ONLY item in the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = >=20 > paths are > > > > > exactly the same even = if they=20 appear in two different > > > items in the > = > >=20 > > requirements' list). > > > > > In = other=20 words, without Requirement 34 the notion of > = co-routed >=20 > > > > bidirectional paths would be void of any = data plane=20 content. > > > > > > > > > > = The=20 somewhat vague scope of this requirement ("other internal = > >=20 > > > functions as appropriate") creates a suspicion = that=20 HW > > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with = it. >=20 > > > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > MIPs and other > > = >=20 > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate=20 nodes." > > > > > > > > > The=20 following text in the draft increases this suspicion: > = > >=20 > > > > > > > <quote> > > = >=20 > > Tandem Connection: A tandem connection is = an >=20 > arbitrary part of a > > > > > = transport=20 path that can be monitored (via OAM) > > > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of a=20 transport path. > > The tandem > > > = >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > > > > = > =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = >=20 > Actually, I am quite fed up about this persistent > = >=20 insistence on the > > > > inclusion of "Tandem=20 Connection." The definition within > > the ITU-T = of >=20 > > > this term is poorly specified and comes from = the >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > = >=20 > > > > > > Doesn't "forwarding engine" = sound like=20 hardware to you? > > > > > > > > = Yes, but=20 so what? > > > > > > > > > = IMHO it is=20 worth noting that neither the MPLS-TP > > > = Requirements=20 draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > > > > > > > > = >=20 > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed in=20 the MPLS-TP OAM > > Framework > > > > = >=20 draft > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > = >=20 > > > > > > Right. > > > > = Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some clarity=20 regarding > > > co-routed vs. > > > > = >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 to=20 specific > > > functionality. > > > > = > > > > Agreed. > > > > > = >=20 > > Adrian > > > > > > > > = >=20 > > > > > > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: = Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc:=20 mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > Not really = sure=20 whether you are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one of Ben's = messages is that associated > > > > >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will = have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > = > This=20 is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > = >=20 > > a special case of associated bidirectional = LSPs. > >=20 > > > > > > If you can set up two = unidirectional=20 LSPs (e.g. using the > > management > > > = >=20 plane) you can surely set up a co-routed > > > = bidirectional=20 LSP. > > > > > > > > There are = shipping=20 solutions that achieve co-routed > bidirectional > = > >=20 > LSPs using the control plane. These either use the = GMPLS >=20 > (which is > > > > cleaner) or non-standard=20 proprietary solutions (which is > > messy but > = > >=20 > functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are = software > >=20 > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the = actual > >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > = >=20 transport networks rather than any specific benefit. > = > >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, >=20 > > > feel, and behavioral characteristics of a=20 "legacy" > > > > transport network. > > = >=20 > > > > > > Based on these observations, = I'd guess=20 (FWIW) that: > > > > > * associated = bidirectional=20 paths are, at least for the time > > > > > = =20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = >=20 > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other = upgrades to=20 existing MPLS solutions will be > needed to reach > = >=20 > > the full function level of MPLS-TP. > > > = >=20 > > > > > * they had a good chance to remain = the only=20 type of > > bidirectional > > > > > = =20 paths in real deployments. > > > > > = >=20 > > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > mpls-tp@ietf.org > = >=20 > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy=20 and are not permitted to disclose the contents of this = communication to=20 others. This email and any files transmitted with it are = confidential=20 and intended solely for the use of the individual or entity to = whom they=20 are addressed. If you have received this email in error please = notify=20 the originator of the message. Any views expressed in this = message are=20 those of the individual sender. This message has been scanned = for=20 viruses and Spam by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. --Boundary_(ID_+k9y/YE2jJaJFuX9dfYIng)-- From maarten.vissers@huawei.com Mon Apr 27 06:56:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B112328C136 for ; Mon, 27 Apr 2009 06:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.722 X-Spam-Level: *** X-Spam-Status: No, score=3.722 tagged_above=-999 required=5 tests=[AWL=-1.730, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llt986l1Blex for ; Mon, 27 Apr 2009 06:56:38 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F02443A68AD for ; Mon, 27 Apr 2009 06:56:36 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR00JX8ISJXU@szxga02-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 21:57:55 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIR00FGQISJLZ@szxga02-in.huawei.com> for mpls-tp@ietf.org; Mon, 27 Apr 2009 21:57:55 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIR00G3KIRZ8C@szxml01-in.huawei.com>; Mon, 27 Apr 2009 21:57:54 +0800 (CST) Date: Mon, 27 Apr 2009 15:57:38 +0200 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C0479D833@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com Message-id: <006001c9c740$228ab5c0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_D3hInxg1pbA14NB8s9C7nQ)" Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAAvBCIAAD3pug Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:56:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_D3hInxg1pbA14NB8s9C7nQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Neil, =20 _____ =20 From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: maandag 27 april 2009 13:46 To: andy.bd.reid@bt.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements What a good analysis Andy. This on its own should be compelling enough = to make it clear that we can't simply take FDI/AIS from its PDH/SDH co-cs = TDM origins and blindly apply it to packet-switched networks. But for = anyone still not convinced here are some further reasons why AIS (and TCM) make = no sense.=20 =20 [mv] As indicated in my response to Andy, his understanding of the AIS specifications in our equipment and protection switching recommendations = is not correct. It seems that also your understanding of those = specifications is also not correct. =20 If one wants to inject an AIS signal into a client from a server one = *must* have a permanent binding of s erver_path<=3D>client_link_connection. = [mv] I agree that there must be a binding at the time that AIS is generated and inserted. If you don't have this then there is no one to send the AIS to! So, in = any cases where the client layer network can dynamically change its routing = (ie to select different servers for each of its link connections) then it is = a pointless exercise attempting to send AIS to the client...as the client = has 'moved somewhere else'. [mv] Any client layer network can change its routing; e.g. as part of restoration. Until such restoration action is performed it is necessary to generate and insert AIS. Part of such restoration action is the withdrawal of the binding. At that moment also = the generation of AIS stops. NOTE: in Ethernet networks in which xSTP is deployed you will find that all n-port connections (VLANs) are restored = and that this restoration process starts immediately after detection of = signal fail condition. That is the reason why ETH AIS generation **within** = such xSTP domain is not performed.=20 =20 Cl-ps networks like IP are obviously like this, and in the limit the client<=3D>server binding can change for each packet of the IP client, = ie new IGP route. The co-cs PSTN is also like this because it is based on = SVCs. And here if one gets a server layer failure the client calls get cleared down and re-established via other servers than the one that has failed. = So who is the broken server going to send AIS to now? [mv] PSTN: I agree. = IP: For IP we have to look at IP VPNs. Those IP VPNs have fixed bindings = between server and IP VPN. If a interruption of an IP VPN link connection is not immediately restored, then an IP-AIS may be required when an IP-CCM = would be active.=20 =20 Moving on to consider TCM, what this is doing is creating an artificial client/server sublayer hierarchy. And as noted above, for a lower TCM = level to meaningfully inject AIS towards a higher TCM level the TCM = client/server bindings must be permanent. [mv] I agree that there must be a binding = at the time that AIS is generated and inserted. But this is rather silly because it is *not* the the relationship = between TCM levels that it key but the *real traffic relationships between the client and the server*.....in other words we *must* be able to re-route = real client traffic around server layer failures (and this includes dynamic restoration, not simply pre-configured protection paths). [mv] Any = client layer network can change its routing; e.g. as part of restoration. When this occurs the TCM end point has to be relocated as well.=20 =20 [mv] NOTE: TCM endpoints are typically at UNI-N ports and at "E-NNI" = ports ("UNI-N": port with one end connected to customer node and other end connected to operator node, "E-NNI": NNI with one end connected to = operator A node and other endpoint connected to operator B node). UNI-N ports do = not change; the customer stays connected to those ports. E-NNI ports do not change; operators A and B stay connected via those ports. If however = more then one E-NNI port is present between networks of two operators, then = it is possible to reroute the client connection via another E-NNI. Often there = is only a single E-NNI agreed for a connection. =20 Note that the only way one could keep the existing TCM hierarchy valid across failures relative to the client traffic routing would be to = create pinch-points at the TCM levels and force the client traffic to always = use these. But now of course one would be reducing the availability = potential of the network...so this is not a smart idea at all. [mv] If one = deploys protection swithcing then the protection edges are indeed carefully = selected pinch-points.... That's why SNC/S (sublayer (i.e. TCM) monitored SNC protection) works well. If one deploys multi-operator connections, then there is either one or a small number of gateway nodes via which such multi-operator connections are crossing admin domain boundaries; i.e. carefully selected pinch-points.... that is why admin domain monitoring using TCM works well. =20 The alternative would be to move the TCM levels in accordance to where = the real traffic had moved to to effect restoration. So the dynamic = act/deact configuration of TCM levels would have to be defined to track real = traffic movements (and it never has been defined). Note also that in changing = the location of the nested TCM levels we have removed their requirement for = a permanent client/server binding and so the sending of AIS from lower to higher TCM levels would be pointless....as they too have moved away from = the server layer failure just like we need the real traffic to do so (if not clear what I mean here refer back to the PSTN example above...its the = same issue). [mv] When you change the route of a connection through the = network, then you will remove matrix connections in one set of nodes and create = new matrix connections at other nodes. As part of such connection = modification process you need to take care of any other configuration needs = associated with the connection; this may include OAM related configuration at mid points or protection related configuration. =20 [mv] If you have a network that has 100% of its connections restored = (e.g. PSTN, xSTP domain), there is no reason to generate AIS inside the = network. There is however still a need to generate AIS at the egress ports of the network, when restoration of the UNI-N to UNI-N connection was not = possible. In a client/server relationship between customer and network, this AIS insertion can be controlled by the Network Connection (NC) MEP_Sk = function at the UNI-N port. For the case of a peer-interconnection between = customer and nework, this AIS insertion can be controlled by a Tandem Connection = (TC) MEP_Sk function at the UNI-N port. =20 [mv] I do not expect that in packet transport networks we will have 100% = of the connections restored. As such AIS is a necessity.=20 =20 [mv] The design of AIS in our equipment specifications is such that AIS insertion stops as soon as the Connection/Flow Point is removed (i.e. = when matrix connection/matrix forwarding process is deleted) from the = connection function by the restoration process.=20 =20 Regards, Maarten =20 So in addition to Andy's observations of why it is not sensible simply = to replicate PDH/SDH AIS behaviour in packet-switched networks we can also = see from the above arguments that trying to send AIS between an artificial = set of nested TCM levels is also pointless....and this applies to any = network mode where the client traffic can move its routing and thus does not = have a permanent client<=3D>server binding relationship. =20 =20 regards, Neil _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: 27 April 2009 11:50 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 It is of course true that adding a boolean input to a logical system increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you identify below. There are=20 =20 - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these input states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly. =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below). =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending on = the exact scope of the forwarding labels, a protection switch may well = require the proactive purging of entries from the AIS forwarding label injection table following the protection switch (this could equivalently been seen = as the forwarding function proactively dropping the AIS packets). =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a forwarding function. But it could equally arise from a misconfiguration of the AIS forwarding label injection table. In fact, the latter actually seems = just as likely and particularly problematic for maintenance. Unlike normal forwarding, any mismatch between the forwarding configuration and the = AIS forwarding label injection table will lie dormant and until a server = fault arises. Then this generates a false and misunderstood fault condition = with maintenance looking for the fault in the wrong place. =20 The first two states can be reliably diagnosed with CC alone. The second = two arise from the introduction of the AIS/FDI. However, any possible = benefit that might arise is completely masked by the fact that the AIS itself = must be configured and there is no reason for this to be more reliable than = what it is supposed to be monitoring. Indeed, there seems good reason to = think that it will be less reliable. =20 There is no avoiding that AIS in circuit switching is fundamentally different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something and = the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the operational = systems and processes are the same. =20 The simple CC replicates all the triggers to management systems made by SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data plane AIS requires a whole new area of configuration and generates a = whole new set of fault conditions which cannot be localised by SONET/SDH processes. So, ironically, packet AIS is directly opposed to backwards compatibility you claim is the main drive. =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to = locate the misconfigured or failed connection function. Once this faulty = connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the performance = against the SLA for the connection. =20 Regards, Maarten _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin = domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server layer. = AIS suppresses the LOC alarm in those cases so that the maintenance guys = don't get triggered and start looking for a fault that is outside their area. =20 Regards, Maarten =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are concerned = with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* = the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you = think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even when AIS = was being received as the service guys want to know about the alarms. The = normal practice is for the equipment to report the alarms *including* AIS and = then a filter is applied in the management system to suppress alarms to the = fault fixing guys. As I'm aware, there are many different techniques applied = for the filtering algorithms, especially when you consider multiple = concurrent faults in a network, however, the existance of AIS/FDI doesn't add = anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And = if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up = simple time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation you describe is = only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to = fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, maybe = AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there = is no AIS/FDI functions, when there is a defects in a given layer network, = it can cause multiple alarm events to be raised. it is diffcult for = operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so I = think every new functions and things may have positive and negative effects. = but we should consider it very much, don't delete some functions at random.=20 best regards=20 liu=20 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Boundary_(ID_D3hInxg1pbA14NB8s9C7nQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Neil, From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: maandag 27 april 2009=20 13:46 To: andy.bd.reid@bt.com;=20 maarten.vissers@huawei.com Cc: = mpls-tp@ietf.org Subject: RE:=20 [mpls-tp] Associated bidirectional transport path=20 requirements What a good = analysis Andy. =20 This on its own should be compelling enough to make it clear that we = can't=20 simply take FDI/AIS from its PDH/SDH co-cs TDM origins and blindly = apply it=20 to packet-switched networks. But for anyone still not convinced = here are=20 some further reasons why AIS (and TCM) make no sense. [mv] As = indicated in my=20 response to Andy, his understanding of the AIS specifications = in our=20 equipment and protection switching recommendations is not correct. It = seems that=20 also your understanding of those specifications is also not=20 correct. If one wants to = inject an AIS=20 signal into a client from a server one *must* have a permanent = binding=20 of  s erver_path<=3D>client_li= nk_connection.   [mv] = I agree that=20 there must be a binding at the time that AIS is generated and=20 inserted. If you don't have this then = there is no=20 one to send the AIS to! So, in any cases where the client layer = network=20 can dynamically change its routing (ie to select different servers for = each of=20 its link connections) then it is a pointless exercise attempting to send = AIS to=20 the client...as the client has 'moved somewhere else'. = [mv] Any client=20 layer network can change its routing; e.g. as part of restoration. Until = such=20 restoration action is performed it is necessary to generate and insert = AIS. Part=20 of such restoration action is the withdrawal of the binding. At that = moment also=20 the generation of AIS stops. NOTE: in Ethernet networks in which = xSTP is=20 deployed you will find that all n-port connections (VLANs) are = restored and=20 that this restoration process starts immediately after detection of = signal fail=20 condition. That is the reason why ETH AIS generation **within** such = xSTP domain=20 is not performed. Cl-ps networks = like IP are=20 obviously like this, and in the limit the client<=3D>server = binding can=20 change for each packet of the IP client, ie new IGP route. The = co-cs PSTN=20 is also like this because it is based on SVCs. And here if one = gets a=20 server layer failure the client calls get cleared down and = re-established via=20 other servers than the one that has failed. So who is the broken = server=20 going to send AIS to now? [mv] PSTN: I agree. IP: For IP we have to = look at IP=20 VPNs. Those IP VPNs have fixed bindings between server and IP VPN. If a=20 interruption of an IP VPN link connection is not immediately restored, = then an=20 IP-AIS may be required when an IP-CCM would be=20 active. Moving on to consider = TCM, what this=20 is doing is creating an artificial client/server sublayer = hierarchy. And=20 as noted above, for a lower TCM level to meaningfully inject AIS towards = a=20 higher TCM level the TCM client/server bindings must be = permanent.  [mv] I agree=20 that there must be a binding at the time that AIS is generated and=20 inserted. But this is rather = silly because=20 it is *not* the the relationship between TCM levels that it key but the = *real=20 traffic relationships between the client and the server*.....in other = words we=20 *must* be able to re-route real client traffic around server layer = failures (and=20 this includes dynamic restoration, not simply pre-configured protection=20 paths). [mv] Any client = layer network=20 can change its routing; e.g. as part of restoration.  When this occurs the TCM end point has = to be=20 relocated as well. &nbs= p; [mv] NOTE: TCM = endpoints are=20 typically at UNI-N ports and at "E-NNI" ports ("UNI-N": port = with one=20 end connected to customer node and other end connected to operator node, = "E-NNI": NNI with one end connected to operator A node and other = endpoint=20 connected to operator B node). UNI-N ports do not change; the = customer=20 stays connected to those ports. E-NNI ports do not change; operators A = and B=20 stay connected via those ports. If however more then one E-NNI port is = present=20 between networks of two operators, then it is possible to reroute the = client=20 connection via another E-NNI. Often there is only a single E-NNI agreed = for a=20 connection. Note that the only = way one could=20 keep the existing TCM hierarchy valid across failures relative to the = client=20 traffic routing would be to create pinch-points at the TCM levels and = force the=20 client traffic to always use these. But now of course one would be = reducing the availability potential of the network...so this is not a = smart idea=20 at all. [mv]=20 If one deploys protection swithcing then the protection edges are indeed = carefully selected pinch-points.... That's why SNC/S (sublayer (i.e. = TCM)=20 monitored SNC protection) works well. If one deploys multi-operator = connections,=20 then there is either one or a small number of gateway nodes via which = such=20 multi-operator connections are crossing admin domain boundaries; i.e. = carefully=20 selected pinch-points.... that is why admin domain monitoring using TCM = works=20 well. The alternative = would be to move=20 the TCM levels in accordance to where the real traffic had moved to to = effect=20 restoration. So the dynamic act/deact configuration of TCM levels = would=20 have to be defined to track real traffic movements (and it never has = been=20 defined). Note also that in changing the location of the nested = TCM levels=20 we have removed their requirement for a permanent client/server binding = and so=20 the sending of AIS from lower to higher TCM levels would be = pointless....as=20 they too have moved away from the server layer failure just like we = need=20 the real traffic to do so (if not clear what I mean here refer back to = the PSTN=20 example above...its the same issue). [mv] When you change the route of a = connection=20 through the network, then you will remove matrix connections in one set = of nodes=20 and create new matrix connections at other nodes. As part of such = connection=20 modification process you need to take care of any other configuration = needs=20 associated with the connection; this may include OAM related = configuration at=20 mid points or protection related=20 configuration. [mv] If you have a network that has 100% of = its=20 connections restored (e.g. PSTN, xSTP domain), there is no reason to = generate=20 AIS inside the network. There is however still a need to generate AIS at = the=20 egress ports of the network, when restoration of the UNI-N to UNI-N = connection=20 was not possible. In a client/server relationship between customer and = network,=20 this AIS insertion can be controlled by the Network Connection (NC) = MEP_Sk=20 function at the UNI-N port. For the case of a peer-interconnection = between=20 customer and nework, this AIS insertion can be controlled by a Tandem = Connection=20 (TC) MEP_Sk function at the UNI-N = port. [mv] I do not expect that in packet transport = networks=20 we will have 100% of the connections restored. As such AIS is a = necessity.=20 [mv] The design of AIS in our equipment = specifications=20 is such that AIS insertion stops as soon as the Connection/Flow Point is = removed=20 (i.e. when matrix connection/matrix forwarding process is deleted) from = the=20 connection function by the restoration=20 process. Regards, Maarten So in addition to = Andy's=20 observations of why it is not sensible simply to replicate PDH/SDH AIS = behaviour=20 in packet-switched networks we can also see from the above arguments = that trying=20 to send AIS between an artificial set of nested TCM levels is also=20 pointless....and this applies to any network mode where the client = traffic can=20 move its routing and thus does not have a permanent = client<=3D>server=20 binding relationship.   regards, = Neil From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: 27 April 2009 = 11:50 To:=20 maarten.vissers@huawei.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Maarten, It is of course true that adding a boolean = input to a=20 logical system increases the number of possible input states. So = adding an AIS=20 boolean to CC boolean creates four possible states not = just the=20 three you identify below. There are - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no=20 AIS We must ask what practical = scenarios could generate=20 each of these input states. Good CC, no AIS One hopes this is because this is because the = service is=20 working properly. CC fault, AIS present One hopes this is because the service is = faulty and one=20 hopes this is because of a fault in a server layer. In fact, the = presence=20 of the AIS could be misleading (see below). Good=20 CC, AIS present This=20 situation could arise because of a misconfiguration of the AIS = forwarding=20 label injection table. And there are a number of scenarios which make = this=20 quite likely when protection switching occurs. Depending on the exact = scope of=20 the forwarding labels, a protection switch may well require the = proactive=20 purging of entries from the AIS forwarding label injection table = following the=20 protection switch (this could equivalently been seen as the forwarding = function proactively dropping the AIS packets). CC=20 fault, no AIS As=20 you suggest, this could arise from a misconfiguration of a forwarding=20 function. But it could equally arise from a misconfiguration of the = AIS=20 forwarding label injection table. In fact, the latter actually seems = just=20 as likely and particularly problematic for = maintenance. Unlike=20 normal forwarding, any mismatch between the forwarding configuration = and the=20 AIS forwarding label injection table will lie dormant and until a = server fault=20 arises. Then this generates a false and misunderstood fault condition = with=20 maintenance looking for the fault in the wrong = place. The=20 first two states can be reliably diagnosed with CC alone. The = second two=20 arise from the introduction of the AIS/FDI. However, any possible = benefit that=20 might arise is completely masked by the fact that the AIS itself must = be=20 configured and there is no reason for this to be more reliable than = what it is=20 supposed to be monitoring. Indeed, there seems good reason to think = that it=20 will be less reliable. There is no avoiding that AIS in circuit = switching is=20 fundamentally different from AIS in packet = switching. - in circuit switching, you must fill = the bit=20 stream with something and the information injected requires no = configuration=20 whatsoever. - in packet switching, no packets is = a=20 perfectly valid condition and the injection of AIS requires individual = client=20 connection specific information to be configured. The=20 objective is not to replicate the data plane primitives of SONET/SDH, = but the=20 triggers to the operational systems so that the operational systems = and=20 processes are the same. The=20 simple CC replicates all the triggers to management systems made by = SONET/SDH=20 and gives maximum compatibility. Conversely, the inclusion of data = plane AIS=20 requires a whole new area of configuration and generates a whole new = set of=20 fault conditions which cannot be localised by SONET/SDH processes. So, = ironically, packet AIS is directly opposed to backwards compatibility = you=20 claim is the main drive. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 24 April 2009=20 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI does give additional information. = Let me=20 explain: The need for AIS/FDI is a consequence of = the deployment=20 of loss of continuity checking OAM (e.g. CCM in ethernet, CC in = ATM). The=20 objective of such CCM OAM is to be able to detect a misconfiguration = or=20 fault of a connection function (fabric) in the connection, which = interrupts=20 the forwarding of traffic in the connection. This is a fault = condition that=20 can only be discovered by the layer network in which the connection = is=20 supported. It requires that the organization responsible for the = layer=20 network takes action (i.e. locate the layer's connection = function that=20 includes the fault) to restore the = connection. Unfortunately, an interruption of one = of=20 the link connections of such connection (due to a fault in a = server=20 layer) will also interrupt the forwarding of traffic in the=20 connection. As such, loss of CC messages (LOC defect) = does not=20 provide sufficient information to determine if the configuration in = the=20 layer's connection functions along the connection have to be checked = and=20 corrected. AIS has been introduced and is used to help = differentiate between the two fault cases. 1) if LOC and AIS are detected, then there = is a server=20 layer fault. This server layer fault is already reported by the = server layer=20 MEP detecting this fault. No action is required, so no alarm to=20 generate. 2) if LOC is detected and there is no AIS, = then there=20 is a layer network fault (i.e. continuity fault). Fault localization = must be=20 started to locate the misconfigured or failed connection function. = Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is = retored. The interruption of the forwarding of = traffic in the=20 connection in both fault cases is however registered as part of = performance=20 monitoring. This performance monitoring information is used to = verify the=20 performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points I = made. My=20 point is that AIS/FDI gives no information above what is already = known - it=20 is only adds complexity and fault liability. Neither of your points = change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000=20 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009 = 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily=20 available. I don't = believe that=20 this is a correct statement in a multi-operator transport network, = or in=20 transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring in admin domain A will be unknown in admin domain B. The = loss of=20 continuaity alarms that are activated in admin domain B due to the = fault=20 in admin domain A will appear as primary alarms, suggesting = connectivity=20 problems in admin domain B. > = The issue=20 arises because the two sides of maintenance want different things. = The=20 fault fixing > guys want to locate the fault and don't want = any other=20 information. The service=20 maintenance > guys want to know whether their customer = service is=20 working. This is addressed in SDH, OTN, Ethernet = and=20 T-MPLS recommendations by means of the additional SSF alarm. = The SSF=20 alarm is for the service guys telling them that the service was=20 interrupted due to a fault in a server layer. AIS suppresses the = LOC alarm=20 in those cases so that the maintenance guys don't get triggered = and start=20 looking for a fault that is outside their = area. Regards, Maarten From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two=20 things which are separate and for which AIS/FDI is no help. = Maintenance=20 operations are concerned with two separate = things. 1) Identifying faults in equipment, = line plant,=20 and other systems (eg misconfigurations) and fixing them = (equipment=20 maintenance). 2) Identifying the health of end to = end=20 connections, especially when they are directly supporting customer = services (service maintenance). The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily = available. If,=20 at an end equipment, I have a good server/section layer and a loss = of CC=20 at the client layer, I *know* the fault is elsewhere - I don't = need=20 AIS/FDI to tell me. (Indeed, if you think about, if the fault is = in the=20 end equipment, it is quite likely that the fault means it cannot = report=20 the traffic loss to the management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the = fault and=20 don't want any other information. The service maintenance guys = want to=20 know whether their customer service is = working. This arose in the early days of = SONET/SDH, when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know=20 about the alarms. The normal practice is for the equipment = to report=20 the alarms *including* AIS and then a filter is applied in the = management=20 system to suppress alarms to the fault fixing guys. As I'm = aware,=20 there are many different techniques applied for the filtering = algorithms,=20 especially when you consider multiple concurrent faults in a = network,=20 however, the existance of AIS/FDI doesn't add anything to these = that's not=20 already known. In fact, I believe simple time-stamp = correlation is=20 one of the most powerful and widely used techniques. And if the = equipment=20 starts messing up the reporting of loss of CC because it waiting=20 for/persistence checking AIS/FDI, it could end up messing up = simple=20 time-stamp correlation! In practice, it is often not quite a = simple as this,=20 as the service guys like to be able to 'localise' the fault. = However,=20 under most circumstances, the filter has automatically done = this.=20 So localisation you describe is only when the filter = hasn't=20 worked for some reason. But the bottom line is, whatever = operations process=20 you want to use, AIS/FDI doesn't add anything other than = complexity=20 and fault liability to the equipment. Remember AIS goes back = to the=20 TDM world where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 = (0)1277=20 324015 Email: = andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000 = This=20 electronic message contains information from British = Telecommunications=20 plc which may be privileged or confidential. The information is = intended=20 to be for the use of the individual(s) or entity named above. If = you are=20 not the intended recipient be aware that any disclosure, copying,=20 distribution or use of the contents of this information is = prohibited. If=20 you have received this electronic message in error, please notify = us by=20 telephone or email (to the numbers or address above)=20 immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded to secure effective operation and for other lawful = business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil: = thank you for wasting more = time in=20 describling the problems. but I think some of what you said is = no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense=20 in cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI=20 functions, when there is a defects in a given layer network, it = can=20 cause multiple alarm events to be raised. it is diffcult = for=20 operators to locate and diagnose the faults. though I completely agree you = on=20 adding new things and functions will bring some complexity = . but=20 if we have no functions, it is more complex and difcult for = operators to=20 maintence and administrator the network. so I think every new = functions=20 and things may have positive and negative effects. but we should = consider it very much, don't delete some functions at = random.=20 best regards = liu <neil.2.harrison@bt.com> 2009-04-21 = 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If MPLS-TP is going to be taken seriously as a = transport network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are = these.=20 1 Provide a transparent = client/server=20 relationship...which means: - all client bits treated=20 equally -=20 client bit ordering preserved - = no attempt to=20 infer client symbol (ie sequence of client bits) meaning and no = attempt=20 to change client symbols - the traffic behaviour of = client X=20 must not impact the performance experienced by client Y = A key corollary of the above is that MPLS-TP must only = support=20 proper connections (ie single source constructs) = = 2 Since = MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does = not=20 support directly external message/file/stream applications).=20 MPLS-TP therefore does not require an E-NNI specification. = A=20 key corollary of this is that MPLS-TP will not have any peer=20 interworking relationship with any other network = mode/technology.=20 Now wrt OAM = MPLS-TP is a co-ps=20 mode network. You could argue this should have = FDI/AIS....however,=20 the merit of this is highly questionable. When I and = colleagues=20 discussed whether PBB-TE (also a co-ps mode network) should have = FDI/AIS=20 we concluded that on balance it was not a good idea.....and note = that=20 initially I was in favour of having AIS, but my colleagues = provided=20 strong technical arguments that convinced me otherwise. = AIS/FDI is historically linked to the early PDH co-cs = mode layer=20 networks that used TTL logic. When this died it put out a = +5V (all=20 1s) signal by default, ie it required no conscious effort to = generate=20 it.....this is key point. Further, in these networks there = is a=20 fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never=20 specified AIS for IP and its why IEEE had the good sense to = throw-out=20 AIS in 802.1ag for Ethernet (though ITU have unwisely IMO = retained it in=20 Y.1731....but I suspect any operator planning to use Ethernet = equipment=20 would always look to IEEE stds and not ITU ones). = AIS/FDI and the co-ps mode is debatable. As I = noted above,=20 on balance we considered not a good idea for PBB-TE OAM because = it=20 requires a conscious effort to generate it (unlike the co-cs = mode) so=20 there are likely to be scaling problems and its one more thing = to go=20 wrong. You should also = have seen me=20 make the point many times in the past that the always-on defect=20 detection/handling OAM needs to be as simple/sparse as possible = with as=20 little config as possible because we need super = reliability......TCM=20 goes completely against the grain here. Also note that the = OAM=20 required for each of the 3 network modes is not the same, = despite what=20 some claim. regards, = Neil From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Deborah: maybe what you said is right. but = I can't=20 completely agree your opinions. IMO. mpls-tp is regard as = transport=20 network like SDH/SONET. so it should have AIS/FDI fuctions as=20 SDH/SONET. do you think so. = best regards liu "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org = 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with = Neil, it is very=20 questionable the value of AIS/FDI in a packet network- any = mode. It=20 can result in a DoS attack by an operator on themselves so = even Y1731=20 recommends not to block data frames: "A MEP can decide = whether it=20 blocks data frames when it detects dAIS. The principle=20 requirement that influences this decision is that data frames = ought=20 to be forwarded as much as possible, without the = possibility of=20 forwarding wrong data frames downstream." Table I.7-2 shows = for AIS,=20 not to block. And as Y1731 states, AIS can only be used = under=20 very constrained architectures - if required for MPLS-TP, it = needs to=20 have the same guidance as in Y1731, i.e. point-to-point and=20 server/client one-to-one: "for a point-to-point ETH = connection, a MEP=20 has only a single peer MEP. Therefore, there is no = ambiguity=20 regarding the peer MEP for which it should suppress alarms = when it=20 receives the ETH-AIS information." So should only be = within one=20 domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the = cl=20 mode?...do me a favour! Ethernet AIS is indeed a = requirement and=20 a necessity. And you will not be able to understand that = as long=20 as you refuse to accept that "cl-mode" is a forwarding = mode within=20 a **transport entity**. G.800 amendment 1 = has finally reintroduced=20 this transport entity into G.800. Besides that, it = also introduced=20 the **differentiated connection**: [G.800 am1] "A = differentiated=20 connection is a transport entity that transfers information = belonging=20 to multiple communications between ports across a subnetwork. = <..> In a differentiated connection = message contents are=20 interpreted to identify (sets of) communications which=20 receive different treatment. The sets of = communications may=20 be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms of=20 G.800 "differentiated connections". Ethernet AIS provides = AIS=20 within the scope of such "differentiated = connection". If you apply=20 this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and core = domains=20 interconnecting EVC matrices. When one of those EVC links = is=20 interrupted, e.g. in the core between metro 1 and metro 4 = (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS = is=20 inserted in the downstream direction to suppress the EVC-LOC = alarms=20 at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet AIS)=20 frame has a reserved multicast address, which guarantees that = the AIS=20 is broadcast to the endpoints of the EVC. I believe that = it is=20 time for you to adapt your view on co and cl = modes and relate it=20 to the forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP = differentiated connection"=20 with a billion or more ports. What we know as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN is=20 essentially an "Ethernet differentiated connection" with n = ports=20 (n in the range of e.g. 2 to 1000). What we know as a p2p = MPLS E-LSP=20 is essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection" with=20 2 ports. Transport network OAM applies to transport = entities,=20 which are (in terms of G.800 am1) connections and = differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: = RE:=20 [mpls-tp] Associated bidirectional transport=20 path requirements John, Thanks this is a great = platform=20 to explain why OAM for the 3 network modes needs to be = different.=20 I am getting a wee bit tired of folks trying to make = all 3=20 network modes look alike (and then, even worse, = interwork them as=20 as peers...esp when not not top-of-stack networks...I mean = how silly=20 can we get?). I am even more frustrated by the fact = those=20 peddling this FUD only ever seem to consider OAM = and forget all=20 other DP/CP/MP components (esp top-of-stack=20 message/file/stream application adaptations). How wrong = can=20 this get! In the co modes a *connection* is a very = specific and=20 *constraining* construct.....I am assuming here we respect = the rules=20 of a connection (ie single source) though some folks don't = even=20 bother to respect this, and this is despite the fact that = we all=20 know what problems multiple-source constructs can cause (from = LDP/PHP....ergo MPLS-TP). When we have a connection this=20 restricts *all* DP (ie traffic and OAM) to stay within the = bounds=20 of the connection. Which is fine=20 under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is = broken.=20 In a nutshell what this means is that OAM that is of = a=20 request/response nature cannot be trusted in co mode networks = under=20 misconnectivity defects.....indeed, why should a = leaking DP have a=20 symmetric go/return defect behaviour?....very likely it=20 won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts to = explain=20 that physics....G.805 does not. So, the 3 modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the=20 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander = Vainshtein;=20 Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path >=20 requirements > > Italo, > > As = described in=20 the MPLS TP OAM Requirements I-D, virtually all of = the > OAM=20 functions require a return path, and in the absence of a return = >=20 path they are disabled. > > As described in David=20 Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the issue=20 of return path for unidirectional LSPs could be > = charaterized=20 as the elephant in the room. In the MPLS TP OAM > = Framework=20 I-D, unicast LSPs are only mentioned three times and return = >=20 paths not at all. > > Thanks, > > = John >=20 > -----Original Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April=20 17, 2009 1:59 AM > > To: Drake, John E; Alexander = Vainshtein;=20 Maarten Vissers > > Cc: mpls-tp@ietf.org > > = Subject:=20 RE: [mpls-tp] Associated bidirectional transport path > = >=20 requirements > > > > John, > > = > >=20 I might have missed the agreement of MPLS-TP being capable of = >=20 > sending replies to OAM requests sent on uni-directional=20 LSPs. > > > > This requirement does not = belong to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken = into=20 account (at worst in a > subsequent phase). > > = >=20 > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility = to work=20 w/o IP > > forwarding and the need for OAM to continue = to=20 monitor the data > > plane also in case of failures = affecting=20 the control or management > > plane). > > = >=20 > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = >=20 > > -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 > > Sent: Thursday, April 16, 2009 8:00 PM > > = > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc:=20 mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > = requirements >=20 > > > > > At the meeting last fall at Juniper = in=20 Massachusetts, I > > think it was > > > = agreed that=20 an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM = packets=20 (e.g., sending > > replies to OAM > > > = requests=20 sent on uni-directional LSPs) even if it does not > > = have an=20 IP > > > forwarding data plane. > > > = >=20 > > > -----Original Message----- > > > > = From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > = >=20 > > > Maarten, > > > > It seems that = you've just=20 (implicitly and, probably, > > > > inadvertently) = stated=20 the following: > > > > > > > > = =20 MPLS-TP = OAM will=20 not ever support MIP loopback function > > (and = fault >=20 > > > localization which requires this function ) = for >=20 > unidirectional P2MP > > > > and P2P = paths. >=20 > > > > > > > If this statement is = correct,=20 this (IMHO and FWIW) > raises a valid > > > = >=20 question: > > > > > > > > = =20 Is MPLS-TP an=20 appropriate solution for these > types of = transport > >=20 > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > = functionality=20 today > > > > for (unidirectional - but it does = not know=20 any other > > type) P2P LSPs > > > > as=20 described in RFC 4379. And its extension to P2MP LSPs seems = >=20 > > > easy... > > > > > > > = >=20 > > > > > > > > = Regards, >=20 > > > > > > > = Sasha >=20 > > > > > > > > > > > = >=20 > > > ________________________________________ > = >=20 > > From: mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On Behalf > > = > >=20 Of Maarten Vissers [maarten.vissers@huawei.com] > > = > >=20 Sent: Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional = transport path=20 > > > > requirements > > > > = >=20 > > > Adrian, > > > > > > > = >=20 >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > = > >=20 > other internal > > > > >> = =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of = that > >=20 > > >> transport path. > = >=20 > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > is, there is > > > > >=20 *nothing* that can be observed from a black box point of > = >=20 > view that > > > > > results from adhering = to this=20 requirement. > > > > > > > > Your = understanding is not correct. It is very much > observable = if > > > > this requirement is met from a black = box point=20 of view. > > > > The MIP functions can only = perform the=20 Loopback when there is a > > > > co-routed = bidirectional=20 transport path. The MPLS-TP LBM packet > > > > = received=20 at a MIP needs to be returned (as LBR > > > > = packet) to=20 the originating MEP function via the other > > = direction=20 of > > > > the co-routed bidirectional transport = path.=20 This other > direction > > > > would not be = available in an associated bidirectional transport > > = >=20 > path... and thus the loopback test > > > would=20 fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not in a > > > > associated = bidir=20 transport path. In the first case the TCM MEP > > > = >=20 Source and Sink functions are co-located and can > = exchange what=20 is > > > > called "remote information" which is = necessary=20 for performance > > > > monitoring. > > = >=20 > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, > >=20 > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = > Your=20 understanding is not correct. This text must not be > > = deleted=20 at > > > > all. > > > > > = > >=20 > > Actually, I am quite fed up about this = persistent > >=20 > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > >=20 is > > > > poorly > > > > > = specified=20 and comes from the monitoring of a path that is > > = > >=20 parallel (i.e. > > > > tandem) > > > = >=20 > to the data path being monitored. This definition of = TC >=20 > > > seems to be at > > > > = variance, >=20 > > > > and would be if the ACH was actually in=20 band. > > > > > > > > I don't = understand=20 where your interpretation of tandem > > connection = is >=20 > > > described in ITU-T recommendations. I.e. "from=20 the > > monitoring of a > > > > path = that is=20 parallel (i.e. tandem) to the data path being > > > = >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection is = a=20 set > > > > of interconnected "link connections" = and=20 "matrix > connections". A > > > > subset of = those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to as > = a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There=20 is only additional OAM inserted inside the data > path by=20 the > > > > TCM MEP_So function and this OAM is = extracted=20 from the > > data path by > > > > the = TCM MEP_Sk=20 function. > > > > > > > >=20 Regards, > > > > Maarten > > > > = >=20 > > > > > > > -----Original=20 Message----- > > > > From:=20 mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel >=20 > > > Sent: donderdag 16 april 2009 11:59 > > = >=20 > To: Alexander Vainshtein; = benjamin.niven-jenkins@bt.com >=20 > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = >=20 > > > requirements > > > > > > = >=20 > Hi Sasha, > > > > > > > > = >=20 Unfortunately I cannot fully agree with your statement: > = >=20 > > > > > > > > <quote> > = >=20 > > > From the point of view of hardware, = co-routed > > > bidirectional LSPs > > > = >=20 > are a special case of associated = bidirectional=20 LSPs. > > > > > <end quote> > > = >=20 > > > > > > > This statement would be = obviously=20 correct, were it not for > > > > = Requirement > >=20 > > > 34 in the latest MPLS-TP requirements = draft > >=20 > > > > > > OK. Got it. > > > = >=20 > > > > But what is this doing in the data plane = requirements section? > > > > > > > = > In=20 fact, what is this requirement actually saying? > > = > >=20 > > > > > <quote> > > > = > >=20 The intermediate nodes (including MEPs, MIPs = and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > = > >=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > > relationship of the = forward and=20 the backward > > > > directions of that > = > >=20 > > transport path. > > > = >=20 > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > = > is,=20 there is > > > > *nothing* that can be observed = from a=20 black box point of > > view that > > > > = results=20 from adhering to this requirement. > > > > = > >=20 > > Therefore it could be assumed that this requirement is = met by=20 > > > > configuring some data plane database = component=20 through the > > > > management plane. The = database=20 component is not used > for anything > > > = > except=20 to satisfy this requirement for "awareness". > > > = >=20 > > > > Ben! Can we please try to rewrite this=20 requirement in terms of > > > > = behavior? > >=20 > > > > > > > Please note that = Requirement 34=20 is the ONLY item in the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = >=20 > paths are > > > > > exactly the same even = if they=20 appear in two different > > > items in the > = > >=20 > > requirements' list). > > > > > In = other=20 words, without Requirement 34 the notion of > = co-routed >=20 > > > > bidirectional paths would be void of any = data plane=20 content. > > > > > > > > > > = The=20 somewhat vague scope of this requirement ("other internal = > >=20 > > > functions as appropriate") creates a suspicion = that=20 HW > > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with = it. >=20 > > > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > MIPs and other > > = >=20 > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate=20 nodes." > > > > > > > > > The=20 following text in the draft increases this suspicion: > = > >=20 > > > > > > > <quote> > > = >=20 > > Tandem Connection: A tandem connection is = an >=20 > arbitrary part of a > > > > > = transport=20 path that can be monitored (via OAM) > > > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of a=20 transport path. > > The tandem > > > = >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > > > > = > =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = >=20 > Actually, I am quite fed up about this persistent > = >=20 insistence on the > > > > inclusion of "Tandem=20 Connection." The definition within > > the ITU-T = of >=20 > > > this term is poorly specified and comes from = the >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > = >=20 > > > > > > Doesn't "forwarding engine" = sound like=20 hardware to you? > > > > > > > > = Yes, but=20 so what? > > > > > > > > > = IMHO it is=20 worth noting that neither the MPLS-TP > > > = Requirements=20 draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > > > > > > > > = >=20 > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed in=20 the MPLS-TP OAM > > Framework > > > > = >=20 draft > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > = >=20 > > > > > > Right. > > > > = Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some clarity=20 regarding > > > co-routed vs. > > > > = >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 to=20 specific > > > functionality. > > > > = > > > > Agreed. > > > > > = >=20 > > Adrian > > > > > > > > = >=20 > > > > > > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: = Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc:=20 mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > Not really = sure=20 whether you are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one of Ben's = messages is that associated > > > > >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will = have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > = > This=20 is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > = >=20 > > a special case of associated bidirectional = LSPs. > >=20 > > > > > > If you can set up two = unidirectional=20 LSPs (e.g. using the > > management > > > = >=20 plane) you can surely set up a co-routed > > > = bidirectional=20 LSP. > > > > > > > > There are = shipping=20 solutions that achieve co-routed > bidirectional > = > >=20 > LSPs using the control plane. These either use the = GMPLS >=20 > (which is > > > > cleaner) or non-standard=20 proprietary solutions (which is > > messy but > = > >=20 > functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are = software > >=20 > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the = actual > >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > = >=20 transport networks rather than any specific benefit. > = > >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, >=20 > > > feel, and behavioral characteristics of a=20 "legacy" > > > > transport network. > > = >=20 > > > > > > Based on these observations, = I'd guess=20 (FWIW) that: > > > > > * associated = bidirectional=20 paths are, at least for the time > > > > > = =20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = >=20 > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other = upgrades to=20 existing MPLS solutions will be > needed to reach > = >=20 > > the full function level of MPLS-TP. > > > = >=20 > > > > > * they had a good chance to remain = the only=20 type of > > bidirectional > > > > > = =20 paths in real deployments. > > > > > = >=20 > > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > mpls-tp@ietf.org > = >=20 > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy=20 and are not permitted to disclose the contents of this = communication to=20 others. This email and any files transmitted with it are = confidential=20 and intended solely for the use of the individual or entity to = whom they=20 are addressed. If you have received this email in error please = notify=20 the originator of the message. Any views expressed in this = message are=20 those of the individual sender. This message has been scanned = for=20 viruses and Spam by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. --Boundary_(ID_D3hInxg1pbA14NB8s9C7nQ)-- From benjamin.niven-jenkins@bt.com Mon Apr 27 07:19:19 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A213A68AF for ; Mon, 27 Apr 2009 07:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXhHwirb0-AS for ; Mon, 27 Apr 2009 07:19:18 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 74AE63A6827 for ; Mon, 27 Apr 2009 07:19:18 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 15:20:38 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Apr 2009 14:20:37 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 27 Apr 2009 15:20:36 +0100 From: Ben Niven-Jenkins To: Maarten Vissers , Message-ID: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gAAGnJO1 In-Reply-To: <002a01c9c733$92015470$6c02a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2009 14:20:38.0042 (UTC) FILETIME=[563E27A0:01C9C743] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:19:19 -0000 Maarten, On 27/04/2009 13:27, "Maarten Vissers" wrote: > Good CC, AIS present > This situation could arise because of a misconfiguration of the AIS > forwarding label injection table. And there are a number of scenarios which > make this quite likely when protection switching occurs. Depending on the > exact scope of the forwarding labels, a protection switch may well require > the proactive purging of entries from the AIS forwarding label injection > table following the protection switch (this could equivalently been seen as > the forwarding function proactively dropping the AIS packets). > > [mv] I don't think that those scenarios are likely scenarios. Equipment > compliant with ITU-T's equipment recommendations will not have those > scenarios. Only equipment that does not comply with those equipment > recommendations could have such scenarios. Just do not deploy such > equipment. I have heard this argument of "you just need to buy boxes that are built properly" before. It's fallacy. Reality is things go wrong. That could be due to hardware fault (fibre break, circuit board failure etc.), bug (hardware or software) or operator error. IME the failure conditions that are hardest to deal with operationally are bugs & misconfigurations. As Andy shows, in cases of error it is hard to trust what is configured correctly. Any additional configuration (e.g. AIS configuration) just increases the likelihood that something has been misconfigured. It is simple logic. I also struggle to see your argument of aligning with SDH/SONET primitives for AIS. If used at all AIS is a northbound function into the management system is it not? In which case it doesn't matter what primitive the node (box) uses to trigger that northbound message generation. In SDH/SONET the AIS primitive was generated automatically and so the node/box could use that to trigger generation a northbound message. In a packet network an AIS flow is not generated automatically it needs to be actively inserted. Insertion of AIS provides no useful information above and beyond that provided by CC, therefore why can the lack of CC not be used to trigger the generation of any northbound AIS message if such a message really is required? What you are proposing AFAICT is definition of additional protocol primitives (internal to the layer network that are not exposed directly to the management system) that provide nothing over the existing required primitives (i.e. CC). At best your proposal provides no value. At worst your proposal provides confusing and conflicting information to the operator trying to perform fault analysis. Ben From Italo.Busi@alcatel-lucent.it Mon Apr 27 10:36:44 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E70E3A6B13 for ; Mon, 27 Apr 2009 10:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=-3.998, BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v74hZcS8ahtu for ; Mon, 27 Apr 2009 10:36:37 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 41B1B3A6DC9 for ; Mon, 27 Apr 2009 10:36:36 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3RHbfZs020411; Mon, 27 Apr 2009 19:37:41 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 19:37:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C75E.DD406A3E" Date: Mon, 27 Apr 2009 19:37:38 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB40220ED18@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <002a01c9c733$92015470$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Associated bidirectional transport path requirements thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gAANdNEw References: <002a01c9c733$92015470$6c02a8c0@china.huawei.com> From: "BUSI ITALO" To: "Maarten Vissers" , X-OriginalArrivalTime: 27 Apr 2009 17:37:41.0492 (UTC) FILETIME=[DD917340:01C9C75E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 17:36:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C75E.DD406A3E Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, =20 thanks for your mail. You have just written all I was going to write on = this topic. =20 If this is not clear enough, I support your statements and I have = nothing more to add. =20 Italo ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Maarten Vissers Sent: Monday, April 27, 2009 2:28 PM To: andy.bd.reid@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 I have the impression that you do not have the correct understanding of = the SNC protection switching fucntional models and the location and = control of AIS insertion. Your understanding seems not aligned with the = specifications in our equipment and protection swithcing = recommendations. See inline... ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 12:50 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 It is of course true that adding a boolean input to a logical system = increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you = identify below. There are=20 =20 - good CC, no AIS =09 - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these input = states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly.=20 =20 [mv] I don't think that there is only "hope". This condition reflects = that there is no disconnect.=20 If every frame/packet arrives correctly is not checked by the reception = of CC and correct MEGID/MEPID. Frame/packet loss is checked by the = frame/packet loss measurement that is embedded in the CCM frames, and = can be activated.=20 =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is = because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below).=20 =20 [mv] With equipment that complies with the equipment standards this = condition doesn't give you just "hope". It gives you "knowledge" that = the discontinutity experienced in the connection is due to a server = layer fault.=20 =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS = forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending = on the exact scope of the forwarding labels, a protection switch may = well require the proactive purging of entries from the AIS forwarding = label injection table following the protection switch (this could = equivalently been seen as the forwarding function proactively dropping = the AIS packets).=20 =20 [mv] I don't think that those scenarios are likely scenarios. Equipment = compliant with ITU-T's equipment recommendations will not have those = scenarios. Only equipment that does not comply with those equipment = recommendations could have such scenarios. Just do not deploy such = equipment. =20 [mv] The AIS insertion in the functional models is performed in the = Adaptation Sink functions. Those Adaptation Sink functions are connected = to the Connection function in which the SNC Protection process is = located. The AIS insertion in an Adaptation sink fucntion continues = independent of the state of the protection switch process in the = Connection function; i.e. the selector in the protection process will = only receive frames/packets from either the working SNC, or the = protection SNC (but never from both).=20 =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a = forwarding function. But it could equally arise from a misconfiguration = of the AIS forwarding label injection table. In fact, the latter = actually seems just as likely and particularly problematic for = maintenance. Unlike normal forwarding, any mismatch between the = forwarding configuration and the AIS forwarding label injection table = will lie dormant and until a server fault arises. Then this generates a = false and misunderstood fault condition with maintenance looking for the = fault in the wrong place.=20 =20 [mv] As indicated in the above comment, equipment compliant with the = equipment and protection switching recommendation will not behave as you = suggest. Only equipment not-compliant with our equipment/protection = switching recommendation may do this, but such equipment should simply = not be deployed. =20 [mv] AIS generation is performed in the adaptation sink function for = the set of active client signals; i.e. for the set of connection/flow = points that are activated on the adaptation sink function (which are = represented by the set of active labels/VIDs/...). There is no "AIS = forwarding label injection table" in any of our equipment = recommendations. AIS will be generated for each client CI output on the = set of CPs/FPs on the adaptation sink function when aAIS consequent = action condition is true. =20 =20 The first two states can be reliably diagnosed with CC alone. The = second two arise from the introduction of the AIS/FDI. However, any = possible benefit that might arise is completely masked by the fact that = the AIS itself must be configured and there is no reason for this to be = more reliable than what it is supposed to be monitoring. Indeed, there = seems good reason to think that it will be less reliable.=20 =20 [mv] You are turning things upside down... CC is present to detect = continuity and connectivity problems introduced in the layer network's = Connection functions. As such you can not diagnose the second state with = CC alone. With CC alone one of your colleagues will be requested to = initiate a number of Loopback tests to find out which connection = function is misconfigured. This is the wrong action of course, as there = is a server layer fault. =20 [mv] You do not understand the AIS "configuration" aspect. AIS = generation configuration is on the node, not on each individual = connection. Networks that deploy AIS have it active on all their NNIs.=20 =20 There is no avoiding that AIS in circuit switching is fundamentally = different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something = and the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured.=20 =20 [mv] In packet transport networks with connectivity checking no packets = is not a valid condition.=20 =20 [mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require = any individual client connection specific information.=20 =20 [mv] ATM VP AIS and ATM VC AIS does not require any individual client = (i.e. VP, VC) connection specific information.=20 =20 [mv] ETH AIS does not require any individual client connection = identification specification, but it requires reuse of the client MEG = Level information which is also required for the ETH MIP functions on = the interface port. =20 [mv] I.e. AIS insertion does not require individual client connection = specific information. Either no additional information at all is = required, or additional information is required that is shared with = other fucntions/processes in the interface. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the = operational systems and processes are the same.=20 =20 [mv] And that is exactly what we do with support of AIS in packet = transport networks (ATM, Ethernet, T-MPLS =3D> MPLS-TP).=20 =20 The simple CC replicates all the triggers to management systems made by = SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data plane AIS requires a whole new area of configuration and generates = a whole new set of fault conditions which cannot be localised by = SONET/SDH processes. So, ironically, packet AIS is directly opposed to = backwards compatibility you claim is the main drive.=20 =20 [mv] I hope that you now understand that it is the opposite case is = that is present. Simple CC does **not** replicates all triggers... AIS = is needed in addition. =20 Regards, Maarten =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of = continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a = connection function (fabric) in the connection, which interrupts the = forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is = supported. It requires that the organization responsible for the layer = network takes action (i.e. locate the layer's connection function that = includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such = connection (due to a fault in a server layer) will also interrupt the = forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient = information to determine if the configuration in the layer's connection = functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. = This server layer fault is already reported by the server layer MEP = detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer = network fault (i.e. continuity fault). Fault localization must be = started to locate the misconfigured or failed connection function. Once = this faulty connection function is located, the configuration fault (or = hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in = both fault cases is however registered as part of performance = monitoring. This performance monitoring information is used to verify = the performance against the SLA for the connection. =20 Regards, Maarten =09 =09 ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only = adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network = management system). A problem occuring in admin domain A will be unknown = in admin domain B. The loss of continuaity alarms that are activated in = admin domain B due to the fault in admin domain A will appear as primary = alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want = different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server = layer. AIS suppresses the LOC alarm in those cases so that the = maintenance guys don't get triggered and start looking for a fault that = is outside their area. =20 Regards, Maarten =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems = (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. If, at an end equipment, = I have a good server/section layer and a loss of CC at the client layer, = I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service = guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system = is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions = will bring some complexity . but if we have no functions, it is more = complex and difcult for operators to maintence and administrator the = network. so I think every new functions and things may have positive and = negative effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network = (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means: = - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the = performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support = proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on = balance we considered not a good idea for PBB-TE OAM because it requires = a conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim.=20 =20 regards, Neil=20 =20 =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 =09 =09 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an = operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects = dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will = not be able to understand that as long as you refuse to accept that = "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated = connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE = and P-OTN VP trails inside metro and core domains interconnecting EVC = matrices. When one of those EVC links is interrupted, e.g. in the core between = metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more = frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a = connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and = OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means = is that OAM that is of a request/response nature cannot be trusted in co = mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it = won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to have = to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact = as they all offer something different/important. But do not be hoodwinked = by those who peddle a story that that tries to make the OAM of the 3 modes = the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a = return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs = could be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of = requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other = > > more important requirements (e.g. the possibility to work w/o IP = > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or = management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for = these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs = seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the = pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there = is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM = packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM = MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for = performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements = section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the = pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met = by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms = of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane = content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, = but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that = associated=20 > > > > > bidirectional paths are the only types of paths that can = be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional = paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the = time > > > > > being, the most important type of bidirectional paths = in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C75E.DD406A3E Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, thanks for your mail. You have just written all I was going to = write on=20 this topic. If this is not clear enough, I support your statements and I = have nothing=20 more to add. Italo From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 27, 2009 2:28 PM To:=20 andy.bd.reid@bt.com Cc: mpls-tp@ietf.org Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Andy, I have the = impression that=20 you do not have the correct understanding of the SNC protection = switching=20 fucntional models and the location and control of AIS insertion. Your=20 understanding seems not aligned with the specifications in our = equipment and=20 protection swithcing recommendations. See=20 inline... From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 12:50 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, It is of course true that adding a boolean = input to a=20 logical system increases the number of possible input states. So = adding an AIS=20 boolean to CC boolean creates four possible states not = just the=20 three you identify below. There are - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no=20 AIS We must ask what practical = scenarios could generate=20 each of these input states. Good CC, no AIS One hopes this is because this is = because the=20 service is working properly. [mv] I don't=20 think that there is only "hope". This condition reflects that = there is no=20 disconnect. If every=20 frame/packet arrives correctly is not checked by the reception of CC = and=20 correct MEGID/MEPID. Frame/packet loss is checked by the frame/packet = loss=20 measurement that is embedded in the CCM frames, and can be activated.=20 CC fault, AIS present One hopes this is because the service = is faulty and=20 one hopes this is because of a fault in a server layer. In fact, = the=20 presence of the AIS could be misleading (see below). [mv] With=20 equipment that complies with the equipment standards this = condition=20 doesn't give you just "hope". It gives you "knowledge" that the = discontinutity=20 experienced in the connection is due to a server layer=20 fault. Good=20 CC, AIS present This situation could arise because of a misconfiguration of = the AIS=20 forwarding label injection table. And there are a number of scenarios = which=20 make this quite likely when protection switching occurs. Depending on = the=20 exact scope of the forwarding labels, a protection switch may well = require the=20 proactive purging of entries from the AIS forwarding label injection = table=20 following the protection switch (this could equivalently been seen as = the=20 forwarding function proactively dropping the AIS packets). [mv] I don't = think that=20 those scenarios are likely scenarios. Equipment compliant with ITU-T's = equipment recommendations will not have those scenarios. Only = equipment that=20 does not comply with those equipment recommendations could have = such=20 scenarios. Just do not deploy such=20 equipment. [mv] The AIS insertion in the functional models = is=20 performed in the Adaptation Sink functions. Those Adaptation Sink = functions=20 are connected to the Connection function in which the SNC Protection = process=20 is located. The AIS insertion in an Adaptation sink fucntion = continues=20 independent of the state of the protection switch process in=20 the Connection function; i.e. the selector in the protection = process will=20 only receive frames/packets from either the working SNC, or the = protection SNC=20 (but never from = both). CC=20 fault, no AIS As you suggest, this could arise from a misconfiguration of a = forwarding function. But it could equally arise from a = misconfiguration of the=20 AIS forwarding label injection table. In fact, the latter actually = seems just=20 as likely and particularly problematic for = maintenance. Unlike=20 normal forwarding, any mismatch between the forwarding configuration = and the=20 AIS forwarding label injection table will lie dormant and until a = server fault=20 arises. Then this generates a false and misunderstood fault condition = with=20 maintenance looking for the fault in the wrong place. [mv] As = indicated in the=20 above comment, equipment compliant with the equipment and = protection=20 switching recommendation will not behave as you suggest. Only = equipment=20 not-compliant with our equipment/protection = switching recommendation may=20 do this, but such equipment should simply not be=20 deployed. [mv] AIS = generation is=20 performed in the adaptation sink function for the set of active = client=20 signals; i.e. for the set of connection/flow points that are activated = on the=20 adaptation sink function (which are represented by the set of active=20 labels/VIDs/...). There is no "AIS forwarding label injection table" = in any of=20 our equipment recommendations. AIS will be generated for each client = CI output=20 on the set of CPs/FPs on the adaptation sink function when aAIS = consequent=20 action condition is true. The first two states can be reliably diagnosed with CC = alone. The=20 second two arise from the introduction of the AIS/FDI. However, any = possible=20 benefit that might arise is completely masked by the fact that the AIS = itself=20 must be configured and there is no reason for this to be more reliable = than=20 what it is supposed to be monitoring. Indeed, there seems good reason = to think=20 that it will be less reliable. [mv] You are = turning=20 things upside down... CC is present to detect continuity and = connectivity=20 problems introduced in the layer network's Connection functions. As = such you=20 can not diagnose the second state with CC alone. With CC alone one of = your=20 colleagues will be requested to initiate a number of Loopback tests to = find=20 out which connection function is misconfigured. This is the wrong = action of=20 course, as there is a server layer=20 fault. [mv] You do = not understand=20 the AIS "configuration" aspect. AIS generation configuration is on the = node,=20 not on each individual connection. Networks that deploy AIS have it = active on=20 all their NNIs. There is no avoiding that AIS in circuit = switching is=20 fundamentally different from AIS in packet = switching. - in circuit switching, you must fill = the bit=20 stream with something and the information injected requires no = configuration=20 whatsoever. - in packet switching, no packets is a perfectly valid = condition=20 and the injection of AIS requires individual client connection = specific=20 information to be configured. [mv] In = packet transport=20 networks with connectivity checking no packets is not a valid = condition.=20 [mv]=20 AIS/FDI insertion specified in e.g. T-MPLS OAM does not = require any=20 individual client connection specific information.=20 [mv] ATM VP = AIS and ATM VC=20 AIS does not require any individual client (i.e. VP, VC) connection = specific=20 information. [mv] ETH AIS = does not=20 require any individual client connection identification specification, = but it=20 requires reuse of the client MEG Level information which is also = required for=20 the ETH MIP functions on the interface=20 port. [mv] I.e. = AIS insertion=20 does not require individual client connection specific information. = Either no=20 additional information at all is required, or additional information = is=20 required that is shared with other fucntions/processes in the=20 interface. The objective is not to replicate the data plane primitives = of=20 SONET/SDH, but the triggers to the operational systems so that the = operational=20 systems and processes are the same. [mv] And = that is exactly=20 what we do with support of AIS in packet transport networks (ATM, = Ethernet,=20 T-MPLS =3D> = MPLS-TP). The simple CC replicates all the triggers to management = systems made by=20 SONET/SDH and gives maximum compatibility. Conversely, the inclusion = of data=20 plane AIS requires a whole new area of configuration and generates a = whole new=20 set of fault conditions which cannot be localised by SONET/SDH = processes. So,=20 ironically, packet AIS is directly opposed to backwards compatibility = you=20 claim is the main drive. [mv] I hope = that you now=20 understand that it is the opposite case is that is = present. Simple=20 CC does **not** replicates all triggers... AIS is needed in=20 addition. Regards, Maarten Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 24 April 2009=20 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI does give additional information. = Let me=20 explain: The need for AIS/FDI is a consequence of = the deployment=20 of loss of continuity checking OAM (e.g. CCM in ethernet, CC in = ATM). The=20 objective of such CCM OAM is to be able to detect a misconfiguration = or=20 fault of a connection function (fabric) in the connection, which = interrupts=20 the forwarding of traffic in the connection. This is a fault = condition that=20 can only be discovered by the layer network in which the connection = is=20 supported. It requires that the organization responsible for the = layer=20 network takes action (i.e. locate the layer's connection = function that=20 includes the fault) to restore the = connection. Unfortunately, an interruption of one = of=20 the link connections of such connection (due to a fault in a = server=20 layer) will also interrupt the forwarding of traffic in the=20 connection. As such, loss of CC messages (LOC defect) = does not=20 provide sufficient information to determine if the configuration in = the=20 layer's connection functions along the connection have to be checked = and=20 corrected. AIS has been introduced and is used to help = differentiate between the two fault cases. 1) if LOC and AIS are detected, then there = is a server=20 layer fault. This server layer fault is already reported by the = server layer=20 MEP detecting this fault. No action is required, so no alarm to=20 generate. 2) if LOC is detected and there is no AIS, = then there=20 is a layer network fault (i.e. continuity fault). Fault localization = must be=20 started to locate the misconfigured or failed connection function. = Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is = retored. The interruption of the forwarding of = traffic in the=20 connection in both fault cases is however registered as part of = performance=20 monitoring. This performance monitoring information is used to = verify the=20 performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points I = made. My=20 point is that AIS/FDI gives no information above what is already = known - it=20 is only adds complexity and fault liability. Neither of your points = change=20 this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000=20 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009 = 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, > The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily=20 available. I don't = believe that=20 this is a correct statement in a multi-operator transport network, = or in=20 transport networks of one operator that have more then one = administrative=20 subdomain (each with its own network management system). A problem = occuring in admin domain A will be unknown in admin domain B. The = loss of=20 continuaity alarms that are activated in admin domain B due to the = fault=20 in admin domain A will appear as primary alarms, suggesting = connectivity=20 problems in admin domain B. > = The issue=20 arises because the two sides of maintenance want different things. = The=20 fault fixing > guys want to locate the fault and don't want = any other=20 information. The service=20 maintenance > guys want to know whether their customer = service is=20 working. This is addressed in SDH, OTN, Ethernet = and=20 T-MPLS recommendations by means of the additional SSF alarm. = The SSF=20 alarm is for the service guys telling them that the service was=20 interrupted due to a fault in a server layer. AIS suppresses the = LOC alarm=20 in those cases so that the maintenance guys don't get triggered = and start=20 looking for a fault that is outside their = area. Regards, Maarten From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two=20 things which are separate and for which AIS/FDI is no help. = Maintenance=20 operations are concerned with two separate = things. 1) Identifying faults in equipment, = line plant,=20 and other systems (eg misconfigurations) and fixing them = (equipment=20 maintenance). 2) Identifying the health of end to = end=20 connections, especially when they are directly supporting customer = services (service maintenance). The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily = available. If,=20 at an end equipment, I have a good server/section layer and a loss = of CC=20 at the client layer, I *know* the fault is elsewhere - I don't = need=20 AIS/FDI to tell me. (Indeed, if you think about, if the fault is = in the=20 end equipment, it is quite likely that the fault means it cannot = report=20 the traffic loss to the management system!) The issue arises because the two sides of = maintenance=20 want different things. The fault fixing guys want to locate the = fault and=20 don't want any other information. The service maintenance guys = want to=20 know whether their customer service is = working. This arose in the early days of = SONET/SDH, when the=20 operations guys demanded that the equipment did *not* suppress the = traffic=20 alarm even when AIS was being received as the service guys want to = know=20 about the alarms. The normal practice is for the equipment = to report=20 the alarms *including* AIS and then a filter is applied in the = management=20 system to suppress alarms to the fault fixing guys. As I'm = aware,=20 there are many different techniques applied for the filtering = algorithms,=20 especially when you consider multiple concurrent faults in a = network,=20 however, the existance of AIS/FDI doesn't add anything to these = that's not=20 already known. In fact, I believe simple time-stamp = correlation is=20 one of the most powerful and widely used techniques. And if the = equipment=20 starts messing up the reporting of loss of CC because it waiting=20 for/persistence checking AIS/FDI, it could end up messing up = simple=20 time-stamp correlation! In practice, it is often not quite a = simple as this,=20 as the service guys like to be able to 'localise' the fault. = However,=20 under most circumstances, the filter has automatically done = this.=20 So localisation you describe is only when the filter = hasn't=20 worked for some reason. But the bottom line is, whatever = operations process=20 you want to use, AIS/FDI doesn't add anything other than = complexity=20 and fault liability to the equipment. Remember AIS goes back = to the=20 TDM world where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 = (0)1277=20 324015 Email: = andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000 = This=20 electronic message contains information from British = Telecommunications=20 plc which may be privileged or confidential. The information is = intended=20 to be for the use of the individual(s) or entity named above. If = you are=20 not the intended recipient be aware that any disclosure, copying,=20 distribution or use of the contents of this information is = prohibited. If=20 you have received this electronic message in error, please notify = us by=20 telephone or email (to the numbers or address above)=20 immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded to secure effective operation and for other lawful = business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil: = thank you for wasting more = time in=20 describling the problems. but I think some of what you said is = no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense=20 in cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI=20 functions, when there is a defects in a given layer network, it = can=20 cause multiple alarm events to be raised. it is diffcult = for=20 operators to locate and diagnose the faults. though I completely agree you = on=20 adding new things and functions will bring some complexity = . but=20 if we have no functions, it is more complex and difcult for = operators to=20 maintence and administrator the network. so I think every new = functions=20 and things may have positive and negative effects. but we should = consider it very much, don't delete some functions at = random.=20 best regards = liu <neil.2.harrison@bt.com> 2009-04-21 = 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If MPLS-TP is going to be taken seriously as a = transport network=20 (like SDH/SONET) then the 2 key MUST HAVE requirements are = these.=20 1 Provide a transparent = client/server=20 relationship...which means: - all client bits treated=20 equally -=20 client bit ordering preserved - = no attempt to=20 infer client symbol (ie sequence of client bits) meaning and no = attempt=20 to change client symbols - the traffic behaviour of = client X=20 must not impact the performance experienced by client Y = A key corollary of the above is that MPLS-TP must only = support=20 proper connections (ie single source constructs) = = 2 Since = MPLS-TP is a=20 transport network it is not a top-of-stack network (ie it does = not=20 support directly external message/file/stream applications).=20 MPLS-TP therefore does not require an E-NNI specification. = A=20 key corollary of this is that MPLS-TP will not have any peer=20 interworking relationship with any other network = mode/technology.=20 Now wrt OAM = MPLS-TP is a co-ps=20 mode network. You could argue this should have = FDI/AIS....however,=20 the merit of this is highly questionable. When I and = colleagues=20 discussed whether PBB-TE (also a co-ps mode network) should have = FDI/AIS=20 we concluded that on balance it was not a good idea.....and note = that=20 initially I was in favour of having AIS, but my colleagues = provided=20 strong technical arguments that convinced me otherwise. = AIS/FDI is historically linked to the early PDH co-cs = mode layer=20 networks that used TTL logic. When this died it put out a = +5V (all=20 1s) signal by default, ie it required no conscious effort to = generate=20 it.....this is key point. Further, in these networks there = is a=20 fairly static/long-holding client server relationship. = Clearly=20 this is not true in the cl-ps mode and it's why IETF have never=20 specified AIS for IP and its why IEEE had the good sense to = throw-out=20 AIS in 802.1ag for Ethernet (though ITU have unwisely IMO = retained it in=20 Y.1731....but I suspect any operator planning to use Ethernet = equipment=20 would always look to IEEE stds and not ITU ones). = AIS/FDI and the co-ps mode is debatable. As I = noted above,=20 on balance we considered not a good idea for PBB-TE OAM because = it=20 requires a conscious effort to generate it (unlike the co-cs = mode) so=20 there are likely to be scaling problems and its one more thing = to go=20 wrong. You should also = have seen me=20 make the point many times in the past that the always-on defect=20 detection/handling OAM needs to be as simple/sparse as possible = with as=20 little config as possible because we need super = reliability......TCM=20 goes completely against the grain here. Also note that the = OAM=20 required for each of the 3 network modes is not the same, = despite what=20 some claim. regards, = Neil From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Deborah: maybe what you said is right. but = I can't=20 completely agree your opinions. IMO. mpls-tp is regard as = transport=20 network like SDH/SONET. so it should have AIS/FDI fuctions as=20 SDH/SONET. do you think so. = best regards liu "BRUNGARD, DEBORAH=20 A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org = 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with = Neil, it is very=20 questionable the value of AIS/FDI in a packet network- any = mode. It=20 can result in a DoS attack by an operator on themselves so = even Y1731=20 recommends not to block data frames: "A MEP can decide = whether it=20 blocks data frames when it detects dAIS. The principle=20 requirement that influences this decision is that data frames = ought=20 to be forwarded as much as possible, without the = possibility of=20 forwarding wrong data frames downstream." Table I.7-2 shows = for AIS,=20 not to block. And as Y1731 states, AIS can only be used = under=20 very constrained architectures - if required for MPLS-TP, it = needs to=20 have the same guidance as in Y1731, i.e. point-to-point and=20 server/client one-to-one: "for a point-to-point ETH = connection, a MEP=20 has only a single peer MEP. Therefore, there is no = ambiguity=20 regarding the peer MEP for which it should suppress alarms = when it=20 receives the ETH-AIS information." So should only be = within one=20 domain - then no need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05 AM To:=20 neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in the = cl=20 mode?...do me a favour! Ethernet AIS is indeed a = requirement and=20 a necessity. And you will not be able to understand that = as long=20 as you refuse to accept that "cl-mode" is a forwarding = mode within=20 a **transport entity**. G.800 amendment 1 = has finally reintroduced=20 this transport entity into G.800. Besides that, it = also introduced=20 the **differentiated connection**: [G.800 am1] "A = differentiated=20 connection is a transport entity that transfers information = belonging=20 to multiple communications between ports across a subnetwork. = <..> In a differentiated connection = message contents are=20 interpreted to identify (sets of) communications which=20 receive different treatment. The sets of = communications may=20 be distinguished by the forwarding identifier or other layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms of=20 G.800 "differentiated connections". Ethernet AIS provides = AIS=20 within the scope of such "differentiated = connection". If you apply=20 this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and core = domains=20 interconnecting EVC matrices. When one of those EVC links = is=20 interrupted, e.g. in the core between metro 1 and metro 4 = (see=20 attached slide), then the EVC differentiated connection that=20 is present on this link will be interrupted. At the EVC = switch/bridge=20 node in metro 4 this interruption is noticed and EVC-AIS = is=20 inserted in the downstream direction to suppress the EVC-LOC = alarms=20 at EVC endpoints D4 and D5. The EVC-AIS (i.e. = Ethernet AIS)=20 frame has a reserved multicast address, which guarantees that = the AIS=20 is broadcast to the endpoints of the EVC. I believe that = it is=20 time for you to adapt your view on co and cl = modes and relate it=20 to the forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP = differentiated connection"=20 with a billion or more ports. What we know as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an Ethernet = VLAN is=20 essentially an "Ethernet differentiated connection" with n = ports=20 (n in the range of e.g. 2 to 1000). What we know as a p2p = MPLS E-LSP=20 is essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection" with=20 2 ports. Transport network OAM applies to transport = entities,=20 which are (in terms of G.800 am1) connections and = differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: = RE:=20 [mpls-tp] Associated bidirectional transport=20 path requirements John, Thanks this is a great = platform=20 to explain why OAM for the 3 network modes needs to be = different.=20 I am getting a wee bit tired of folks trying to make = all 3=20 network modes look alike (and then, even worse, = interwork them as=20 as peers...esp when not not top-of-stack networks...I mean = how silly=20 can we get?). I am even more frustrated by the fact = those=20 peddling this FUD only ever seem to consider OAM = and forget all=20 other DP/CP/MP components (esp top-of-stack=20 message/file/stream application adaptations). How wrong = can=20 this get! In the co modes a *connection* is a very = specific and=20 *constraining* construct.....I am assuming here we respect = the rules=20 of a connection (ie single source) though some folks don't = even=20 bother to respect this, and this is despite the fact that = we all=20 know what problems multiple-source constructs can cause (from = LDP/PHP....ergo MPLS-TP). When we have a connection this=20 restricts *all* DP (ie traffic and OAM) to stay within the = bounds=20 of the connection. Which is fine=20 under defect-free conditions, but if we have leaking = traffic then=20 the constraining nature of the connection construct is = broken.=20 In a nutshell what this means is that OAM that is of = a=20 request/response nature cannot be trusted in co mode networks = under=20 misconnectivity defects.....indeed, why should a = leaking DP have a=20 symmetric go/return defect behaviour?....very likely it=20 won't. So whilst request/response OAM is right for the cl = mode it=20 is not right for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different and = not just=20 in OAM requirements....but AIS/FDI in the cl mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why I = often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts to = explain=20 that physics....G.805 does not. So, the 3 modes are=20 different...please accept/rejoice in this fact as they all = offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of the=20 3 modes the same. regards, Neil > = -----Original=20 Message----- > From: mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander = Vainshtein;=20 Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path >=20 requirements > > Italo, > > As = described in=20 the MPLS TP OAM Requirements I-D, virtually all of = the > OAM=20 functions require a return path, and in the absence of a return = >=20 path they are disabled. > > As described in David=20 Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; neither = the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the issue=20 of return path for unidirectional LSPs could be > = charaterized=20 as the elephant in the room. In the MPLS TP OAM > = Framework=20 I-D, unicast LSPs are only mentioned three times and return = >=20 paths not at all. > > Thanks, > > = John >=20 > -----Original Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, = April=20 17, 2009 1:59 AM > > To: Drake, John E; Alexander = Vainshtein;=20 Maarten Vissers > > Cc: mpls-tp@ietf.org > > = Subject:=20 RE: [mpls-tp] Associated bidirectional transport path > = >=20 requirements > > > > John, > > = > >=20 I might have missed the agreement of MPLS-TP being capable of = >=20 > sending replies to OAM requests sent on uni-directional=20 LSPs. > > > > This requirement does not = belong to the=20 first set of requirements > > ITU-T is expecting to be = met by=20 October. > > > > However, I think this in a = potential=20 interesting additional > > requirement to be taken = into=20 account (at worst in a > subsequent phase). > > = >=20 > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility = to work=20 w/o IP > > forwarding and the need for OAM to continue = to=20 monitor the data > > plane also in case of failures = affecting=20 the control or management > > plane). > > = >=20 > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the = design=20 solution. > > > > Thanks, Italo > > = >=20 > > -----Original Message----- > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 > > Sent: Thursday, April 16, 2009 8:00 PM > > = > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc:=20 mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > = requirements >=20 > > > > > At the meeting last fall at Juniper = in=20 Massachusetts, I > > think it was > > > = agreed that=20 an MPLS TP network needs to have a forwarding > >=20 capability > > > for management, control, and OAM = packets=20 (e.g., sending > > replies to OAM > > > = requests=20 sent on uni-directional LSPs) even if it does not > > = have an=20 IP > > > forwarding data plane. > > > = >=20 > > > -----Original Message----- > > > > = From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > > = Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > > = >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > = >=20 > > > Maarten, > > > > It seems that = you've just=20 (implicitly and, probably, > > > > inadvertently) = stated=20 the following: > > > > > > > > = =20 MPLS-TP = OAM will=20 not ever support MIP loopback function > > (and = fault >=20 > > > localization which requires this function ) = for >=20 > unidirectional P2MP > > > > and P2P = paths. >=20 > > > > > > > If this statement is = correct,=20 this (IMHO and FWIW) > raises a valid > > > = >=20 question: > > > > > > > > = =20 Is MPLS-TP an=20 appropriate solution for these > types of = transport > >=20 > > paths? > > > > > > > > = For the=20 reference, IP/MPLS provides this kind of > > = functionality=20 today > > > > for (unidirectional - but it does = not know=20 any other > > type) P2P LSPs > > > > as=20 described in RFC 4379. And its extension to P2MP LSPs seems = >=20 > > > easy... > > > > > > > = >=20 > > > > > > > > = Regards, >=20 > > > > > > > = Sasha >=20 > > > > > > > > > > > = >=20 > > > ________________________________________ > = >=20 > > From: mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On Behalf > > = > >=20 Of Maarten Vissers [maarten.vissers@huawei.com] > > = > >=20 Sent: Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc: = mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional = transport path=20 > > > > requirements > > > > = >=20 > > > Adrian, > > > > > > > = >=20 >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > = > >=20 > other internal > > > > >> = =20 functions as appropriate) of a co-routed > > > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of = that > >=20 > > >> transport path. > = >=20 > > >> <end quote> > > > > = > >=20 > > > > There is no way this is a functional = requirement.=20 That > > > is, there is > > > > >=20 *nothing* that can be observed from a black box point of > = >=20 > view that > > > > > results from adhering = to this=20 requirement. > > > > > > > > Your = understanding is not correct. It is very much > observable = if > > > > this requirement is met from a black = box point=20 of view. > > > > The MIP functions can only = perform the=20 Loopback when there is a > > > > co-routed = bidirectional=20 transport path. The MPLS-TP LBM packet > > > > = received=20 at a MIP needs to be returned (as LBR > > > > = packet) to=20 the originating MEP function via the other > > = direction=20 of > > > > the co-routed bidirectional transport = path.=20 This other > direction > > > > would not be = available in an associated bidirectional transport > > = >=20 > path... and thus the loopback test > > > would=20 fail. > > > > > > > > Similarly, = when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not in a > > > > associated = bidir=20 transport path. In the first case the TCM MEP > > > = >=20 Source and Sink functions are co-located and can > = exchange what=20 is > > > > called "remote information" which is = necessary=20 for performance > > > > monitoring. > > = >=20 > In the latter case the TCM MEP Source and Sink = functions >=20 > are in e.g. > > > > different nodes in the = network=20 and TCM would not be able > > to provide > > = > >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, > >=20 > MIPs and other > > > > internal > > = >=20 > > functions as appropriate)" should be deleted. It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = > Your=20 understanding is not correct. This text must not be > > = deleted=20 at > > > > all. > > > > > = > >=20 > > Actually, I am quite fed up about this = persistent > >=20 > insistence on the > > > > inclusion > = >=20 > > > of "Tandem Connection." The definition within the = ITU-T=20 of > > > > this term > > > > >=20 is > > > > poorly > > > > > = specified=20 and comes from the monitoring of a path that is > > = > >=20 parallel (i.e. > > > > tandem) > > > = >=20 > to the data path being monitored. This definition of = TC >=20 > > > seems to be at > > > > = variance, >=20 > > > > and would be if the ACH was actually in=20 band. > > > > > > > > I don't = understand=20 where your interpretation of tandem > > connection = is >=20 > > > described in ITU-T recommendations. I.e. "from=20 the > > monitoring of a > > > > path = that is=20 parallel (i.e. tandem) to the data path being > > > = >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection is = a=20 set > > > > of interconnected "link connections" = and=20 "matrix > connections". A > > > > subset of = those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to as > = a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > > = There=20 is only additional OAM inserted inside the data > path by=20 the > > > > TCM MEP_So function and this OAM is = extracted=20 from the > > data path by > > > > the = TCM MEP_Sk=20 function. > > > > > > > >=20 Regards, > > > > Maarten > > > > = >=20 > > > > > > > -----Original=20 Message----- > > > > From:=20 mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel >=20 > > > Sent: donderdag 16 april 2009 11:59 > > = >=20 > To: Alexander Vainshtein; = benjamin.niven-jenkins@bt.com >=20 > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = >=20 > > > requirements > > > > > > = >=20 > Hi Sasha, > > > > > > > > = >=20 Unfortunately I cannot fully agree with your statement: > = >=20 > > > > > > > > <quote> > = >=20 > > > From the point of view of hardware, = co-routed > > > bidirectional LSPs > > > = >=20 > are a special case of associated = bidirectional=20 LSPs. > > > > > <end quote> > > = >=20 > > > > > > > This statement would be = obviously=20 correct, were it not for > > > > = Requirement > >=20 > > > 34 in the latest MPLS-TP requirements = draft > >=20 > > > > > > OK. Got it. > > > = >=20 > > > > But what is this doing in the data plane = requirements section? > > > > > > > = > In=20 fact, what is this requirement actually saying? > > = > >=20 > > > > > <quote> > > > = > >=20 The intermediate nodes (including MEPs, MIPs = and > > > other internal > > > > > = =20 functions as appropriate) of a co-routed > = > >=20 > bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > > relationship of the = forward and=20 the backward > > > > directions of that > = > >=20 > > transport path. > > > = >=20 > <end quote> > > > > > > > = >=20 There is no way this is a functional requirement. That > = > is,=20 there is > > > > *nothing* that can be observed = from a=20 black box point of > > view that > > > > = results=20 from adhering to this requirement. > > > > = > >=20 > > Therefore it could be assumed that this requirement is = met by=20 > > > > configuring some data plane database = component=20 through the > > > > management plane. The = database=20 component is not used > for anything > > > = > except=20 to satisfy this requirement for "awareness". > > > = >=20 > > > > Ben! Can we please try to rewrite this=20 requirement in terms of > > > > = behavior? > >=20 > > > > > > > Please note that = Requirement 34=20 is the ONLY item in the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > requirements > > > = > >=20 at end points for co-routed and associated bidirectional > = >=20 > paths are > > > > > exactly the same even = if they=20 appear in two different > > > items in the > = > >=20 > > requirements' list). > > > > > In = other=20 words, without Requirement 34 the notion of > = co-routed >=20 > > > > bidirectional paths would be void of any = data plane=20 content. > > > > > > > > > > = The=20 somewhat vague scope of this requirement ("other internal = > >=20 > > > functions as appropriate") creates a suspicion = that=20 HW > > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with = it. >=20 > > > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > MIPs and other > > = >=20 > internal functions as appropriate)" should be deleted. = It >=20 > does not > > > > add to "The intermediate=20 nodes." > > > > > > > > > The=20 following text in the draft increases this suspicion: > = > >=20 > > > > > > > <quote> > > = >=20 > > Tandem Connection: A tandem connection is = an >=20 > arbitrary part of a > > > > > = transport=20 path that can be monitored (via OAM) > > > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of a=20 transport path. > > The tandem > > > = >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > > > > = > =20 at the edge(s) of the segment or concatenated segment. > = > >=20 > > <end quote> > > > > > > = >=20 > Actually, I am quite fed up about this persistent > = >=20 insistence on the > > > > inclusion of "Tandem=20 Connection." The definition within > > the ITU-T = of >=20 > > > this term is poorly specified and comes from = the >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > > = monitored. This=20 definition of TC seems to be at variance, > > and = would >=20 > > > be if the ACH was actually in band. > > = >=20 > > > > > > Doesn't "forwarding engine" = sound like=20 hardware to you? > > > > > > > > = Yes, but=20 so what? > > > > > > > > > = IMHO it is=20 worth noting that neither the MPLS-TP > > > = Requirements=20 draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > > > > > > > > = >=20 > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed in=20 the MPLS-TP OAM > > Framework > > > > = >=20 draft > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > ). > = >=20 > > > > > > Right. > > > > = Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some clarity=20 regarding > > > co-routed vs. > > > > = >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 to=20 specific > > > functionality. > > > > = > > > > Agreed. > > > > > = >=20 > > Adrian > > > > > > > > = >=20 > > > > > > > > > > >=20 ________________________________________ > > > > = From:=20 Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: = Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc:=20 mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp]=20 Associated bidirectional transport path > > > >=20 requirements > > > > > > > > Hi=20 Sasha, > > > > > > > > Not really = sure=20 whether you are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one of Ben's = messages is that associated > > > > >=20 bidirectional paths are the only types of paths that can = be > >=20 > > created in > > > > > the existing = networks;=20 "true" co-routed bidirectional paths > > > > will = have > > > > > to wait until (if ever) new = equipment=20 becomes available. > > > > > > > = > This=20 is clearly nonsense! > > > > From the point of = view of=20 hardware, co-routed > > bidirectional LSPs are > = >=20 > > a special case of associated bidirectional = LSPs. > >=20 > > > > > > If you can set up two = unidirectional=20 LSPs (e.g. using the > > management > > > = >=20 plane) you can surely set up a co-routed > > > = bidirectional=20 LSP. > > > > > > > > There are = shipping=20 solutions that achieve co-routed > bidirectional > = > >=20 > LSPs using the control plane. These either use the = GMPLS >=20 > (which is > > > > cleaner) or non-standard=20 proprietary solutions (which is > > messy but > = > >=20 > functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment=20 as they > are = software > >=20 > > solutions. > > > > > > > = > >=20 2. My reading of one of Neil's messages is that the = actual > >=20 > > driver for > > > > > co-routed = bidirectional=20 paths may be experience with existing > > > > = >=20 transport networks rather than any specific benefit. > = > >=20 > > > > > Isn't that the case with 75% of the = MPLS-TP=20 requirements? > > > > Which is not to say it is a = bad=20 thing. > > > > > > > > A large = driver for=20 MPLS-TP is to give the packet network > > the = look, >=20 > > > feel, and behavioral characteristics of a=20 "legacy" > > > > transport network. > > = >=20 > > > > > > Based on these observations, = I'd guess=20 (FWIW) that: > > > > > * associated = bidirectional=20 paths are, at least for the time > > > > > = =20 being, the most important type of bidirectional paths = in >=20 > > > > MPLS-TP > > > > = >=20 > > > I think that is wrong both given my statement = above,=20 and > > given that > > > > other = upgrades to=20 existing MPLS solutions will be > needed to reach > = >=20 > > the full function level of MPLS-TP. > > > = >=20 > > > > > * they had a good chance to remain = the only=20 type of > > bidirectional > > > > > = =20 paths in real deployments. > > > > > = >=20 > > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > mpls-tp@ietf.org > = >=20 > https://www.ietf.org/mailman/listinfo/mpls-tp > > = >=20 > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy=20 and are not permitted to disclose the contents of this = communication to=20 others. This email and any files transmitted with it are = confidential=20 and intended solely for the use of the individual or entity to = whom they=20 are addressed. If you have received this email in error please = notify=20 the originator of the message. Any views expressed in this = message are=20 those of the individual sender. This message has been scanned = for=20 viruses and Spam by ZTE Anti-Spam = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9C75E.DD406A3E-- From Italo.Busi@alcatel-lucent.it Mon Apr 27 10:48:24 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8AA3A68E7 for ; Mon, 27 Apr 2009 10:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.23 X-Spam-Level: * X-Spam-Status: No, score=1.23 tagged_above=-999 required=5 tests=[AWL=-6.456, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUx7GWu9hDfF for ; Mon, 27 Apr 2009 10:48:18 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 82E6B3A6821 for ; Mon, 27 Apr 2009 10:48:16 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3RHnDWZ021533; Mon, 27 Apr 2009 19:49:14 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 19:49:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C760.79BEE6BF" Date: Mon, 27 Apr 2009 19:49:09 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB40220ED1C@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <003801c9c735$2eaeede0$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AIS/FDI (was [mpls-tp] Associated bidirectional transport path requirements) thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAHRYX7AAEIvGoAAGn4jgAAsEQCA= References: <003801c9c735$2eaeede0$6c02a8c0@china.huawei.com> From: "BUSI ITALO" To: "Maarten Vissers" , , X-OriginalArrivalTime: 27 Apr 2009 17:49:13.0529 (UTC) FILETIME=[7A0DEA90:01C9C760] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 17:48:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C760.79BEE6BF Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, =20 I have seen some SPs not willing to deploy AIS/FDI in their network and = some SPs supporting the requirement for AIS/FDI. =20 As a consequence I think that AIS/FDI (like all OAM features) should be = a feature optional to use. =20 However, this discussion has convinced myself that the most appropriate = approach is to have AIS/FDI enabled by default with the option for the = SP to disable it. =20 Disabling AIS/FDI, or deploying NEs that does not support the = capability, has the implications you have listed below and as such it = should be a conscious decision from the SP. =20 Italo ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Maarten Vissers Sent: Monday, April 27, 2009 2:39 PM To: andy.bd.reid@bt.com; lihan@chinamobile.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 Please read my response to your post. I have indicated that your = understanding of existing equipment and protection switching = recommendations is incorrect.=20 =20 The use of AIS/FDI and the general agreement that AIS is mandatory = (i.e. not optional) will allow us to use the same fault detection, alarm = suppression and fault localisation as in other transport network = technologies (SDH, OTN, Ethernet). =20 If AIS is optional, then operators not using AIS must find other means = to distinguish between LOC alarm due to a continuity/connectivity fault = in the layer network, or in the server layer. If such other means are = not deployed then there are two alternatives: 1) ignore every LOC alarm (assume that it is a server layer fault), = until the customer complains that his/her connection is broken 2) start fault localisation on every LOC alarm, and conclude in 90-99% = of the cases that the problem was a server layer fault. =20 Regards, Maarten ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 13:20 To: lihan@chinamobile.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Han, =20 In his post below, Maarten is not claiming that AIS is needed for alarm = suppression. He is saying that he sees it being used to distinguish = faults in a server layer from faults in the client layer. As you will = see in my post back to Maarten, this cannot be practically achieved. =20 I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, = in the packet world of MPLS-TP, AIS/FDI cannot be simple and therefore = cannot be the same as in SONET/SDH. =20 The objective is to reuse the same basic fault detection, alarm = suppression, and fault localisation as SONET/SDH. This is readily = achieved with the CC messages in the dataplane. =20 However, adding AIS/FDI would require a completely new configuration = management system and a completely new set of fault conditions requiring = localisation. Ironically, adding a packet AIS/FDI effectively removes = the compatibility with SONET/SDH management systems and processes. =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: lihan [mailto:lihan@chinamobile.com]=20 Sent: 27 April 2009 02:41 To: 'Maarten Vissers'; Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: =B4=F0=B8=B4: [mpls-tp] Associated bidirectional transport = path requirements =09 =09 Support! AIS/FDI is very importance for network management. MPLS-TP is divided = into three layers in order to enhance the scalability and OAM. It is = very important to distinguish the failure is belong to server layer or = client layer. AIS/FDI is a simple and well-known mechanism to realize = alarm suppression and fault localization.=20 =20 =20 Best regards, Han Li ***************************************************** Han Li, Ph.D. R&D, CHINA MOBILE COMMUNICATIONS CORPORATION Tel: +86 10 66006688 ext. 3092 Fax: +86 10 63601087 MOBILE: 13501093385 ***************************************************** =09 ________________________________ =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] =B4=FA=B1=ED Maarten Vissers =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C225=C8=D5 2:15 =CA=D5=BC=FE=C8=CB: andy.bd.reid@bt.com =B3=AD=CB=CD: mpls-tp@ietf.org =D6=F7=CC=E2: Re: [mpls-tp] Associated bidirectional transport path = requirements =20 Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of = continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a = connection function (fabric) in the connection, which interrupts the = forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is = supported. It requires that the organization responsible for the layer = network takes action (i.e. locate the layer's connection function that = includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such = connection (due to a fault in a server layer) will also interrupt the = forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient = information to determine if the configuration in the layer's connection = functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. = This server layer fault is already reported by the server layer MEP = detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer = network fault (i.e. continuity fault). Fault localization must be = started to locate the misconfigured or failed connection function. Once = this faulty connection function is located, the configuration fault (or = hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in = both fault cases is however registered as part of performance = monitoring. This performance monitoring information is used to verify = the performance against the SLA for the connection. =20 Regards, Maarten =20 =09 ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only = adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 =20 =09 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network = management system). A problem occuring in admin domain A will be unknown = in admin domain B. The loss of continuaity alarms that are activated in = admin domain B due to the fault in admin domain A will appear as primary = alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want = different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server = layer. AIS suppresses the LOC alarm in those cases so that the = maintenance guys don't get triggered and start looking for a fault that = is outside their area. =20 Regards, Maarten =20 =20 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems = (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. If, at an end equipment, = I have a good server/section layer and a loss of CC at the client layer, = I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service = guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system = is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 =20 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions = will bring some complexity . but if we have no functions, it is more = complex and difcult for operators to maintence and administrator the = network. so I think every new functions and things may have positive and = negative effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements =20 =20 =20 =09 =09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network = (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means: = - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the = performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support = proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on = balance we considered not a good idea for PBB-TE OAM because it requires = a conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim.=20 =20 regards, Neil=20 =20 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements =20 =20 =20 =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an = operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects = dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will = not be able to understand that as long as you refuse to accept that = "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated = connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE = and P-OTN VP trails inside metro and core domains interconnecting EVC = matrices. When one of those EVC links is interrupted, e.g. in the core between = metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints = D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more = frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a = connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and = OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means = is that OAM that is of a request/response nature cannot be trusted in co = mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it = won't. So whilst request/response OAM is right for the cl mode it is not right = for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to have = to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact = as they all offer something different/important. But do not be hoodwinked = by those who peddle a story that that tries to make the OAM of the 3 modes = the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of = the =09 > OAM functions require a return path, and in the absence of a = return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, = an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs = could be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of = requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other = > > more important requirements (e.g. the possibility to work w/o IP = > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or = management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for = these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs = seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the = pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there = is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM = packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM = MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for = performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements = section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the = pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met = by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms = of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane = content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, = but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that = associated=20 > > > > > bidirectional paths are the only types of paths that can = be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional = paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the = time > > > > > being, the most important type of bidirectional paths = in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C760.79BEE6BF Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, I have seen some SPs not willing to deploy AIS/FDI in their = network and=20 some SPs supporting the requirement for AIS/FDI. As a consequence I think that AIS/FDI (like all OAM features) = should be a=20 feature optional to use. However, this discussion has convinced myself that the most = appropriate=20 approach is to have AIS/FDI enabled by default with the option for the = SP to=20 disable it. Disabling AIS/FDI, or deploying NEs that does not support the = capability,=20 has the implications you have listed below and as such it should be a = conscious=20 decision from the SP. Italo From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers Sent: Monday, April 27, 2009 2:39 PM To:=20 andy.bd.reid@bt.com; lihan@chinamobile.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, Please read my response to your post. I have = indicated=20 that your understanding of existing equipment and protection switching = recommendations is incorrect. The use of AIS/FDI and the general agreement=20 that AIS is mandatory (i.e. not optional) will allow us = to use=20 the same fault detection, alarm suppression and fault localisation as = in other=20 transport network technologies (SDH, OTN, = Ethernet). If AIS is optional, then operators not using = AIS must=20 find other means to distinguish between LOC alarm due to a=20 continuity/connectivity fault in the layer network, or in the server = layer. If=20 such other means are not deployed then there are two=20 alternatives: 1) ignore every LOC alarm (assume that it is = a server=20 layer fault), until the customer complains that his/her connection is=20 broken 2) start fault localisation on every LOC = alarm, and=20 conclude in 90-99% of the cases that the problem was a server layer=20 fault. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 13:20 To: lihan@chinamobile.com;=20 maarten.vissers@huawei.com Cc: = mpls-tp@ietf.org Subject:=20 RE: [mpls-tp] Associated bidirectional transport path=20 requirements Han, In his post below, Maarten is not claiming = that AIS is=20 needed for alarm suppression. He is saying that he sees it=20 being used to distinguish faults in a server layer from faults in = the=20 client layer. As you will see in my post back to Maarten, this cannot = be=20 practically achieved. I agree, in SONET/SDH, AIS/FDI is simple and = well known.=20 Unfortunately, in the packet world of MPLS-TP, AIS/FDI cannot be = simple and=20 therefore cannot be the same as in SONET/SDH. The objective is to reuse the same basic = fault detection,=20 alarm suppression, and fault localisation as SONET/SDH. This is = readily=20 achieved with the CC messages in the = dataplane. However, adding AIS/FDI would require a = completely new=20 configuration management system and a completely new set of fault = conditions requiring localisation. Ironically, adding a packet AIS/FDI = effectively removes the compatibility with SONET/SDH management = systems and=20 processes. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: lihan = [mailto:lihan@chinamobile.com]=20 Sent: 27 April 2009 02:41 To: 'Maarten = Vissers';=20 Reid,ABD,Andy,CXM R Cc: = mpls-tp@ietf.org Subject: =B4=F0=B8=B4:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Support! AIS/FDI is = very=20 importance for network management. MPLS-TP is divided into three = layers in=20 order to enhance the scalability and OAM. It is very important to=20 distinguish the failure is belong to server layer or client layer. = AIS/FDI=20 is a simple and well-known mechanism to realize alarm suppression = and fault=20 localization. Best=20 regards,     Han=20 Li *****************************************************<= /SPAN> Han=20 Li, Ph.D. R&D,=20 CHINA MOBILE COMMUNICATIONS CORPORATION Tel:=20 +86 10 66006688 ext. 3092 Fax:=20 +86 10 63601087 MOBILE<= /ns0:place>: = 13501093385 ***************************************************** =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] =B4=FA=B1=ED = Maarten=20 Vissers =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C225=C8=D5 = 2:15 =CA=D5=BC=FE=C8=CB: = andy.bd.reid@bt.com =B3=AD=CB=CD: = mpls-tp@ietf.org =D6=F7=CC=E2: Re: [mpls-tp] Associated bidirectional = transport=20 path requirements Andy, AIS/FDI = does give=20 additional information. Let me explain: The need = for=20 AIS/FDI is a consequence of the deployment of loss of continuity = checking=20 OAM (e.g. CCM in ethernet, CC in ATM). The objective of such CCM OAM = is to=20 be able to detect a misconfiguration or fault of a connection = function=20 (fabric) in the connection, which interrupts the forwarding of = traffic in=20 the connection. This is a fault condition that can only be = discovered by the=20 layer network in which the connection is supported. It requires that = the=20 organization responsible for the layer network takes action (i.e. = locate=20 the layer's connection function that includes the = fault) to=20 restore the connection. Unfortunately, an=20 interruption of one of the link connections of such = connection=20 (due to a fault in a server layer) will also interrupt the = forwarding of=20 traffic in the connection. As such, = loss of CC=20 messages (LOC defect) does not provide sufficient information to = determine=20 if the configuration in the layer's connection functions along the=20 connection have to be checked and corrected. AIS has = been=20 introduced and is used to help differentiate between the two fault=20 cases. 1) if LOC = and AIS=20 are detected, then there is a server layer fault. This server layer = fault is=20 already reported by the server layer MEP detecting this fault. No = action is=20 required, so no alarm to generate. 2) if LOC = is=20 detected and there is no AIS, then there is a layer network fault = (i.e.=20 continuity fault). Fault localization must be started to locate the=20 misconfigured or failed connection function. Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is = retored. The = interruption of=20 the forwarding of traffic in the connection in both fault cases is = however=20 registered as part of performance monitoring. This performance = monitoring=20 information is used to verify the performance against the SLA for the connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april 2009=20 12:34 To:=20 maarten.vissers@huawei.com Cc: = mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements Maarten, These = points are=20 irrelevant to the points I made. My point is that AIS/FDI gives no=20 information above what is already known - it is only adds complexity = and=20 fault liability. Neither of your points change = this. Andy Andy=20 Reid Chief=20 Network Services Strategist = BT = Innovate            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Office: +44 (0)1277=20 322038 Mobile: +44 (0)7917=20 025451 Fax :      =20 +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com = British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no.=20 1800000 This = electronic=20 message contains information from British Telecommunications plc = which may=20 be privileged or confidential. The information is intended to be for = the use=20 of the individual(s) or entity named above. If you are not the = intended=20 recipient be aware that any disclosure, copying, distribution or use = of the=20 contents of this information is prohibited. If you have received = this=20 electronic message in error, please notify us by telephone or email = (to the=20 numbers or address above) immediately. Activity = and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April 2009 = 20:42 To: Reid,ABD,Andy,CXM = R Cc: = mpls-tp@ietf.org Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path requirements Andy, > = The problem=20 is *not* about a lack of alarm suppression in the data plane - = that=20 information is readily available. I don't = believe=20 that this is a correct statement in a multi-operator transport = network, or=20 in transport networks of one operator that have more then one=20 administrative subdomain (each with its own network management = system). A=20 problem occuring in admin domain A will be unknown in admin domain = B. The=20 loss of continuaity alarms that are activated in admin domain B = due to the=20 fault in admin domain A will appear as primary alarms, suggesting=20 connectivity problems in admin domain B. > = The issue=20 arises because the two sides of maintenance want different things. = The=20 fault fixing > guys=20 want to locate the fault and don't want any other information. The = service=20 maintenance > guys=20 want to know whether their customer service is = working. This is = addressed=20 in SDH, OTN, Ethernet and T-MPLS recommendations by means of the=20 additional SSF alarm. The SSF alarm is for the service guys = telling=20 them that the service was interrupted due to a fault in a server = layer.=20 AIS suppresses the LOC alarm in those cases so that the = maintenance guys=20 don't get triggered and start looking for a fault that is outside = their=20 area. Regards, Maarten From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april = 2009=20 12:14 To:=20 liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path requirements Liu, Allow = me to jump=20 in. You are bringing together two things which are separate and = for which=20 AIS/FDI is no help. Maintenance operations are concerned with two = separate=20 things. 1) =20 Identifying faults in equipment, line plant, and other systems (eg = misconfigurations) and fixing them (equipment=20 maintenance). 2) =20 Identifying the health of end to end connections, especially when = they are=20 directly supporting customer services (service=20 maintenance). The = problem is=20 *not* about a lack of alarm suppression in the data plane - that=20 information is readily available. If, at an end equipment, I have = a good=20 server/section layer and a loss of CC at the client layer, I = *know* the=20 fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if = you=20 think about, if the fault is in the end equipment, it is quite = likely that=20 the fault means it cannot report the traffic loss to the = management=20 system!) The = issue arises=20 because the two sides of maintenance want different things. The = fault=20 fixing guys want to locate the fault and don't want any other = information.=20 The service maintenance guys want to know whether their customer = service=20 is working. This = arose in the=20 early days of SONET/SDH, when the operations guys demanded that = the=20 equipment did *not* suppress the traffic alarm even when AIS was = being=20 received as the service guys want to know about the alarms. The = normal=20 practice is for the equipment to report the alarms = *including* AIS=20 and then a filter is applied in the management system to = suppress=20 alarms to the fault fixing guys. As I'm aware, there are many = different=20 techniques applied for the filtering algorithms, especially when = you=20 consider multiple concurrent faults in a network, however, the = existance=20 of AIS/FDI doesn't add anything to these that's not already known. = In=20 fact, I believe simple time-stamp correlation is one of the = most=20 powerful and widely used techniques. And if the equipment starts = messing=20 up the reporting of loss of CC because it waiting for/persistence=20 checking AIS/FDI, it could end up messing up simple = time-stamp=20 correlation! In = practice, it=20 is often not quite a simple as this, as the service guys like to = be able=20 to 'localise' the fault. However, under most = circumstances, the=20 filter has automatically done this. So localisation you = describe=20 is only when the filter hasn't worked for some = reason. But the = bottom=20 line is, whatever operations process you want to use, AIS/FDI = doesn't=20 add anything other than complexity and fault liability to the = equipment.=20 Remember AIS goes back to the TDM world where you *have to = fill the=20 bit stream with something*. Andy Andy=20 Reid Chief=20 Network Services Strategist=20 BT = Innovate            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Office: +44 (0)1277=20 322038 Mobile: +44 (0)7917=20 025451 Fax :      =20 +44 (0)1277 324015 = Email: =20 andy.bd.reid@bt.com = British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no.=20 1800000 This = electronic=20 message contains information from British Telecommunications plc = which may=20 be privileged or confidential. The information is intended to be = for the=20 use of the individual(s) or entity named above. If you are not the = intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received this electronic message in error, please notify us by = telephone=20 or email (to the numbers or address above) = immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded to secure effective operation and for other lawful = business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To:=20 Harrison,N,Neil,CXM R Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path requirements Neil:=20 thank you for wasting = more time=20 in describling the problems. but I think some of what you said = is no=20 relations with our problem.for me, maybe AIS/FDI functions is no = sense=20 in cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI=20 functions, when there is a defects in a given layer network, it = can=20 cause multiple alarm events to be raised. it is diffcult = for=20 operators to locate and diagnose the faults. though I completely = agree you on=20 adding new things and functions will bring some complexity = . but=20 if we have no functions, it is more complex and difcult for = operators to=20 maintence and administrator the network. so I think every new = functions=20 and things may have positive and negative effects. but we should = consider it very much, don't delete some functions at=20 random. = best=20 regards liu=20 <neil.2.harrison@bt.com>=20 2009-04-21=20 20:30 = =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org> =D6=F7=CC=E2 RE:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Liu, If=20 MPLS-TP is going to be taken seriously as a transport network = (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are=20 these. = 1=20 Provide a transparent client/server = relationship...which=20 means: -=20 all client bits treated equally -=20 client bit ordering preserved -=20 no attempt to infer client symbol (ie sequence of = client=20 bits) meaning and no attempt to change client = symbols -=20 the traffic behaviour of client X must not impact = the=20 performance experienced by client Y=20 A=20 key corollary of the above is that MPLS-TP must only support = proper=20 connections (ie single source constructs)=20 2=20 Since MPLS-TP is a transport network it is not a = top-of-stack=20 network (ie it does not support directly external = message/file/stream=20 applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP = will not=20 have any peer interworking relationship with any other network=20 mode/technology. = =20 Now=20 wrt OAM MPLS-TP is a co-ps mode network. You could argue = this=20 should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether = PBB-TE (also=20 a co-ps mode network) should have FDI/AIS we concluded that on = balance=20 it was not a good idea.....and note that initially I was in = favour of=20 having AIS, but my colleagues provided strong technical = arguments that=20 convinced me otherwise. = =20 AIS/FDI=20 is historically linked to the early PDH co-cs mode layer = networks that=20 used TTL logic. When this died it put out a +5V (all 1s) = signal by=20 default, ie it required no conscious effort to generate = it.....this is=20 key point. Further, in these networks there is a fairly=20 static/long-holding client server relationship. Clearly = this is=20 not true in the cl-ps mode and it's why IETF have never = specified AIS=20 for IP and its why IEEE had the good sense to throw-out AIS in = 802.1ag=20 for Ethernet (though ITU have unwisely IMO retained it in = Y.1731....but=20 I suspect any operator planning to use Ethernet equipment would = always=20 look to IEEE stds and not ITU ones).=20 AIS/FDI=20 and the co-ps mode is debatable. As I noted above, on = balance we=20 considered not a good idea for PBB-TE OAM because it requires a=20 conscious effort to generate it (unlike the co-cs mode) so there = are=20 likely to be scaling problems and its one more thing to go=20 wrong. = You=20 should also have seen me make the point many times in the past = that the=20 always-on defect detection/handling OAM needs to be as = simple/sparse as=20 possible with as little config as possible because we need super = reliability......TCM goes completely against the grain here. = Also=20 note that the OAM required for each of the 3 network modes is = not the=20 same, despite what some claim. = =20 regards,=20 Neil = From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: = BRUNGARD,=20 DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path = requirements Deborah: maybe = what you said=20 is right. but I can't completely agree your opinions. IMO. = mpls-tp is=20 regard as transport network like SDH/SONET. so it should have = AIS/FDI=20 fuctions as SDH/SONET. = do you = think=20 so. best=20 regards liu=20 "BRUNGARD,=20 DEBORAH A, ATTLABS"=20 <dbrungard@att.com>=20 =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org=20 2009-04-20=20 23:47 = =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> =B3=AD=CB=CD mpls-tp@ietf.org =D6=F7=CC=E2 Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements I agree with=20 Neil, it is very questionable the value of AIS/FDI in=20 a packet network- = any mode. It can=20 result in a DoS attack by an operator on themselves so even Y1731 recommends not = to block data=20 frames: "A MEP can = decide whether it=20 blocks data frames when it detects = dAIS. The principle = requirement that=20 influences this decision is that data frames ought to be=20 forwarded as much = as possible,=20 without the = possibility of forwarding=20 wrong data frames downstream." Table=20 I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used = under very=20 constrained architectures - if required=20 for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point = and server/client=20 one-to-one: "for a = point-to-point ETH=20 connection, a MEP has only a single peer = MEP. Therefore, there is no=20 ambiguity regarding the peer MEP for which it should=20 suppress alarms = when it receives=20 the ETH-AIS=20 information." So = should only be within=20 one domain - then no need. Deborah -----Original=20 Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of = Maarten=20 Vissers Sent: = Monday, April 20, 2009=20 10:05 AM To:=20 neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 Associated bidirectional transport path requirements Neil, > but AIS/FDI in=20 the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a = necessity. And you=20 will not be able to understand that as long as you = refuse to accept that=20 "cl-mode" is = a forwarding mode within a **transport = entity**. G.800 amendment 1=20 has finally reintroduced this transport entity into = G.800. Besides that, it=20 also introduced the = **differentiated=20 connection**: [G.800 am1] "A=20 differentiated connection is a transport entity=20 that transfers = information belonging to=20 multiple communications between ports across a subnetwork. <..> In a = differentiated connection=20 message contents are interpreted to=20 identify (sets of) communications which = receive different treatment. The=20 sets of communications may be distinguished by=20 the forwarding = identifier or other=20 layer information. Order is not necessarily preserved between=20 messages belonging to sets of communications=20 receiving different = treatment.=20 Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving = communication message=20 order." Ethernet VLANs are in=20 terms of G.800 "differentiated = connections". Ethernet AIS provides AIS=20 within the scope of such "differentiated=20 connection". If you apply this to my=20 proposed PTN layer stack, then the EVC = layer topology will consists of EVC=20 links supported by MPLS-TP, Ethernet, PBB-TE=20 and P-OTN VP trails inside metro and core domains = interconnecting EVC=20 matrices. When one of those EVC links is interrupted, e.g. = in the core between=20 metro 1 and metro 4 (see attached slide), then the EVC = differentiated=20 connection that=20 is present on this = link will be=20 interrupted. At the EVC switch/bridge = node in metro 4 this interruption is=20 noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC = alarms at EVC=20 endpoints D4 and D5. The EVC-AIS (i.e.=20 Ethernet AIS) frame has a reserved multicast=20 address, which = guarantees that the AIS=20 is broadcast to the endpoints of the = EVC. I believe that it is time for you to adapt = your view on co and=20 cl modes and relate it to the forwarding mode **INSIDE** = a transport entity.=20 What we know = as the internet is=20 essentially an "IP differentiated connection" with a billion or more=20 ports. What we know = as an IP VPN is=20 essentially an "IP differentiated connection" with e.g. n ports=20 (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is = essentially an=20 "Ethernet differentiated connection" with=20 n ports (n in the range of e.g. 2 to = 1000). What we know as a p2p MPLS E-LSP is = essentially an "MPLS=20 differentiated connection" with 2=20 ports. What we know = as a p2p SDH VC-n=20 is a "SDH VC-n connection" with 2 = ports. Transport network OAM applies to transport = entities, which are=20 (in terms of G.800 am1) connections and differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From:=20 neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 = april 2009=20 22:00 To: = John.E.Drake2@boeing.com;=20 Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp]=20 Associated bidirectional transport path requirements John,=20 Thanks this is a great platform to explain why OAM for the = 3 network modes needs to be different. I am = getting a wee bit tired=20 of folks trying to make all 3 network=20 modes look alike (and then, even worse,=20 interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how=20 silly can we get?). I am even more frustrated=20 by the fact those = peddling this FUD=20 only ever seem to consider OAM and forget all other DP/CP/MP=20 components (esp top-of-stack=20 message/file/stream application=20 adaptations). How wrong can this get!=20 In the co = modes a *connection* is=20 a very specific and *constraining* construct.....I am assuming here we respect = the rules of a=20 connection (ie single source) though some folks don't even = bother to respect=20 this, and this is despite the fact that we all know what = problems=20 multiple-source constructs can cause=20 (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts = *all* DP (ie traffic=20 and OAM) to stay within the bounds of the connection. = Which is fine=20 under defect-free conditions, but if=20 we have leaking traffic then the constraining=20 nature of the connection construct is broken. In = a nutshell what=20 this means is that OAM that is of a=20 request/response nature cannot be trusted in co=20 mode networks under = misconnectivity=20 defects.....indeed, why should a = leaking DP have a symmetric go/return=20 defect behaviour?....very likely it = won't. So whilst request/response OAM=20 is right for the cl mode it is not right = for the co mode under=20 misconnectivity defect conditions. More generally the 3 modes are different and = not just in=20 OAM requirements....but AIS/FDI in the=20 cl mode?...do me a favour!...at least IEEE had the good sense to bin this for = Ethernet even though it=20 remains in Y.1731. And which is why I often = trot-out the rather silly=20 (to have to say this) observation that if=20 IP (cl mode) could do it all then why = have IETF found it necessary to=20 create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer = lies in the=20 physics...and G.800 attempts to explain = that physics....G.805 does = not. So, the 3 modes are different...please = accept/rejoice in this=20 fact as they all offer something different/important. = But do not be=20 hoodwinked by those who peddle a story that=20 that tries to make the OAM of the 3 modes = the same. regards, Neil=20 > = -----Original=20 Message----- > = From:=20 mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > Sent: 17 = April 2009=20 20:02 > To: BUSI = ITALO; Alexander=20 Vainshtein; Maarten Vissers > Cc:=20 mpls-tp@ietf.org > Subject: Re:=20 [mpls-tp] Associated bidirectional transport path=20 >=20 requirements >=20 > = Italo, > > As described in the=20 MPLS TP OAM Requirements I-D, virtually all of=20 the > OAM = functions require a=20 return path, and in the absence of a return = > path they are = disabled. > > As described in=20 David Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no >=20 tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is = used, an=20 > MPLS TP = network needs to be=20 capable of getting IP packets from > destination to source; neither the = minutes nor I stipulate=20 that a > = control plane needs to be=20 used to instantiate this forwarding. > > As an aside, the=20 issue of return path for unidirectional LSPs could=20 be > = charaterized as the=20 elephant in the room. In the MPLS TP OAM = > Framework I-D, unicast LSPs are only = mentioned three times=20 and return > = paths not at=20 all. > = > Thanks, >=20 > = John > > -----Original = Message----- > > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59=20 AM > > To: = Drake, John E;=20 Alexander Vainshtein; Maarten Vissers > > Cc: = mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path > >=20 requirements > = >=20 > >=20 John, > >=20 > > I might = have missed the=20 agreement of MPLS-TP being capable of > > sending replies to OAM requests = sent on=20 uni-directional LSPs. > >=20 > > This = requirement does not=20 belong to the first set of requirements = > > ITU-T is expecting to be met by=20 October. > >=20 > > However, = I think this in a=20 potential interesting additional >=20 > requirement to be taken into account (at worst in=20 a > subsequent=20 phase). > >=20 > > I think = that this=20 requirement needs to be evaluated versus other = > > more important requirements (e.g. = the possibility to=20 work w/o IP > = > forwarding and=20 the need for OAM to continue to monitor the data=20 > > plane = also in case of=20 failures affecting the control or management = > > plane). > >=20 > > I am = open to discuss it but=20 not sure this is the right time because = > > I wish to avoid delaying the first = phase of the design=20 solution. > > = > > Thanks,=20 Italo > >=20 > > > = -----Original=20 Message----- > = > > From:=20 mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > > > = Sent: Thursday, April=20 16, 2009 8:00 PM > > > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc: = mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated bidirectional=20 transport path > > >=20 requirements > = > >=20 > > > At = the meeting last=20 fall at Juniper in Massachusetts,=20 I > > think = it=20 was > > > = agreed that an MPLS=20 TP network needs to have a forwarding > > = capability > >=20 > for management, control, and OAM packets (e.g.,=20 sending > > = replies to=20 OAM > > > = requests sent on=20 uni-directional LSPs) even if it does = not > > have an = IP > >=20 > forwarding data plane. > >=20 > > > = > > -----Original=20 Message----- > = > > > From:=20 Alexander Vainshtein > > >=20 = [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April = 16, 2009 9:57=20 AM > > > = > To: Maarten=20 Vissers > > = > > Cc:=20 mpls-tp@ietf.org > > > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > = >=20 requirements > = > > >=20 > > > = >=20 Maarten, > > = > > It seems=20 that you've just (implicitly and, = probably, > > > > inadvertently) stated = the=20 following: > = > > >=20 > > > = > =20 MPLS-TP OAM will = not=20 ever support MIP loopback function >=20 > (and fault > > > >=20 localization which requires this function ) = for > > unidirectional = P2MP > > > > and P2P = paths. > > > > = > >=20 > > If this statement is correct, this (IMHO and=20 FWIW) > raises a = valid > > = > >=20 question: > > = > >=20 > > > = > =20 Is MPLS-TP an=20 appropriate solution for these >=20 types of transport > > > >=20 paths? > > = > >=20 > > > = > For the reference,=20 IP/MPLS provides this kind of > >=20 functionality today > > > >=20 for (unidirectional - but it does not know any=20 other > > = type) P2P=20 LSPs > > > = > as described=20 in RFC 4379. And its extension to P2MP LSPs seems=20 > > > = >=20 easy... > > = > >=20 > > > = >=20 > > = > >=20 > > > = >=20 Regards, > > = > >=20 > > > = > =20 Sasha > = > > >=20 > > > = >=20 > > > = >=20 > > > = >=20 = ________________________________________ > > > > From: = mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > = > > Of Maarten=20 Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April = 16, 2009 3:24=20 PM > > > = > To:=20 'Adrian=20 Farrel' > > >=20 > Cc: mpls-tp@ietf.org > >=20 > > Subject: Re: [mpls-tp] Associated bidirectional = transport path=20 > > > = >=20 requirements > = > > >=20 > > > = > Adrian, > > > > = > >=20 > > >> <quote> >=20 > > > >> The intermediate = nodes=20 (including MEPs, MIPs and > >=20 > > other internal > > >=20 > >> functions as appropriate) of = a=20 co-routed > > = > >=20 bidirectional transport > > >=20 > >> path at each (sub-)layer MUST = be=20 aware of the pairing > > >=20 > >> relationship of the forward = and the=20 backward > > = > > directions=20 of that > > = > > >>=20 transport path. > > > > >> <end=20 quote> > > = > >=20 > > > > = > > There is=20 no way this is a functional requirement. = That > > > is, there = is > > > > > *nothing* that can = be observed from a=20 black box point of > > > view=20 that > > > = > > results=20 from adhering to this requirement. >=20 > > > > > > >=20 Your understanding is not correct. It is very=20 much > = observable=20 if > > > = > this requirement=20 is met from a black box point of view. > > > > The MIP functions can = only perform the=20 Loopback when there is a > >=20 > > co-routed bidirectional transport path. The MPLS-TP = LBM packet=20 > > > = > received at a MIP=20 needs to be returned (as LBR > >=20 > > packet) to the originating MEP function via the=20 other > > = direction=20 of > > > = > the co-routed=20 bidirectional transport path. This = other > direction > > >=20 > would not be available in an associated bidirectional = transport=20 > > > = > path... and thus=20 the loopback test > > > would=20 fail. > > = > >=20 > > > = > Similarly, when we=20 have to apply TCM MEPs to monitor a > > segment, = then >=20 > > > this is possible in a co-routed bidir transport=20 path > but not = in=20 a > > > = > associated bidir=20 transport path. In the first case the TCM MEP = > > > > Source and Sink = functions are co-located and=20 can > exchange = what=20 is > > > = > called "remote=20 information" which is necessary for performance=20 > > > = >=20 monitoring. > = > > > In the=20 latter case the TCM MEP Source and Sink=20 functions > > = are in e.g.=20 > > > = > different nodes in=20 the network and TCM would not be able > > to = provide > >=20 > > performance monitoring. >=20 > > > > > > >=20 > The entirety of the bracketted text "(including=20 MEPs, > > = > MIPs and=20 other > > = > >=20 internal > > = > > >=20 functions as appropriate)" should be deleted. It does=20 not > > > = > add to=20 "The > > > = > >=20 intermediate nodes." > > >=20 > > > = > > Your=20 understanding is not correct. This text must not=20 be > > = deleted=20 at > > > = >=20 all. > > > = >=20 > > > = > > Actually, I=20 am quite fed up about this persistent > > > insistence on = the > > > > = inclusion > > > > > of "Tandem = Connection." The definition=20 within the ITU-T of > > > >=20 this term > > = > > >=20 is > > > = >=20 poorly > > = > > >=20 specified and comes from the monitoring of a path that=20 is > > > = > parallel=20 (i.e. > > = > >=20 tandem) > > = > > > to the=20 data path being monitored. This definition of=20 TC > > > = > seems to be=20 at > > > = >=20 variance, > > = > > > and=20 would be if the ACH was actually in = band. > > > > = > >=20 > > I don't understand where your interpretation of=20 tandem > > = connection=20 is > > > = > described in=20 ITU-T recommendations. I.e. "from the > > monitoring of = a >=20 > > > path that is parallel (i.e. tandem) to the data = path=20 being > > = > >=20 monitored."? > = > > >=20 > > > = > There is a=20 "network connection" and this network > > connection is a = set > > > > of interconnected "link = connections" and=20 "matrix > = connections".=20 A > > > = > subset of those=20 interconnected link connections and matrix = > > > > connections can be = monitored and is then=20 referred to as > = a=20 "tandem > > = > >=20 connection". There is no "path that is parallel to=20 the > > data = path".=20 > > > = > There is only=20 additional OAM inserted inside the data > path by the > > >=20 > TCM MEP_So function and this OAM is extracted from=20 the > > data = path=20 by > > > = > the TCM MEP_Sk=20 function. > > = > >=20 > > > = >=20 Regards, > > = > >=20 Maarten > > = > >=20 > > > = >=20 > > > = > -----Original=20 Message----- > = > > > From:=20 mpls-tp-bounces@ietf.org > > >=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Adrian = Farrel > > > > Sent: donderdag 16 april = 2009=20 11:59 > > = > > To: Alexander=20 Vainshtein; = benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO;=20 mpls-tp@ietf.org > > > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > = >=20 requirements > = > > >=20 > > > = > Hi=20 Sasha, > > = > >=20 > > > = > > Unfortunately=20 I cannot fully agree with your = statement: > > > > = > >=20 > > > > <quote> >=20 > > > > From the point of view of = hardware,=20 co-routed > > = > bidirectional=20 LSPs > > > = > > =20 are a special case of associated bidirectional=20 LSPs. > > = > > > <end=20 quote> > > = > >=20 > > > > = > > This=20 statement would be obviously correct, were it not=20 for > > > = >=20 Requirement > = > > > >=20 34 = in the latest=20 MPLS-TP requirements draft > >=20 > > > = > > > OK. Got=20 it. > > > = >=20 > > > = > But what is this=20 doing in the data plane requirements = section? > > > > = > >=20 > > In fact, what is this requirement actually=20 saying? > > = > >=20 > > > = > >=20 <quote> > = > > > >=20 The intermediate nodes (including MEPs, MIPs = and > > > = other=20 internal > > = > > >=20 functions as appropriate) of a=20 co-routed > > = > >=20 bidirectional transport > > >=20 > > path at each (sub-)layer MUST be = aware of=20 the pairing > = > > > >=20 relationship of the forward and the=20 backward > > = > > directions=20 of that > > = > > > =20 transport path. > >=20 > > > <end quote> >=20 > > > > > > >=20 There is no way this is a functional requirement.=20 That > > is, = there=20 is > > > = > *nothing* that=20 can be observed from a black box point = of > > view that > >=20 > > results from adhering to this=20 requirement. > = > > >=20 > > > = > Therefore it could=20 be assumed that this requirement is met by = > > > > configuring some data = plane database=20 component through the > > >=20 > management plane. The database component is not=20 used > for=20 anything > > = > > except to=20 satisfy this requirement for = "awareness". > > > > = > >=20 > > Ben! Can we please try to rewrite this requirement in = terms of=20 > > > = >=20 behavior? > > = > >=20 > > > = > > Please note=20 that Requirement 34 is the ONLY item in = the > > > > list that = is > > > > > specific for = co-routed bidirectional=20 LSPs. (The pairing > > > >=20 requirements > = > > > >=20 at end points for co-routed and associated=20 bidirectional > = > > paths=20 are > > > = > > exactly=20 the same even if they appear in two = different > > > items in = the > > > > > requirements'=20 list). > > = > > > In=20 other words, without Requirement 34 the notion=20 of >=20 co-routed > > = > > >=20 bidirectional paths would be void of any data plane=20 content. > > = > >=20 > > > > = > > The=20 somewhat vague scope of this requirement ("other internal=20 > > > = > > functions as=20 appropriate") creates a suspicion that = HW > > > > support of = the > > > > > pairing awareness = may be required in=20 order to comply with it. > > >=20 > > > = > > The entirety=20 of the bracketted text "(including = MEPs, > > MIPs and = other >=20 > > > internal functions as appropriate)" should be = deleted.=20 It > > does=20 not > > > = > add to "The=20 intermediate nodes." > > >=20 > > > = > > > The=20 following text in the draft increases this=20 suspicion: > = > > >=20 > > > > = > >=20 <quote> > = > > > >=20 Tandem Connection: A tandem connection is=20 an > > = arbitrary part of=20 a > > > = > > =20 transport path that can be monitored (via = OAM) > > > > independently from=20 the > > > = > > =20 end-to-end monitoring (OAM). It may be a=20 monitored > > = segment or=20 a > > > = > > =20 monitored concatenated segment of a transport path.=20 > > = The=20 tandem > > = > > > =20 connection may also include the forwarding engine(s)=20 of > > > = > the=20 node(s) > > = > > > =20 at the edge(s) of the segment or concatenated=20 segment. > > = > > >=20 <end quote> > > > >=20 > > > = > Actually, I am=20 quite fed up about this persistent >=20 > insistence on the > > >=20 > inclusion of "Tandem Connection." The definition=20 within > > = the ITU-T=20 of > > > = > this term is=20 poorly specified and comes from the > monitoring of = a > >=20 > > path that is parallel (i.e. tandem) to the data path = being=20 > > > = > monitored. This=20 definition of TC seems to be at = variance, > > and would > >=20 > > be if the ACH was actually in = band. > > > > = > >=20 > > > Doesn't "forwarding engine" sound like hardware = to=20 you? > > > = >=20 > > > = > Yes, but so=20 what? > > = > >=20 > > > = > > IMHO it is=20 worth noting that neither the MPLS-TP > > > Requirements = draft > > > > > nor the MPLS-TP OAM = requirements=20 one > > > = > >=20 > > > = >=20 > > >=20 > > = >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain = any requirements=20 dealing with tandem > > >=20 connections. > = > > >=20 > > > > = > > But=20 tandem connections are discussed in the MPLS-TP=20 OAM > >=20 Framework > > = > > >=20 draft > > = > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > = amework-00.txt > > > > = ). >=20 > > > > > > >=20 Right. > > = > > Let's just=20 get rid of an unnecessary term and bring = all > the I-Ds > > >=20 > into line. > > > >=20 > > > = > > The bottom=20 line, IMHO, is that some clarity = regarding > > > co-routed = vs. > > > > > = associated > > > > > bidirectional paths = is still required.=20 One way to provide > > > >=20 that could > = > > > > be=20 by explicitly limiting Requirement 34 to=20 specific > > = >=20 functionality. > = > > >=20 > > > = >=20 Agreed. > > = > >=20 > > > = > Adrian > > > > = > >=20 > > > = > > >=20 > > > = >=20 > > > = >=20 = ________________________________________ > > > > From: Adrian=20 Farrel = [adrian@olddog.co.uk] > > > > Sent: Thursday, April = 16, 2009 12:13=20 AM > > > = > To: Alexander=20 Vainshtein; Lou Berger; BUSI ITALO >=20 > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > >=20 > > requirements > > >=20 > > > = > > Hi=20 Sasha, > > = > >=20 > > > = > Not really sure=20 whether you are misrepresenting anyone, = but... > > > > = > >=20 > > > 1. My reading of one of Ben's = messages is=20 that associated > > > >=20 > bidirectional paths are the only types of paths that can=20 be > > > = > created=20 in > > > = > > the=20 existing networks; "true" co-routed bidirectional=20 paths > > = > > will=20 have > > > = > > to wait=20 until (if ever) new equipment becomes=20 available. > = > > >=20 > > > = > This is clearly=20 nonsense! > > = > > From the=20 point of view of hardware, co-routed > > bidirectional LSPs = are > > > > a special case of = associated bidirectional=20 LSPs. > > = > >=20 > > > = > If you can set up=20 two unidirectional LSPs (e.g. using the > > = management > >=20 > > plane) you can surely set up a=20 co-routed > > = > bidirectional=20 LSP. > > > = >=20 > > > = > There are shipping=20 solutions that achieve co-routed >=20 bidirectional > = > > > LSPs=20 using the control plane. These either use the=20 GMPLS > > = (which=20 is > > > = > cleaner) or=20 non-standard proprietary solutions (which = is > > messy but > >=20 > > functional). > > >=20 > > > = > > But (of=20 course) the management plane or control = plane > > solutions = have >=20 > > > nothing to do with availability of equipment as=20 they > are=20 software > > = > >=20 solutions. > = > > >=20 > > > = > > 2. My reading=20 of one of Neil's messages is that the = actual > > > > driver = for > > > > > co-routed = bidirectional paths may be=20 experience with existing > >=20 > > > transport networks rather than any specific=20 benefit. > > = > >=20 > > > = > Isn't that the=20 case with 75% of the MPLS-TP = requirements? > > > > Which is not to say it = is a bad=20 thing. > > = > >=20 > > > = > A large driver for=20 MPLS-TP is to give the packet network > > the look, > >=20 > > feel, and behavioral characteristics of a=20 "legacy" > > = > > transport=20 network. > > = > >=20 > > > = > > Based on=20 these observations, I'd guess (FWIW) = that: > > > > > * associated = bidirectional paths are,=20 at least for the time > > >=20 > > being, the most important type of = bidirectional=20 paths in > > = > > >=20 MPLS-TP > > >=20 > > > = > > I think that=20 is wrong both given my statement above, = and > > given = that > >=20 > > other upgrades to existing MPLS solutions will=20 be > needed to=20 reach > > = > > the full=20 function level of MPLS-TP. > >=20 > > > = > > > > *=20 they had a good chance to remain the only type=20 of > >=20 bidirectional > = > > > >=20 paths in real deployments. > > > > = > >=20 > > I don't see what that follows = from. > > > > = > >=20 > > Cheers, > > > >=20 Adrian > > > > = > >=20 > >=20 = _______________________________________________ > > > > mpls-tp mailing=20 list > > > = >=20 mpls-tp@ietf.org > > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > = > >=20 > >=20 = _______________________________________________ > > > > mpls-tp mailing=20 list > > > = >=20 mpls-tp@ietf.org > > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > = > >=20 > > > = > >=20 = _______________________________________________ > > > mpls-tp mailing = list > > > = mpls-tp@ietf.org > > >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 >=20 = _______________________________________________ > mpls-tp mailing = list >=20 mpls-tp@ietf.org >=20 = https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp<= /TT> -----------------------------------------------------= --- ZTE Information Security Notice: The = information contained in=20 this mail is solely property of the sender's organization. This = mail=20 communication is confidential. Recipients named above are = obligated to=20 maintain secrecy and are not permitted to disclose the contents = of this=20 communication to others. This email and=20 any files transmitted with it are confidential and intended = solely for=20 the use of the individual or entity to whom they are addressed. = If you=20 have received this email in error please notify the originator = of the=20 message. Any views expressed in this message are those of the = individual=20 sender. This = message has been scanned=20 for viruses and Spam by ZTE Anti-Spam=20 = system. --------------------------------------------------------= ZTE Information Security Notice: The infor= mation contained in this mail is solely&nbs= p;property of the sender's organization. This&nb= sp;mail communication is confidential. Recipients&nbs= p;named above are obligated to maintain sec= recy and are not permitted to disclose = ;the contents of this communication to othe= rs. This email and any files transmitted = with it are confidential and intended solel= y for the use of the individual or&nbs= p;entity to whom they are addressed. If&nbs= p;you have received this email in error&nbs= p;please notify the originator of the messa= ge. Any views expressed in this message&nbs= p;are those of the individual sender.= This message has been scanned for vir= uses and Spam by ZTE Anti-Spam system.= ------_=_NextPart_001_01C9C760.79BEE6BF-- From Italo.Busi@alcatel-lucent.it Mon Apr 27 10:51:23 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECEC3A6A8B for ; Mon, 27 Apr 2009 10:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.396 X-Spam-Level: X-Spam-Status: No, score=0.396 tagged_above=-999 required=5 tests=[AWL=-5.406, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8QiIhV8+5BY for ; Mon, 27 Apr 2009 10:51:16 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id BCE693A6F31 for ; Mon, 27 Apr 2009 10:51:14 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3RHqIE9021905; Mon, 27 Apr 2009 19:52:18 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 19:52:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C760.E80352B5" Date: Mon, 27 Apr 2009 19:52:14 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB40220ED1D@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AIS/FDI (was [mpls-tp] Associated bidirectional transport path requirements) thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gAADv3tAAAoqbLA= References: <002a01c9c733$92015470$6c02a8c0@china.huawei.com> From: "BUSI ITALO" To: , X-OriginalArrivalTime: 27 Apr 2009 17:52:18.0530 (UTC) FILETIME=[E852D420:01C9C760] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 17:51:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C760.E80352B5 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Andy, =20 the key point is that you configure on which existing connections (and = not on which labels) you have to generate AIS/FDI. As a consequence you = cannot configure AIS generation on a label that is associated with a = connection that it is not faulty. =20 If AIS/FDI is enabled by default, than it is your conscious decision to = disable it and to live without the feature. =20 Italo ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: Monday, April 27, 2009 2:59 PM To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 Snipped =20 "AIS generation is performed in the adaptation sink function for the = set of active client signals; i.e. for the set of connection/flow points = that are activated on the adaptation sink function (which are = represented by the set of active labels/VIDs/...)." =20 In your words, the adaptation sink function contains a set of label = values, one for each client connection. Different words, same thing. = This is a list of label values which requires configuration if it is to = be used for the injection of AIS and could be configured wrongly. It's = the same thing even in your ITU-T speak. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 27 April 2009 13:28 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 I have the impression that you do not have the correct understanding = of the SNC protection switching fucntional models and the location and = control of AIS insertion. Your understanding seems not aligned with the = specifications in our equipment and protection swithcing = recommendations. See inline... ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 12:50 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 It is of course true that adding a boolean input to a logical system = increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you = identify below. There are=20 =20 - good CC, no AIS =09 - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these = input states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly.=20 =20 [mv] I don't think that there is only "hope". This condition reflects = that there is no disconnect.=20 If every frame/packet arrives correctly is not checked by the = reception of CC and correct MEGID/MEPID. Frame/packet loss is checked by = the frame/packet loss measurement that is embedded in the CCM frames, = and can be activated.=20 =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is = because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below).=20 =20 [mv] With equipment that complies with the equipment standards this = condition doesn't give you just "hope". It gives you "knowledge" that = the discontinutity experienced in the connection is due to a server = layer fault.=20 =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS = forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending = on the exact scope of the forwarding labels, a protection switch may = well require the proactive purging of entries from the AIS forwarding = label injection table following the protection switch (this could = equivalently been seen as the forwarding function proactively dropping = the AIS packets).=20 =20 [mv] I don't think that those scenarios are likely scenarios. = Equipment compliant with ITU-T's equipment recommendations will not have = those scenarios. Only equipment that does not comply with those = equipment recommendations could have such scenarios. Just do not deploy = such equipment. =20 [mv] The AIS insertion in the functional models is performed in the = Adaptation Sink functions. Those Adaptation Sink functions are connected = to the Connection function in which the SNC Protection process is = located. The AIS insertion in an Adaptation sink fucntion continues = independent of the state of the protection switch process in the = Connection function; i.e. the selector in the protection process will = only receive frames/packets from either the working SNC, or the = protection SNC (but never from both).=20 =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a = forwarding function. But it could equally arise from a misconfiguration = of the AIS forwarding label injection table. In fact, the latter = actually seems just as likely and particularly problematic for = maintenance. Unlike normal forwarding, any mismatch between the = forwarding configuration and the AIS forwarding label injection table = will lie dormant and until a server fault arises. Then this generates a = false and misunderstood fault condition with maintenance looking for the = fault in the wrong place.=20 =20 [mv] As indicated in the above comment, equipment compliant with the = equipment and protection switching recommendation will not behave as you = suggest. Only equipment not-compliant with our equipment/protection = switching recommendation may do this, but such equipment should simply = not be deployed. =20 [mv] AIS generation is performed in the adaptation sink function for = the set of active client signals; i.e. for the set of connection/flow = points that are activated on the adaptation sink function (which are = represented by the set of active labels/VIDs/...). There is no "AIS = forwarding label injection table" in any of our equipment = recommendations. AIS will be generated for each client CI output on the = set of CPs/FPs on the adaptation sink function when aAIS consequent = action condition is true. =20 =20 The first two states can be reliably diagnosed with CC alone. The = second two arise from the introduction of the AIS/FDI. However, any = possible benefit that might arise is completely masked by the fact that = the AIS itself must be configured and there is no reason for this to be = more reliable than what it is supposed to be monitoring. Indeed, there = seems good reason to think that it will be less reliable.=20 =20 [mv] You are turning things upside down... CC is present to detect = continuity and connectivity problems introduced in the layer network's = Connection functions. As such you can not diagnose the second state with = CC alone. With CC alone one of your colleagues will be requested to = initiate a number of Loopback tests to find out which connection = function is misconfigured. This is the wrong action of course, as there = is a server layer fault. =20 [mv] You do not understand the AIS "configuration" aspect. AIS = generation configuration is on the node, not on each individual = connection. Networks that deploy AIS have it active on all their NNIs.=20 =20 There is no avoiding that AIS in circuit switching is fundamentally = different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something = and the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured.=20 =20 [mv] In packet transport networks with connectivity checking no = packets is not a valid condition.=20 =20 [mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require = any individual client connection specific information.=20 =20 [mv] ATM VP AIS and ATM VC AIS does not require any individual client = (i.e. VP, VC) connection specific information.=20 =20 [mv] ETH AIS does not require any individual client connection = identification specification, but it requires reuse of the client MEG = Level information which is also required for the ETH MIP functions on = the interface port. =20 [mv] I.e. AIS insertion does not require individual client connection = specific information. Either no additional information at all is = required, or additional information is required that is shared with = other fucntions/processes in the interface. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the = operational systems and processes are the same.=20 =20 [mv] And that is exactly what we do with support of AIS in packet = transport networks (ATM, Ethernet, T-MPLS =3D> MPLS-TP).=20 =20 The simple CC replicates all the triggers to management systems made = by SONET/SDH and gives maximum compatibility. Conversely, the inclusion = of data plane AIS requires a whole new area of configuration and = generates a whole new set of fault conditions which cannot be localised = by SONET/SDH processes. So, ironically, packet AIS is directly opposed = to backwards compatibility you claim is the main drive.=20 =20 [mv] I hope that you now understand that it is the opposite case is = that is present. Simple CC does **not** replicates all triggers... AIS = is needed in addition. =20 Regards, Maarten =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of = continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a = connection function (fabric) in the connection, which interrupts the = forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is = supported. It requires that the organization responsible for the layer = network takes action (i.e. locate the layer's connection function that = includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such = connection (due to a fault in a server layer) will also interrupt the = forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient = information to determine if the configuration in the layer's connection = functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. = This server layer fault is already reported by the server layer MEP = detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer = network fault (i.e. continuity fault). Fault localization must be = started to locate the misconfigured or failed connection function. Once = this faulty connection function is located, the configuration fault (or = hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in = both fault cases is however registered as part of performance = monitoring. This performance monitoring information is used to verify = the performance against the SLA for the connection. =20 Regards, Maarten =09 =09 ________________________________ From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only = adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system = is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network = management system). A problem occuring in admin domain A will be unknown = in admin domain B. The loss of continuaity alarms that are activated in = admin domain B due to the fault in admin domain A will appear as primary = alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want = different things. The fault fixing > guys want to locate the fault and don't want any other = information. The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations = by means of the additional SSF alarm. The SSF alarm is for the service = guys telling them that the service was interrupted due to a fault in a = server layer. AIS suppresses the LOC alarm in those cases so that the = maintenance guys don't get triggered and start looking for a fault that = is outside their area. =20 Regards, Maarten =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are = concerned with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems = (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially = when they are directly supporting customer services (service = maintenance). =20 The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. If, at an end equipment, = I have a good server/section layer and a loss of CC at the client layer, = I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. = (Indeed, if you think about, if the fault is in the end equipment, it is = quite likely that the fault means it cannot report the traffic loss to = the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want = any other information. The service maintenance guys want to know whether = their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even = when AIS was being received as the service guys want to know about the = alarms. The normal practice is for the equipment to report the alarms = *including* AIS and then a filter is applied in the management system to = suppress alarms to the fault fixing guys. As I'm aware, there are many = different techniques applied for the filtering algorithms, especially = when you consider multiple concurrent faults in a network, however, the = existance of AIS/FDI doesn't add anything to these that's not already = known. In fact, I believe simple time-stamp correlation is one of the = most powerful and widely used techniques. And if the equipment starts = messing up the reporting of loss of CC because it waiting = for/persistence checking AIS/FDI, it could end up messing up simple = time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service = guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation = you describe is only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability = to the equipment. Remember AIS goes back to the TDM world where you = *have to fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 = =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 =09 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity = named above. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately. Activity and use of the British Telecommunications plc email system = is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Neil:=20 thank you for wasting more time in describling the problems. but = I think some of what you said is no relations with our problem.for me, = maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS = networks.if there is no AIS/FDI functions, when there is a defects in a = given layer network, it can cause multiple alarm events to be raised. it = is diffcult for operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions = will bring some complexity . but if we have no functions, it is more = complex and difcult for operators to maintence and administrator the = network. so I think every new functions and things may have positive and = negative effects. but we should consider it very much, don't delete some = functions at random.=20 =09 =09 best regards=20 liu=20 =09 =09 =09 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements=09 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network = (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which = means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the = performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support = proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP will not have = any peer interworking relationship with any other network = mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly = questionable. When I and colleagues discussed whether PBB-TE (also a = co-ps mode network) should have FDI/AIS we concluded that on balance it = was not a good idea.....and note that initially I was in favour of = having AIS, but my colleagues provided strong technical arguments that = convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) = signal by default, ie it required no conscious effort to generate = it.....this is key point. Further, in these networks there is a fairly = static/long-holding client server relationship. Clearly this is not = true in the cl-ps mode and it's why IETF have never specified AIS for IP = and its why IEEE had the good sense to throw-out AIS in 802.1ag for = Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I = suspect any operator planning to use Ethernet equipment would always = look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on = balance we considered not a good idea for PBB-TE OAM because it requires = a conscious effort to generate it (unlike the co-cs mode) so there are = likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past = that the always-on defect detection/handling OAM needs to be as = simple/sparse as possible with as little config as possible because we = need super reliability......TCM goes completely against the grain here. = Also note that the OAM required for each of the 3 network modes is not = the same, despite what some claim.=20 =20 regards, Neil=20 =20 =09 =09 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =09 =09 Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so = it should have AIS/FDI fuctions as SDH/SONET.=20 =09 do you think so.=20 =09 best regards=20 liu=20 =09 =09 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements=09 =09 =09 =09 =09 I agree with Neil, it is very questionable the value of AIS/FDI in = a packet network- any mode. It can result in a DoS attack by an = operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects = dAIS. The principle requirement that influences this decision is that data frames ought to be = forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. =09 And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client = one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer = MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. =09 Deborah =09 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements =09 Neil, =09 > but AIS/FDI in the cl mode?...do me a favour! =09 Ethernet AIS is indeed a requirement and a necessity. And you will = not be able to understand that as long as you refuse to accept that = "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 = has finally reintroduced this transport entity into G.800. Besides that, it = also introduced the **differentiated connection**: =09 [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between = ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications = receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message = order." =09 =09 Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated = connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE = and P-OTN VP trails inside metro and core domains interconnecting EVC = matrices. When one of those EVC links is interrupted, e.g. in the core between = metro 1 and metro 4 (see attached slide), then the EVC differentiated = connection that is present on this link will be interrupted. At the EVC switch/bridge = node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC = endpoints D4 and D5. =09 The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast = address, which guarantees that the AIS is broadcast to the endpoints of the = EVC. =09 I believe that it is time for you to adapt your view on co and cl = modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 =09 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS = differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 = ports. =09 Transport network OAM applies to transport entities, which are (in = terms of G.800 am1) connections and differentiated connections. =09 Regards, Maarten =09 -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements =09 John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, = interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more = frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 =09 In the co modes a *connection* is a very specific and = *constraining* construct.....I am assuming here we respect the rules of a = connection (ie single source) though some folks don't even bother to respect this, = and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). =09 When we have a connection this restricts *all* DP (ie traffic and = OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining = nature of the connection construct is broken. In a nutshell what this means = is that OAM that is of a request/response nature cannot be trusted in co = mode networks under misconnectivity defects.....indeed, why should a = leaking DP have a symmetric go/return defect behaviour?....very likely it = won't. So whilst request/response OAM is right for the cl mode it is not = right for the co mode under misconnectivity defect conditions. =09 More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at = least IEEE had the good sense to bin this for Ethernet even though it = remains in Y.1731. And which is why I often trot-out the rather silly (to = have to say this) observation that if IP (cl mode) could do it all then why = have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). = The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. =09 So, the 3 modes are different...please accept/rejoice in this fact = as they all offer something different/important. But do not be hoodwinked = by those who peddle a story that that tries to make the OAM of the 3 modes = the same.=20 =09 regards, Neil=20 =09 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all = of the =09 > OAM functions require a return path, and in the absence of a = return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is = used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a = > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs = could be =09 > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and = return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of = requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus = other=20 > > more important requirements (e.g. the possibility to work w/o = IP=20 > > forwarding and the need for OAM to continue to monitor the data = > > plane also in case of failures affecting the control or = management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time = because=20 > > I wish to avoid delaying the first phase of the design = solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP = loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for = these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs = seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the = pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there = is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM = packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM = MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for = performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T = of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not = for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements = section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the = pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met = by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms = of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane = content. > > > > > > > > > > The somewhat vague scope of this requirement ("other = internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with = it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, = but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that = associated=20 > > > > > bidirectional paths are the only types of paths that can = be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional = paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the = actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with = existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the = time > > > > > being, the most important type of bidirectional paths = in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C760.E80352B5 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Andy, the key point is that you configure on which existing = connections (and=20 not on which labels) you have to generate AIS/FDI. As a consequence you = cannot=20 configure AIS generation on a label that is associated with a connection = that it=20 is not faulty. If AIS/FDI is enabled by default, than it is your conscious = decision to=20 disable it and to live without the feature. Italo From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: Monday, April 27, 2009 2:59=20 PM To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, Snipped "AIS generation is performed in the = adaptation sink=20 function for the set of active client signals; i.e. for the set = of=20 connection/flow points that are activated on the adaptation sink = function=20 (which are represented by the set of active=20 labels/VIDs/...)." In your words, the adaptation sink = function=20 contains a set of label values, one for each client connection. = Different=20 words, same thing. This is a list of label values which = requires=20 configuration if it is to be used for the injection of AIS and could = be=20 configured wrongly. It's the same thing even in your ITU-T=20 speak. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 (0)1277 = 322038 Mobile: +44=20 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate Street=20 London EC1A 7AJ Registered in England no. 1800000 = This = electronic message=20 contains information from British Telecommunications plc which may be=20 privileged or confidential. The information is intended to be for the = use of=20 the individual(s) or entity named above. If you are not the intended = recipient=20 be aware that any disclosure, copying, distribution or use of the = contents of=20 this information is prohibited. If you have received this electronic = message=20 in error, please notify us by telephone or email (to the numbers or = address=20 above) immediately. Activity and use of=20 the British Telecommunications plc email system is monitored to secure = its=20 effective operation and for other lawful business purposes. = Communications=20 using this system will also be monitored and may be recorded to secure = effective operation and for other lawful business = purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 27 April 2009=20 13:28 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, I have the = impression that=20 you do not have the correct understanding of the SNC protection = switching=20 fucntional models and the location and control of AIS insertion. = Your=20 understanding seems not aligned with the specifications in our = equipment and=20 protection swithcing recommendations. See=20 inline... From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: maandag 27 april 2009=20 12:50 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, It is of course true that adding a boolean = input to a=20 logical system increases the number of possible input states. So = adding an=20 AIS boolean to CC boolean creates four = possible states not=20 just the three you identify below. There are = - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no=20 AIS We must ask what practical = scenarios could=20 generate each of these input states. Good CC, no AIS One hopes this is = because this=20 is because the service is working properly. [mv] I don't think that there is only=20 "hope". This condition reflects that there is no disconnect.=20 If every frame/packet arrives correctly = is not=20 checked by the reception of CC and correct MEGID/MEPID. Frame/packet = loss is=20 checked by the frame/packet loss measurement that is embedded in the = CCM=20 frames, and can be activated. = CC fault, AIS present One hopes this is = because the=20 service is faulty and one hopes this is because of a fault in a = server=20 layer. In fact, the presence of the AIS could be misleading (see=20 below). [mv] With equipment that complies with = the=20 equipment standards this condition doesn't give you just = "hope". It=20 gives you "knowledge" that the discontinutity experienced in the = connection=20 is due to a server layer=20 fault. Good CC, AIS present This situation could arise because of = a=20 misconfiguration of the AIS forwarding label injection table. And = there are=20 a number of scenarios which make this quite likely when protection = switching=20 occurs. Depending on the exact scope of the forwarding labels, a = protection=20 switch may well require the proactive purging of entries from the = AIS=20 forwarding label injection table following the protection switch = (this could=20 equivalently been seen as the forwarding function proactively = dropping the=20 AIS packets). [mv] I = don't think that=20 those scenarios are likely scenarios. Equipment compliant with = ITU-T's=20 equipment recommendations will not have those scenarios. Only = equipment that=20 does not comply with those equipment recommendations could have = such=20 scenarios. Just do not deploy such=20 equipment. [mv] The AIS insertion in the functional models = is=20 performed in the Adaptation Sink functions. Those Adaptation Sink = functions=20 are connected to the Connection function in which the SNC Protection = process=20 is located. The AIS insertion in an Adaptation sink fucntion = continues=20 independent of the state of the protection switch process in=20 the Connection function; i.e. the selector in the protection = process=20 will only receive frames/packets from either the working SNC, or the = protection SNC (but never from=20 both). CC=20 fault, no AIS As you suggest, this could arise from = a=20 misconfiguration of a forwarding function. But it could equally = arise from a=20 misconfiguration of the AIS forwarding label injection table. In = fact, the=20 latter actually seems just as likely and particularly = problematic for=20 maintenance. Unlike normal forwarding, any mismatch between the = forwarding configuration and the AIS forwarding label injection = table will=20 lie dormant and until a server fault arises. Then this generates a = false and=20 misunderstood fault condition with maintenance looking for the fault = in the=20 wrong place. [mv] As = indicated in the=20 above comment, equipment compliant with the equipment and = protection=20 switching recommendation will not behave as you suggest. Only = equipment=20 not-compliant with our equipment/protection = switching recommendation=20 may do this, but such equipment should simply not be=20 deployed. [mv] AIS = generation is=20 performed in the adaptation sink function for the set of active = client=20 signals; i.e. for the set of connection/flow points that are = activated on=20 the adaptation sink function (which are represented by the set of = active=20 labels/VIDs/...). There is no "AIS forwarding label injection table" = in any=20 of our equipment recommendations. AIS will be generated for each = client CI=20 output on the set of CPs/FPs on the adaptation sink function when = aAIS=20 consequent action condition is=20 true. The first two states can be reliably = diagnosed=20 with CC alone. The second two arise from the introduction of = the=20 AIS/FDI. However, any possible benefit that might arise is = completely masked=20 by the fact that the AIS itself must be configured and there is no = reason=20 for this to be more reliable than what it is supposed to be = monitoring.=20 Indeed, there seems good reason to think that it will be less = reliable. [mv] You = are turning=20 things upside down... CC is present to detect continuity and = connectivity=20 problems introduced in the layer network's Connection functions. As = such you=20 can not diagnose the second state with CC alone. With CC alone one = of your=20 colleagues will be requested to initiate a number of Loopback tests = to find=20 out which connection function is misconfigured. This is the wrong = action of=20 course, as there is a server layer=20 fault. [mv] You = do not=20 understand the AIS "configuration" aspect. AIS generation = configuration is=20 on the node, not on each individual connection. Networks that deploy = AIS=20 have it active on all their NNIs. = There is no avoiding that AIS in circuit = switching=20 is fundamentally different from AIS in packet=20 switching. - in circuit switching, you must = fill the bit=20 stream with something and the information injected requires no = configuration=20 whatsoever. - in packet switching, no = packets is a=20 perfectly valid condition and the injection of AIS requires = individual=20 client connection specific information to be configured. [mv] In = packet transport=20 networks with connectivity checking no packets is not a valid = condition.=20 [mv]=20 AIS/FDI insertion specified in e.g. T-MPLS OAM does not = require=20 any individual client connection specific information.=20 [mv] ATM = VP AIS and ATM=20 VC AIS does not require any individual client (i.e. VP, VC) = connection=20 specific information. [mv] ETH = AIS does not=20 require any individual client connection identification = specification, but=20 it requires reuse of the client MEG Level information which is also = required=20 for the ETH MIP functions on the interface=20 port. [mv] I.e. = AIS insertion=20 does not require individual client connection specific information. = Either=20 no additional information at all is required, or additional = information is=20 required that is shared with other fucntions/processes in the=20 interface. The objective is not to replicate the = data plane=20 primitives of SONET/SDH, but the triggers to the operational systems = so that=20 the operational systems and processes are the same. [mv] And = that is exactly=20 what we do with support of AIS in packet transport networks (ATM, = Ethernet,=20 T-MPLS =3D> = MPLS-TP). The simple CC replicates all the = triggers to=20 management systems made by SONET/SDH and gives maximum = compatibility.=20 Conversely, the inclusion of data plane AIS requires a whole new = area of=20 configuration and generates a whole new set of fault conditions = which cannot=20 be localised by SONET/SDH processes. So, ironically, packet AIS is = directly=20 opposed to backwards compatibility you claim is the main drive. [mv] I = hope that you now=20 understand that it is the opposite case is that is = present. Simple=20 CC does **not** replicates all triggers... AIS is needed in=20 addition. Regards, Maarten Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 (0)1277=20 324015 Email: andy.bd.reid@bt.com = British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000=20 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 24 April 2009 = 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI does give additional information. = Let me=20 explain: The need for AIS/FDI is a consequence of = the=20 deployment of loss of continuity checking OAM (e.g. CCM in = ethernet, CC in=20 ATM). The objective of such CCM OAM is to be able to detect a=20 misconfiguration or fault of a connection function (fabric) in the = connection, which interrupts the forwarding of traffic in the = connection.=20 This is a fault condition that can only be discovered by the layer = network=20 in which the connection is supported. It requires that the = organization=20 responsible for the layer network takes action (i.e. locate=20 the layer's connection function that includes the = fault) to=20 restore the connection. Unfortunately, an interruption = of one of=20 the link connections of such connection (due to a fault in a = server=20 layer) will also interrupt the forwarding of traffic in the=20 connection. As such, loss of CC messages (LOC defect) = does not=20 provide sufficient information to determine if the configuration = in the=20 layer's connection functions along the connection have to be = checked and=20 corrected. AIS has been introduced and is used to = help=20 differentiate between the two fault cases. 1) if LOC and AIS are detected, then = there is a=20 server layer fault. This server layer fault is already reported by = the=20 server layer MEP detecting this fault. No action is required, so = no alarm=20 to generate. 2) if LOC is detected and there is no = AIS, then there=20 is a layer network fault (i.e. continuity fault). Fault = localization must=20 be started to locate the misconfigured or failed connection = function. Once=20 this faulty connection function is located, the configuration = fault=20 (or hardware fault) can be corrected, after which the = connection is=20 retored. The interruption of the forwarding of = traffic in the=20 connection in both fault cases is however registered as part of=20 performance monitoring. This performance monitoring information is = used to=20 verify the performance against the SLA for the=20 connection. Regards, Maarten From: andy.bd.reid@bt.com=20 [mailto:andy.bd.reid@bt.com] Sent: vrijdag 24 april = 2009=20 12:34 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These points are irrelevant to the points = I made. My=20 point is that AIS/FDI gives no information above what is already = known -=20 it is only adds complexity and fault liability. Neither of your = points=20 change this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile:=20 +44 (0)7917 025451 Fax :       +44 = (0)1277=20 324015 Email: = andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. 1800000 = This=20 electronic message contains information from British = Telecommunications=20 plc which may be privileged or confidential. The information is = intended=20 to be for the use of the individual(s) or entity named above. If = you are=20 not the intended recipient be aware that any disclosure, copying,=20 distribution or use of the contents of this information is = prohibited. If=20 you have received this electronic message in error, please notify = us by=20 telephone or email (to the numbers or address above)=20 immediately. Activity and use=20 of the British Telecommunications plc email system is monitored to = secure=20 its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded to secure effective operation and for other lawful = business=20 purposes. From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: 23 April = 2009=20 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated=20 bidirectional transport path requirements Andy, > The problem is *not* about = a lack of=20 alarm suppression in the data plane - that information is = readily=20 available. I = don't believe that=20 this is a correct statement in a multi-operator transport = network, or in=20 transport networks of one operator that have more then one=20 administrative subdomain (each with its own network management = system).=20 A problem occuring in admin domain A will be unknown in admin = domain B.=20 The loss of continuaity alarms that are activated in admin = domain B due=20 to the fault in admin domain A will appear as primary alarms, = suggesting=20 connectivity problems in admin domain = B. > = The issue=20 arises because the two sides of maintenance want different = things. The=20 fault fixing > guys want to locate the fault and don't want = any other=20 information. The service=20 maintenance > guys want to know whether their customer = service is=20 working. This is addressed in SDH, OTN, = Ethernet and=20 T-MPLS recommendations by means of the additional SSF = alarm. The=20 SSF alarm is for the service guys telling them that the service = was=20 interrupted due to a fault in a server layer. AIS suppresses the = LOC=20 alarm in those cases so that the maintenance guys don't get = triggered=20 and start looking for a fault that is outside their=20 area. Regards, Maarten From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow me to jump in. You are bringing = together two=20 things which are separate and for which AIS/FDI is no help. = Maintenance=20 operations are concerned with two separate = things. 1) Identifying faults in = equipment, line=20 plant, and other systems (eg misconfigurations) and fixing them=20 (equipment maintenance). 2) Identifying the health of end = to end=20 connections, especially when they are directly supporting = customer=20 services (service maintenance). The problem is *not* about a lack of = alarm=20 suppression in the data plane - that information is readily = available.=20 If, at an end equipment, I have a good server/section layer and = a loss=20 of CC at the client layer, I *know* the fault is elsewhere - I = don't=20 need AIS/FDI to tell me. (Indeed, if you think about, if the = fault is in=20 the end equipment, it is quite likely that the fault means it = cannot=20 report the traffic loss to the management = system!) The issue arises because the two sides = of=20 maintenance want different things. The fault fixing guys want to = locate=20 the fault and don't want any other information. The service = maintenance=20 guys want to know whether their customer service is=20 working. This arose in the early days of = SONET/SDH, when the=20 operations guys demanded that the equipment did *not* suppress = the=20 traffic alarm even when AIS was being received as the service = guys want=20 to know about the alarms. The normal practice is for the = equipment=20 to report the alarms *including* AIS and then a filter is = applied=20 in the management system to suppress alarms to the fault = fixing=20 guys. As I'm aware, there are many different techniques applied = for the=20 filtering algorithms, especially when you consider multiple = concurrent=20 faults in a network, however, the existance of AIS/FDI doesn't = add=20 anything to these that's not already known. In fact, I believe=20 simple time-stamp correlation is one of the most powerful = and=20 widely used techniques. And if the equipment starts messing up = the=20 reporting of loss of CC because it waiting for/persistence=20 checking AIS/FDI, it could end up messing up simple = time-stamp=20 correlation! In practice, it is often not quite a = simple as=20 this, as the service guys like to be able to 'localise' the = fault.=20 However, under most circumstances, the filter has = automatically=20 done this. So localisation you describe is only when = the=20 filter hasn't worked for some reason. But the bottom line is, whatever = operations process=20 you want to use, AIS/FDI doesn't add anything other than = complexity=20 and fault liability to the equipment. Remember AIS goes = back to the=20 TDM world where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief Network Services Strategist = BT = Innovate           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =20 Office: +44 = (0)1277=20 322038 Mobile: +44 (0)7917 025451 Fax :       +44 = (0)1277=20 324015 Email: = andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 = Newgate=20 Street London EC1A 7AJ Registered in England no. = 1800000=20 This=20 electronic message contains information from British = Telecommunications=20 plc which may be privileged or confidential. The information is = intended=20 to be for the use of the individual(s) or entity named above. If = you are=20 not the intended recipient be aware that any disclosure, = copying,=20 distribution or use of the contents of this information is = prohibited.=20 If you have received this electronic message in error, please = notify us=20 by telephone or email (to the numbers or address above)=20 immediately. Activity and=20 use of the British Telecommunications plc email system is = monitored to=20 secure its effective operation and for other lawful business = purposes.=20 Communications using this system will also be monitored and may = be=20 recorded to secure effective operation and for other lawful = business=20 purposes. From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil: = thank you for wasting more = time in=20 describling the problems. but I think some of what you said is = no=20 relations with our problem.for me, maybe AIS/FDI functions is = no sense=20 in cl-ps ,eg. IP. but for CO-PS networks.if there is no = AIS/FDI=20 functions, when there is a defects in a given layer network, = it can=20 cause multiple alarm events to be raised. it is diffcult = for=20 operators to locate and diagnose the faults. though I completely agree you = on=20 adding new things and functions will bring some = complexity . but=20 if we have no functions, it is more complex and difcult for = operators=20 to maintence and administrator the network. so I think every = new=20 functions and things may have positive and negative effects. = but we=20 should consider it very much, don't delete some functions at=20 random. best=20 regards liu = <neil.2.harrison@bt.com> 2009-04-21 = 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com>=20 =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements = <= FONT=20 face=3D"Comic Sans MS" color=3D#800000 size=3D2>Liu, = If MPLS-TP is going to be taken seriously as a = transport=20 network (like SDH/SONET) then the 2 key MUST HAVE requirements = are=20 these. 1 = Provide a=20 transparent client/server relationship...which means: = - = all client=20 bits treated equally - client bit ordering=20 preserved -=20 no attempt to infer client symbol (ie sequence of = client=20 bits) meaning and no attempt to change client symbols = - = the traffic=20 behaviour of client X must not impact the performance = experienced by=20 client Y A key = corollary of the above=20 is that MPLS-TP must only support proper connections (ie = single source=20 constructs) 2 Since MPLS-TP is a transport network it is = not a=20 top-of-stack network (ie it does not support directly external = message/file/stream applications). MPLS-TP therefore = does not=20 require an E-NNI specification. A key corollary of this = is that=20 MPLS-TP will not have any peer interworking relationship with = any=20 other network mode/technology. =20 Now wrt OAM MPLS-TP is a co-ps mode = network.=20 You could argue this should have FDI/AIS....however, the = merit=20 of this is highly questionable. When I and colleagues = discussed=20 whether PBB-TE (also a co-ps mode network) should have FDI/AIS = we=20 concluded that on balance it was not a good idea.....and note = that=20 initially I was in favour of having AIS, but my colleagues = provided=20 strong technical arguments that convinced me otherwise. = AIS/FDI is historically linked to the = early PDH=20 co-cs mode layer networks that used TTL logic. When this = died it=20 put out a +5V (all 1s) signal by default, ie it required no = conscious=20 effort to generate it.....this is key point. Further, in = these=20 networks there is a fairly static/long-holding client server=20 relationship. Clearly this is not true in the cl-ps mode = and=20 it's why IETF have never specified AIS for IP and its why IEEE = had the=20 good sense to throw-out AIS in 802.1ag for Ethernet (though = ITU have=20 unwisely IMO retained it in Y.1731....but I suspect any = operator=20 planning to use Ethernet equipment would always look to IEEE = stds and=20 not ITU ones). = AIS/FDI and = the co-ps mode=20 is debatable. As I noted above, on balance we considered = not a=20 good idea for PBB-TE OAM because it requires a conscious = effort to=20 generate it (unlike the co-cs mode) so there are likely to be = scaling=20 problems and its one more thing to go wrong. You should also have seen me make the point many = times in the=20 past that the always-on defect detection/handling OAM needs to = be as=20 simple/sparse as possible with as little config as possible = because we=20 need super reliability......TCM goes completely against the = grain=20 here. Also note that the OAM required for each of the 3 = network=20 modes is not the same, despite what some claim. = regards, Neil = From: = mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: = mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Deborah: = maybe what you said is right. = but I can't=20 completely agree your opinions. IMO. mpls-tp is regard as = transport=20 network like SDH/SONET. so it should have AIS/FDI fuctions as=20 SDH/SONET. do you think so. = best regards=20 liu "BRUNGARD,=20 DEBORAH A, ATTLABS" <dbrungard@att.com> = =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org = 2009-04-20 = 23:47 =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] = Associated=20 bidirectional transport path=20 requirements I agree with = Neil, it is=20 very questionable the value of AIS/FDI in a packet network- = any=20 mode. It can result in a DoS attack by an operator on = themselves so=20 even Y1731 recommends not to block data frames: "A MEP can = decide=20 whether it blocks data frames when it detects dAIS. The = principle=20 requirement that influences this decision is that data = frames ought=20 to be forwarded as much as possible, without the = possibility of=20 forwarding wrong data frames downstream." Table I.7-2 shows = for=20 AIS, not to block. And as Y1731 states, AIS can only be = used=20 under very constrained architectures - if required for = MPLS-TP, it=20 needs to have the same guidance as in Y1731, i.e. = point-to-point=20 and server/client one-to-one: "for a point-to-point ETH = connection,=20 a MEP has only a single peer MEP. Therefore, there is no = ambiguity regarding the peer MEP for which it should=20 suppress alarms when it receives the ETH-AIS = information." So=20 should only be within one domain - then no=20 need. Deborah -----Original = Message----- From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org]=20 On Behalf Of Maarten Vissers Sent: Monday, April 20, = 2009 10:05=20 AM To: neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport=20 path requirements Neil, > but AIS/FDI in = the cl=20 mode?...do me a favour! Ethernet AIS is indeed a = requirement=20 and a necessity. And you will not be able to understand = that as=20 long as you refuse to accept that "cl-mode" is = a forwarding mode=20 within a **transport entity**. G.800 amendment 1=20 has finally reintroduced this transport entity into = G.800.=20 Besides that, it also introduced the **differentiated=20 connection**: [G.800 am1] "A differentiated connection = is a=20 transport entity that transfers information belonging to = multiple=20 communications between ports across a subnetwork. = <..> In a=20 differentiated connection message contents are = interpreted to=20 identify (sets of) communications which=20 receive different treatment. The sets of = communications=20 may be distinguished by the forwarding identifier or other = layer=20 information. Order is not necessarily preserved = between=20 messages belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic conditioning or preserving=20 communication message order." Ethernet VLANs are in = terms=20 of G.800 "differentiated connections". Ethernet AIS = provides AIS=20 within the scope of such "differentiated = connection". If you=20 apply this to my proposed PTN layer stack, then the EVC=20 layer topology will consists of EVC links supported by = MPLS-TP,=20 Ethernet, PBB-TE and P-OTN VP trails inside metro and = core=20 domains interconnecting EVC matrices. When one of those = EVC=20 links is interrupted, e.g. in the core between metro = 1 and metro=20 4 (see attached slide), then the EVC differentiated = connection that=20 is present on this link will be interrupted. At the EVC=20 switch/bridge node in metro 4 this interruption is = noticed and=20 EVC-AIS is inserted in the downstream direction to suppress = the=20 EVC-LOC alarms at EVC endpoints D4 and D5. The = EVC-AIS=20 (i.e. Ethernet AIS) frame has a reserved multicast = address, which=20 guarantees that the AIS is broadcast to the endpoints of the=20 EVC. I believe that it is time for you to adapt your = view on co=20 and cl modes and relate it to the forwarding mode = **INSIDE** a=20 transport entity. What we know as the internet is = essentially=20 an "IP differentiated connection" with a billion or more=20 ports. What we know as an IP VPN is essentially an "IP=20 differentiated connection" with e.g. n ports (n in the = range of=20 e.g. 2 to 1000). What we know as an Ethernet VLAN is = essentially an=20 "Ethernet differentiated connection" with n ports (n in = the=20 range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP = is=20 essentially an "MPLS differentiated connection" with 2=20 ports. What we know as a p2p SDH VC-n is a "SDH VC-n = connection"=20 with 2 ports. Transport network OAM applies to = transport=20 entities, which are (in terms of G.800 am1) connections = and=20 differentiated=20 connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 april = 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com;=20 maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: = RE:=20 [mpls-tp] Associated bidirectional transport=20 path requirements John, Thanks this is a great = platform to explain why OAM for the 3 network modes = needs to be=20 different. I am getting a wee bit tired of = folks trying to=20 make all 3 network modes look alike (and then, even worse,=20 interwork them as as peers...esp when not not=20 top-of-stack networks...I mean how silly can we get?). = I am=20 even more frustrated by the fact those peddling this FUD = only ever=20 seem to consider OAM and forget all other DP/CP/MP = components=20 (esp top-of-stack message/file/stream application = adaptations).=20 How wrong can this get! In the co modes a = *connection*=20 is a very specific and *constraining* construct.....I am = assuming=20 here we respect the rules of a connection (ie single = source)=20 though some folks don't even bother to respect this, = and this is=20 despite the fact that we all know what problems=20 multiple-source constructs can cause (from LDP/PHP....ergo=20 MPLS-TP). When we have a connection this restricts = *all* DP (ie=20 traffic and OAM) to stay within the bounds of the = connection.=20 Which is fine under defect-free conditions, but if = we have=20 leaking traffic then the constraining nature of the = connection=20 construct is broken. In a nutshell what this means=20 is that OAM that is of a request/response nature cannot = be=20 trusted in co mode networks under misconnectivity=20 defects.....indeed, why should a leaking DP have a = symmetric=20 go/return defect behaviour?....very likely it = won't. So whilst=20 request/response OAM is right for the cl mode it is not right=20 for the co mode under misconnectivity defect=20 conditions. More generally the 3 modes are different = and not=20 just in OAM requirements....but AIS/FDI in the cl = mode?...do me a=20 favour!...at least IEEE had the good sense to bin this for = Ethernet=20 even though it remains in Y.1731. And which is why = I often=20 trot-out the rather silly (to have to say this) = observation that=20 if IP (cl mode) could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 attempts = to=20 explain that physics....G.805 does not. So, the 3 = modes are=20 different...please accept/rejoice in this fact = as they all offer=20 something different/important. But do not be hoodwinked=20 by those who peddle a story that that tries to make the = OAM of=20 the 3 modes the same. regards, Neil >=20 -----Original Message----- > From:=20 mpls-tp-bounces@ietf.org > = [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of Drake, John E > Sent: 17 April 2009 = 20:02 > To:=20 BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc:=20 mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated=20 bidirectional transport path > requirements > = >=20 Italo, > > As described in the MPLS TP OAM = Requirements=20 I-D, virtually all of the > OAM functions require a = return=20 path, and in the absence of a return > path they are=20 disabled. > > As described in David Sinicrope's = meeting=20 minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if = IP=20 addressing is used, an > MPLS TP network needs to be = capable of=20 getting IP packets from > destination to source; = neither the=20 minutes nor I stipulate that a > control plane needs to = be used=20 to instantiate this forwarding. > > As an aside, = the=20 issue of return path for unidirectional LSPs could = be >=20 charaterized as the elephant in the room. In the MPLS TP = OAM=20 > Framework I-D, unicast LSPs are only mentioned three = times=20 and return > paths not at all. > > = Thanks, >=20 > John > > -----Original Message----- > = >=20 From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > = >=20 Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, = John E;=20 Alexander Vainshtein; Maarten Vissers > > Cc:=20 mpls-tp@ietf.org > > Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path > > = requirements > >=20 > > John, > > > > I might have = missed the=20 agreement of MPLS-TP being capable of > > sending = replies to=20 OAM requests sent on uni-directional LSPs. > > = > >=20 This requirement does not belong to the first set of = requirements=20 > > ITU-T is expecting to be met by October. > = >=20 > > However, I think this in a potential interesting = additional > > requirement to be taken into account = (at=20 worst in a > subsequent phase). > > > = > I=20 think that this requirement needs to be evaluated versus other = > > more important requirements (e.g. the = possibility to=20 work w/o IP > > forwarding and the need for OAM to = continue=20 to monitor the data > > plane also in case of = failures=20 affecting the control or management > > = plane). > >=20 > > I am open to discuss it but not sure this is the = right=20 time because > > I wish to avoid delaying the first = phase of=20 the design solution. > > > > Thanks, = Italo >=20 > > > > -----Original Message----- > = > >=20 From: mpls-tp-bounces@ietf.org > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John = E >=20 > > Sent: Thursday, April 16, 2009 8:00 PM > > = > To:=20 Alexander Vainshtein; Maarten Vissers > > > Cc:=20 mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path > > > = requirements >=20 > > > > > At the meeting last fall at = Juniper in=20 Massachusetts, I > > think it was > > > = agreed=20 that an MPLS TP network needs to have a forwarding > = >=20 capability > > > for management, control, and OAM = packets=20 (e.g., sending > > replies to OAM > > > = requests=20 sent on uni-directional LSPs) even if it does not > > = have an=20 IP > > > forwarding data plane. > > > = >=20 > > > -----Original Message----- > > > = > From:=20 Alexander Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > > = > Sent:=20 Thursday, April 16, 2009 9:57 AM > > > > To: = Maarten=20 Vissers > > > > Cc: mpls-tp@ietf.org > = > >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > = >=20 > > > Maarten, > > > > It seems that = you've=20 just (implicitly and, probably, > > > > = inadvertently)=20 stated the following: > > > > > > = > >=20 = MPLS-TP=20 OAM will not ever support MIP loopback function > > = (and=20 fault > > > > localization which requires this = function=20 ) for > > unidirectional P2MP > > > > = and P2P=20 paths. > > > > > > > > If this=20 statement is correct, this (IMHO and FWIW) > raises a=20 valid > > > > question: > > > > = >=20 > > > = =20 Is MPLS-TP an appropriate solution for these > = types of=20 transport > > > > paths? > > > > = > > > > For the reference, IP/MPLS provides = this kind=20 of > > functionality today > > > > for = (unidirectional - but it does not know any other > > = type)=20 P2P LSPs > > > > as described in RFC 4379. And = its=20 extension to P2MP LSPs seems > > > > = easy... >=20 > > > > > > > > > = > >=20 > > > > Regards, > > > > = > >=20 > > Sasha > > > > = >=20 > > > > > > > > > > > = ________________________________________ > > > = > From:=20 mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > = > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > Sent: = Thursday,=20 April 16, 2009 3:24 PM > > > > To: 'Adrian=20 Farrel' > > > > Cc: mpls-tp@ietf.org > = > >=20 > Subject: Re: [mpls-tp] Associated bidirectional transport = path=20 > > > > requirements > > > > = >=20 > > > Adrian, > > > > > > = > >=20 >> <quote> > > > > >> = =20 The intermediate nodes (including MEPs, MIPs and > = >=20 > > other internal > > > > >> = =20 functions as appropriate) of a co-routed > > = > >=20 bidirectional transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of = the=20 forward and the backward > > > > directions of=20 that > > > > >> = transport=20 path. > > > > >> <end = quote> > >=20 > > > > > > > > There is no way = this is a=20 functional requirement. That > > > is, there = is >=20 > > > > *nothing* that can be observed from a = black box=20 point of > > > view that > > > > = >=20 results from adhering to this requirement. > > > = >=20 > > > > Your understanding is not correct. It = is very=20 much > observable if > > > > this = requirement is=20 met from a black box point of view. > > > > The = MIP=20 functions can only perform the Loopback when there is a = > >=20 > > co-routed bidirectional transport path. The MPLS-TP = LBM=20 packet > > > > received at a MIP needs to be = returned=20 (as LBR > > > > packet) to the originating MEP = function=20 via the other > > direction of > > > > = the=20 co-routed bidirectional transport path. This other >=20 direction > > > > would not be available in an=20 associated bidirectional transport > > > > = path... and=20 thus the loopback test > > > would fail. > = > >=20 > > > > > Similarly, when we have to apply = TCM MEPs=20 to monitor a > > segment, then > > > > = this is=20 possible in a co-routed bidir transport path > but not = in=20 a > > > > associated bidir transport path. In = the first=20 case the TCM MEP > > > > Source and Sink = functions are=20 co-located and can > exchange what is > > > = >=20 called "remote information" which is necessary for performance = > > > > monitoring. > > > > In = the=20 latter case the TCM MEP Source and Sink functions > > = are in=20 e.g. > > > > different nodes in the network = and TCM=20 would not be able > > to provide > > > = >=20 performance monitoring. > > > > > > = > >=20 > The entirety of the bracketted text "(including = MEPs, >=20 > > MIPs and other > > > > = internal > >=20 > > > functions as appropriate)" should be deleted. = It does=20 not > > > > add to "The > > > > = >=20 intermediate nodes." > > > > > > > = >=20 Your understanding is not correct. This text must not = be > >=20 deleted at > > > > all. > > > > = >=20 > > > > Actually, I am quite fed up about this=20 persistent > > > insistence on the > > = > >=20 inclusion > > > > > of "Tandem Connection." = The=20 definition within the ITU-T of > > > > this=20 term > > > > > is > > > >=20 poorly > > > > > specified and comes from = the=20 monitoring of a path that is > > > > parallel=20 (i.e. > > > > tandem) > > > > = > to=20 the data path being monitored. This definition of TC > = > >=20 > seems to be at > > > > variance, > = > >=20 > > and would be if the ACH was actually in = band. > >=20 > > > > > > I don't understand where = your=20 interpretation of tandem > > connection is > = > >=20 > described in ITU-T recommendations. I.e. "from = the > >=20 monitoring of a > > > > path that is parallel = (i.e.=20 tandem) to the data path being > > > >=20 monitored."? > > > > > > > > = There is a=20 "network connection" and this network > > connection = is a=20 set > > > > of interconnected "link = connections" and=20 "matrix > connections". A > > > > subset = of those=20 interconnected link connections and matrix > > > = >=20 connections can be monitored and is then referred to = as > a=20 "tandem > > > > connection". There is no "path = that is=20 parallel to the > > data path". > > > = > There=20 is only additional OAM inserted inside the data > path = by=20 the > > > > TCM MEP_So function and this OAM is = extracted from the > > data path by > > > = >=20 the TCM MEP_Sk function. > > > > > > = >=20 > Regards, > > > > Maarten > > > = >=20 > > > > > > > > -----Original=20 Message----- > > > > From:=20 mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian = Farrel >=20 > > > Sent: donderdag 16 april 2009 11:59 > = > >=20 > To: Alexander Vainshtein; = benjamin.niven-jenkins@bt.com >=20 > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > = > >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path = > > > > requirements > > > > = >=20 > > > Hi Sasha, > > > > > > = >=20 > > Unfortunately I cannot fully agree with your=20 statement: > > > > > > > > > = >=20 <quote> > > > > > From = the point=20 of view of hardware, co-routed > > > bidirectional = LSPs > > > > > are a special = case of=20 associated bidirectional LSPs. > > > > > = <end=20 quote> > > > > > > > > > = > This=20 statement would be obviously correct, were it not for > = >=20 > > Requirement > > > > > 34 in the = latest=20 MPLS-TP requirements draft > > > > > = > >=20 > OK. Got it. > > > > > > > = > But=20 what is this doing in the data plane requirements = section? >=20 > > > > > > > In fact, what is this=20 requirement actually saying? > > > > > = > >=20 > > <quote> > > > > > = =20 The intermediate nodes (including MEPs, MIPs and > = >=20 > other internal > > > > > = =20 functions as appropriate) of a co-routed > > > = >=20 bidirectional transport > > > > > = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > > relationship of the = forward=20 and the backward > > > > directions of = that >=20 > > > > transport = path. > >=20 > > > <end quote> > > > > = > >=20 > > There is no way this is a functional requirement.=20 That > > is, there is > > > > = *nothing* that=20 can be observed from a black box point of > > view=20 that > > > > results from adhering to this=20 requirement. > > > > > > > > = Therefore=20 it could be assumed that this requirement is met by > = > >=20 > configuring some data plane database component through = the=20 > > > > management plane. The database = component is=20 not used > for anything > > > > except to = satisfy=20 this requirement for "awareness". > > > > = > >=20 > > Ben! Can we please try to rewrite this requirement = in terms=20 of > > > > behavior? > > > > = >=20 > > > > Please note that Requirement 34 is the = ONLY item=20 in the > > > > list that is > > > = > >=20 specific for co-routed bidirectional LSPs. (The = pairing > >=20 > > requirements > > > > > at end = points for=20 co-routed and associated bidirectional > > > paths = are > > > > > exactly the same even if they = appear=20 in two different > > > items in the > > = > >=20 > requirements' list). > > > > > In other = words,=20 without Requirement 34 the notion of > co-routed > = >=20 > > > bidirectional paths would be void of any data = plane=20 content. > > > > > > > > > = > The=20 somewhat vague scope of this requirement ("other internal = >=20 > > > > functions as appropriate") creates a = suspicion=20 that HW > > > > support of the > > = > >=20 > pairing awareness may be required in order to comply with = it. > > > > > > > > The = entirety of the=20 bracketted text "(including MEPs, > > MIPs and = other >=20 > > > internal functions as appropriate)" should be = deleted.=20 It > > does not > > > > add to "The=20 intermediate nodes." > > > > > > > = >=20 > The following text in the draft increases this = suspicion: >=20 > > > > > > > > > = <quote> >=20 > > > > Tandem Connection: A tandem = connection is=20 an > > arbitrary part of a > > > > = > =20 transport path that can be monitored (via OAM) > > = > >=20 independently from the > > > > > = end-to-end=20 monitoring (OAM). It may be a monitored > > = segment or=20 a > > > > > monitored concatenated = segment of=20 a transport path. > > The tandem > > = >=20 > > connection may also include the forwarding = engine(s)=20 of > > > > the node(s) > > > > = >=20 at the edge(s) of the segment or concatenated = segment. >=20 > > > > <end quote> > > > > = >=20 > > > Actually, I am quite fed up about this=20 persistent > > insistence on the > > > = >=20 inclusion of "Tandem Connection." The definition = within > >=20 the ITU-T of > > > > this term is poorly = specified and=20 comes from the > monitoring of a > > > > = path=20 that is parallel (i.e. tandem) to the data path being > = >=20 > > monitored. This definition of TC seems to be at=20 variance, > > and would > > > > be if = the ACH=20 was actually in band. > > > > > > = > >=20 > Doesn't "forwarding engine" sound like hardware to = you? >=20 > > > > > > > Yes, but so = what? > >=20 > > > > > > > IMHO it is worth noting = that=20 neither the MPLS-TP > > > Requirements = draft > >=20 > > > nor the MPLS-TP OAM requirements one > = > >=20 > > > > > > > > > > = >=20 >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen>=20 > > > > ts-01.txt) contain any requirements = dealing with=20 tandem > > > connections. > > > >=20 > > > > > > But tandem connections are = discussed=20 in the MPLS-TP OAM > > Framework > > > = > >=20 draft > > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > > = ). > >=20 > > > > > > Right. > > > = > Let's=20 just get rid of an unnecessary term and bring all > the=20 I-Ds > > > > into line. > > > > = >=20 > > > > The bottom line, IMHO, is that some = clarity=20 regarding > > > co-routed vs. > > > = > >=20 associated > > > > > bidirectional paths is = still=20 required. One way to provide > > > > that = could >=20 > > > > be by explicitly limiting Requirement 34 = to=20 specific > > > functionality. > > > = >=20 > > > > Agreed. > > > > = > >=20 > > Adrian > > > > > > > = >=20 > > > > > > > > > > = >=20 > ________________________________________ > > = > >=20 From: Adrian Farrel [adrian@olddog.co.uk] > > > = > Sent:=20 Thursday, April 16, 2009 12:13 AM > > > > To: = Alexander=20 Vainshtein; Lou Berger; BUSI ITALO > > > > Cc:=20 mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] = Associated bidirectional transport path > > > = >=20 requirements > > > > > > > > Hi = Sasha, > > > > > > > > Not = really sure=20 whether you are misrepresenting anyone, but... > > = > >=20 > > > > > 1. My reading of one of = Ben's=20 messages is that associated > > > > > = bidirectional paths are the only types of paths that can = be >=20 > > > created in > > > > > the = existing=20 networks; "true" co-routed bidirectional paths > > = > >=20 will have > > > > > to wait until (if ever) = new=20 equipment becomes available. > > > > > = > >=20 > This is clearly nonsense! > > > > From the = point=20 of view of hardware, co-routed > > bidirectional LSPs = are > > > > a special case of associated = bidirectional=20 LSPs. > > > > > > > > If you = can set up=20 two unidirectional LSPs (e.g. using the > >=20 management > > > > plane) you can surely set up = a=20 co-routed > > > bidirectional LSP. > > = > >=20 > > > > There are shipping solutions that = achieve=20 co-routed > bidirectional > > > > LSPs = using the=20 control plane. These either use the GMPLS > > (which=20 is > > > > cleaner) or non-standard proprietary = solutions (which is > > messy but > > > = >=20 functional). > > > > > > > > = But (of=20 course) the management plane or control plane > > = solutions=20 have > > > > nothing to do with availability of = equipment as they > are=20 software > > > > solutions. > > > = >=20 > > > > > 2. My reading of one of Neil's = messages=20 is that the actual > > > > driver for > = > >=20 > > co-routed bidirectional paths may be experience with = existing > > > > > transport networks = rather than=20 any specific benefit. > > > > > > = > >=20 Isn't that the case with 75% of the MPLS-TP = requirements? > >=20 > > Which is not to say it is a bad thing. > > = >=20 > > > > > A large driver for MPLS-TP is to = give the=20 packet network > > the look, > > > > = feel, and=20 behavioral characteristics of a "legacy" > > > = >=20 transport network. > > > > > > > = > >=20 Based on these observations, I'd guess (FWIW) that: > = > >=20 > > * associated bidirectional paths are, at least for = the=20 time > > > > > being, the most=20 important type of bidirectional paths in > > > = > >=20 MPLS-TP > > > > > > > = > I=20 think that is wrong both given my statement above, and > = >=20 given that > > > > other upgrades to existing = MPLS=20 solutions will be > needed to reach > > > = > the=20 full function level of MPLS-TP. > > > > = > >=20 > > > * they had a good chance to remain the only = type=20 of > > bidirectional > > > > > = paths=20 in real deployments. > > > > > = > >=20 > I don't see what that follows from. > > > = >=20 > > > > Cheers, > > > > = Adrian >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > >=20 _______________________________________________ > > = > >=20 mpls-tp mailing list > > > > = mpls-tp@ietf.org >=20 > > > = https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > > > > > > > > > >=20 _______________________________________________ > > = >=20 mpls-tp mailing list > > > = mpls-tp@ietf.org > >=20 > https://www.ietf.org/mailman/listinfo/mpls-tp > = > >=20 > > >=20 _______________________________________________ > = mpls-tp=20 mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp = mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= -------------------------------------------------------- = ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication=20 is confidential. Recipients named above are obligated to = maintain=20 secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files = transmitted with=20 it are confidential and intended solely for the use of the = individual=20 or entity to whom they are addressed. If you have received = this email=20 in error please notify the originator of the message. Any = views=20 expressed in this message are those of the individual = sender. This=20 message has been scanned for viruses and Spam by ZTE Anti-Spam = = system. -------------------------------------= ------------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9C760.E80352B5-- From benjamin.niven-jenkins@bt.com Mon Apr 27 11:09:57 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12FA43A69F0 for ; Mon, 27 Apr 2009 11:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-3.213, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1zEIyHwdjYK for ; Mon, 27 Apr 2009 11:09:53 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E92CD3A69EA for ; Mon, 27 Apr 2009 11:09:51 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 19:11:11 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Apr 2009 18:11:11 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 27 Apr 2009 19:11:10 +0100 From: Ben Niven-Jenkins To: BUSI ITALO , Maarten Vissers , , Message-ID: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAHRYX7AAEIvGoAAGn4jgAAsEQCAAAPhp5Q== In-Reply-To: <6FD21B53861BF44AA90A288402036AB40220ED1C@FRVELSMBS21.ad2.ad.alcatel.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Apr 2009 18:11:11.0893 (UTC) FILETIME=[8BDC4C50:01C9C763] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:09:57 -0000 Italo, What this discussion has convinced me of is that we do not have a common understanding of what AIS is, what it is used for and where it is used. Lack of such an understanding is causing confusion. For example it is still not clear to me whether when talking about AIS/FDI we are talking about: 1) Injecting an artificial (i.e. Not generated by the client or the transport path ingress) packet stream into a transport path by some piece o= f equipment along the transport path. 2) A northbound message from a piece of equipment into the management system. 3) Both. 4) Something entirely different. Without such clarity of understanding I don't see how it's possible to articulate a functional requirement, if such a requirement exists. It is also not clear to me how having some SPs not wanting AIS/FDI and others apparently[1] wanting it leads to a conclusion it should be turned o= n by default. Ben [1] No SP I have seen has stated on the list they want it but we are waitin= g for Andy to double check back with his transport experts. On 27/04/2009 18:49, "BUSI ITALO" wrote: > Maarten, > =20 > I have seen some SPs not willing to deploy AIS/FDI in their network and s= ome > SPs supporting the requirement for AIS/FDI. > =20 > As a consequence I think that AIS/FDI (like all OAM features) should be a > feature optional to use. > =20 > However, this discussion has convinced myself that the most appropriate > approach is to have AIS/FDI enabled by default with the option for the SP= to > disable it. > =20 > Disabling AIS/FDI, or deploying NEs that does not support the capability,= has > the implications you have listed below and as such it should be a conscio= us > decision from the SP. > =20 > Italo >=20 >=20 > ________________________________ >=20 > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > Maarten Vissers > Sent: Monday, April 27, 2009 2:39 PM > To: andy.bd.reid@bt.com; lihan@chinamobile.com > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 >=20 > Andy, >=20 > Please read my response to your post. I have indicated that your understa= nding > of existing equipment and protection switching recommendations is incorre= ct. >=20 > The use of AIS/FDI and the general agreement that AIS is mandatory (i.e. = not > optional) will allow us to use the same fault detection, alarm suppressio= n and > fault localisation as in other transport network technologies (SDH, OTN, > Ethernet). >=20 > If AIS is optional, then operators not using AIS must find other means to > distinguish between LOC alarm due to a continuity/connectivity fault in t= he > layer network, or in the server layer. If such other means are not deploy= ed > then there are two alternatives: > 1) ignore every LOC alarm (assume that it is a server layer fault), until= the > customer complains that his/her connection is broken > 2) start fault localisation on every LOC alarm, and conclude in 90-99% of= the > cases that the problem was a server layer fault. >=20 > Regards, > Maarten >=20 > ________________________________ >=20 > From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] > Sent: maandag 27 april 2009 13:20 > To: lihan@chinamobile.com; maarten.vissers@huawei.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 >=20 > Han, >=20 > In his post below, Maarten is not claiming that AIS is needed for alarm > suppression. He is saying that he sees it being used to distinguish fault= s in > a server layer from faults in the client layer. As you will see in my pos= t > back to Maarten, this cannot be practically achieved. >=20 > I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, i= n the > packet world of MPLS-TP, AIS/FDI cannot be simple and therefore cannot be= the > same as in SONET/SDH. >=20 > The objective is to reuse the same basic fault detection, alarm suppressi= on, > and fault localisation as SONET/SDH. This is readily achieved with the CC > messages in the dataplane. >=20 > However, adding AIS/FDI would require a completely new configuration > management system and a completely new set of fault conditions requiring > localisation. Ironically, adding a packet AIS/FDI effectively removes the > compatibility with SONET/SDH management systems and processes. >=20 > Andy >=20 >=20 > Andy Reid=20 > Chief Network Services Strategist > BT Innovate=20 > =20 > Office: +44 (0)1277 322038 > Mobile: +44 (0)7917 025451 > Fax : +44 (0)1277 324015 > Email: andy.bd.reid@bt.com >=20 >=20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > This electronic message contains information from British Telecommunicati= ons > plc which may be privileged or confidential. The information is intended = to be > for the use of the individual(s) or entity named above. If you are not th= e > intended recipient be aware that any disclosure, copying, distribution or= use > of the contents of this information is prohibited. If you have received t= his > electronic message in error, please notify us by telephone or email (to t= he > numbers or address above) immediately. >=20 > Activity and use of the British Telecommunications plc email system is > monitored to secure its effective operation and for other lawful business > purposes. Communications using this system will also be monitored and may= be > recorded to secure effective operation and for other lawful business purp= oses. >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: lihan [mailto:lihan@chinamobile.com] > Sent: 27 April 2009 02:41 > To: 'Maarten Vissers'; Reid,ABD,Andy,CXM R > Cc: mpls-tp@ietf.org > Subject: =B4=F0=B8=B4: [mpls-tp] Associated bidirectional transport path requirem= ents >=20 >=20 >=20 > Support! >=20 > AIS/FDI is very importance for network management. MPLS-TP is divided int= o > three layers in order to enhance the scalability and OAM. It is very impo= rtant > to distinguish the failure is belong to server layer or client layer. AIS= /FDI > is a simple and well-known mechanism to realize alarm suppression and fau= lt > localization.=20 >=20 >=20 >=20 >=20 >=20 > Best regards, >=20 > Han Li >=20 > ***************************************************** >=20 > Han Li, Ph.D. >=20 > R&D, CHINA MOBILE COMMUNICATIONS CORPORATION >=20 > Tel: +86 10 66006688 ext. 3092 >=20 > Fax: +86 10 63601087 >=20 > MOBILE: 13501093385 >=20 > ***************************************************** >=20 >=20 > ________________________________ >=20 >=20 > =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] =B4=FA=B1=ED M= aarten > Vissers > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C225=C8=D5 2:15 > =CA=D5=BC=FE=C8=CB: andy.bd.reid@bt.com > =B3=AD=CB=CD: mpls-tp@ietf.org > =D6=F7=CC=E2: Re: [mpls-tp] Associated bidirectional transport path requirements >=20 >=20 >=20 > Andy, >=20 >=20 >=20 > AIS/FDI does give additional information. Let me explain: >=20 >=20 >=20 > The need for AIS/FDI is a consequence of the deployment of loss of contin= uity > checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of such CCM= OAM > is to be able to detect a misconfiguration or fault of a connection funct= ion > (fabric) in the connection, which interrupts the forwarding of traffic in= the > connection. This is a fault condition that can only be discovered by the = layer > network in which the connection is supported. It requires that the > organization responsible for the layer network takes action (i.e. locate = the > layer's connection function that includes the fault) to restore the > connection. >=20 >=20 >=20 > Unfortunately, an interruption of one of the link connections of such > connection (due to a fault in a server layer) will also interrupt the > forwarding of traffic in the connection. >=20 >=20 >=20 > As such, loss of CC messages (LOC defect) does not provide sufficient > information to determine if the configuration in the layer's connection > functions along the connection have to be checked and corrected. >=20 >=20 >=20 > AIS has been introduced and is used to help differentiate between the two > fault cases. >=20 > 1) if LOC and AIS are detected, then there is a server layer fault. This > server layer fault is already reported by the server layer MEP detecting = this > fault. No action is required, so no alarm to generate. >=20 > 2) if LOC is detected and there is no AIS, then there is a layer network = fault > (i.e. continuity fault). Fault localization must be started to locate the > misconfigured or failed connection function. Once this faulty connection > function is located, the configuration fault (or hardware fault) can be > corrected, after which the connection is retored. >=20 >=20 >=20 > The interruption of the forwarding of traffic in the connection in both f= ault > cases is however registered as part of performance monitoring. This > performance monitoring information is used to verify the performance agai= nst > the SLA for the connection. >=20 >=20 >=20 > Regards, >=20 > Maarten >=20 >=20 >=20 >=20 > ________________________________ >=20 >=20 > From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] > Sent: vrijdag 24 april 2009 12:34 > To: maarten.vissers@huawei.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 > Maarten, >=20 >=20 >=20 > These points are irrelevant to the points I made. My point is that AIS/FD= I > gives no information above what is already known - it is only adds comple= xity > and fault liability. Neither of your points change this. >=20 >=20 >=20 > Andy >=20 >=20 >=20 >=20 >=20 > Andy Reid=20 > Chief Network Services Strategist > BT Innovate=20 > =20 > Office: +44 (0)1277 322038 > Mobile: +44 (0)7917 025451 > Fax : +44 (0)1277 324015 > Email: andy.bd.reid@bt.com >=20 >=20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > This electronic message contains information from British Telecommunicati= ons > plc which may be privileged or confidential. The information is intended = to be > for the use of the individual(s) or entity named above. If you are not th= e > intended recipient be aware that any disclosure, copying, distribution or= use > of the contents of this information is prohibited. If you have received t= his > electronic message in error, please notify us by telephone or email (to t= he > numbers or address above) immediately. >=20 > Activity and use of the British Telecommunications plc email system is > monitored to secure its effective operation and for other lawful business > purposes. Communications using this system will also be monitored and may= be > recorded to secure effective operation and for other lawful business purp= oses. >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 >=20 > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > Sent: 23 April 2009 20:42 > To: Reid,ABD,Andy,CXM R > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 > Andy, >=20 >=20 >=20 >> The problem is *not* about a lack of alarm suppression in the data plane= - >> that information is readily available. >=20 >=20 >=20 > I don't believe that this is a correct statement in a multi-operator tran= sport > network, or in transport networks of one operator that have more then one > administrative subdomain (each with its own network management system). A > problem occuring in admin domain A will be unknown in admin domain B. The= loss > of continuaity alarms that are activated in admin domain B due to the fau= lt in > admin domain A will appear as primary alarms, suggesting connectivity pro= blems > in admin domain B. >=20 >=20 >=20 >> The issue arises because the two sides of maintenance want different thi= ngs. >> The fault fixing >=20 >> guys want to locate the fault and don't want any other information. The >> service maintenance >=20 >> guys want to know whether their customer service is working. >=20 >=20 >=20 > This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by mea= ns of > the additional SSF alarm. The SSF alarm is for the service guys telling t= hem > that the service was interrupted due to a fault in a server layer. AIS > suppresses the LOC alarm in those cases so that the maintenance guys don'= t get > triggered and start looking for a fault that is outside their area. >=20 >=20 >=20 > Regards, >=20 > Maarten >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 >=20 > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > andy.bd.reid@bt.com > Sent: woensdag 22 april 2009 12:14 > To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 > Liu, >=20 >=20 >=20 > Allow me to jump in. You are bringing together two things which are separ= ate > and for which AIS/FDI is no help. Maintenance operations are concerned wi= th > two separate things. >=20 >=20 >=20 > 1) Identifying faults in equipment, line plant, and other systems (eg > misconfigurations) and fixing them (equipment maintenance). >=20 > 2) Identifying the health of end to end connections, especially when the= y are > directly supporting customer services (service maintenance). >=20 >=20 >=20 > The problem is *not* about a lack of alarm suppression in the data plane = - > that information is readily available. If, at an end equipment, I have a = good > server/section layer and a loss of CC at the client layer, I *know* the f= ault > is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you think abo= ut, > if the fault is in the end equipment, it is quite likely that the fault m= eans > it cannot report the traffic loss to the management system!) >=20 >=20 >=20 > The issue arises because the two sides of maintenance want different thin= gs. > The fault fixing guys want to locate the fault and don't want any other > information. The service maintenance guys want to know whether their cust= omer > service is working. >=20 >=20 >=20 > This arose in the early days of SONET/SDH, when the operations guys deman= ded > that the equipment did *not* suppress the traffic alarm even when AIS was > being received as the service guys want to know about the alarms. The nor= mal > practice is for the equipment to report the alarms *including* AIS and th= en a > filter is applied in the management system to suppress alarms to the faul= t > fixing guys. As I'm aware, there are many different techniques applied fo= r the > filtering algorithms, especially when you consider multiple concurrent fa= ults > in a network, however, the existance of AIS/FDI doesn't add anything to t= hese > that's not already known. In fact, I believe simple time-stamp correlatio= n is > one of the most powerful and widely used techniques. And if the equipment > starts messing up the reporting of loss of CC because it waiting > for/persistence checking AIS/FDI, it could end up messing up simple time-= stamp > correlation!=20 >=20 >=20 >=20 > In practice, it is often not quite a simple as this, as the service guys = like > to be able to 'localise' the fault. However, under most circumstances, th= e > filter has automatically done this. So localisation you describe is only = when > the filter hasn't worked for some reason. >=20 >=20 >=20 > But the bottom line is, whatever operations process you want to use, AIS/= FDI > doesn't add anything other than complexity and fault liability to the > equipment. Remember AIS goes back to the TDM world where you *have to fil= l the > bit stream with something*. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Andy >=20 >=20 >=20 > Andy Reid=20 > Chief Network Services Strategist > BT Innovate=20 > =20 > Office: +44 (0)1277 322038 > Mobile: +44 (0)7917 025451 > Fax : +44 (0)1277 324015 > Email: andy.bd.reid@bt.com >=20 >=20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > This electronic message contains information from British Telecommunicati= ons > plc which may be privileged or confidential. The information is intended = to be > for the use of the individual(s) or entity named above. If you are not th= e > intended recipient be aware that any disclosure, copying, distribution or= use > of the contents of this information is prohibited. If you have received t= his > electronic message in error, please notify us by telephone or email (to t= he > numbers or address above) immediately. >=20 > Activity and use of the British Telecommunications plc email system is > monitored to secure its effective operation and for other lawful business > purposes. Communications using this system will also be monitored and may= be > recorded to secure effective operation and for other lawful business purp= oses. >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 >=20 > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > liu.guoman@zte.com.cn > Sent: 22 April 2009 09:15 > To: Harrison,N,Neil,CXM R > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 >=20 > Neil:=20 > thank you for wasting more time in describling the problems. but I think= some > of what you said is no relations with our problem.for me, maybe AIS/FDI > functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there i= s no > AIS/FDI functions, when there is a defects in a given layer network, it c= an > cause multiple alarm events to be raised. it is diffcult for operators t= o > locate and diagnose the faults. > though I completely agree you on adding new things and functions will br= ing > some complexity . but if we have no functions, it is more complex and dif= cult > for operators to maintence and administrator the network. so I think ever= y new > functions and things may have positive and negative effects. but we shoul= d > consider it very much, don't delete some functions at random. >=20 >=20 > best regards=20 > liu=20 >=20 >=20 >=20 > >=20 > 2009-04-21 20:30=20 >=20 > =CA=D5=BC=FE=C8=CB >=20 > , >=20 > =B3=AD=CB=CD >=20 > >=20 > =D6=F7=CC=E2 >=20 > RE: [mpls-tp] Associated bidirectional transport path requirements >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 > Liu,=20 > =20 > If MPLS-TP is going to be taken seriously as a transport network (like > SDH/SONET) then the 2 key MUST HAVE requirements are these. > =20 > 1 Provide a transparent client/server relationship...which means: > - all client bits treated equally > - client bit ordering preserved > - no attempt to infer client symbol (ie sequence of client bits) meani= ng > and no attempt to change client symbols > - the traffic behaviour of client X must not impact the performance > experienced by client Y > =20 > A key corollary of the above is that MPLS-TP must only support proper > connections (ie single source constructs) > =20 > =20 > 2 Since MPLS-TP is a transport network it is not a top-of-stack network= (ie > it does not support directly external message/file/stream applications). > MPLS-TP therefore does not require an E-NNI specification. A key corolla= ry of > this is that MPLS-TP will not have any peer interworking relationship wit= h any > other network mode/technology. > =20 > =20 > Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this should= have > FDI/AIS....however, the merit of this is highly questionable. When I and > colleagues discussed whether PBB-TE (also a co-ps mode network) should ha= ve > FDI/AIS we concluded that on balance it was not a good idea.....and note = that > initially I was in favour of having AIS, but my colleagues provided stron= g > technical arguments that convinced me otherwise. > =20 > AIS/FDI is historically linked to the early PDH co-cs mode layer networks= that > used TTL logic. When this died it put out a +5V (all 1s) signal by defau= lt, > ie it required no conscious effort to generate it.....this is key point. > Further, in these networks there is a fairly static/long-holding client s= erver > relationship. Clearly this is not true in the cl-ps mode and it's why IE= TF > have never specified AIS for IP and its why IEEE had the good sense to > throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO retai= ned > it in Y.1731....but I suspect any operator planning to use Ethernet equip= ment > would always look to IEEE stds and not ITU ones). > =20 > AIS/FDI and the co-ps mode is debatable. As I noted above, on balance we > considered not a good idea for PBB-TE OAM because it requires a conscious > effort to generate it (unlike the co-cs mode) so there are likely to be > scaling problems and its one more thing to go wrong. > =20 > You should also have seen me make the point many times in the past that t= he > always-on defect detection/handling OAM needs to be as simple/sparse as > possible with as little config as possible because we need super > reliability......TCM goes completely against the grain here. Also note t= hat > the OAM required for each of the 3 network modes is not the same, despite= what > some claim.=20 > =20 > regards, Neil=20 > =20 >=20 >=20 > ________________________________ >=20 >=20 > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > liu.guoman@zte.com.cn > Sent: 21 April 2009 02:59 > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path requiremen= ts >=20 >=20 > Deborah:=20 > maybe what you said is right. but I can't completely agree your opinions.= IMO. > mpls-tp is regard as transport network like SDH/SONET. so it should have > AIS/FDI fuctions as SDH/SONET. >=20 > do you think so.=20 >=20 > best regards=20 > liu=20 >=20 > "BRUNGARD, DEBORAH A, ATTLABS" > =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org >=20 > 2009-04-20 23:47=20 >=20 > =20 >=20 > =CA=D5=BC=FE=C8=CB >=20 > "Maarten Vissers" , >=20 > =B3=AD=CB=CD >=20 > mpls-tp@ietf.org=20 >=20 > =D6=F7=CC=E2 >=20 > Re: [mpls-tp] Associated bidirectional transport path requirements >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > I agree with Neil, it is very questionable the value of AIS/FDI in a > packet network- any mode. It can result in a DoS attack by an operator > on themselves so even Y1731 recommends not to block data frames: > "A MEP can decide whether it blocks data frames when it detects dAIS. > The principle requirement > that influences this decision is that data frames ought to be forwarded > as much as possible, without > the possibility of forwarding wrong data frames downstream." > Table I.7-2 shows for AIS, not to block. >=20 > And as Y1731 states, AIS can only be used under very constrained > architectures - if required for MPLS-TP, it needs to have the same > guidance as in Y1731, i.e. point-to-point and server/client one-to-one: > "for a point-to-point ETH connection, a MEP has only a single peer MEP. > Therefore, there > is no ambiguity regarding the peer MEP for which it should suppress > alarms when it receives the > ETH-AIS information." > So should only be within one domain - then no need. >=20 > Deborah >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Maarten Vissers > Sent: Monday, April 20, 2009 10:05 AM > To: neil.2.harrison@bt.com > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path > requirements >=20 > Neil, >=20 >> but AIS/FDI in the cl mode?...do me a favour! >=20 > Ethernet AIS is indeed a requirement and a necessity. And you will not > be > able to understand that as long as you refuse to accept that "cl-mode" > is a > forwarding mode within a **transport entity**. G.800 amendment 1 has > finally > reintroduced this transport entity into G.800. Besides that, it also > introduced the **differentiated connection**: >=20 > [G.800 am1] "A differentiated connection is a transport entity that > transfers information belonging to multiple communications between ports > across a subnetwork. <..> In a differentiated connection message > contents > are interpreted to identify (sets of) communications which receive > different > treatment. The sets of communications may be distinguished by the > forwarding identifier or other layer information. Order is not > necessarily > preserved between messages belonging to sets of communications receiving > different treatment. Sets of communications may be identified for > purposes > such as traffic conditioning or preserving communication message order." >=20 >=20 > Ethernet VLANs are in terms of G.800 "differentiated connections". > Ethernet > AIS provides AIS within the scope of such "differentiated connection". > If > you apply this to my proposed PTN layer stack, then the EVC layer > topology > will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and > P-OTN > VP trails inside metro and core domains interconnecting EVC matrices. > When > one of those EVC links is interrupted, e.g. in the core between metro 1 > and > metro 4 (see attached slide), then the EVC differentiated connection > that is > present on this link will be interrupted. At the EVC switch/bridge node > in > metro 4 this interruption is noticed and EVC-AIS is inserted in the > downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 > and > D5. >=20 > The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, > which guarantees that the AIS is broadcast to the endpoints of the EVC. >=20 > I believe that it is time for you to adapt your view on co and cl modes > and > relate it to the forwarding mode **INSIDE** a transport entity. >=20 > What we know as the internet is essentially an "IP differentiated > connection" with a billion or more ports. > What we know as an IP VPN is essentially an "IP differentiated > connection" > with e.g. n ports (n in the range of e.g. 2 to 1000). > What we know as an Ethernet VLAN is essentially an "Ethernet > differentiated > connection" with n ports (n in the range of e.g. 2 to 1000). > What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated > connection" with 2 ports. > What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. >=20 > Transport network OAM applies to transport entities, which are (in terms > of > G.800 am1) connections and differentiated connections. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: vrijdag 17 april 2009 22:00 > To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; > Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] Associated bidirectional transport path > requirements >=20 > John, Thanks this is a great platform to explain why OAM for the 3 > network > modes needs to be different. I am getting a wee bit tired of folks > trying > to make all 3 network modes look alike (and then, even worse, interwork > them > as as peers...esp when not not top-of-stack > networks...I mean how silly can we get?). I am even more frustrated by > the fact those peddling this FUD only ever seem to consider OAM and > forget > all other DP/CP/MP components (esp top-of-stack message/file/stream > application adaptations). How wrong can this get! >=20 > In the co modes a *connection* is a very specific and *constraining* > construct.....I am assuming here we respect the rules of a connection > (ie > single source) though some folks don't even bother to respect this, and > this > is despite the fact that we all know what problems multiple-source > constructs can cause (from LDP/PHP....ergo MPLS-TP). >=20 > When we have a connection this restricts *all* DP (ie traffic and OAM) > to > stay within the bounds of the connection. Which is fine under > defect-free > conditions, but if we have leaking traffic then the constraining nature > of > the connection construct is broken. In a nutshell what this means is > that > OAM that is of a request/response nature cannot be trusted in co mode > networks under misconnectivity defects.....indeed, why should a leaking > DP > have a symmetric go/return defect behaviour?....very likely it won't. > So > whilst request/response OAM is right for the cl mode it is not right for > the > co mode under misconnectivity defect conditions. >=20 > More generally the 3 modes are different and not just in OAM > requirements....but AIS/FDI in the cl mode?...do me a favour!...at least > IEEE had the good sense to bin this for Ethernet even though it remains > in > Y.1731. And which is why I often trot-out the rather silly (to have to > say > this) observation that if IP (cl mode) could do it all then why have > IETF > found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The > answer lies in the physics...and G.800 attempts to explain that > physics....G.805 does not. >=20 > So, the 3 modes are different...please accept/rejoice in this fact as > they > all offer something different/important. But do not be hoodwinked by > those > who peddle a story that that tries to make the OAM of the 3 modes the > same.=20 >=20 > regards, Neil=20 >=20 >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >> Sent: 17 April 2009 20:02 >> To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >>=20 >> Italo, >>=20 >> As described in the MPLS TP OAM Requirements I-D, virtually all of the >=20 >> OAM functions require a return path, and in the absence of a return >> path they are disabled. >>=20 >> As described in David Sinicrope's meeting minutes >> (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >> meeting-no >> tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an >> MPLS TP network needs to be capable of getting IP packets from >> destination to source; neither the minutes nor I stipulate that a >> control plane needs to be used to instantiate this forwarding. >>=20 >> As an aside, the issue of return path for unidirectional LSPs could be >=20 >> charaterized as the elephant in the room. In the MPLS TP OAM >> Framework I-D, unicast LSPs are only mentioned three times and return >> paths not at all. >>=20 >> Thanks, >>=20 >> John >>> -----Original Message----- >>> From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >>> Sent: Friday, April 17, 2009 1:59 AM >>> To: Drake, John E; Alexander Vainshtein; Maarten Vissers >>> Cc: mpls-tp@ietf.org >>> Subject: RE: [mpls-tp] Associated bidirectional transport path >>> requirements >>>=20 >>> John, >>>=20 >>> I might have missed the agreement of MPLS-TP being capable of >>> sending replies to OAM requests sent on uni-directional LSPs. >>>=20 >>> This requirement does not belong to the first set of requirements >>> ITU-T is expecting to be met by October. >>>=20 >>> However, I think this in a potential interesting additional >>> requirement to be taken into account (at worst in a >> subsequent phase). >>>=20 >>> I think that this requirement needs to be evaluated versus other >>> more important requirements (e.g. the possibility to work w/o IP >>> forwarding and the need for OAM to continue to monitor the data >>> plane also in case of failures affecting the control or management >>> plane). >>>=20 >>> I am open to discuss it but not sure this is the right time because >>> I wish to avoid delaying the first phase of the design solution. >>>=20 >>> Thanks, Italo >>>=20 >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org >>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >>>> Sent: Thursday, April 16, 2009 8:00 PM >>>> To: Alexander Vainshtein; Maarten Vissers >>>> Cc: mpls-tp@ietf.org >>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>>> requirements >>>>=20 >>>> At the meeting last fall at Juniper in Massachusetts, I >>> think it was >>>> agreed that an MPLS TP network needs to have a forwarding >>> capability >>>> for management, control, and OAM packets (e.g., sending >>> replies to OAM >>>> requests sent on uni-directional LSPs) even if it does not >>> have an IP >>>> forwarding data plane. >>>>=20 >>>>> -----Original Message----- >>>>> From: Alexander Vainshtein >>>> [mailto:Alexander.Vainshtein@ecitele.com] >>>>> Sent: Thursday, April 16, 2009 9:57 AM >>>>> To: Maarten Vissers >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>>>> requirements >>>>>=20 >>>>> Maarten, >>>>> It seems that you've just (implicitly and, probably, >>>>> inadvertently) stated the following: >>>>>=20 >>>>> MPLS-TP OAM will not ever support MIP loopback funct= ion >>> (and fault >>>>> localization which requires this function ) for >>> unidirectional P2MP >>>>> and P2P paths. >>>>>=20 >>>>> If this statement is correct, this (IMHO and FWIW) >> raises a valid >>>>> question: >>>>>=20 >>>>> Is MPLS-TP an appropriate solution for these >> types of transport >>>>> paths? >>>>>=20 >>>>> For the reference, IP/MPLS provides this kind of >>> functionality today >>>>> for (unidirectional - but it does not know any other >>> type) P2P LSPs >>>>> as described in RFC 4379. And its extension to P2MP LSPs seems=20 >>>>> easy... >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Sasha >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] >>> On Behalf >>>>> Of Maarten Vissers [maarten.vissers@huawei.com] >>>>> Sent: Thursday, April 16, 2009 3:24 PM >>>>> To: 'Adrian Farrel' >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path=20 >>>>> requirements >>>>>=20 >>>>> Adrian, >>>>>=20 >>>>>>> >>>>>>> The intermediate nodes (including MEPs, MIPs and >>>>> other internal >>>>>>> functions as appropriate) of a co-routed >>>>> bidirectional transport >>>>>>> path at each (sub-)layer MUST be aware of the pairing >>>>>>> relationship of the forward and the backward >>>>> directions of that >>>>>>> transport path. >>>>>>> >>>>>>=20 >>>>>> There is no way this is a functional requirement. That >>>> is, there is >>>>>> *nothing* that can be observed from a black box point of >>>> view that >>>>>> results from adhering to this requirement. >>>>>=20 >>>>> Your understanding is not correct. It is very much >> observable if >>>>> this requirement is met from a black box point of view. >>>>> The MIP functions can only perform the Loopback when there is a=20 >>>>> co-routed bidirectional transport path. The MPLS-TP LBM packet=20 >>>>> received at a MIP needs to be returned (as LBR >>>>> packet) to the originating MEP function via the other >>> direction of >>>>> the co-routed bidirectional transport path. This other >> direction >>>>> would not be available in an associated bidirectional transport=20 >>>>> path... and thus the loopback test >>>> would fail. >>>>>=20 >>>>> Similarly, when we have to apply TCM MEPs to monitor a >>> segment, then >>>>> this is possible in a co-routed bidir transport path >> but not in a >>>>> associated bidir transport path. In the first case the TCM MEP=20 >>>>> Source and Sink functions are co-located and can >> exchange what is >>>>> called "remote information" which is necessary for performance=20 >>>>> monitoring. >>>>> In the latter case the TCM MEP Source and Sink functions >>> are in e.g.=20 >>>>> different nodes in the network and TCM would not be able >>> to provide >>>>> performance monitoring. >>>>>=20 >>>>>> The entirety of the bracketted text "(including MEPs, >>>> MIPs and other >>>>> internal >>>>>> functions as appropriate)" should be deleted. It does not >>>>> add to "The >>>>>> intermediate nodes." >>>>>=20 >>>>> Your understanding is not correct. This text must not be >>> deleted at >>>>> all. >>>>>=20 >>>>>> Actually, I am quite fed up about this persistent >>>> insistence on the >>>>> inclusion >>>>>> of "Tandem Connection." The definition within the ITU-T of >>>>> this term >>>>>> is >>>>> poorly >>>>>> specified and comes from the monitoring of a path that is >>>>> parallel (i.e. >>>>> tandem) >>>>>> to the data path being monitored. This definition of TC >>>>> seems to be at >>>>> variance, >>>>>> and would be if the ACH was actually in band. >>>>>=20 >>>>> I don't understand where your interpretation of tandem >>> connection is >>>>> described in ITU-T recommendations. I.e. "from the >>> monitoring of a >>>>> path that is parallel (i.e. tandem) to the data path being=20 >>>>> monitored."? >>>>>=20 >>>>> There is a "network connection" and this network >>> connection is a set >>>>> of interconnected "link connections" and "matrix >> connections". A >>>>> subset of those interconnected link connections and matrix=20 >>>>> connections can be monitored and is then referred to as >> a "tandem >>>>> connection". There is no "path that is parallel to the >>> data path".=20 >>>>> There is only additional OAM inserted inside the data >> path by the >>>>> TCM MEP_So function and this OAM is extracted from the >>> data path by >>>>> the TCM MEP_Sk function. >>>>>=20 >>>>> Regards, >>>>> Maarten >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: mpls-tp-bounces@ietf.org >>>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel >>>>> Sent: donderdag 16 april 2009 11:59 >>>>> To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com >>>>> Cc: BUSI ITALO; mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path=20 >>>>> requirements >>>>>=20 >>>>> Hi Sasha, >>>>>=20 >>>>>> Unfortunately I cannot fully agree with your statement: >>>>>>=20 >>>>>> >>>>>> From the point of view of hardware, co-routed >>>> bidirectional LSPs >>>>>> are a special case of associated bidirectional LSPs. >>>>>> >>>>>>=20 >>>>>> This statement would be obviously correct, were it not for >>>>> Requirement >>>>>> 34 in the latest MPLS-TP requirements draft >>>>>=20 >>>>> OK. Got it. >>>>>=20 >>>>> But what is this doing in the data plane requirements section? >>>>>=20 >>>>> In fact, what is this requirement actually saying? >>>>>=20 >>>>>> >>>>>> The intermediate nodes (including MEPs, MIPs and >>>> other internal >>>>>> functions as appropriate) of a co-routed >>>>> bidirectional transport >>>>>> path at each (sub-)layer MUST be aware of the pairing >>>>>> relationship of the forward and the backward >>>>> directions of that >>>>>> transport path. >>>>>> >>>>>=20 >>>>> There is no way this is a functional requirement. That >>> is, there is >>>>> *nothing* that can be observed from a black box point of >>> view that >>>>> results from adhering to this requirement. >>>>>=20 >>>>> Therefore it could be assumed that this requirement is met by=20 >>>>> configuring some data plane database component through the=20 >>>>> management plane. The database component is not used >> for anything >>>>> except to satisfy this requirement for "awareness". >>>>>=20 >>>>> Ben! Can we please try to rewrite this requirement in terms of=20 >>>>> behavior? >>>>>=20 >>>>>> Please note that Requirement 34 is the ONLY item in the >>>>> list that is >>>>>> specific for co-routed bidirectional LSPs. (The pairing >>>>> requirements >>>>>> at end points for co-routed and associated bidirectional >>>> paths are >>>>>> exactly the same even if they appear in two different >>>> items in the >>>>>> requirements' list). >>>>>> In other words, without Requirement 34 the notion of >> co-routed >>>>>> bidirectional paths would be void of any data plane content. >>>>>>=20 >>>>>> The somewhat vague scope of this requirement ("other internal=20 >>>>>> functions as appropriate") creates a suspicion that HW >>>>> support of the >>>>>> pairing awareness may be required in order to comply with it. >>>>>=20 >>>>> The entirety of the bracketted text "(including MEPs, >>> MIPs and other >>>>> internal functions as appropriate)" should be deleted. It >>> does not >>>>> add to "The intermediate nodes." >>>>>=20 >>>>>> The following text in the draft increases this suspicion: >>>>>>=20 >>>>>> >>>>>> Tandem Connection: A tandem connection is an >>> arbitrary part of a >>>>>> transport path that can be monitored (via OAM) >>>>> independently from the >>>>>> end-to-end monitoring (OAM). It may be a monitored >>> segment or a >>>>>> monitored concatenated segment of a transport path. =20 >>> The tandem >>>>>> connection may also include the forwarding engine(s) of >>>>> the node(s) >>>>>> at the edge(s) of the segment or concatenated segment. >>>>>> >>>>>=20 >>>>> Actually, I am quite fed up about this persistent >>> insistence on the >>>>> inclusion of "Tandem Connection." The definition within >>> the ITU-T of >>>>> this term is poorly specified and comes from the >> monitoring of a >>>>> path that is parallel (i.e. tandem) to the data path being=20 >>>>> monitored. This definition of TC seems to be at variance, >>> and would >>>>> be if the ACH was actually in band. >>>>>=20 >>>>>> Doesn't "forwarding engine" sound like hardware to you? >>>>>=20 >>>>> Yes, but so what? >>>>>=20 >>>>>> IMHO it is worth noting that neither the MPLS-TP >>>> Requirements draft >>>>>> nor the MPLS-TP OAM requirements one >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen >>>>>> ts-01.txt) contain any requirements dealing with tandem >>>> connections. >>>>>>=20 >>>>>> But tandem connections are discussed in the MPLS-TP OAM >>> Framework >>>>>> draft >>>>> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >>>>> amework-00.txt >>>>> ). >>>>>=20 >>>>> Right. >>>>> Let's just get rid of an unnecessary term and bring all >> the I-Ds >>>>> into line. >>>>>=20 >>>>>> The bottom line, IMHO, is that some clarity regarding >>>> co-routed vs. >>>>>> associated >>>>>> bidirectional paths is still required. One way to provide >>>>> that could >>>>>> be by explicitly limiting Requirement 34 to specific >>>> functionality. >>>>>=20 >>>>> Agreed. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> From: Adrian Farrel [adrian@olddog.co.uk] >>>>> Sent: Thursday, April 16, 2009 12:13 AM >>>>> To: Alexander Vainshtein; Lou Berger; BUSI ITALO >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path=20 >>>>> requirements >>>>>=20 >>>>> Hi Sasha, >>>>>=20 >>>>> Not really sure whether you are misrepresenting anyone, but... >>>>>=20 >>>>>> 1. My reading of one of Ben's messages is that associated=20 >>>>>> bidirectional paths are the only types of paths that can be >>>>> created in >>>>>> the existing networks; "true" co-routed bidirectional paths >>>>> will have >>>>>> to wait until (if ever) new equipment becomes available. >>>>>=20 >>>>> This is clearly nonsense! >>>>> From the point of view of hardware, co-routed >>> bidirectional LSPs are >>>>> a special case of associated bidirectional LSPs. >>>>>=20 >>>>> If you can set up two unidirectional LSPs (e.g. using the >>> management >>>>> plane) you can surely set up a co-routed >>>> bidirectional LSP. >>>>>=20 >>>>> There are shipping solutions that achieve co-routed >> bidirectional >>>>> LSPs using the control plane. These either use the GMPLS >>> (which is >>>>> cleaner) or non-standard proprietary solutions (which is >>> messy but >>>>> functional). >>>>>=20 >>>>> But (of course) the management plane or control plane >>> solutions have >>>>> nothing to do with availability of equipment as they=20 >> are software >>>>> solutions. >>>>>=20 >>>>>> 2. My reading of one of Neil's messages is that the actual >>>>> driver for >>>>>> co-routed bidirectional paths may be experience with existing=20 >>>>>> transport networks rather than any specific benefit. >>>>>=20 >>>>> Isn't that the case with 75% of the MPLS-TP requirements? >>>>> Which is not to say it is a bad thing. >>>>>=20 >>>>> A large driver for MPLS-TP is to give the packet network >>> the look, >>>>> feel, and behavioral characteristics of a "legacy" >>>>> transport network. >>>>>=20 >>>>>> Based on these observations, I'd guess (FWIW) that: >>>>>> * associated bidirectional paths are, at least for the time >>>>>> being, the most important type of bidirectional paths in >>>>>> MPLS-TP >>>>>=20 >>>>> I think that is wrong both given my statement above, and >>> given that >>>>> other upgrades to existing MPLS solutions will be >> needed to reach >>>>> the full function level of MPLS-TP. >>>>>=20 >>>>>> * they had a good chance to remain the only type of >>> bidirectional >>>>>> paths in real deployments. >>>>>=20 >>>>> I don't see what that follows from. >>>>>=20 >>>>> Cheers, >>>>> Adrian >>>>>=20 >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>>=20 >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>=20 >>>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s=20 > solely property of the sender's organization. This mail communication is=20 > confidential. Recipients named above are obligated to maintain secrecy an= d are=20 > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d=20 > solely for the use of the individual or entity to whom they are addressed= . If=20 > you have received this email in error please notify the originator of the= =20 > message. Any views expressed in this message are those of the individual=20 > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s=20 > solely property of the sender's organization. This mail communication is=20 > confidential. Recipients named above are obligated to maintain secrecy an= d are=20 > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d=20 > solely for the use of the individual or entity to whom they are addressed= . If=20 > you have received this email in error please notify the originator of the= =20 > message. Any views expressed in this message are those of the individual=20 > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From gregimirsky@gmail.com Mon Apr 27 11:18:44 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33753A6ACC for ; Mon, 27 Apr 2009 11:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHgKzrjmdncm for ; Mon, 27 Apr 2009 11:18:43 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 805D63A6ACA for ; Mon, 27 Apr 2009 11:18:42 -0700 (PDT) Received: by bwz7 with SMTP id 7so74917bwz.37 for ; Mon, 27 Apr 2009 11:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ohX0gxDSU4Ap+7S961JAUMER8IhHZJgY540WEkjgCEw=; b=BeiSo71YXGig2Pcp3QSifn67b9ah+g65Kx9vN1xS8EtdqGdjCMNDvZLbVtML+JAK1U /cTx+dAHf2K4ZhFH/FdfjLGHY2aCrnf2MP/qF655WiDy/TR0pv4Bnvvk0giHTQml8KJw OY9Gvgl+7ReCX737psyXTy8jk6cVTx+a7r0Ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W50M6duD8xlPLSmXekP+j886thjcoussspjV+mg47qSfklVA1IClq1kibqT0ocuqp1 jz03fyUoVknkKrcM+3CGu6vNVWTj0rap1ylJSRFCm8BZvoQKqu8wyg/qPr9xAvcnOP9A pCJ6oRe6b+gsFh7pzP1D/yiqkUxLEVFR646l8= MIME-Version: 1.0 Received: by 10.103.92.8 with SMTP id u8mr3396468mul.12.1240856402686; Mon, 27 Apr 2009 11:20:02 -0700 (PDT) In-Reply-To: <000001c9c704$5843ba40$6c02a8c0@china.huawei.com> References: <20090424154900.X31703@sapphire.juniper.net> <000001c9c704$5843ba40$6c02a8c0@china.huawei.com> Date: Mon, 27 Apr 2009 14:20:02 -0400 Message-ID: <787be2780904271120j488e30aeyb445197f8d49efd0@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=0016e6de04e319720e04688d658b Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:18:45 -0000 --0016e6de04e319720e04688d658b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, the draft you've referred to is a proposed solution but not a requirement that can be satisfied by supporting AIS/FDI. Regards, Greg 2009/4/27 Maarten Vissers > Rahul, > > > Personally I would very much like to see greater SP involvement in > MPLS-TP > requirements effort. > > Please read draft-bhh-mpls-tp-oam-y1731. This draft is co-authored by > representatives of DT, FT, KPN, KDDI and CT. > > Regards, > Maarten > > -----Original Message----- > From: Rahul Aggarwal [mailto:rahul@juniper.net] > Sent: zaterdag 25 april 2009 0:54 > To: Maarten Vissers > Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) > > > Maarten, > > On Fri, 24 Apr 2009, Maarten Vissers wrote: > > > Ben, > > > > Your company is one of the many operators in the world, and the number > > of nodes outside your network is factors larger then the number of > > nodes inside your network. My experience is that different operators > > have different sets of requirements. > > Those different operators then must present those different requirements = to > the MPLS WG. In the absence of that we have no choice but to work with th= e > requirements presented by the set of SPs who are currently involved in > formulating the MPLS-TP requirements. > > Personally I would very much like to see greater SP involvement in MPLS-T= P > requirements effort. And vendors should not proxy for SPs in defining > MPLS-TP requirements. > > > rahul > > Manufacturers have to support the superset of those > > requirements. Each operator will then deploy the subset of provided > > features that fits its needs (and turn off or don't use the others). > > Your company for some years has been asking for less, other operators > > have been asking for more. Manufacturers thus build their products > > with lots of configurability to support all variations. > > > > It is my opinion that we should not remove well established features > > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > > before the majority of operators have agreed that such features are > > not longer necessary. > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of Ben Niven-Jenkins > > Sent: vrijdag 24 april 2009 0:14 > > To: mpls-tp@ietf.org > > Subject: [mpls-tp] We appear to be going around in circles (Re: > > Associated bidirectional transport path requirements) > > > > Colleagues, > > > > The current debates appear to be going around in circles and achieving > > nothing of value IMO. Two major operators have expressed their > > opinions and no operator that I can see has disagreed with those > opinions. > > > > I apologise for being direct (and possibly rude) but I am getting > > tired of being told by folks who do not represent operators what > > functionality I need or should have in my networks. > > > > To put some context on BT's comments in these threads: > > I have the largest MPLS network in the UK. > > I have one of the largest MPLS networks globally delivering service to > > 173 countries with over 200 000 customer ports I have (off the top of > > my head) at least another 10 MPLS networks in specific countries > > covering at least 3 continents delivering dedicated services to > particular > market segments. > > > > I have an extremely large SDH network in the UK consisting of over 30 > > 000 switches and supporting in excess of 1 million circuits. > > I have an extremely large SDH network globally delivering service in > > 110 countries. > > > > I would like to think my BT colleagues and I might know a little > > something about building large scale networks and the requirements of > > those networks and the needs of the customers that I deliver services t= o. > > > > Can we please stop these circular arguments which are IMO going > > nowhere and focus on the task in hand which is defining the > > requirements (and later > > solutions) being asked for by myself, my company and my colleagues in > > other operators on this list. > > > > Thanks > > Ben > > > > > > -- > > > > Ben Niven-Jenkins > > IP, Data & Content Architect > > Network Infrastructure Architecture, BT > > > > E-mail: benjamin.niven-jenkins@bt.com > > Office: +44 (0)1473 648225 > > Mobile: +44 (0)7918 077205 > > Fax: +44 (0)1332 578827 > > > > British Telecommunications plc. Registered office: 81 Newgate Street > London > > EC1A 7AJ Registered in England no: 1800000 > > > > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > > > > > ben: > > > I understand your meaning, you still wish to resign and make a more > > > reliable and effective, easy to operator and easy to manage packet > > > transport network like me. but why not apply this SDH/SONET in the > > > future maybe the following cause: > > > 1 it adopted circuit switching techonogy to bring lower useful of > > > the resource than PTN network; > > > 2 it can't bear all kinds of traffics like PTN networks it noted > > > that we can't apply SDH/SONET network in the future not because it > > > have a complex OAM functions. while more people like to move the > > > advantages of the OAM functions in SDH/SONET to PTN networks. and > > > AIS/FDI function is a kind of OAM functions of SDH/SONET . we should > > > use and extend the AIS/FDI functions to MPLS-TP ; > > > > > > best regards > > > liu > > > > > > > > > > > > Ben Niven-Jenkins > > > 2009-04-23 07:58 > > > > > > =CA=D5=BC=FE=C8=CB > > > , "BRUNGARD, DEBORAH A, ATTLABS" > > > > > > =B3=AD=CB=CD > > > > > > =D6=F7=CC=E2 > > > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > > > > > > > > > > > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > > > wrote: > > > > > >> Deborah: > > >> maybe what you said is right. but I can't completely agree your > > > opinions. > > >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it > > >> should have AIS/FDI fuctions as SDH/SONET. > > >> > > >> do you think so. > > > > > > No we must assess the requirements for packet transport networks > > > supporting the needs of operators today and in the future. We must > > > not blindly recreate SDH/SONET. If we do so without consideration to > > > how operators' needs and requirements may have evolved (and continue > > > to evolve in future) we will have failed IMO and I would severely > > > question the value of the work we will have produced. If we just > > > recreate SDH/SONET then what is the purpose of the work an operator > > > would be better off just deploying existing SDH/SONET equipment. > > > > > > > > > Ben > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail is solely property of the sender's organization. This mail > > > communication is confidential. Recipients named above are obligated > > > to maintain secrecy and are not permitted to disclose the contents > > > of this > > communication to others. > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they > > > are addressed. If you have received this email in error please > > > notify the originator of the message. Any views expressed in this > > > message are those of the individual sender. > > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --0016e6de04e319720e04688d658b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, the draft you've referred to is a proposed solution bu= t not a requirement that can be satisfied by supporting AIS/FDI. Reg= ards, Greg 2009/4/27 Maarten Vissers <= span dir=3D"ltr"><maarten.= vissers@huawei.com> Rahul, > Personally I would very much like to see greater SP involvement in MPL= S-TP requirements effort. Please read draft-bhh-mpls-tp-oam-y1731. This draft is co-authored by= representatives of DT, FT, KPN, KDDI and CT. Regards, Maarten -----Original Message----- From: Rahul Aggarwal [mailto:rahul@jun= iper.net] Sent: zaterdag 25 april 2009 0:54 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-t= p@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maarten, On Fri, 24 Apr 2009, Maarten Vissers wrote: > Ben, > > Your company is one of the many operators in the world, and the number= > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Those different operators then must present those different requirements to= the MPLS WG. In the absence of that we have no choice but to work with the<= br> requirements presented by the set of SPs who are currently involved in formulating the MPLS-TP requirements. Personally I would very much like to see greater SP involvement in MPLS-TP<= br> requirements effort. And vendors should not proxy for SPs in defining MPLS-TP requirements. rahul Manufacturers have to support the superset of those > requirements. Each operator will then deploy the subset of provided > features that fits its needs (and turn off or don't use the others= ). > Your company for some years has been asking for less, other operators<= br> > have been asking for more. Manufacturers thus build their products > with lots of configurability to support all variations. > > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf= .org [mailto:mpls-tp-bounce= s@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving= > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those opini= ons. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to= > 173 countries with over 200 000 customer ports I have (off the top of<= br> > my head) at least another 10 MPLS networks in specific countries > covering at least 3 continents delivering dedicated services to partic= ular market segments. > > I have an extremely large SDH network in the UK consisting of over 30<= br> > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of<= br> > those networks and the needs of the customers that I deliver services = to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in<= br> > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.nive= n-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate St= reet London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "li= u.guoman@zte.com.cn" <= liu.guoman@zte.com.cn> wrote: > > > ben: > > I understand your meaning, you still wish to resign and mak= e a more > > reliable and effective, easy to operator and easy to manage packe= t > > transport network like me. but why not apply this SDH/SONET in th= e > > future maybe the following cause: > > 1 it adopted circuit switching techonogy to bring lo= wer useful of > > the resource than PTN network; > > 2 it can't bear all kinds of traffics like PTN n= etworks it noted > > that we can't apply SDH/SONET network in the future not becau= se it > > have a complex OAM functions. while more people like to move the<= br> > > advantages of the OAM functions in SDH/SONET to PTN network= s. and > > AIS/FDI function is a kind of OAM functions of SDH/SONET . we sho= uld > > use and extend the AIS/FDI functions to MPLS-TP ; > > > > best regards > > liu > > > > > > > > Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com> > > 2009-04-23 07:58 > > > > =CA=D5=BC=FE=C8=CB > > <liu.guoman@zte.com.c= n>, "BRUNGARD, DEBORAH A, ATTLABS" > > <dbrungard@att.com>= ; > > =B3=AD=CB=CD > > <mpls-tp@ietf.org><= br> > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional transport path requirement= s > > > > > > > > > > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> > > wrote: > > > >> Deborah: > >> maybe what you said is right. but I can't completel= y agree your > > opinions. > >> IMO. mpls-tp is regard as transport network like SDH/SONET. s= o it > >> should have AIS/FDI fuctions as SDH/SONET. > >> > >> do you think so. > > > > No we must assess the requirements for packet transport networks<= br> > > supporting the needs of operators today and in the future. We mus= t > > not blindly recreate SDH/SONET. If we do so without consideration= to > > how operators' needs and requirements may have evolved (and c= ontinue > > to evolve in future) we will have failed IMO and I would severely= > > question the value of the work we will have produced. If we just<= br> > > recreate SDH/SONET then what is the purpose of the work an operat= or > > would be better off just deploying existing SDH/SONET equipment.<= br> > > > > > > Ben > > > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in thi= s > > mail is solely property of the sender's organization. This ma= il > > communication is confidential. Recipients named above are obligat= ed > > to maintain secrecy and are not permitted to disclose the content= s > > of this > communication to others. > > This email and any files transmitted with it are confidential and= > > intended solely for the use of the individual or entity to whom t= hey > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this= > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Sp= am > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --0016e6de04e319720e04688d658b-- From gregimirsky@gmail.com Mon Apr 27 11:45:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7EB83A6FF3 for ; Mon, 27 Apr 2009 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-1.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSDH0ar-w8fu for ; Mon, 27 Apr 2009 11:45:29 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by core3.amsl.com (Postfix) with ESMTP id C95AF3A6FF4 for ; Mon, 27 Apr 2009 11:45:28 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so37662mue.9 for ; Mon, 27 Apr 2009 11:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jeKHvyA2Mr30F5Wm748T0T14zVo92NMz2y9vv4NRD0A=; b=nHfMV6VtBSweP8kCtqSrgYvvU3NmHbLirRIN1VxTeJ7nIgeOOC2bbraAOB41JmdYow b3s5T/S2jTy2O0GYOgERkMKvDWswsm8GJ3naa61GxwvLuq+KO3Dsi1glcm+vR8/ZlcMQ SmEaXMstZO/BC6JDPLZYajry5vNQWC1MWru6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v6cYVOxUhfFXWzljeXN5zcm77nrCUShP2smPsTo00tbGzbILky60nx7P6swU+VkYqA KQQk3+gWrPKu2E2KBtmKHs5OvHezkdJ5GHkDIfllPhiYoSeNG0o7f3FiLlK/BfBeNvA6 gqEaJEkGjqbyeM/uHdEKGW8KDzq/XvTRO8aqY= MIME-Version: 1.0 Received: by 10.103.92.8 with SMTP id u8mr3409766mul.12.1240858007556; Mon, 27 Apr 2009 11:46:47 -0700 (PDT) In-Reply-To: <000501c9c704$5cf7cc70$6c02a8c0@china.huawei.com> References: <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com> <000501c9c704$5cf7cc70$6c02a8c0@china.huawei.com> Date: Mon, 27 Apr 2009 14:46:47 -0400 Message-ID: <787be2780904271146hcff7e94xca5da9384f16d92e@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=0016e6de04e3c1d39604688dc4a1 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:45:31 -0000 --0016e6de04e3c1d39604688dc4a1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, you definitely know but I'd note that MEF formulates requirements for Carrier Ethernet as a service, i.e. client layer of a transport network, no= t requirements for the transport network as server layer. Thus requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers > Tom, > > This AIS discussion has been held in previous technologies as well, e.g. > Ethernet OAM. > The result was that AIS insertion is optional and that Ethernet equipment > (see G.8021) can be configured to insert Ethernet AIS or to not insert > Ethernet AIS. > > > Do you see our (BT's) requirements to be very divergent from those of > other operators participating in this effort? > > I see the requirements for OAM that have been expressed in this mpls-tp > discussion by BT representatives to be different from the requirements > expressed by other operator representatives. For example > draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, > KPN, KDDI and CT. I also see that the OAM requirements defined in MEF (wi= th > input from e.g. AT&T and Verizon) be different from those expressed by BT > representatives. I see that MEF is requesting to support in Y.1731 frame > loss counting for more then one priority level; i.e. an extension of the > existing capability that support frame loss counting for a single priorit= y > (i.e. a case of more OAM, not less OAM). > > I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have > created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtua= l > UNI specifications, while representatives of BT state that there can't be > "UNI" or "E-NNI" interfaces associated with packet transport networks, as > those networks are "not top of stack". I see that many operators require > compliance with MEF specifications, including the Ethernet UNI > specification. > > I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service v= ia > rooted-multipoint EVCs, which EVCs terminate outside the KPN network (ref= er > to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and > > http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml > ); i.e. a peer-interconnection case and a potential case for TCM, a case > which according to BT representatives does not exist. > > I see that the "message, file, stream" concepts are key to BT's > considerations, while I don't see any of that contributed by other > operators. When I look at the telecom network stack (see attached slide), > then message, file stream are important concepts at Layer 3 (NGN) where > those represent the characteristics of the main services (data, voice, > video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important > services at Layer 2 (PTN). This raises the question what the scope of > MPLS-TP is for you: > A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to support > the IP based Layer 3 Services/Channel layer > B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to support > the EVC based Layer 2 Services/Channel layer. > > Regards, > Maarten > > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: vrijdag 24 april 2009 15:35 > To: Maarten Vissers > Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) > > > Maartin, > > > Ben, > > > > Your company is one of the many operators in the world, and the number > > of nodes outside your network is factors larger then the number of > > nodes inside your network. My experience is that different operators > > have different sets of requirements. Manufacturers have to support the > > superset of those requirements. Each operator will then deploy the > > subset of provided features that fits its needs (and turn off or don't > > use the others). Your company for some years has been asking for less, > > other operators have been asking for more. Manufacturers thus build > > their products with lots of configurability to support all variations. > > Do you see our (BT's) requirements to be very divergent from those > of other operators participating in this effort? Unless our requirements > are very different, I am confident vendors will build (or have built) the= ir > devices based on our (sensible) requirements. > > > It is my opinion that we should not remove well established features > > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > > before the majority of operators have agreed that such features are > > not longer necessary. > > Again, that is your opinion, which frankly seems to diverge from > what other operators have expressed. Furthermore, let me recommend that y= ou > get out of the habit of telling your customers (or potential ones), what > they require after they have been plainly clear about what they want. > Unless you think we don't know what we are talking about. Is this perhaps > the case? > > --Tom > > > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of Ben Niven-Jenkins > > Sent: vrijdag 24 april 2009 0:14 > > To: mpls-tp@ietf.org > > Subject: [mpls-tp] We appear to be going around in circles (Re: > > Associated > > bidirectional transport path requirements) > > > > Colleagues, > > > > The current debates appear to be going around in circles and achieving > > nothing of value IMO. Two major operators have expressed their > > opinions and no operator that I can see has disagreed with those > > opinions. > > > > I apologise for being direct (and possibly rude) but I am getting > > tired of being told by folks who do not represent operators what > > functionality I need or should have in my networks. > > > > To put some context on BT's comments in these threads: > > I have the largest MPLS network in the UK. > > I have one of the largest MPLS networks globally delivering service to > > 173 countries with over 200 000 customer ports I have (off the top of > > my > > head) > > at least another 10 MPLS networks in specific countries covering at > > least 3 continents delivering dedicated services to particular market > > segments. > > > > I have an extremely large SDH network in the UK consisting of over 30 > > 000 switches and supporting in excess of 1 million circuits. > > I have an extremely large SDH network globally delivering service in > > 110 countries. > > > > I would like to think my BT colleagues and I might know a little > > something about building large scale networks and the requirements of > > those networks and the needs of the customers that I deliver services > > to. > > > > Can we please stop these circular arguments which are IMO going > > nowhere and focus on the task in hand which is defining the > > requirements (and later > > solutions) being asked for by myself, my company and my colleagues in > > other operators on this list. > > > > Thanks > > Ben > > > > > > -- > > > > Ben Niven-Jenkins > > IP, Data & Content Architect > > Network Infrastructure Architecture, BT > > > > E-mail: benjamin.niven-jenkins@bt.com > > Office: +44 (0)1473 648225 > > Mobile: +44 (0)7918 077205 > > Fax: +44 (0)1332 578827 > > > > British Telecommunications plc. Registered office: 81 Newgate Street > > London > > EC1A 7AJ Registered in England no: 1800000 > > > > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > > wrote: > > > >> ben: > >> I understand your meaning, you still wish to resign and make a more > >> reliable and effective, easy to operator and easy to manage packet > >> transport network like me. but why not apply this SDH/SONET in the > >> future maybe the following cause: > >> 1 it adopted circuit switching techonogy to bring lower useful of > >> the resource than PTN network; > >> 2 it can't bear all kinds of traffics like PTN networks it noted > >> that we can't apply SDH/SONET network in the future not because it > >> have a complex OAM functions. while more people like to move the > >> advantages of the OAM functions in SDH/SONET to PTN networks. and > >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should > >> use and extend the AIS/FDI functions to MPLS-TP ; > >> > >> best regards > >> liu > >> > >> > >> > >> Ben Niven-Jenkins > >> 2009-04-23 07:58 > >> > >> =CA=D5=BC=FE=C8=CB > >> , "BRUNGARD, DEBORAH A, ATTLABS" > >> > >> =B3=AD=CB=CD > >> > >> =D6=F7=CC=E2 > >> Re: [mpls-tp] Associated bidirectional transport path requirements > >> > >> > >> > >> > >> > >> > >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > >> wrote: > >> > >>> Deborah: > >>> maybe what you said is right. but I can't completely agree your > >> opinions. > >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it > >>> should have AIS/FDI fuctions as SDH/SONET. > >>> > >>> do you think so. > >> > >> No we must assess the requirements for packet transport networks > >> supporting the needs of operators today and in the future. We must > >> not blindly recreate SDH/SONET. If we do so without consideration to > >> how operators' needs and requirements may have evolved (and continue > >> to evolve in future) we will have failed IMO and I would severely > >> question the value of the work we will have produced. If we just > >> recreate SDH/SONET then what is the purpose of the work an operator > >> would be better off just deploying existing SDH/SONET equipment. > >> > >> > >> Ben > >> > >> > >> > >> > >> > >> -------------------------------------------------------- > >> ZTE Information Security Notice: The information contained in this > >> mail is solely property of the sender's organization. This mail > >> communication is confidential. Recipients named above are obligated > >> to maintain secrecy and are not permitted to disclose the contents of > >> this > > communication to others. > >> This email and any files transmitted with it are confidential and > >> intended solely for the use of the individual or entity to whom they > >> are addressed. If you have received this email in error please notify > >> the originator of the message. Any views expressed in this message > >> are those of the individual sender. > >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > --0016e6de04e3c1d39604688dc4a1 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, you definitely know but I'd note that MEF formulates r= equirements for Carrier Ethernet as a service, i.e. client layer of a trans= port network, not requirements for the transport network as server layer. T= hus requirements expressed by SPs at MEF are not applicable or transitive, = in my view, to MPLS-TP, at least not automatically. Regards, Greg Mirsky 2009/4/27 Maa= rten Vissers <maarten.vissers@huawei.com> Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those= of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-= tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF (with= input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single priority<= br> (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) hav= e created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtual<= br> UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet tran= sport networks, as those networks are "not top of stack". I see that many operators = require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service via= rooted-multipoint EVCs, which EVCs terminate outside the KPN network (refer= to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.= html and http://www.kpn-wholesale.com/nl/1936-Wholes= ale_Broadband_Access_Service.html ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT'= ;s considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the imp= ortant services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnad= eau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number= > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the= > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don&#= 39;t > use the others). Your company for some years has been asking for less,= > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations.= Do you see our (BT's) requirements to be ve= ry divergent from those of other operators participating in this effort? Unless our requireme= nts are very different, I am confident vendors will build (or have built) their= devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seem= s to diverge from what other operators have expressed. Furthermore, let me recommend that you= get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this perha= ps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf= .org [mailto:mpls-tp-bounce= s@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving= > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to= > 173 countries with over 200 000 customer ports I have (off the top of<= br> > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market<= br> > segments. > > I have an extremely large SDH network in the UK consisting of over 30<= br> > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of<= br> > those networks and the needs of the customers that I deliver services<= br> > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in<= br> > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.nive= n-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate St= reet > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "li= u.guoman@zte.com.cn" <= liu.guoman@zte.com.cn> > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a mor= e >> reliable and effective, easy to operator and easy to manage packet= >> transport network like me. but why not apply this SDH/SONET in the= >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower use= ful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks= it noted >> that we can't apply SDH/SONET network in the future not becaus= e it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks= . and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we shou= ld >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com> >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> <liu.guoman@zte.com.cn= >, "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com>= >> =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements= >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree= your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so= it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must= >> not blindly recreate SDH/SONET. If we do so without consideration = to >> how operators' needs and requirements may have evolved (and co= ntinue >> to evolve in future) we will have failed IMO and I would severely<= br> >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operato= r >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this= >> mail is solely property of the sender's organization. This mai= l >> communication is confidential. Recipients named above are obligate= d >> to maintain secrecy and are not permitted to disclose the contents= of >> this > communication to others. >> This email and any files transmitted with it are confidential and<= br> >> intended solely for the use of the individual or entity to whom th= ey >> are addressed. If you have received this email in error please not= ify >> the originator of the message. Any views expressed in this message= >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spa= m > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --0016e6de04e3c1d39604688dc4a1-- From adrian@olddog.co.uk Mon Apr 27 12:16:40 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477E83A6FF6 for ; Mon, 27 Apr 2009 12:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.509 X-Spam-Level: X-Spam-Status: No, score=0.509 tagged_above=-999 required=5 tests=[AWL=-2.307, BAYES_40=-0.185, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CayPOW5gITie for ; Mon, 27 Apr 2009 12:16:36 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 7DABE3A6FCD for ; Mon, 27 Apr 2009 12:16:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3RJHgvo002614 for ; Mon, 27 Apr 2009 20:17:42 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3RJHVnT002548 for ; Mon, 27 Apr 2009 20:17:34 +0100 Message-ID: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe> From: "Adrian Farrel" To: References: Date: Mon, 27 Apr 2009 20:17:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:16:40 -0000 Isn't the solution here the same as the one I proposed for "TCM"? Stop using short-cut terms that have definitions in other venues, but for which there is plenty of confusion because different interpretations have grown up over the years (some of them requirement/architecture, some of them solution). Just write down the real, separate, modular functional requirements. These can be partitioned, examined, discussed and agreed. It would really help me personally if one of the proponents of AIS/FDI could set out a list of simple single sentence requirements (just like we have in the requirements I-Ds already). I would then be able to understand exactly what functions are being asked for. It would be my guess, that such a decomposition would also bring an end to the "yes it is," "no it isn't" style of discussion. Cheers, Adrian ----- Original Message ----- From: "Ben Niven-Jenkins" To: "BUSI ITALO" ; "Maarten Vissers" ; ; Cc: Sent: Monday, April 27, 2009 7:11 PM Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) > Italo, > > What this discussion has convinced me of is that we do not have a common > understanding of what AIS is, what it is used for and where it is used. > > Lack of such an understanding is causing confusion. > > For example it is still not clear to me whether when talking about AIS/FDI > we are talking about: > > 1) Injecting an artificial (i.e. Not generated by the client or the > transport path ingress) packet stream into a transport path by some piece > of > equipment along the transport path. > 2) A northbound message from a piece of equipment into the management > system. > 3) Both. > 4) Something entirely different. > > Without such clarity of understanding I don't see how it's possible to > articulate a functional requirement, if such a requirement exists. > > > It is also not clear to me how having some SPs not wanting AIS/FDI and > others apparently[1] wanting it leads to a conclusion it should be turned > on > by default. > > Ben > > [1] No SP I have seen has stated on the list they want it but we are > waiting > for Andy to double check back with his transport experts. > > > On 27/04/2009 18:49, "BUSI ITALO" wrote: > >> Maarten, >> >> I have seen some SPs not willing to deploy AIS/FDI in their network and >> some >> SPs supporting the requirement for AIS/FDI. >> >> As a consequence I think that AIS/FDI (like all OAM features) should be a >> feature optional to use. >> >> However, this discussion has convinced myself that the most appropriate >> approach is to have AIS/FDI enabled by default with the option for the SP >> to >> disable it. >> >> Disabling AIS/FDI, or deploying NEs that does not support the capability, >> has >> the implications you have listed below and as such it should be a >> conscious >> decision from the SP. >> >> Italo >> >> >> ________________________________ >> >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of >> Maarten Vissers >> Sent: Monday, April 27, 2009 2:39 PM >> To: andy.bd.reid@bt.com; lihan@chinamobile.com >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> >> Andy, >> >> Please read my response to your post. I have indicated that your >> understanding >> of existing equipment and protection switching recommendations is >> incorrect. >> >> The use of AIS/FDI and the general agreement that AIS is mandatory (i.e. >> not >> optional) will allow us to use the same fault detection, alarm >> suppression and >> fault localisation as in other transport network technologies (SDH, OTN, >> Ethernet). >> >> If AIS is optional, then operators not using AIS must find other means to >> distinguish between LOC alarm due to a continuity/connectivity fault in >> the >> layer network, or in the server layer. If such other means are not >> deployed >> then there are two alternatives: >> 1) ignore every LOC alarm (assume that it is a server layer fault), until >> the >> customer complains that his/her connection is broken >> 2) start fault localisation on every LOC alarm, and conclude in 90-99% of >> the >> cases that the problem was a server layer fault. >> >> Regards, >> Maarten >> >> ________________________________ >> >> From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] >> Sent: maandag 27 april 2009 13:20 >> To: lihan@chinamobile.com; maarten.vissers@huawei.com >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] Associated bidirectional transport path >> requirements >> >> >> Han, >> >> In his post below, Maarten is not claiming that AIS is needed for alarm >> suppression. He is saying that he sees it being used to distinguish >> faults in >> a server layer from faults in the client layer. As you will see in my >> post >> back to Maarten, this cannot be practically achieved. >> >> I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, >> in the >> packet world of MPLS-TP, AIS/FDI cannot be simple and therefore cannot be >> the >> same as in SONET/SDH. >> >> The objective is to reuse the same basic fault detection, alarm >> suppression, >> and fault localisation as SONET/SDH. This is readily achieved with the CC >> messages in the dataplane. >> >> However, adding AIS/FDI would require a completely new configuration >> management system and a completely new set of fault conditions requiring >> localisation. Ironically, adding a packet AIS/FDI effectively removes the >> compatibility with SONET/SDH management systems and processes. >> >> Andy >> >> >> Andy Reid >> Chief Network Services Strategist >> BT Innovate >> >> Office: +44 (0)1277 322038 >> Mobile: +44 (0)7917 025451 >> Fax : +44 (0)1277 324015 >> Email: andy.bd.reid@bt.com >> >> >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ >> Registered in England no. 1800000 >> This electronic message contains information from British >> Telecommunications >> plc which may be privileged or confidential. The information is intended >> to be >> for the use of the individual(s) or entity named above. If you are not >> the >> intended recipient be aware that any disclosure, copying, distribution or >> use >> of the contents of this information is prohibited. If you have received >> this >> electronic message in error, please notify us by telephone or email (to >> the >> numbers or address above) immediately. >> >> Activity and use of the British Telecommunications plc email system is >> monitored to secure its effective operation and for other lawful business >> purposes. Communications using this system will also be monitored and may >> be >> recorded to secure effective operation and for other lawful business >> purposes. >> >> >> >> >> ________________________________ >> >> From: lihan [mailto:lihan@chinamobile.com] >> Sent: 27 April 2009 02:41 >> To: 'Maarten Vissers'; Reid,ABD,Andy,CXM R >> Cc: mpls-tp@ietf.org >> Subject: ��: [mpls-tp] Associated bidirectional transport path >> requirements >> >> >> >> Support! >> >> AIS/FDI is very importance for network management. MPLS-TP is divided >> into >> three layers in order to enhance the scalability and OAM. It is very >> important >> to distinguish the failure is belong to server layer or client layer. >> AIS/FDI >> is a simple and well-known mechanism to realize alarm suppression and >> fault >> localization. >> >> >> >> >> >> Best regards, >> >> Han Li >> >> ***************************************************** >> >> Han Li, Ph.D. >> >> R&D, CHINA MOBILE COMMUNICATIONS CORPORATION >> >> Tel: +86 10 66006688 ext. 3092 >> >> Fax: +86 10 63601087 >> >> MOBILE: 13501093385 >> >> ***************************************************** >> >> >> ________________________________ >> >> >> ��: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] �� >> Maarten >> Vissers >> ��: 2009��4��25�� 2:15 >> ��: andy.bd.reid@bt.com >> ��: mpls-tp@ietf.org >> ��: Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> Andy, >> >> >> >> AIS/FDI does give additional information. Let me explain: >> >> >> >> The need for AIS/FDI is a consequence of the deployment of loss of >> continuity >> checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of such CCM >> OAM >> is to be able to detect a misconfiguration or fault of a connection >> function >> (fabric) in the connection, which interrupts the forwarding of traffic in >> the >> connection. This is a fault condition that can only be discovered by the >> layer >> network in which the connection is supported. It requires that the >> organization responsible for the layer network takes action (i.e. locate >> the >> layer's connection function that includes the fault) to restore the >> connection. >> >> >> >> Unfortunately, an interruption of one of the link connections of such >> connection (due to a fault in a server layer) will also interrupt the >> forwarding of traffic in the connection. >> >> >> >> As such, loss of CC messages (LOC defect) does not provide sufficient >> information to determine if the configuration in the layer's connection >> functions along the connection have to be checked and corrected. >> >> >> >> AIS has been introduced and is used to help differentiate between the two >> fault cases. >> >> 1) if LOC and AIS are detected, then there is a server layer fault. This >> server layer fault is already reported by the server layer MEP detecting >> this >> fault. No action is required, so no alarm to generate. >> >> 2) if LOC is detected and there is no AIS, then there is a layer network >> fault >> (i.e. continuity fault). Fault localization must be started to locate the >> misconfigured or failed connection function. Once this faulty connection >> function is located, the configuration fault (or hardware fault) can be >> corrected, after which the connection is retored. >> >> >> >> The interruption of the forwarding of traffic in the connection in both >> fault >> cases is however registered as part of performance monitoring. This >> performance monitoring information is used to verify the performance >> against >> the SLA for the connection. >> >> >> >> Regards, >> >> Maarten >> >> >> >> >> ________________________________ >> >> >> From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] >> Sent: vrijdag 24 april 2009 12:34 >> To: maarten.vissers@huawei.com >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Maarten, >> >> >> >> These points are irrelevant to the points I made. My point is that >> AIS/FDI >> gives no information above what is already known - it is only adds >> complexity >> and fault liability. Neither of your points change this. >> >> >> >> Andy >> >> >> >> >> >> Andy Reid >> Chief Network Services Strategist >> BT Innovate >> >> Office: +44 (0)1277 322038 >> Mobile: +44 (0)7917 025451 >> Fax : +44 (0)1277 324015 >> Email: andy.bd.reid@bt.com >> >> >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ >> Registered in England no. 1800000 >> This electronic message contains information from British >> Telecommunications >> plc which may be privileged or confidential. The information is intended >> to be >> for the use of the individual(s) or entity named above. If you are not >> the >> intended recipient be aware that any disclosure, copying, distribution or >> use >> of the contents of this information is prohibited. If you have received >> this >> electronic message in error, please notify us by telephone or email (to >> the >> numbers or address above) immediately. >> >> Activity and use of the British Telecommunications plc email system is >> monitored to secure its effective operation and for other lawful business >> purposes. Communications using this system will also be monitored and may >> be >> recorded to secure effective operation and for other lawful business >> purposes. >> >> >> >> >> >> >> ________________________________ >> >> >> From: Maarten Vissers [mailto:maarten.vissers@huawei.com] >> Sent: 23 April 2009 20:42 >> To: Reid,ABD,Andy,CXM R >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Andy, >> >> >> >>> The problem is *not* about a lack of alarm suppression in the data >>> plane - >>> that information is readily available. >> >> >> >> I don't believe that this is a correct statement in a multi-operator >> transport >> network, or in transport networks of one operator that have more then one >> administrative subdomain (each with its own network management system). A >> problem occuring in admin domain A will be unknown in admin domain B. The >> loss >> of continuaity alarms that are activated in admin domain B due to the >> fault in >> admin domain A will appear as primary alarms, suggesting connectivity >> problems >> in admin domain B. >> >> >> >>> The issue arises because the two sides of maintenance want different >>> things. >>> The fault fixing >> >>> guys want to locate the fault and don't want any other information. The >>> service maintenance >> >>> guys want to know whether their customer service is working. >> >> >> >> This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by >> means of >> the additional SSF alarm. The SSF alarm is for the service guys telling >> them >> that the service was interrupted due to a fault in a server layer. AIS >> suppresses the LOC alarm in those cases so that the maintenance guys >> don't get >> triggered and start looking for a fault that is outside their area. >> >> >> >> Regards, >> >> Maarten >> >> >> >> >> >> >> ________________________________ >> >> >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of >> andy.bd.reid@bt.com >> Sent: woensdag 22 april 2009 12:14 >> To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Liu, >> >> >> >> Allow me to jump in. You are bringing together two things which are >> separate >> and for which AIS/FDI is no help. Maintenance operations are concerned >> with >> two separate things. >> >> >> >> 1) Identifying faults in equipment, line plant, and other systems (eg >> misconfigurations) and fixing them (equipment maintenance). >> >> 2) Identifying the health of end to end connections, especially when >> they are >> directly supporting customer services (service maintenance). >> >> >> >> The problem is *not* about a lack of alarm suppression in the data >> plane - >> that information is readily available. If, at an end equipment, I have a >> good >> server/section layer and a loss of CC at the client layer, I *know* the >> fault >> is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you think >> about, >> if the fault is in the end equipment, it is quite likely that the fault >> means >> it cannot report the traffic loss to the management system!) >> >> >> >> The issue arises because the two sides of maintenance want different >> things. >> The fault fixing guys want to locate the fault and don't want any other >> information. The service maintenance guys want to know whether their >> customer >> service is working. >> >> >> >> This arose in the early days of SONET/SDH, when the operations guys >> demanded >> that the equipment did *not* suppress the traffic alarm even when AIS was >> being received as the service guys want to know about the alarms. The >> normal >> practice is for the equipment to report the alarms *including* AIS and >> then a >> filter is applied in the management system to suppress alarms to the >> fault >> fixing guys. As I'm aware, there are many different techniques applied >> for the >> filtering algorithms, especially when you consider multiple concurrent >> faults >> in a network, however, the existance of AIS/FDI doesn't add anything to >> these >> that's not already known. In fact, I believe simple time-stamp >> correlation is >> one of the most powerful and widely used techniques. And if the equipment >> starts messing up the reporting of loss of CC because it waiting >> for/persistence checking AIS/FDI, it could end up messing up simple >> time-stamp >> correlation! >> >> >> >> In practice, it is often not quite a simple as this, as the service guys >> like >> to be able to 'localise' the fault. However, under most circumstances, >> the >> filter has automatically done this. So localisation you describe is only >> when >> the filter hasn't worked for some reason. >> >> >> >> But the bottom line is, whatever operations process you want to use, >> AIS/FDI >> doesn't add anything other than complexity and fault liability to the >> equipment. Remember AIS goes back to the TDM world where you *have to >> fill the >> bit stream with something*. >> >> >> >> >> >> >> >> Andy >> >> >> >> Andy Reid >> Chief Network Services Strategist >> BT Innovate >> >> Office: +44 (0)1277 322038 >> Mobile: +44 (0)7917 025451 >> Fax : +44 (0)1277 324015 >> Email: andy.bd.reid@bt.com >> >> >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ >> Registered in England no. 1800000 >> This electronic message contains information from British >> Telecommunications >> plc which may be privileged or confidential. The information is intended >> to be >> for the use of the individual(s) or entity named above. If you are not >> the >> intended recipient be aware that any disclosure, copying, distribution or >> use >> of the contents of this information is prohibited. If you have received >> this >> electronic message in error, please notify us by telephone or email (to >> the >> numbers or address above) immediately. >> >> Activity and use of the British Telecommunications plc email system is >> monitored to secure its effective operation and for other lawful business >> purposes. Communications using this system will also be monitored and may >> be >> recorded to secure effective operation and for other lawful business >> purposes. >> >> >> >> >> >> >> ________________________________ >> >> >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of >> liu.guoman@zte.com.cn >> Sent: 22 April 2009 09:15 >> To: Harrison,N,Neil,CXM R >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> >> Neil: >> thank you for wasting more time in describling the problems. but I think >> some >> of what you said is no relations with our problem.for me, maybe AIS/FDI >> functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there >> is no >> AIS/FDI functions, when there is a defects in a given layer network, it >> can >> cause multiple alarm events to be raised. it is diffcult for operators >> to >> locate and diagnose the faults. >> though I completely agree you on adding new things and functions will >> bring >> some complexity . but if we have no functions, it is more complex and >> difcult >> for operators to maintence and administrator the network. so I think >> every new >> functions and things may have positive and negative effects. but we >> should >> consider it very much, don't delete some functions at random. >> >> >> best regards >> liu >> >> >> >> >> >> 2009-04-21 20:30 >> >> �� >> >> , >> >> �� >> >> >> >> �� >> >> RE: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> >> >> >> >> Liu, >> >> If MPLS-TP is going to be taken seriously as a transport network (like >> SDH/SONET) then the 2 key MUST HAVE requirements are these. >> >> 1 Provide a transparent client/server relationship...which means: >> - all client bits treated equally >> - client bit ordering preserved >> - no attempt to infer client symbol (ie sequence of client bits) >> meaning >> and no attempt to change client symbols >> - the traffic behaviour of client X must not impact the performance >> experienced by client Y >> >> A key corollary of the above is that MPLS-TP must only support proper >> connections (ie single source constructs) >> >> >> 2 Since MPLS-TP is a transport network it is not a top-of-stack network >> (ie >> it does not support directly external message/file/stream applications). >> MPLS-TP therefore does not require an E-NNI specification. A key >> corollary of >> this is that MPLS-TP will not have any peer interworking relationship >> with any >> other network mode/technology. >> >> >> Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this should >> have >> FDI/AIS....however, the merit of this is highly questionable. When I and >> colleagues discussed whether PBB-TE (also a co-ps mode network) should >> have >> FDI/AIS we concluded that on balance it was not a good idea.....and note >> that >> initially I was in favour of having AIS, but my colleagues provided >> strong >> technical arguments that convinced me otherwise. >> >> AIS/FDI is historically linked to the early PDH co-cs mode layer networks >> that >> used TTL logic. When this died it put out a +5V (all 1s) signal by >> default, >> ie it required no conscious effort to generate it.....this is key point. >> Further, in these networks there is a fairly static/long-holding client >> server >> relationship. Clearly this is not true in the cl-ps mode and it's why >> IETF >> have never specified AIS for IP and its why IEEE had the good sense to >> throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO >> retained >> it in Y.1731....but I suspect any operator planning to use Ethernet >> equipment >> would always look to IEEE stds and not ITU ones). >> >> AIS/FDI and the co-ps mode is debatable. As I noted above, on balance we >> considered not a good idea for PBB-TE OAM because it requires a conscious >> effort to generate it (unlike the co-cs mode) so there are likely to be >> scaling problems and its one more thing to go wrong. >> >> You should also have seen me make the point many times in the past that >> the >> always-on defect detection/handling OAM needs to be as simple/sparse as >> possible with as little config as possible because we need super >> reliability......TCM goes completely against the grain here. Also note >> that >> the OAM required for each of the 3 network modes is not the same, despite >> what >> some claim. >> >> regards, Neil >> >> >> >> ________________________________ >> >> >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of >> liu.guoman@zte.com.cn >> Sent: 21 April 2009 02:59 >> To: BRUNGARD, DEBORAH A, ATTLABS >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> >> Deborah: >> maybe what you said is right. but I can't completely agree your opinions. >> IMO. >> mpls-tp is regard as transport network like SDH/SONET. so it should have >> AIS/FDI fuctions as SDH/SONET. >> >> do you think so. >> >> best regards >> liu >> >> "BRUNGARD, DEBORAH A, ATTLABS" >> ��: mpls-tp-bounces@ietf.org >> >> 2009-04-20 23:47 >> >> >> >> �� >> >> "Maarten Vissers" , >> >> �� >> >> mpls-tp@ietf.org >> >> �� >> >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> >> >> >> >> >> I agree with Neil, it is very questionable the value of AIS/FDI in a >> packet network- any mode. It can result in a DoS attack by an operator >> on themselves so even Y1731 recommends not to block data frames: >> "A MEP can decide whether it blocks data frames when it detects dAIS. >> The principle requirement >> that influences this decision is that data frames ought to be forwarded >> as much as possible, without >> the possibility of forwarding wrong data frames downstream." >> Table I.7-2 shows for AIS, not to block. >> >> And as Y1731 states, AIS can only be used under very constrained >> architectures - if required for MPLS-TP, it needs to have the same >> guidance as in Y1731, i.e. point-to-point and server/client one-to-one: >> "for a point-to-point ETH connection, a MEP has only a single peer MEP. >> Therefore, there >> is no ambiguity regarding the peer MEP for which it should suppress >> alarms when it receives the >> ETH-AIS information." >> So should only be within one domain - then no need. >> >> Deborah >> >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of Maarten Vissers >> Sent: Monday, April 20, 2009 10:05 AM >> To: neil.2.harrison@bt.com >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] Associated bidirectional transport path >> requirements >> >> Neil, >> >>> but AIS/FDI in the cl mode?...do me a favour! >> >> Ethernet AIS is indeed a requirement and a necessity. And you will not >> be >> able to understand that as long as you refuse to accept that "cl-mode" >> is a >> forwarding mode within a **transport entity**. G.800 amendment 1 has >> finally >> reintroduced this transport entity into G.800. Besides that, it also >> introduced the **differentiated connection**: >> >> [G.800 am1] "A differentiated connection is a transport entity that >> transfers information belonging to multiple communications between ports >> across a subnetwork. <..> In a differentiated connection message >> contents >> are interpreted to identify (sets of) communications which receive >> different >> treatment. The sets of communications may be distinguished by the >> forwarding identifier or other layer information. Order is not >> necessarily >> preserved between messages belonging to sets of communications receiving >> different treatment. Sets of communications may be identified for >> purposes >> such as traffic conditioning or preserving communication message order." >> >> >> Ethernet VLANs are in terms of G.800 "differentiated connections". >> Ethernet >> AIS provides AIS within the scope of such "differentiated connection". >> If >> you apply this to my proposed PTN layer stack, then the EVC layer >> topology >> will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and >> P-OTN >> VP trails inside metro and core domains interconnecting EVC matrices. >> When >> one of those EVC links is interrupted, e.g. in the core between metro 1 >> and >> metro 4 (see attached slide), then the EVC differentiated connection >> that is >> present on this link will be interrupted. At the EVC switch/bridge node >> in >> metro 4 this interruption is noticed and EVC-AIS is inserted in the >> downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 >> and >> D5. >> >> The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, >> which guarantees that the AIS is broadcast to the endpoints of the EVC. >> >> I believe that it is time for you to adapt your view on co and cl modes >> and >> relate it to the forwarding mode **INSIDE** a transport entity. >> >> What we know as the internet is essentially an "IP differentiated >> connection" with a billion or more ports. >> What we know as an IP VPN is essentially an "IP differentiated >> connection" >> with e.g. n ports (n in the range of e.g. 2 to 1000). >> What we know as an Ethernet VLAN is essentially an "Ethernet >> differentiated >> connection" with n ports (n in the range of e.g. 2 to 1000). >> What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated >> connection" with 2 ports. >> What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. >> >> Transport network OAM applies to transport entities, which are (in terms >> of >> G.800 am1) connections and differentiated connections. >> >> Regards, >> Maarten >> >> -----Original Message----- >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: vrijdag 17 april 2009 22:00 >> To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; >> Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] Associated bidirectional transport path >> requirements >> >> John, Thanks this is a great platform to explain why OAM for the 3 >> network >> modes needs to be different. I am getting a wee bit tired of folks >> trying >> to make all 3 network modes look alike (and then, even worse, interwork >> them >> as as peers...esp when not not top-of-stack >> networks...I mean how silly can we get?). I am even more frustrated by >> the fact those peddling this FUD only ever seem to consider OAM and >> forget >> all other DP/CP/MP components (esp top-of-stack message/file/stream >> application adaptations). How wrong can this get! >> >> In the co modes a *connection* is a very specific and *constraining* >> construct.....I am assuming here we respect the rules of a connection >> (ie >> single source) though some folks don't even bother to respect this, and >> this >> is despite the fact that we all know what problems multiple-source >> constructs can cause (from LDP/PHP....ergo MPLS-TP). >> >> When we have a connection this restricts *all* DP (ie traffic and OAM) >> to >> stay within the bounds of the connection. Which is fine under >> defect-free >> conditions, but if we have leaking traffic then the constraining nature >> of >> the connection construct is broken. In a nutshell what this means is >> that >> OAM that is of a request/response nature cannot be trusted in co mode >> networks under misconnectivity defects.....indeed, why should a leaking >> DP >> have a symmetric go/return defect behaviour?....very likely it won't. >> So >> whilst request/response OAM is right for the cl mode it is not right for >> the >> co mode under misconnectivity defect conditions. >> >> More generally the 3 modes are different and not just in OAM >> requirements....but AIS/FDI in the cl mode?...do me a favour!...at least >> IEEE had the good sense to bin this for Ethernet even though it remains >> in >> Y.1731. And which is why I often trot-out the rather silly (to have to >> say >> this) observation that if IP (cl mode) could do it all then why have >> IETF >> found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The >> answer lies in the physics...and G.800 attempts to explain that >> physics....G.805 does not. >> >> So, the 3 modes are different...please accept/rejoice in this fact as >> they >> all offer something different/important. But do not be hoodwinked by >> those >> who peddle a story that that tries to make the OAM of the 3 modes the >> same. >> >> regards, Neil >> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >>> Sent: 17 April 2009 20:02 >>> To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>> requirements >>> >>> Italo, >>> >>> As described in the MPLS TP OAM Requirements I-D, virtually all of the >> >>> OAM functions require a return path, and in the absence of a return >>> path they are disabled. >>> >>> As described in David Sinicrope's meeting minutes >>> (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >>> meeting-no >>> tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an >>> MPLS TP network needs to be capable of getting IP packets from >>> destination to source; neither the minutes nor I stipulate that a >>> control plane needs to be used to instantiate this forwarding. >>> >>> As an aside, the issue of return path for unidirectional LSPs could be >> >>> charaterized as the elephant in the room. In the MPLS TP OAM >>> Framework I-D, unicast LSPs are only mentioned three times and return >>> paths not at all. >>> >>> Thanks, >>> >>> John >>>> -----Original Message----- >>>> From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >>>> Sent: Friday, April 17, 2009 1:59 AM >>>> To: Drake, John E; Alexander Vainshtein; Maarten Vissers >>>> Cc: mpls-tp@ietf.org >>>> Subject: RE: [mpls-tp] Associated bidirectional transport path >>>> requirements >>>> >>>> John, >>>> >>>> I might have missed the agreement of MPLS-TP being capable of >>>> sending replies to OAM requests sent on uni-directional LSPs. >>>> >>>> This requirement does not belong to the first set of requirements >>>> ITU-T is expecting to be met by October. >>>> >>>> However, I think this in a potential interesting additional >>>> requirement to be taken into account (at worst in a >>> subsequent phase). >>>> >>>> I think that this requirement needs to be evaluated versus other >>>> more important requirements (e.g. the possibility to work w/o IP >>>> forwarding and the need for OAM to continue to monitor the data >>>> plane also in case of failures affecting the control or management >>>> plane). >>>> >>>> I am open to discuss it but not sure this is the right time because >>>> I wish to avoid delaying the first phase of the design solution. >>>> >>>> Thanks, Italo >>>> >>>>> -----Original Message----- >>>>> From: mpls-tp-bounces@ietf.org >>>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E >>>>> Sent: Thursday, April 16, 2009 8:00 PM >>>>> To: Alexander Vainshtein; Maarten Vissers >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>>>> requirements >>>>> >>>>> At the meeting last fall at Juniper in Massachusetts, I >>>> think it was >>>>> agreed that an MPLS TP network needs to have a forwarding >>>> capability >>>>> for management, control, and OAM packets (e.g., sending >>>> replies to OAM >>>>> requests sent on uni-directional LSPs) even if it does not >>>> have an IP >>>>> forwarding data plane. >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexander Vainshtein >>>>> [mailto:Alexander.Vainshtein@ecitele.com] >>>>>> Sent: Thursday, April 16, 2009 9:57 AM >>>>>> To: Maarten Vissers >>>>>> Cc: mpls-tp@ietf.org >>>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>>>>> requirements >>>>>> >>>>>> Maarten, >>>>>> It seems that you've just (implicitly and, probably, >>>>>> inadvertently) stated the following: >>>>>> >>>>>> MPLS-TP OAM will not ever support MIP loopback >>>>>> function >>>> (and fault >>>>>> localization which requires this function ) for >>>> unidirectional P2MP >>>>>> and P2P paths. >>>>>> >>>>>> If this statement is correct, this (IMHO and FWIW) >>> raises a valid >>>>>> question: >>>>>> >>>>>> Is MPLS-TP an appropriate solution for these >>> types of transport >>>>>> paths? >>>>>> >>>>>> For the reference, IP/MPLS provides this kind of >>>> functionality today >>>>>> for (unidirectional - but it does not know any other >>>> type) P2P LSPs >>>>>> as described in RFC 4379. And its extension to P2MP LSPs seems >>>>>> easy... >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Sasha >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] >>>> On Behalf >>>>>> Of Maarten Vissers [maarten.vissers@huawei.com] >>>>>> Sent: Thursday, April 16, 2009 3:24 PM >>>>>> To: 'Adrian Farrel' >>>>>> Cc: mpls-tp@ietf.org >>>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>>>>> requirements >>>>>> >>>>>> Adrian, >>>>>> >>>>>>>> >>>>>>>> The intermediate nodes (including MEPs, MIPs and >>>>>> other internal >>>>>>>> functions as appropriate) of a co-routed >>>>>> bidirectional transport >>>>>>>> path at each (sub-)layer MUST be aware of the pairing >>>>>>>> relationship of the forward and the backward >>>>>> directions of that >>>>>>>> transport path. >>>>>>>> >>>>>>> >>>>>>> There is no way this is a functional requirement. That >>>>> is, there is >>>>>>> *nothing* that can be observed from a black box point of >>>>> view that >>>>>>> results from adhering to this requirement. >>>>>> >>>>>> Your understanding is not correct. It is very much >>> observable if >>>>>> this requirement is met from a black box point of view. >>>>>> The MIP functions can only perform the Loopback when there is a >>>>>> co-routed bidirectional transport path. The MPLS-TP LBM packet >>>>>> received at a MIP needs to be returned (as LBR >>>>>> packet) to the originating MEP function via the other >>>> direction of >>>>>> the co-routed bidirectional transport path. This other >>> direction >>>>>> would not be available in an associated bidirectional transport >>>>>> path... and thus the loopback test >>>>> would fail. >>>>>> >>>>>> Similarly, when we have to apply TCM MEPs to monitor a >>>> segment, then >>>>>> this is possible in a co-routed bidir transport path >>> but not in a >>>>>> associated bidir transport path. In the first case the TCM MEP >>>>>> Source and Sink functions are co-located and can >>> exchange what is >>>>>> called "remote information" which is necessary for performance >>>>>> monitoring. >>>>>> In the latter case the TCM MEP Source and Sink functions >>>> are in e.g. >>>>>> different nodes in the network and TCM would not be able >>>> to provide >>>>>> performance monitoring. >>>>>> >>>>>>> The entirety of the bracketted text "(including MEPs, >>>>> MIPs and other >>>>>> internal >>>>>>> functions as appropriate)" should be deleted. It does not >>>>>> add to "The >>>>>>> intermediate nodes." >>>>>> >>>>>> Your understanding is not correct. This text must not be >>>> deleted at >>>>>> all. >>>>>> >>>>>>> Actually, I am quite fed up about this persistent >>>>> insistence on the >>>>>> inclusion >>>>>>> of "Tandem Connection." The definition within the ITU-T of >>>>>> this term >>>>>>> is >>>>>> poorly >>>>>>> specified and comes from the monitoring of a path that is >>>>>> parallel (i.e. >>>>>> tandem) >>>>>>> to the data path being monitored. This definition of TC >>>>>> seems to be at >>>>>> variance, >>>>>>> and would be if the ACH was actually in band. >>>>>> >>>>>> I don't understand where your interpretation of tandem >>>> connection is >>>>>> described in ITU-T recommendations. I.e. "from the >>>> monitoring of a >>>>>> path that is parallel (i.e. tandem) to the data path being >>>>>> monitored."? >>>>>> >>>>>> There is a "network connection" and this network >>>> connection is a set >>>>>> of interconnected "link connections" and "matrix >>> connections". A >>>>>> subset of those interconnected link connections and matrix >>>>>> connections can be monitored and is then referred to as >>> a "tandem >>>>>> connection". There is no "path that is parallel to the >>>> data path". >>>>>> There is only additional OAM inserted inside the data >>> path by the >>>>>> TCM MEP_So function and this OAM is extracted from the >>>> data path by >>>>>> the TCM MEP_Sk function. >>>>>> >>>>>> Regards, >>>>>> Maarten >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-tp-bounces@ietf.org >>>>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel >>>>>> Sent: donderdag 16 april 2009 11:59 >>>>>> To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com >>>>>> Cc: BUSI ITALO; mpls-tp@ietf.org >>>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>>>>> requirements >>>>>> >>>>>> Hi Sasha, >>>>>> >>>>>>> Unfortunately I cannot fully agree with your statement: >>>>>>> >>>>>>> >>>>>>> From the point of view of hardware, co-routed >>>>> bidirectional LSPs >>>>>>> are a special case of associated bidirectional LSPs. >>>>>>> >>>>>>> >>>>>>> This statement would be obviously correct, were it not for >>>>>> Requirement >>>>>>> 34 in the latest MPLS-TP requirements draft >>>>>> >>>>>> OK. Got it. >>>>>> >>>>>> But what is this doing in the data plane requirements section? >>>>>> >>>>>> In fact, what is this requirement actually saying? >>>>>> >>>>>>> >>>>>>> The intermediate nodes (including MEPs, MIPs and >>>>> other internal >>>>>>> functions as appropriate) of a co-routed >>>>>> bidirectional transport >>>>>>> path at each (sub-)layer MUST be aware of the pairing >>>>>>> relationship of the forward and the backward >>>>>> directions of that >>>>>>> transport path. >>>>>>> >>>>>> >>>>>> There is no way this is a functional requirement. That >>>> is, there is >>>>>> *nothing* that can be observed from a black box point of >>>> view that >>>>>> results from adhering to this requirement. >>>>>> >>>>>> Therefore it could be assumed that this requirement is met by >>>>>> configuring some data plane database component through the >>>>>> management plane. The database component is not used >>> for anything >>>>>> except to satisfy this requirement for "awareness". >>>>>> >>>>>> Ben! Can we please try to rewrite this requirement in terms of >>>>>> behavior? >>>>>> >>>>>>> Please note that Requirement 34 is the ONLY item in the >>>>>> list that is >>>>>>> specific for co-routed bidirectional LSPs. (The pairing >>>>>> requirements >>>>>>> at end points for co-routed and associated bidirectional >>>>> paths are >>>>>>> exactly the same even if they appear in two different >>>>> items in the >>>>>>> requirements' list). >>>>>>> In other words, without Requirement 34 the notion of >>> co-routed >>>>>>> bidirectional paths would be void of any data plane content. >>>>>>> >>>>>>> The somewhat vague scope of this requirement ("other internal >>>>>>> functions as appropriate") creates a suspicion that HW >>>>>> support of the >>>>>>> pairing awareness may be required in order to comply with it. >>>>>> >>>>>> The entirety of the bracketted text "(including MEPs, >>>> MIPs and other >>>>>> internal functions as appropriate)" should be deleted. It >>>> does not >>>>>> add to "The intermediate nodes." >>>>>> >>>>>>> The following text in the draft increases this suspicion: >>>>>>> >>>>>>> >>>>>>> Tandem Connection: A tandem connection is an >>>> arbitrary part of a >>>>>>> transport path that can be monitored (via OAM) >>>>>> independently from the >>>>>>> end-to-end monitoring (OAM). It may be a monitored >>>> segment or a >>>>>>> monitored concatenated segment of a transport path. >>>> The tandem >>>>>>> connection may also include the forwarding engine(s) of >>>>>> the node(s) >>>>>>> at the edge(s) of the segment or concatenated segment. >>>>>>> >>>>>> >>>>>> Actually, I am quite fed up about this persistent >>>> insistence on the >>>>>> inclusion of "Tandem Connection." The definition within >>>> the ITU-T of >>>>>> this term is poorly specified and comes from the >>> monitoring of a >>>>>> path that is parallel (i.e. tandem) to the data path being >>>>>> monitored. This definition of TC seems to be at variance, >>>> and would >>>>>> be if the ACH was actually in band. >>>>>> >>>>>>> Doesn't "forwarding engine" sound like hardware to you? >>>>>> >>>>>> Yes, but so what? >>>>>> >>>>>>> IMHO it is worth noting that neither the MPLS-TP >>>>> Requirements draft >>>>>>> nor the MPLS-TP OAM requirements one >>>>>>> >>>>>> >>>>> >>>> >>> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen >>>>>>> ts-01.txt) contain any requirements dealing with tandem >>>>> connections. >>>>>>> >>>>>>> But tandem connections are discussed in the MPLS-TP OAM >>>> Framework >>>>>>> draft >>>>>> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >>>>>> amework-00.txt >>>>>> ). >>>>>> >>>>>> Right. >>>>>> Let's just get rid of an unnecessary term and bring all >>> the I-Ds >>>>>> into line. >>>>>> >>>>>>> The bottom line, IMHO, is that some clarity regarding >>>>> co-routed vs. >>>>>>> associated >>>>>>> bidirectional paths is still required. One way to provide >>>>>> that could >>>>>>> be by explicitly limiting Requirement 34 to specific >>>>> functionality. >>>>>> >>>>>> Agreed. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: Adrian Farrel [adrian@olddog.co.uk] >>>>>> Sent: Thursday, April 16, 2009 12:13 AM >>>>>> To: Alexander Vainshtein; Lou Berger; BUSI ITALO >>>>>> Cc: mpls-tp@ietf.org >>>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path >>>>>> requirements >>>>>> >>>>>> Hi Sasha, >>>>>> >>>>>> Not really sure whether you are misrepresenting anyone, but... >>>>>> >>>>>>> 1. My reading of one of Ben's messages is that associated >>>>>>> bidirectional paths are the only types of paths that can be >>>>>> created in >>>>>>> the existing networks; "true" co-routed bidirectional paths >>>>>> will have >>>>>>> to wait until (if ever) new equipment becomes available. >>>>>> >>>>>> This is clearly nonsense! >>>>>> From the point of view of hardware, co-routed >>>> bidirectional LSPs are >>>>>> a special case of associated bidirectional LSPs. >>>>>> >>>>>> If you can set up two unidirectional LSPs (e.g. using the >>>> management >>>>>> plane) you can surely set up a co-routed >>>>> bidirectional LSP. >>>>>> >>>>>> There are shipping solutions that achieve co-routed >>> bidirectional >>>>>> LSPs using the control plane. These either use the GMPLS >>>> (which is >>>>>> cleaner) or non-standard proprietary solutions (which is >>>> messy but >>>>>> functional). >>>>>> >>>>>> But (of course) the management plane or control plane >>>> solutions have >>>>>> nothing to do with availability of equipment as they >>> are software >>>>>> solutions. >>>>>> >>>>>>> 2. My reading of one of Neil's messages is that the actual >>>>>> driver for >>>>>>> co-routed bidirectional paths may be experience with existing >>>>>>> transport networks rather than any specific benefit. >>>>>> >>>>>> Isn't that the case with 75% of the MPLS-TP requirements? >>>>>> Which is not to say it is a bad thing. >>>>>> >>>>>> A large driver for MPLS-TP is to give the packet network >>>> the look, >>>>>> feel, and behavioral characteristics of a "legacy" >>>>>> transport network. >>>>>> >>>>>>> Based on these observations, I'd guess (FWIW) that: >>>>>>> * associated bidirectional paths are, at least for the time >>>>>>> being, the most important type of bidirectional paths in >>>>>>> MPLS-TP >>>>>> >>>>>> I think that is wrong both given my statement above, and >>>> given that >>>>>> other upgrades to existing MPLS solutions will be >>> needed to reach >>>>>> the full function level of MPLS-TP. >>>>>> >>>>>>> * they had a good chance to remain the only type of >>>> bidirectional >>>>>>> paths in real deployments. >>>>>> >>>>>> I don't see what that follows from. >>>>>> >>>>>> Cheers, >>>>>> Adrian >>>>>> >>>>>> _______________________________________________ >>>>>> mpls-tp mailing list >>>>>> mpls-tp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>>> >>>>>> _______________________________________________ >>>>>> mpls-tp mailing list >>>>>> mpls-tp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> >>>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail >> is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy >> and are >> not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and >> intended >> solely for the use of the individual or entity to whom they are >> addressed. If >> you have received this email in error please notify the originator of the >> message. Any views expressed in this message are those of the individual >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail >> is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy >> and are >> not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and >> intended >> solely for the use of the individual or entity to whom they are >> addressed. If >> you have received this email in error please notify the originator of the >> message. Any views expressed in this message are those of the individual >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From dbrungard@att.com Mon Apr 27 13:59:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6983A6BAC for ; Mon, 27 Apr 2009 13:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.055 X-Spam-Level: X-Spam-Status: No, score=-105.055 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55u0X6ei3iNr for ; Mon, 27 Apr 2009 13:59:17 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 46E123A6A79 for ; Mon, 27 Apr 2009 13:59:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-11.tower-167.messagelabs.com!1240866035!20171570!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 17458 invoked from network); 27 Apr 2009 21:00:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Apr 2009 21:00:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3RL0Y8j026721; Mon, 27 Apr 2009 17:00:35 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3RL0R0w026651; Mon, 27 Apr 2009 17:00:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C77B.2EA8C93D" Date: Mon, 27 Apr 2009 17:00:22 -0400 Message-ID: In-Reply-To: <787be2780904271146hcff7e94xca5da9384f16d92e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Thread-Index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAA References: <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com><000501c9c704$5cf7cc70$6c02a8c0@china.huawei.com> <787be2780904271146hcff7e94xca5da9384f16d92e@mail.gmail.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Greg Mirsky" , "Maarten Vissers" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 20:59:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C77B.2EA8C93D Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, =20 I think you have oversimplified the discussion in MEF and in so doing = have inaccurately summarized. As Greg says, MEF is oriented towards = services (SLA/SLS) and they also recognize that some operators only need = simple troubleshooting tools. Considering the on-going discussion in = MEF, for the service operators group, it is questionable if Y1731 should = be used by MPLS-TP as a baseline as it is considered inadequate. And I = don=A1=AFt see AT&T=A1=AFs requirements as any different from BT. I = think we should follow Adrian=A1=AFs and Ben=A1=AFs proposal to define = the actual requirements for MPLS-TP before replicating other = technologies=A1=AF solutions. =20 And the UNI/ENNI being discussed there is not comparable to your = definition. =20 Deborah =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) =20 Dear Maarten, you definitely know but I'd note that MEF formulates requirements for = Carrier Ethernet as a service, i.e. client layer of a transport network, = not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, = in my view, to MPLS-TP, at least not automatically.=20 Regards, Greg Mirsky 2009/4/27 Maarten Vissers Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don't > use the others). Your company for some years has been asking for less, > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from = those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market > segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must >> not blindly recreate SDH/SONET. If we do so without consideration to >> how operators' needs and requirements may have evolved (and continue >> to evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents of >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =20 ------_=_NextPart_001_01C9C77B.2EA8C93D Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, I think you have oversimplified the discussion in MEF and = in so doing have inaccurately summarized. As Greg says, MEF is oriented = towards services (SLA/SLS) and they also recognize that some operators only need = simple troubleshooting tools. Considering the on-going discussion in MEF, for = the service operators group, it is questionable if Y1731 should be used by MPLS-TP = as a baseline as it is considered inadequate. And I don=A1=AFt see = AT&T=A1=AFs requirements as any different from BT. I think we should follow Adrian=A1=AFs and = Ben=A1=AFs proposal to define the actual requirements for MPLS-TP before replicating other technologies=A1=AF solutions. And the UNI/ENNI being discussed there is not comparable = to your definition. Deborah From:= mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Dear Maarten, you definitely know but I'd note that MEF formulates requirements for = Carrier Ethernet as a service, i.e. client layer of a transport network, not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Tom, This AIS discussion has been held in previous technologies as well, = e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not = insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those = of other operators participating in this effort? I see the requirements for OAM that have been = expressed in this mpls-tp discussion by BT representatives to be different from the = requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, = FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed = by BT representatives. I see that MEF is requesting to support in Y.1731 = frame loss counting for more then one priority level; i.e. an extension of = the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) = have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, as those networks are "not top of stack". I see that many = operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services= .html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadban= d_Access_Service.html ); i.e. a peer-interconnection case and a potential case for TCM, a = case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to = BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) = where those represent the characteristics of the main services (data, = voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope = of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the = number > of nodes outside your network is factors larger then the number = of > nodes inside your network. My experience is that different = operators > have different sets of requirements. Manufacturers have to support = the > superset of those requirements. Each operator will then deploy = the > subset of provided features that fits its needs (and turn off or = don't > use the others). Your company for some years has been asking for = less, > other operators have been asking for more. Manufacturers thus = build > their products with lots of configurability to support all = variations. Do you see our = (BT's) requirements to be very divergent from those of other operators participating in this effort? Unless our requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established = features > like AIS, TCM, frame loss counting, delay measurement, loopback, = etc > before the majority of operators have agreed that such features = are > not longer necessary. Again, that is = your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), = what they require after they have been plainly clear about what they = want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and = achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with = those > opinions. > > I apologise for being direct (and possibly rude) but I am = getting > tired of being told by folks who do not represent operators = what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service = to > 173 countries with over 200 000 customer ports I have (off the top = of > my > head) > at least another 10 MPLS networks in specific countries covering = at > least 3 continents delivering dedicated services to particular = market > segments. > > I have an extremely large SDH network in the UK consisting of over = 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service = in > 110 countries. > > I would like to think my BT colleagues and I might know a = little > something about building large scale networks and the requirements = of > those networks and the needs of the customers that I deliver = services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues = in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.c= om > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a = more >> reliable and effective, easy to operator and easy to manage = packet >> transport network like me. but why not apply this SDH/SONET in = the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because = it >> have a complex OAM functions. while more people like to move = the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we = should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins <benjamin.niven-jenkins@bt.c= om> >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> <liu.guoman@zte.com.cn>, "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com> >> =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path = requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree = your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. = so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport = networks >> supporting the needs of operators today and in the future. We = must >> not blindly recreate SDH/SONET. If we do so without = consideration to >> how operators' needs and requirements may have evolved (and = continue >> to evolve in future) we will have failed IMO and I would = severely >> question the value of the work we will have produced. If we = just >> recreate SDH/SONET then what is the purpose of the work an = operator >> would be better off just deploying existing SDH/SONET = equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in = this >> mail is solely property of the sender's organization. This = mail >> communication is confidential. Recipients named above are = obligated >> to maintain secrecy and are not permitted to disclose the = contents of >> this > communication to others. >> This email and any files transmitted with it are confidential = and >> intended solely for the use of the individual or entity to whom = they >> are addressed. If you have received this email in error please = notify >> the originator of the message. Any views expressed in this = message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE = Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp<= /o:p> _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp<= /o:p> ------_=_NextPart_001_01C9C77B.2EA8C93D-- From hhelvoort@chello.nl Mon Apr 27 14:13:32 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB613A6AD0 for ; Mon, 27 Apr 2009 14:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M4t8cAmPMoW for ; Mon, 27 Apr 2009 14:13:31 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id D58AF3A69C4 for ; Mon, 27 Apr 2009 14:13:30 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090427211449.ODPD29379.viefep17-int.chello.at@edge02.upc.biz>; Mon, 27 Apr 2009 23:14:49 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge02.upc.biz with edge id klEo1b00X3KDBhC02lEpiU; Mon, 27 Apr 2009 23:14:49 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49F62047.4000308@chello.nl> Date: Mon, 27 Apr 2009 23:14:47 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: andy.bd.reid@bt.com References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:13:32 -0000 Hi Andy, You wrote: > It is of course true that adding a boolean input to a logical system > increases the number of possible input states. So adding an AIS boolean > to CC boolean creates four possible states not just the three you > identify below. There are > > - good CC, no AIS > - CC fault, AIS present > - good CC, AIS present > - CC fault, no AIS > > We must ask what practical scenarios could generate each of these input > states. [hvh] we should also wonder wheter *all* OAM is provisioned correctly > Good CC, no AIS > One hopes this is because this is because the service is working properly. [hvh] it may be interpreted that CC and AIS are provisioned correctly > CC fault, AIS present > One hopes this is because the service is faulty and one hopes this is > because of a fault in a server layer. In fact, the presence of the AIS > could be misleading (see below). [hvh] one also hopes that CC is correctly (if at all) provisioned, in fact the absence of CC could be equally misleading If both CC and AIS are both enabled this state indicates a second fault: AIS because of a fault in a lower layer, CC absent because of a fault in this layer. > Good CC, AIS present > This situation could arise because of a misconfiguration of the AIS > forwarding label injection table. And there are a number of scenarios > which make this quite likely when protection switching occurs. Depending > on the exact scope of the forwarding labels, a protection switch may > well require the proactive purging of entries from the AIS forwarding > label injection table following the protection switch (this could > equivalently been seen as the forwarding function proactively dropping > the AIS packets). [hvh] if the insertion of AIS is a consequent action to a detected defect *not* configured by management, this state means that in this layer transport is OK, *and* the Ops does not have to take repair actions. Insertion of consequent AIS can be enabled/disabled by provisioning. > CC fault, no AIS > As you suggest, this could arise from a misconfiguration of a forwarding > function. But it could equally arise from a misconfiguration of the AIS > forwarding label injection table. In fact, the latter actually seems > just as likely and particularly problematic for maintenance. Unlike > normal forwarding, any mismatch between the forwarding configuration and > the AIS forwarding label injection table will lie dormant and until a > server fault arises. Then this generates a false and misunderstood fault > condition with maintenance looking for the fault in the wrong place. [hvh] one hopes that CC generation and AIS injection are enabled > The first two states can be reliably diagnosed with CC alone. The second > two arise from the introduction of the AIS/FDI. [hvh] the second and fourth are only reliable if CC is enabled. > However, any possible > benefit that might arise is completely masked by the fact that the AIS > itself must be configured and there is no reason for this to be more > reliable than what it is supposed to be monitoring. Indeed, there seems > good reason to think that it will be less reliable. [hvh] the enabling of CC generation and the enabling of AIS insertion make both equally reliable. > There is no avoiding that AIS in circuit switching is fundamentally > different from AIS in packet switching. > - in circuit switching, you must fill the bit stream with something and > the information injected requires no configuration whatsoever. [hvh] AIS insertion as consequent action has to be provisioned. > - in packet switching, no packets is a perfectly valid condition and > the injection of AIS requires individual client connection specific > information to be configured. [hvh] AIS injection is a consequent action, the injection has to be enabled, a one time action, and not per detected defect > The objective is not to replicate the data plane primitives of > SONET/SDH, but the triggers to the operational systems so that the > operational systems and processes are the same. [hvh] I think that the requirement is that a server layer shall inform its clients that it has detected a service interuption to ensure that the clients can inhibit (unnecessary) alarms. Regards, Huub, Senior Researcher & Developer -- ================================================================ Always remember that you are unique...just like everyone else... From John.E.Drake2@boeing.com Mon Apr 27 14:21:23 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C2B28C152 for ; Mon, 27 Apr 2009 14:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.405 X-Spam-Level: X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao9dqwDveo+p for ; Mon, 27 Apr 2009 14:21:15 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 635163A680D for ; Mon, 27 Apr 2009 14:21:15 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3RLMJWA003936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Apr 2009 14:22:20 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3RLMJRc014735; Mon, 27 Apr 2009 16:22:19 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3RLMDPa014517; Mon, 27 Apr 2009 16:22:19 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 14:22:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 14:22:10 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01ABAB0B@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) Thread-Index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAAE1mIA= References: <6CDF736E-25F5-4CB9-A05F-6AF2904EF034@lucidvision.com><000501c9c704$5cf7cc70$6c02a8c0@china.huawei.com><787be2780904271146hcff7e94xca5da9384f16d92e@mail.gmail.com> From: "Drake, John E" To: "BRUNGARD, DEBORAH A, ATTLABS" , "Greg Mirsky" , "Maarten Vissers" X-OriginalArrivalTime: 27 Apr 2009 21:22:13.0739 (UTC) FILETIME=[3BA733B0:01C9C77E] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:21:23 -0000 inline > -----Original Message----- > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 > Sent: Monday, April 27, 2009 2:00 PM > To: Greg Mirsky; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in=20 > circles(Re:Associated bidirectional transport path requirements) >=20 > Maarten, >=20 > =20 >=20 > I think you have oversimplified the discussion in MEF and in=20 > so doing have inaccurately summarized. As Greg says, MEF is=20 > oriented towards services (SLA/SLS) and they also recognize=20 > that some operators only need simple troubleshooting tools.=20 > Considering the on-going discussion in MEF, for the service=20 > operators group, it is questionable if Y1731 should be used=20 > by MPLS-TP as a baseline as it is considered inadequate. And=20 > I don=A1=AFt see AT&T=A1=AFs requirements as any different from BT. I=20 > think we should follow Adrian=A1=AFs and Ben=A1=AFs proposal to define = > the actual requirements for MPLS-TP before replicating other=20 > technologies=A1=AF solutions. JD: What a concept. >=20 > =20 >=20 > And the UNI/ENNI being discussed there is not comparable to=20 > your definition. >=20 > =20 >=20 > Deborah >=20 > =20 >=20 > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky > Sent: Monday, April 27, 2009 2:47 PM > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in=20 > circles (Re:Associated bidirectional transport path requirements) >=20 > =20 >=20 > Dear Maarten, > you definitely know but I'd note that MEF formulates=20 > requirements for Carrier Ethernet as a service, i.e. client=20 > layer of a transport network, not requirements for the=20 > transport network as server layer. Thus requirements=20 > expressed by SPs at MEF are not applicable or transitive, in=20 > my view, to MPLS-TP, at least not automatically.=20 >=20 > Regards, > Greg Mirsky >=20 > 2009/4/27 Maarten Vissers >=20 > Tom, >=20 > This AIS discussion has been held in previous technologies as=20 > well, e.g. > Ethernet OAM. > The result was that AIS insertion is optional and that=20 > Ethernet equipment (see G.8021) can be configured to insert=20 > Ethernet AIS or to not insert Ethernet AIS. >=20 >=20 > > Do you see our (BT's) requirements to be very divergent=20 > from those of > other operators participating in this effort? >=20 > I see the requirements for OAM that have been expressed in=20 > this mpls-tp discussion by BT representatives to be different=20 > from the requirements expressed by other operator=20 > representatives. For example > draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives=20 > of DT, FT, KPN, KDDI and CT. I also see that the OAM=20 > requirements defined in MEF (with input from e.g. AT&T and=20 > Verizon) be different from those expressed by BT=20 > representatives. I see that MEF is requesting to support in=20 > Y.1731 frame loss counting for more then one priority level;=20 > i.e. an extension of the existing capability that support=20 > frame loss counting for a single priority (i.e. a case of=20 > more OAM, not less OAM). >=20 > I see that the operators active in MEF (e.g. AT&T, Verizon,=20 > Sprint) have created and are creating Ethernet UNI, Ethernet=20 > E-NNI and Ethernet Virtual UNI specifications, while=20 > representatives of BT state that there can't be "UNI" or=20 > "E-NNI" interfaces associated with packet transport networks,=20 > as those networks are "not top of stack". I see that many=20 > operators require compliance with MEF specifications,=20 > including the Ethernet UNI specification. >=20 > I see that e.g. KPN provides a Wholesale Broadband Access=20 > (WBA) service via rooted-multipoint EVCs, which EVCs=20 > terminate outside the KPN network (refer to=20 > http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html=20 > and=20 > http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Acces > s_Service.html > ); i.e. a peer-interconnection case and a potential case for=20 > TCM, a case which according to BT representatives does not exist. >=20 > I see that the "message, file, stream" concepts are key to=20 > BT's considerations, while I don't see any of that=20 > contributed by other operators. When I look at the telecom=20 > network stack (see attached slide), then message, file stream=20 > are important concepts at Layer 3 (NGN) where those represent=20 > the characteristics of the main services (data, voice,=20 > video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the=20 > important services at Layer 2 (PTN). This raises the question=20 > what the scope of MPLS-TP is for you: > A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which=20 > has to support the IP based Layer 3 Services/Channel layer > B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which=20 > has to support the EVC based Layer 2 Services/Channel layer. >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: vrijdag 24 april 2009 15:35 > To: Maarten Vissers >=20 > Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) >=20 >=20 > Maartin, >=20 > > Ben, > > > > Your company is one of the many operators in the world, and=20 > the number=20 > > of nodes outside your network is factors larger then the number of=20 > > nodes inside your network. My experience is that different=20 > operators=20 > > have different sets of requirements. Manufacturers have to=20 > support the=20 > > superset of those requirements. Each operator will then deploy the=20 > > subset of provided features that fits its needs (and turn=20 > off or don't=20 > > use the others). Your company for some years has been=20 > asking for less,=20 > > other operators have been asking for more. Manufacturers thus build=20 > > their products with lots of configurability to support all=20 > variations. >=20 > Do you see our (BT's) requirements to be very=20 > divergent from those of other operators participating in this=20 > effort? Unless our requirements are very different, I am=20 > confident vendors will build (or have built) their devices=20 > based on our (sensible) requirements. >=20 > > It is my opinion that we should not remove well established=20 > features=20 > > like AIS, TCM, frame loss counting, delay measurement,=20 > loopback, etc=20 > > before the majority of operators have agreed that such features are=20 > > not longer necessary. >=20 > Again, that is your opinion, which frankly seems to=20 > diverge from what other operators have expressed.=20 > Furthermore, let me recommend that you get out of the habit=20 > of telling your customers (or potential ones), what they=20 > require after they have been plainly clear about what they want. > Unless you think we don't know what we are talking about. Is=20 > this perhaps the case? >=20 > --Tom >=20 >=20 >=20 >=20 > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > > Behalf Of Ben Niven-Jenkins > > Sent: vrijdag 24 april 2009 0:14 > > To: mpls-tp@ietf.org > > Subject: [mpls-tp] We appear to be going around in circles (Re: > > Associated > > bidirectional transport path requirements) > > > > Colleagues, > > > > The current debates appear to be going around in circles=20 > and achieving=20 > > nothing of value IMO. Two major operators have expressed their=20 > > opinions and no operator that I can see has disagreed with those=20 > > opinions. > > > > I apologise for being direct (and possibly rude) but I am getting=20 > > tired of being told by folks who do not represent operators what=20 > > functionality I need or should have in my networks. > > > > To put some context on BT's comments in these threads: > > I have the largest MPLS network in the UK. > > I have one of the largest MPLS networks globally delivering=20 > service to > > 173 countries with over 200 000 customer ports I have (off=20 > the top of=20 > > my > > head) > > at least another 10 MPLS networks in specific countries covering at=20 > > least 3 continents delivering dedicated services to=20 > particular market=20 > > segments. > > > > I have an extremely large SDH network in the UK consisting=20 > of over 30=20 > > 000 switches and supporting in excess of 1 million circuits. > > I have an extremely large SDH network globally delivering=20 > service in=20 > > 110 countries. > > > > I would like to think my BT colleagues and I might know a little=20 > > something about building large scale networks and the=20 > requirements of=20 > > those networks and the needs of the customers that I=20 > deliver services=20 > > to. > > > > Can we please stop these circular arguments which are IMO going=20 > > nowhere and focus on the task in hand which is defining the=20 > > requirements (and later > > solutions) being asked for by myself, my company and my=20 > colleagues in=20 > > other operators on this list. > > > > Thanks > > Ben > > > > > > -- > > > > Ben Niven-Jenkins > > IP, Data & Content Architect > > Network Infrastructure Architecture, BT > > > > E-mail: benjamin.niven-jenkins@bt.com > > Office: +44 (0)1473 648225 > > Mobile: +44 (0)7918 077205 > > Fax: +44 (0)1332 578827 > > > > British Telecommunications plc. Registered office: 81=20 > Newgate Street=20 > > London > > EC1A 7AJ Registered in England no: 1800000 > > > > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > > wrote: > > > >> ben: > >> I understand your meaning, you still wish to resign and=20 > make a more=20 > >> reliable and effective, easy to operator and easy to manage packet=20 > >> transport network like me. but why not apply this SDH/SONET in the=20 > >> future maybe the following cause: > >> 1 it adopted circuit switching techonogy to bring lower=20 > useful of=20 > >> the resource than PTN network; > >> 2 it can't bear all kinds of traffics like PTN networks it noted=20 > >> that we can't apply SDH/SONET network in the future not because it=20 > >> have a complex OAM functions. while more people like to move the=20 > >> advantages of the OAM functions in SDH/SONET to PTN networks. and=20 > >> AIS/FDI function is a kind of OAM functions of SDH/SONET .=20 > we should=20 > >> use and extend the AIS/FDI functions to MPLS-TP ; > >> > >> best regards > >> liu > >> > >> > >> > >> Ben Niven-Jenkins > >> 2009-04-23 07:58 > >> > >> =CA=D5=BC=FE=C8=CB > >> , "BRUNGARD, DEBORAH A, ATTLABS" > >> > >> =B3=AD=CB=CD > >> > >> =D6=F7=CC=E2 > >> Re: [mpls-tp] Associated bidirectional transport path requirements > >> > >> > >> > >> > >> > >> > >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn"=20 > > >> wrote: > >> > >>> Deborah: > >>> maybe what you said is right. but I can't completely agree your > >> opinions. > >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it=20 > >>> should have AIS/FDI fuctions as SDH/SONET. > >>> > >>> do you think so. > >> > >> No we must assess the requirements for packet transport networks=20 > >> supporting the needs of operators today and in the future. We must=20 > >> not blindly recreate SDH/SONET. If we do so without=20 > consideration to=20 > >> how operators' needs and requirements may have evolved=20 > (and continue=20 > >> to evolve in future) we will have failed IMO and I would severely=20 > >> question the value of the work we will have produced. If we just=20 > >> recreate SDH/SONET then what is the purpose of the work an=20 > operator=20 > >> would be better off just deploying existing SDH/SONET equipment. > >> > >> > >> Ben > >> > >> > >> > >> > >> > >> -------------------------------------------------------- > >> ZTE Information Security Notice: The information contained in this=20 > >> mail is solely property of the sender's organization. This mail=20 > >> communication is confidential. Recipients named above are=20 > obligated=20 > >> to maintain secrecy and are not permitted to disclose the=20 > contents of=20 > >> this > > communication to others. > >> This email and any files transmitted with it are confidential and=20 > >> intended solely for the use of the individual or entity to=20 > whom they=20 > >> are addressed. If you have received this email in error=20 > please notify=20 > >> the originator of the message. Any views expressed in this message=20 > >> are those of the individual sender. > >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > =20 >=20 >=20 From hhelvoort@chello.nl Mon Apr 27 14:25:32 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122033A6F9C for ; Mon, 27 Apr 2009 14:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTaMGcvxNg-Y for ; Mon, 27 Apr 2009 14:25:28 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id DA3AF3A6DE3 for ; Mon, 27 Apr 2009 14:25:22 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090427212642.IKTN10095.viefep16-int.chello.at@edge03.upc.biz>; Mon, 27 Apr 2009 23:26:42 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge03.upc.biz with edge id klSg1b03m3KDBhC03lSh20; Mon, 27 Apr 2009 23:26:42 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49F62310.4020109@chello.nl> Date: Mon, 27 Apr 2009 23:26:40 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Adrian Farrel References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe> In-Reply-To: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:25:32 -0000 Hi Adrian, You wrote: > Isn't the solution here the same as the one I proposed for "TCM"? Indeed, and that we do not have to around in circles about TCM. How about: the requirement is that a server layer shall inform its clients that it has detected a service interuption, this to ensure that the clients can inhibit (unnecessary) alarms. Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From adrian@olddog.co.uk Mon Apr 27 14:33:39 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51CA73A6F04 for ; Mon, 27 Apr 2009 14:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA0OczlrSUvp for ; Mon, 27 Apr 2009 14:33:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 248A03A6A5B for ; Mon, 27 Apr 2009 14:33:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3RLYhkk032165; Mon, 27 Apr 2009 22:34:43 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3RLYdFx032142; Mon, 27 Apr 2009 22:34:42 +0100 Message-ID: From: "Adrian Farrel" To: References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe> <49F62310.4020109@chello.nl> Date: Mon, 27 Apr 2009 22:34:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:33:39 -0000 WFM (although I am not an OAM expert). A ----- Original Message ----- From: "Huub van Helvoort" To: "Adrian Farrel" Cc: Sent: Monday, April 27, 2009 10:26 PM Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) > Hi Adrian, > > You wrote: > >> Isn't the solution here the same as the one I proposed for "TCM"? > > Indeed, and that we do not have to around in circles about TCM. > > How about: > the requirement is that a server layer shall inform its clients > that it has detected a service interuption, this to ensure that > the clients can inhibit (unnecessary) alarms. > > Cheers, Huub. > > -- > ================================================================ > http://www.van-helvoort.eu/ > ================================================================ > Always remember that you are unique...just like everyone else... > From Italo.Busi@alcatel-lucent.it Mon Apr 27 14:57:24 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0881E3A6931 for ; Mon, 27 Apr 2009 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.015 X-Spam-Level: X-Spam-Status: No, score=-4.015 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-TDYT02CMNH for ; Mon, 27 Apr 2009 14:57:22 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 990393A688F for ; Mon, 27 Apr 2009 14:57:21 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3RLwZwx022626; Mon, 27 Apr 2009 23:58:35 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 23:58:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C783.4F98432B" Date: Mon, 27 Apr 2009 23:58:33 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB40220ED3A@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <787be2780904271120j488e30aeyb445197f8d49efd0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) thread-index: AcnHZNdNftwlB7ktS+6HMnAq9AYBOQAHlOnw References: <20090424154900.X31703@sapphire.juniper.net><000001c9c704$5843ba40$6c02a8c0@china.huawei.com> <787be2780904271120j488e30aeyb445197f8d49efd0@mail.gmail.com> From: "BUSI ITALO" To: "Greg Mirsky" , "Maarten Vissers" X-OriginalArrivalTime: 27 Apr 2009 21:58:35.0198 (UTC) FILETIME=[4FE76DE0:01C9C783] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:57:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C783.4F98432B Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable It looks strange to me supporting solutions for something that is not = required ... =20 Italo ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Monday, April 27, 2009 8:20 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) =09 =09 Dear Maarten, the draft you've referred to is a proposed solution but not a = requirement that can be satisfied by supporting AIS/FDI. =09 Regards, Greg =09 =09 2009/4/27 Maarten Vissers =09 Rahul, =09 > Personally I would very much like to see greater SP involvement in = MPLS-TP requirements effort. =09 =09 Please read draft-bhh-mpls-tp-oam-y1731. This draft is co-authored by representatives of DT, FT, KPN, KDDI and CT. =09 Regards, Maarten =09 -----Original Message----- From: Rahul Aggarwal [mailto:rahul@juniper.net] Sent: zaterdag 25 april 2009 0:54 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) =09 =09 Maarten, =09 On Fri, 24 Apr 2009, Maarten Vissers wrote: =09 > Ben, > > Your company is one of the many operators in the world, and the = number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. =09 Those different operators then must present those different = requirements to the MPLS WG. In the absence of that we have no choice but to work with = the requirements presented by the set of SPs who are currently involved in formulating the MPLS-TP requirements. =09 Personally I would very much like to see greater SP involvement in = MPLS-TP requirements effort. And vendors should not proxy for SPs in defining MPLS-TP requirements. =09 =09 rahul =09 Manufacturers have to support the superset of those > requirements. Each operator will then deploy the subset of provided > features that fits its needs (and turn off or don't use the others). > Your company for some years has been asking for less, other = operators > have been asking for more. Manufacturers thus build their products > with lots of configurability to support all variations. > > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and = achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those = opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service = to > 173 countries with over 200 000 customer ports I have (off the top = of > my head) at least another 10 MPLS networks in specific countries > covering at least 3 continents delivering dedicated services to = particular market segments. > > I have an extremely large SDH network in the UK consisting of over = 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements = of > those networks and the needs of the customers that I deliver = services to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues = in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate = Street London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" wrote: > > > ben: > > I understand your meaning, you still wish to resign and make a = more > > reliable and effective, easy to operator and easy to manage packet > > transport network like me. but why not apply this SDH/SONET in the > > future maybe the following cause: > > 1 it adopted circuit switching techonogy to bring lower useful = of > > the resource than PTN network; > > 2 it can't bear all kinds of traffics like PTN networks it = noted > > that we can't apply SDH/SONET network in the future not because it > > have a complex OAM functions. while more people like to move the > > advantages of the OAM functions in SDH/SONET to PTN networks. and > > AIS/FDI function is a kind of OAM functions of SDH/SONET . we = should > > use and extend the AIS/FDI functions to MPLS-TP ; > > > > best regards > > liu > > > > > > > > Ben Niven-Jenkins > > 2009-04-23 07:58 > > > > =CA=D5=BC=FE=C8=CB > > , "BRUNGARD, DEBORAH A, ATTLABS" > > > > =B3=AD=CB=CD > > > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > > > > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" = > > wrote: > > > >> Deborah: > >> maybe what you said is right. but I can't completely agree your > > opinions. > >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it > >> should have AIS/FDI fuctions as SDH/SONET. > >> > >> do you think so. > > > > No we must assess the requirements for packet transport networks > > supporting the needs of operators today and in the future. We must > > not blindly recreate SDH/SONET. If we do so without consideration = to > > how operators' needs and requirements may have evolved (and = continue > > to evolve in future) we will have failed IMO and I would severely > > question the value of the work we will have produced. If we just > > recreate SDH/SONET then what is the purpose of the work an = operator > > would be better off just deploying existing SDH/SONET equipment. > > > > > > Ben > > > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are = obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this > communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom = they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE = Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > =09 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 ------_=_NextPart_001_01C9C783.4F98432B Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable It looks strange to me supporting solutions for something that = is not=20 required ... Italo From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky Sent: Monday, April 27, 2009 8:20 PM To: = Maarten=20 Vissers Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp] We=20 appear to be going around in circles (Re:Associated bidirectional = transport=20 path requirements) Dear Maarten, the draft you've referred to is a proposed = solution but not a requirement that can be satisfied by supporting=20 AIS/FDI. Regards, Greg 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Rahul, > Personally I would very much like to see = greater SP=20 involvement in MPLS-TP requirements effort. Please = read=20 draft-bhh-mpls-tp-oam-y1731. This draft is co-authored = by representatives=20 of DT, FT, KPN, KDDI and CT. Regards, Maarten -----Original Message----- From: Rahul = Aggarwal=20 [mailto:rahul@juniper.net] Sent:=20 zaterdag 25 april 2009 0:54 To: Maarten Vissers Cc: 'Ben=20 Niven-Jenkins'; mpls-tp@ietf.org Subject: = Re:=20 [mpls-tp] We appear to be going around in circles (Re: Associated = bidirectional transport path = requirements) Maarten, On=20 Fri, 24 Apr 2009, Maarten Vissers wrote: > = Ben, > >=20 Your company is one of the many operators in the world, and the=20 number > of nodes outside your network is factors larger then = the=20 number of > nodes inside your network. My experience is that = different=20 operators > have different sets of requirements. Those=20 different operators then must present those different requirements = to the=20 MPLS WG. In the absence of that we have no choice but to work with=20 the requirements presented by the set of SPs who are currently = involved=20 in formulating the MPLS-TP requirements. Personally I = would very=20 much like to see greater SP involvement in MPLS-TP requirements = effort.=20 And vendors should not proxy for SPs in defining MPLS-TP=20 requirements. rahul Manufacturers have to = support=20 the superset of those > requirements. Each operator will then = deploy=20 the subset of provided > features that fits its needs (and = turn off or=20 don't use the others). > Your company for some years has been = asking=20 for less, other operators > have been asking for more. = Manufacturers=20 thus build their products > with lots of configurability to = support=20 all variations. > > It is my opinion that we should not = remove=20 well established features > like AIS, TCM, frame loss = counting, delay=20 measurement, loopback, etc > before the majority of operators = have=20 agreed that such features are > not longer = necessary. > >=20 Regards, > Maarten > > -----Original = Message----- >=20 From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org]=20 On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 = april 2009=20 0:14 > To: mpls-tp@ietf.org > = Subject:=20 [mpls-tp] We appear to be going around in circles (Re: > = Associated=20 bidirectional transport path requirements) > >=20 Colleagues, > > The current debates appear to be going = around in=20 circles and achieving > nothing of value IMO. Two major = operators have=20 expressed their > opinions and no operator that I can see has=20 disagreed with those opinions. > > I apologise for being = direct=20 (and possibly rude) but I am getting > tired of being told by = folks=20 who do not represent operators what > functionality I need or = should=20 have in my networks. > > To put some context on BT's = comments in=20 these threads: > I have the largest MPLS network in the = UK. > I=20 have one of the largest MPLS networks globally delivering service = to >=20 173 countries with over 200 000 customer ports I have (off the top=20 of > my head) at least another 10 MPLS networks in specific=20 countries > covering at least 3 continents delivering = dedicated=20 services to particular market segments. > > I have an = extremely large SDH network in the UK consisting of over 30 > = 000=20 switches and supporting in excess of 1 million circuits. > I = have an=20 extremely large SDH network globally delivering service in > = 110=20 countries. > > I would like to think my BT colleagues = and I=20 might know a little > something about building large scale = networks=20 and the requirements of > those networks and the needs of the=20 customers that I deliver services to. > > Can we please = stop=20 these circular arguments which are IMO going > nowhere and = focus on=20 the task in hand which is defining the > requirements (and=20 later > solutions) being asked for by myself, my company and = my=20 colleagues in > other operators on this list. > >=20 Thanks > Ben > > > -- > > Ben=20 Niven-Jenkins > IP, Data & Content Architect > = Network=20 Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.c= om >=20 Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 = 077205 > =20 Fax: +44 (0)1332 578827 > > British = Telecommunications=20 plc. Registered office: 81 Newgate Street London > = EC1A 7AJ=20 Registered in England no: = 1800000 > > > On=20 23/04/2009 07:23, "liu.guoman@zte.com.cn" = <liu.guoman@zte.com.cn> wr= ote: > >=20 > ben: > > I understand your meaning, you still = wish to=20 resign and make a more > > reliable and effective, easy to = operator=20 and easy to manage packet > > transport network like me. = but why=20 not apply this SDH/SONET in the > > future maybe the = following=20 cause: > > 1 it adopted circuit switching = techonogy to=20 bring lower useful of > > the resource than PTN = network; >=20 > 2 it can't bear all kinds of traffics like PTN = networks it=20 noted > > that we can't apply SDH/SONET network in the = future not=20 because it > > have a complex OAM functions. while more = people like=20 to move the > > advantages of the OAM functions in = SDH/SONET=20 to PTN networks. and > > AIS/FDI function is a kind of OAM=20 functions of SDH/SONET . we should > > use and extend the = AIS/FDI=20 functions to MPLS-TP ; > > > > best = regards > >=20 liu > > > > > > > > Ben = Niven-Jenkins=20 <benjamin.niven-jenkins@bt.c= om> >=20 > 2009-04-23 07:58 > > > > = =CA=D5=BC=FE=C8=CB > > <liu.guoman@zte.com.cn>, = "BRUNGARD, DEBORAH A, ATTLABS" > > <dbrungard@att.com> > = >=20 =B3=AD=CB=CD > > <mpls-tp@ietf.org> > = >=20 =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional = transport path=20 requirements > > > > > > > = > >=20 > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" = <liu.guoman@zte.com.cn> &g= t;=20 > wrote: > > > >> Deborah: > >>=20 maybe what you said is right. but I can't completely agree=20 your > > opinions. > >> IMO. mpls-tp is regard = as=20 transport network like SDH/SONET. so it > >> should have = AIS/FDI=20 fuctions as SDH/SONET. > >> > >> do you = think=20 so. > > > > No we must assess the requirements for = packet=20 transport networks > > supporting the needs of operators = today and=20 in the future. We must > > not blindly recreate SDH/SONET. = If we do=20 so without consideration to > > how operators' needs and=20 requirements may have evolved (and continue > > to evolve = in=20 future) we will have failed IMO and I would severely > > = question=20 the value of the work we will have produced. If we just > > = recreate SDH/SONET then what is the purpose of the work an = operator >=20 > would be better off just deploying existing SDH/SONET=20 equipment. > > > > > > Ben > = > >=20 > > > > > > > > >=20 -------------------------------------------------------- > = > ZTE=20 Information Security Notice: The information contained in = this > >=20 mail is solely property of the sender's organization. This = mail > >=20 communication is confidential. Recipients named above are = obligated >=20 > to maintain secrecy and are not permitted to disclose the=20 contents > > of this > communication to = others. > >=20 This email and any files transmitted with it are confidential = and >=20 > intended solely for the use of the individual or entity to whom = they > > are addressed. If you have received this email in = error=20 please > > notify the originator of the message. Any views=20 expressed in this > > message are those of the individual=20 sender. > > This message has been scanned for viruses and = Spam by=20 ZTE Anti-Spam > system. > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >= > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >= > _______________________________________________ mpls-t= p=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ------_=_NextPart_001_01C9C783.4F98432B-- From benjamin.niven-jenkins@bt.com Mon Apr 27 16:00:10 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA333A68DA for ; Mon, 27 Apr 2009 16:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGT5BAFbCD8D for ; Mon, 27 Apr 2009 16:00:09 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id A3A233A68D5 for ; Mon, 27 Apr 2009 16:00:09 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 00:01:29 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Apr 2009 23:01:29 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 28 Apr 2009 00:01:28 +0100 From: Ben Niven-Jenkins To: Maarten Vissers , Thomas Nadeau Message-ID: Thread-Topic: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Thread-Index: AcnE4nfmDisldMC8TTSA48rkzWYbjQAAaPxAAKn/NV0= In-Reply-To: <000501c9c704$5cf7cc70$6c02a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2009 23:01:29.0852 (UTC) FILETIME=[19C5EBC0:01C9C78C] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 23:00:10 -0000 Maarten, On 27/04/2009 07:49, "Maarten Vissers" wrote: >> Do you see our (BT's) requirements to be very divergent from those of > other operators participating in this effort? > > I see the requirements for OAM that have been expressed in this mpls-tp > discussion by BT representatives to be different from the requirements > expressed by other operator representatives. For example > draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, > KPN, KDDI and CT. I also see that the OAM requirements defined in MEF (with > input from e.g. AT&T and Verizon) be different from those expressed by BT > representatives. And your point is? Assumption is the mother of all mess ups. BT was involved in the development of Y.1731 but inferring from that involvement that BT has requirements for the entire contents of that document would be erroneous. Maybe those operators involved in the documents you mention require the entire contents of those documents, maybe they don't. Unless those operators choose to express their requirements on the list we won't know and trying to position involvement in a document as an operator requiring the entire document is at best misleading IMO. Ben From nurit.sprecher@nsn.com Mon Apr 27 21:55:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FB83A700E for ; Mon, 27 Apr 2009 21:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.422 X-Spam-Level: X-Spam-Status: No, score=-5.422 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwENaiybVcFS for ; Mon, 27 Apr 2009 21:55:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4F4333A6802 for ; Mon, 27 Apr 2009 21:55:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3S4uObU017510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 06:56:24 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3S4uNvu024551; Tue, 28 Apr 2009 06:56:23 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 06:56:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 06:56:22 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A0E90B@DEMUEXC014.nsn-intra.net> In-Reply-To: <49F62310.4020109@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFw References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe> <49F62310.4020109@chello.nl> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , "Adrian Farrel" X-OriginalArrivalTime: 28 Apr 2009 04:56:23.0546 (UTC) FILETIME=[ADCDC5A0:01C9C7BD] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 04:55:08 -0000 Huub, I think that the requirement is to provide a mechanism to suppress alarms in the networks, to ensure that alarms that may be generated by client layers as a result of a failure condition in the server layer may be suppressed. Every thing else is a solution, etc.=20 I propose to phrase the requirement appropriately and conclude the discussion on this in the context of the requirements (until we are getting to the solution phase).=20 This requirement is included in the OAM requirement draft.=20 Best regards, NUrit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Tuesday, April 28, 2009 12:27 AM To: Adrian Farrel Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Hi Adrian, You wrote: > Isn't the solution here the same as the one I proposed for "TCM"? Indeed, and that we do not have to around in circles about TCM. How about: the requirement is that a server layer shall inform its clients that it has detected a service interuption, this to ensure that the clients can inhibit (unnecessary) alarms. Cheers, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From neil.2.harrison@bt.com Mon Apr 27 23:42:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC56F3A68D6 for ; Mon, 27 Apr 2009 23:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQYxzJXjdnOg for ; Mon, 27 Apr 2009 23:42:12 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id A7F533A68BE for ; Mon, 27 Apr 2009 23:42:11 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 07:43:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 07:43:28 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0479DBB6@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <49F62310.4020109@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnHfuYvo1g5PacUQAme2dazjKllYwARrvMw From: To: , , X-OriginalArrivalTime: 28 Apr 2009 06:43:31.0941 (UTC) FILETIME=[A56D0150:01C9C7CC] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:42:12 -0000 Huub wrote 27 April 2009 22:27 >=20 > Hi Adrian, >=20 > You wrote: >=20 > > Isn't the solution here the same as the one I proposed for "TCM"? >=20 > Indeed, and that we do not have to around in circles about TCM. >=20 > How about: > the requirement is that a server layer shall inform its clients > that it has detected a service interuption, this to ensure that > the clients can inhibit (unnecessary) alarms. NH=3D> This only applies if the client/server binding is fixed. And of course way back in the 70s when binary all 1s popped out of the failed TTL logic into the PDH transport hierarchy this was true. Also: no labels here and no client traffic units to create. =20 Where the client can dynamically be re-routed in response to a server failure the proposed text is not valid. It is also not necessary that the server has to keep track of where its client traffic routings have moved to. For example, if I create the topology of an IP layer network with links provided by SDH, Ethernet, ATM, OTN, etc servers, and each of these server links is provided by a different operator, then why should the servers need have knowledge of where the IP flows have moved to in response to a server layer failure when the new routes have been calculated by the IGP in the IP layer network? I can apply the same logic to an SVC-based co-ps/co-cs mode client....indeed the co-cs mode PSTN is like this. These observations make it quite clear to me at least that just copying the AIS behaviour of the old transport hierarchies that had fixed client/server relationships is not a sensible thing to do. IMO the only essential DP OAM requirement is that each layer network should be self-sufficient wrt OAM and not rely on any server layer primitives being passed upwards. Moreover, it should also be noted that (i) the defects that can occur in each of the 3 network modes are not the same and (ii) their OAM requirements are not identically the same. So the OAM that applies to the cl-ps mode (eg IP) is not the same as the OAM that applies to the co-ps mode (eg MPLS-TP) and neither of these is identically the same as the OAM that applies to the co-cs mode (eg SDH). Note - The only point being considered here is the real client and server traffic relationship. The creation of a hierarchy of TCM sublayers is a separate topic. Further, it is quite clear from a simple technical analysis that any non top-of-stack network has no need for E-NNI peer-partition working between different operating parties. So this is also a separate issue. However, I propose that this latter point be captured in the MPLS-TP requirements draft due to its stand-alone and generic importance, ie this applies to more than just DP OAM. Ben can you please consider this point as/when the MPLS-TP requirements draft is updated. regards, Neil > Cheers, Huub. From maarten.vissers@huawei.com Mon Apr 27 23:56:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F723A683A for ; Mon, 27 Apr 2009 23:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[AWL=1.221, BAYES_00=-2.599, MANGLED_DICK=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpUIF4mkO1jq for ; Mon, 27 Apr 2009 23:56:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 8C9323A68C7 for ; Mon, 27 Apr 2009 23:56:10 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIS00GFBTZT7H@szxga01-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 14:57:30 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIS008WYTZSJB@szxga01-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 14:57:29 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIS00ENNTZMEC@szxml02-in.huawei.com>; Tue, 28 Apr 2009 14:57:29 +0800 (CST) Date: Tue, 28 Apr 2009 08:57:23 +0200 From: Maarten Vissers In-reply-to: To: 'Ben Niven-Jenkins' Message-id: <002801c9c7ce$991d8990$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gAAGnJO1ACExPCA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:56:14 -0000 Ben, > In SDH/SONET the AIS primitive was generated automatically Your understanding of AIS generation in SDH is not correct. AIS generation in SDH is explicitly controlled by the Consequent Action process in atomic functions. Furthermore the AIS signal has to be explicitly generated in SDH equipment. It does not appear automatically. E.g. during a cable break you will see that the input port generates a noise pattern, which results in a arbitrary series of 1 and 0 bits after the Clock/Data Recovery circuit. Detection of the signal fail condition will now result in the replacement of this arbitrary 1 and 0 bit stream by the all-1's AIS bit stream, which creates either MSn frames or VC-n frames in which all bits are set to 1. And during a misconnection, the incoming RSn or VC-n signal contains a non-AIS pattern. The detection of dTIM identifies that the termination sink function is connected with an unexpected termination source function. This results in the replacement of the RSn or VC-n signal by the AIS signal. In OTN a similar AIS control and generation is present in equipment. It generates either ODUk frames in which all bits are set to 1, or OTUk frames which contains a PN-11 bit stream, or STM-N frames which contain a PN-11 bit stream, or 802.3 signals which contain Link Fault or Local Fault code words. In ATM and Ethernet a similar AIS control and generation is present. But instead of generating frames in which all bits are set to 1, or frames in which the bits carry a PN-11 sequence or code words in which the bits carry a Link/Local Fault indication, in ATM a stream of AIS cells and in Ethernet a stream of AIS frames is generated. > If used at all AIS is a northbound function into the management system > is it not? In which case it doesn't matter what primitive the node (box) > uses to trigger that northbound message generation. Your understanding of AIS usage is not correct. AIS is used in the Defect Correlations in the atomic functions. It's main task is to suppress the fault causes associated with defects which are detected as a consequence of another primary fault. There is no alternative primitive available in a transport network that could replace the function of AIS. The defect correlation specifications in the ETHx_FT_Sk function are: cLOC[i] <-- dLOC[i] and (not dAIS) and (not dLCK) and (not CI_SSF) and (MI_CC_Enable) cMMG <-- dMMG cUNM <-- dUNM cUNP <-- dUNP cUNL <-- dUNL cUNPr <-- dUNPr cRDI <-- (dRDI[1..n]) and (MI_CC_Enable) cSSF <-- CI_SSF or dAIS cLCK <-- dLCK and (not dAIS) cDEG[1] <-- dDEG[1] and (not dAIS) and (not CI_SSF) and (not (dLOC[1..n] or dUNL or dMMG or dUNM)) and (MI_CC_Enable)) The defect correlation specifications in the Och/OTUk_A_Sk function are: cLOF <-- dLOF and (not dAIS) and (not AI_TSF-P) cLOM <-- dLOM and (not dLOF) and (not dAIS) and (not AI_TSF-P). The defect correlation specifications in the ODUkP_TT_Sk are: cOCI <-- dOCI and (not CI_SSF) cLCK <-- dLCK and (not CI_SSF) cTIM <-- dTIM and (not CI_SSF) and (not dAIS) and (not dOCI) and (not dLCK) cDEG <-- dDEG and (not CI_SSF) and (not dAIS) and (not dOCI) and (not dLCK) and (not (dTIM and (not TIMActDis))) cBDI <-- dBDI and (not CI_SSF) and (not dAIS) and (not dOCI) and (not dLCK) and (not (dTIM and (not TIMActDis))) cSSF <-- CI_SSF or dAIS. > Any additional configuration (e.g. AIS configuration) There doesn't have to be AIS specific configuration and in most cases there is no AIS specific configuration. Regards, Maarten -----Original Message----- From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] Sent: maandag 27 april 2009 16:21 To: Maarten Vissers; andy.bd.reid@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Maarten, On 27/04/2009 13:27, "Maarten Vissers" wrote: > Good CC, AIS present > This situation could arise because of a misconfiguration of the AIS > forwarding label injection table. And there are a number of scenarios > which make this quite likely when protection switching occurs. > Depending on the exact scope of the forwarding labels, a protection > switch may well require the proactive purging of entries from the AIS > forwarding label injection table following the protection switch (this > could equivalently been seen as the forwarding function proactively dropping the AIS packets). > > [mv] I don't think that those scenarios are likely scenarios. > Equipment compliant with ITU-T's equipment recommendations will not > have those scenarios. Only equipment that does not comply with those > equipment recommendations could have such scenarios. Just do not > deploy such equipment. I have heard this argument of "you just need to buy boxes that are built properly" before. It's fallacy. Reality is things go wrong. That could be due to hardware fault (fibre break, circuit board failure etc.), bug (hardware or software) or operator error. IME the failure conditions that are hardest to deal with operationally are bugs & misconfigurations. As Andy shows, in cases of error it is hard to trust what is configured correctly. Any additional configuration (e.g. AIS configuration) just increases the likelihood that something has been misconfigured. It is simple logic. I also struggle to see your argument of aligning with SDH/SONET primitives for AIS. If used at all AIS is a northbound function into the management system is it not? In which case it doesn't matter what primitive the node (box) uses to trigger that northbound message generation. In SDH/SONET the AIS primitive was generated automatically and so the node/box could use that to trigger generation a northbound message. In a packet network an AIS flow is not generated automatically it needs to be actively inserted. Insertion of AIS provides no useful information above and beyond that provided by CC, therefore why can the lack of CC not be used to trigger the generation of any northbound AIS message if such a message really is required? What you are proposing AFAICT is definition of additional protocol primitives (internal to the layer network that are not exposed directly to the management system) that provide nothing over the existing required primitives (i.e. CC). At best your proposal provides no value. At worst your proposal provides confusing and conflicting information to the operator trying to perform fault analysis. Ben From Italo.Busi@alcatel-lucent.it Tue Apr 28 00:42:24 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D733A697F for ; Tue, 28 Apr 2009 00:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=-1.279, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN3KeF-mhChu for ; Tue, 28 Apr 2009 00:42:23 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 5A9D03A680A for ; Tue, 28 Apr 2009 00:42:23 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3S7hcCW027111; Tue, 28 Apr 2009 09:43:40 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 09:43:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 09:43:37 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB40220EDA4@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A0E90B@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNA= References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe><49F62310.4020109@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A0E90B@DEMUEXC014.nsn-intra.net> From: "BUSI ITALO" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , , "Adrian Farrel" X-OriginalArrivalTime: 28 Apr 2009 07:43:39.0459 (UTC) FILETIME=[0BAC9130:01C9C7D5] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:42:24 -0000 I think that the requirements are defined in section 2.2.8 of draft-ietf-mpls-tp-oam-requirements-01 Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN - IL/Hod HaSharon) > Sent: Tuesday, April 28, 2009 6:56 AM > To: hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transport pathrequirements) >=20 > Huub, > I think that the requirement is to provide a mechanism to suppress > alarms in the networks, to ensure that alarms that may be generated by > client layers as a result of a failure condition in the=20 > server layer may > be suppressed. > Every thing else is a solution, etc.=20 > I propose to phrase the requirement appropriately and conclude the > discussion on this in the context of the requirements (until we are > getting to the solution phase).=20 > This requirement is included in the OAM requirement draft.=20 > Best regards, > NUrit >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of ext Huub van Helvoort > Sent: Tuesday, April 28, 2009 12:27 AM > To: Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport > path requirements) >=20 > Hi Adrian, >=20 > You wrote: >=20 > > Isn't the solution here the same as the one I proposed for "TCM"? >=20 > Indeed, and that we do not have to around in circles about TCM. >=20 > How about: > the requirement is that a server layer shall inform its clients > that it has detected a service interuption, this to ensure that > the clients can inhibit (unnecessary) alarms. >=20 > Cheers, Huub. >=20 > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.van-helvoort.eu/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From nurit.sprecher@nsn.com Tue Apr 28 00:45:05 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205703A69A8 for ; Tue, 28 Apr 2009 00:45:05 -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=[AWL=-0.870, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-amGl7XYJ5U for ; Tue, 28 Apr 2009 00:45:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B3C593A680A for ; Tue, 28 Apr 2009 00:45:02 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3S7kJhv018215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 09:46:19 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3S7kEBF015058; Tue, 28 Apr 2009 09:46:18 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 09:46:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 09:46:13 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A415D6@DEMUEXC014.nsn-intra.net> In-Reply-To: <6FD21B53861BF44AA90A288402036AB40220EDA4@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQA== References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe><49F62310.4020109@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A0E90B@DEMUEXC014.nsn-intra.net> <6FD21B53861BF44AA90A288402036AB40220EDA4@FRVELSMBS21.ad2.ad.alcatel.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext BUSI ITALO" , , "Adrian Farrel" X-OriginalArrivalTime: 28 Apr 2009 07:46:14.0390 (UTC) FILETIME=[68052960:01C9C7D5] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:45:05 -0000 If we agree that the requirement is included, so why do we keep with the endless discussions on this requirement? -----Original Message----- From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 Sent: Tuesday, April 28, 2009 10:44 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; Adrian Farrel Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) I think that the requirements are defined in section 2.2.8 of draft-ietf-mpls-tp-oam-requirements-01 Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN - IL/Hod HaSharon) > Sent: Tuesday, April 28, 2009 6:56 AM > To: hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transport pathrequirements) >=20 > Huub, > I think that the requirement is to provide a mechanism to suppress > alarms in the networks, to ensure that alarms that may be generated by > client layers as a result of a failure condition in the=20 > server layer may > be suppressed. > Every thing else is a solution, etc.=20 > I propose to phrase the requirement appropriately and conclude the > discussion on this in the context of the requirements (until we are > getting to the solution phase).=20 > This requirement is included in the OAM requirement draft.=20 > Best regards, > NUrit >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of ext Huub van Helvoort > Sent: Tuesday, April 28, 2009 12:27 AM > To: Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport > path requirements) >=20 > Hi Adrian, >=20 > You wrote: >=20 > > Isn't the solution here the same as the one I proposed for "TCM"? >=20 > Indeed, and that we do not have to around in circles about TCM. >=20 > How about: > the requirement is that a server layer shall inform its clients > that it has detected a service interuption, this to ensure that > the clients can inhibit (unnecessary) alarms. >=20 > Cheers, Huub. >=20 > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.van-helvoort.eu/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From neil.2.harrison@bt.com Tue Apr 28 01:06:10 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40F83A67FF for ; Tue, 28 Apr 2009 01:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DXr3QJ5VZqY for ; Tue, 28 Apr 2009 01:06:09 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id C3A003A681A for ; Tue, 28 Apr 2009 01:05:55 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 09:07:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 09:07:11 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A415D6@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQ From: To: , , , X-OriginalArrivalTime: 28 Apr 2009 08:07:15.0882 (UTC) FILETIME=[57ED90A0:01C9C7D8] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:06:10 -0000 Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN - IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transportpathrequirements) >=20 > If we agree that the requirement is included, so why do we=20 > keep with the > endless discussions on this requirement? >=20 > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > hhelvoort@chello.nl; Adrian > Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) >=20 > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > > Nurit (NSN - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > transport pathrequirements) > >=20 > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be=20 > generated by > > client layers as a result of a failure condition in the=20 > > server layer may > > be suppressed. > > Every thing else is a solution, etc.=20 > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase).=20 > > This requirement is included in the OAM requirement draft.=20 > > Best regards, > > NUrit > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional transport > > path requirements) > >=20 > > Hi Adrian, > >=20 > > You wrote: > >=20 > > > Isn't the solution here the same as the one I proposed for "TCM"? > >=20 > > Indeed, and that we do not have to around in circles about TCM. > >=20 > > How about: > > the requirement is that a server layer shall inform its clients > > that it has detected a service interuption, this to ensure that > > the clients can inhibit (unnecessary) alarms. > >=20 > > Cheers, Huub. > >=20 > > --=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/ > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From adrian@olddog.co.uk Tue Apr 28 01:33:17 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03413A6A6F for ; Tue, 28 Apr 2009 01:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qt1KLpt3vyN for ; Tue, 28 Apr 2009 01:33:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id D84563A67EB for ; Tue, 28 Apr 2009 01:33:15 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n3S8YH16030467; Tue, 28 Apr 2009 09:34:17 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n3S8YEvO030406; Tue, 28 Apr 2009 09:34:16 +0100 Message-ID: From: "Adrian Farrel" To: References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe> <49F62310.4020109@chello.nl> Date: Tue, 28 Apr 2009 09:33:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:33:17 -0000 Huub, On mature reflection... > How about: > the requirement is that a server layer shall inform its clients > that it has detected a service interuption, this to ensure that > the clients can inhibit (unnecessary) alarms. I believe that the use made of the information is out of scope. That would reduce us to... > the requirement is that a server layer shall inform its clients > that it has detected a service interruption. We might note that "service" is possibly ambiguous. Some people regard a "service" as being what exists in the client layer. Some people see it as what the server layer delivers to the client layer. Could we restate this in terms of server layer trails? A From maarten.vissers@huawei.com Tue Apr 28 02:41:09 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D224B3A6BE1 for ; Tue, 28 Apr 2009 02:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.299 X-Spam-Level: ** X-Spam-Status: No, score=2.299 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg1ojwUdBR3J for ; Tue, 28 Apr 2009 02:41:08 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 87C933A6BF0 for ; Tue, 28 Apr 2009 02:40:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00KGU0W0FR@szxga03-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 17:26:25 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00BKS0W09Q@szxga03-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 17:26:24 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT00E2I0VLEC@szxml02-in.huawei.com>; Tue, 28 Apr 2009 17:26:24 +0800 (CST) Date: Tue, 28 Apr 2009 11:26:13 +0200 From: Maarten Vissers In-reply-to: <787be2780904271120j488e30aeyb445197f8d49efd0@mail.gmail.com> To: 'Greg Mirsky' Message-id: <004e01c9c7e3$621fe1d0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ZXgSpymcX1NRq9dc7MApxg)" Thread-index: AcnHZM3KBb5yEAV3S2ecqsIJMFlGCwAfDq/Q Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associatedbidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:41:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZXgSpymcX1NRq9dc7MApxg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Dear Greg, =20 You are right, the draft is a proposed solution. This solution however implicitly supports the requirements underlying such AIS/FDI. The = proposal is to deploy the well known AIS mechanism to support those requirements; this proposal and thus the underlying requirement is supported by the co-authors. =20 For many people, "AIS" expresses both the requirement and the solution. = If we look at Y.1710, Y.1730 and Y.sup4, then we find the following requirements underlying this AIS/FDI capability: =20 [Y.1710] A defect event in a given layer network should not cause = multiple alarm events to be raised, nor=20 cause unnecessary corrective actions to be taken in any higher level client-layer networks. =20 [Y.1730] A defect event in a given layer network should not cause = multiple alarm events to be raised, nor cause unnecessary corrective actions to = be taken, in any higher-layer level client-layer network. The Ethernet = layer network should support alarm suppression for server layer sourced = defects whose presence have been communicated by forward defect indication = means. Ethernet layer network should support forward defect indication = capability where possible. =20 [Y.sup4] It should be possible to prevent alarms being raised in a = client layer or client sublayer as a result of a defect in a server layer.=20 =20 It is possible to use the above text as requirement for the AIS = mechanism in MPLS-TP. =20 Regards, Maarten =20 _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: maandag 27 april 2009 20:20 To: Maarten Vissers Cc: Rahul Aggarwal; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associatedbidirectional transport path requirements) Dear Maarten, the draft you've referred to is a proposed solution but not a = requirement that can be satisfied by supporting AIS/FDI. Regards, Greg 2009/4/27 Maarten Vissers Rahul, > Personally I would very much like to see greater SP involvement in = MPLS-TP requirements effort. Please read draft-bhh-mpls-tp-oam-y1731. This draft is co-authored by representatives of DT, FT, KPN, KDDI and CT. Regards, Maarten -----Original Message----- From: Rahul Aggarwal [mailto:rahul@juniper.net] Sent: zaterdag 25 april 2009 0:54 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maarten, On Fri, 24 Apr 2009, Maarten Vissers wrote: > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Those different operators then must present those different requirements = to the MPLS WG. In the absence of that we have no choice but to work with = the requirements presented by the set of SPs who are currently involved in formulating the MPLS-TP requirements. Personally I would very much like to see greater SP involvement in = MPLS-TP requirements effort. And vendors should not proxy for SPs in defining MPLS-TP requirements. rahul Manufacturers have to support the superset of those > requirements. Each operator will then deploy the subset of provided > features that fits its needs (and turn off or don't use the others). > Your company for some years has been asking for less, other operators > have been asking for more. Manufacturers thus build their products > with lots of configurability to support all variations. > > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those = opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my head) at least another 10 MPLS networks in specific countries > covering at least 3 continents delivering dedicated services to = particular market segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services = to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" wrote: > > > ben: > > I understand your meaning, you still wish to resign and make a more > > reliable and effective, easy to operator and easy to manage packet > > transport network like me. but why not apply this SDH/SONET in the > > future maybe the following cause: > > 1 it adopted circuit switching techonogy to bring lower useful of > > the resource than PTN network; > > 2 it can't bear all kinds of traffics like PTN networks it noted > > that we can't apply SDH/SONET network in the future not because it > > have a complex OAM functions. while more people like to move the > > advantages of the OAM functions in SDH/SONET to PTN networks. and > > AIS/FDI function is a kind of OAM functions of SDH/SONET . we should > > use and extend the AIS/FDI functions to MPLS-TP ; > > > > best regards > > liu > > > > > > > > Ben Niven-Jenkins > > 2009-04-23 07:58 > > > > =CA=D5=BC=FE=C8=CB > > , "BRUNGARD, DEBORAH A, ATTLABS" > > > > =B3=AD=CB=CD > > > > =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional transport path requirements > > > > > > > > > > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > > wrote: > > > >> Deborah: > >> maybe what you said is right. but I can't completely agree your > > opinions. > >> IMO. mpls-tp is regard as transport network like SDH/SONET. so it > >> should have AIS/FDI fuctions as SDH/SONET. > >> > >> do you think so. > > > > No we must assess the requirements for packet transport networks > > supporting the needs of operators today and in the future. We must > > not blindly recreate SDH/SONET. If we do so without consideration to > > how operators' needs and requirements may have evolved (and continue > > to evolve in future) we will have failed IMO and I would severely > > question the value of the work we will have produced. If we just > > recreate SDH/SONET then what is the purpose of the work an operator > > would be better off just deploying existing SDH/SONET equipment. > > > > > > Ben > > > > > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this > communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_ZXgSpymcX1NRq9dc7MApxg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Dear Greg, You are right, the draft is a proposed = solution. This=20 solution however implicitly supports the requirements underlying = such=20 AIS/FDI. The proposal is to deploy the well known AIS mechanism to = support those=20 requirements; this proposal and thus the underlying requirement is = supported by=20 the co-authors. For many people, "AIS" expresses both the = requirement and=20 the solution. If we look at Y.1710, Y.1730 and Y.sup4, then we find the=20 following requirements underlying this AIS/FDI = capability: [Y.1710]=20 A defect event in a given layer network should not cause multiple alarm = events=20 to be raised, nor cause=20 unnecessary corrective actions to be taken in any higher level = client-layer=20 networks. [Y.1730]=20 A defect event in a given layer network should not cause multiple alarm = events=20 to be raised, nor cause unnecessary corrective actions to be taken, in = any=20 higher-layer=20 level client-layer network. The=20 Ethernet layer network should support alarm suppression for server layer = sourced=20 defects whose presence have been communicated by forward defect = indication=20 means. Ethernet layer network should support forward defect indication=20 capability where possible. [Y.sup4]=20 It should be possible to prevent alarms being raised in a client layer = or client=20 sublayer as a result=20 of a defect in a server layer.=20 It is possible to=20 use the above text as requirement for the AIS mechanism in=20 MPLS-TP. Regards, Maarten From: Greg Mirsky = [mailto:gregimirsky@gmail.com]=20 Sent: maandag 27 april 2009 20:20 To: Maarten=20 Vissers Cc: Rahul Aggarwal; = mpls-tp@ietf.org Subject: Re:=20 [mpls-tp] We appear to be going around in circles (Re: = Associatedbidirectional=20 transport path requirements) Dear Maarten, the draft you've referred to is a proposed = solution=20 but not a requirement that can be satisfied by supporting=20 AIS/FDI. Regards, Greg 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Rahul, > Personally I would very much like to see = greater SP=20 involvement in MPLS-TP requirements effort. Please = read=20 draft-bhh-mpls-tp-oam-y1731. This draft is co-authored = by representatives=20 of DT, FT, KPN, KDDI and CT. Regards, Maarten -----Original Message----- From: Rahul Aggarwal = [mailto:rahul@juniper.net] Sent:=20 zaterdag 25 april 2009 0:54 To: Maarten Vissers Cc: 'Ben = Niven-Jenkins';=20 mpls-tp@ietf.org Subject: = Re:=20 [mpls-tp] We appear to be going around in circles (Re: Associated=20 bidirectional transport path = requirements) Maarten, On Fri,=20 24 Apr 2009, Maarten Vissers wrote: > Ben, > > = Your=20 company is one of the many operators in the world, and the = number > of=20 nodes outside your network is factors larger then the number = of > nodes=20 inside your network. My experience is that different operators > = have=20 different sets of requirements. Those different operators then = must=20 present those different requirements to the MPLS WG. In the absence = of that=20 we have no choice but to work with the requirements presented by = the set of=20 SPs who are currently involved in formulating the MPLS-TP=20 requirements. Personally I would very much like to see greater = SP=20 involvement in MPLS-TP requirements effort. And vendors should not = proxy=20 for SPs in defining MPLS-TP=20 requirements. rahul Manufacturers have to = support the=20 superset of those > requirements. Each operator will then deploy = the=20 subset of provided > features that fits its needs (and turn off = or don't=20 use the others). > Your company for some years has been asking = for less,=20 other operators > have been asking for more. Manufacturers thus = build=20 their products > with lots of configurability to support all=20 variations. > > It is my opinion that we should not remove = well=20 established features > like AIS, TCM, frame loss counting, delay = measurement, loopback, etc > before the majority of operators = have=20 agreed that such features are > not longer = necessary. > >=20 Regards, > Maarten > > -----Original = Message----- >=20 From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] = On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april = 2009=20 0:14 > To: mpls-tp@ietf.org > Subject: = [mpls-tp]=20 We appear to be going around in circles (Re: > Associated = bidirectional=20 transport path requirements) > > = Colleagues, > > The=20 current debates appear to be going around in circles and = achieving >=20 nothing of value IMO. Two major operators have expressed their > = opinions and no operator that I can see has disagreed with those=20 opinions. > > I apologise for being direct (and possibly = rude) but=20 I am getting > tired of being told by folks who do not represent = operators what > functionality I need or should have in my=20 networks. > > To put some context on BT's comments in = these=20 threads: > I have the largest MPLS network in the UK. > I = have one=20 of the largest MPLS networks globally delivering service to > = 173=20 countries with over 200 000 customer ports I have (off the top = of > my=20 head) at least another 10 MPLS networks in specific countries > = covering=20 at least 3 continents delivering dedicated services to = particular market=20 segments. > > I have an extremely large SDH network in the = UK=20 consisting of over 30 > 000 switches and supporting in excess of = 1=20 million circuits. > I have an extremely large SDH network = globally=20 delivering service in > 110 countries. > > I would = like to=20 think my BT colleagues and I might know a little > something = about=20 building large scale networks and the requirements of > those = networks=20 and the needs of the customers that I deliver services = to. > > Can=20 we please stop these circular arguments which are IMO going > = nowhere=20 and focus on the task in hand which is defining the > = requirements (and=20 later > solutions) being asked for by myself, my company and my=20 colleagues in > other operators on this list. > >=20 Thanks > Ben > > > -- > > Ben=20 Niven-Jenkins > IP, Data & Content Architect > Network = Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.c= om >=20 Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = =20 Fax: +44 (0)1332 578827 > > British = Telecommunications plc.=20 Registered office: 81 Newgate Street London > EC1A 7AJ = =20 Registered in England no: 1800000 > > > On = 23/04/2009=20 07:23, "liu.guoman@zte.com.cn"=20 <liu.guoman@zte.com.cn> wr= ote: > >=20 > ben: > > I understand your meaning, you still wish = to=20 resign and make a more > > reliable and effective, easy to = operator=20 and easy to manage packet > > transport network like me. but = why not=20 apply this SDH/SONET in the > > future maybe the following=20 cause: > > 1 it adopted circuit switching = techonogy to=20 bring lower useful of > > the resource than PTN = network; > >=20 2 it can't bear all kinds of traffics like PTN networks = it=20 noted > > that we can't apply SDH/SONET network in the future = not=20 because it > > have a complex OAM functions. while more = people like=20 to move the > > advantages of the OAM functions in = SDH/SONET to=20 PTN networks. and > > AIS/FDI function is a kind of OAM = functions of=20 SDH/SONET . we should > > use and extend the AIS/FDI = functions to=20 MPLS-TP ; > > > > best regards > > = liu >=20 > > > > > > > Ben Niven-Jenkins <benjamin.niven-jenkins@bt.c= om> >=20 > 2009-04-23 07:58 > > > > = =CA=D5=BC=FE=C8=CB > > <liu.guoman@zte.com.cn>, = "BRUNGARD,=20 DEBORAH A, ATTLABS" > > <dbrungard@att.com> > = >=20 =B3=AD=CB=CD > > <mpls-tp@ietf.org> > > = =D6=F7=CC=E2 > > Re: [mpls-tp] Associated bidirectional = transport path=20 requirements > > > > > > > = > >=20 > > > > > On 21/04/2009 02:59, "liu.guoman@zte.com.cn" = <liu.guoman@zte.com.cn> &g= t; >=20 wrote: > > > >> Deborah: > >> = maybe=20 what you said is right. but I can't completely agree your > > = opinions. > >> IMO. mpls-tp is regard as transport network = like=20 SDH/SONET. so it > >> should have AIS/FDI fuctions as=20 SDH/SONET. > >> > >> do you think so. >=20 > > > No we must assess the requirements for packet = transport=20 networks > > supporting the needs of operators today and in = the=20 future. We must > > not blindly recreate SDH/SONET. If we do = so=20 without consideration to > > how operators' needs and = requirements=20 may have evolved (and continue > > to evolve in future) we = will have=20 failed IMO and I would severely > > question the value of the = work we=20 will have produced. If we just > > recreate SDH/SONET then = what is=20 the purpose of the work an operator > > would be better off = just=20 deploying existing SDH/SONET equipment. > > > = > > >=20 Ben > > > > > > > > > = > >=20 > -------------------------------------------------------- > = > ZTE=20 Information Security Notice: The information contained in this > = >=20 mail is solely property of the sender's organization. This = mail > >=20 communication is confidential. Recipients named above are = obligated >=20 > to maintain secrecy and are not permitted to disclose the=20 contents > > of this > communication to others. > = >=20 This email and any files transmitted with it are confidential = and > >=20 intended solely for the use of the individual or entity to whom = they >=20 > are addressed. If you have received this email in error = please >=20 > notify the originator of the message. Any views expressed in = this >=20 > message are those of the individual sender. > > This = message has=20 been scanned for viruses and Spam by ZTE Anti-Spam >=20 system. > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= > _______________________________________________ mpls-t= p=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_ZXgSpymcX1NRq9dc7MApxg)-- From maarten.vissers@huawei.com Tue Apr 28 03:46:19 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA343A6A7F for ; Tue, 28 Apr 2009 03:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.309 X-Spam-Level: ** X-Spam-Status: No, score=2.309 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhU-TY2udwPx for ; Tue, 28 Apr 2009 03:46:16 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8E1C73A6C80 for ; Tue, 28 Apr 2009 03:46:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00GX14N1RJ@szxga04-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 18:47:25 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT000IO4N1B7@szxga04-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 18:47:25 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT002694MCUM@szxml02-in.huawei.com>; Tue, 28 Apr 2009 18:47:25 +0800 (CST) Date: Tue, 28 Apr 2009 12:47:04 +0200 From: Maarten Vissers In-reply-to: <787be2780904271146hcff7e94xca5da9384f16d92e@mail.gmail.com> To: 'Greg Mirsky' Message-id: <005c01c9c7ee$adb90ee0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_YkMuOFbO155xctCNGzzWuQ)" Thread-index: AcnHaIpxqe8CaUKkSAa/993gXKOxdgAevCxg Cc: mpls-tp@ietf.org Subject: [mpls-tp] 4 layer stack options {RE: We appear to be going around in circles (Re: Associatedbidirectional transport path requirements)} X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 10:46:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YkMuOFbO155xctCNGzzWuQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Dear Greg, =20 If MPLS-TP's role is restricted to the Transport Layer in the MEF layer stack, then I agree with your observation that requirements expressed by = SPs at MEF are not applicable to MPLS-TP. For such case, the EVC layer will = be the service carrying layer, and MPLS-TP will be one of the technologies = that carries the EVCs. =20 I do not agree with your interpretation that MEF formulates requirements = for carrier ethernet as a client layer of a "transport network". As far as I understand MEF's specifications, they talk about a "transport layer", = not a "transport network" underneath of the EVC layer.=20 =20 For me, a transport network includes a service layer as its "top of = stack" layer. The EVC layer is the top-of-stack layer in this carrier ethernet packet transport network, and the MPLS-TP layer is one of the transport path/tunnel layers that support the EVC layer. =20 As you notice the difference is just the point where you and I consider = the boundary of a transport network to be. This difference would completely disappear if we would draw a figure in which we illustrate how e.g. an = E-LAN or E-Line service would be supported.=20 =20 In my view the transport network boundary is above the EVC layer (i.e. = EVC layer is part of the packet transport network), in analogy to the = boundaries of the SDH transport network (above the LO VC layer), OTN transport = network (above LO ODU layer) and ATM transport network (above ATM VC layer). =20 In my view you have comparable roles of the following layers: =20 - service/channel layer (UNI-N to UNI-N connectivity):=20 SDH LO VC - OTN LO ODU - ATM VC - EVC =20 - tunnel/path layer (domain edge to domain edge connectivity):=20 SDH HO VC - OTN HO ODU - ATM VP - MPSL-TP LSP - EVP - PBB-TE TESI =20 Furthermore in my view you have comparable roles of the following = labels:=20 =20 - service/channel layer label:=20 SDH TU timeslot - OTN LO ODU timeslot - ATM VCI - Ethernet VLAN ID - = MPLS-TP PW label =20 - tunnel/path layer label:=20 SDH AU timeslot - OTN lambda - ATM VPI - MPLS-TP LSP label - Ethernet = VLAN ID - PBB-TE tuple. =20 =20 As noted two weeks ago, E-LAN over SDH has introduced an additional = service layer on top of the traditional SDH service layer; i.e. the EVC layer. = This EVC layer has UNI-N to UNI-N connectivity. The VC-12 layer has now only = EVC termination to EVC switch point and EVC swithc point to EVC switch point connectivity. This VC-12 connectivity could be 1-to-1 with the HOVC connectivity.=20 The VC-12 connections are not longer the service connections (this role = has been taken over by the EVC), and VC-12 connections are also not tunnel connections (HO VC provides tunnel connections). These VC-12 connections = are only there to be able to carry the E-LAN services over timeslots of the = HOVC signals.=20 For the case those VC-12 connections terminate at the same points as = where the HOVC connections terminate (i.e. SS-VC12) it would be possible to disable the VC-12 OAM; i.e. the VC-12 OAM does not add anything to that provided by the HOVC OAM and EVC OAM. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 For the case that MPLS-TP would perform the role of a service/channel = layer (see layer stack (2) below), then the requirements expressed by SPs at = MEF will be applicable/transitive to MPLS-TP's EVC replacement in my opinion(i.e. to MPLS-TP MS-PW).=20 =20 If it is not the intention that an MPLS-TP construct replaces the EVC, = then the MEF service layer requirements do not apply to the MPLS-TP layer or layers (which are located below the EVC layer). For this case I agree = with you. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 I believe that there are four alternative MPLS-TP based packet transport network layer stacks: =20 (1) (2) (3) (4) ------------ --------------- ------------- ------- | EVC | | EVC & MS-PW | | EVC | | EVC | ------------ --------------- ------------- ------------ | LSP | | LSP | | PW | | PW | ------------ --------------- ------------- ------------ | T.Media | | Trans.Media | | LSP | | LSP | ------------ --------------- ------------- ------------ | T.Media | | T.Media | ------------- ------------ =20 Which of these four stacks do we want to standardize for MPLS-TP based packet transport networks? =20 For Ethernet VLAN based packet transport networks the layer stack is: =20 (5) ------------ | EVC | ------------ | EVP | ------------ | T.Media | ------------ =20 For PBB-TE based packet transport networks the layer stack is: =20 (6) ------------ | EVC | ------------ | TESI | ------------ | T.Media | ------------ =20 If we choose for MPLS-TP based packet transport network layer stacks (2) = or (4) we will deploy the PW layer as a service layer for p2p and p2mp = customer services. For the case one of the endpoints of a p2p customer service is behind an Ethernet VLAN or PBB-TE domain, we will have to realize a peer-interworking between PW and EVC to support the customer service. = For the case one or more of the p2mp customer service endpoints are behind = an Ethernet VLAN or PBB-TE domain, we will have to realize a = peer-interworking between PW and EVC to support the customer service. =20 Such peer interworking is not required when we choose for MPLS-TP based packet transport network layer stacks (1) or (3). =20 Regards, Maarten =20 =20 _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: maandag 27 april 2009 20:47 To: Maarten Vissers Cc: Thomas Nadeau; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associatedbidirectional transport path requirements) Dear Maarten, you definitely know but I'd note that MEF formulates requirements for Carrier Ethernet as a service, i.e. client layer of a transport network, = not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically.=20 Regards, Greg Mirsky 2009/4/27 Maarten Vissers Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don't > use the others). Your company for some years has been asking for less, > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from = those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market > segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must >> not blindly recreate SDH/SONET. If we do so without consideration to >> how operators' needs and requirements may have evolved (and continue >> to evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents of >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_YkMuOFbO155xctCNGzzWuQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Dear Greg, If MPLS-TP's role is restricted to the = Transport Layer in=20 the MEF layer stack, then I agree with your observation that = requirements=20 expressed by SPs at MEF are not applicable to MPLS-TP. For such case, = the EVC=20 layer will be the service carrying layer, and MPLS-TP will be one of the = technologies that carries the EVCs. I do not agree with your interpretation that = MEF formulates=20 requirements for carrier ethernet as a client layer of a "transport = network". As=20 far as I understand MEF's specifications, they talk about a "transport = layer",=20 not a "transport network" underneath of the EVC layer. = For me, a transport network includes a service = layer as its=20 "top of stack" layer. The EVC layer is the top-of-stack layer in this = carrier=20 ethernet packet transport network, and the MPLS-TP layer is one of = the=20 transport path/tunnel layers that support the EVC = layer. As you notice the difference is just the point = where you=20 and I consider the boundary of a transport network to be. This = difference would=20 completely disappear if we would draw a figure in which we illustrate = how e.g.=20 an E-LAN or E-Line service would be supported. In my view the transport network boundary is = above the EVC=20 layer (i.e. EVC layer is part of the packet transport network), in = analogy to=20 the boundaries of the SDH transport network (above the LO VC layer), OTN = transport network (above LO ODU layer) and ATM transport network (above = ATM VC=20 layer). In my view you have comparable roles of the = following=20 layers: - service/channel layer (UNI-N to UNI-N = connectivity):=20 SDH LO VC - OTN LO ODU - ATM VC - = EVC - tunnel/path layer (domain edge to domain edge = connectivity): SDH HO VC - OTN HO ODU - ATM VP - MPSL-TP LSP - = EVP -=20 PBB-TE TESI Furthermore in my view you have comparable = roles of the=20 following labels: - service/channel layer label: = SDH TU timeslot - OTN LO ODU timeslot - ATM VCI = - Ethernet=20 VLAN ID - MPLS-TP PW label - tunnel/path layer label: SDH AU timeslot - OTN lambda - ATM VPI - = MPLS-TP LSP label=20 - Ethernet VLAN ID - PBB-TE <ESP-DA,ESP-SA,ESP-VID>=20 tuple. As noted two weeks ago, E-LAN over SDH has = introduced an=20 additional service layer on top of the traditional SDH service layer; = i.e. the=20 EVC layer. This EVC layer has UNI-N to UNI-N connectivity. The VC-12 = layer has=20 now only EVC termination to EVC switch point and EVC swithc point to EVC = switch=20 point connectivity. This VC-12 connectivity could be 1-to-1 with the = HOVC=20 connectivity. The VC-12 connections are not longer the = service=20 connections (this role has been taken over by the EVC), and VC-12 = connections=20 are also not tunnel connections (HO VC provides tunnel connections). = These VC-12=20 connections are only there to be able to carry the E-LAN services over = timeslots=20 of the HOVC signals. For the case those VC-12 connections terminate = at the same=20 points as where the HOVC connections terminate (i.e. SS-VC12) it = would be=20 possible to disable the VC-12 OAM; i.e. the VC-12 OAM does not add = anything to=20 that provided by the HOVC OAM and EVC OAM. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For the case that MPLS-TP would perform the = role of a=20 service/channel layer (see layer stack (2) below), then the requirements = expressed by SPs at MEF will be applicable/transitive to MPLS-TP's EVC=20 replacement in my opinion(i.e. to MPLS-TP MS-PW). = If it is not the intention that an MPLS-TP = construct=20 replaces the EVC, then the MEF service layer requirements do not apply = to the=20 MPLS-TP layer or layers (which are located below the EVC layer). = For this=20 case I agree with you. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I believe that there are four alternative = MPLS-TP based=20 packet transport network layer stacks:     (1)      &= nbsp;       =20 (2)           &nbs= p;   =20 (3)           &nbs= p;=20 (4) ------------   =20 ---------------     -------------  &nb= sp;=20 ------- |   EVC    = |    | EVC=20 & MS-PW |     |    = EVC   =20 |    | EVC | ------------   =20 ---------------     -------------   =20 ------------ |   LSP    = |   =20 |     LSP     = |    =20 |    PW     |   =20 |    PW    | ------------   =20 ---------------     -------------   =20 ------------ | T.Media |    | = Trans.Media=20 |     |    LSP =20 |    |   LSP    = | ------------   =20 ---------------     -------------   =20 ------------           &nbs= p;            = ;            = | =20 T.Media |    | T.Media |           &nbs= p;            = ;            = -------------   =20 ------------ Which of these four stacks do we want to = standardize for=20 MPLS-TP based packet transport networks? For=20 Ethernet VLAN based packet transport networks the layer stack=20 is:     (5) ------------ |   EVC    = | ------------ |   EVP    = | ------------ | T.Media | ------------ For=20 PBB-TE based packet transport networks the layer stack = is:     (6) ------------ |   EVC    = | ------------ |   TESI   = | ------------ | T.Media | ------------ If we = choose for MPLS-TP=20 based packet transport network layer stacks (2) or (4) we will deploy = the PW=20 layer as a service layer for p2p and p2mp customer services. For the = case one of=20 the endpoints of a p2p customer service is behind an Ethernet VLAN or = PBB-TE=20 domain, we will have to realize a peer-interworking between PW and EVC = to=20 support the customer service. For the case one or more of the p2mp = customer=20 service endpoints are behind an Ethernet VLAN or PBB-TE domain, we = will=20 have to realize a peer-interworking between PW and EVC to support the = customer=20 service. Such peer = interworking is=20 not required when we choose for MPLS-TP based packet transport network = layer=20 stacks (1) or (3). Regards, Maarten From: = Greg Mirsky=20 [mailto:gregimirsky@gmail.com] Sent: maandag 27 april 2009=20 20:47 To: Maarten Vissers Cc: Thomas Nadeau;=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going = around=20 in circles (Re: Associatedbidirectional transport path=20 requirements) Dear Maarten, you definitely know but I'd note that MEF = formulates=20 requirements for Carrier Ethernet as a service, i.e. client layer of a = transport=20 network, not requirements for the transport network as server layer. = Thus=20 requirements expressed by SPs at MEF are not applicable or transitive, = in my=20 view, to MPLS-TP, at least not automatically. Regards, Greg=20 Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Tom, This=20 AIS discussion has been held in previous technologies as well,=20 e.g. Ethernet OAM. The result was that AIS insertion is optional = and=20 that Ethernet equipment (see G.8021) can be configured to insert = Ethernet=20 AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very = divergent=20 from those of other operators participating in this = effort? I=20 see the requirements for OAM that have been expressed in this=20 mpls-tp discussion by BT representatives to be different from the=20 requirements expressed by other operator representatives. For=20 example draft-bhh-mpls-tp-oam-y1731 is co-authored by = representatives of=20 DT, FT, KPN, KDDI and CT. I also see that the OAM requirements = defined in=20 MEF (with input from e.g. AT&T and Verizon) be different from = those=20 expressed by BT representatives. I see that MEF is requesting to = support in=20 Y.1731 frame loss counting for more then one priority level; i.e. = an=20 extension of the existing capability that support frame loss = counting for a=20 single priority (i.e. a case of more OAM, not less OAM). I = see that=20 the operators active in MEF (e.g. AT&T, Verizon, Sprint) = have created=20 and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI=20 specifications, while representatives of BT state that there can't = be "UNI"=20 or "E-NNI" interfaces associated with packet transport networks, = as those=20 networks are "not top of stack". I see that many operators=20 require compliance with MEF specifications, including the Ethernet=20 UNI specification. I see that e.g. KPN provides a Wholesale=20 Broadband Access (WBA) service via rooted-multipoint EVCs, which = EVCs=20 terminate outside the KPN network (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.h= tml=20 and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_= Access_Service.html );=20 i.e. a peer-interconnection case and a potential case for TCM, a = case which=20 according to BT representatives does not exist. I see that the=20 "message, file, stream" concepts are key to BT's considerations, = while I=20 don't see any of that contributed by other operators. When I look = at the=20 telecom network stack (see attached slide), then message, file = stream are=20 important concepts at Layer 3 (NGN) where those represent the=20 characteristics of the main services (data, voice, video), whereas = "E-Line,=20 E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 = (PTN).=20 This raises the question what the scope of MPLS-TP is for = you: A)=20 MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the=20 IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 = Tunnel/Path=20 layer technology which has to support the EVC based Layer 2=20 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau = [mailto:tnadeau@lucidvision.com] S= ent:=20 vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 We appear to be going around in circles (Re: Associated = bidirectional=20 transport path requirements) =20 Maartin, > Ben, > > Your company is one of = the=20 many operators in the world, and the number > of nodes outside = your=20 network is factors larger then the number of > nodes inside your = network. My experience is that different operators > have = different sets=20 of requirements. Manufacturers have to support the > superset of = those=20 requirements. Each operator will then deploy the > subset of = provided=20 features that fits its needs (and turn off or don't > use the = others).=20 Your company for some years has been asking for less, > other = operators=20 have been asking for more. Manufacturers thus build > their = products=20 with lots of configurability to support all variations. = =20 Do you see our (BT's) requirements to be very divergent = from=20 those of other operators participating in this effort? Unless = our=20 requirements are very different, I am confident vendors will build = (or have=20 built) their devices based on our (sensible) = requirements. > It=20 is my opinion that we should not remove well established = features > like=20 AIS, TCM, frame loss counting, delay measurement, loopback, = etc > before=20 the majority of operators have agreed that such features are > = not=20 longer necessary. Again, that is = your=20 opinion, which frankly seems to diverge from what other operators = have=20 expressed. Furthermore, let me recommend that you get out of the = habit of=20 telling your customers (or potential ones), what they require after = they=20 have been plainly clear about what they want. Unless you think we = don't=20 know what we are talking about. Is this perhaps the = case? =20 --Tom > Regards, >=20 Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] = On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april = 2009=20 0:14 > To: mpls-tp@ietf.org > Subject: = [mpls-tp]=20 We appear to be going around in circles (Re: > = Associated >=20 bidirectional transport path requirements) > >=20 Colleagues, > > The current debates appear to be going = around in=20 circles and achieving > nothing of value IMO. Two major = operators have=20 expressed their > opinions and no operator that I can see has = disagreed=20 with those > opinions. > > I apologise for being = direct (and=20 possibly rude) but I am getting > tired of being told by folks = who do=20 not represent operators what > functionality I need or should = have in my=20 networks. > > To put some context on BT's comments in = these=20 threads: > I have the largest MPLS network in the UK. > I = have one=20 of the largest MPLS networks globally delivering service to > = 173=20 countries with over 200 000 customer ports I have (off the top = of >=20 my > head) > at least another 10 MPLS networks in specific = countries covering at > least 3 continents delivering dedicated = services=20 to particular market > segments. > > I have an = extremely=20 large SDH network in the UK consisting of over 30 > 000 switches = and=20 supporting in excess of 1 million circuits. > I have an = extremely large=20 SDH network globally delivering service in > 110=20 countries. > > I would like to think my BT colleagues and = I might=20 know a little > something about building large scale networks = and the=20 requirements of > those networks and the needs of the customers = that I=20 deliver services > to. > > Can we please stop these = circular=20 arguments which are IMO going > nowhere and focus on the task in = hand=20 which is defining the > requirements (and later > = solutions) being=20 asked for by myself, my company and my colleagues in > other = operators=20 on this list. > > Thanks > = Ben > > >=20 -- > > Ben Niven-Jenkins > IP, Data & Content=20 Architect > Network Infrastructure Architecture, = BT > >=20 E-mail: benjamin.niven-jenkins@bt.c= om >=20 Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = =20 Fax: +44 (0)1332 578827 > > British Telecommunications = plc.=20 Registered office: 81 Newgate Street > London > EC1A = 7AJ=20 Registered in England no: 1800000 > > > = On=20 23/04/2009 07:23, "liu.guoman@zte.com.cn" = <liu.guoman@zte.com.cn> &g= t;=20 wrote: > >> ben: >> I understand your meaning, = you=20 still wish to resign and make a more >> reliable and = effective, easy=20 to operator and easy to manage packet >> transport network = like me.=20 but why not apply this SDH/SONET in the >> future maybe the = following=20 cause: >> 1 it adopted circuit switching techonogy to = bring=20 lower useful of >> the resource than PTN network; >> = =20 2 it can't bear all kinds of traffics like PTN networks it = noted >>=20 that we can't apply SDH/SONET network in the future not because = it >>=20 have a complex OAM functions. while more people like to move = the >>=20 advantages of the OAM functions in SDH/SONET to PTN networks.=20 and >> AIS/FDI function is a kind of OAM functions of = SDH/SONET . we=20 should >> use and extend the AIS/FDI functions to MPLS-TP=20 ; >> >> best regards >>=20 liu >> >> >> >> Ben Niven-Jenkins = <benjamin.niven-jenkins@bt.c= om> >>=20 2009-04-23 07:58 >> >> = =CA=D5=BC=FE=C8=CB >> <liu.guoman@zte.com.cn>, = "BRUNGARD,=20 DEBORAH A, ATTLABS" >> <dbrungard@att.com> >>=20 =B3=AD=CB=CD >> <mpls-tp@ietf.org> >>=20 =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional = transport path=20 = requirements >> >> >> >> >><= BR>>> >>=20 On 21/04/2009 02:59, "liu.guoman@zte.com.cn" = <liu.guoman@zte.com.cn> &g= t;>=20 wrote: >> >>> Deborah: >>> maybe what = you=20 said is right. but I can't completely agree your >>=20 opinions. >>> IMO. mpls-tp is regard as transport network = like=20 SDH/SONET. so it >>> should have AIS/FDI fuctions as=20 SDH/SONET. >>> >>> do you think=20 so. >> >> No we must assess the requirements for = packet=20 transport networks >> supporting the needs of operators today = and in=20 the future. We must >> not blindly recreate SDH/SONET. If we = do so=20 without consideration to >> how operators' needs and = requirements may=20 have evolved (and continue >> to evolve in future) we will = have=20 failed IMO and I would severely >> question the value of the = work we=20 will have produced. If we just >> recreate SDH/SONET then = what is the=20 purpose of the work an operator >> would be better off just = deploying=20 existing SDH/SONET equipment. >> >> >>=20 = Ben >> >> >> >> >> >&g= t;=20 -------------------------------------------------------- >> = ZTE=20 Information Security Notice: The information contained in = this >>=20 mail is solely property of the sender's organization. This = mail >>=20 communication is confidential. Recipients named above are=20 obligated >> to maintain secrecy and are not permitted to = disclose=20 the contents of >> this > communication to = others. >>=20 This email and any files transmitted with it are confidential = and >>=20 intended solely for the use of the individual or entity to whom=20 they >> are addressed. If you have received this email in = error=20 please notify >> the originator of the message. Any views = expressed=20 in this message >> are those of the individual = sender. >>=20 This message has been scanned for viruses and Spam by ZTE = Anti-Spam >=20 system. > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp = --Boundary_(ID_YkMuOFbO155xctCNGzzWuQ)-- From maarten.vissers@huawei.com Tue Apr 28 04:03:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C992928C106 for ; Tue, 28 Apr 2009 04:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.318 X-Spam-Level: ** X-Spam-Status: No, score=2.318 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp1pjjh8neAS for ; Tue, 28 Apr 2009 04:03:18 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 32B8D3A7084 for ; Tue, 28 Apr 2009 04:03:17 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT006WR5ASFB@szxga04-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 19:01:40 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00BKL5ASEG@szxga04-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 19:01:40 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT00IFA5A6PQ@szxml01-in.huawei.com>; Tue, 28 Apr 2009 19:01:40 +0800 (CST) Date: Tue, 28 Apr 2009 13:01:22 +0200 From: Maarten Vissers In-reply-to: To: "'BRUNGARD, DEBORAH A, ATTLABS'" Message-id: <006701c9c7f0$ada21990$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_7UG8yvP1lIRPk7NLpuGoLg)" Thread-index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:03:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_7UG8yvP1lIRPk7NLpuGoLg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Deborah, =20 > And the UNI/ENNI being discussed there is not comparable to your definition. =20 I be more then happy if you give me alternative terms to UNI and ENNI. =20 Just use the example of a customer requesting a 2 Mbit/s service from = the SDH network, of which the first customer location is located behind the network of operator A and the second endpoint is located behind the = network of operator B. Operator A and B interconnect via a STM-1 interface with = each other. The customer connects via a 2 Mbit/s G.703 interface with the networks of operator A and B. =20 What term should I use for the interconnect of the customer to the = networks of operator A and B? I.e. if it is not possible to call this the "UNI", what should it be = called then? =20 What term should I use for the interconnect of the networks of operator = A and B? I.e. if it is not possible to call this the "ENNI", what should it be = called then? =20 Thanks for your help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: "An interface that is used = for the interconnection of customer equipment with a network element of the transport network." =20 _____ =20 From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: maandag 27 april 2009 23:00 To: Greg Mirsky; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Maarten, =20 I think you have oversimplified the discussion in MEF and in so doing = have inaccurately summarized. As Greg says, MEF is oriented towards services (SLA/SLS) and they also recognize that some operators only need simple troubleshooting tools. Considering the on-going discussion in MEF, for = the service operators group, it is questionable if Y1731 should be used by MPLS-TP as a baseline as it is considered inadequate. And I don=A1=AFt = see AT&T=A1=AFs requirements as any different from BT. I think we should = follow Adrian=A1=AFs and Ben=A1=AFs proposal to define the actual requirements = for MPLS-TP before replicating other technologies=A1=AF solutions. =20 And the UNI/ENNI being discussed there is not comparable to your = definition. =20 Deborah =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) =20 Dear Maarten, you definitely know but I'd note that MEF formulates requirements for Carrier Ethernet as a service, i.e. client layer of a transport network, = not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically.=20 Regards, Greg Mirsky 2009/4/27 Maarten Vissers Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don't > use the others). Your company for some years has been asking for less, > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from = those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market > segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must >> not blindly recreate SDH/SONET. If we do so without consideration to >> how operators' needs and requirements may have evolved (and continue >> to evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents of >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =20 --Boundary_(ID_7UG8yvP1lIRPk7NLpuGoLg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Deborah, > And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. I be = more then=20 happy if you give me alternative terms to UNI and=20 ENNI. Just use the example of a customer requesting = a 2=20 Mbit/s service from the SDH network, of which the first customer = location is=20 located behind the network of operator A and the second endpoint is = located=20 behind the network of operator B. Operator A and B interconnect via a = STM-1=20 interface with each other. The customer connects via a 2 Mbit/s G.703 = interface=20 with the networks of operator A and = B. What term should I use for the interconnect = of the=20 customer to the networks of operator A and=20 B? I.e. if it is not possible to call this the = "UNI", what=20 should it be called then? What term should I use for the interconnect = of the=20 networks of operator A and B? I.e. if it is not possible to call this the = "ENNI",=20 what should it be called then? Thanks for your=20 help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: = "An interface that is used for = the=20 interconnection of customer equipment with a network element of the = transport=20 network." From: BRUNGARD, DEBORAH A, ATTLABS=20 [mailto:dbrungard@att.com] Sent: maandag 27 april 2009=20 23:00 To: Greg Mirsky; Maarten Vissers Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Maarten, I=20 think you have oversimplified the discussion in MEF and in so doing have = inaccurately summarized. As Greg says, MEF is oriented towards services=20 (SLA/SLS) and they also recognize that some operators only need simple=20 troubleshooting tools. Considering the on-going discussion in MEF, for = the=20 service operators group, it is questionable if Y1731 should be used by = MPLS-TP=20 as a baseline as it is considered inadequate. And I don=A1=AFt see = AT&T=A1=AFs=20 requirements as any different from BT. I think we should follow = Adrian=A1=AFs and=20 Ben=A1=AFs proposal to define the actual requirements for MPLS-TP before = replicating=20 other technologies=A1=AF solutions. And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. Deborah From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of=20 Greg Mirsky Sent: Monday, April 27, 2009 2:47 = PM To:=20 Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 We appear to be going around in circles (Re:Associated bidirectional = transport=20 path requirements) Dear Maarten, you = definitely=20 know but I'd note that MEF formulates requirements for Carrier Ethernet = as a=20 service, i.e. client layer of a transport network, not requirements for = the=20 transport network as server layer. Thus requirements expressed by SPs at = MEF are=20 not applicable or transitive, in my view, to MPLS-TP, at least not=20 automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Tom, This AIS discussion has been held in = previous=20 technologies as well, e.g. Ethernet OAM. The result was that AIS = insertion=20 is optional and that Ethernet equipment (see G.8021) can be = configured to=20 insert Ethernet AIS or to not insert Ethernet AIS. > Do you see = our (BT's)=20 requirements to be very divergent from those of other operators = participating=20 in this effort? I see the requirements for OAM that have been = expressed in=20 this mpls-tp discussion by BT representatives to be different from = the=20 requirements expressed by other operator representatives. For=20 example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives = of DT,=20 FT, KPN, KDDI and CT. I also see that the OAM requirements defined in = MEF=20 (with input from e.g. AT&T and Verizon) be different from those = expressed=20 by BT representatives. I see that MEF is requesting to support in = Y.1731=20 frame loss counting for more then one priority level; i.e. an = extension of=20 the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that = the=20 operators active in MEF (e.g. AT&T, Verizon, Sprint) have created = and are=20 creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtual UNI=20 specifications, while representatives of BT state that there can't = be "UNI"=20 or "E-NNI" interfaces associated with packet transport networks, = as those=20 networks are "not top of stack". I see that many operators = require compliance=20 with MEF specifications, including the Ethernet = UNI specification. I=20 see that e.g. KPN provides a Wholesale Broadband Access (WBA) service=20 via rooted-multipoint EVCs, which EVCs terminate outside the KPN = network=20 (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.h= tml=20 and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_= Access_Service.html );=20 i.e. a peer-interconnection case and a potential case for TCM, a = case which=20 according to BT representatives does not exist. I see that the = "message,=20 file, stream" concepts are key to BT's considerations, while I don't = see any=20 of that contributed by other operators. When I look at the telecom = network=20 stack (see attached slide), then message, file stream are important = concepts=20 at Layer 3 (NGN) where those represent the characteristics of the = main=20 services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH = CES, etc"=20 are the important services at Layer 2 (PTN). This raises the question = what=20 the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 = Tunnel/Path layer=20 technology which has to support the IP based Layer 3 Services/Channel = layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has = to=20 support the EVC based Layer 2 Services/Channel=20 layer. Regards, Maarten -----Original Message----- From: Thomas = Nadeau=20 [mailto:tnadeau@lucidvision.com] S= ent:=20 vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: = [mpls-tp] We=20 appear to be going around in circles (Re: Associated bidirectional = transport=20 path requirements) Maartin, >=20 Ben, > > Your company is one of the many operators in the = world, and=20 the number > of nodes outside your network is factors larger then = the=20 number of > nodes inside your network. My experience is that = different=20 operators > have different sets of requirements. Manufacturers = have to=20 support the > superset of those requirements. Each operator will = then=20 deploy the > subset of provided features that fits its needs (and = turn off=20 or don't > use the others). Your company for some years has been = asking=20 for less, > other operators have been asking for more. = Manufacturers thus=20 build > their products with lots of configurability to support all = variations. Do you see = our (BT's)=20 requirements to be very divergent from those of other operators = participating=20 in this effort? Unless our=20 requirements are very different, I am confident vendors will build = (or have=20 built) their devices based on our (sensible) = requirements. > It is=20 my opinion that we should not remove well established features > = like AIS,=20 TCM, frame loss counting, delay measurement, loopback, etc > = before the=20 majority of operators have agreed that such features are > not = longer=20 necessary. Again, that = is your=20 opinion, which frankly seems to diverge from what other operators = have=20 expressed. Furthermore, let me recommend that you get out of the = habit of=20 telling your customers (or potential ones), what they require after = they have=20 been plainly clear about what they want. Unless you think we don't = know what=20 we are talking about. Is this perhaps the case? --Tom >=20 Regards, > Maarten > > -----Original = Message----- >=20 From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org]=20 On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april = 2009=20 0:14 > To: mpls-tp@ietf.org >=20 Subject: [mpls-tp] We appear to be going around in circles (Re: >=20 Associated > bidirectional transport path = requirements) > >=20 Colleagues, > > The current debates appear to be going = around in=20 circles and achieving > nothing of value IMO. Two major operators = have=20 expressed their > opinions and no operator that I can see has = disagreed=20 with those > opinions. > > I apologise for being = direct (and=20 possibly rude) but I am getting > tired of being told by folks who = do not=20 represent operators what > functionality I need or should have in = my=20 networks. > > To put some context on BT's comments in these=20 threads: > I have the largest MPLS network in the UK. > I = have one=20 of the largest MPLS networks globally delivering service to > 173=20 countries with over 200 000 customer ports I have (off the top = of >=20 my > head) > at least another 10 MPLS networks in specific = countries=20 covering at > least 3 continents delivering dedicated services to=20 particular market > segments. > > I have an extremely = large=20 SDH network in the UK consisting of over 30 > 000 switches and = supporting=20 in excess of 1 million circuits. > I have an extremely large SDH = network=20 globally delivering service in > 110 countries. > > I = would=20 like to think my BT colleagues and I might know a little > = something about=20 building large scale networks and the requirements of > those = networks and=20 the needs of the customers that I deliver services > = to. > >=20 Can we please stop these circular arguments which are IMO going > = nowhere=20 and focus on the task in hand which is defining the > requirements = (and=20 later > solutions) being asked for by myself, my company and my = colleagues=20 in > other operators on this list. > > Thanks >=20 Ben > > > -- > > Ben Niven-Jenkins > = IP,=20 Data & Content Architect > Network Infrastructure = Architecture,=20 BT > > E-mail: benjamin.niven-jenkins@bt.c= om >=20 Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = Fax: +44 = (0)1332=20 578827 > > British Telecommunications plc. Registered = office: 81 Newgate=20 Street > London > EC1A 7AJ Registered = in England=20 no: 1800000 > > >=20 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> &g= t;=20 wrote: > >> ben: >> I understand your meaning, = you still=20 wish to resign and make a more >> reliable and effective, easy = to=20 operator and easy to manage packet >> transport network like = me. but=20 why not apply this SDH/SONET in the >> future maybe the = following=20 cause: >> 1 it adopted = circuit=20 switching techonogy to bring lower useful of >> the resource = than PTN=20 network; >> 2 it can't = bear all=20 kinds of traffics like PTN networks it noted >> that we can't = apply=20 SDH/SONET network in the future not because it >> have a = complex OAM=20 functions. while more people like to move the >> advantages of = the OAM = functions in=20 SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of = OAM=20 functions of SDH/SONET . we should >> use and extend the = AIS/FDI=20 functions to MPLS-TP ; >> >> best regards >>=20 liu >> >> >> >> Ben Niven-Jenkins = <benjamin.niven-jenkins@bt.c= om> >>=20 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >>=20 <liu.guoman@zte.com.cn>,=20 "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com> >> = =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> = =D6=F7=CC=E2 >> Re: [mpls-tp] Associated = bidirectional=20 transport path=20 requirements >> >> >> >> >><= BR>>> >>=20 On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> &g= t;>=20 wrote: >> >>> Deborah: >>> maybe what = you said=20 is right. but I can't completely agree your >>=20 opinions. >>> IMO. mpls-tp is regard as transport network = like=20 SDH/SONET. so it >>> should have AIS/FDI fuctions as=20 SDH/SONET. >>> >>> do you think=20 so. >> >> No we must assess the requirements for = packet=20 transport networks >> supporting the needs of operators today = and in=20 the future. We must >> not blindly recreate SDH/SONET. If we do = so=20 without consideration to >> how operators' needs and = requirements may=20 have evolved (and continue >> to evolve in future) we will have = failed=20 IMO and I would severely >> question the value of the work we = will have=20 produced. If we just >> recreate SDH/SONET then what is the = purpose of=20 the work an operator >> would be better off just deploying = existing=20 SDH/SONET equipment. >> >> >>=20 Ben >> >> >> >> >> >&g= t;=20 -------------------------------------------------------- >> ZTE = Information Security Notice: The information contained in = this >> mail=20 is solely property of the sender's organization. This mail >>=20 communication is confidential. Recipients named above are = obligated >>=20 to maintain secrecy and are not permitted to disclose the contents=20 of >> this > communication to others. >> This = email and=20 any files transmitted with it are confidential and >> intended = solely=20 for the use of the individual or entity to whom they >> are = addressed.=20 If you have received this email in error please notify >> the=20 originator of the message. Any views expressed in this = message >> are=20 those of the individual sender. >> This message has been = scanned for=20 viruses and Spam by ZTE Anti-Spam > system. > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_7UG8yvP1lIRPk7NLpuGoLg)-- From hhelvoort@chello.nl Tue Apr 28 04:19:27 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87803A6F9D for ; Tue, 28 Apr 2009 04:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51LJSP9BLtVe for ; Tue, 28 Apr 2009 04:19:27 -0700 (PDT) Received: from viefep28-int.chello.at (viefep28-int.chello.at [62.179.121.48]) by core3.amsl.com (Postfix) with ESMTP id 863953A67E4 for ; Tue, 28 Apr 2009 04:19:26 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090428112024.SXJ1912.viefep12-int.chello.at@edge03.upc.biz>; Tue, 28 Apr 2009 13:20:24 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge03.upc.biz with edge id kzLN1b0533KDBhC03zLQTi; Tue, 28 Apr 2009 13:20:24 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49F6E675.2030903@chello.nl> Date: Tue, 28 Apr 2009 13:20:21 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 References: <2ECAA42C79676B42AEBAC11229CA7D0C0479DBB6@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0479DBB6@E03MVB2-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:19:27 -0000 Neil, You wrote: > NH=> This only applies if the client/server binding is fixed. And of > course way back in the 70s when binary all 1s popped out of the failed > TTL logic into the PDH transport hierarchy this was true. Also: no > labels here and no client traffic units to create. This is again very academic. In real life failed TTL could get stuck at "1" or "0". Between the TTL and the line there is analog circuitry that can detect this "stuck at" and replace consequently the HDB3 output by a 1.024 Mbit/s sinusoidal signal which in binary is an all ONEs signal. The "stuck at" defect is reported and the all ONEs is used to inhibit alarm reporting. At the receiver side of the line it is similar, when a line signal defect (e.g. LOS, LOC, LOF) is detected consequently an all ONEs signal replaces the original. When there is a line defect noise is received generating an arbitrary 0/1 pattern. Replacing this noise by an all ONEs pattern again inhibits alarm reporting. The LOS/LOC/LOF is the only alarm important for fault localisation. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Tue Apr 28 04:29:55 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433C43A70A4 for ; Tue, 28 Apr 2009 04:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcPV3NPbkSqh for ; Tue, 28 Apr 2009 04:29:54 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 071453A709C for ; Tue, 28 Apr 2009 04:29:53 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090428113113.KLVE10095.viefep16-int.chello.at@edge05.upc.biz>; Tue, 28 Apr 2009 13:31:13 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge05.upc.biz with edge id kzXB1b07h3KDBhC05zXDA0; Tue, 28 Apr 2009 13:31:13 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49F6E8FF.3030400@chello.nl> Date: Tue, 28 Apr 2009 13:31:11 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Adrian Farrel References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe> <49F62310.4020109@chello.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:29:55 -0000 Hi Adrian, You replied: > On mature reflection... ;-) >> How about: >> the requirement is that a server layer shall inform its clients >> that it has detected a service interuption, this to ensure that >> the clients can inhibit (unnecessary) alarms. > > I believe that the use made of the information is out of scope. That > would reduce us to... > >> the requirement is that a server layer shall inform its clients >> that it has detected a service interruption. The second part could be a separate requirement because MPLS-TP is also a client layer: If a client layer is informed by its server layer that a defect in the server layer trail has been detected the client layer shall not raise an alarm related to that defect. > We might note that "service" is possibly ambiguous. Some people regard a > "service" as being what exists in the client layer. Some people see it > as what the server layer delivers to the client layer. Could we restate > this in terms of server layer trails? If you think it is more appropriate and less ambiguous: The server layer shall inform its clients that it has detected that the trail transporting the client signal is has a defect. Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From neil.2.harrison@bt.com Tue Apr 28 04:32:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9F53A6C5A for ; Tue, 28 Apr 2009 04:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlzDPXcwANTJ for ; Tue, 28 Apr 2009 04:32:13 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 697373A7084 for ; Tue, 28 Apr 2009 04:32:13 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 12:33:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 12:33:27 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0479DE0F@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <49F6E675.2030903@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnH82hXjBkFLFxqRKKmAGlG+5vjwwAAKEtg From: To: X-OriginalArrivalTime: 28 Apr 2009 11:33:29.0121 (UTC) FILETIME=[26F40110:01C9C7F5] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:32:14 -0000 Thanks Hubb....but the key point is the 1st sentence, ie: "This only applies if the client/server binding is fixed. " .....and the related bits you snipped regarding the ability of the client layer network to re-route traffic without any involvement of the server. I agree the nature of the actual PDH AIS signal is somewhat academic and it is of far less importance than the other observations...indeed when the other observations apply then we can't meaningfully send AIS to the client anyway, and that is the key point. regards, Neil =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Huub van Helvoort > Sent: 28 April 2009 12:20 > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transport path requirements) >=20 > Neil, >=20 > You wrote: >=20 > > NH=3D> This only applies if the client/server binding is=20 > fixed. And of > > course way back in the 70s when binary all 1s popped out of=20 > the failed > > TTL logic into the PDH transport hierarchy this was true. Also: no > > labels here and no client traffic units to create. =20 >=20 > This is again very academic. > In real life failed TTL could get stuck at "1" or "0". > Between the TTL and the line there is analog circuitry > that can detect this "stuck at" and replace consequently the > HDB3 output by a 1.024 Mbit/s sinusoidal signal which in binary > is an all ONEs signal. The "stuck at" defect is reported and > the all ONEs is used to inhibit alarm reporting. > At the receiver side of the line it is similar, when a line > signal defect (e.g. LOS, LOC, LOF) is detected consequently > an all ONEs signal replaces the original. When there is a line > defect noise is received generating an arbitrary 0/1 pattern. > Replacing this noise by an all ONEs pattern again inhibits alarm > reporting. The LOS/LOC/LOF is the only alarm important for > fault localisation. >=20 > Regards, Huub. >=20 > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From hhelvoort@chello.nl Tue Apr 28 04:45:56 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B24928C210 for ; Tue, 28 Apr 2009 04:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nvj4iLPGyK8 for ; Tue, 28 Apr 2009 04:45:55 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id B042B3A705E for ; Tue, 28 Apr 2009 04:45:35 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep15-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090428114654.CLJP6909.viefep15-int.chello.at@edge04.upc.biz>; Tue, 28 Apr 2009 13:46:54 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge04.upc.biz with edge id kzmt1b0083KDBhC04zmudE; Tue, 28 Apr 2009 13:46:54 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49F6ECAC.7080500@chello.nl> Date: Tue, 28 Apr 2009 13:46:52 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe><49F62310.4020109@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A0E90B@DEMUEXC014.nsn-intra.net> <6FD21B53861BF44AA90A288402036AB40220EDA4@FRVELSMBS21.ad2.ad.alcatel.com> <077E41CFFD002C4CAB7DFA4386A53264A415D6@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A415D6@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ext BUSI ITALO , mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:45:56 -0000 Dear Nurit, You wondered: > If we agree that the requirement is included, so why do we keep with the > endless discussions on this requirement? The endless discussion is caused by the use of certain three letter abbreviations (which I will not repeat to avoid another round of discussions). We agreed to write the requirements without mentioning the solutions related to these three letter abbreviations. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From BETTS01@nortel.com Tue Apr 28 05:20:08 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D569B28C1E8 for ; Tue, 28 Apr 2009 05:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UljGY4omophT for ; Tue, 28 Apr 2009 05:20:08 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id ACE3C28C11B for ; Tue, 28 Apr 2009 05:20:07 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3SCLPC05918; Tue, 28 Apr 2009 12:21:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 08:21:08 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516F07E55@zcarhxm2.corp.nortel.com> In-Reply-To: <49F6E8FF.3030400@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnH9NtaK4F5bQkpS4qiRjzfenyURQABSWXw References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe><49F62310.4020109@chello.nl> <49F6E8FF.3030400@chello.nl> From: "Malcolm Betts" To: , "Adrian Farrel" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:20:09 -0000 All, I support these proposals with a minor refinement. I suggest that the following wording should be included in the MPLS-TP OAM requirements draft. R1) A MPLS-TP server layer shall inform its clients when a defect is detected in the MPLS-TP trail being used to support those clients. R2) When a MPLS-TP client layer is informed of the failure of a server layer trail it should propagate that information to the MPLS-TP trail termination. It may use this information to suppress alarms. As we develop the OAM Implementation draft we need to determine if and how this requirement can be met reliably. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Huub van Helvoort Sent: Tuesday, April 28, 2009 7:31 AM To: Adrian Farrel Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Hi Adrian, You replied: > On mature reflection... ;-) >> How about: >> the requirement is that a server layer shall inform its clients that=20 >> it has detected a service interuption, this to ensure that the=20 >> clients can inhibit (unnecessary) alarms. >=20 > I believe that the use made of the information is out of scope. That=20 > would reduce us to... >=20 >> the requirement is that a server layer shall inform its clients that=20 >> it has detected a service interruption. The second part could be a separate requirement because MPLS-TP is also a client layer: If a client layer is informed by its server layer that a defect in the server layer trail has been detected the client layer shall not raise an alarm related to that defect. > We might note that "service" is possibly ambiguous. Some people regard > a "service" as being what exists in the client layer. Some people see=20 > it as what the server layer delivers to the client layer. Could we=20 > restate this in terms of server layer trails? If you think it is more appropriate and less ambiguous: The server layer shall inform its clients that it has detected that the trail transporting the client signal is has a defect. Cheers, Huub. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From BETTS01@nortel.com Tue Apr 28 05:22:09 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B469B28C20C for ; Tue, 28 Apr 2009 05:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1m0jaw4De5u for ; Tue, 28 Apr 2009 05:22:08 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 644A228C20A for ; Tue, 28 Apr 2009 05:22:08 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3SCMaP17040; Tue, 28 Apr 2009 12:22:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 08:23:25 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516F07E59@zcarhxm2.corp.nortel.com> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0479DE0F@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) Thread-Index: AcnH82hXjBkFLFxqRKKmAGlG+5vjwwAAKEtgAAH0GqA= References: <49F6E675.2030903@chello.nl> <2ECAA42C79676B42AEBAC11229CA7D0C0479DE0F@E03MVB2-UKBR.domain1.systemhost.net> From: "Malcolm Betts" To: , Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:22:09 -0000 Neil, I think that this important point should be captured/considered in the context of the OAM implementation draft. I don't think it belongs in the OAM requirements draft. =20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: Tuesday, April 28, 2009 7:33 AM To: hhelvoort@chello.nl Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) Thanks Hubb....but the key point is the 1st sentence, ie: "This only applies if the client/server binding is fixed. " .....and the related bits you snipped regarding the ability of the client layer network to re-route traffic without any involvement of the server. I agree the nature of the actual PDH AIS signal is somewhat academic and it is of far less importance than the other observations...indeed when the other observations apply then we can't meaningfully send AIS to the client anyway, and that is the key point. regards, Neil =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Huub van Helvoort > Sent: 28 April 2009 12:20 > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport > path requirements) >=20 > Neil, >=20 > You wrote: >=20 > > NH=3D> This only applies if the client/server binding is > fixed. And of > > course way back in the 70s when binary all 1s popped out of > the failed > > TTL logic into the PDH transport hierarchy this was true. Also: no > > labels here and no client traffic units to create. =20 >=20 > This is again very academic. > In real life failed TTL could get stuck at "1" or "0". > Between the TTL and the line there is analog circuitry that can detect > this "stuck at" and replace consequently the > HDB3 output by a 1.024 Mbit/s sinusoidal signal which in binary is an=20 > all ONEs signal. The "stuck at" defect is reported and the all ONEs is > used to inhibit alarm reporting. > At the receiver side of the line it is similar, when a line signal=20 > defect (e.g. LOS, LOC, LOF) is detected consequently an all ONEs=20 > signal replaces the original. When there is a line defect noise is=20 > received generating an arbitrary 0/1 pattern. > Replacing this noise by an all ONEs pattern again inhibits alarm=20 > reporting. The LOS/LOC/LOF is the only alarm important for fault=20 > localisation. >=20 > Regards, Huub. >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Tue Apr 28 05:47:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A533A691A for ; Tue, 28 Apr 2009 05:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[AWL=1.297, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HigccNpiRw0b for ; Tue, 28 Apr 2009 05:47:42 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 93D393A6AB6 for ; Tue, 28 Apr 2009 05:46:29 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00BWZA7GN5@szxga03-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 20:47:40 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00E8ZA7GI2@szxga03-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 20:47:40 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT00BA3A766Z@szxml01-in.huawei.com>; Tue, 28 Apr 2009 20:47:40 +0800 (CST) Date: Tue, 28 Apr 2009 14:47:34 +0200 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, nurit.sprecher@nsn.com, Italo.Busi@alcatel-lucent.it, hhelvoort@chello.nl, adrian@olddog.co.uk Message-id: <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:47:45 -0000 Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation. There is no difference with what we do today in SDH and OTN. A client/server relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generation is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > ================================================================ > > http://www.van-helvoort.eu/ > > ================================================================ > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From John.E.Drake2@boeing.com Tue Apr 28 06:39:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4603A70B7 for ; Tue, 28 Apr 2009 06:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4d7vDB7n2oL for ; Tue, 28 Apr 2009 06:39:30 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0A6833A70A6 for ; Tue, 28 Apr 2009 06:39:30 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3SDeYxj003261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 06:40:42 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3SDeYxl020394; Tue, 28 Apr 2009 08:40:34 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3SDdw7s019027; Tue, 28 Apr 2009 08:40:34 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 06:40:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 06:40:30 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01ABABE0@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A0E90B@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwABJw2nA= References: <7A71F689116D4CEB93DE5BA04CCAC11F@your029b8cecfe><49F62310.4020109@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A0E90B@DEMUEXC014.nsn-intra.net> From: "Drake, John E" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , , "Adrian Farrel" X-OriginalArrivalTime: 28 Apr 2009 13:40:33.0619 (UTC) FILETIME=[E7821230:01C9C806] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:39:31 -0000 Why do we want to stipulate what the client layer does?=20 > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > [mailto:nurit.sprecher@nsn.com]=20 > Sent: Monday, April 27, 2009 9:56 PM > To: hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transport pathrequirements) >=20 > Huub, > I think that the requirement is to provide a mechanism to=20 > suppress alarms in the networks, to ensure that alarms that=20 > may be generated by client layers as a result of a failure=20 > condition in the server layer may be suppressed. > Every thing else is a solution, etc.=20 > I propose to phrase the requirement appropriately and=20 > conclude the discussion on this in the context of the=20 > requirements (until we are getting to the solution phase).=20 > This requirement is included in the OAM requirement draft.=20 > Best regards, > NUrit >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Huub van Helvoort > Sent: Tuesday, April 28, 2009 12:27 AM > To: Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transport path requirements) >=20 > Hi Adrian, >=20 > You wrote: >=20 > > Isn't the solution here the same as the one I proposed for "TCM"? >=20 > Indeed, and that we do not have to around in circles about TCM. >=20 > How about: > the requirement is that a server layer shall inform its=20 > clients that it has detected a service interuption, this to=20 > ensure that the clients can inhibit (unnecessary) alarms. >=20 > Cheers, Huub. >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.van-helvoort.eu/=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From neil.2.harrison@bt.com Tue Apr 28 07:10:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0A728C2B8 for ; Tue, 28 Apr 2009 07:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfikXFx4WERP for ; Tue, 28 Apr 2009 07:10:09 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D4F2E28C2BB for ; Tue, 28 Apr 2009 07:08:25 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 15:09:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 15:09:43 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E1FBD@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAAAb8BoA== From: To: , , , , X-OriginalArrivalTime: 28 Apr 2009 14:09:46.0071 (UTC) FILETIME=[FC0D0670:01C9C80A] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:10:11 -0000 Thanks Maarten...a couple of further observations in-line:=20 Maarten wrote 28 April 2009 13:48 > >=20 > Neil, >=20 > > However, if the client can dynamically change its routing=20 > in response > > to link failures in its topology (because some server layer=20 > network has > > failed....which may or may not belong to the same operating=20 > party as the > > client) then there is no fixed client/server relationship.=20 >=20 > I believe there is a fixed client/server relationship also in=20 > this case in > the network. This relationship is broken when the connection=20 > is rerouted. > Such reroute will remove the CP/FP and as such will stop the=20 > AIS generation. >=20 > There is no difference with what we do today in SDH and OTN.=20 > A client/server > relationship is fixed until the point in time that the=20 > connection is either > teardown or rerouted. When either of the two cases occur, the=20 > AIS generation > is stopped. Until such action is performed, AIS is generated=20 > during signal > fail condition period and inserted into the connection. NH=3D> I'm pretty uneasy about these ideas. I know this was the case in the largely static PDH/SDH networks but I'm very uncomfortable with carrying this idea through to packet based networks like MPLS-TP....and in the case of a cl-ps mode packet network then I really cannot see how anyone could seriously suggest AIS/FDI had any validity at all. =20 >=20 > In MPLS-TP we have the requirement that MPLS-TP must be able=20 > to operate > without control plane. NH=3D> True, but we must also design the OAM to work with a CP. And looking forward to the case of MPLS-TPoverMPLS-TP (which will sure as anything be required) it will be essential IMO that we can have independent routing/restoration processes in both the client and server MPLS-TP networks. And in such a case it will not be a good idea to try force permament client/server bindings here....the client MPLS-TP layer network will want to run its own routing/restoration processes quite independently of the server MPLS-TP network. Once upon a time I used to think AIS was a good idea in co mode networks, but having been forced to really think about this over the last few years I am now of the firm view that AIS is not a good idea at all. The only essential thing we need with the defect detection/handling OAM is CV and BDI....and of course the requirement that each layer network has its own independent OAM. I truly believe we will be making a mistake in carrying the concept of AIS over into MPLS-TP when have the opportunity not to make this mistake here. We should not do things just because they are either (i) possible and/or (ii) it's how we did stuff historically if we can see there are technical problems. regards, Neil This implies that it will operate without > restoration, and that there will not be frequent rerouteing=20 > ongoing. Result > is that client/server relationships will last until the connection is > teardown. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of neil.2.harrison@bt.com > Sent: dinsdag 28 april 2009 10:07 > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Nurit, >=20 > I believe the reason we need this discussion is that there is=20 > an unstated > assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in=20 > response to > link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating=20 > party as the > client) then there is no fixed client/server relationship. >=20 > Refer to my post earlier today and consider what this means=20 > in the case of a > cl-ps IP client layer network or a some SVC-based co-ps/co-cs=20 > mode client > layer network. The key point here is the *routing process*=20 > in the client is > independent of the server layer network....so there is not a fixed > client/server relationship. Further, there is also no=20 > requirement for the > server to keep track of where its client traffic routings are at any > epoch.....indeed why should it in the general case where these are > independent layer networks? >=20 > So the only OAM requirement that is critical is that the OAM=20 > of the client > and server layer networks are independent. It is thus not=20 > sensible to make > client layer alarm supression a 'requirement' here...in fact=20 > if this is in > the OAM requirements then it is technically wrong and should=20 > be removed IMO. >=20 > regards, Neil=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN -=20 > > IL/Hod HaSharon) > > Sent: 28 April 2009 08:46 > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > >=20 > > If we agree that the requirement is included, so why do we=20 > keep with=20 > > the endless discussions on this requirement? > >=20 > > -----Original Message----- > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Tuesday, April 28, 2009 10:44 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > > Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional transport > > pathrequirements) > >=20 > > I think that the requirements are defined in section 2.2.8 of > > draft-ietf-mpls-tp-oam-requirements-01 > >=20 > > Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN=20 > > > - IL/Hod HaSharon) > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > To: hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > > transport pathrequirements) > > >=20 > > > Huub, > > > I think that the requirement is to provide a mechanism to=20 > suppress=20 > > > alarms in the networks, to ensure that alarms that may be > > generated by > > > client layers as a result of a failure condition in the=20 > server layer=20 > > > may be suppressed. > > > Every thing else is a solution, etc.=20 > > > I propose to phrase the requirement appropriately and=20 > conclude the=20 > > > discussion on this in the context of the requirements=20 > (until we are=20 > > > getting to the solution phase). > > > This requirement is included in the OAM requirement draft.=20 > > > Best regards, > > > NUrit > > >=20 > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On=20 > > > Behalf Of ext Huub van Helvoort > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > To: Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > path requirements) > > >=20 > > > Hi Adrian, > > >=20 > > > You wrote: > > >=20 > > > > Isn't the solution here the same as the one I proposed=20 > for "TCM"? > > >=20 > > > Indeed, and that we do not have to around in circles about TCM. > > >=20 > > > How about: > > > the requirement is that a server layer shall inform its=20 > clients that=20 > > > it has detected a service interuption, this to ensure that the=20 > > > clients can inhibit (unnecessary) alarms. > > >=20 > > > Cheers, Huub. > > >=20 > > > -- > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > http://www.van-helvoort.eu/=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 From maarten.vissers@huawei.com Tue Apr 28 07:21:38 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0583A6C8A for ; Tue, 28 Apr 2009 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.755 X-Spam-Level: X-Spam-Status: No, score=0.755 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jglm-HMgOXuq for ; Tue, 28 Apr 2009 07:21:37 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E1F1128C20C for ; Tue, 28 Apr 2009 07:21:07 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00961EL6DC@szxga04-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 22:22:18 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00CAREL6PK@szxga04-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 22:22:18 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT0055BEL1WJ@szxml02-in.huawei.com>; Tue, 28 Apr 2009 22:22:18 +0800 (CST) Date: Tue, 28 Apr 2009 16:22:16 +0200 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C0479DBB6@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, hhelvoort@chello.nl Message-id: <01e501c9c80c$beb670c0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfuYvo1g5PacUQAme2dazjKllYwARrvMwAA6CPaA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:21:38 -0000 Neil, > if I create the topology of an IP layer network with links provided by SDH, > Ethernet, ATM, OTN, etc servers, and each of these server links is provided > by a different operator, then why should the servers need have knowledge of > where the IP flows have moved to in response to a server layer failure when > the new routes have been calculated by the IGP in the IP layer network? In an IP layer network there are typically a number of IP transport entities; i.e. the INTERNET is one IP transport entity and an IP VPN is another IP transport entity. Within this scope, I agree with you that the servers don't need to know where the IP flows within an IP transport entity have moved to. But the servers must know when an IP transport entity (e.g. IP VPN) has moved. Rationale for the latter is that the label identifying the IP VPN has to be withdrawn. And the same applies to an Ethernet layer network. The Ethernet transport entities are the VLANs. The servers of the Ethernet layer network don't need to know where the MAC flows within a VLAN have moved to. But the servers must know when an Ethernet transport entity (i.e. VLAN) has moved. Rationale for the latter is that the VLAN ID identifying the VLAN has to be withdrawn. Ethernet AIS is associated with the VLAN, not with the individual MAC flows within a VLAN. In Ethernet transport networks (which use network management for VLAN setup) there is as such a fixed client/server relationship between a VLAN in the Ethernet layer netowrk and the servers over which this VLAN is supported. This fixed client/server relationship enables the deployment of Etherent AIS as an alarm suppression mechanism within VLANs. So you have to adapt your understanding of the entity on which AIS acts in Ethernet. AIS acts on the Ethernet transport entity (i.e. VLAN); AIS does not act on the MAC flows that exist within the Ethernet transport entity. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 8:43 To: hhelvoort@chello.nl; adrian@olddog.co.uk; benjamin.niven-jenkins@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements) Huub wrote 27 April 2009 22:27 > > Hi Adrian, > > You wrote: > > > Isn't the solution here the same as the one I proposed for "TCM"? > > Indeed, and that we do not have to around in circles about TCM. > > How about: > the requirement is that a server layer shall inform its clients that > it has detected a service interuption, this to ensure that the clients > can inhibit (unnecessary) alarms. NH=> This only applies if the client/server binding is fixed. And of course way back in the 70s when binary all 1s popped out of the failed TTL logic into the PDH transport hierarchy this was true. Also: no labels here and no client traffic units to create. Where the client can dynamically be re-routed in response to a server failure the proposed text is not valid. It is also not necessary that the server has to keep track of where its client traffic routings have moved to. For example, if I create the topology of an IP layer network with links provided by SDH, Ethernet, ATM, OTN, etc servers, and each of these server links is provided by a different operator, then why should the servers need have knowledge of where the IP flows have moved to in response to a server layer failure when the new routes have been calculated by the IGP in the IP layer network? I can apply the same logic to an SVC-based co-ps/co-cs mode client....indeed the co-cs mode PSTN is like this. These observations make it quite clear to me at least that just copying the AIS behaviour of the old transport hierarchies that had fixed client/server relationships is not a sensible thing to do. IMO the only essential DP OAM requirement is that each layer network should be self-sufficient wrt OAM and not rely on any server layer primitives being passed upwards. Moreover, it should also be noted that (i) the defects that can occur in each of the 3 network modes are not the same and (ii) their OAM requirements are not identically the same. So the OAM that applies to the cl-ps mode (eg IP) is not the same as the OAM that applies to the co-ps mode (eg MPLS-TP) and neither of these is identically the same as the OAM that applies to the co-cs mode (eg SDH). Note - The only point being considered here is the real client and server traffic relationship. The creation of a hierarchy of TCM sublayers is a separate topic. Further, it is quite clear from a simple technical analysis that any non top-of-stack network has no need for E-NNI peer-partition working between different operating parties. So this is also a separate issue. However, I propose that this latter point be captured in the MPLS-TP requirements draft due to its stand-alone and generic importance, ie this applies to more than just DP OAM. Ben can you please consider this point as/when the MPLS-TP requirements draft is updated. regards, Neil > Cheers, Huub. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From IBryskin@advaoptical.com Tue Apr 28 08:04:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8EB028C281 for ; Tue, 28 Apr 2009 08:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BrwnzAyQRw2 for ; Tue, 28 Apr 2009 08:04:40 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 772E628C2AD for ; Tue, 28 Apr 2009 08:03:36 -0700 (PDT) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n3SF4dZ1002292 for ; Tue, 28 Apr 2009 17:04:39 +0200 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 28 Apr 2009 17:04:52 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 17:04:38 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 28 Apr 2009 11:04:36 -0400 From: Igor Bryskin To: Maarten Vissers , "neil.2.harrison@bt.com" , "nurit.sprecher@nsn.com" , "Italo.Busi@alcatel-lucent.it" , "hhelvoort@chello.nl" , "adrian@olddog.co.uk" Date: Tue, 28 Apr 2009 11:04:34 -0400 Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3457FB@atl-srv-exgen.atl.advaoptical.com> References: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com> In-Reply-To: <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:04:41 -0000 Neil. I actually agree with Maarten on this. I don't quite understand why do you = keep talking about fixed client-server relationship. It is fixed as long as= the client layer connection configured this way (statically or dynamically= ). As soon as the connection is re-routed, this relationship is broken (bec= ause this is a part of the re-routing process) and hence the server trail t= ermination points will know that the server trail now serves one connection= less, whereas some other server trail(s) will learn that they serve from n= ow on one connection more. These new client-server relationships are fixed = until the next re-routing. Cheers, Igor=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-luce= nt.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as the > client) then there is no fixed client/server relationship.=20 I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation= . There is no difference with what we do today in SDH and OTN. A client/serve= r relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generatio= n is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of = a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client i= s independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO= . regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -=20 > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) >=20 > If we agree that the requirement is included, so why do we keep with=20 > the endless discussions on this requirement? >=20 > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) >=20 > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN=20 > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > transport pathrequirements) > >=20 > > Huub, > > I think that the requirement is to provide a mechanism to suppress=20 > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer=20 > > may be suppressed. > > Every thing else is a solution, etc.=20 > > I propose to phrase the requirement appropriately and conclude the=20 > > discussion on this in the context of the requirements (until we are=20 > > getting to the solution phase). > > This requirement is included in the OAM requirement draft.=20 > > Best regards, > > NUrit > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > >=20 > > Hi Adrian, > >=20 > > You wrote: > >=20 > > > Isn't the solution here the same as the one I proposed for "TCM"? > >=20 > > Indeed, and that we do not have to around in circles about TCM. > >=20 > > How about: > > the requirement is that a server layer shall inform its clients that=20 > > it has detected a service interuption, this to ensure that the=20 > > clients can inhibit (unnecessary) alarms. > >=20 > > Cheers, Huub. > >=20 > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From IBryskin@advaoptical.com Tue Apr 28 08:26:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727873A6D3B for ; Tue, 28 Apr 2009 08:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meapTHapwFRk for ; Tue, 28 Apr 2009 08:26:40 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 176D53A7100 for ; Tue, 28 Apr 2009 08:26:34 -0700 (PDT) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n3SFRXpR003477 for ; Tue, 28 Apr 2009 17:27:34 +0200 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 28 Apr 2009 17:27:47 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 17:27:33 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 28 Apr 2009 11:27:31 -0400 From: Igor Bryskin To: "davarish@yahoo.com" , "'Maarten Vissers'" , "neil.2.harrison@bt.com" , "nurit.sprecher@nsn.com" , "Italo.Busi@alcatel-lucent.it" , "hhelvoort@chello.nl" , "adrian@olddog.co.uk" Date: Tue, 28 Apr 2009 11:27:28 -0400 Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B345810@atl-srv-exgen.atl.advaoptical.com> References: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3457FB@atl-srv-exgen.atl.advaoptical.com> <049e01c9c814$0cbd1830$26374890$@com> In-Reply-To: <049e01c9c814$0cbd1830$26374890$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:26:41 -0000 Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a cont= rol plane. As part of such provisioning a binding is created between this c= onnection and network C at the two adaptation points on either side of the = link provided by network C. When the connection is torn down, this binding = is removed as a part of the cleanup process. The re-routing of the connecti= on onto A-F-G-E is indistinguishable from the connection tear down as far a= s link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com]=20 Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher= @nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.= co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that networ= k C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer.=20 -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically)= . As soon as the connection is re-routed, this relationship is broken (becaus= e this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connectio= n less, whereas some other server trail(s) will learn that they serve from no= w on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as the > client) then there is no fixed client/server relationship.=20 I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation= . There is no difference with what we do today in SDH and OTN. A client/serve= r relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generatio= n is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of = a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client i= s independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO= . regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -=20 > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) >=20 > If we agree that the requirement is included, so why do we keep with=20 > the endless discussions on this requirement? >=20 > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) >=20 > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN=20 > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > transport pathrequirements) > >=20 > > Huub, > > I think that the requirement is to provide a mechanism to suppress=20 > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer=20 > > may be suppressed. > > Every thing else is a solution, etc.=20 > > I propose to phrase the requirement appropriately and conclude the=20 > > discussion on this in the context of the requirements (until we are=20 > > getting to the solution phase). > > This requirement is included in the OAM requirement draft.=20 > > Best regards, > > NUrit > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > >=20 > > Hi Adrian, > >=20 > > You wrote: > >=20 > > > Isn't the solution here the same as the one I proposed for "TCM"? > >=20 > > Indeed, and that we do not have to around in circles about TCM. > >=20 > > How about: > > the requirement is that a server layer shall inform its clients that=20 > > it has detected a service interuption, this to ensure that the=20 > > clients can inhibit (unnecessary) alarms. > >=20 > > Cheers, Huub. > >=20 > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Tue Apr 28 08:33:33 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338543A6B21 for ; Tue, 28 Apr 2009 08:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSJoJl7OEskU for ; Tue, 28 Apr 2009 08:33:31 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 56CD33A6D26 for ; Tue, 28 Apr 2009 08:31:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00G1VHV5BO@szxga03-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 23:33:05 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00HW5HV50B@szxga03-in.huawei.com> for mpls-tp@ietf.org; Tue, 28 Apr 2009 23:33:05 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT00BH5HUO6Z@szxml01-in.huawei.com>; Tue, 28 Apr 2009 23:33:04 +0800 (CST) Date: Tue, 28 Apr 2009 17:32:50 +0200 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C047E1FBD@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, nurit.sprecher@nsn.com, Italo.Busi@alcatel-lucent.it, hhelvoort@chello.nl, adrian@olddog.co.uk Message-id: <000901c9c816$9beb61e0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAAAb8BoAACSF8g Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:33:33 -0000 Thanks Neil, let me add a bit more to your observations in line... including a proposal to change the objective of CC, which will result in the dropping of the requirement for AIS... I hope that this could resolve this discussion... -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: dinsdag 28 april 2009 16:10 To: maarten.vissers@huawei.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thanks Maarten...a couple of further observations in-line: Maarten wrote 28 April 2009 13:48 > > > Neil, > > > However, if the client can dynamically change its routing > in response > > to link failures in its topology (because some server layer > network has > > failed....which may or may not belong to the same operating > party as the > > client) then there is no fixed client/server relationship. > > I believe there is a fixed client/server relationship also in this > case in the network. This relationship is broken when the connection > is rerouted. > Such reroute will remove the CP/FP and as such will stop the AIS > generation. > > There is no difference with what we do today in SDH and OTN. > A client/server > relationship is fixed until the point in time that the connection is > either teardown or rerouted. When either of the two cases occur, the > AIS generation is stopped. Until such action is performed, AIS is > generated during signal fail condition period and inserted into the > connection. NH=> I'm pretty uneasy about these ideas. I know this was the case in the largely static PDH/SDH networks but I'm very uncomfortable with carrying this idea through to packet based networks like MPLS-TP....and in the case of a cl-ps mode packet network then I really cannot see how anyone could seriously suggest AIS/FDI had any validity at all. [MV] I have replied to another email from you a couple of minutes ago. In that reply I have tried to describe the cl-ps mode packet networks have two entities that we need to analyse separately: 1) transport entity, which is set up under connection management control (with or without help of a control plane) and are traffic engineered 2) flows, which exist within the transport entity but are not under control of connection management and are not traffic engineered. [MV] Examples of cl-ps transport entities are: IP VPN and Ethernet VLAN. Examples of cl-ps flows are: IP flow and MAC flow. [MV] I fully agree with you that you do not generate AIS for each of the MAC flows inside an Ethernet VLAN when the server of the VLAN fails. [MV] I do however strongly believe that a transport network must generate AIS for the Ethernet VLAN (i.e. for the Ethernet transport entity) when the server of the VLAN fails. Rationale is the fixed cleint/server relationship between the VLAN and its servers, the use of CCM OAM in the VLAN and the LOC defect that is detected also when the server fails which results in alarm storms if not suppressed. > > In MPLS-TP we have the requirement that MPLS-TP must be able to > operate without control plane. NH=> True, but we must also design the OAM to work with a CP. And looking forward to the case of MPLS-TPoverMPLS-TP (which will sure as anything be required) it will be essential IMO that we can have independent routing/restoration processes in both the client and server MPLS-TP networks. And in such a case it will not be a good idea to try force permament client/server bindings here....the client MPLS-TP layer network will want to run its own routing/restoration processes quite independently of the server MPLS-TP network. [MV] Yes, and these independent routing/restoration processes would not be hindered by registered client/server relationships, as those relationships can be broken and replaced by alternative relationships. And alarm suppression by means of AIS/FDI will not be impacted by such independence, nor will it impact such independence. AIS is inserted into MPLS-TP connections (that have been interrupted due to a server fault) for which there is a client/server registration and as long as there is this registration. That's the beauty of this mechanism and that's why it works good in existing technologies. Once upon a time I used to think AIS was a good idea in co mode networks, but having been forced to really think about this over the last few years I am now of the firm view that AIS is not a good idea at all. The only essential thing we need with the defect detection/handling OAM is CV and BDI....and of course the requirement that each layer network has its own independent OAM. [MV] I do not understand whay caused you to change your idea? Some pre-condition must have been changed? Can you indicate which one? E.g. is it the believe that every connection is restored almost immediately using a control plane? I truly believe we will be making a mistake in carrying the concept of AIS over into MPLS-TP when have the opportunity not to make this mistake here. We should not do things just because they are either (i) possible and/or (ii) it's how we did stuff historically if we can see there are technical problems. [MV] Neither of those two cases is a rationale for my promotion of AIS in MPLS-TP. The rationale for MPLS-TP AIS is proper and scalable fault management in a transport network. CC is there to detect faults in the connectivity of the matrices in the layer network. But most of the times that CC is lost is due to a fault in a server layer. AIS provides the necessary filter information to discover the matrix faults. [MV] It would be possible to drastically change the nature and objective of CC... i.e. it is possible to declare that 1) there are no layer network continuity faults; i.e. any interruption of the connection that is not due to a server fault is intentional, and as such does not need to be alarmed 2) all continuity faults are due to server layer interruptions 3) loss of continuity is not longer a primary alarm; i.e. LOC is a service status indication and will not cause any fault localization procedure to be initiated 4) loss of continuity detection will by default not be alarmed 5) loss of continuity will trigger protection switching and performance monitoring. [MV] In the above scenario we do not need to deploy AIS as there is nothing to suppress (LOC is not longer alarmed as a primary fault that needs immediate fixing). [MV] Any misconnections are still alarmed as a primary fault (i.e. MisMerge (MMG) alarm). Regards, Maarten regards, Neil This implies that it will operate without > restoration, and that there will not be frequent rerouteing ongoing. > Result is that client/server relationships will last until the > connection is teardown. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com > Sent: dinsdag 28 april 2009 10:07 > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Nurit, > > I believe the reason we need this discussion is that there is an > unstated assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. > > Refer to my post earlier today and consider what this means in the > case of a cl-ps IP client layer network or a some SVC-based > co-ps/co-cs mode client layer network. The key point here is the > *routing process* in the client is independent of the server layer > network....so there is not a fixed client/server relationship. > Further, there is also no requirement for the server to keep track of > where its client traffic routings are at any epoch.....indeed why > should it in the general case where these are independent layer > networks? > > So the only OAM requirement that is critical is that the OAM of the > client and server layer networks are independent. It is thus not > sensible to make client layer alarm supression a 'requirement' > here...in fact if this is in the OAM requirements then it is > technically wrong and should be removed IMO. > > regards, Neil > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > Nurit (NSN - > > IL/Hod HaSharon) > > Sent: 28 April 2009 08:46 > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > > > > If we agree that the requirement is included, so why do we > keep with > > the endless discussions on this requirement? > > > > -----Original Message----- > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Tuesday, April 28, 2009 10:44 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > > Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > pathrequirements) > > > > I think that the requirements are defined in section 2.2.8 of > > draft-ietf-mpls-tp-oam-requirements-01 > > > > Italo > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > Nurit (NSN > > > - IL/Hod HaSharon) > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > To: hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > > transport pathrequirements) > > > > > > Huub, > > > I think that the requirement is to provide a mechanism to > suppress > > > alarms in the networks, to ensure that alarms that may be > > generated by > > > client layers as a result of a failure condition in the > server layer > > > may be suppressed. > > > Every thing else is a solution, etc. > > > I propose to phrase the requirement appropriately and > conclude the > > > discussion on this in the context of the requirements > (until we are > > > getting to the solution phase). > > > This requirement is included in the OAM requirement draft. > > > Best regards, > > > NUrit > > > > > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On > > > Behalf Of ext Huub van Helvoort > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > To: Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > path requirements) > > > > > > Hi Adrian, > > > > > > You wrote: > > > > > > > Isn't the solution here the same as the one I proposed > for "TCM"? > > > > > > Indeed, and that we do not have to around in circles about TCM. > > > > > > How about: > > > the requirement is that a server layer shall inform its > clients that > > > it has detected a service interuption, this to ensure that the > > > clients can inhibit (unnecessary) alarms. > > > > > > Cheers, Huub. > > > > > > -- > > > ================================================================ > > > http://www.van-helvoort.eu/ > > > ================================================================ > > > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > From dbrungard@att.com Tue Apr 28 08:51:22 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2411B3A6B92 for ; Tue, 28 Apr 2009 08:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.466 X-Spam-Level: X-Spam-Status: No, score=-104.466 tagged_above=-999 required=5 tests=[AWL=-1.918, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUr7OXdzUJWx for ; Tue, 28 Apr 2009 08:51:18 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id CD0FA3A6C17 for ; Tue, 28 Apr 2009 08:50:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1240933929!19264088!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 24476 invoked from network); 28 Apr 2009 15:52:09 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Apr 2009 15:52:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3SFq8aM013980 for ; Tue, 28 Apr 2009 11:52:09 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3SFq3Fa013926 for ; Tue, 28 Apr 2009 11:52:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C819.45F1E247" Date: Tue, 28 Apr 2009 11:52:02 -0400 Message-ID: In-Reply-To: <006701c9c7f0$ada21990$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Thread-Index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJAABtoogA== References: <006701c9c7f0$ada21990$6c02a8c0@china.huawei.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Maarten Vissers" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:51:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C819.45F1E247 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Exactly =A8C G707 defined the ENNI for SDH and G703/G704 for PDH. The = PHY and framing is defined (per layer). This definition is very = different from your earlier email. It does not require supporting = PDH<->SDH interworking, or PDH OAM in SDH, or OAM interworking between a = client/server as one of your earlier emails required: =20 >For this case it is necessary to develop ETH<>PW(client) layer=20 > network > interworking specifications. To limit the complexity of such layer=20 > network interworking, it is beneficial to select the MPLS-TP PW OAM = > to > use the Y.7131 OAM PDUs as proposed in draft-bhh-mpls-tp-oam-y1731. = > I.e. > both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs =20 The interconnection of equipment (at one layer) should not put any = restrictions on other layers. =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: Tuesday, April 28, 2009 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) =20 Deborah, =20 > And the UNI/ENNI being discussed there is not comparable to your = definition. =20 I be more then happy if you give me alternative terms to UNI and ENNI. =20 Just use the example of a customer requesting a 2 Mbit/s service from = the SDH network, of which the first customer location is located behind = the network of operator A and the second endpoint is located behind the = network of operator B. Operator A and B interconnect via a STM-1 = interface with each other. The customer connects via a 2 Mbit/s G.703 = interface with the networks of operator A and B. =20 What term should I use for the interconnect of the customer to the = networks of operator A and B? I.e. if it is not possible to call this the "UNI", what should it be = called then? =20 What term should I use for the interconnect of the networks of operator = A and B? I.e. if it is not possible to call this the "ENNI", what should it be = called then? =20 Thanks for your help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: "An interface that is used = for the interconnection of customer equipment with a network element of = the transport network." =20 ________________________________ From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: maandag 27 april 2009 23:00 To: Greg Mirsky; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) Maarten, =20 I think you have oversimplified the discussion in MEF and in so doing = have inaccurately summarized. As Greg says, MEF is oriented towards = services (SLA/SLS) and they also recognize that some operators only need = simple troubleshooting tools. Considering the on-going discussion in = MEF, for the service operators group, it is questionable if Y1731 should = be used by MPLS-TP as a baseline as it is considered inadequate. And I = don=A1=AFt see AT&T=A1=AFs requirements as any different from BT. I = think we should follow Adrian=A1=AFs and Ben=A1=AFs proposal to define = the actual requirements for MPLS-TP before replicating other = technologies=A1=AF solutions. =20 And the UNI/ENNI being discussed there is not comparable to your = definition. =20 Deborah =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) =20 Dear Maarten, you definitely know but I'd note that MEF formulates requirements for = Carrier Ethernet as a service, i.e. client layer of a transport network, = not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, = in my view, to MPLS-TP, at least not automatically.=20 Regards, Greg Mirsky 2009/4/27 Maarten Vissers Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don't > use the others). Your company for some years has been asking for less, > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from = those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market > segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must >> not blindly recreate SDH/SONET. If we do so without consideration to >> how operators' needs and requirements may have evolved (and continue >> to evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents of >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =20 ------_=_NextPart_001_01C9C819.45F1E247 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Exactly =A8C G707 defined the ENNI for SDH and G703/G704 = for PDH. The PHY and framing is defined (per layer). This definition is very = different from your earlier email. It does not require supporting PDH<->SDH interworking, or PDH OAM in SDH, or OAM interworking between a = client/server as one of your earlier emails required: >For this case it is necessary to develop ETH<>PW(client) layer > network >    interworking = specifications. To limit the complexity of such layer >    network interworking, it = is beneficial to select the MPLS-TP PW OAM > to >    use the Y.7131 OAM PDUs = as proposed in draft-bhh-mpls-tp-oam-y1731. > I.e. >    both Ethernet and MPLS-TP = will then use e.g. CCM OAM PDUs The interconnection of equipment (at one layer) should = not put any restrictions on other layers. From:= Maarten = Vissers [mailto:maarten.vissers@huawei.com] Sent: Tuesday, April 28, 2009 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Deborah, > And the UNI/ENNI being discussed there is not comparable = to your definition. I be more then happy if you give me alternative terms to UNI = and ENNI. Just use the example of a customer requesting a 2 Mbit/s = service from the SDH network, of which the first customer location is located = behind the network of operator A and the second endpoint is located behind the = network of operator B. Operator A and B interconnect via a STM-1 interface with = each other. The customer connects via a 2 Mbit/s G.703 interface with the = networks of operator A and B. What term should I use for the interconnect of the = customer to the networks of operator A and B? I.e. if it is not possible to call this the = "UNI", what should it be called then? What term should I use for the interconnect of the = networks of operator A and B? I.e. if it is not possible to call this the = "ENNI", what should it be called then? Thanks for your help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: = "An interface that is used for the interconnection of customer equipment = with a network element of the transport network." From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] Sent: maandag 27 april 2009 23:00 To: Greg Mirsky; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Maarten, I think you have oversimplified the discussion in MEF and = in so doing have inaccurately summarized. As Greg says, MEF is oriented = towards services (SLA/SLS) and they also recognize that some operators only need = simple troubleshooting tools. Considering the on-going discussion in MEF, for = the service operators group, it is questionable if Y1731 should be used by = MPLS-TP as a baseline as it is considered inadequate. And I don=A1=AFt see = AT&T=A1=AFs requirements as any different from BT. I think we should follow = Adrian=A1=AFs and Ben=A1=AFs proposal to define the actual requirements for MPLS-TP before = replicating other technologies=A1=AF solutions. And the UNI/ENNI being discussed there is not comparable = to your definition. Deborah From:= mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Dear Maarten, you definitely know but I'd note that MEF formulates requirements for = Carrier Ethernet as a service, i.e. client layer of a transport network, not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Tom, This AIS discussion has been held in previous technologies as well, = e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not = insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those = of other operators participating in this effort? I see the requirements for OAM that have been = expressed in this mpls-tp discussion by BT representatives to be different from the = requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, = FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed = by BT representatives. I see that MEF is requesting to support in Y.1731 = frame loss counting for more then one priority level; i.e. an extension of = the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) = have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet = transport networks, as those networks are "not top of stack". I see that many = operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services= .html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadban= d_Access_Service.html ); i.e. a peer-interconnection case and a potential case for TCM, a = case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to = BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) = where those represent the characteristics of the main services (data, = voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope = of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the = number > of nodes outside your network is factors larger then the number = of > nodes inside your network. My experience is that different = operators > have different sets of requirements. Manufacturers have to support = the > superset of those requirements. Each operator will then deploy = the > subset of provided features that fits its needs (and turn off or = don't > use the others). Your company for some years has been asking for = less, > other operators have been asking for more. Manufacturers thus = build > their products with lots of configurability to support all = variations. Do you see our = (BT's) requirements to be very divergent from those of other operators participating in this effort? Unless our requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established = features > like AIS, TCM, frame loss counting, delay measurement, loopback, = etc > before the majority of operators have agreed that such features = are > not longer necessary. Again, that is = your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), = what they require after they have been plainly clear about what they = want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and = achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with = those > opinions. > > I apologise for being direct (and possibly rude) but I am = getting > tired of being told by folks who do not represent operators = what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service = to > 173 countries with over 200 000 customer ports I have (off the top = of > my > head) > at least another 10 MPLS networks in specific countries covering = at > least 3 continents delivering dedicated services to particular = market > segments. > > I have an extremely large SDH network in the UK consisting of over = 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service = in > 110 countries. > > I would like to think my BT colleagues and I might know a = little > something about building large scale networks and the requirements = of > those networks and the needs of the customers that I deliver = services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues = in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.c= om > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a = more >> reliable and effective, easy to operator and easy to manage = packet >> transport network like me. but why not apply this SDH/SONET in = the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because = it >> have a complex OAM functions. while more people like to move = the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we = should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins <benjamin.niven-jenkins@bt.c= om> >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> <liu.guoman@zte.com.cn>, "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com> >> =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path = requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree = your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. = so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport = networks >> supporting the needs of operators today and in the future. We = must >> not blindly recreate SDH/SONET. If we do so without = consideration to >> how operators' needs and requirements may have evolved (and = continue >> to evolve in future) we will have failed IMO and I would = severely >> question the value of the work we will have produced. If we = just >> recreate SDH/SONET then what is the purpose of the work an = operator >> would be better off just deploying existing SDH/SONET = equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in = this >> mail is solely property of the sender's organization. This = mail >> communication is confidential. Recipients named above are = obligated >> to maintain secrecy and are not permitted to disclose the = contents of >> this > communication to others. >> This email and any files transmitted with it are confidential = and >> intended solely for the use of the individual or entity to whom = they >> are addressed. If you have received this email in error please = notify >> the originator of the message. Any views expressed in this = message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE = Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp<= /o:p> _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp<= /o:p> ------_=_NextPart_001_01C9C819.45F1E247-- From maarten.vissers@huawei.com Tue Apr 28 09:03:51 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028FA28C27B for ; Tue, 28 Apr 2009 09:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.397 X-Spam-Level: *** X-Spam-Status: No, score=3.397 tagged_above=-999 required=5 tests=[AWL=-1.559, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h04sZlMfaEV1 for ; Tue, 28 Apr 2009 09:03:43 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5F64828C2A7 for ; Tue, 28 Apr 2009 09:01:58 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00GWQJ98BO@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 00:03:08 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT006T9J97WA@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 00:03:08 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT00BEFJ696Z@szxml01-in.huawei.com>; Wed, 29 Apr 2009 00:03:07 +0800 (CST) Date: Tue, 28 Apr 2009 18:01:24 +0200 From: Maarten Vissers In-reply-to: <03dc01c9c744$90576540$b1062fc0$@com> To: davarish@yahoo.com, andy.bd.reid@bt.com Message-id: <002601c9c81a$9926c6d0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Km8uPqFftZWJLuGdxtColA)" Thread-index: AcnDIuyXwu/Qpw5VRfK/mLqx15DB/gACRNUgAEYQ6mAAICAwEAAQMUQgAIVo2fAAA218gAADv3tAAADKjhAAAh2VEAA1nlmg Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:03:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Km8uPqFftZWJLuGdxtColA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Shahram, =20 A transport equipment contains many devices (chips) and a lot of = software. A single configuration command from a management system may result in the configuration of multiple devices and software modules in the transport equipment. The equipment manufacturer develops its product such that = there is consistent configuration amoung these devices and software modules. = That is why from outside the black box you can view this as a single configuration. =20 REgards, Maarten _____ =20 From: Shahram Davari [mailto:davarish@yahoo.com]=20 Sent: maandag 27 april 2009 16:29 To: 'Maarten Vissers'; andy.bd.reid@bt.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 In MPLS forwarding (and consequently in MPLS-TP forwarding), no binding = is kept at adaptation sink function. In other words top label is popped and lower label is looked up independent of what the popped label was. But = to generate AIS you require such binding to be kept in memory so that you = can generate AIS on the client LSPs. =20 So I disagree with your analysis here. Because the client/server binding = for forwarding purpose is kept at source point and not sink point. I agree with Andy, and the chips that I have seen that generate AIS, generate it using an independent client/server binding table that must = be configured which may be miss-configured. =20 Regards, Shahram =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Maarten Vissers Sent: April-27-09 9:43 AM To: andy.bd.reid@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements =20 Andy, =20 The configuration of this set of label values in the adaptation function = is locked to the configuration of the set of matrix connections/matrix forwarding processes. It is locked to the creation of the = "Connection/Flow Point" that interconnects the Matrix and Adaptation functions. I.e. a = sinlge action which result in configuration of both a Connection = function/Matrix and an Adaptation function/Link End. =20 If there would be any mistake in this configuration, you will notice = this immediately as the CC frames will not reach the MEP Sink functions at = the output ports of the connection (i.e. connection set up is not = succesful). =20 Regards, Maarten =20 _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 14:59 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 Snipped =20 "AIS generation is performed in the adaptation sink function for the set = of active client signals; i.e. for the set of connection/flow points that = are activated on the adaptation sink function (which are represented by the = set of active labels/VIDs/...)." =20 In your words, the adaptation sink function contains a set of label = values, one for each client connection. Different words, same thing. This is a = list of label values which requires configuration if it is to be used for the injection of AIS and could be configured wrongly. It's the same thing = even in your ITU-T speak. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 27 April 2009 13:28 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 I have the impression that you do not have the correct understanding of = the SNC protection switching fucntional models and the location and control = of AIS insertion. Your understanding seems not aligned with the = specifications in our equipment and protection swithcing recommendations. See inline... =20 _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: maandag 27 april 2009 12:50 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 It is of course true that adding a boolean input to a logical system increases the number of possible input states. So adding an AIS boolean = to CC boolean creates four possible states not just the three you identify below. There are=20 =20 - good CC, no AIS - CC fault, AIS present - good CC, AIS present - CC fault, no AIS =20 We must ask what practical scenarios could generate each of these input states. =20 Good CC, no AIS One hopes this is because this is because the service is working = properly.=20 =20 [mv] I don't think that there is only "hope". This condition reflects = that there is no disconnect.=20 If every frame/packet arrives correctly is not checked by the reception = of CC and correct MEGID/MEPID. Frame/packet loss is checked by the = frame/packet loss measurement that is embedded in the CCM frames, and can be = activated.=20 =20 CC fault, AIS present One hopes this is because the service is faulty and one hopes this is because of a fault in a server layer. In fact, the presence of the AIS = could be misleading (see below).=20 =20 [mv] With equipment that complies with the equipment standards this condition doesn't give you just "hope". It gives you "knowledge" that = the discontinutity experienced in the connection is due to a server layer = fault. =20 Good CC, AIS present This situation could arise because of a misconfiguration of the AIS forwarding label injection table. And there are a number of scenarios = which make this quite likely when protection switching occurs. Depending on = the exact scope of the forwarding labels, a protection switch may well = require the proactive purging of entries from the AIS forwarding label injection table following the protection switch (this could equivalently been seen = as the forwarding function proactively dropping the AIS packets).=20 =20 [mv] I don't think that those scenarios are likely scenarios. Equipment compliant with ITU-T's equipment recommendations will not have those scenarios. Only equipment that does not comply with those equipment recommendations could have such scenarios. Just do not deploy such equipment. =20 [mv] The AIS insertion in the functional models is performed in the Adaptation Sink functions. Those Adaptation Sink functions are connected = to the Connection function in which the SNC Protection process is located. = The AIS insertion in an Adaptation sink fucntion continues independent of = the state of the protection switch process in the Connection function; i.e. = the selector in the protection process will only receive frames/packets from either the working SNC, or the protection SNC (but never from both).=20 =20 CC fault, no AIS As you suggest, this could arise from a misconfiguration of a forwarding function. But it could equally arise from a misconfiguration of the AIS forwarding label injection table. In fact, the latter actually seems = just as likely and particularly problematic for maintenance. Unlike normal forwarding, any mismatch between the forwarding configuration and the = AIS forwarding label injection table will lie dormant and until a server = fault arises. Then this generates a false and misunderstood fault condition = with maintenance looking for the fault in the wrong place.=20 =20 [mv] As indicated in the above comment, equipment compliant with the equipment and protection switching recommendation will not behave as you suggest. Only equipment not-compliant with our equipment/protection switching recommendation may do this, but such equipment should simply = not be deployed. =20 [mv] AIS generation is performed in the adaptation sink function for the = set of active client signals; i.e. for the set of connection/flow points = that are activated on the adaptation sink function (which are represented by = the set of active labels/VIDs/...). There is no "AIS forwarding label = injection table" in any of our equipment recommendations. AIS will be generated = for each client CI output on the set of CPs/FPs on the adaptation sink = function when aAIS consequent action condition is true. =20 =20 The first two states can be reliably diagnosed with CC alone. The second = two arise from the introduction of the AIS/FDI. However, any possible = benefit that might arise is completely masked by the fact that the AIS itself = must be configured and there is no reason for this to be more reliable than = what it is supposed to be monitoring. Indeed, there seems good reason to = think that it will be less reliable.=20 =20 [mv] You are turning things upside down... CC is present to detect continuity and connectivity problems introduced in the layer network's Connection functions. As such you can not diagnose the second state with = CC alone. With CC alone one of your colleagues will be requested to = initiate a number of Loopback tests to find out which connection function is misconfigured. This is the wrong action of course, as there is a server layer fault. =20 [mv] You do not understand the AIS "configuration" aspect. AIS = generation configuration is on the node, not on each individual connection. = Networks that deploy AIS have it active on all their NNIs.=20 =20 There is no avoiding that AIS in circuit switching is fundamentally different from AIS in packet switching. - in circuit switching, you must fill the bit stream with something and = the information injected requires no configuration whatsoever. - in packet switching, no packets is a perfectly valid condition and = the injection of AIS requires individual client connection specific = information to be configured.=20 =20 [mv] In packet transport networks with connectivity checking no packets = is not a valid condition.=20 =20 [mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require any individual client connection specific information.=20 =20 [mv] ATM VP AIS and ATM VC AIS does not require any individual client = (i.e. VP, VC) connection specific information.=20 =20 [mv] ETH AIS does not require any individual client connection identification specification, but it requires reuse of the client MEG = Level information which is also required for the ETH MIP functions on the interface port. =20 [mv] I.e. AIS insertion does not require individual client connection specific information. Either no additional information at all is = required, or additional information is required that is shared with other fucntions/processes in the interface. =20 The objective is not to replicate the data plane primitives of = SONET/SDH, but the triggers to the operational systems so that the operational = systems and processes are the same.=20 =20 [mv] And that is exactly what we do with support of AIS in packet = transport networks (ATM, Ethernet, T-MPLS =3D> MPLS-TP).=20 =20 The simple CC replicates all the triggers to management systems made by SONET/SDH and gives maximum compatibility. Conversely, the inclusion of = data plane AIS requires a whole new area of configuration and generates a = whole new set of fault conditions which cannot be localised by SONET/SDH processes. So, ironically, packet AIS is directly opposed to backwards compatibility you claim is the main drive.=20 =20 [mv] I hope that you now understand that it is the opposite case is that = is present. Simple CC does **not** replicates all triggers... AIS is needed = in addition. =20 Regards, Maarten =20 Andy =20 =20 =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 24 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 AIS/FDI does give additional information. Let me explain: =20 The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective = of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that = can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection. =20 Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection. =20 As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected. =20 AIS has been introduced and is used to help differentiate between the = two fault cases. 1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate.=20 2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to = locate the misconfigured or failed connection function. Once this faulty = connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored. =20 The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. = This performance monitoring information is used to verify the performance = against the SLA for the connection. =20 Regards, Maarten =20 _____ =20 From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com]=20 Sent: vrijdag 24 april 2009 12:34 To: maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Maarten, =20 These points are irrelevant to the points I made. My point is that = AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this. =20 Andy =20 =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 =20 _____ =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 23 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path = requirements Andy, =20 > The problem is *not* about a lack of alarm suppression in the data = plane - that information is readily available. =20 I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have = more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin = domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B. =20 > The issue arises because the two sides of maintenance want different things. The fault fixing > guys want to locate the fault and don't want any other information. = The service maintenance > guys want to know whether their customer service is working. =20 This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of the additional SSF alarm. The SSF alarm is for the service guys = telling them that the service was interrupted due to a fault in a server layer. = AIS suppresses the LOC alarm in those cases so that the maintenance guys = don't get triggered and start looking for a fault that is outside their area. =20 Regards, Maarten =20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of andy.bd.reid@bt.com Sent: woensdag 22 april 2009 12:14 To: liu.guoman@zte.com.cn; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Liu, =20 Allow me to jump in. You are bringing together two things which are = separate and for which AIS/FDI is no help. Maintenance operations are concerned = with two separate things. =20 1) Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance). 2) Identifying the health of end to end connections, especially when = they are directly supporting customer services (service maintenance). =20 The problem is *not* about a lack of alarm suppression in the data plane = - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* = the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you = think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!) =20 The issue arises because the two sides of maintenance want different = things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working. =20 This arose in the early days of SONET/SDH, when the operations guys = demanded that the equipment did *not* suppress the traffic alarm even when AIS = was being received as the service guys want to know about the alarms. The = normal practice is for the equipment to report the alarms *including* AIS and = then a filter is applied in the management system to suppress alarms to the = fault fixing guys. As I'm aware, there are many different techniques applied = for the filtering algorithms, especially when you consider multiple = concurrent faults in a network, however, the existance of AIS/FDI doesn't add = anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And = if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up = simple time-stamp correlation!=20 =20 In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most = circumstances, the filter has automatically done this. So localisation you describe is = only when the filter hasn't worked for some reason. =20 But the bottom line is, whatever operations process you want to use, = AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to = fill the bit stream with something*. =20 =20 =20 Andy =20 Andy Reid=20 Chief Network Services Strategist=20 BT Innovate=20 =20 Office: +44 (0)1277 322038=20 Mobile: +44 (0)7917 025451=20 Fax : +44 (0)1277 324015=20 Email: andy.bd.reid@bt.com=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British = Telecommunications plc which may be privileged or confidential. The information is intended = to be for the use of the individual(s) or entity named above. If you are = not the intended recipient be aware that any disclosure, copying, = distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be monitored and = may be recorded to secure effective operation and for other lawful business purposes. =20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 22 April 2009 09:15 To: Harrison,N,Neil,CXM R Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Neil:=20 thank you for wasting more time in describling the problems. but I = think some of what you said is no relations with our problem.for me, maybe = AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there = is no AIS/FDI functions, when there is a defects in a given layer network, = it can cause multiple alarm events to be raised. it is diffcult for = operators to locate and diagnose the faults.=20 though I completely agree you on adding new things and functions will bring some complexity . but if we have no functions, it is more complex = and difcult for operators to maintence and administrator the network. so I = think every new functions and things may have positive and negative effects. = but we should consider it very much, don't delete some functions at random.=20 best regards=20 liu=20 =20 2009-04-21 20:30=20 =CA=D5=BC=FE=C8=CB , =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 RE: [mpls-tp] Associated bidirectional transport path requirements =20 =09 Liu,=20 =20 If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.=20 =20 1 Provide a transparent client/server relationship...which means:=20 - all client bits treated equally=20 - client bit ordering preserved=20 - no attempt to infer client symbol (ie sequence of client bits) = meaning and no attempt to change client symbols=20 - the traffic behaviour of client X must not impact the performance experienced by client Y=20 =20 A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)=20 =20 =20 2 Since MPLS-TP is a transport network it is not a top-of-stack = network (ie it does not support directly external message/file/stream = applications). MPLS-TP therefore does not require an E-NNI specification. A key = corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.=20 =20 =20 Now wrt OAM MPLS-TP is a co-ps mode network. You could argue this = should have FDI/AIS....however, the merit of this is highly questionable. When = I and colleagues discussed whether PBB-TE (also a co-ps mode network) = should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.=20 =20 AIS/FDI is historically linked to the early PDH co-cs mode layer = networks that used TTL logic. When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is = key point. Further, in these networks there is a fairly static/long-holding client server relationship. Clearly this is not true in the cl-ps mode = and it's why IETF have never specified AIS for IP and its why IEEE had the = good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely = IMO retained it in Y.1731....but I suspect any operator planning to use = Ethernet equipment would always look to IEEE stds and not ITU ones).=20 =20 AIS/FDI and the co-ps mode is debatable. As I noted above, on balance = we considered not a good idea for PBB-TE OAM because it requires a = conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.=20 =20 You should also have seen me make the point many times in the past that = the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here. Also note = that the OAM required for each of the 3 network modes is not the same, = despite what some claim.=20 =20 regards, Neil=20 =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of liu.guoman@zte.com.cn Sent: 21 April 2009 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path = requirements Deborah:=20 maybe what you said is right. but I can't completely agree your = opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET.=20 do you think so.=20 best regards=20 liu=20 "BRUNGARD, DEBORAH A, ATTLABS" =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-20 23:47=20 =20 =CA=D5=BC=FE=C8=CB "Maarten Vissers" , = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] Associated bidirectional transport path requirements =20 =09 I agree with Neil, it is very questionable the value of AIS/FDI in a packet network- any mode. It can result in a DoS attack by an operator on themselves so even Y1731 recommends not to block data frames: "A MEP can decide whether it blocks data frames when it detects dAIS. The principle requirement that influences this decision is that data frames ought to be forwarded as much as possible, without the possibility of forwarding wrong data frames downstream." Table I.7-2 shows for AIS, not to block. And as Y1731 states, AIS can only be used under very constrained architectures - if required for MPLS-TP, it needs to have the same guidance as in Y1731, i.e. point-to-point and server/client one-to-one: "for a point-to-point ETH connection, a MEP has only a single peer MEP. Therefore, there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives the ETH-AIS information." So should only be within one domain - then no need. Deborah -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Monday, April 20, 2009 10:05 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated bidirectional transport path requirements Neil, > but AIS/FDI in the cl mode?...do me a favour! Ethernet AIS is indeed a requirement and a necessity. And you will not be able to understand that as long as you refuse to accept that "cl-mode" is a forwarding mode within a **transport entity**. G.800 amendment 1 has finally reintroduced this transport entity into G.800. Besides that, it also introduced the **differentiated connection**: [G.800 am1] "A differentiated connection is a transport entity that transfers information belonging to multiple communications between ports across a subnetwork. <..> In a differentiated connection message contents are interpreted to identify (sets of) communications which receive different treatment. The sets of communications may be distinguished by the forwarding identifier or other layer information. Order is not necessarily preserved between messages belonging to sets of communications receiving different treatment. Sets of communications may be identified for purposes such as traffic conditioning or preserving communication message order." Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet AIS provides AIS within the scope of such "differentiated connection". If you apply this to my proposed PTN layer stack, then the EVC layer topology will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN VP trails inside metro and core domains interconnecting EVC matrices. When one of those EVC links is interrupted, e.g. in the core between metro 1 and metro 4 (see attached slide), then the EVC differentiated connection that is present on this link will be interrupted. At the EVC switch/bridge node in metro 4 this interruption is noticed and EVC-AIS is inserted in the downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and D5. The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address, which guarantees that the AIS is broadcast to the endpoints of the EVC. I believe that it is time for you to adapt your view on co and cl modes and relate it to the forwarding mode **INSIDE** a transport entity.=20 What we know as the internet is essentially an "IP differentiated connection" with a billion or more ports. What we know as an IP VPN is essentially an "IP differentiated connection" with e.g. n ports (n in the range of e.g. 2 to 1000). What we know as an Ethernet VLAN is essentially an "Ethernet differentiated connection" with n ports (n in the range of e.g. 2 to 1000). What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated connection" with 2 ports. What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports. Transport network OAM applies to transport entities, which are (in terms of G.800 am1) connections and differentiated connections. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 17 april 2009 22:00 To: John.E.Drake2@boeing.com; Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.com; maarten.vissers@huawei.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated bidirectional transport path requirements John, Thanks this is a great platform to explain why OAM for the 3 network modes needs to be different. I am getting a wee bit tired of folks trying to make all 3 network modes look alike (and then, even worse, interwork them as as peers...esp when not not top-of-stack networks...I mean how silly can we get?). I am even more frustrated by the fact those peddling this FUD only ever seem to consider OAM and forget all other DP/CP/MP components (esp top-of-stack message/file/stream application adaptations). How wrong can this get!=20 In the co modes a *connection* is a very specific and *constraining* construct.....I am assuming here we respect the rules of a connection (ie single source) though some folks don't even bother to respect this, and this is despite the fact that we all know what problems multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP). When we have a connection this restricts *all* DP (ie traffic and OAM) to stay within the bounds of the connection. Which is fine under defect-free conditions, but if we have leaking traffic then the constraining nature of the connection construct is broken. In a nutshell what this means is that OAM that is of a request/response nature cannot be trusted in co mode networks under misconnectivity defects.....indeed, why should a leaking DP have a symmetric go/return defect behaviour?....very likely it won't. So whilst request/response OAM is right for the cl mode it is not right for the co mode under misconnectivity defect conditions. More generally the 3 modes are different and not just in OAM requirements....but AIS/FDI in the cl mode?...do me a favour!...at least IEEE had the good sense to bin this for Ethernet even though it remains in Y.1731. And which is why I often trot-out the rather silly (to have to say this) observation that if IP (cl mode) could do it all then why have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs). The answer lies in the physics...and G.800 attempts to explain that physics....G.805 does not. So, the 3 modes are different...please accept/rejoice in this fact as they all offer something different/important. But do not be hoodwinked by those who peddle a story that that tries to make the OAM of the 3 modes the same.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > Sent: 17 April 2009 20:02 > To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > requirements >=20 > Italo, >=20 > As described in the MPLS TP OAM Requirements I-D, virtually all of the > OAM functions require a return path, and in the absence of a return=20 > path they are disabled. >=20 > As described in David Sinicrope's meeting minutes=20 > (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ > meeting-no > tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an=20 > MPLS TP network needs to be capable of getting IP packets from=20 > destination to source; neither the minutes nor I stipulate that a=20 > control plane needs to be used to instantiate this forwarding. >=20 > As an aside, the issue of return path for unidirectional LSPs could be > charaterized as the elephant in the room. In the MPLS TP OAM=20 > Framework I-D, unicast LSPs are only mentioned three times and return=20 > paths not at all. >=20 > Thanks, >=20 > John > > -----Original Message----- > > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Friday, April 17, 2009 1:59 AM > > To: Drake, John E; Alexander Vainshtein; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Associated bidirectional transport path=20 > > requirements > >=20 > > John, > >=20 > > I might have missed the agreement of MPLS-TP being capable of=20 > > sending replies to OAM requests sent on uni-directional LSPs. > >=20 > > This requirement does not belong to the first set of requirements=20 > > ITU-T is expecting to be met by October. > >=20 > > However, I think this in a potential interesting additional=20 > > requirement to be taken into account (at worst in a > subsequent phase). > >=20 > > I think that this requirement needs to be evaluated versus other=20 > > more important requirements (e.g. the possibility to work w/o IP=20 > > forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting the control or management=20 > > plane). > >=20 > > I am open to discuss it but not sure this is the right time because=20 > > I wish to avoid delaying the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E > > > Sent: Thursday, April 16, 2009 8:00 PM > > > To: Alexander Vainshtein; Maarten Vissers > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > requirements > > >=20 > > > At the meeting last fall at Juniper in Massachusetts, I > > think it was > > > agreed that an MPLS TP network needs to have a forwarding > > capability > > > for management, control, and OAM packets (e.g., sending > > replies to OAM > > > requests sent on uni-directional LSPs) even if it does not > > have an IP > > > forwarding data plane. > > >=20 > > > > -----Original Message----- > > > > From: Alexander Vainshtein > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > Sent: Thursday, April 16, 2009 9:57 AM > > > > To: Maarten Vissers > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Maarten, > > > > It seems that you've just (implicitly and, probably, > > > > inadvertently) stated the following: > > > >=20 > > > > MPLS-TP OAM will not ever support MIP loopback function > > (and fault > > > > localization which requires this function ) for > > unidirectional P2MP > > > > and P2P paths. > > > >=20 > > > > If this statement is correct, this (IMHO and FWIW) > raises a valid > > > > question: > > > >=20 > > > > Is MPLS-TP an appropriate solution for these > types of transport > > > > paths? > > > >=20 > > > > For the reference, IP/MPLS provides this kind of > > functionality today > > > > for (unidirectional - but it does not know any other > > type) P2P LSPs > > > > as described in RFC 4379. And its extension to P2MP LSPs seems=20 > > > > easy... > > > >=20 > > > > =20 > > > >=20 > > > > Regards, > > > >=20 > > > > Sasha > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] > > On Behalf > > > > Of Maarten Vissers [maarten.vissers@huawei.com] > > > > Sent: Thursday, April 16, 2009 3:24 PM > > > > To: 'Adrian Farrel' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Adrian, > > > >=20 > > > > >> > > > > >> The intermediate nodes (including MEPs, MIPs and > > > > other internal > > > > >> functions as appropriate) of a co-routed > > > > bidirectional transport > > > > >> path at each (sub-)layer MUST be aware of the pairing > > > > >> relationship of the forward and the backward > > > > directions of that > > > > >> transport path. > > > > >> > > > > > > > > > > There is no way this is a functional requirement. That > > > is, there is > > > > > *nothing* that can be observed from a black box point of > > > view that > > > > > results from adhering to this requirement. > > > >=20 > > > > Your understanding is not correct. It is very much > observable if > > > > this requirement is met from a black box point of view. > > > > The MIP functions can only perform the Loopback when there is a=20 > > > > co-routed bidirectional transport path. The MPLS-TP LBM packet=20 > > > > received at a MIP needs to be returned (as LBR > > > > packet) to the originating MEP function via the other > > direction of > > > > the co-routed bidirectional transport path. This other > direction > > > > would not be available in an associated bidirectional transport=20 > > > > path... and thus the loopback test > > > would fail. > > > >=20 > > > > Similarly, when we have to apply TCM MEPs to monitor a > > segment, then > > > > this is possible in a co-routed bidir transport path > but not in a > > > > associated bidir transport path. In the first case the TCM MEP=20 > > > > Source and Sink functions are co-located and can > exchange what is > > > > called "remote information" which is necessary for performance=20 > > > > monitoring. > > > > In the latter case the TCM MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network and TCM would not be able > > to provide > > > > performance monitoring. > > > >=20 > > > > > The entirety of the bracketted text "(including MEPs, > > > MIPs and other > > > > internal > > > > > functions as appropriate)" should be deleted. It does not > > > > add to "The > > > > > intermediate nodes." > > > >=20 > > > > Your understanding is not correct. This text must not be > > deleted at > > > > all. > > > >=20 > > > > > Actually, I am quite fed up about this persistent > > > insistence on the > > > > inclusion > > > > > of "Tandem Connection." The definition within the ITU-T of > > > > this term > > > > > is > > > > poorly > > > > > specified and comes from the monitoring of a path that is > > > > parallel (i.e. > > > > tandem) > > > > > to the data path being monitored. This definition of TC > > > > seems to be at > > > > variance, > > > > > and would be if the ACH was actually in band. > > > >=20 > > > > I don't understand where your interpretation of tandem > > connection is > > > > described in ITU-T recommendations. I.e. "from the > > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored."? > > > >=20 > > > > There is a "network connection" and this network > > connection is a set > > > > of interconnected "link connections" and "matrix > connections". A > > > > subset of those interconnected link connections and matrix=20 > > > > connections can be monitored and is then referred to as > a "tandem > > > > connection". There is no "path that is parallel to the > > data path".=20 > > > > There is only additional OAM inserted inside the data > path by the > > > > TCM MEP_So function and this OAM is extracted from the > > data path by > > > > the TCM MEP_Sk function. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: donderdag 16 april 2009 11:59 > > > > To: Alexander Vainshtein; benjamin.niven-jenkins@bt.com > > > > Cc: BUSI ITALO; mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot fully agree with your statement: > > > > > > > > > > > > > > > From the point of view of hardware, co-routed > > > bidirectional LSPs > > > > > are a special case of associated bidirectional LSPs. > > > > > > > > > > > > > > > This statement would be obviously correct, were it not for > > > > Requirement > > > > > 34 in the latest MPLS-TP requirements draft > > > >=20 > > > > OK. Got it. > > > >=20 > > > > But what is this doing in the data plane requirements section? > > > >=20 > > > > In fact, what is this requirement actually saying? > > > >=20 > > > > > > > > > > The intermediate nodes (including MEPs, MIPs and > > > other internal > > > > > functions as appropriate) of a co-routed > > > > bidirectional transport > > > > > path at each (sub-)layer MUST be aware of the pairing > > > > > relationship of the forward and the backward > > > > directions of that > > > > > transport path. > > > > > > > > >=20 > > > > There is no way this is a functional requirement. That > > is, there is > > > > *nothing* that can be observed from a black box point of > > view that > > > > results from adhering to this requirement. > > > >=20 > > > > Therefore it could be assumed that this requirement is met by=20 > > > > configuring some data plane database component through the=20 > > > > management plane. The database component is not used > for anything > > > > except to satisfy this requirement for "awareness". > > > >=20 > > > > Ben! Can we please try to rewrite this requirement in terms of=20 > > > > behavior? > > > >=20 > > > > > Please note that Requirement 34 is the ONLY item in the > > > > list that is > > > > > specific for co-routed bidirectional LSPs. (The pairing > > > > requirements > > > > > at end points for co-routed and associated bidirectional > > > paths are > > > > > exactly the same even if they appear in two different > > > items in the > > > > > requirements' list). > > > > > In other words, without Requirement 34 the notion of > co-routed > > > > > bidirectional paths would be void of any data plane content. > > > > > > > > > > The somewhat vague scope of this requirement ("other internal=20 > > > > > functions as appropriate") creates a suspicion that HW > > > > support of the > > > > > pairing awareness may be required in order to comply with it. > > > >=20 > > > > The entirety of the bracketted text "(including MEPs, > > MIPs and other > > > > internal functions as appropriate)" should be deleted. It > > does not > > > > add to "The intermediate nodes." > > > >=20 > > > > > The following text in the draft increases this suspicion: > > > > > > > > > > > > > > > Tandem Connection: A tandem connection is an > > arbitrary part of a > > > > > transport path that can be monitored (via OAM) > > > > independently from the > > > > > end-to-end monitoring (OAM). It may be a monitored > > segment or a > > > > > monitored concatenated segment of a transport path. =20 > > The tandem > > > > > connection may also include the forwarding engine(s) of > > > > the node(s) > > > > > at the edge(s) of the segment or concatenated segment. > > > > > > > > >=20 > > > > Actually, I am quite fed up about this persistent > > insistence on the > > > > inclusion of "Tandem Connection." The definition within > > the ITU-T of > > > > this term is poorly specified and comes from the > monitoring of a > > > > path that is parallel (i.e. tandem) to the data path being=20 > > > > monitored. This definition of TC seems to be at variance, > > and would > > > > be if the ACH was actually in band. > > > >=20 > > > > > Doesn't "forwarding engine" sound like hardware to you? > > > >=20 > > > > Yes, but so what? > > > >=20 > > > > > IMHO it is worth noting that neither the MPLS-TP > > > Requirements draft > > > > > nor the MPLS-TP OAM requirements one > > > > >=20 > > > >=20 > > >=20 > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen > > > > > ts-01.txt) contain any requirements dealing with tandem > > > connections. > > > > > > > > > > But tandem connections are discussed in the MPLS-TP OAM > > Framework > > > > > draft > > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr > > > > amework-00.txt > > > > ). > > > >=20 > > > > Right. > > > > Let's just get rid of an unnecessary term and bring all > the I-Ds > > > > into line. > > > >=20 > > > > > The bottom line, IMHO, is that some clarity regarding > > > co-routed vs. > > > > > associated > > > > > bidirectional paths is still required. One way to provide > > > > that could > > > > > be by explicitly limiting Requirement 34 to specific > > > functionality. > > > >=20 > > > > Agreed. > > > >=20 > > > > Adrian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > ________________________________________ > > > > From: Adrian Farrel [adrian@olddog.co.uk] > > > > Sent: Thursday, April 16, 2009 12:13 AM > > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > > > >=20 > > > > Hi Sasha, > > > >=20 > > > > Not really sure whether you are misrepresenting anyone, but... > > > >=20 > > > > > 1. My reading of one of Ben's messages is that associated=20 > > > > > bidirectional paths are the only types of paths that can be > > > > created in > > > > > the existing networks; "true" co-routed bidirectional paths > > > > will have > > > > > to wait until (if ever) new equipment becomes available. > > > >=20 > > > > This is clearly nonsense! > > > > From the point of view of hardware, co-routed > > bidirectional LSPs are > > > > a special case of associated bidirectional LSPs. > > > >=20 > > > > If you can set up two unidirectional LSPs (e.g. using the > > management > > > > plane) you can surely set up a co-routed > > > bidirectional LSP. > > > >=20 > > > > There are shipping solutions that achieve co-routed > bidirectional > > > > LSPs using the control plane. These either use the GMPLS > > (which is > > > > cleaner) or non-standard proprietary solutions (which is > > messy but > > > > functional). > > > >=20 > > > > But (of course) the management plane or control plane > > solutions have > > > > nothing to do with availability of equipment as they=20 > are software > > > > solutions. > > > >=20 > > > > > 2. My reading of one of Neil's messages is that the actual > > > > driver for > > > > > co-routed bidirectional paths may be experience with existing=20 > > > > > transport networks rather than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of the MPLS-TP requirements? > > > > Which is not to say it is a bad thing. > > > >=20 > > > > A large driver for MPLS-TP is to give the packet network > > the look, > > > > feel, and behavioral characteristics of a "legacy" > > > > transport network. > > > >=20 > > > > > Based on these observations, I'd guess (FWIW) that: > > > > > * associated bidirectional paths are, at least for the time > > > > > being, the most important type of bidirectional paths in > > > > > MPLS-TP > > > >=20 > > > > I think that is wrong both given my statement above, and > > given that > > > > other upgrades to existing MPLS solutions will be > needed to reach > > > > the full function level of MPLS-TP. > > > >=20 > > > > > * they had a good chance to remain the only type of > > bidirectional > > > > > paths in real deployments. > > > >=20 > > > > I don't see what that follows from. > > > >=20 > > > > Cheers, > > > > Adrian > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Boundary_(ID_Km8uPqFftZWJLuGdxtColA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Shahram, A transport equipment contains many devices = (chips) and a=20 lot of software. A single configuration command from a management system = may=20 result in the configuration of multiple devices and software modules in = the=20 transport equipment. The equipment manufacturer develops its product = such that=20 there is consistent configuration amoung these devices and software = modules.=20 That is why from outside the black box you can view this as a single=20 configuration. REgards, Maarten From: Shahram Davari = [mailto:davarish@yahoo.com]=20 Sent: maandag 27 april 2009 16:29 To: 'Maarten = Vissers';=20 andy.bd.reid@bt.com Cc: mpls-tp@ietf.org Subject: = RE:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Maarten, In=20 MPLS forwarding (and consequently in MPLS-TP forwarding), no binding is = kept at=20 adaptation sink function. In other words top label is popped and lower = label is=20 looked up independent of what the popped label was. But to generate AIS = you=20 require such binding to be kept in memory so that you can generate AIS = on the=20 client LSPs. So=20 I disagree with your analysis here. Because the client/server binding = for=20 forwarding purpose is kept at source point and not sink=20 point. I=20 agree with Andy, and the chips that I have seen that generate AIS, = generate it=20 using an independent client/server binding table that must be configured = which=20 may be miss-configured. Regards, Shahram From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of=20 Maarten Vissers Sent: April-27-09 9:43 AM To:=20 andy.bd.reid@bt.com Cc: mpls-tp@ietf.org Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path=20 requirements Andy, The=20 configuration of this set of label values in the adaptation function is=20 locked to the=20 configuration of the set of matrix connections/matrix forwarding=20 processes. It is locked to the creation of the "Connection/Flow = Point"=20 that interconnects the Matrix and Adaptation functions. I.e. a sinlge = action=20 which result in configuration of both a Connection function/Matrix and = an=20 Adaptation function/Link End. If there=20 would be any mistake in this configuration, you will notice this = immediately as=20 the CC frames will not reach the MEP Sink functions at the output ports = of the=20 connection (i.e. connection set up is not = succesful). Regards, Maarten From:=20 andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] Sent: = maandag 27=20 april 2009 14:59 To: maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, Snipped "AIS=20 generation is performed in the adaptation sink function for the set = of=20 active client signals; i.e. for the set of connection/flow points that = are=20 activated on the adaptation sink function (which are represented by the = set of=20 active labels/VIDs/...)." In your=20 words, the adaptation sink function contains a set of label values, one = for each=20 client connection. Different words, same thing. This is a list of label = values=20 which requires configuration if it is to be used for the injection of = AIS and=20 could be configured wrongly. It's the same thing even in your ITU-T=20 speak. Andy Andy=20 Reid Chief=20 Network Services Strategist BT=20 Innovate            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       =20 Office:=20 +44 (0)1277 322038 Mobile:=20 +44 (0)7917 025451 Fax :       = +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com British=20 Telecommunications plc Registered office: 81 Newgate Street London = EC1A=20 7AJ Registered in England no. 1800000 This=20 electronic message contains information from British Telecommunications = plc=20 which may be privileged or confidential. The information is intended to = be for=20 the use of the individual(s) or entity named above. If you are not the = intended=20 recipient be aware that any disclosure, copying, distribution or use of = the=20 contents of this information is prohibited. If you have received this = electronic=20 message in error, please notify us by telephone or email (to the numbers = or=20 address above) immediately. Activity=20 and use of the British Telecommunications plc email system is monitored = to=20 secure its effective operation and for other lawful business purposes.=20 Communications using this system will also be monitored and may be = recorded to=20 secure effective operation and for other lawful business=20 purposes. From:=20 Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: = 27 April=20 2009 13:28 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, I=20 have the impression that you do not have the correct understanding of = the SNC=20 protection switching fucntional models and the location and control of = AIS=20 insertion. Your understanding seems not aligned with the = specifications in our=20 equipment and protection swithcing recommendations. See=20 inline... From:=20 andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] Sent: = maandag 27=20 april 2009 12:50 To: = maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, It is=20 of course true that adding a boolean input to a logical system = increases the=20 number of possible input states. So adding an AIS boolean to CC=20 boolean creates four possible states not just the three = you=20 identify below. There are - good=20 CC, no AIS - CC=20 fault, AIS present - good=20 CC, AIS present - CC=20 fault, no AIS We=20 must ask what practical scenarios could generate each of = these input=20 states. Good=20 CC, no AIS One=20 hopes this is because this is because the service is working=20 properly. [mv]=20 I don't think that there is only "hope". This condition reflects = that=20 there is no disconnect. If=20 every frame/packet arrives correctly is not checked by the reception = of CC and=20 correct MEGID/MEPID. Frame/packet loss is checked by the frame/packet = loss=20 measurement that is embedded in the CCM frames, and can be activated.=20 CC=20 fault, AIS present One=20 hopes this is because the service is faulty and one hopes this is = because of a=20 fault in a server layer. In fact, the presence of the AIS could = be=20 misleading (see below). [mv]=20 With equipment that complies with the equipment standards this = condition=20 doesn't give you just "hope". It gives you "knowledge" that the = discontinutity=20 experienced in the connection is due to a server layer=20 fault. Good=20 CC, AIS present This=20 situation could arise because of a misconfiguration of the AIS = forwarding=20 label injection table. And there are a number of scenarios which make = this=20 quite likely when protection switching occurs. Depending on the exact = scope of=20 the forwarding labels, a protection switch may well require the = proactive=20 purging of entries from the AIS forwarding label injection table = following the=20 protection switch (this could equivalently been seen as the forwarding = function proactively dropping the AIS=20 packets). [mv]=20 I don't think that those scenarios are likely scenarios. Equipment = compliant=20 with ITU-T's equipment recommendations will not have those scenarios. = Only=20 equipment that does not comply with those equipment = recommendations could=20 have such scenarios. Just do not deploy such=20 equipment. [mv] The=20 AIS insertion in the functional models is performed in the Adaptation = Sink=20 functions. Those Adaptation Sink functions are connected to the = Connection=20 function in which the SNC Protection process is located. The AIS = insertion=20 in an Adaptation sink fucntion continues independent of the state = of the=20 protection switch process in the Connection function; i.e. the = selector=20 in the protection process will only receive frames/packets from either = the=20 working SNC, or the protection SNC (but never from both). CC=20 fault, no AIS As you=20 suggest, this could arise from a misconfiguration of a forwarding = function.=20 But it could equally arise from a misconfiguration of the AIS = forwarding label=20 injection table. In fact, the latter actually seems just = as likely and=20 particularly problematic for maintenance. Unlike normal = forwarding, any=20 mismatch between the forwarding configuration and the AIS forwarding = label=20 injection table will lie dormant and until a server fault arises. Then = this=20 generates a false and misunderstood fault condition with maintenance = looking=20 for the fault in the wrong place. [mv]=20 As indicated in the above comment, equipment compliant with the = equipment=20 and protection switching recommendation will not behave as you = suggest. Only=20 equipment not-compliant with our equipment/protection=20 switching recommendation may do this, but such equipment should = simply=20 not be deployed. [mv]=20 AIS generation is performed in the adaptation sink function for = the set=20 of active client signals; i.e. for the set of connection/flow points = that are=20 activated on the adaptation sink function (which are represented by = the set of=20 active labels/VIDs/...). There is no "AIS forwarding label injection = table" in=20 any of our equipment recommendations. AIS will be generated for each = client CI=20 output on the set of CPs/FPs on the adaptation sink function when aAIS = consequent action condition is true. The=20 first two states can be reliably diagnosed with CC alone. The = second two=20 arise from the introduction of the AIS/FDI. However, any possible = benefit that=20 might arise is completely masked by the fact that the AIS itself must = be=20 configured and there is no reason for this to be more reliable than = what it is=20 supposed to be monitoring. Indeed, there seems good reason to think = that it=20 will be less reliable. [mv]=20 You are turning things upside down... CC is present to detect = continuity and=20 connectivity problems introduced in the layer network's Connection = functions.=20 As such you can not diagnose the second state with CC alone. With CC = alone one=20 of your colleagues will be requested to initiate a number of Loopback = tests to=20 find out which connection function is misconfigured. This is the wrong = action=20 of course, as there is a server layer = fault. [mv]=20 You do not understand the AIS "configuration" aspect. AIS generation=20 configuration is on the node, not on each individual connection. = Networks that=20 deploy AIS have it active on all their NNIs. = There=20 is no avoiding that AIS in circuit switching is fundamentally = different from=20 AIS in packet switching. -=20 in circuit switching, you must fill the bit stream with something and = the=20 information injected requires no configuration=20 whatsoever. -=20 in packet switching, no packets is a perfectly valid condition and the = injection of AIS requires individual client connection specific = information to=20 be configured. [mv]=20 In packet transport networks with connectivity checking no packets is = not a=20 valid condition. [mv]=20 AIS/FDI insertion specified in e.g. T-MPLS OAM does not = require any=20 individual client connection specific information.=20 [mv]=20 ATM VP AIS and ATM VC AIS does not require any individual client (i.e. = VP, VC)=20 connection specific information. [mv]=20 ETH AIS does not require any individual client connection = identification=20 specification, but it requires reuse of the client MEG Level = information which=20 is also required for the ETH MIP functions on the interface=20 port. [mv]=20 I.e. AIS insertion does not require individual client connection = specific=20 information. Either no additional information at all is required, or=20 additional information is required that is shared with other=20 fucntions/processes in the interface. The=20 objective is not to replicate the data plane primitives of SONET/SDH, = but the=20 triggers to the operational systems so that the operational systems = and=20 processes are the same. [mv]=20 And that is exactly what we do with support of AIS in packet transport = networks (ATM, Ethernet, T-MPLS =3D>=20 MPLS-TP). The=20 simple CC replicates all the triggers to management systems made by = SONET/SDH=20 and gives maximum compatibility. Conversely, the inclusion of data = plane AIS=20 requires a whole new area of configuration and generates a whole new = set of=20 fault conditions which cannot be localised by SONET/SDH processes. So, = ironically, packet AIS is directly opposed to backwards compatibility = you=20 claim is the main drive. [mv]=20 I hope that you now understand that it is the opposite case is = that is=20 present. Simple CC does **not** replicates all triggers... AIS is = needed=20 in addition. Regards, Maarten Andy Andy=20 Reid Chief=20 Network Services Strategist BT=20 Innovate            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       =20 Office:=20 +44 (0)1277 322038 Mobile:=20 +44 (0)7917 025451 Fax :       = +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com British=20 Telecommunications plc Registered office: 81 Newgate Street London = EC1A=20 7AJ Registered in England no. 1800000 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be for=20 the use of the individual(s) or entity named above. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use=20 of the contents of this information is prohibited. If you have = received this=20 electronic message in error, please notify us by telephone or email = (to the=20 numbers or address above) immediately. Activity=20 and use of the British Telecommunications plc email system is = monitored to=20 secure its effective operation and for other lawful business purposes. = Communications using this system will also be monitored and may be = recorded to=20 secure effective operation and for other lawful business=20 purposes. From:=20 Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: = 24=20 April 2009 19:15 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, AIS/FDI=20 does give additional information. Let me = explain: The=20 need for AIS/FDI is a consequence of the deployment of loss of = continuity=20 checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of = such CCM=20 OAM is to be able to detect a misconfiguration or fault of a = connection=20 function (fabric) in the connection, which interrupts the forwarding = of=20 traffic in the connection. This is a fault condition that can only = be=20 discovered by the layer network in which the connection is = supported. It=20 requires that the organization responsible for the layer network = takes=20 action (i.e. locate the layer's connection function that = includes the=20 fault) to restore the connection. Unfortunately,=20 an interruption of one of the link connections of such = connection=20 (due to a fault in a server layer) will also interrupt the = forwarding of=20 traffic in the connection. As=20 such, loss of CC messages (LOC defect) does not provide sufficient=20 information to determine if the configuration in the layer's = connection=20 functions along the connection have to be checked and=20 corrected. AIS=20 has been introduced and is used to help differentiate between the = two fault=20 cases. 1)=20 if LOC and AIS are detected, then there is a server layer fault. = This server=20 layer fault is already reported by the server layer MEP detecting = this=20 fault. No action is required, so no alarm to=20 generate. 2)=20 if LOC is detected and there is no AIS, then there is a layer = network fault=20 (i.e. continuity fault). Fault localization must be started to = locate the=20 misconfigured or failed connection function. Once this=20 faulty connection function is located, the configuration fault = (or=20 hardware fault) can be corrected, after which the connection is = retored. The=20 interruption of the forwarding of traffic in the connection in both = fault=20 cases is however registered as part of performance monitoring. This=20 performance monitoring information is used to verify the performance = against=20 the SLA for the connection. Regards, Maarten From:=20 andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] Sent: = vrijdag 24=20 april 2009 12:34 To: = maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Maarten, These=20 points are irrelevant to the points I made. My point is that AIS/FDI = gives=20 no information above what is already known - it is only adds = complexity and=20 fault liability. Neither of your points change = this. Andy Andy=20 Reid Chief=20 Network Services Strategist BT=20 Innovate            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       =20 Office:=20 +44 (0)1277 322038 Mobile:=20 +44 (0)7917 025451 Fax :       = +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no. 1800000 This=20 electronic message contains information from British = Telecommunications plc=20 which may be privileged or confidential. The information is intended = to be=20 for the use of the individual(s) or entity named above. If you are = not the=20 intended recipient be aware that any disclosure, copying, = distribution or=20 use of the contents of this information is prohibited. If you have = received=20 this electronic message in error, please notify us by telephone or = email (to=20 the numbers or address above) immediately. Activity=20 and use of the British Telecommunications plc email system is = monitored to=20 secure its effective operation and for other lawful business = purposes.=20 Communications using this system will also be monitored and may be = recorded=20 to secure effective operation and for other lawful business=20 purposes. From:=20 Maarten Vissers [mailto:maarten.vissers@huawei.com] = Sent: 23=20 April 2009 20:42 To: Reid,ABD,Andy,CXM R Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated = bidirectional=20 transport path requirements Andy, >=20 The problem is *not* about a lack of alarm suppression in the data = plane -=20 that information is readily available. I=20 don't believe that this is a correct statement in a multi-operator = transport network, or in transport networks of one operator that = have more=20 then one administrative subdomain (each with its own network = management=20 system). A problem occuring in admin domain A will be unknown in = admin=20 domain B. The loss of continuaity alarms that are activated in = admin=20 domain B due to the fault in admin domain A will appear as primary = alarms,=20 suggesting connectivity problems in admin domain = B. >=20 The issue arises because the two sides of maintenance want = different=20 things. The fault fixing > guys=20 want to locate the fault and don't want any other information. The = service=20 maintenance > guys=20 want to know whether their customer service is=20 working. This=20 is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by = means of=20 the additional SSF alarm. The SSF alarm is for the service = guys=20 telling them that the service was interrupted due to a fault in a = server=20 layer. AIS suppresses the LOC alarm in those cases so that the = maintenance=20 guys don't get triggered and start looking for a fault that is = outside=20 their area. Regards, Maarten From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of=20 andy.bd.reid@bt.com Sent: woensdag 22 april 2009=20 12:14 To: liu.guoman@zte.com.cn;=20 neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org Subject:=20 Re: [mpls-tp] Associated bidirectional transport path=20 requirements Liu, Allow=20 me to jump in. You are bringing together two things which are = separate and=20 for which AIS/FDI is no help. Maintenance operations are concerned = with=20 two separate things. 1) =20 Identifying faults in equipment, line plant, and other systems (eg = misconfigurations) and fixing them (equipment=20 maintenance). 2) =20 Identifying the health of end to end connections, especially when = they are=20 directly supporting customer services (service=20 maintenance). The=20 problem is *not* about a lack of alarm suppression in the data = plane -=20 that information is readily available. If, at an end equipment, I = have a=20 good server/section layer and a loss of CC at the client layer, I = *know*=20 the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, = if you=20 think about, if the fault is in the end equipment, it is quite = likely that=20 the fault means it cannot report the traffic loss to the = management=20 system!) The=20 issue arises because the two sides of maintenance want different = things.=20 The fault fixing guys want to locate the fault and don't want any = other=20 information. The service maintenance guys want to know whether = their=20 customer service is working. This=20 arose in the early days of SONET/SDH, when the operations guys = demanded=20 that the equipment did *not* suppress the traffic alarm even when = AIS was=20 being received as the service guys want to know about the alarms. = The=20 normal practice is for the equipment to report the alarms = *including*=20 AIS and then a filter is applied in the management system to = suppress=20 alarms to the fault fixing guys. As I'm aware, there are many = different=20 techniques applied for the filtering algorithms, especially when = you=20 consider multiple concurrent faults in a network, however, the = existance=20 of AIS/FDI doesn't add anything to these that's not already known. = In=20 fact, I believe simple time-stamp correlation is one of the = most=20 powerful and widely used techniques. And if the equipment starts = messing=20 up the reporting of loss of CC because it waiting for/persistence=20 checking AIS/FDI, it could end up messing up simple = time-stamp=20 correlation! In=20 practice, it is often not quite a simple as this, as the service = guys like=20 to be able to 'localise' the fault. However, under most=20 circumstances, the filter has automatically done this.=20 So localisation you describe is only when the filter = hasn't=20 worked for some reason. But=20 the bottom line is, whatever operations process you want to=20 use, AIS/FDI doesn't add anything other than complexity and = fault=20 liability to the equipment. Remember AIS goes back to the TDM = world=20 where you *have to fill the bit stream with=20 something*. Andy Andy=20 Reid Chief=20 Network Services Strategist BT=20 Innovate            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       =20 Office:=20 +44 (0)1277 322038 Mobile:=20 +44 (0)7917 025451 Fax :       = +44 (0)1277 324015 Email: =20 andy.bd.reid@bt.com = British=20 Telecommunications plc Registered office: 81 Newgate Street = London EC1A=20 7AJ Registered in England no. 1800000 This=20 electronic message contains information from British = Telecommunications=20 plc which may be privileged or confidential. The information is = intended=20 to be for the use of the individual(s) or entity named above. If = you are=20 not the intended recipient be aware that any disclosure, copying,=20 distribution or use of the contents of this information is = prohibited. If=20 you have received this electronic message in error, please notify = us by=20 telephone or email (to the numbers or address above)=20 immediately. Activity=20 and use of the British Telecommunications plc email system is = monitored to=20 secure its effective operation and for other lawful business = purposes.=20 Communications using this system will also be monitored and may be = recorded to secure effective operation and for other lawful = business=20 purposes. From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf=20 Of liu.guoman@zte.com.cn Sent: 22 April 2009=20 09:15 To: Harrison,N,Neil,CXM R Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path requirements Neil: = thank you for = wasting=20 more time in describling the problems. but I think some of what = you said=20 is no relations with our problem.for me, maybe AIS/FDI functions = is no=20 sense in cl-ps ,eg. IP. but for CO-PS networks.if there is no = AIS/FDI=20 functions, when there is a defects in a given layer network, it = can=20 cause multiple alarm events to be raised. it is diffcult = for=20 operators to locate and diagnose the faults. though I = completely=20 agree you on adding new things and functions will bring = some=20 complexity . but if we have no functions, it is more complex and = difcult=20 for operators to maintence and administrator the network. so I = think=20 every new functions and things may have positive and negative = effects.=20 but we should consider it very much, don't delete some functions = at=20 random. best regards = liu <neil.2.harrison@bt.com>=20 2009-04-21=20 20:30 =CA=D5=BC=FE=C8=CB <liu.guoman@zte.com.cn>,=20 <dbrungard@att.com> = =B3=AD=CB=CD <mpls-tp@ietf.org>=20 =D6=F7=CC=E2 RE:=20 [mpls-tp] Associated bidirectional transport path=20 = requirements Liu,=20 If=20 MPLS-TP is going to be taken seriously as a transport network = (like=20 SDH/SONET) then the 2 key MUST HAVE requirements are = these.=20 1=20 Provide a transparent client/server = relationship...which=20 means: -=20 all client bits treated equally -=20 client bit ordering preserved -=20 no attempt to infer client symbol (ie sequence of = client=20 bits) meaning and no attempt to change client symbols = -=20 the traffic behaviour of client X must not impact = the=20 performance experienced by client Y A=20 key corollary of the above is that MPLS-TP must only support = proper=20 connections (ie single source constructs) = =20 2=20 Since MPLS-TP is a transport network it is not a = top-of-stack=20 network (ie it does not support directly external = message/file/stream=20 applications). MPLS-TP therefore does not require an E-NNI = specification. A key corollary of this is that MPLS-TP = will not=20 have any peer interworking relationship with any other network=20 mode/technology. Now=20 wrt OAM MPLS-TP is a co-ps mode network. You could argue = this=20 should have FDI/AIS....however, the merit of this is highly=20 questionable. When I and colleagues discussed whether = PBB-TE (also=20 a co-ps mode network) should have FDI/AIS we concluded that on = balance=20 it was not a good idea.....and note that initially I was in = favour of=20 having AIS, but my colleagues provided strong technical = arguments that=20 convinced me otherwise. AIS/FDI=20 is historically linked to the early PDH co-cs mode layer = networks that=20 used TTL logic. When this died it put out a +5V (all 1s) = signal by=20 default, ie it required no conscious effort to generate = it.....this is=20 key point. Further, in these networks there is a fairly=20 static/long-holding client server relationship. Clearly = this is=20 not true in the cl-ps mode and it's why IETF have never = specified AIS=20 for IP and its why IEEE had the good sense to throw-out AIS in = 802.1ag=20 for Ethernet (though ITU have unwisely IMO retained it in = Y.1731....but=20 I suspect any operator planning to use Ethernet equipment would = always=20 look to IEEE stds and not ITU ones). AIS/FDI=20 and the co-ps mode is debatable. As I noted above, on = balance we=20 considered not a good idea for PBB-TE OAM because it requires a=20 conscious effort to generate it (unlike the co-cs mode) so there = are=20 likely to be scaling problems and its one more thing to go = wrong.=20 You=20 should also have seen me make the point many times in the past = that the=20 always-on defect detection/handling OAM needs to be as = simple/sparse as=20 possible with as little config as possible because we need super = reliability......TCM goes completely against the grain here. = Also=20 note that the OAM required for each of the 3 network modes is = not the=20 same, despite what some claim. regards,=20 Neil From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf=20 Of liu.guoman@zte.com.cn Sent: 21 April 2009=20 02:59 To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport path=20 requirements Deborah:=20 maybe=20 what you said is right. but I can't completely agree your = opinions. IMO.=20 mpls-tp is regard as transport network like SDH/SONET. so it = should have=20 AIS/FDI fuctions as SDH/SONET. do you=20 think so. best=20 regards liu=20 "BRUNGARD,=20 DEBORAH A, ATTLABS" = <dbrungard@att.com>=20 =B7=A2=BC=FE=C8=CB:=20 mpls-tp-bounces@ietf.org 2009-04-20=20 23:47 =CA=D5=BC=FE=C8=CB "Maarten=20 Vissers" <maarten.vissers@huawei.com>,=20 <neil.2.harrison@bt.com> = =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re:=20 [mpls-tp] Associated bidirectional transport path=20 = requirements I=20 agree with Neil, it is very questionable the value of AIS/FDI in = a packet network- any mode. It can result in a DoS = attack by=20 an operator on themselves so even Y1731 recommends = not to=20 block data frames: "A MEP can decide whether it = blocks data=20 frames when it detects dAIS. The principle=20 requirement that influences this decision is that = data=20 frames ought to be forwarded as much as possible,=20 without the possibility of forwarding wrong data = frames=20 downstream." Table I.7-2 shows for AIS, not to=20 block. And as Y1731 states, AIS can only be used = under=20 very constrained architectures - if required for = MPLS-TP, it=20 needs to have the same guidance as in Y1731, i.e.=20 point-to-point and server/client one-to-one: "for a=20 point-to-point ETH connection, a MEP has only a single peer=20 MEP. Therefore, there is no ambiguity = regarding=20 the peer MEP for which it should suppress alarms = when it=20 receives the ETH-AIS information." So = should=20 only be within one domain - then no=20 need. Deborah -----Original=20 Message----- From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Maarten=20 Vissers Sent: Monday, April 20, 2009 10:05=20 AM To: neil.2.harrison@bt.com Cc:=20 mpls-tp@ietf.org Subject: Re: [mpls-tp] Associated=20 bidirectional transport=20 = path requirements Neil, > = but AIS/FDI in the cl mode?...do me a = favour! Ethernet=20 AIS is indeed a requirement and a necessity. And you will=20 not be able to understand that as long = as you=20 refuse to accept that "cl-mode" is = a forwarding=20 mode within a **transport entity**. G.800 amendment 1=20 has finally reintroduced this transport = entity=20 into G.800. Besides that, it also introduced the=20 **differentiated connection**: [G.800 am1] "A=20 differentiated connection is a transport entity=20 that transfers information belonging to multiple=20 communications between ports across a subnetwork. = <..>=20 In a differentiated connection=20 message contents are interpreted to = identify=20 (sets of) communications which=20 receive different treatment. The = sets of=20 communications may be distinguished by = the forwarding=20 identifier or other layer information. Order is=20 not necessarily preserved between = messages=20 belonging to sets of communications = receiving different=20 treatment. Sets of communications may be identified=20 for purposes such as traffic = conditioning or=20 preserving communication message = order." Ethernet=20 VLANs are in terms of G.800 "differentiated=20 connections". Ethernet AIS provides AIS = within=20 the scope of such "differentiated=20 connection". If you apply this to my = proposed=20 PTN layer stack, then the EVC=20 layer topology will consists of EVC = links=20 supported by MPLS-TP, Ethernet, PBB-TE=20 and P-OTN VP trails inside metro and = core=20 domains interconnecting EVC = matrices. When one=20 of those EVC links is interrupted, e.g. in the core between = metro=20 1 and metro 4 (see attached slide), then = the EVC=20 differentiated connection that = is present on=20 this link will be interrupted. At the EVC switch/bridge=20 node in metro 4 this interruption is = noticed and=20 EVC-AIS is inserted in the downstream direction to = suppress=20 the EVC-LOC alarms at EVC endpoints=20 D4 and D5. The EVC-AIS = (i.e.=20 Ethernet AIS) frame has a reserved multicast = address, which=20 guarantees that the AIS is broadcast to the endpoints of the=20 EVC. I believe that it is time for you to adapt = your=20 view on co and cl modes and relate it to = the=20 forwarding mode **INSIDE** a transport entity. = What we=20 know as the internet is essentially an "IP=20 differentiated connection" with a billion or more=20 ports. What we know as an IP VPN is essentially an = "IP=20 differentiated connection" with e.g. n = ports (n=20 in the range of e.g. 2 to 1000). What we know as an = Ethernet=20 VLAN is essentially an=20 "Ethernet differentiated connection" = with n=20 ports (n in the range of e.g. 2 to 1000). What we = know as a=20 p2p MPLS E-LSP is essentially an "MPLS=20 differentiated connection" with 2 = ports. What we=20 know as a p2p SDH VC-n is a "SDH VC-n connection" with 2=20 ports. Transport network OAM applies to = transport=20 entities, which are (in terms of G.800 = am1)=20 connections and differentiated=20 = connections. Regards, Maarten -----Original=20 Message----- From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com] Sent: vrijdag 17 = april 2009=20 22:00 To: John.E.Drake2@boeing.com;=20 = Italo.Busi@alcatel-lucent.it; Alexander.Vainshtein@ecitele.co= m;=20 maarten.vissers@huawei.com Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] Associated=20 bidirectional transport=20 path requirements John, Thanks = this is=20 a great platform to explain why OAM for the=20 3 network modes needs to be different. = I=20 am getting a wee bit tired of = folks trying to=20 make all 3 network modes look alike (and then, even worse,=20 interwork them as as peers...esp when = not not=20 top-of-stack networks...I mean how silly can we = get?).=20 I am even more frustrated by the fact those = peddling=20 this FUD only ever seem to consider OAM=20 and forget all other DP/CP/MP components = (esp=20 top-of-stack message/file/stream application = adaptations).=20 How wrong can this get! In the co modes a = *connection* is a very specific and=20 *constraining* construct.....I am assuming here we = respect=20 the rules of a connection (ie single = source)=20 though some folks don't even bother to respect this,=20 and this is despite the fact that we all = know=20 what problems multiple-source constructs can cause = (from=20 LDP/PHP....ergo MPLS-TP). When we have a = connection this=20 restricts *all* DP (ie traffic and = OAM) to stay=20 within the bounds of the connection. Which is fine=20 under defect-free conditions, but if we = have=20 leaking traffic then the constraining=20 nature of the connection construct is = broken.=20 In a nutshell what this means = is that OAM=20 that is of a request/response nature cannot be trusted in co=20 mode networks under misconnectivity = defects.....indeed, why=20 should a leaking DP have a symmetric = go/return=20 defect behaviour?....very likely it=20 won't. So whilst request/response OAM is = right=20 for the cl mode it is not right = for the co mode=20 under misconnectivity defect conditions. More = generally=20 the 3 modes are different and not just in=20 OAM requirements....but AIS/FDI in the cl mode?...do = me a=20 favour!...at least IEEE had the good sense to bin = this for=20 Ethernet even though it = remains in Y.1731.=20 And which is why I often trot-out the rather silly (to = have=20 to say this) observation that if IP (cl = mode)=20 could do it all then why have IETF found = it=20 necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).=20 The answer lies in the physics...and G.800 = attempts to=20 explain that physics....G.805 does = not. So,=20 the 3 modes are different...please accept/rejoice in this fact=20 as they all offer something = different/important.=20 But do not be hoodwinked = by those who=20 peddle a story that that tries to make the OAM of the 3 modes=20 the same. regards, Neil=20 > -----Original = Message----- > From:=20 mpls-tp-bounces@ietf.org >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > Sent: 17 April 2009 20:02 > = To: BUSI=20 ITALO; Alexander Vainshtein; Maarten Vissers > = Cc:=20 mpls-tp@ietf.org > Subject: Re: [mpls-tp] = Associated=20 bidirectional transport path >=20 requirements > > = Italo, >=20 > As described in the MPLS TP OAM Requirements = I-D,=20 virtually all of the > OAM functions require = a return=20 path, and in the absence of a return > path they = are=20 disabled. > > As described in = David=20 Sinicrope's meeting minutes >=20 = (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/ >=20 meeting-no > = tes/20081015.mpls-interop-dt-notes.zip), if=20 IP addressing is used, an > MPLS TP network = needs to be=20 capable of getting IP packets from > destination = to=20 source; neither the minutes nor I stipulate that a = >=20 control plane needs to be used to instantiate this=20 forwarding. > > As an aside, the = issue of=20 return path for unidirectional LSPs could = be >=20 charaterized as the elephant in the room. In the MPLS TP = OAM=20 > Framework I-D, unicast LSPs are only mentioned = three=20 times and return > paths not at = all. >=20 > Thanks, > >=20 John > > -----Original = Message----- >=20 > From: BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > > = Sent:=20 Friday, April 17, 2009 1:59 AM > > To: Drake, = John E;=20 Alexander Vainshtein; Maarten Vissers > > Cc:=20 mpls-tp@ietf.org > > Subject: RE: [mpls-tp] = Associated=20 bidirectional transport path > >=20 requirements > > > >=20 John, > > > > I might have = missed=20 the agreement of MPLS-TP being capable of > > = sending=20 replies to OAM requests sent on uni-directional = LSPs. >=20 > > > This requirement does not belong to = the=20 first set of requirements > > ITU-T is = expecting to=20 be met by October. > > > > = However,=20 I think this in a potential interesting additional = >=20 > requirement to be taken into account (at worst in=20 a > subsequent phase). > >=20 > > I think that this requirement needs to be = evaluated versus other > > more important=20 requirements (e.g. the possibility to work w/o IP = > >=20 forwarding and the need for OAM to continue to monitor the data=20 > > plane also in case of failures affecting = the=20 control or management > > = plane). >=20 > > > I am open to discuss it but not sure = this is=20 the right time because > > I wish to avoid = delaying=20 the first phase of the design solution. > >=20 > > Thanks, Italo > >=20 > > > -----Original = Message----- >=20 > > From: mpls-tp-bounces@ietf.org > > = >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John=20 E > > > Sent: Thursday, April 16, 2009 8:00 = PM > > > To: Alexander Vainshtein; Maarten=20 Vissers > > > Cc: = mpls-tp@ietf.org >=20 > > Subject: Re: [mpls-tp] Associated bidirectional = transport path=20 > > > requirements > > = >=20 > > > At the meeting last fall at Juniper = in=20 Massachusetts, I > > think it = was >=20 > > agreed that an MPLS TP network needs to have a=20 forwarding > > capability > = > >=20 for management, control, and OAM packets (e.g., = sending >=20 > replies to OAM > > > requests sent on=20 uni-directional LSPs) even if it does not > > = have an=20 IP > > > forwarding data = plane. >=20 > > > > > > -----Original=20 Message----- > > > > From: Alexander=20 Vainshtein > > >=20 [mailto:Alexander.Vainshtein@ecitele.com] > > = >=20 > Sent: Thursday, April 16, 2009 9:57 AM > = > >=20 > To: Maarten Vissers > > > > Cc:=20 mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > > = > >=20 requirements > > > > > = > >=20 > Maarten, > > > > It seems that = you've just=20 (implicitly and, probably, > > > >=20 inadvertently) stated the following: > > > = >=20 > > > > = =20 MPLS-TP OAM will not ever support MIP = loopback function > > (and = fault > >=20 > > localization which requires this function )=20 for > > unidirectional P2MP > = > >=20 > and P2P paths. > > > > = >=20 > > > If this statement is correct, this (IMHO and=20 FWIW) > raises a valid > > > = >=20 question: > > > > > > = >=20 > = Is=20 MPLS-TP an appropriate solution for these > types = of=20 transport > > > > = paths? > >=20 > > > > > > For the reference, = IP/MPLS=20 provides this kind of > > functionality=20 today > > > > for (unidirectional - but = it does=20 not know any other > > type) P2P = LSPs >=20 > > > as described in RFC 4379. And its extension to = P2MP LSPs=20 seems > > > > easy... > = >=20 > > > > > > = > >=20 > > > > > > = Regards, >=20 > > > > > > > =20 Sasha > > > > > = > >=20 > > > > > > > = > >=20 ________________________________________ > > = > >=20 From: mpls-tp-bounces@ietf.org=20 [mpls-tp-bounces@ietf.org] > > On=20 Behalf > > > > Of Maarten Vissers=20 [maarten.vissers@huawei.com] > > > > = Sent:=20 Thursday, April 16, 2009 3:24 PM > > > > = To:=20 'Adrian Farrel' > > > > Cc:=20 mpls-tp@ietf.org > > > > Subject: Re: = [mpls-tp]=20 Associated bidirectional transport path > > = > >=20 requirements > > > > > = > >=20 > Adrian, > > > > > = > >=20 > >> <quote> > > > > = >>=20 The intermediate nodes (including MEPs, MIPs = and > > > > other = internal > >=20 > > >> functions as = appropriate) of a=20 co-routed > > > > bidirectional=20 transport > > > > >> = =20 path at each (sub-)layer MUST be aware of the = pairing >=20 > > > >> relationship of the = forward=20 and the backward > > > > directions of=20 that > > > > >> = =20 transport path. > > > > >> <end = quote> > > > > > > = >=20 > > > There is no way this is a functional requirement. = That > > > is, there is > = > >=20 > > *nothing* that can be observed from a black box point=20 of > > > view that > > = > >=20 > results from adhering to this requirement. > = >=20 > > > > > > Your understanding is = not=20 correct. It is very much > observable = if >=20 > > > this requirement is met from a black box point of = view. > > > > The MIP functions can only = perform=20 the Loopback when there is a > > > > = co-routed=20 bidirectional transport path. The MPLS-TP LBM packet = >=20 > > > received at a MIP needs to be returned (as=20 LBR > > > > packet) to the originating = MEP=20 function via the other > > direction=20 of > > > > the co-routed bidirectional = transport=20 path. This other > direction > = > >=20 > would not be available in an associated bidirectional = transport=20 > > > > path... and thus the loopback=20 test > > > would fail. > = > >=20 > > > > > Similarly, when we have to = apply=20 TCM MEPs to monitor a > > segment,=20 then > > > > this is possible in a = co-routed=20 bidir transport path > but not in = a > >=20 > > associated bidir transport path. In the first case the = TCM MEP=20 > > > > Source and Sink functions are=20 co-located and can > exchange what = is >=20 > > > called "remote information" which is necessary = for=20 performance > > > >=20 monitoring. > > > > In the latter case = the TCM=20 MEP Source and Sink functions > > are in e.g.=20 > > > > different nodes in the network = and TCM=20 would not be able > > to = provide > >=20 > > performance monitoring. > > > = >=20 > > > > > The entirety of the = bracketted=20 text "(including MEPs, > > > MIPs and=20 other > > > > internal > = >=20 > > > functions as appropriate)" should be deleted. It = does=20 not > > > > add to "The > = >=20 > > > intermediate nodes." > > > = >=20 > > > > Your understanding is not = correct. This=20 text must not be > > deleted = at > >=20 > > all. > > > > > = >=20 > > > Actually, I am quite fed up about this=20 persistent > > > insistence on = the >=20 > > > inclusion > > > > > of = "Tandem=20 Connection." The definition within the ITU-T of > = >=20 > > this term > > > > >=20 is > > > > poorly > > = >=20 > > specified and comes from the monitoring of a path that = is > > > > parallel = (i.e. > >=20 > > tandem) > > > > > to the = data path=20 being monitored. This definition of TC > > = > >=20 seems to be at > > > >=20 variance, > > > > > and would be if = the ACH=20 was actually in band. > > > > = >=20 > > > I don't understand where your interpretation of=20 tandem > > connection is > > = >=20 > described in ITU-T recommendations. I.e. "from = the >=20 > monitoring of a > > > > path that = is=20 parallel (i.e. tandem) to the data path being > = >=20 > > monitored."? > > > > = >=20 > > > There is a "network connection" and this=20 network > > connection is a = set > >=20 > > of interconnected "link connections" and=20 "matrix > connections". A > > = > >=20 subset of those interconnected link connections and matrix=20 > > > > connections can be monitored = and is=20 then referred to as > a "tandem > = >=20 > > connection". There is no "path that is parallel to=20 the > > data path". > > = > >=20 There is only additional OAM inserted inside the = data >=20 path by the > > > > TCM MEP_So function = and this=20 OAM is extracted from the > > data path=20 by > > > > the TCM MEP_Sk=20 function. > > > > > > = >=20 > Regards, > > > > = Maarten >=20 > > > > > > > = > >=20 > > -----Original Message----- > > > = >=20 From: mpls-tp-bounces@ietf.org > > > >=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian=20 Farrel > > > > Sent: donderdag 16 april = 2009=20 11:59 > > > > To: Alexander Vainshtein;=20 benjamin.niven-jenkins@bt.com > > > > = Cc: BUSI=20 ITALO; mpls-tp@ietf.org > > > > Subject: = Re:=20 [mpls-tp] Associated bidirectional transport path = > >=20 > > requirements > > > > = >=20 > > > Hi Sasha, > > > >=20 > > > > > Unfortunately I cannot = fully agree=20 with your statement: > > > >=20 > > > > > > = <quote> >=20 > > > > From the point of view of = hardware,=20 co-routed > > > bidirectional = LSPs >=20 > > > > are a special case of = associated=20 bidirectional LSPs. > > > > > <end = quote> > > > > > > = >=20 > > > This statement would be obviously correct, were = it not=20 for > > > > Requirement > = >=20 > > > 34 in the latest MPLS-TP requirements=20 draft > > > > > > = > >=20 OK. Got it. > > > > > = > >=20 > But what is this doing in the data plane requirements=20 section? > > > > > > = >=20 > In fact, what is this requirement actually = saying? >=20 > > > > > > > >=20 <quote> > > > > > = The intermediate nodes (including MEPs, MIPs = and >=20 > > other internal > > > > > = =20 functions as appropriate) of a = co-routed >=20 > > > bidirectional transport > > = > >=20 > path at each (sub-)layer MUST be aware = of the=20 pairing > > > > > = =20 relationship of the forward and the backward > = > >=20 > directions of that > > > > > = =20 transport path. > > > > = >=20 <end quote> > > > > = > >=20 > > There is no way this is a functional requirement.=20 That > > is, there is > > = > >=20 *nothing* that can be observed from a black box point=20 of > > view that > > > = >=20 results from adhering to this requirement. > > = >=20 > > > > > Therefore it could be = assumed that=20 this requirement is met by > > > > = configuring=20 some data plane database component through the > = >=20 > > management plane. The database component is not=20 used > for anything > > > = >=20 except to satisfy this requirement for = "awareness". >=20 > > > > > > > Ben! Can we = please try=20 to rewrite this requirement in terms of > > = > >=20 behavior? > > > > > > = >=20 > > Please note that Requirement 34 is the ONLY item in=20 the > > > > list that = is > >=20 > > > specific for co-routed bidirectional LSPs. (The=20 pairing > > > > = requirements >=20 > > > > at end points for co-routed and associated=20 bidirectional > > > paths = are > >=20 > > > exactly the same even if they appear in two=20 different > > > items in = the > >=20 > > > requirements' list). > > > = > >=20 In other words, without Requirement 34 the notion = of >=20 co-routed > > > > > bidirectional = paths would=20 be void of any data plane content. > > > = >=20 > > > > > > The somewhat vague = scope of=20 this requirement ("other internal > > > = > >=20 functions as appropriate") creates a suspicion that = HW >=20 > > > support of the > > > > = >=20 pairing awareness may be required in order to comply with=20 it. > > > > > > > = > The=20 entirety of the bracketted text "(including = MEPs, > >=20 MIPs and other > > > > internal = functions as=20 appropriate)" should be deleted. It > > does=20 not > > > > add to "The intermediate=20 nodes." > > > > > > = > >=20 > The following text in the draft increases this=20 suspicion: > > > > > > = >=20 > > > <quote> > > > > = > =20 Tandem Connection: A tandem connection is an > = >=20 arbitrary part of a > > > > > =20 transport path that can be monitored (via OAM) > = >=20 > > independently from the > > > > = >=20 end-to-end monitoring (OAM). It may be a=20 monitored > > segment or a > = > >=20 > > monitored concatenated segment of a transport = path.=20 > > The tandem > > = > >=20 > connection may also include the forwarding engine(s) = of > > > > the node(s) > = >=20 > > > at the edge(s) of the segment or = concatenated=20 segment. > > > > > <end=20 quote> > > > > > > = >=20 > Actually, I am quite fed up about this = persistent >=20 > insistence on the > > > > inclusion = of=20 "Tandem Connection." The definition within > > = the=20 ITU-T of > > > > this term is poorly = specified=20 and comes from the > monitoring of = a >=20 > > > path that is parallel (i.e. tandem) to the data = path=20 being > > > > monitored. This = definition of TC=20 seems to be at variance, > > and=20 would > > > > be if the ACH was actually = in=20 band. > > > > > > = > >=20 > Doesn't "forwarding engine" sound like hardware to=20 you? > > > > > > > = >=20 Yes, but so what? > > > > = > >=20 > > > IMHO it is worth noting that neither the=20 MPLS-TP > > > Requirements = draft >=20 > > > > nor the MPLS-TP OAM requirements=20 one > > > > > > > = >=20 > > > > > >=20 >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen >=20 > > > > ts-01.txt) contain any requirements dealing = with=20 tandem > > > connections. > = >=20 > > > > > > > > But tandem=20 connections are discussed in the MPLS-TP OAM > = >=20 Framework > > > > > = draft >=20 > > >=20 = (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr >=20 > > > amework-00.txt > > > >=20 ). > > > > > > > = >=20 Right. > > > > Let's just get rid of an=20 unnecessary term and bring all > the=20 I-Ds > > > > into line. > = >=20 > > > > > > > The bottom line, = IMHO,=20 is that some clarity regarding > > > = co-routed=20 vs. > > > > > = associated >=20 > > > > bidirectional paths is still required. One = way to=20 provide > > > > that = could > >=20 > > > be by explicitly limiting Requirement 34 to=20 specific > > > = functionality. > >=20 > > > > > > = Agreed. > >=20 > > > > > > = Adrian > >=20 > > > > > > > = > >=20 > > > > > > > = > >=20 ________________________________________ > > = > >=20 From: Adrian Farrel [adrian@olddog.co.uk] > > = >=20 > Sent: Thursday, April 16, 2009 12:13 AM > = > >=20 > To: Alexander Vainshtein; Lou Berger; BUSI = ITALO >=20 > > > Cc: mpls-tp@ietf.org > > > = >=20 Subject: Re: [mpls-tp] Associated bidirectional transport path=20 > > > > requirements > = > >=20 > > > > > Hi Sasha, > = >=20 > > > > > > Not really sure = whether you=20 are misrepresenting anyone, but... > > > = >=20 > > > > > 1. My reading of one = of=20 Ben's messages is that associated > > = > >=20 > bidirectional paths are the only types of paths that can=20 be > > > > created in > = > >=20 > > the existing networks; "true" co-routed bidirectional=20 paths > > > > will have > = >=20 > > > to wait until (if ever) new equipment becomes=20 available. > > > > > = > >=20 > This is clearly nonsense! > > > > = >From the=20 point of view of hardware, co-routed > > = bidirectional=20 LSPs are > > > > a special case of = associated=20 bidirectional LSPs. > > > > = >=20 > > > If you can set up two unidirectional LSPs (e.g. = using=20 the > > management > > > = >=20 plane) you can surely set up a co-routed > > = >=20 bidirectional LSP. > > > > = >=20 > > > There are shipping solutions that achieve=20 co-routed > bidirectional > > = > >=20 LSPs using the control plane. These either use the=20 GMPLS > > (which is > > > = >=20 cleaner) or non-standard proprietary solutions (which=20 is > > messy but > > > = >=20 functional). > > > > > = > >=20 > But (of course) the management plane or control=20 plane > > solutions have > > = >=20 > nothing to do with availability of equipment as they=20 > are software > > > >=20 solutions. > > > > > = > >=20 > > 2. My reading of one of Neil's messages is that the=20 actual > > > > driver = for > >=20 > > > co-routed bidirectional paths may be experience = with=20 existing > > > > > transport = networks rather=20 than any specific benefit. > > > >=20 > > > > Isn't that the case with 75% of = the=20 MPLS-TP requirements? > > > > Which is = not to=20 say it is a bad thing. > > > > = >=20 > > > A large driver for MPLS-TP is to give the packet=20 network > > the look, > > = > >=20 feel, and behavioral characteristics of a = "legacy" > >=20 > > transport network. > > > >=20 > > > > > Based on these = observations, I'd=20 guess (FWIW) that: > > > > > * = associated=20 bidirectional paths are, at least for the time > = >=20 > > > being, the most important type of=20 bidirectional paths in > > > > > = =20 MPLS-TP > > > > > = >=20 > > I think that is wrong both given my statement above,=20 and > > given that > > > = >=20 other upgrades to existing MPLS solutions will = be >=20 needed to reach > > > > the full = function level=20 of MPLS-TP. > > > > > = > >=20 > > * they had a good chance to remain the only type=20 of > > bidirectional > > = > >=20 > paths in real deployments. > = > >=20 > > > > > I don't see what that = follows=20 from. > > > > > > = > >=20 Cheers, > > > > Adrian > = >=20 > > > > > >=20 _______________________________________________ > = >=20 > > mpls-tp mailing list > > > >=20 mpls-tp@ietf.org > > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > = > >=20 > > > > >=20 _______________________________________________ > = >=20 > > mpls-tp mailing list > > > >=20 mpls-tp@ietf.org > > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > = > >=20 > > > > > > > = >=20 _______________________________________________ > = >=20 > mpls-tp mailing list > > >=20 mpls-tp@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > = > >=20 > > >=20 _______________________________________________ > = mpls-tp=20 mailing list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 = _______________________________________________ = mpls-tp=20 mailing=20 = list mpls-tp@ietf.org https://www.ietf.org/mailma= n/listinfo/mpls-tp ----------------------------------= ---------------------- ZTE=20 Information Security Notice: The information contained in this = mail is=20 solely property of the sender's organization. This mail = communication is=20 confidential. Recipients named above are obligated to maintain = secrecy=20 and are not permitted to disclose the contents of this = communication to=20 others. This email and any files transmitted with it = are=20 confidential and intended solely for the use of the individual = or entity=20 to whom they are addressed. If you have received this email in = error=20 please notify the originator of the message. Any views expressed = in this=20 message are those of the individual sender. This = message has=20 been scanned for viruses and Spam by ZTE Anti-Spam = system. -------------------------------= ------------------------- ZTE Information = Security Notice: The information contained in&nb= sp;this mail is solely property of the = ;sender's organization. This mail communication = is confidential. Recipients named above are = ;obligated to maintain secrecy and are not&= nbsp;permitted to disclose the contents of = this communication to others. This&nb= sp;email and any files transmitted with it&= nbsp;are confidential and intended solely for&nb= sp;the use of the individual or entity = ;to whom they are addressed. If you ha= ve received this email in error please = ;notify the originator of the message. Any&= nbsp;views expressed in this message are th= ose of the individual sender. Th= is message has been scanned for viruses&nbs= p;and Spam by ZTE Anti-Spam system. --Boundary_(ID_Km8uPqFftZWJLuGdxtColA)-- From maarten.vissers@huawei.com Tue Apr 28 09:07:58 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD153A6D94 for ; Tue, 28 Apr 2009 09:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg2mNKa-qE+R for ; Tue, 28 Apr 2009 09:07:51 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 888653A6BEA for ; Tue, 28 Apr 2009 09:07:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT004EKJJ1K8@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 00:09:01 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00H5LJJ10B@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 00:09:01 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT0050AJINWJ@szxml02-in.huawei.com>; Wed, 29 Apr 2009 00:09:01 +0800 (CST) Date: Tue, 28 Apr 2009 18:08:50 +0200 From: Maarten Vissers In-reply-to: <04b401c9c81a$0383bd40$0a8b37c0$@com> To: davarish@yahoo.com Message-id: <002b01c9c81b$a31bf380$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAjs+w Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:07:58 -0000 Shahram, When you apply protection you will not change the binding between client and server layers when you switch from e.g. working to protection. All client/server bindings are still present. What you changed is the connectivity in the connection function. You find this illustrated in e.g. G.806. When the working connection would fail, then AIS would be inserted e.g. at the end of the server layer connection that carries the working connection. AIS is inserted independent of the state of the next protection switch selector process. If the selector is not moved to the protection connection, then AIS inserted into the working connection is forwarded through the protection switch selector to the far end of the protected connection. If the selector is moved to read from the protection connection, then AIS is still inserted intto the working connection, but the selector is not reading from working, so AIS will drop dead at the input of the selector. Regards, Maarten -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: dinsdag 28 april 2009 17:57 To: 'Igor Bryskin'; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Your assumption is that there is a control plane that sets up the binding between client and server layer and that such binding will be removed via the control plane when a reroute happens. I think this assumption is not always true. For example in a linear 1:1 or 1+1 protection, there is no signalling to withdraw the binding at intermediate nodes. In 1:1 there is APS, but that is end-to-end and is sent on the backup path not working path. -Shahram -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: April-28-09 11:27 AM To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side of the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that network C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer. -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connection less, whereas some other server trail(s) will learn that they serve from now on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation. There is no difference with what we do today in SDH and OTN. A client/server relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generation is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > ================================================================ > > http://www.van-helvoort.eu/ > > ================================================================ > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From IBryskin@advaoptical.com Tue Apr 28 09:19:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD89A3A68EA for ; Tue, 28 Apr 2009 09:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjqHyFQ+4BBz for ; Tue, 28 Apr 2009 09:19:10 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 6916A3A68D2 for ; Tue, 28 Apr 2009 09:19:09 -0700 (PDT) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n3SGK73D019749 for ; Tue, 28 Apr 2009 18:20:08 +0200 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 28 Apr 2009 18:20:21 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 18:20:06 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 28 Apr 2009 12:20:05 -0400 From: Igor Bryskin To: "davarish@yahoo.com" , "'Maarten Vissers'" , "neil.2.harrison@bt.com" , "nurit.sprecher@nsn.com" , "Italo.Busi@alcatel-lucent.it" , "hhelvoort@chello.nl" , "adrian@olddog.co.uk" Date: Tue, 28 Apr 2009 12:20:03 -0400 Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrw Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B34583C@atl-srv-exgen.atl.advaoptical.com> References: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3457FB@atl-srv-exgen.atl.advaoptical.com> <049e01c9c814$0cbd1830$26374890$@com> <052C67B4ED558D41BBDEA7CA9FC6DCDC145B345810@atl-srv-exgen.atl.advaoptical.com> <04b401c9c81a$0383bd40$0a8b37c0$@com> In-Reply-To: <04b401c9c81a$0383bd40$0a8b37c0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:19:11 -0000 Shahram, I was addressing Neil's comments about the dynamic re-routing, which is dif= ferent from protection switchover onto pre-provisioned protection connectio= n. True, in the latter case the server layer wouldn't notice that and will = keep notifying the client that the trail is broken. But this does not chang= e anything. The big 2 questions in my mind are: a) Is the OAM of a given layer is (i) self-sufficient and (ii) scalable eno= ugh, so that operator can rely on it completely and independently from what= is happening in the lower layers? b) Is it beneficial if a server trail notifies its clients about a detected= problem to suppress the OAM traffic and possibly unnecessary switchovers u= ntil the server trail corrects itself? Cheers, Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com]=20 Sent: Tuesday, April 28, 2009 11:57 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher= @nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.= co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Igor, Your assumption is that there is a control plane that sets up the binding between client and server layer and that such binding will be removed via the control plane when a reroute happens. I think this assumption is not always true. For example in a linear 1:1 or 1+1 protection, there is no signalling to withdraw the binding at intermediate nodes. In 1:1 there is APS, but that is end-to-end and is sent on the backup path not working path= . -Shahram =20 -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: April-28-09 11:27 AM To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side o= f the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com]=20 Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that networ= k C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer.=20 -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically)= . As soon as the connection is re-routed, this relationship is broken (becaus= e this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connectio= n less, whereas some other server trail(s) will learn that they serve from no= w on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as the > client) then there is no fixed client/server relationship.=20 I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation= . There is no difference with what we do today in SDH and OTN. A client/serve= r relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generatio= n is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of = a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client i= s independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO= . regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -=20 > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) >=20 > If we agree that the requirement is included, so why do we keep with=20 > the endless discussions on this requirement? >=20 > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) >=20 > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN=20 > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > transport pathrequirements) > >=20 > > Huub, > > I think that the requirement is to provide a mechanism to suppress=20 > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer=20 > > may be suppressed. > > Every thing else is a solution, etc.=20 > > I propose to phrase the requirement appropriately and conclude the=20 > > discussion on this in the context of the requirements (until we are=20 > > getting to the solution phase). > > This requirement is included in the OAM requirement draft.=20 > > Best regards, > > NUrit > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > >=20 > > Hi Adrian, > >=20 > > You wrote: > >=20 > > > Isn't the solution here the same as the one I proposed for "TCM"? > >=20 > > Indeed, and that we do not have to around in circles about TCM. > >=20 > > How about: > > the requirement is that a server layer shall inform its clients that=20 > > it has detected a service interuption, this to ensure that the=20 > > clients can inhibit (unnecessary) alarms. > >=20 > > Cheers, Huub. > >=20 > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Tue Apr 28 11:54:43 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44193A6970 for ; Tue, 28 Apr 2009 11:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.684 X-Spam-Level: X-Spam-Status: No, score=0.684 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oUa+92alYfS for ; Tue, 28 Apr 2009 11:54:41 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D04143A70D5 for ; Tue, 28 Apr 2009 11:54:40 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00FVLR93BZ@szxga02-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 02:55:52 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00AETR93AJ@szxga02-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 02:55:51 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT0007YR8T16@szxml02-in.huawei.com>; Wed, 29 Apr 2009 02:55:51 +0800 (CST) Date: Tue, 28 Apr 2009 20:55:43 +0200 From: Maarten Vissers In-reply-to: <04c801c9c81d$c616ce80$52446b80$@com> To: davarish@yahoo.com Message-id: <003b01c9c832$f16ea4d0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAjs+wAACv2LAABRx6IA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:54:43 -0000 Shahram, In 1+1 AIS will generated by the adaptation function supporting the failed working connection. As long as the selector reads from this working connection, AIS will be forwarded to the far end endpoint. As soon as the selector reads from the protection connection, AIS generated by the working connection adaptation fucntion will drop dead at the input of the selector. I don't know if FRR is a protection switching method or if it is a restoration method. If it is a protection switching method, then a link fault will result in generation of AIS on all active client connections of the link. The protection selector will forward such AIS packet as long as it reads from the failed link. Once it switches to the alternative link, the AIS packets will drop dead at the input of the selector. If FRR is a restoration method, then a fault in a link will result in setting up an alternative path and in withdrawing the bindings with the failed link. Initially the failed link endpoint will emit AIS for each registered client connection; as soon as a registration is withdrawn (due to restorations), generation of AIS for this client connection stops. Regards, Maarten -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: dinsdag 28 april 2009 18:24 To: 'Maarten Vissers' Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Maarten, How about in 1+1? Or in FRR? will AIS be forwarded? Shahram -----Original Message----- From: Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: April-28-09 12:09 PM To: davarish@yahoo.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, When you apply protection you will not change the binding between client and server layers when you switch from e.g. working to protection. All client/server bindings are still present. What you changed is the connectivity in the connection function. You find this illustrated in e.g. G.806. When the working connection would fail, then AIS would be inserted e.g. at the end of the server layer connection that carries the working connection. AIS is inserted independent of the state of the next protection switch selector process. If the selector is not moved to the protection connection, then AIS inserted into the working connection is forwarded through the protection switch selector to the far end of the protected connection. If the selector is moved to read from the protection connection, then AIS is still inserted intto the working connection, but the selector is not reading from working, so AIS will drop dead at the input of the selector. Regards, Maarten -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: dinsdag 28 april 2009 17:57 To: 'Igor Bryskin'; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Your assumption is that there is a control plane that sets up the binding between client and server layer and that such binding will be removed via the control plane when a reroute happens. I think this assumption is not always true. For example in a linear 1:1 or 1+1 protection, there is no signalling to withdraw the binding at intermediate nodes. In 1:1 there is APS, but that is end-to-end and is sent on the backup path not working path. -Shahram -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: April-28-09 11:27 AM To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side of the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that network C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer. -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connection less, whereas some other server trail(s) will learn that they serve from now on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation. There is no difference with what we do today in SDH and OTN. A client/server relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generation is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > ================================================================ > > http://www.van-helvoort.eu/ > > ================================================================ > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Tue Apr 28 12:23:54 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568EF3A67EA for ; Tue, 28 Apr 2009 12:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2fdTwRy+sgo for ; Tue, 28 Apr 2009 12:23:52 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id EF5AE3A67E4 for ; Tue, 28 Apr 2009 12:23:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00GFNSLQBO@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 03:25:02 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00G0GSLQUJ@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 03:25:02 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT004AYSLEBW@szxml01-in.huawei.com>; Wed, 29 Apr 2009 03:25:02 +0800 (CST) Date: Tue, 28 Apr 2009 21:24:52 +0200 From: Maarten Vissers In-reply-to: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B34583C@atl-srv-exgen.atl.advaoptical.com> To: 'Igor Bryskin' Message-id: <003d01c9c837$03fb7f20$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:23:54 -0000 Igor, > b) Is it beneficial if a server trail notifies its clients about a detected problem to suppress the OAM traffic The suppression we have been talking about is alarm suppression, not OAM traffic suppression. Loss of CC is intended to detect an open connection fault in a matrix. E.g. assume a connection that starts in node A, passes through nodes B and C and ends in node D. Nodes A, B, C and D have a connection function in which a matrix connection is to be set up to support this connection from A to D. What is now possible is that the matrix connection in node B is unintentionally removed (i.e. a continuity fault). Node D will now detect a loss of CC. Node D does not detect any other faults. Node C will not detect any fault. Node B will not detect any fault. Node A will not detect any fault if the matrix connection in B is removed in one direction only. In order to detect this open matrix connection fault it is required to report the loss of CC to the management system and to start a fault localization procedure to locate the faulty matrix (i.e. in node B). If such reporting is not done, then there is a hidden fault, which keeps the connection interrupted much longer; i.e. until one or more customers start to complain that their connections are lost. Then you hae to find in a big network without any fault report which node has the fault. What happens now if the fault is not an open matrix connection but a server layer fault (e.g. a link fault between nodes A and B). Node D will now detect a loss of CC. Node D does not detect any other faults. Node C will not detect any fault. Node B will detect a loss of signal fault. Node A will not detect any fault if the link from A to B is broken in one direction only. If loss of CC is unconditionally reported, then node D will report loss of CC. Node B will report loss of signal. - If node B and node D are managed by the same management system it is possible to perform a fault correlation in this management system to filter out the loss of CC from node D. What is necessary is to know that connection A-D is supported by the link A to B. In larger multi-layer networks such correlations become complex. If such correlations are not performed, then the loss of CC will trigger a fault localisation action, which of course will not find a matrix fault (i.e. waste of time). - If node B is managed by another management system then node D, there is no correlation possible. Node D's management system will see only the loss of CC and will start fault localization, and will not find any fault in its part of the network. Use of AIS will help in distinguishing between connection interruption due to an open matrix connection fault and due to server fault. AIS provides the necessary filter for loss of CC. What happens for the case a port detects a signal fail condition is the following; assume a 10G port that detects a signal fail condition. This implies that all traffic is lost. Assume that there are 1000 client connections active (e.g. with an average bandwidth of 5 Mbit/s). When AIS is to be generated for those 1000 client conenctions the port has to generate 1000 AIS frames/packets per second. Each AIS frame/packet is 64 bytes/512 bits. Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005 Gbit/s) of traffic in a further empty 10G port. This isn't any real complexity. --------- The alternative is to declare that open matrix connections are never a fault condition (i.e. are always intentional and thus known by network management). Under such starting point it is not necessary to detect an open matrix connection as a fault condition. Now it is not longer necessary to distinguish between connection interruption due to open matrix and server layer fault as the first condition isn't a fault anylonger. Under this condition it is not useful that a server trail informs its clients about a detected server trail problem that interrupts the client connections. If we go for this latter approach and if in future an open matrix connection would be a fault condition, then this is a hidden fault and you need a lot more work to locate the fault (there are no alarms that help you). Regards, Maarten -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: dinsdag 28 april 2009 18:20 To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, I was addressing Neil's comments about the dynamic re-routing, which is different from protection switchover onto pre-provisioned protection connection. True, in the latter case the server layer wouldn't notice that and will keep notifying the client that the trail is broken. But this does not change anything. The big 2 questions in my mind are: a) Is the OAM of a given layer is (i) self-sufficient and (ii) scalable enough, so that operator can rely on it completely and independently from what is happening in the lower layers? b) Is it beneficial if a server trail notifies its clients about a detected problem to suppress the OAM traffic and possibly unnecessary switchovers until the server trail corrects itself? Cheers, Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:57 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Your assumption is that there is a control plane that sets up the binding between client and server layer and that such binding will be removed via the control plane when a reroute happens. I think this assumption is not always true. For example in a linear 1:1 or 1+1 protection, there is no signalling to withdraw the binding at intermediate nodes. In 1:1 there is APS, but that is end-to-end and is sent on the backup path not working path. -Shahram -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: April-28-09 11:27 AM To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side of the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that network C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer. -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connection less, whereas some other server trail(s) will learn that they serve from now on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation. There is no difference with what we do today in SDH and OTN. A client/server relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generation is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > ================================================================ > > http://www.van-helvoort.eu/ > > ================================================================ > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Tue Apr 28 12:29:25 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72BB3A67E4 for ; Tue, 28 Apr 2009 12:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.615 X-Spam-Level: X-Spam-Status: No, score=0.615 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JahkG+qseMY0 for ; Tue, 28 Apr 2009 12:29:24 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CC83B3A6A77 for ; Tue, 28 Apr 2009 12:29:23 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT005HNSUYQD@szxga04-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 03:30:35 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT0047RSUY1J@szxga04-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 03:30:34 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT004JTSUOBW@szxml01-in.huawei.com>; Wed, 29 Apr 2009 03:30:34 +0800 (CST) Date: Tue, 28 Apr 2009 21:30:27 +0200 From: Maarten Vissers In-reply-to: <04d601c9c835$323ed410$96bc7c30$@com> To: davarish@yahoo.com Message-id: <003e01c9c837$cb3870c0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAjs+wAACv2LAABRx6IAAArtQgAACYz5A= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:29:26 -0000 Shahram, Merging is I believe outside the scope of MPLS-TP... If this type of merging is inside the scope of MPLS-TP then AIS will indeed be forwarded. This then becomes similar to the n-port VLAN case. I.e. in a VLAN one of the branches may be disconnected, whereas other branches are still connected. The disconnected branch will insert ETH AIS to inform the downstream endpoints that there is a server layer failure. Any loss of CC detected at those endpoints will be suppressed by AIS. AIS has no impact on loss of CC detectors itself or on loss of CC fault cause determination for loss of CC detectors that still receive the expected CC frames. With the merging in FRR you will notice the same behaviour. If the reroute results in recovery of the connection, then the AIS packet will be received by the endpoint. At the endpoint it will be discarded as there is nothing to suppress. Regards, Maarten -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: dinsdag 28 april 2009 21:12 To: 'Maarten Vissers' Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Maarten, In FRR there is merging at the sink node and there is no selector. So AIS will be forwarded. -Shahram -----Original Message----- From: Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: April-28-09 2:56 PM To: davarish@yahoo.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, In 1+1 AIS will generated by the adaptation function supporting the failed working connection. As long as the selector reads from this working connection, AIS will be forwarded to the far end endpoint. As soon as the selector reads from the protection connection, AIS generated by the working connection adaptation fucntion will drop dead at the input of the selector. I don't know if FRR is a protection switching method or if it is a restoration method. If it is a protection switching method, then a link fault will result in generation of AIS on all active client connections of the link. The protection selector will forward such AIS packet as long as it reads from the failed link. Once it switches to the alternative link, the AIS packets will drop dead at the input of the selector. If FRR is a restoration method, then a fault in a link will result in setting up an alternative path and in withdrawing the bindings with the failed link. Initially the failed link endpoint will emit AIS for each registered client connection; as soon as a registration is withdrawn (due to restorations), generation of AIS for this client connection stops. Regards, Maarten -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: dinsdag 28 april 2009 18:24 To: 'Maarten Vissers' Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Maarten, How about in 1+1? Or in FRR? will AIS be forwarded? Shahram -----Original Message----- From: Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: April-28-09 12:09 PM To: davarish@yahoo.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, When you apply protection you will not change the binding between client and server layers when you switch from e.g. working to protection. All client/server bindings are still present. What you changed is the connectivity in the connection function. You find this illustrated in e.g. G.806. When the working connection would fail, then AIS would be inserted e.g. at the end of the server layer connection that carries the working connection. AIS is inserted independent of the state of the next protection switch selector process. If the selector is not moved to the protection connection, then AIS inserted into the working connection is forwarded through the protection switch selector to the far end of the protected connection. If the selector is moved to read from the protection connection, then AIS is still inserted intto the working connection, but the selector is not reading from working, so AIS will drop dead at the input of the selector. Regards, Maarten -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: dinsdag 28 april 2009 17:57 To: 'Igor Bryskin'; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Your assumption is that there is a control plane that sets up the binding between client and server layer and that such binding will be removed via the control plane when a reroute happens. I think this assumption is not always true. For example in a linear 1:1 or 1+1 protection, there is no signalling to withdraw the binding at intermediate nodes. In 1:1 there is APS, but that is end-to-end and is sent on the backup path not working path. -Shahram -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: April-28-09 11:27 AM To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side of the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that network C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer. -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connection less, whereas some other server trail(s) will learn that they serve from now on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation. There is no difference with what we do today in SDH and OTN. A client/server relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generation is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > ================================================================ > > http://www.van-helvoort.eu/ > > ================================================================ > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From IBryskin@advaoptical.com Tue Apr 28 12:53:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814A83A69F1 for ; Tue, 28 Apr 2009 12:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngB7T8Y2Km4y for ; Tue, 28 Apr 2009 12:52:58 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 92A283A6CA2 for ; Tue, 28 Apr 2009 12:52:57 -0700 (PDT) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n3SJs5Ip027992 for ; Tue, 28 Apr 2009 21:54:06 +0200 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 28 Apr 2009 21:54:19 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 21:54:05 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 28 Apr 2009 15:54:03 -0400 From: Igor Bryskin To: Maarten Vissers Date: Tue, 28 Apr 2009 15:54:01 -0400 Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAAAZtPMA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3458F9@atl-srv-exgen.atl.advaoptical.com> References: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B34583C@atl-srv-exgen.atl.advaoptical.com> <003d01c9c837$03fb7f20$6c02a8c0@china.huawei.com> In-Reply-To: <003d01c9c837$03fb7f20$6c02a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:53:00 -0000 Marten thanks, Yes, when I said OAM traffic suppression, I meant actually the alarm suppre= ssion. Andy wrote that the AIS provides no additional information, and I disagree. The two cases: a) CC fails, no AIS; b) CC fails, AIS is present are different, and the difference IMHO is in the time to react on CC failur= e. In case b) I would allow more time to let the server to attempt to repai= r itself. In case a) I would react faster. So I agree with you, there could be a multi-layer correlation recovery-wise= . What if you have a multi-layer network and a failure happens in the lowest = layer? It seams reasonable to let the lowest layer to try to recover befor= e recovering clients and clients of clients. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Maarten Vissers Sent: Tuesday, April 28, 2009 3:25 PM To: Igor Bryskin Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Igor, > b) Is it beneficial if a server trail notifies its clients about a detected problem to suppress the OAM traffic The suppression we have been talking about is alarm suppression, not OAM traffic suppression. Loss of CC is intended to detect an open connection fault in a matrix. E.g. assume a connection that starts in node A, passes through nodes B and = C and ends in node D. Nodes A, B, C and D have a connection function in which a matrix connection is to be set up to support this connection from A to D. What is now possible is that the matrix connection in node B is unintentionally removed (i.e. a continuity fault). Node D will now detect a loss of CC. Node D does not detect any other faults. Node C will not detect any fault. Node B will not detect any fault. Node A will not detect any fault if the matrix connection in B is removed i= n one direction only. In order to detect this open matrix connection fault it is required to report the loss of CC to the management system and to start a fault localization procedure to locate the faulty matrix (i.e. in node B). If suc= h reporting is not done, then there is a hidden fault, which keeps the connection interrupted much longer; i.e. until one or more customers start to complain that their connections are lost. Then you hae to find in a big network without any fault report which node has the fault. What happens now if the fault is not an open matrix connection but a server layer fault (e.g. a link fault between nodes A and B). Node D will now detect a loss of CC. Node D does not detect any other faults. Node C will not detect any fault. Node B will detect a loss of signal fault. Node A will not detect any fault if the link from A to B is broken in one direction only. If loss of CC is unconditionally reported, then node D will report loss of CC. Node B will report loss of signal. - If node B and node D are managed by the same management system it is possible to perform a fault correlation in this management system to filter out the loss of CC from node D. What is necessary is to know that connectio= n A-D is supported by the link A to B. In larger multi-layer networks such correlations become complex. If such correlations are not performed, then the loss of CC will trigger a fault localisation action, which of course will not find a matrix fault (i.e. waste of time). - If node B is managed by another management system then node D, there is n= o correlation possible. Node D's management system will see only the loss of CC and will start fault localization, and will not find any fault in its part of the network. Use of AIS will help in distinguishing between connection interruption due to an open matrix connection fault and due to server fault. AIS provides th= e necessary filter for loss of CC. What happens for the case a port detects a signal fail condition is the following; assume a 10G port that detects a signal fail condition. This implies that all traffic is lost. Assume that there are 1000 client connections active (e.g. with an average bandwidth of 5 Mbit/s). When AIS i= s to be generated for those 1000 client conenctions the port has to generate 1000 AIS frames/packets per second. Each AIS frame/packet is 64 bytes/512 bits. Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005 Gbit/s) of traffic in a further empty 10G port. This isn't any real complexity. --------- The alternative is to declare that open matrix connections are never a faul= t condition (i.e. are always intentional and thus known by network management). Under such starting point it is not necessary to detect an ope= n matrix connection as a fault condition. Now it is not longer necessary to distinguish between connection interruption due to open matrix and server layer fault as the first condition isn't a fault anylonger. Under this condition it is not useful that a server trail informs its clients about a detected server trail problem that interrupts the client connections. If we go for this latter approach and if in future an open matrix connectio= n would be a fault condition, then this is a hidden fault and you need a lot more work to locate the fault (there are no alarms that help you). Regards, Maarten -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: dinsdag 28 april 2009 18:20 To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, I was addressing Neil's comments about the dynamic re-routing, which is different from protection switchover onto pre-provisioned protection connection. True, in the latter case the server layer wouldn't notice that and will keep notifying the client that the trail is broken. But this does not change anything. The big 2 questions in my mind are: a) Is the OAM of a given layer is (i) self-sufficient and (ii) scalable enough, so that operator can rely on it completely and independently from what is happening in the lower layers? b) Is it beneficial if a server trail notifies its clients about a detected problem to suppress the OAM traffic and possibly unnecessary switchovers until the server trail corrects itself? Cheers, Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:57 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Your assumption is that there is a control plane that sets up the binding between client and server layer and that such binding will be removed via the control plane when a reroute happens. I think this assumption is not always true. For example in a linear 1:1 or 1+1 protection, there is no signalling to withdraw the binding at intermediate nodes. In 1:1 there is APS, but that is end-to-end and is sent on the backup path not working path= . -Shahram -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: April-28-09 11:27 AM To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side o= f the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that networ= k C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer. -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically)= . As soon as the connection is re-routed, this relationship is broken (becaus= e this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connectio= n less, whereas some other server trail(s) will learn that they serve from no= w on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation= . There is no difference with what we do today in SDH and OTN. A client/serve= r relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generatio= n is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of = a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client i= s independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO= . regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/ > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From IBryskin@advaoptical.com Tue Apr 28 14:21:31 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67963A6AF3 for ; Tue, 28 Apr 2009 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YDkidNTpbEB for ; Tue, 28 Apr 2009 14:21:30 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 9F4113A69FE for ; Tue, 28 Apr 2009 14:21:02 -0700 (PDT) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n3SLMCSp031933 for ; Tue, 28 Apr 2009 23:22:12 +0200 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 28 Apr 2009 23:22:26 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 23:22:11 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Tue, 28 Apr 2009 17:22:09 -0400 From: Igor Bryskin To: "davarish@yahoo.com" , "'Maarten Vissers'" Date: Tue, 28 Apr 2009 17:22:08 -0400 Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAAAZtPMAABAlNQAAIkhpA= Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B345941@atl-srv-exgen.atl.advaoptical.com> References: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B34583C@atl-srv-exgen.atl.advaoptical.com> <003d01c9c837$03fb7f20$6c02a8c0@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3458F9@atl-srv-exgen.atl.advaoptical.com> <04de01c9c83d$b7a27f50$26e77df0$@com> In-Reply-To: <04de01c9c83d$b7a27f50$26e77df0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 21:21:32 -0000 Shahram, OSPF will react on Hello miss or a fault indication from the server layer s= erving IP link. The only reason why you need the latter is that it comes ea= rlier that the former. So, IMO you can delay the fault indication by the la= yer serving IP link if it receives some sort of AIS from its own server lay= er. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 4:13 PM To: Igor Bryskin; 'Maarten Vissers' Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Hi Igore, If client layer is using a dynamic routing such as RSTP or OSPF, I don't think AIS could slow down the convergence of RSTP or OSPF. Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 3:54 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Marten thanks, Yes, when I said OAM traffic suppression, I meant actually the alarm suppression. Andy wrote that the AIS provides no additional information, and I disagree. The two cases: a) CC fails, no AIS; b) CC fails, AIS is present are different, and the difference IMHO is in the time to react on CC failure. In case b) I would allow more time to let the server to attempt to repair itself. In case a) I would react faster. So I agree with you, there could be a multi-layer correlation recovery-wise= . What if you have a multi-layer network and a failure happens in the lowest layer? It seams reasonable to let the lowest layer to try to recover befor= e recovering clients and clients of clients. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 3:25 PM To: Igor Bryskin Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, > b) Is it beneficial if a server trail notifies its clients about a detected problem to suppress the OAM traffic The suppression we have been talking about is alarm suppression, not OAM traffic suppression. Loss of CC is intended to detect an open connection fault in a matrix. E.g. assume a connection that starts in node A, passes through nodes B and = C and ends in node D. Nodes A, B, C and D have a connection function in which a matrix connection is to be set up to support this connection from A to D. What is now possible is that the matrix connection in node B is unintentionally removed (i.e. a continuity fault). Node D will now detect a loss of CC. Node D does not detect any other faults. Node C will not detect any fault. Node B will not detect any fault. Node A will not detect any fault if the matrix connection in B is removed i= n one direction only. In order to detect this open matrix connection fault it is required to report the loss of CC to the management system and to start a fault localization procedure to locate the faulty matrix (i.e. in node B). If suc= h reporting is not done, then there is a hidden fault, which keeps the connection interrupted much longer; i.e. until one or more customers start to complain that their connections are lost. Then you hae to find in a big network without any fault report which node has the fault. What happens now if the fault is not an open matrix connection but a server layer fault (e.g. a link fault between nodes A and B). Node D will now detect a loss of CC. Node D does not detect any other faults. Node C will not detect any fault. Node B will detect a loss of signal fault. Node A will not detect any fault if the link from A to B is broken in one direction only. If loss of CC is unconditionally reported, then node D will report loss of CC. Node B will report loss of signal. - If node B and node D are managed by the same management system it is possible to perform a fault correlation in this management system to filter out the loss of CC from node D. What is necessary is to know that connectio= n A-D is supported by the link A to B. In larger multi-layer networks such correlations become complex. If such correlations are not performed, then the loss of CC will trigger a fault localisation action, which of course will not find a matrix fault (i.e. waste of time). - If node B is managed by another management system then node D, there is n= o correlation possible. Node D's management system will see only the loss of CC and will start fault localization, and will not find any fault in its part of the network. Use of AIS will help in distinguishing between connection interruption due to an open matrix connection fault and due to server fault. AIS provides th= e necessary filter for loss of CC. What happens for the case a port detects a signal fail condition is the following; assume a 10G port that detects a signal fail condition. This implies that all traffic is lost. Assume that there are 1000 client connections active (e.g. with an average bandwidth of 5 Mbit/s). When AIS i= s to be generated for those 1000 client conenctions the port has to generate 1000 AIS frames/packets per second. Each AIS frame/packet is 64 bytes/512 bits. Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005 Gbit/s) of traffic in a further empty 10G port. This isn't any real complexity. --------- The alternative is to declare that open matrix connections are never a faul= t condition (i.e. are always intentional and thus known by network management). Under such starting point it is not necessary to detect an ope= n matrix connection as a fault condition. Now it is not longer necessary to distinguish between connection interruption due to open matrix and server layer fault as the first condition isn't a fault anylonger. Under this condition it is not useful that a server trail informs its clients about a detected server trail problem that interrupts the client connections. If we go for this latter approach and if in future an open matrix connectio= n would be a fault condition, then this is a hidden fault and you need a lot more work to locate the fault (there are no alarms that help you). Regards, Maarten -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: dinsdag 28 april 2009 18:20 To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, I was addressing Neil's comments about the dynamic re-routing, which is different from protection switchover onto pre-provisioned protection connection. True, in the latter case the server layer wouldn't notice that and will keep notifying the client that the trail is broken. But this does not change anything. The big 2 questions in my mind are: a) Is the OAM of a given layer is (i) self-sufficient and (ii) scalable enough, so that operator can rely on it completely and independently from what is happening in the lower layers? b) Is it beneficial if a server trail notifies its clients about a detected problem to suppress the OAM traffic and possibly unnecessary switchovers until the server trail corrects itself? Cheers, Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:57 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Your assumption is that there is a control plane that sets up the binding between client and server layer and that such binding will be removed via the control plane when a reroute happens. I think this assumption is not always true. For example in a linear 1:1 or 1+1 protection, there is no signalling to withdraw the binding at intermediate nodes. In 1:1 there is APS, but that is end-to-end and is sent on the backup path not working path= . -Shahram -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: April-28-09 11:27 AM To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Shahram, Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side o= f the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned. Igor -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com] Sent: Tuesday, April 28, 2009 11:15 AM To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Hi Igor, How does the server know the client is rerouted? Assume the following networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that networ= k C uses MPLS-TP as server layer. Network C will never know there was a protection switching done for the client layer. -Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: April-28-09 11:05 AM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically)= . As soon as the connection is re-routed, this relationship is broken (becaus= e this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connectio= n less, whereas some other server trail(s) will learn that they serve from no= w on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation= . There is no difference with what we do today in SDH and OTN. A client/serve= r relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generatio= n is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of = a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client i= s independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO= . regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/ > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From Italo.Busi@alcatel-lucent.it Tue Apr 28 15:14:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1122C3A6C99 for ; Tue, 28 Apr 2009 15:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkqtmI-CyuDu for ; Tue, 28 Apr 2009 15:14:35 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 0B2BE3A6D69 for ; Tue, 28 Apr 2009 15:14:34 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3SMFfQo014831; Wed, 29 Apr 2009 00:15:41 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 00:15:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 00:15:40 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB40220F0C8@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <049e01c9c814$0cbd1830$26374890$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAA0cuEA= References: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com> <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3457FB@atl-srv-exgen.atl.advaoptical.com> <049e01c9c814$0cbd1830$26374890$@com> From: "BUSI ITALO" To: , "Igor Bryskin" , "Maarten Vissers" , , , , X-OriginalArrivalTime: 28 Apr 2009 22:15:41.0697 (UTC) FILETIME=[DE287F10:01C9C84E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 22:14:37 -0000 Shahram, C will insert AIS toward E. This is correct because we wish to suppress the reporting of the LOC alarm at E on the working transport entity. However the LOC condition still triggers the protection switching action so the traffic is rerouted on the protection path. Italo > -----Original Message----- > From: Shahram Davari [mailto:davarish@yahoo.com]=20 > Sent: Tuesday, April 28, 2009 5:15 PM > To: 'Igor Bryskin'; 'Maarten Vissers';=20 > neil.2.harrison@bt.com; nurit.sprecher@nsn.com; BUSI ITALO;=20 > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated=20 > bidirectionaltransportpathrequirements) >=20 > Hi Igor, >=20 > How does the server know the client is rerouted? Assume the following > networks: A-B-C-D-E (working) and A-F-G-E (protection).=20 > Assume each has its > own server layer such as MPLS, MPLS-TP, ATM, SONET, etc.=20 > Assume that network > C uses MPLS-TP as server layer. Network C will never know there was a > protection switching done for the client layer.=20 >=20 > -Shahram >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Igor Bryskin > Sent: April-28-09 11:05 AM > To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Neil. >=20 > I actually agree with Maarten on this. I don't quite=20 > understand why do you > keep talking about fixed client-server relationship. It is=20 > fixed as long as > the client layer connection configured this way (statically=20 > or dynamically). > As soon as the connection is re-routed, this relationship is=20 > broken (because > this is a part of the re-routing process) and hence the server trail > termination points will know that the server trail now serves=20 > one connection > less, whereas some other server trail(s) will learn that they=20 > serve from now > on one connection more. These new client-server relationships=20 > are fixed > until the next re-routing. >=20 > Cheers, > Igor=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Maarten Vissers > Sent: Tuesday, April 28, 2009 8:48 AM > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Neil, >=20 > > However, if the client can dynamically change its routing=20 > in response > > to link failures in its topology (because some server layer=20 > network has > > failed....which may or may not belong to the same operating=20 > party as the > > client) then there is no fixed client/server relationship.=20 >=20 > I believe there is a fixed client/server relationship also in=20 > this case in > the network. This relationship is broken when the connection=20 > is rerouted. > Such reroute will remove the CP/FP and as such will stop the=20 > AIS generation. >=20 > There is no difference with what we do today in SDH and OTN.=20 > A client/server > relationship is fixed until the point in time that the=20 > connection is either > teardown or rerouted. When either of the two cases occur, the=20 > AIS generation > is stopped. Until such action is performed, AIS is generated=20 > during signal > fail condition period and inserted into the connection. >=20 > In MPLS-TP we have the requirement that MPLS-TP must be able=20 > to operate > without control plane. This implies that it will operate without > restoration, and that there will not be frequent rerouteing=20 > ongoing. Result > is that client/server relationships will last until the connection is > teardown. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of neil.2.harrison@bt.com > Sent: dinsdag 28 april 2009 10:07 > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Nurit, >=20 > I believe the reason we need this discussion is that there is=20 > an unstated > assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in=20 > response to > link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating=20 > party as the > client) then there is no fixed client/server relationship. >=20 > Refer to my post earlier today and consider what this means=20 > in the case of a > cl-ps IP client layer network or a some SVC-based co-ps/co-cs=20 > mode client > layer network. The key point here is the *routing process*=20 > in the client is > independent of the server layer network....so there is not a fixed > client/server relationship. Further, there is also no=20 > requirement for the > server to keep track of where its client traffic routings are at any > epoch.....indeed why should it in the general case where these are > independent layer networks? >=20 > So the only OAM requirement that is critical is that the OAM=20 > of the client > and server layer networks are independent. It is thus not=20 > sensible to make > client layer alarm supression a 'requirement' here...in fact=20 > if this is in > the OAM requirements then it is technically wrong and should=20 > be removed IMO. >=20 > regards, Neil=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN -=20 > > IL/Hod HaSharon) > > Sent: 28 April 2009 08:46 > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > >=20 > > If we agree that the requirement is included, so why do we=20 > keep with=20 > > the endless discussions on this requirement? > >=20 > > -----Original Message----- > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Tuesday, April 28, 2009 10:44 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > > Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional transport > > pathrequirements) > >=20 > > I think that the requirements are defined in section 2.2.8 of > > draft-ietf-mpls-tp-oam-requirements-01 > >=20 > > Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN=20 > > > - IL/Hod HaSharon) > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > To: hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > > transport pathrequirements) > > >=20 > > > Huub, > > > I think that the requirement is to provide a mechanism to=20 > suppress=20 > > > alarms in the networks, to ensure that alarms that may be > > generated by > > > client layers as a result of a failure condition in the=20 > server layer=20 > > > may be suppressed. > > > Every thing else is a solution, etc.=20 > > > I propose to phrase the requirement appropriately and=20 > conclude the=20 > > > discussion on this in the context of the requirements=20 > (until we are=20 > > > getting to the solution phase). > > > This requirement is included in the OAM requirement draft.=20 > > > Best regards, > > > NUrit > > >=20 > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On=20 > > > Behalf Of ext Huub van Helvoort > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > To: Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > path requirements) > > >=20 > > > Hi Adrian, > > >=20 > > > You wrote: > > >=20 > > > > Isn't the solution here the same as the one I proposed=20 > for "TCM"? > > >=20 > > > Indeed, and that we do not have to around in circles about TCM. > > >=20 > > > How about: > > > the requirement is that a server layer shall inform its=20 > clients that=20 > > > it has detected a service interuption, this to ensure that the=20 > > > clients can inhibit (unnecessary) alarms. > > >=20 > > > Cheers, Huub. > > >=20 > > > -- > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > http://www.van-helvoort.eu/=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 From andy.bd.reid@bt.com Tue Apr 28 15:25:07 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18AB3A7128 for ; Tue, 28 Apr 2009 15:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.418 X-Spam-Level: X-Spam-Status: No, score=0.418 tagged_above=-999 required=5 tests=[AWL=3.417, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDOonoVePpY9 for ; Tue, 28 Apr 2009 15:25:01 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 06DAC3A6E25 for ; Tue, 28 Apr 2009 15:24:59 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 23:26:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 23:26:20 +0100 Message-ID: In-Reply-To: <003d01c9c837$03fb7f20$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0A== From: To: , X-OriginalArrivalTime: 28 Apr 2009 22:26:20.0631 (UTC) FILETIME=[5AFE1670:01C9C850] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 22:25:07 -0000 Maarten, Igor, Before dealing with the specific scenarios, let me go through again what I said in an earlier posting about the way alarm 'suppression' actually works. There are two sides to maintenance - the faulty kit guys who fix faulty cards, mend cable breaks, etc, etc, and end service guys who deal with customer service. 'Suppressed' alarms are only suppressed to the faulty kit guys who fix cards, etc. The distinction between 'local' and 'remote' alarms is very important to ensure that these faulty kit guys are directed to the place where the actual fault lies and not to places affected by, but remote from the actual fault. However, these 'suppressed' alarms are still forwarded to the service maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they want to know whether the end service is 'up' or 'down' irrespective of the cause and irrespective of the presence of AIS. AIS most emphatically does not suppress this alarm! These guys wants to know that the service is 'down' before the customer is on the phone! So to go to Maarten's first example, the faulty kit guys are not getting any alarms telling them to fix broken kit - which is correct. The service maintenance guys *have* got an alarm - the customer has not got their service! They also notice that it is not fixing itself. So they investigate, ie start localising. In practice, the first thing they will do (and most management systems will do it automatically by some form of correlation engine) is check for any corresponding faulty kit alarms. In this case, they will find no faulty kit alarms and suspect a misconfiguration, localise it, and fix it. To go to Maarten's second example, the faulty kit guys are getting an alarm telling them to fix the link between A and B. The service maintenance guys have also got an alarm - again the customer has not got their service. They also notice that it is not fixing itself. So they investigate, ie start localising. Again, the first thing they will do (and most management systems will do it automatically by some form of correlation engine) is check for any corresponding faulty kit alarms. In this case, they will find the corresponding faulty kit alarm and can check of the repair plan and status should the customer call and ask. As these particular scenarios illustrate, the right alarms have been directed to the right maintenance guys. The service guys deal with the service configurations, the faulty kit guys deal with faulty kit. Occasionally, there will be faulty kit which is not reporting itself despite the best design efforts in the equipment. In this case, the service maintenance guys are likely to have a series of alarms which can be correlated to help localise the fault and the diagnosed fault can then be passed to the faulty kit guys for fixing. Another important point. There is little room here for *false* information coming to either set of maintenance guys. When trying to localise a fault, no additional information is better than wrong additional information. That is my concern with the trying to inject packet based AIS. There is significant room for creating false information. As I've already indicted there is AIS specific configuration to do which will be prone to misconfiguration. We should then note that the thing that the AIS is supposed to be identifying is the present of misconfiguration - but achieving this requires configuration. So why should one configuration be more reliable than the other? But there are other scenarios. For example, consider port mapping (or in ITU-T speak, a degenerate subnetwork) where we terminate the section layer on one interface and blindly ship all the packets out on an other interface in a new section. If we assume AIS is being used, a fault in the incoming section should result in the injection of AIS. But how does it know what label values to use? Or does it not inject AIS? In which case we have the poor service maintenance guys actively looking for a configuration error which does not exist. A similar scenario would exist if we choose to use a sort of ADM where the forwarding table was made up of exception (add/drop) label values and a default outgoing port. Again, the same dilemma exists. Andy Andy Reid Chief Network Services Strategist BT Innovate =20 Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com =20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 28 April 2009 20:25 > To: 'Igor Bryskin' > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated=20 > bidirectionaltransportpathrequirements) >=20 > Igor, >=20 > > b) Is it beneficial if a server trail notifies its clients about > a detected problem to suppress the OAM traffic=20 >=20 > The suppression we have been talking about is alarm=20 > suppression, not OAM traffic suppression. >=20 > Loss of CC is intended to detect an open connection fault in=20 > a matrix.=20 > E.g. assume a connection that starts in node A, passes=20 > through nodes B and C and ends in node D. > Nodes A, B, C and D have a connection function in which a=20 > matrix connection is to be set up to support this connection=20 > from A to D. >=20 > What is now possible is that the matrix connection in node B=20 > is unintentionally removed (i.e. a continuity fault). > Node D will now detect a loss of CC. Node D does not detect=20 > any other faults. > Node C will not detect any fault. > Node B will not detect any fault. > Node A will not detect any fault if the matrix connection in=20 > B is removed in one direction only. >=20 > In order to detect this open matrix connection fault it is=20 > required to report the loss of CC to the management system=20 > and to start a fault localization procedure to locate the=20 > faulty matrix (i.e. in node B). If such reporting is not=20 > done, then there is a hidden fault, which keeps the=20 > connection interrupted much longer; i.e. until one or more=20 > customers start to complain that their connections are lost.=20 > Then you hae to find in a big network without any fault=20 > report which node has the fault. >=20 > What happens now if the fault is not an open matrix=20 > connection but a server layer fault (e.g. a link fault=20 > between nodes A and B). > Node D will now detect a loss of CC. Node D does not detect=20 > any other faults. > Node C will not detect any fault. > Node B will detect a loss of signal fault. > Node A will not detect any fault if the link from A to B is=20 > broken in one direction only. >=20 > If loss of CC is unconditionally reported, then node D will=20 > report loss of CC. Node B will report loss of signal. > - If node B and node D are managed by the same management=20 > system it is possible to perform a fault correlation in this=20 > management system to filter out the loss of CC from node D.=20 > What is necessary is to know that connection A-D is supported=20 > by the link A to B. In larger multi-layer networks such=20 > correlations become complex. If such correlations are not=20 > performed, then the loss of CC will trigger a fault=20 > localisation action, which of course will not find a matrix=20 > fault (i.e. waste of time). > - If node B is managed by another management system then node=20 > D, there is no correlation possible. Node D's management=20 > system will see only the loss of CC and will start fault=20 > localization, and will not find any fault in its part of the network.=20 >=20 > Use of AIS will help in distinguishing between connection=20 > interruption due to an open matrix connection fault and due=20 > to server fault. AIS provides the necessary filter for loss of CC. >=20 > What happens for the case a port detects a signal fail=20 > condition is the following; assume a 10G port that detects a=20 > signal fail condition. This implies that all traffic is lost.=20 > Assume that there are 1000 client connections active (e.g.=20 > with an average bandwidth of 5 Mbit/s). When AIS is to be=20 > generated for those 1000 client conenctions the port has to=20 > generate 1000 AIS frames/packets per second. Each AIS=20 > frame/packet is 64 bytes/512 bits. Those 1000 AIS=20 > frames/packets thus generate 512 kbit/s (i.e. 0.0005 > Gbit/s) of traffic in a further empty 10G port. This isn't=20 > any real complexity. >=20 > --------- >=20 > The alternative is to declare that open matrix connections=20 > are never a fault condition (i.e. are always intentional and=20 > thus known by network management). Under such starting point=20 > it is not necessary to detect an open matrix connection as a=20 > fault condition. Now it is not longer necessary to=20 > distinguish between connection interruption due to open=20 > matrix and server layer fault as the first condition isn't a=20 > fault anylonger. Under this condition it is not useful that a=20 > server trail informs its clients about a detected server=20 > trail problem that interrupts the client connections. >=20 > If we go for this latter approach and if in future an open=20 > matrix connection would be a fault condition, then this is a=20 > hidden fault and you need a lot more work to locate the fault=20 > (there are no alarms that help you). >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: dinsdag 28 april 2009 18:20 > To: davarish@yahoo.com; 'Maarten Vissers';=20 > neil.2.harrison@bt.com; nurit.sprecher@nsn.com;=20 > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Shahram, >=20 > I was addressing Neil's comments about the dynamic=20 > re-routing, which is different from protection switchover=20 > onto pre-provisioned protection connection. True, in the=20 > latter case the server layer wouldn't notice that and will=20 > keep notifying the client that the trail is broken. But this=20 > does not change anything. The big 2 questions in my mind are: >=20 > a) Is the OAM of a given layer is (i) self-sufficient and=20 > (ii) scalable enough, so that operator can rely on it=20 > completely and independently from what is happening in the=20 > lower layers? >=20 > b) Is it beneficial if a server trail notifies its clients=20 > about a detected problem to suppress the OAM traffic and=20 > possibly unnecessary switchovers until the server trail=20 > corrects itself? >=20 > Cheers, > Igor >=20 >=20 >=20 > -----Original Message----- > From: Shahram Davari [mailto:davarish@yahoo.com] > Sent: Tuesday, April 28, 2009 11:57 AM > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Igor, >=20 > Your assumption is that there is a control plane that sets up=20 > the binding between client and server layer and that such=20 > binding will be removed via the control plane when a reroute=20 > happens. I think this assumption is not always true. For=20 > example in a linear 1:1 or 1+1 protection, there is no=20 > signalling to withdraw the binding at intermediate nodes. In=20 > 1:1 there is APS, but that is end-to-end and is sent on the=20 > backup path not working path. >=20 > -Shahram >=20 > =20 >=20 > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: April-28-09 11:27 AM > To: davarish@yahoo.com; 'Maarten Vissers';=20 > neil.2.harrison@bt.com; nurit.sprecher@nsn.com;=20 > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Shahram, >=20 > Let's assume that connection A-B-C-D-E is dynamically=20 > provisioned by a control plane. As part of such provisioning=20 > a binding is created between this connection and network C at=20 > the two adaptation points on either side of the link provided=20 > by network C. When the connection is torn down, this binding=20 > is removed as a part of the cleanup process. The re-routing=20 > of the connection onto A-F-G-E is indistinguishable from the=20 > connection tear down as far as link C is concerned. >=20 > Igor >=20 > -----Original Message----- > From: Shahram Davari [mailto:davarish@yahoo.com] > Sent: Tuesday, April 28, 2009 11:15 AM > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Hi Igor, >=20 > How does the server know the client is rerouted? Assume the following > networks: A-B-C-D-E (working) and A-F-G-E (protection).=20 > Assume each has its own server layer such as MPLS, MPLS-TP,=20 > ATM, SONET, etc. Assume that network C uses MPLS-TP as server=20 > layer. Network C will never know there was a protection=20 > switching done for the client layer.=20 >=20 > -Shahram >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin > Sent: April-28-09 11:05 AM > To: Maarten Vissers; neil.2.harrison@bt.com;=20 > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Neil. >=20 > I actually agree with Maarten on this. I don't quite=20 > understand why do you keep talking about fixed client-server=20 > relationship. It is fixed as long as the client layer=20 > connection configured this way (statically or dynamically). > As soon as the connection is re-routed, this relationship is=20 > broken (because this is a part of the re-routing process) and=20 > hence the server trail termination points will know that the=20 > server trail now serves one connection less, whereas some=20 > other server trail(s) will learn that they serve from now on=20 > one connection more. These new client-server relationships=20 > are fixed until the next re-routing. >=20 > Cheers, > Igor=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: Tuesday, April 28, 2009 8:48 AM > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com;=20 > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Neil, >=20 > > However, if the client can dynamically change its routing=20 > in response=20 > > to link failures in its topology (because some server layer network=20 > > has failed....which may or may not belong to the same=20 > operating party=20 > > as the > > client) then there is no fixed client/server relationship.=20 >=20 > I believe there is a fixed client/server relationship also in=20 > this case in the network. This relationship is broken when=20 > the connection is rerouted. > Such reroute will remove the CP/FP and as such will stop the=20 > AIS generation. >=20 > There is no difference with what we do today in SDH and OTN.=20 > A client/server relationship is fixed until the point in time=20 > that the connection is either teardown or rerouted. When=20 > either of the two cases occur, the AIS generation is stopped.=20 > Until such action is performed, AIS is generated during=20 > signal fail condition period and inserted into the connection. >=20 > In MPLS-TP we have the requirement that MPLS-TP must be able=20 > to operate without control plane. This implies that it will=20 > operate without restoration, and that there will not be=20 > frequent rerouteing ongoing. Result is that client/server=20 > relationships will last until the connection is teardown. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com > Sent: dinsdag 28 april 2009 10:07 > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Nurit, >=20 > I believe the reason we need this discussion is that there is=20 > an unstated assumption here that the client/server=20 > relationship is fixed. > However, if the client can dynamically change its routing in=20 > response to link failures in its topology (because some=20 > server layer network has failed....which may or may not=20 > belong to the same operating party as the > client) then there is no fixed client/server relationship. >=20 > Refer to my post earlier today and consider what this means=20 > in the case of a cl-ps IP client layer network or a some=20 > SVC-based co-ps/co-cs mode client layer network. The key=20 > point here is the *routing process* in the client is=20 > independent of the server layer network....so there is not a=20 > fixed client/server relationship. Further, there is also no=20 > requirement for the server to keep track of where its client=20 > traffic routings are at any epoch.....indeed why should it in=20 > the general case where these are independent layer networks? >=20 > So the only OAM requirement that is critical is that the OAM=20 > of the client and server layer networks are independent. It=20 > is thus not sensible to make client layer alarm supression a=20 > 'requirement' here...in fact if this is in the OAM=20 > requirements then it is technically wrong and should be removed IMO. >=20 > regards, Neil=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN -=20 > > IL/Hod HaSharon) > > Sent: 28 April 2009 08:46 > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > >=20 > > If we agree that the requirement is included, so why do we=20 > keep with=20 > > the endless discussions on this requirement? > >=20 > > -----Original Message----- > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Tuesday, April 28, 2009 10:44 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > > Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional transport > > pathrequirements) > >=20 > > I think that the requirements are defined in section 2.2.8 of > > draft-ietf-mpls-tp-oam-requirements-01 > >=20 > > Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN > > > - IL/Hod HaSharon) > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > To: hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > > transport pathrequirements) > > >=20 > > > Huub, > > > I think that the requirement is to provide a mechanism to=20 > suppress=20 > > > alarms in the networks, to ensure that alarms that may be > > generated by > > > client layers as a result of a failure condition in the=20 > server layer=20 > > > may be suppressed. > > > Every thing else is a solution, etc.=20 > > > I propose to phrase the requirement appropriately and=20 > conclude the=20 > > > discussion on this in the context of the requirements=20 > (until we are=20 > > > getting to the solution phase). > > > This requirement is included in the OAM requirement draft.=20 > > > Best regards, > > > NUrit > > >=20 > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On=20 > > > Behalf Of ext Huub van Helvoort > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > To: Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > path requirements) > > >=20 > > > Hi Adrian, > > >=20 > > > You wrote: > > >=20 > > > > Isn't the solution here the same as the one I proposed=20 > for "TCM"? > > >=20 > > > Indeed, and that we do not have to around in circles about TCM. > > >=20 > > > How about: > > > the requirement is that a server layer shall inform its=20 > clients that=20 > > > it has detected a service interuption, this to ensure that the=20 > > > clients can inhibit (unnecessary) alarms. > > >=20 > > > Cheers, Huub. > > >=20 > > > -- > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > http://www.van-helvoort.eu/=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From su.hui@zte.com.cn Tue Apr 28 18:38:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366203A6862; Tue, 28 Apr 2009 18:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xTdlAf7179V; Tue, 28 Apr 2009 18:38:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id BF1643A6B25; Tue, 28 Apr 2009 18:38:08 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641105171106; Wed, 29 Apr 2009 09:28:23 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 47274.7058044864; Wed, 29 Apr 2009 09:35:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3T1cqWG015665; Wed, 29 Apr 2009 09:38:52 +0800 (CST) (envelope-from su.hui@zte.com.cn) In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: su.hui@zte.com.cn Date: Wed, 29 Apr 2009 09:36:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-29 09:38:50, Serialize complete at 2009-04-29 09:38:50 Content-Type: multipart/alternative; boundary="=_alternative 00090ED9482575A7_=" X-MAIL: mse2.zte.com.cn n3T1cqWG015665 Cc: mpls-tp@ietf.org, Italo.Busi@alcatel-lucent.it, mpls-tp-bounces@ietf.org Subject: [mpls-tp] =?gb2312?b?tPC4tDogUmU6ICBBSVMvRkRJICh3YXMgQXNzb2NpYXRl?= =?gb2312?b?ZCBiaWRpcmVjdGlvbmFsCXRyYW5zcG9ydHBhdGhyZXF1aXJlbWVudHMp?= X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 01:38:11 -0000 This is a multipart message in MIME format. --=_alternative 00090ED9482575A7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTmVpbCwNCg0KSSB0aGluayBjbGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcCBpcyBmaXhlZCBp biBjby1jcy9jby1wcy4gb25jZSBhIA0KY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGNs aWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwIHdpbGwgbm90IGNoYW5nZSANCnVudGlsIHRoZSBjb25u ZWN0aW9uIGlzIHRlYXJkb3duLiBzZXJ2ZXIgY2FuIGdldCB0aGUgc2VydmVyL2NsaWVudCANCnJl bGF0aW9uc2hpcCBpbmZvcm1hdGlvbiB3aGVuIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQvdGVh cmRvd24sIHRoZXJlIGlzIA0Kbm8gbmVlZCBvZiBtb3JlIGNvbmZpZ3VyYXRpb24uIA0KDQpSZWdh cmRzLA0KU3VodWkNCg0KDQoNCjxuZWlsLjIuaGFycmlzb25AYnQuY29tPiANCreivP7IyzogIG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0wNC0yOCAxNjowNw0KDQrK1bz+yMsNCjxudXJp dC5zcHJlY2hlckBuc24uY29tPiwgPEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+LCANCjxo aGVsdm9vcnRAY2hlbGxvLm5sPiwgPGFkcmlhbkBvbGRkb2cuY28udWs+DQqzrcvNDQptcGxzLXRw QGlldGYub3JnDQrW98ziDQpSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgDQp0cmFuc3BvcnRwYXRocmVxdWlyZW1lbnRzKQ0KDQoNCg0KDQoNCg0KTnVy aXQsDQoNCkkgYmVsaWV2ZSB0aGUgcmVhc29uIHdlIG5lZWQgdGhpcyBkaXNjdXNzaW9uIGlzIHRo YXQgdGhlcmUgaXMgYW4NCnVuc3RhdGVkIGFzc3VtcHRpb24gaGVyZSB0aGF0IHRoZSBjbGllbnQv c2VydmVyIHJlbGF0aW9uc2hpcCBpcyBmaXhlZC4NCkhvd2V2ZXIsIGlmIHRoZSBjbGllbnQgY2Fu IGR5bmFtaWNhbGx5IGNoYW5nZSBpdHMgcm91dGluZyBpbiByZXNwb25zZSB0bw0KbGluayBmYWls dXJlcyBpbiBpdHMgdG9wb2xvZ3kgKGJlY2F1c2Ugc29tZSBzZXJ2ZXIgbGF5ZXIgbmV0d29yayBo YXMNCmZhaWxlZC4uLi53aGljaCBtYXkgb3IgbWF5IG5vdCBiZWxvbmcgdG8gdGhlIHNhbWUgb3Bl cmF0aW5nIHBhcnR5IGFzIHRoZQ0KY2xpZW50KSB0aGVuIHRoZXJlIGlzIG5vIGZpeGVkIGNsaWVu dC9zZXJ2ZXIgcmVsYXRpb25zaGlwLg0KDQpSZWZlciB0byBteSBwb3N0IGVhcmxpZXIgdG9kYXkg YW5kIGNvbnNpZGVyIHdoYXQgdGhpcyBtZWFucyBpbiB0aGUgY2FzZQ0Kb2YgYSBjbC1wcyBJUCBj bGllbnQgbGF5ZXIgbmV0d29yayBvciBhIHNvbWUgU1ZDLWJhc2VkIGNvLXBzL2NvLWNzIG1vZGUN CmNsaWVudCBsYXllciBuZXR3b3JrLiAgVGhlIGtleSBwb2ludCBoZXJlIGlzIHRoZSAqcm91dGlu ZyBwcm9jZXNzKiBpbg0KdGhlIGNsaWVudCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgc2VydmVyIGxh eWVyIG5ldHdvcmsuLi4uc28gdGhlcmUgaXMgbm90DQphIGZpeGVkIGNsaWVudC9zZXJ2ZXIgcmVs YXRpb25zaGlwLiAgRnVydGhlciwgdGhlcmUgaXMgYWxzbyBubw0KcmVxdWlyZW1lbnQgZm9yIHRo ZSBzZXJ2ZXIgdG8ga2VlcCB0cmFjayBvZiB3aGVyZSBpdHMgY2xpZW50IHRyYWZmaWMNCnJvdXRp bmdzIGFyZSBhdCBhbnkgZXBvY2guLi4uLmluZGVlZCB3aHkgc2hvdWxkIGl0IGluIHRoZSBnZW5l cmFsIGNhc2UNCndoZXJlIHRoZXNlIGFyZSBpbmRlcGVuZGVudCBsYXllciBuZXR3b3Jrcz8NCg0K U28gdGhlIG9ubHkgT0FNIHJlcXVpcmVtZW50IHRoYXQgaXMgY3JpdGljYWwgaXMgdGhhdCB0aGUg T0FNIG9mIHRoZQ0KY2xpZW50IGFuZCBzZXJ2ZXIgbGF5ZXIgbmV0d29ya3MgYXJlIGluZGVwZW5k ZW50LiAgSXQgaXMgdGh1cyBub3QNCnNlbnNpYmxlIHRvIG1ha2UgY2xpZW50IGxheWVyIGFsYXJt IHN1cHJlc3Npb24gYSAncmVxdWlyZW1lbnQnIGhlcmUuLi5pbg0KZmFjdCBpZiB0aGlzIGlzIGlu IHRoZSBPQU0gcmVxdWlyZW1lbnRzIHRoZW4gaXQgaXMgdGVjaG5pY2FsbHkgd3JvbmcgYW5kDQpz aG91bGQgYmUgcmVtb3ZlZCBJTU8uDQoNCnJlZ2FyZHMsIE5laWwgDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCj4gW21haWx0 bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcHJlY2hlciwgDQo+IE51 cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pDQo+IFNlbnQ6IDI4IEFwcmlsIDIwMDkgMDg6NDYN Cj4gVG86IGV4dCBCVVNJIElUQUxPOyBoaGVsdm9vcnRAY2hlbGxvLm5sOyBBZHJpYW4gRmFycmVs DQo+IENjOiBtcGxzLXRwQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gQUlTL0ZE SSAod2FzIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCANCj4gdHJhbnNwb3J0cGF0aHJlcXVpcmVt ZW50cykNCj4gDQo+IElmIHdlIGFncmVlIHRoYXQgdGhlIHJlcXVpcmVtZW50IGlzIGluY2x1ZGVk LCBzbyB3aHkgZG8gd2UgDQo+IGtlZXAgd2l0aCB0aGUNCj4gZW5kbGVzcyBkaXNjdXNzaW9ucyBv biB0aGlzIHJlcXVpcmVtZW50Pw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogZXh0IEJVU0kgSVRBTE8gW21haWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0 XSANCj4gU2VudDogVHVlc2RheSwgQXByaWwgMjgsIDIwMDkgMTA6NDQgQU0NCj4gVG86IFNwcmVj aGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgDQo+IGhoZWx2b29ydEBjaGVsbG8u bmw7IEFkcmlhbg0KPiBGYXJyZWwNCj4gQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCj4gU3ViamVjdDog UkU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydA0KPiBwYXRocmVxdWlyZW1lbnRzKQ0KPiANCj4gSSB0aGluayB0aGF0IHRoZSByZXF1aXJl bWVudHMgYXJlIGRlZmluZWQgaW4gc2VjdGlvbiAyLjIuOCBvZg0KPiBkcmFmdC1pZXRmLW1wbHMt dHAtb2FtLXJlcXVpcmVtZW50cy0wMQ0KPiANCj4gSXRhbG8NCj4gDQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQo+ID4g W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcHJlY2hlciwg DQo+ID4gTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikNCj4gPiBTZW50OiBUdWVzZGF5LCBB cHJpbCAyOCwgMjAwOSA2OjU2IEFNDQo+ID4gVG86IGhoZWx2b29ydEBjaGVsbG8ubmw7IEFkcmlh biBGYXJyZWwNCj4gPiBDYzogbXBscy10cEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbXBs cy10cF0gQUlTL0ZESSAod2FzIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCANCj4gPiB0cmFuc3Bv cnQgcGF0aHJlcXVpcmVtZW50cykNCj4gPiANCj4gPiBIdXViLA0KPiA+IEkgdGhpbmsgdGhhdCB0 aGUgcmVxdWlyZW1lbnQgaXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBzdXBwcmVzcw0KPiA+ IGFsYXJtcyBpbiB0aGUgbmV0d29ya3MsIHRvIGVuc3VyZSB0aGF0IGFsYXJtcyB0aGF0IG1heSBi ZSANCj4gZ2VuZXJhdGVkIGJ5DQo+ID4gY2xpZW50IGxheWVycyBhcyBhIHJlc3VsdCBvZiBhIGZh aWx1cmUgY29uZGl0aW9uIGluIHRoZSANCj4gPiBzZXJ2ZXIgbGF5ZXIgbWF5DQo+ID4gYmUgc3Vw cHJlc3NlZC4NCj4gPiBFdmVyeSB0aGluZyBlbHNlIGlzIGEgc29sdXRpb24sIGV0Yy4gDQo+ID4g SSBwcm9wb3NlIHRvIHBocmFzZSB0aGUgcmVxdWlyZW1lbnQgYXBwcm9wcmlhdGVseSBhbmQgY29u Y2x1ZGUgdGhlDQo+ID4gZGlzY3Vzc2lvbiBvbiB0aGlzIGluIHRoZSBjb250ZXh0IG9mIHRoZSBy ZXF1aXJlbWVudHMgKHVudGlsIHdlIGFyZQ0KPiA+IGdldHRpbmcgdG8gdGhlIHNvbHV0aW9uIHBo YXNlKS4gDQo+ID4gVGhpcyByZXF1aXJlbWVudCBpcyBpbmNsdWRlZCBpbiB0aGUgT0FNIHJlcXVp cmVtZW50IGRyYWZ0LiANCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gTlVyaXQNCj4gPiANCj4gPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhh bGYgT2YgZXh0IEh1dWIgdmFuIEhlbHZvb3J0DQo+ID4gU2VudDogVHVlc2RheSwgQXByaWwgMjgs IDIwMDkgMTI6MjcgQU0NCj4gPiBUbzogQWRyaWFuIEZhcnJlbA0KPiA+IENjOiBtcGxzLXRwQGll dGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRl ZCANCj4gYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQNCj4gPiBwYXRoIHJlcXVpcmVtZW50cykNCj4g PiANCj4gPiBIaSBBZHJpYW4sDQo+ID4gDQo+ID4gWW91IHdyb3RlOg0KPiA+IA0KPiA+ID4gSXNu J3QgdGhlIHNvbHV0aW9uIGhlcmUgdGhlIHNhbWUgYXMgdGhlIG9uZSBJIHByb3Bvc2VkIGZvciAi VENNIj8NCj4gPiANCj4gPiBJbmRlZWQsIGFuZCB0aGF0IHdlIGRvIG5vdCBoYXZlIHRvIGFyb3Vu ZCBpbiBjaXJjbGVzIGFib3V0IFRDTS4NCj4gPiANCj4gPiBIb3cgYWJvdXQ6DQo+ID4gdGhlIHJl cXVpcmVtZW50IGlzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXIgc2hhbGwgaW5mb3JtIGl0cyBjbGllbnRz DQo+ID4gdGhhdCBpdCBoYXMgZGV0ZWN0ZWQgYSBzZXJ2aWNlIGludGVydXB0aW9uLCB0aGlzIHRv IGVuc3VyZSB0aGF0DQo+ID4gdGhlIGNsaWVudHMgY2FuIGluaGliaXQgKHVubmVjZXNzYXJ5KSBh bGFybXMuDQo+ID4gDQo+ID4gQ2hlZXJzLCBIdXViLg0KPiA+IA0KPiA+IC0tIA0KPiA+ID09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCj4gPiAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy52YW4taGVsdm9vcnQuZXUvDQo+ ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KPiA+IEFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVlLi4uanVz dCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IG1wbHMtdHAgbWFpbGluZyBsaXN0DQo+ID4gbXBscy10 cEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzLXRwQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQo+ID4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFp bGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwDQo+IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 00090ED9482575A7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE5laWwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIDwvZm9udD48Zm9u dCBzaXplPTI+PHR0PmNsaWVudC9zZXJ2ZXINCnJlbGF0aW9uc2hpcCBpcyBmaXhlZDwvdHQ+PC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4gaW4gY28tY3MvY28tcHMuDQpvbmNl IGEgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25z aGlwIHdpbGwgbm90DQpjaGFuZ2UgdW50aWwgdGhlIGNvbm5lY3Rpb24gaXMgdGVhcmRvd24uIHNl cnZlciBjYW4gZ2V0IHRoZSBzZXJ2ZXIvY2xpZW50DQpyZWxhdGlvbnNoaXAgaW5mb3JtYXRpb24g d2hlbiBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVkL3RlYXJkb3duLCB0aGVyZQ0KaXMgbm8gbmVl ZCBvZiBtb3JlIGNvbmZpZ3VyYXRpb24uIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlN1aHVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjxiPiZsdDtuZWlsLjIuaGFycmlzb25AYnQuY29tJmd0OzwvYj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxz LXRwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAwOS0wNC0yOCAxNjowNzwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7bnVyaXQuc3ByZWNoZXJAbnNuLmNvbSZndDssICZs dDtJdGFsby5CdXNpQGFsY2F0ZWwtbHVjZW50Lml0Jmd0OywNCiZsdDtoaGVsdm9vcnRAY2hlbGxv Lm5sJmd0OywgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5t cGxzLXRwQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW21wbHMtdHBdIEFJUy9GREkg KHdhcyBBc3NvY2lhdGVkDQpiaWRpcmVjdGlvbmFsICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3RyYW5zcG9ydHBhdGhyZXF1aXJlbWVudHMpPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5OdXJpdCw8YnI+DQo8YnI+DQpJIGJlbGlldmUg dGhlIHJlYXNvbiB3ZSBuZWVkIHRoaXMgZGlzY3Vzc2lvbiBpcyB0aGF0IHRoZXJlIGlzIGFuPGJy Pg0KdW5zdGF0ZWQgYXNzdW1wdGlvbiBoZXJlIHRoYXQgdGhlIGNsaWVudC9zZXJ2ZXIgcmVsYXRp b25zaGlwIGlzIGZpeGVkLjxicj4NCkhvd2V2ZXIsIGlmIHRoZSBjbGllbnQgY2FuIGR5bmFtaWNh bGx5IGNoYW5nZSBpdHMgcm91dGluZyBpbiByZXNwb25zZSB0bzxicj4NCmxpbmsgZmFpbHVyZXMg aW4gaXRzIHRvcG9sb2d5IChiZWNhdXNlIHNvbWUgc2VydmVyIGxheWVyIG5ldHdvcmsgaGFzPGJy Pg0KZmFpbGVkLi4uLndoaWNoIG1heSBvciBtYXkgbm90IGJlbG9uZyB0byB0aGUgc2FtZSBvcGVy YXRpbmcgcGFydHkgYXMgdGhlPGJyPg0KY2xpZW50KSB0aGVuIHRoZXJlIGlzIG5vIGZpeGVkIGNs aWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwLjxicj4NCjxicj4NClJlZmVyIHRvIG15IHBvc3QgZWFy bGllciB0b2RheSBhbmQgY29uc2lkZXIgd2hhdCB0aGlzIG1lYW5zIGluIHRoZSBjYXNlPGJyPg0K b2YgYSBjbC1wcyBJUCBjbGllbnQgbGF5ZXIgbmV0d29yayBvciBhIHNvbWUgU1ZDLWJhc2VkIGNv LXBzL2NvLWNzIG1vZGU8YnI+DQpjbGllbnQgbGF5ZXIgbmV0d29yay4gJm5ic3A7VGhlIGtleSBw b2ludCBoZXJlIGlzIHRoZSAqcm91dGluZyBwcm9jZXNzKg0KaW48YnI+DQp0aGUgY2xpZW50IGlz IGluZGVwZW5kZW50IG9mIHRoZSBzZXJ2ZXIgbGF5ZXIgbmV0d29yay4uLi5zbyB0aGVyZSBpcyBu b3Q8YnI+DQphIGZpeGVkIGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwLiAmbmJzcDtGdXJ0aGVy LCB0aGVyZSBpcyBhbHNvIG5vPGJyPg0KcmVxdWlyZW1lbnQgZm9yIHRoZSBzZXJ2ZXIgdG8ga2Vl cCB0cmFjayBvZiB3aGVyZSBpdHMgY2xpZW50IHRyYWZmaWM8YnI+DQpyb3V0aW5ncyBhcmUgYXQg YW55IGVwb2NoLi4uLi5pbmRlZWQgd2h5IHNob3VsZCBpdCBpbiB0aGUgZ2VuZXJhbCBjYXNlPGJy Pg0Kd2hlcmUgdGhlc2UgYXJlIGluZGVwZW5kZW50IGxheWVyIG5ldHdvcmtzPzxicj4NCjxicj4N ClNvIHRoZSBvbmx5IE9BTSByZXF1aXJlbWVudCB0aGF0IGlzIGNyaXRpY2FsIGlzIHRoYXQgdGhl IE9BTSBvZiB0aGU8YnI+DQpjbGllbnQgYW5kIHNlcnZlciBsYXllciBuZXR3b3JrcyBhcmUgaW5k ZXBlbmRlbnQuICZuYnNwO0l0IGlzIHRodXMgbm90PGJyPg0Kc2Vuc2libGUgdG8gbWFrZSBjbGll bnQgbGF5ZXIgYWxhcm0gc3VwcmVzc2lvbiBhICdyZXF1aXJlbWVudCcgaGVyZS4uLmluPGJyPg0K ZmFjdCBpZiB0aGlzIGlzIGluIHRoZSBPQU0gcmVxdWlyZW1lbnRzIHRoZW4gaXQgaXMgdGVjaG5p Y2FsbHkgd3JvbmcgYW5kPGJyPg0Kc2hvdWxkIGJlIHJlbW92ZWQgSU1PLjxicj4NCjxicj4NCnJl Z2FyZHMsIE5laWwgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIDxicj4NCiZndDsgW21haWx0bzptcGxz LXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcHJlY2hlciwgPGJyPg0KJmd0OyBO dXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTxicj4NCiZndDsgU2VudDogMjggQXByaWwgMjAw OSAwODo0Njxicj4NCiZndDsgVG86IGV4dCBCVVNJIElUQUxPOyBoaGVsdm9vcnRAY2hlbGxvLm5s OyBBZHJpYW4gRmFycmVsPGJyPg0KJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxicj4NCiZndDsg U3ViamVjdDogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIDxicj4NCiZndDsgdHJhbnNwb3J0cGF0aHJlcXVpcmVtZW50cyk8YnI+DQomZ3Q7IDxicj4N CiZndDsgSWYgd2UgYWdyZWUgdGhhdCB0aGUgcmVxdWlyZW1lbnQgaXMgaW5jbHVkZWQsIHNvIHdo eSBkbyB3ZSA8YnI+DQomZ3Q7IGtlZXAgd2l0aCB0aGU8YnI+DQomZ3Q7IGVuZGxlc3MgZGlzY3Vz c2lvbnMgb24gdGhpcyByZXF1aXJlbWVudD88YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IGV4dCBCVVNJIElUQUxPIFttYWlsdG86 SXRhbG8uQnVzaUBhbGNhdGVsLWx1Y2VudC5pdF0gPGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBB cHJpbCAyOCwgMjAwOSAxMDo0NCBBTTxicj4NCiZndDsgVG86IFNwcmVjaGVyLCBOdXJpdCAoTlNO IC0gSUwvSG9kIEhhU2hhcm9uKTsgPGJyPg0KJmd0OyBoaGVsdm9vcnRAY2hlbGxvLm5sOyBBZHJp YW48YnI+DQomZ3Q7IEZhcnJlbDxicj4NCiZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQom Z3Q7IFN1YmplY3Q6IFJFOiBbbXBscy10cF0gQUlTL0ZESSAod2FzIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQ8YnI+DQomZ3Q7IHBhdGhyZXF1aXJlbWVudHMpPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEkgdGhpbmsgdGhhdCB0aGUgcmVxdWlyZW1lbnRzIGFyZSBkZWZpbmVkIGluIHNl Y3Rpb24gMi4yLjggb2Y8YnI+DQomZ3Q7IGRyYWZ0LWlldGYtbXBscy10cC1vYW0tcmVxdWlyZW1l bnRzLTAxPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0YWxvPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogbXBscy10 cC1ib3VuY2VzQGlldGYub3JnIDxicj4NCiZndDsgJmd0OyBbbWFpbHRvOm1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNwcmVjaGVyLCA8YnI+DQomZ3Q7ICZndDsgTnVyaXQg KE5TTiAtIElML0hvZCBIYVNoYXJvbik8YnI+DQomZ3Q7ICZndDsgU2VudDogVHVlc2RheSwgQXBy aWwgMjgsIDIwMDkgNjo1NiBBTTxicj4NCiZndDsgJmd0OyBUbzogaGhlbHZvb3J0QGNoZWxsby5u bDsgQWRyaWFuIEZhcnJlbDxicj4NCiZndDsgJmd0OyBDYzogbXBscy10cEBpZXRmLm9yZzxicj4N CiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwNCjxicj4NCiZndDsgJmd0OyB0cmFuc3BvcnQgcGF0aHJlcXVpcmVtZW50 cyk8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEh1dWIsPGJyPg0KJmd0OyAmZ3Q7IEkg dGhpbmsgdGhhdCB0aGUgcmVxdWlyZW1lbnQgaXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBz dXBwcmVzczxicj4NCiZndDsgJmd0OyBhbGFybXMgaW4gdGhlIG5ldHdvcmtzLCB0byBlbnN1cmUg dGhhdCBhbGFybXMgdGhhdCBtYXkgYmUgPGJyPg0KJmd0OyBnZW5lcmF0ZWQgYnk8YnI+DQomZ3Q7 ICZndDsgY2xpZW50IGxheWVycyBhcyBhIHJlc3VsdCBvZiBhIGZhaWx1cmUgY29uZGl0aW9uIGlu IHRoZSA8YnI+DQomZ3Q7ICZndDsgc2VydmVyIGxheWVyIG1heTxicj4NCiZndDsgJmd0OyBiZSBz dXBwcmVzc2VkLjxicj4NCiZndDsgJmd0OyBFdmVyeSB0aGluZyBlbHNlIGlzIGEgc29sdXRpb24s IGV0Yy4gPGJyPg0KJmd0OyAmZ3Q7IEkgcHJvcG9zZSB0byBwaHJhc2UgdGhlIHJlcXVpcmVtZW50 IGFwcHJvcHJpYXRlbHkgYW5kIGNvbmNsdWRlDQp0aGU8YnI+DQomZ3Q7ICZndDsgZGlzY3Vzc2lv biBvbiB0aGlzIGluIHRoZSBjb250ZXh0IG9mIHRoZSByZXF1aXJlbWVudHMgKHVudGlsDQp3ZSBh cmU8YnI+DQomZ3Q7ICZndDsgZ2V0dGluZyB0byB0aGUgc29sdXRpb24gcGhhc2UpLiA8YnI+DQom Z3Q7ICZndDsgVGhpcyByZXF1aXJlbWVudCBpcyBpbmNsdWRlZCBpbiB0aGUgT0FNIHJlcXVpcmVt ZW50IGRyYWZ0LiA8YnI+DQomZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgJmd0OyBO VXJpdDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IG1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10NCk9uPGJyPg0KJmd0 OyAmZ3Q7IEJlaGFsZiBPZiBleHQgSHV1YiB2YW4gSGVsdm9vcnQ8YnI+DQomZ3Q7ICZndDsgU2Vu dDogVHVlc2RheSwgQXByaWwgMjgsIDIwMDkgMTI6MjcgQU08YnI+DQomZ3Q7ICZndDsgVG86IEFk cmlhbiBGYXJyZWw8YnI+DQomZ3Q7ICZndDsgQ2M6IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7 ICZndDsgU3ViamVjdDogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCA8YnI+ DQomZ3Q7IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0PGJyPg0KJmd0OyAmZ3Q7IHBhdGggcmVxdWly ZW1lbnRzKTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSGkgQWRyaWFuLDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgWW91IHdyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyBJc24ndCB0aGUgc29sdXRpb24gaGVyZSB0aGUgc2FtZSBhcyB0aGUgb25l IEkgcHJvcG9zZWQgZm9yDQomcXVvdDtUQ00mcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBJbmRlZWQsIGFuZCB0aGF0IHdlIGRvIG5vdCBoYXZlIHRvIGFyb3VuZCBpbiBjaXJj bGVzIGFib3V0IFRDTS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhvdyBhYm91dDo8 YnI+DQomZ3Q7ICZndDsgdGhlIHJlcXVpcmVtZW50IGlzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXIgc2hh bGwgaW5mb3JtIGl0cyBjbGllbnRzPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgaXQgaGFzIGRldGVjdGVk IGEgc2VydmljZSBpbnRlcnVwdGlvbiwgdGhpcyB0byBlbnN1cmUgdGhhdDxicj4NCiZndDsgJmd0 OyB0aGUgY2xpZW50cyBjYW4gaW5oaWJpdCAodW5uZWNlc3NhcnkpIGFsYXJtcy48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IENoZWVycywgSHV1Yi48YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsgJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDtodHRwOi8vd3d3LnZhbi1oZWx2b29ydC5ldS88YnI+DQomZ3Q7ICZndDsgPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiZndDsgJmd0OyBBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3UgYXJlIHVuaXF1ZS4uLmp1 c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IG1wbHMtdHAgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KJmd0OyAm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyAmZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IG1wbHMtdHBAaWV0 Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzLXRwPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1wbHMtdHAgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyBtcGxzLXRwQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8YnI+DQomZ3Q7IDxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscy10cCBtYWlsaW5nIGxp c3Q8YnI+DQptcGxzLXRwQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzLXRwPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZu YnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFp bCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJz cDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDtt YWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJt aXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtv ZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlz Jm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVk Jm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5i c3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5i c3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5 b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZu YnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRv ciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNw O2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0 aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMm bmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJz cDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1T cGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00090ED9482575A7_=-- From su.hui@zte.com.cn Tue Apr 28 19:23:02 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9713A3A6D15; Tue, 28 Apr 2009 19:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.19 X-Spam-Level: X-Spam-Status: No, score=-92.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4oR+89yZnm5; Tue, 28 Apr 2009 19:23:01 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 6C7CB3A6D02; Tue, 28 Apr 2009 19:23:00 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101105171106; Wed, 29 Apr 2009 10:16:31 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.5514055519; Wed, 29 Apr 2009 10:20:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3T2OH4r095000; Wed, 29 Apr 2009 10:24:17 +0800 (CST) (envelope-from su.hui@zte.com.cn) In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0479DBB6@E03MVB2-UKBR.domain1.systemhost.net> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: su.hui@zte.com.cn Date: Wed, 29 Apr 2009 10:22:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-29 10:24:15, Serialize complete at 2009-04-29 10:24:15 Content-Type: multipart/alternative; boundary="=_alternative 000D372B482575A7_=" X-MAIL: mse1.zte.com.cn n3T2OH4r095000 Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: [mpls-tp] =?gb2312?b?tPC4tDogUmU6ICBBSVMvRkRJICh3YXMgQXNzb2NpYXRl?= =?gb2312?b?ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoCXJlcXVpcmVtZW50cyk=?= X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 02:23:02 -0000 This is a multipart message in MIME format. --=_alternative 000D372B482575A7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTmVpbCwNCg0Koa5pdCBpcyBxdWl0ZSBjbGVhciBmcm9tIGEgc2ltcGxlIHRlY2huaWNhbCBh bmFseXNpcyB0aGF0IGFueSBub24gDQp0b3Atb2Ytc3RhY2sgbmV0d29yayBoYXMgbm8gbmVlZCBm b3IgRS1OTkkgcGVlci1wYXJ0aXRpb24gd29ya2luZyBiZXR3ZWVuIA0KZGlmZmVyZW50IG9wZXJh dGluZyBwYXJ0aWVzLqGvDQoNCkkgY2Fubm90IGFncmVlIHRoaXMgc3RhdGVtZW50LiANCkZvciBl eGFtcGxlLCB0aGVyZSBhcmUgdHdvIElQIG5ldHdvcmtzIGJlbG9uZ2luZyB0byB0d28gb3BlcmF0 b3JzLCBhIEUxIGlzIA0KdHJhbnNwb3J0ZWQgZnJvbSBBIG5ldHdvcmsgdG8gQiBuZXR3b3JrIChl LmcuIEUxb3ZlclBXb3ZlcklQICksIElQIA0KcGFja2V0KG5vdCBFMSkgcGFzcyBhY3Jvc3MgZm9y bSBBIHRvIEIgYXQgYm9yZGVyIG5vZGUsIHNvIHRoZXJlIGlzIGEgRS1OTkkgDQpiZXR3ZWVuIHRo ZXNlICB0d28gSVAgbmV0d29yay4gSW4gdGhpcyBjYXNlLCBpcyBJUCBhIHRvcC1vZi1zdGFjayBu ZXR3b3JrPw0KTm93IGxldCB1cyByZXBsYWNlIElQIG5ldHdvcmtzIGJ5IE1QTFMtVFAgbmV0d29y a3MgKGUuZy4gDQpFMW92ZXJQV292ZXJNUEwtVFApLCBNUExTLVRQIG5ldHdvcmsgaXMgYXQgc2Ft ZSBwb3NpdGlvbiBpbiB0aGUgc3RhY2sgYXMgDQpJUCBuZXR3b3JrIGlzLCB3aHkgY2FuIElQIG5l dHdvcmsgaGF2ZSBFLU5OSSBidXQgTVBMUy1UUCBjYW5ub3Q/DQoNClJlZ2FyZCwNClN1aHVpDQoN Cg0KDQo8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbT4gDQq3orz+yMs6ICBtcGxzLXRwLWJvdW5jZXNA aWV0Zi5vcmcNCjIwMDktMDQtMjggMTQ6NDMNCg0KytW8/sjLDQo8aGhlbHZvb3J0QGNoZWxsby5u bD4sIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiwgDQo8YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5j b20+DQqzrcvNDQptcGxzLXRwQGlldGYub3JnDQrW98ziDQpSZTogW21wbHMtdHBdIEFJUy9GREkg KHdhcyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQpyZXF1aXJlbWVu dHMpDQoNCg0KDQoNCg0KDQpIdXViIHdyb3RlIDI3IEFwcmlsIDIwMDkgMjI6MjcNCj4gDQo+IEhp IEFkcmlhbiwNCj4gDQo+IFlvdSB3cm90ZToNCj4gDQo+ID4gSXNuJ3QgdGhlIHNvbHV0aW9uIGhl cmUgdGhlIHNhbWUgYXMgdGhlIG9uZSBJIHByb3Bvc2VkIGZvciAiVENNIj8NCj4gDQo+IEluZGVl ZCwgYW5kIHRoYXQgd2UgZG8gbm90IGhhdmUgdG8gYXJvdW5kIGluIGNpcmNsZXMgYWJvdXQgVENN Lg0KPiANCj4gSG93IGFib3V0Og0KPiB0aGUgcmVxdWlyZW1lbnQgaXMgdGhhdCBhIHNlcnZlciBs YXllciBzaGFsbCBpbmZvcm0gaXRzIGNsaWVudHMNCj4gdGhhdCBpdCBoYXMgZGV0ZWN0ZWQgYSBz ZXJ2aWNlIGludGVydXB0aW9uLCB0aGlzIHRvIGVuc3VyZSB0aGF0DQo+IHRoZSBjbGllbnRzIGNh biBpbmhpYml0ICh1bm5lY2Vzc2FyeSkgYWxhcm1zLg0KDQpOSD0+IFRoaXMgb25seSBhcHBsaWVz IGlmIHRoZSBjbGllbnQvc2VydmVyIGJpbmRpbmcgaXMgZml4ZWQuICBBbmQgb2YNCmNvdXJzZSB3 YXkgYmFjayBpbiB0aGUgNzBzIHdoZW4gYmluYXJ5IGFsbCAxcyBwb3BwZWQgb3V0IG9mIHRoZSBm YWlsZWQNClRUTCBsb2dpYyBpbnRvIHRoZSBQREggdHJhbnNwb3J0IGhpZXJhcmNoeSB0aGlzIHdh cyB0cnVlLiAgQWxzbzogbm8NCmxhYmVscyBoZXJlIGFuZCBubyBjbGllbnQgdHJhZmZpYyB1bml0 cyB0byBjcmVhdGUuIA0KDQpXaGVyZSB0aGUgY2xpZW50IGNhbiBkeW5hbWljYWxseSBiZSByZS1y b3V0ZWQgaW4gcmVzcG9uc2UgdG8gYSBzZXJ2ZXINCmZhaWx1cmUgdGhlIHByb3Bvc2VkIHRleHQg aXMgbm90IHZhbGlkLiAgSXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRoYXQNCnRoZSBzZXJ2ZXIg aGFzIHRvIGtlZXAgdHJhY2sgb2Ygd2hlcmUgaXRzIGNsaWVudCB0cmFmZmljIHJvdXRpbmdzIGhh dmUNCm1vdmVkIHRvLiAgRm9yIGV4YW1wbGUsIGlmIEkgY3JlYXRlIHRoZSB0b3BvbG9neSBvZiBh biBJUCBsYXllciBuZXR3b3JrDQp3aXRoIGxpbmtzIHByb3ZpZGVkIGJ5IFNESCwgRXRoZXJuZXQs IEFUTSwgT1ROLCBldGMgc2VydmVycywgYW5kIGVhY2ggb2YNCnRoZXNlIHNlcnZlciBsaW5rcyBp cyBwcm92aWRlZCBieSBhIGRpZmZlcmVudCBvcGVyYXRvciwgdGhlbiB3aHkgc2hvdWxkDQp0aGUg c2VydmVycyBuZWVkIGhhdmUga25vd2xlZGdlIG9mIHdoZXJlIHRoZSBJUCBmbG93cyBoYXZlIG1v dmVkIHRvIGluDQpyZXNwb25zZSB0byBhIHNlcnZlciBsYXllciBmYWlsdXJlIHdoZW4gdGhlIG5l dyByb3V0ZXMgaGF2ZSBiZWVuDQpjYWxjdWxhdGVkIGJ5IHRoZSBJR1AgaW4gdGhlIElQIGxheWVy IG5ldHdvcms/ICBJIGNhbiBhcHBseSB0aGUgc2FtZQ0KbG9naWMgdG8gYW4gU1ZDLWJhc2VkIGNv LXBzL2NvLWNzIG1vZGUgY2xpZW50Li4uLmluZGVlZCB0aGUgY28tY3MgbW9kZQ0KUFNUTiBpcyBs aWtlIHRoaXMuDQoNClRoZXNlIG9ic2VydmF0aW9ucyBtYWtlIGl0IHF1aXRlIGNsZWFyIHRvIG1l IGF0IGxlYXN0IHRoYXQganVzdCBjb3B5aW5nDQp0aGUgQUlTIGJlaGF2aW91ciBvZiB0aGUgb2xk IHRyYW5zcG9ydCBoaWVyYXJjaGllcyB0aGF0IGhhZCBmaXhlZA0KY2xpZW50L3NlcnZlciByZWxh dGlvbnNoaXBzIGlzIG5vdCBhIHNlbnNpYmxlIHRoaW5nIHRvIGRvLg0KDQpJTU8gdGhlIG9ubHkg ZXNzZW50aWFsIERQIE9BTSByZXF1aXJlbWVudCBpcyB0aGF0IGVhY2ggbGF5ZXIgbmV0d29yaw0K c2hvdWxkIGJlIHNlbGYtc3VmZmljaWVudCB3cnQgT0FNIGFuZCBub3QgcmVseSBvbiBhbnkgc2Vy dmVyIGxheWVyDQpwcmltaXRpdmVzIGJlaW5nIHBhc3NlZCB1cHdhcmRzLg0KDQpNb3Jlb3Zlciwg aXQgc2hvdWxkIGFsc28gYmUgbm90ZWQgdGhhdCAoaSkgdGhlIGRlZmVjdHMgdGhhdCBjYW4gb2Nj dXIgaW4NCmVhY2ggb2YgdGhlIDMgbmV0d29yayBtb2RlcyBhcmUgbm90IHRoZSBzYW1lIGFuZCAo aWkpIHRoZWlyIE9BTQ0KcmVxdWlyZW1lbnRzIGFyZSBub3QgaWRlbnRpY2FsbHkgdGhlIHNhbWUu IFNvIHRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvDQp0aGUgY2wtcHMgbW9kZSAoZWcgSVApIGlzIG5v dCB0aGUgc2FtZSBhcyB0aGUgT0FNIHRoYXQgYXBwbGllcyB0byB0aGUNCmNvLXBzIG1vZGUgKGVn IE1QTFMtVFApIGFuZCBuZWl0aGVyIG9mIHRoZXNlIGlzIGlkZW50aWNhbGx5IHRoZSBzYW1lIGFz DQp0aGUgT0FNIHRoYXQgYXBwbGllcyB0byB0aGUgY28tY3MgbW9kZSAoZWcgU0RIKS4NCg0KTm90 ZSAtIFRoZSBvbmx5IHBvaW50IGJlaW5nIGNvbnNpZGVyZWQgaGVyZSBpcyB0aGUgcmVhbCBjbGll bnQgYW5kDQpzZXJ2ZXIgdHJhZmZpYyByZWxhdGlvbnNoaXAuICBUaGUgY3JlYXRpb24gb2YgYSBo aWVyYXJjaHkgb2YgVENNDQpzdWJsYXllcnMgaXMgYSBzZXBhcmF0ZSB0b3BpYy4gIEZ1cnRoZXIs IGl0IGlzIHF1aXRlIGNsZWFyIGZyb20gYSBzaW1wbGUNCnRlY2huaWNhbCBhbmFseXNpcyB0aGF0 IGFueSBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5vIG5lZWQgZm9yDQpFLU5OSSBwZWVy LXBhcnRpdGlvbiB3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50IG9wZXJhdGluZyBwYXJ0aWVzLiAg U28NCnRoaXMgaXMgYWxzbyBhIHNlcGFyYXRlIGlzc3VlLiAgSG93ZXZlciwgSSBwcm9wb3NlIHRo YXQgdGhpcyBsYXR0ZXINCnBvaW50IGJlIGNhcHR1cmVkIGluIHRoZSBNUExTLVRQIHJlcXVpcmVt ZW50cyBkcmFmdCBkdWUgdG8gaXRzDQpzdGFuZC1hbG9uZSBhbmQgZ2VuZXJpYyBpbXBvcnRhbmNl LCBpZSB0aGlzIGFwcGxpZXMgdG8gbW9yZSB0aGFuIGp1c3QgRFANCk9BTS4gIEJlbiBjYW4geW91 IHBsZWFzZSBjb25zaWRlciB0aGlzIHBvaW50IGFzL3doZW4gdGhlIE1QTFMtVFANCnJlcXVpcmVt ZW50cyBkcmFmdCBpcyB1cGRhdGVkLg0KDQpyZWdhcmRzLCBOZWlsDQoNCj4gQ2hlZXJzLCBIdXVi Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMt dHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVs eSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVu aWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGln YXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9z ZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1h aWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5k IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRp dmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz IGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000D372B482575A7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE5laWwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj6hrml0IGlzIHF1aXRlIGNsZWFy IGZyb20gYSBzaW1wbGUgdGVjaG5pY2FsDQphbmFseXNpcyB0aGF0IGFueSBub24gdG9wLW9mLXN0 YWNrIG5ldHdvcmsgaGFzIG5vIG5lZWQgZm9yIEUtTk5JIHBlZXItcGFydGl0aW9uDQp3b3JraW5n IGJldHdlZW4gZGlmZmVyZW50IG9wZXJhdGluZyBwYXJ0aWVzLqGvPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGNhbm5vdCBhZ3JlZSB0aGlzIHN0YXRl bWVudC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gb3IgZXhh bXBsZSwgdGhlcmUgYXJlIHR3byBJUCBuZXR3b3Jrcw0KYmVsb25naW5nIHRvIHR3byBvcGVyYXRv cnMsIGEgRTEgaXMgdHJhbnNwb3J0ZWQgZnJvbSBBIG5ldHdvcmsgdG8gQiBuZXR3b3JrDQooZS5n LiBFMW92ZXJQV292ZXJJUCApLCBJUCBwYWNrZXQobm90IEUxKSBwYXNzIGFjcm9zcyBmb3JtIEEg dG8gQiBhdCBib3JkZXINCm5vZGUsIHNvIHRoZXJlIGlzIGEgRS1OTkkgYmV0d2VlbiB0aGVzZSAm bmJzcDt0d28gSVAgbmV0d29yay4gSW4gdGhpcyBjYXNlLA0KaXMgSVAgYSB0b3Atb2Ytc3RhY2sg bmV0d29yaz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5vdyBs ZXQgdXMgcmVwbGFjZSBJUCBuZXR3b3JrcyBieSBNUExTLVRQDQpuZXR3b3JrcyAoZS5nLiBFMW92 ZXJQV292ZXJNUEwtVFApLCBNUExTLVRQIG5ldHdvcmsgaXMgYXQgc2FtZSBwb3NpdGlvbg0KaW4g dGhlIHN0YWNrIGFzIElQIG5ldHdvcmsgaXMsIHdoeSBjYW4gSVAgbmV0d29yayBoYXZlIEUtTk5J IGJ1dCBNUExTLVRQDQpjYW5ub3Q/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5SZWdhcmQsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5TdWh1aTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj48Yj4mbHQ7bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBscy10cC1i b3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjIwMDktMDQtMjggMTQ6NDM8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2hoZWx2b29ydEBjaGVsbG8ubmwmZ3Q7LCAmbHQ7YWRyaWFu QG9sZGRvZy5jby51ayZndDssDQombHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7 PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5tcGxzLXRwQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkDQpiaWRpcmVjdGlvbmFsIHRyYW5z cG9ydCBwYXRoICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlcXVpcmVtZW50cyk8L2ZvbnQ+ PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFi bGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pkh1dWIg d3JvdGUgMjcgQXByaWwgMjAwOSAyMjoyNzxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBBZHJpYW4s PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlvdSB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0 OyBJc24ndCB0aGUgc29sdXRpb24gaGVyZSB0aGUgc2FtZSBhcyB0aGUgb25lIEkgcHJvcG9zZWQg Zm9yICZxdW90O1RDTSZxdW90Oz88YnI+DQomZ3Q7IDxicj4NCiZndDsgSW5kZWVkLCBhbmQgdGhh dCB3ZSBkbyBub3QgaGF2ZSB0byBhcm91bmQgaW4gY2lyY2xlcyBhYm91dCBUQ00uPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEhvdyBhYm91dDo8YnI+DQomZ3Q7IHRoZSByZXF1aXJlbWVudCBpcyB0aGF0 IGEgc2VydmVyIGxheWVyIHNoYWxsIGluZm9ybSBpdHMgY2xpZW50czxicj4NCiZndDsgdGhhdCBp dCBoYXMgZGV0ZWN0ZWQgYSBzZXJ2aWNlIGludGVydXB0aW9uLCB0aGlzIHRvIGVuc3VyZSB0aGF0 PGJyPg0KJmd0OyB0aGUgY2xpZW50cyBjYW4gaW5oaWJpdCAodW5uZWNlc3NhcnkpIGFsYXJtcy48 YnI+DQo8YnI+DQpOSD0mZ3Q7IFRoaXMgb25seSBhcHBsaWVzIGlmIHRoZSBjbGllbnQvc2VydmVy IGJpbmRpbmcgaXMgZml4ZWQuICZuYnNwO0FuZA0Kb2Y8YnI+DQpjb3Vyc2Ugd2F5IGJhY2sgaW4g dGhlIDcwcyB3aGVuIGJpbmFyeSBhbGwgMXMgcG9wcGVkIG91dCBvZiB0aGUgZmFpbGVkPGJyPg0K VFRMIGxvZ2ljIGludG8gdGhlIFBESCB0cmFuc3BvcnQgaGllcmFyY2h5IHRoaXMgd2FzIHRydWUu ICZuYnNwO0Fsc286IG5vPGJyPg0KbGFiZWxzIGhlcmUgYW5kIG5vIGNsaWVudCB0cmFmZmljIHVu aXRzIHRvIGNyZWF0ZS4gJm5ic3A7IDxicj4NCjxicj4NCldoZXJlIHRoZSBjbGllbnQgY2FuIGR5 bmFtaWNhbGx5IGJlIHJlLXJvdXRlZCBpbiByZXNwb25zZSB0byBhIHNlcnZlcjxicj4NCmZhaWx1 cmUgdGhlIHByb3Bvc2VkIHRleHQgaXMgbm90IHZhbGlkLiAmbmJzcDtJdCBpcyBhbHNvIG5vdCBu ZWNlc3NhcnkNCnRoYXQ8YnI+DQp0aGUgc2VydmVyIGhhcyB0byBrZWVwIHRyYWNrIG9mIHdoZXJl IGl0cyBjbGllbnQgdHJhZmZpYyByb3V0aW5ncyBoYXZlPGJyPg0KbW92ZWQgdG8uICZuYnNwO0Zv ciBleGFtcGxlLCBpZiBJIGNyZWF0ZSB0aGUgdG9wb2xvZ3kgb2YgYW4gSVAgbGF5ZXIgbmV0d29y azxicj4NCndpdGggbGlua3MgcHJvdmlkZWQgYnkgU0RILCBFdGhlcm5ldCwgQVRNLCBPVE4sIGV0 YyBzZXJ2ZXJzLCBhbmQgZWFjaCBvZjxicj4NCnRoZXNlIHNlcnZlciBsaW5rcyBpcyBwcm92aWRl ZCBieSBhIGRpZmZlcmVudCBvcGVyYXRvciwgdGhlbiB3aHkgc2hvdWxkPGJyPg0KdGhlIHNlcnZl cnMgbmVlZCBoYXZlIGtub3dsZWRnZSBvZiB3aGVyZSB0aGUgSVAgZmxvd3MgaGF2ZSBtb3ZlZCB0 byBpbjxicj4NCnJlc3BvbnNlIHRvIGEgc2VydmVyIGxheWVyIGZhaWx1cmUgd2hlbiB0aGUgbmV3 IHJvdXRlcyBoYXZlIGJlZW48YnI+DQpjYWxjdWxhdGVkIGJ5IHRoZSBJR1AgaW4gdGhlIElQIGxh eWVyIG5ldHdvcms/ICZuYnNwO0kgY2FuIGFwcGx5IHRoZSBzYW1lPGJyPg0KbG9naWMgdG8gYW4g U1ZDLWJhc2VkIGNvLXBzL2NvLWNzIG1vZGUgY2xpZW50Li4uLmluZGVlZCB0aGUgY28tY3MgbW9k ZTxicj4NClBTVE4gaXMgbGlrZSB0aGlzLjxicj4NCjxicj4NClRoZXNlIG9ic2VydmF0aW9ucyBt YWtlIGl0IHF1aXRlIGNsZWFyIHRvIG1lIGF0IGxlYXN0IHRoYXQganVzdCBjb3B5aW5nPGJyPg0K dGhlIEFJUyBiZWhhdmlvdXIgb2YgdGhlIG9sZCB0cmFuc3BvcnQgaGllcmFyY2hpZXMgdGhhdCBo YWQgZml4ZWQ8YnI+DQpjbGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcHMgaXMgbm90IGEgc2Vuc2li bGUgdGhpbmcgdG8gZG8uPGJyPg0KPGJyPg0KSU1PIHRoZSBvbmx5IGVzc2VudGlhbCBEUCBPQU0g cmVxdWlyZW1lbnQgaXMgdGhhdCBlYWNoIGxheWVyIG5ldHdvcms8YnI+DQpzaG91bGQgYmUgc2Vs Zi1zdWZmaWNpZW50IHdydCBPQU0gYW5kIG5vdCByZWx5IG9uIGFueSBzZXJ2ZXIgbGF5ZXI8YnI+ DQpwcmltaXRpdmVzIGJlaW5nIHBhc3NlZCB1cHdhcmRzLjxicj4NCjxicj4NCk1vcmVvdmVyLCBp dCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0IChpKSB0aGUgZGVmZWN0cyB0aGF0IGNhbiBvY2N1 ciBpbjxicj4NCmVhY2ggb2YgdGhlIDMgbmV0d29yayBtb2RlcyBhcmUgbm90IHRoZSBzYW1lIGFu ZCAoaWkpIHRoZWlyIE9BTTxicj4NCnJlcXVpcmVtZW50cyBhcmUgbm90IGlkZW50aWNhbGx5IHRo ZSBzYW1lLiBTbyB0aGUgT0FNIHRoYXQgYXBwbGllcyB0bzxicj4NCnRoZSBjbC1wcyBtb2RlIChl ZyBJUCkgaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvIHRoZTxicj4N CmNvLXBzIG1vZGUgKGVnIE1QTFMtVFApIGFuZCBuZWl0aGVyIG9mIHRoZXNlIGlzIGlkZW50aWNh bGx5IHRoZSBzYW1lIGFzPGJyPg0KdGhlIE9BTSB0aGF0IGFwcGxpZXMgdG8gdGhlIGNvLWNzIG1v ZGUgKGVnIFNESCkuPGJyPg0KPGJyPg0KTm90ZSAtIFRoZSBvbmx5IHBvaW50IGJlaW5nIGNvbnNp ZGVyZWQgaGVyZSBpcyB0aGUgcmVhbCBjbGllbnQgYW5kPGJyPg0Kc2VydmVyIHRyYWZmaWMgcmVs YXRpb25zaGlwLiAmbmJzcDtUaGUgY3JlYXRpb24gb2YgYSBoaWVyYXJjaHkgb2YgVENNPGJyPg0K c3VibGF5ZXJzIGlzIGEgc2VwYXJhdGUgdG9waWMuICZuYnNwO0Z1cnRoZXIsIGl0IGlzIHF1aXRl IGNsZWFyIGZyb20gYQ0Kc2ltcGxlPGJyPg0KdGVjaG5pY2FsIGFuYWx5c2lzIHRoYXQgYW55IG5v biB0b3Atb2Ytc3RhY2sgbmV0d29yayBoYXMgbm8gbmVlZCBmb3I8YnI+DQpFLU5OSSBwZWVyLXBh cnRpdGlvbiB3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50IG9wZXJhdGluZyBwYXJ0aWVzLiAmbmJz cDtTbzxicj4NCnRoaXMgaXMgYWxzbyBhIHNlcGFyYXRlIGlzc3VlLiAmbmJzcDtIb3dldmVyLCBJ IHByb3Bvc2UgdGhhdCB0aGlzIGxhdHRlcjxicj4NCnBvaW50IGJlIGNhcHR1cmVkIGluIHRoZSBN UExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdCBkdWUgdG8gaXRzPGJyPg0Kc3RhbmQtYWxvbmUgYW5k IGdlbmVyaWMgaW1wb3J0YW5jZSwgaWUgdGhpcyBhcHBsaWVzIHRvIG1vcmUgdGhhbiBqdXN0IERQ PGJyPg0KT0FNLiAmbmJzcDtCZW4gY2FuIHlvdSBwbGVhc2UgY29uc2lkZXIgdGhpcyBwb2ludCBh cy93aGVuIHRoZSBNUExTLVRQPGJyPg0KcmVxdWlyZW1lbnRzIGRyYWZ0IGlzIHVwZGF0ZWQuPGJy Pg0KPGJyPg0KcmVnYXJkcywgTmVpbDxicj4NCjxicj4NCiZndDsgQ2hlZXJzLCBIdXViLjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBs cy10cCBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzLXRwQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+ DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90 aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJz cDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNw O1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVk Jm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJz cDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7 Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJz cDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZu YnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50 aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUm bmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2Vu dGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQu Jm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7 ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhl Jm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkm bmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2Um bmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw O3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5u ZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7 WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000D372B482575A7_=-- From maarten.vissers@huawei.com Tue Apr 28 23:19:40 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6111F3A6E44 for ; Tue, 28 Apr 2009 23:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.883 X-Spam-Level: X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2ENzYh0dIYG for ; Tue, 28 Apr 2009 23:19:38 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 710DE3A6E30 for ; Tue, 28 Apr 2009 23:19:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU00F5TMHCE3@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 14:10:24 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU002XPMHCT6@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 14:10:24 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIU0068TMH0RX@szxml02-in.huawei.com>; Wed, 29 Apr 2009 14:10:24 +0800 (CST) Date: Wed, 29 Apr 2009 08:10:15 +0200 From: Maarten Vissers In-reply-to: To: andy.bd.reid@bt.com Message-id: <006301c9c891$2cc37570$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AASESoQ Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 06:19:40 -0000 Andy, > That is my concern with the trying to inject packet based AIS. There is > significant room for creating false information. As I've already indicted > there is AIS specific configuration to do which will be prone to > misconfiguration. Can you list what the "AIS specific configuration" is that we have to do? I don't know of any such "AIS specific configuration". ------------ > For example, consider port mapping (or in ITU-T speak, a degenerate > subnetwork) where we terminate the section layer on one interface > and blindly ship all the packets out on an other interface in a > new section. I am interested to learn in which types of equipment this occurs, or at which location in a network this occurs. I have not come across this so far in transport network equipment designs. I.e. this seems to be a non-existing case in transport networks. I have come across a port-based service. In this port-based service you terminate the Physical Media layer and forward the Section_CI. There is now a single Characteristic Information stream and AIS insertion is done in this single connection. An example are the port-based Ethernet services; the Section VLAN (EVS_CI) is the service and this service is forwarded through the network as an EVC. An example is also the port-based SDH and 802.3 services provided by the OTN. In those cases the STM-N bit streams and 802.3 bit or codeword streams are forwarded. > A similar scenario would exist if we choose to use a sort of > ADM where the forwarding table was made up of exception (add/drop) > label values and a default outgoing port. Again, I don't know of any such design in transport equipment. It is kind of useless to make this type of equipment in my understanding. Regards, Maarten -----Original Message----- From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] Sent: woensdag 29 april 2009 0:26 To: maarten.vissers@huawei.com; IBryskin@advaoptical.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Maarten, Igor, Before dealing with the specific scenarios, let me go through again what I said in an earlier posting about the way alarm 'suppression' actually works. There are two sides to maintenance - the faulty kit guys who fix faulty cards, mend cable breaks, etc, etc, and end service guys who deal with customer service. 'Suppressed' alarms are only suppressed to the faulty kit guys who fix cards, etc. The distinction between 'local' and 'remote' alarms is very important to ensure that these faulty kit guys are directed to the place where the actual fault lies and not to places affected by, but remote from the actual fault. However, these 'suppressed' alarms are still forwarded to the service maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they want to know whether the end service is 'up' or 'down' irrespective of the cause and irrespective of the presence of AIS. AIS most emphatically does not suppress this alarm! These guys wants to know that the service is 'down' before the customer is on the phone! So to go to Maarten's first example, the faulty kit guys are not getting any alarms telling them to fix broken kit - which is correct. The service maintenance guys *have* got an alarm - the customer has not got their service! They also notice that it is not fixing itself. So they investigate, ie start localising. In practice, the first thing they will do (and most management systems will do it automatically by some form of correlation engine) is check for any corresponding faulty kit alarms. In this case, they will find no faulty kit alarms and suspect a misconfiguration, localise it, and fix it. To go to Maarten's second example, the faulty kit guys are getting an alarm telling them to fix the link between A and B. The service maintenance guys have also got an alarm - again the customer has not got their service. They also notice that it is not fixing itself. So they investigate, ie start localising. Again, the first thing they will do (and most management systems will do it automatically by some form of correlation engine) is check for any corresponding faulty kit alarms. In this case, they will find the corresponding faulty kit alarm and can check of the repair plan and status should the customer call and ask. As these particular scenarios illustrate, the right alarms have been directed to the right maintenance guys. The service guys deal with the service configurations, the faulty kit guys deal with faulty kit. Occasionally, there will be faulty kit which is not reporting itself despite the best design efforts in the equipment. In this case, the service maintenance guys are likely to have a series of alarms which can be correlated to help localise the fault and the diagnosed fault can then be passed to the faulty kit guys for fixing. Another important point. There is little room here for *false* information coming to either set of maintenance guys. When trying to localise a fault, no additional information is better than wrong additional information. That is my concern with the trying to inject packet based AIS. There is significant room for creating false information. As I've already indicted there is AIS specific configuration to do which will be prone to misconfiguration. We should then note that the thing that the AIS is supposed to be identifying is the present of misconfiguration - but achieving this requires configuration. So why should one configuration be more reliable than the other? But there are other scenarios. For example, consider port mapping (or in ITU-T speak, a degenerate subnetwork) where we terminate the section layer on one interface and blindly ship all the packets out on an other interface in a new section. If we assume AIS is being used, a fault in the incoming section should result in the injection of AIS. But how does it know what label values to use? Or does it not inject AIS? In which case we have the poor service maintenance guys actively looking for a configuration error which does not exist. A similar scenario would exist if we choose to use a sort of ADM where the forwarding table was made up of exception (add/drop) label values and a default outgoing port. Again, the same dilemma exists. Andy Andy Reid Chief Network Services Strategist BT Innovate Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 28 April 2009 20:25 > To: 'Igor Bryskin' > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Igor, > > > b) Is it beneficial if a server trail notifies its clients about > a detected problem to suppress the OAM traffic > > The suppression we have been talking about is alarm suppression, not > OAM traffic suppression. > > Loss of CC is intended to detect an open connection fault in a matrix. > E.g. assume a connection that starts in node A, passes through nodes B > and C and ends in node D. > Nodes A, B, C and D have a connection function in which a matrix > connection is to be set up to support this connection from A to D. > > What is now possible is that the matrix connection in node B is > unintentionally removed (i.e. a continuity fault). > Node D will now detect a loss of CC. Node D does not detect any other > faults. > Node C will not detect any fault. > Node B will not detect any fault. > Node A will not detect any fault if the matrix connection in B is > removed in one direction only. > > In order to detect this open matrix connection fault it is required to > report the loss of CC to the management system and to start a fault > localization procedure to locate the faulty matrix (i.e. in node B). > If such reporting is not done, then there is a hidden fault, which > keeps the connection interrupted much longer; i.e. until one or more > customers start to complain that their connections are lost. > Then you hae to find in a big network without any fault report which > node has the fault. > > What happens now if the fault is not an open matrix connection but a > server layer fault (e.g. a link fault between nodes A and B). > Node D will now detect a loss of CC. Node D does not detect any other > faults. > Node C will not detect any fault. > Node B will detect a loss of signal fault. > Node A will not detect any fault if the link from A to B is broken in > one direction only. > > If loss of CC is unconditionally reported, then node D will report > loss of CC. Node B will report loss of signal. > - If node B and node D are managed by the same management system it is > possible to perform a fault correlation in this management system to > filter out the loss of CC from node D. > What is necessary is to know that connection A-D is supported by the > link A to B. In larger multi-layer networks such correlations become > complex. If such correlations are not performed, then the loss of CC > will trigger a fault localisation action, which of course will not > find a matrix fault (i.e. waste of time). > - If node B is managed by another management system then node D, there > is no correlation possible. Node D's management system will see only > the loss of CC and will start fault localization, and will not find > any fault in its part of the network. > > Use of AIS will help in distinguishing between connection interruption > due to an open matrix connection fault and due to server fault. AIS > provides the necessary filter for loss of CC. > > What happens for the case a port detects a signal fail condition is > the following; assume a 10G port that detects a signal fail condition. > This implies that all traffic is lost. > Assume that there are 1000 client connections active (e.g. > with an average bandwidth of 5 Mbit/s). When AIS is to be generated > for those 1000 client conenctions the port has to generate 1000 AIS > frames/packets per second. Each AIS frame/packet is 64 bytes/512 bits. > Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005 > Gbit/s) of traffic in a further empty 10G port. This isn't any real > complexity. > > --------- > > The alternative is to declare that open matrix connections are never a > fault condition (i.e. are always intentional and thus known by network > management). Under such starting point it is not necessary to detect > an open matrix connection as a fault condition. Now it is not longer > necessary to distinguish between connection interruption due to open > matrix and server layer fault as the first condition isn't a fault > anylonger. Under this condition it is not useful that a server trail > informs its clients about a detected server trail problem that > interrupts the client connections. > > If we go for this latter approach and if in future an open matrix > connection would be a fault condition, then this is a hidden fault and > you need a lot more work to locate the fault (there are no alarms that > help you). > > Regards, > Maarten > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: dinsdag 28 april 2009 18:20 > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Shahram, > > I was addressing Neil's comments about the dynamic re-routing, which > is different from protection switchover onto pre-provisioned > protection connection. True, in the latter case the server layer > wouldn't notice that and will keep notifying the client that the trail > is broken. But this does not change anything. The big 2 questions in > my mind are: > > a) Is the OAM of a given layer is (i) self-sufficient and > (ii) scalable enough, so that operator can rely on it completely and > independently from what is happening in the lower layers? > > b) Is it beneficial if a server trail notifies its clients about a > detected problem to suppress the OAM traffic and possibly unnecessary > switchovers until the server trail corrects itself? > > Cheers, > Igor > > > > -----Original Message----- > From: Shahram Davari [mailto:davarish@yahoo.com] > Sent: Tuesday, April 28, 2009 11:57 AM > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Igor, > > Your assumption is that there is a control plane that sets up the > binding between client and server layer and that such binding will be > removed via the control plane when a reroute happens. I think this > assumption is not always true. For example in a linear 1:1 or 1+1 > protection, there is no signalling to withdraw the binding at > intermediate nodes. In > 1:1 there is APS, but that is end-to-end and is sent on the backup > path not working path. > > -Shahram > > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: April-28-09 11:27 AM > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Shahram, > > Let's assume that connection A-B-C-D-E is dynamically provisioned by a > control plane. As part of such provisioning a binding is created > between this connection and network C at the two adaptation points on > either side of the link provided by network C. When the connection is > torn down, this binding is removed as a part of the cleanup process. > The re-routing of the connection onto A-F-G-E is indistinguishable > from the connection tear down as far as link C is concerned. > > Igor > > -----Original Message----- > From: Shahram Davari [mailto:davarish@yahoo.com] > Sent: Tuesday, April 28, 2009 11:15 AM > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Hi Igor, > > How does the server know the client is rerouted? Assume the following > networks: A-B-C-D-E (working) and A-F-G-E (protection). > Assume each has its own server layer such as MPLS, MPLS-TP, ATM, > SONET, etc. Assume that network C uses MPLS-TP as server layer. > Network C will never know there was a protection switching done for > the client layer. > > -Shahram > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin > Sent: April-28-09 11:05 AM > To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Neil. > > I actually agree with Maarten on this. I don't quite understand why do > you keep talking about fixed client-server relationship. It is fixed > as long as the client layer connection configured this way (statically > or dynamically). > As soon as the connection is re-routed, this relationship is broken > (because this is a part of the re-routing process) and hence the > server trail termination points will know that the server trail now > serves one connection less, whereas some other server trail(s) will > learn that they serve from now on one connection more. These new > client-server relationships are fixed until the next re-routing. > > Cheers, > Igor > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: Tuesday, April 28, 2009 8:48 AM > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Neil, > > > However, if the client can dynamically change its routing > in response > > to link failures in its topology (because some server layer network > > has failed....which may or may not belong to the same > operating party > > as the > > client) then there is no fixed client/server relationship. > > I believe there is a fixed client/server relationship also in this > case in the network. This relationship is broken when the connection > is rerouted. > Such reroute will remove the CP/FP and as such will stop the AIS > generation. > > There is no difference with what we do today in SDH and OTN. > A client/server relationship is fixed until the point in time that the > connection is either teardown or rerouted. When either of the two > cases occur, the AIS generation is stopped. > Until such action is performed, AIS is generated during signal fail > condition period and inserted into the connection. > > In MPLS-TP we have the requirement that MPLS-TP must be able to > operate without control plane. This implies that it will operate > without restoration, and that there will not be frequent rerouteing > ongoing. Result is that client/server relationships will last until > the connection is teardown. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com > Sent: dinsdag 28 april 2009 10:07 > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Nurit, > > I believe the reason we need this discussion is that there is an > unstated assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. > > Refer to my post earlier today and consider what this means in the > case of a cl-ps IP client layer network or a some SVC-based > co-ps/co-cs mode client layer network. The key point here is the > *routing process* in the client is independent of the server layer > network....so there is not a fixed client/server relationship. > Further, there is also no requirement for the server to keep track of > where its client traffic routings are at any epoch.....indeed why > should it in the general case where these are independent layer > networks? > > So the only OAM requirement that is critical is that the OAM of the > client and server layer networks are independent. It is thus not > sensible to make client layer alarm supression a 'requirement' > here...in fact if this is in the OAM requirements then it is > technically wrong and should be removed IMO. > > regards, Neil > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > Nurit (NSN - > > IL/Hod HaSharon) > > Sent: 28 April 2009 08:46 > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > > > > If we agree that the requirement is included, so why do we > keep with > > the endless discussions on this requirement? > > > > -----Original Message----- > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Tuesday, April 28, 2009 10:44 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > > Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > pathrequirements) > > > > I think that the requirements are defined in section 2.2.8 of > > draft-ietf-mpls-tp-oam-requirements-01 > > > > Italo > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > Nurit (NSN > > > - IL/Hod HaSharon) > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > To: hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > > transport pathrequirements) > > > > > > Huub, > > > I think that the requirement is to provide a mechanism to > suppress > > > alarms in the networks, to ensure that alarms that may be > > generated by > > > client layers as a result of a failure condition in the > server layer > > > may be suppressed. > > > Every thing else is a solution, etc. > > > I propose to phrase the requirement appropriately and > conclude the > > > discussion on this in the context of the requirements > (until we are > > > getting to the solution phase). > > > This requirement is included in the OAM requirement draft. > > > Best regards, > > > NUrit > > > > > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On > > > Behalf Of ext Huub van Helvoort > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > To: Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > path requirements) > > > > > > Hi Adrian, > > > > > > You wrote: > > > > > > > Isn't the solution here the same as the one I proposed > for "TCM"? > > > > > > Indeed, and that we do not have to around in circles about TCM. > > > > > > How about: > > > the requirement is that a server layer shall inform its > clients that > > > it has detected a service interuption, this to ensure that the > > > clients can inhibit (unnecessary) alarms. > > > > > > Cheers, Huub. > > > > > > -- > > > ================================================================ > > > http://www.van-helvoort.eu/ > > > ================================================================ > > > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From mtwu@cisco.com Tue Apr 28 23:23:35 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B675C3A6AD9 for ; Tue, 28 Apr 2009 23:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSwWCrQoccbT for ; Tue, 28 Apr 2009 23:23:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DB4D73A6859 for ; Tue, 28 Apr 2009 23:23:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,265,1238976000"; d="scan'208,217";a="73780842" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 29 Apr 2009 06:24:57 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3T6Ov7s015013 for ; Tue, 28 Apr 2009 23:24:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3T6OuS8017043 for ; Wed, 29 Apr 2009 06:24:57 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 23:24:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C893.36F2BDE3" Date: Tue, 28 Apr 2009 23:25:03 -0700 Message-ID: <4A90369EC3D15C4F91C73F46BBA068E707D738CD@xmb-sjc-22d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interworking Thread-Index: AcnIkzr/OCtaxBPMQ4GxueQyq0XAMg== From: "Michael T. Wu (mtwu)" To: X-OriginalArrivalTime: 29 Apr 2009 06:24:56.0733 (UTC) FILETIME=[371F84D0:01C9C893] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1401; t=1240986297; x=1241850297; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mtwu@cisco.com; z=From:=20=22Michael=20T.=20Wu=20(mtwu)=22=20 |Subject:=20Interworking |Sender:=20; bh=x4lm98vFRjQkfEnnuGNhT73ROhR++UHtoK1Ak7e40JY=; b=ijD18/TNFFMZS3j77jnEOLYXJw4ur54rA6An41Cn+R4kRgkMo86+1+tlIE zDr+Bdl3Di78tcm7iOnjTL0N+szWHH9a5qwe2qP/wVEwxMXyeXxhJp9TOvne oy75sHk2bE; Authentication-Results: sj-dkim-3; header.From=mtwu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [mpls-tp] Interworking X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 06:23:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C893.36F2BDE3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Is there a draft or discussion on the interworking with existing technologies (L2 or L3) and standards (ITU/MEF)? =20 Thanks, Michael ------_=_NextPart_001_01C9C893.36F2BDE3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Is = there a draft or=20 discussion on the interworking with existing technologies (L2 or L3) and = standards (ITU/MEF)? Thanks, Michael ------_=_NextPart_001_01C9C893.36F2BDE3-- From neil.2.harrison@bt.com Tue Apr 28 23:39:23 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BE23A6C53; Tue, 28 Apr 2009 23:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP9uEDDIOXRC; Tue, 28 Apr 2009 23:39:21 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 3249A3A689C; Tue, 28 Apr 2009 23:39:21 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 07:40:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C895.6A2C361C" Date: Wed, 29 Apr 2009 07:40:37 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E2187@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnIcZxcCbD7EWzbQreltx+qsWahewAHRjog From: To: X-OriginalArrivalTime: 29 Apr 2009 06:40:42.0142 (UTC) FILETIME=[6AA17BE0:01C9C895] Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 06:39:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C895.6A2C361C Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhhbmtzIFNodWh1aSwNCiANCkRvIG5vdCBjb25mdXNlIHBoeXNpY2FsIGludGVyY29ubmVjdCB3 aXRoIEUtTk5JLi4uLi5JJ2xsIGNvbWUgYmFjayBvbiB0aGlzIHNob3J0bHkgd2hlbiBkaXNjdXNz aW5nIHRoZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4NCiANClRoZSBmaXJzdCB0aGlu ZyB0byB1bmRlcnN0YW5kIGlzIHRoYXQgKmFsbCogbmV0d29ya3MgYXJlIHRoZXJlIHRvIHVsdGlt YXRlbHkgc3VwcG9ydCBvbmUgcHVycG9zZS4uLi4uYW5kIHRoYXQgaXMgdG8gYWxsb3cgY29tbXVu aWNhdGlvbnMgYmV0d2VlbiBwYXJ0aWVzIHRoYXQgYXJlICpleHRlcm5hbCogdG8gdGhlIG5ldHdv cmtzLiAgU28gZXZlcnl0aGluZyB3ZSBkbyBpbiBuZXR3b3JraW5nIGlzIHRoZXJlIHRvIHVsdGlt YXRlbHkgc3VwcG9ydCB0aGlzIG9iamVjdGl2ZS4gIFdoYXQgdGhpcyBtZWFucyBpcyB0aGF0IHRo ZSBEUCBvZiBzb21lIG5ldHdvcmsgKHdoYXQgSSBjYWxsIHRoZSB0b3Atb2Ytc3RhY2sgbmV0d29y aykgTVVTVCBiZSBwcm92aWRpbmcgYWRhcHRhdGlvbiBmdW5jdGlvbnMgZm9yIHRoZXNlIGV4dGVy bmFsIGFwcGxpY2F0aW9ucy4uLi4uLi5hbmQgdGhlc2UgY2FuIGdlbmVyaWNhbGx5IGJlIGNsYXNz aWZpZWQgYXMgbWVzc2FnZXMsIGZpbGVzIGFuZCBzdHJlYW1zLiANCiANCldlIGNhbiBzZWUgdGhh dCBJUCBpcyBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGFzIGl0IGhhcyBVRFAvVENQL1JUUCAoZm9y IGV4YW1wbGUpIGFkYXB0YXRpb25zLiAgQVRNIHdhcyBhbHNvIG9uY2UgKH45MHMpIGludGVuZGVk IHRvIGJlIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgYW5kIGl0IGhhZCBpdHMgb3duIGFwcGxpY2F0 aW9uIGFkYXB0YXRpb25zIGluIHRoZSBmb3JtIG9mIEFBTHMuICBBdCBvbmUgc3RhZ2UgdGhlcmUg d2VyZSA1IG9mIHRoZXNlLCBidXQgaW4gcHJhY3RpY2Ugb25seSBhIGNvdXBsZSB3ZXJlIHJlYWxs eSBzdWNjZXNzZnVsIGJlY2F1c2Ugb2YgdGhlIGdlbmVyaWMgbmF0dXJlIG9mIG1lc3NhZ2UvZmls ZS9zdHJlYW0gY2xhc3NpZmljYXRpb24uICBUaGUgUFNUTiBpcyBhbHNvIHRvcC1vZi1zdGFjaywg YW5kIGl0cyBhcHBsaWNhdGlvbiBhZGFwdGF0aW9uIHdhcyBtYWlubHkgZm9yIHZvaWNlIChzdHJl YW0pIHN1cHBvcnQuDQogDQpNb3N0IG90aGVyIG5ldHdvcmtzIGRvIG5vdCBoYXZlIHRoZXNlIGFw cGxpY2F0aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zLi4uLnNvIHRoZXkgZG8gbm90IGRpcmVjdGx5 IHN1cHBvcnQgYXBwbGljYXRpb25zLiAgV2hhdCB0aGlzIG1lYW5zIGluIHByYWN0aWNlIGlzIHRo YXQgdGhlc2UgbmV0d29ya3MgKGEgbGlzdCB3aGljaCBpbmNsdWRlcyBQREgsIFNESCwgT1ROLCBF dGhlcm5ldCwgTVBMUykgTVVTVCBjYXJyeSBhIGZ1cnRoZXIgbGF5ZXIgbmV0d29yayBhYm92ZSB0 aGVtIHRoYXQgaXMgdG9wLW9mLXN0YWNrLi4uLmxpa2UgSVAuICBUaGVyZSBpcyBubyBjaG9pY2Ug aW4gdGhlIG1hdHRlciBoZXJlLiAgU28gd2hpbHN0IHdlIG1pZ2h0IHNheSB0aGF0IGFuIE1QTFMg bmV0d29yayBpcyBjYXJyeWluZyBhbiBFMSBQVyB0aGUgRTEgZW50aXR5IG11c3QgaW4gdHVybiBi ZSBjYXJyeWluZyBzb21lIG90aGVyIHRvcC1vZi1zdGFjayBuZXR3b3JrIChsaWtlIElQIG9yIFBT VE4pLCBlbHNlIGl0IGlzIHNlcnZpbmcgbm8gdWx0aW1hdGUgcHVycG9zZS4NCiANCk5vdyBpbiBv cmRlciB0byB0cmFuc21pdCBpbmZvcm1hdGlvbiBvdmVyIGdlb2dyYXBoaWMgZGlzdGFuY2Ugd2Ug bXVzdCBtb2R1bGF0ZSBhbiBFTSB3YXZlIG9uIHNvbWUgbWV0YWxsaWMvb3B0aWNhbC9yYWRpbyBt ZWRpYS4uLi50aGlzIGlzIHRoZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4gIFRoZXNl IGFyZSBoaWdoIGJpdCByYXRlIHRyYW5zcG9ydCBwaXBlcyB3aG9zZSBmdW5jdGlvbiBpcyB0byBw cm92aWRlIHRyYW5zcGFyZW50ICh3aGljaCBJIGhhdmUgZGVmaW5lZCBwcmV2aW91c2x5KSB0cmFu c3BvcnQgdG8gd2hhdGV2ZXIgY2xpZW50IGxheWVycyBuZXR3b3JrcyBzaXQgYWJvdmUgdGhlbS4u Li5hbmQgd2hlcmUsIGFzIEkgbm90ZWQgYWJvdmUsIHRoZXJlIE1VU1QgYmUgYSB0b3Atb2Ytc3Rh Y2sgbmV0d29yayBwcmVzZW50IGFzIHRoZSB1bHRpbWF0ZSBsYXllciBuZXR3b3JrIGNsaWVudCBl bHNlIHRoZXJlIGlzIG5vdCBleHRlcm5hbCBwYXJ0eSBjb21tdW5pY2F0aW9uIHBvc3NpYmxlLg0K IA0KU28gd2hlbiB3ZSBjb25uZWN0IHRvZ2V0aGVyIDIgdG9wLW9mLXN0YWNrIG5ldHdvcmtzIHdl IGRvIHNvIGF0IGEgc2VjdGlvbiBsYXllciB3aGljaCBpcyBpbnZhcmlhYmx5IGNhcnJ5aW5nIGEg dmVyeSBsYXJnZSBhZ2dyZWdhdGUgb2YgYXBwbGljYXRpb25zLi4uLi5hbmQgb2YgY291cnNlIHRo ZXNlIGFwcGxpY2F0aW9ucyBjYW4gYmUgYSB0aW1lIHZhcnlpbmcgbWl4IG9mIG1lc3NhZ2UvZmls ZS9zdHJlYW0gY2FzZXMgd2l0aCBhIHNldCBvZiB1bmtub3duICh0byB0aGUgc2VjdGlvbiBsYXll cikgaW1wb3J0YW5jZSdzIChlcmdvIHdoeSB0cmFuc3BhcmVuY3kgaXMgYW4gZXNzZW50aWFsIHJl cXVpcmVtZW50IGluIHRyYW5zcG9ydCBuZXR3b3JrcykuDQogDQpUaGUgcmVhbCBFLU5OSXMgKHdo aWNoIGNvbnNpZGVycyBib3RoIERQIGFuZCBDUCBjb21wb25lbnRzLi4uLndlIG5ldmVyIHVzdWFs bHkgcGVlciB0aGUgTVAsIGFuZCB3ZSByZXN0cmljdCB0aGUgc2NvcGUgb2YgdGhlIENQKSBleGlz dCBpbiB0aGUgdG9wLW9mLXN0YWNrIGxheWVyIG5ldHdvcmsuICBUaGUgc2VjdGlvbiBsYXllciBp bnRlcmNvbm5lY3QgaXMgYSBkdW1iIERQIHBpcGUuLi5pdCBqdXN0IHNoaWZ0cyBiaXRzIHRyYW5z cGFyZW50bHkgYW5kIG1haW50YWlucyB0aGVpciBvcmRlcmluZy4gIFRoZXJlIGlzIG5vIGNvbmNl cHQgb2YgQ1AgKG9yIE1QKSBwZWVyaW5nIG9uIHRoZXNlIGJvdHRvbS1vZi1zdGFjayBzZWN0aW9u IGxheWVyIGludGVyY29ubmVjdHMuDQpBc2lkZT0+IEluIHNvbWUgY291bnRyaWVzIHRoZXNlIGlu dGVyY29ubmVjdHMgaGF2ZSB0byBiZSBjYXJlZnVsbHkgc3BlY2lmaWVkIGluIG9yZGVyIHRvIGRp c3Rpbmd1aXNoIHJlZ3VsYXRlZCBhbmQgdW5yZWd1bGF0ZWQgc2VydmljZXMuLi4uLnNvIHRoZXJl IGFyZSBpbXBvcnRhbnQgbGVnYWwvY29tbWVyY2lhbCBjb25zaWRlcmF0aW9ucyBoZXJlLCBpdCBp cyBub3Qgc2ltcGx5IGEgdGVjaG5pY2FsIGlzc3VlLg0KIA0KV2UgY2FuIG9mIGNvdXJzZSBjcmVh dGUgRS1OTklzIGluIG5vbiB0b3Atb2Ytc3RhY2sgbGF5ZXIgbmV0d29ya3MgKHdlIGNhbiBkbyBt YW55IHRoaW5ncyB0aGF0IGFyZSBub3QgdXNlZnVsKS4gIFNvIGxldHMgYXNzdW1lIHdlIGRvIHRo aXMuLi4uLmFuZCBsZXRzIGFzc3VtZSB3ZSBjaG9vc2UgTVBMUyBzaW5jZSB5b3UgbWVudGlvbiB0 aGlzIGluIHRoZSBtYWlsIGJlbG93LiANCiANCk5vdyBob3cgZG8gZXh0ZXJuYWwgcGFydGllcyB3 aG8gd2lzaCB0byBjb21tdW5pY2F0ZSBpbnRlcmZhY2Ugd2l0aCB0aGlzIE1QTFMgbmV0d29yaz8g IENhbiB5b3Ugc3VwcG9ydCBhbGwgdHlwZXMgb2YgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNh dGlvbnMgKmRpcmVjdGx5KiBpbnRvIE1QTFM/ICBJbiBwcmluY2lwbGUgeW91IGNvdWxkIGlmIHlv dSBhbGxvd2VkIE1QTFMgdG8gaGF2ZSBlbmQgc3lzdGVtIGFwcGxpY2F0aW9uIGFkYXB0YXRpb25z IHN1Y2ggYXMgVURQL1RDUC9SVFAgb3IgdGhlIGxpa2UuICBCdXQgdGhlc2UgZG9uJ3QgZXhpc3Qg dG9kYXksIGFuZCBpbiB0aGUgbW9zdCB1c3VhbCBjYXNlIHRoZSBNUExTIG5ldHdvcmsgd2lsbCBj YXJyeSBhbiBJUCBsYXllciBuZXR3b3JrIGJlY2F1c2UgdGhpcyBjYW4gc3VwcG9ydCB0aGUgbWVz c2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMuDQogDQpXZSBjYW4gZ28gdGhyb3VnaCBleGFj dGx5IHRoZSBzYW1lIGFuYWx5c2lzIHdpdGggYW55IG5ldHdvcmsgdGhhdCBpcyBub3QgdG9wLW9m LXN0YWNrLCBlZyBFdGhlcm5ldC4gIEFuZCB3aGVuIHlvdSBkbyB0aGlzIHdoYXQgeW91IHJlYWxp c2UgaXMgdGhhdCBhbHRob3VnaCB3ZSBjYW4gY3JlYXRlIHBlZXIgaW50ZXJ3b3JraW5nIG9mIE1Q TFMgKG9yIHdoYXRldmVyKSB0aGlzIGhhcyBub3QgcmVhbGx5IGhlbHBlZCBzaW5jZSB3ZSBtaWdo dCBhcyB3ZWxsIGhhdmUganVzdCB0ZXJtaW5hdGVkIHRoZSBNUExTIG5ldHdvcmsgYW5kIHBhc3Nl ZCB0aGUgSVAgbGF5ZXIgYWNyb3NzLg0KIA0KTm93IHRoZSBhYm92ZSBiZWNvbWVzIGV2ZW4gbW9y ZSBzdHJpa2luZyBpbiBpdHMgaW1wb3J0YW5jZSBpZiB5b3UgY29uc2lkZXIgcGVlciBpbnRlcndv cmtpbmcgb2YgMiBkaWZmZXJlbnQgbm9uIHRvcC1vZi1zdGFjayBuZXR3b3Jrcy4uLi5sZXRzIHBp Y2sgTVBMUyBhbmQgRXRoZXJuZXQgYmVjYXVzZSB0aGF0IGlzIHdoYXQgaXMgb2Z0ZW4gbWVudGlv bmVkLiAgDQogDQpXaGF0IHdlIGhhdmUgdG8gZG8gbm93IGF0IHRoZSBFLU5OSXMgYmV0d2VlbiBF dGhlcm5ldCBhbmQgTVBMUyBpcyBnbyB0aHJvdWdoIGVhY2ggRFAgYW5kIENQIGNvbXBvbmVudCBh bmQgZG8gYSAncHJvdG9jb2wgY29udmVyc2lvbicgZXhlcmNpc2Ugd2hlcmUgcmVxdWlyZWQuLi4u Li5hbmQgdGhlIGZpcnN0IHByb2JsZW0geW91IHdpbGwgZW5jb3VudGVyIGlzIHRoYXQgdGhlcmUg d2lsbCBiZSBsb3RzIG9mIGZ1bmN0aW9uYWwgbWlzbWF0Y2guICBNb3Jlb3ZlciBpZiBvbmUgb3Ig Ym90aCBvZiB0aGUgbmV0d29ya3MgY2FuIHN1cHBvcnQgbXVsdGlwbGUgQ1AgdHlwZXMgbGlrZSBN UExTIGNhbiwgZWcgUlNWUC1URSBzaWduYWxsaW5nLCBMRFAgc2lnbmFsbGluZywgQkdQNCAnc2ln bmFsbGluZycsIE9TUEYgcm91dGluZywgSVMtSVMgcm91dGluZy4uLi4uYW5kIEkgY291bGQgbGlz dCBzaW1pbGFyIGZvciBFdGhlcm5ldC4uLi4ueW91IGFyZSBnb2luZyB0byBoYXZlIHRvIGNvbnNp ZGVyIGVhY2ggcGFpcmluZyBjYXNlIGluIHR1cm4uICBBIGxvdCBvZiB3b3JrLg0KIA0KQW5kIHdo ZW4geW91IGhhdmUgZG9uZSBhbGwgdGhpcyB5b3UgYXNrIHRoZSBxdWVzdGlvbiAnd2hhdCBpcyBp dCB0aGF0IGNhcnJpZXMgdGhlIHJlYWwgZXh0ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBs aWNhdGlvbnMgaW4gdGhlIERQIGhlcmU/Jy4uLi4uLi5hbmQgbm93IHlvdSBmaW5kIG5vIG5hdGl2 ZSBzdXBwb3J0IGZvciB0aGVzZSBpbiBNUExTIG9yIEV0aGVybmV0LCBidXQgd2hhdCB3ZSBkbyBm aW5kIGlzIHRoYXQgYm90aCBvZiB0aGVtIGFyZSBjYXJyeWluZyBJUCBiZWNhdXNlIHRoaXMgZG9l cyBzdXBwb3J0IHRoZSBleHRlcm5hbCBhcHBsaWNhdGlvbnMuICBOb3cgYXQgdGhpcyBwb2ludCB3 ZSBoYXZlIGRpc2NvdmVyZWQgd2hhdCBpcyB0aGUgY29tbW9uIHRoaW5nIGJldHdlZW4gTVBMUyBh bmQgRXRoZXJuZXQuLi4uaXQgaXMgdGhlIHRvcC1vZi1zdGFjayBJUCBsYXllciBuZXR3b3JrLiAg QW5kIHNvIHdlIHVsdGltYXRlbHkgcmVhbGlzZSB3ZSBjb3VsZCBoYXZlIHNhdmUgb3Vyc2VsdmVz IGEgbG9hZCBvZiB1bm5lY2Vzc2FyeSB3b3JrIGJ5IHNpbXBseSB0ZXJtaW5hdGluZyB0aGUgTVBM UyBhbmQgRXRoZXJuZXQgbGF5ZXIgbmV0d29yayBhdCB0aGUgaW50ZXJ3b3JraW5nIHBvaW50IGFu ZCBqdXN0IHBhc3NlZCB0aGUgSVAgbGF5ZXIgbmV0d29yayBhY3Jvc3MuDQogDQpTb3JyeSBJJ3Zl IGhhZCB0byBnbyB0aHJvdWdoIGFsbCB0aGlzIHlldCBhZ2FpbiAoZXNwIGZvciBhbGwgdGhlIGZv bGtzIHRoYXQgaGF2ZSBhbHJlYWR5IHVuZGVyc3Rvb2QgdGhlIHBvaW50KSBidXQgSSBkbyBob3Bl IGl0cyBjbGVhciBub3cgYW5kIHdlIGNhbiBwdXQgdGhpcyBpc3N1ZSB0byBiZWQuDQogDQpyZWdh cmRzLCBOZWlsIA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCglGcm9t OiBzdS5odWlAenRlLmNvbS5jbiBbbWFpbHRvOnN1Lmh1aUB6dGUuY29tLmNuXSANCglTZW50OiAy OSBBcHJpbCAyMDA5IDAzOjIyDQoJVG86IEhhcnJpc29uLE4sTmVpbCxDWE0gUg0KCUNjOiBhZHJp YW5Ab2xkZG9nLmNvLnVrOyBOaXZlbi1qZW5raW5zLEIsQmVuLERNRiBSOyBoaGVsdm9vcnRAY2hl bGxvLm5sOyBtcGxzLXRwQGlldGYub3JnOyBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCglTdWJq ZWN0OiDnrZTlpI06IFJlOiBbbXBscy10cF0gQUlTL0ZESSAod2FzIEFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQoJDQoJDQoNCglIaSBOZWlsLCAN CgkNCgnigJhpdCBpcyBxdWl0ZSBjbGVhciBmcm9tIGEgc2ltcGxlIHRlY2huaWNhbCBhbmFseXNp cyB0aGF0IGFueSBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5vIG5lZWQgZm9yIEUtTk5J IHBlZXItcGFydGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0aW5nIHBhcnRp ZXMu4oCZIA0KCQ0KCUkgY2Fubm90IGFncmVlIHRoaXMgc3RhdGVtZW50LiANCglGb3IgZXhhbXBs ZSwgdGhlcmUgYXJlIHR3byBJUCBuZXR3b3JrcyBiZWxvbmdpbmcgdG8gdHdvIG9wZXJhdG9ycywg YSBFMSBpcyB0cmFuc3BvcnRlZCBmcm9tIEEgbmV0d29yayB0byBCIG5ldHdvcmsgKGUuZy4gRTFv dmVyUFdvdmVySVAgKSwgSVAgcGFja2V0KG5vdCBFMSkgcGFzcyBhY3Jvc3MgZm9ybSBBIHRvIEIg YXQgYm9yZGVyIG5vZGUsIHNvIHRoZXJlIGlzIGEgRS1OTkkgYmV0d2VlbiB0aGVzZSAgdHdvIElQ IG5ldHdvcmsuIEluIHRoaXMgY2FzZSwgaXMgSVAgYSB0b3Atb2Ytc3RhY2sgbmV0d29yaz8gDQoJ Tm93IGxldCB1cyByZXBsYWNlIElQIG5ldHdvcmtzIGJ5IE1QTFMtVFAgbmV0d29ya3MgKGUuZy4g RTFvdmVyUFdvdmVyTVBMLVRQKSwgTVBMUy1UUCBuZXR3b3JrIGlzIGF0IHNhbWUgcG9zaXRpb24g aW4gdGhlIHN0YWNrIGFzIElQIG5ldHdvcmsgaXMsIHdoeSBjYW4gSVAgbmV0d29yayBoYXZlIEUt Tk5JIGJ1dCBNUExTLVRQIGNhbm5vdD8gDQoJDQoJUmVnYXJkLCANCglTdWh1aSANCgkNCgkNCgkN CjxuZWlsLjIuaGFycmlzb25AYnQuY29tPiANCuWPkeS7tuS6ujogIG1wbHMtdHAtYm91bmNlc0Bp ZXRmLm9yZyANCg0KMjAwOS0wNC0yOCAxNDo0MyANCg0K5pS25Lu25Lq6DQo8aGhlbHZvb3J0QGNo ZWxsby5ubD4sIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiwgPGJlbmphbWluLm5pdmVuLWplbmtpbnNA YnQuY29tPiANCuaKhOmAgQ0KbXBscy10cEBpZXRmLm9yZyANCuS4u+mimA0KUmU6IFttcGxzLXRw XSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoICAg ICAgICByZXF1aXJlbWVudHMpDQoNCgkNCg0KDQoNCg0KCUh1dWIgd3JvdGUgMjcgQXByaWwgMjAw OSAyMjoyNw0KCT4gDQoJPiBIaSBBZHJpYW4sDQoJPiANCgk+IFlvdSB3cm90ZToNCgk+IA0KCT4g PiBJc24ndCB0aGUgc29sdXRpb24gaGVyZSB0aGUgc2FtZSBhcyB0aGUgb25lIEkgcHJvcG9zZWQg Zm9yICJUQ00iPw0KCT4gDQoJPiBJbmRlZWQsIGFuZCB0aGF0IHdlIGRvIG5vdCBoYXZlIHRvIGFy b3VuZCBpbiBjaXJjbGVzIGFib3V0IFRDTS4NCgk+IA0KCT4gSG93IGFib3V0Og0KCT4gdGhlIHJl cXVpcmVtZW50IGlzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXIgc2hhbGwgaW5mb3JtIGl0cyBjbGllbnRz DQoJPiB0aGF0IGl0IGhhcyBkZXRlY3RlZCBhIHNlcnZpY2UgaW50ZXJ1cHRpb24sIHRoaXMgdG8g ZW5zdXJlIHRoYXQNCgk+IHRoZSBjbGllbnRzIGNhbiBpbmhpYml0ICh1bm5lY2Vzc2FyeSkgYWxh cm1zLg0KCQ0KCU5IPT4gVGhpcyBvbmx5IGFwcGxpZXMgaWYgdGhlIGNsaWVudC9zZXJ2ZXIgYmlu ZGluZyBpcyBmaXhlZC4gIEFuZCBvZg0KCWNvdXJzZSB3YXkgYmFjayBpbiB0aGUgNzBzIHdoZW4g YmluYXJ5IGFsbCAxcyBwb3BwZWQgb3V0IG9mIHRoZSBmYWlsZWQNCglUVEwgbG9naWMgaW50byB0 aGUgUERIIHRyYW5zcG9ydCBoaWVyYXJjaHkgdGhpcyB3YXMgdHJ1ZS4gIEFsc286IG5vDQoJbGFi ZWxzIGhlcmUgYW5kIG5vIGNsaWVudCB0cmFmZmljIHVuaXRzIHRvIGNyZWF0ZS4gICANCgkNCglX aGVyZSB0aGUgY2xpZW50IGNhbiBkeW5hbWljYWxseSBiZSByZS1yb3V0ZWQgaW4gcmVzcG9uc2Ug dG8gYSBzZXJ2ZXINCglmYWlsdXJlIHRoZSBwcm9wb3NlZCB0ZXh0IGlzIG5vdCB2YWxpZC4gIEl0 IGlzIGFsc28gbm90IG5lY2Vzc2FyeSB0aGF0DQoJdGhlIHNlcnZlciBoYXMgdG8ga2VlcCB0cmFj ayBvZiB3aGVyZSBpdHMgY2xpZW50IHRyYWZmaWMgcm91dGluZ3MgaGF2ZQ0KCW1vdmVkIHRvLiAg Rm9yIGV4YW1wbGUsIGlmIEkgY3JlYXRlIHRoZSB0b3BvbG9neSBvZiBhbiBJUCBsYXllciBuZXR3 b3JrDQoJd2l0aCBsaW5rcyBwcm92aWRlZCBieSBTREgsIEV0aGVybmV0LCBBVE0sIE9UTiwgZXRj IHNlcnZlcnMsIGFuZCBlYWNoIG9mDQoJdGhlc2Ugc2VydmVyIGxpbmtzIGlzIHByb3ZpZGVkIGJ5 IGEgZGlmZmVyZW50IG9wZXJhdG9yLCB0aGVuIHdoeSBzaG91bGQNCgl0aGUgc2VydmVycyBuZWVk IGhhdmUga25vd2xlZGdlIG9mIHdoZXJlIHRoZSBJUCBmbG93cyBoYXZlIG1vdmVkIHRvIGluDQoJ cmVzcG9uc2UgdG8gYSBzZXJ2ZXIgbGF5ZXIgZmFpbHVyZSB3aGVuIHRoZSBuZXcgcm91dGVzIGhh dmUgYmVlbg0KCWNhbGN1bGF0ZWQgYnkgdGhlIElHUCBpbiB0aGUgSVAgbGF5ZXIgbmV0d29yaz8g IEkgY2FuIGFwcGx5IHRoZSBzYW1lDQoJbG9naWMgdG8gYW4gU1ZDLWJhc2VkIGNvLXBzL2NvLWNz IG1vZGUgY2xpZW50Li4uLmluZGVlZCB0aGUgY28tY3MgbW9kZQ0KCVBTVE4gaXMgbGlrZSB0aGlz Lg0KCQ0KCVRoZXNlIG9ic2VydmF0aW9ucyBtYWtlIGl0IHF1aXRlIGNsZWFyIHRvIG1lIGF0IGxl YXN0IHRoYXQganVzdCBjb3B5aW5nDQoJdGhlIEFJUyBiZWhhdmlvdXIgb2YgdGhlIG9sZCB0cmFu c3BvcnQgaGllcmFyY2hpZXMgdGhhdCBoYWQgZml4ZWQNCgljbGllbnQvc2VydmVyIHJlbGF0aW9u c2hpcHMgaXMgbm90IGEgc2Vuc2libGUgdGhpbmcgdG8gZG8uDQoJDQoJSU1PIHRoZSBvbmx5IGVz c2VudGlhbCBEUCBPQU0gcmVxdWlyZW1lbnQgaXMgdGhhdCBlYWNoIGxheWVyIG5ldHdvcmsNCglz aG91bGQgYmUgc2VsZi1zdWZmaWNpZW50IHdydCBPQU0gYW5kIG5vdCByZWx5IG9uIGFueSBzZXJ2 ZXIgbGF5ZXINCglwcmltaXRpdmVzIGJlaW5nIHBhc3NlZCB1cHdhcmRzLg0KCQ0KCU1vcmVvdmVy LCBpdCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0IChpKSB0aGUgZGVmZWN0cyB0aGF0IGNhbiBv Y2N1ciBpbg0KCWVhY2ggb2YgdGhlIDMgbmV0d29yayBtb2RlcyBhcmUgbm90IHRoZSBzYW1lIGFu ZCAoaWkpIHRoZWlyIE9BTQ0KCXJlcXVpcmVtZW50cyBhcmUgbm90IGlkZW50aWNhbGx5IHRoZSBz YW1lLiBTbyB0aGUgT0FNIHRoYXQgYXBwbGllcyB0bw0KCXRoZSBjbC1wcyBtb2RlIChlZyBJUCkg aXMgbm90IHRoZSBzYW1lIGFzIHRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvIHRoZQ0KCWNvLXBzIG1v ZGUgKGVnIE1QTFMtVFApIGFuZCBuZWl0aGVyIG9mIHRoZXNlIGlzIGlkZW50aWNhbGx5IHRoZSBz YW1lIGFzDQoJdGhlIE9BTSB0aGF0IGFwcGxpZXMgdG8gdGhlIGNvLWNzIG1vZGUgKGVnIFNESCku DQoJDQoJTm90ZSAtIFRoZSBvbmx5IHBvaW50IGJlaW5nIGNvbnNpZGVyZWQgaGVyZSBpcyB0aGUg cmVhbCBjbGllbnQgYW5kDQoJc2VydmVyIHRyYWZmaWMgcmVsYXRpb25zaGlwLiAgVGhlIGNyZWF0 aW9uIG9mIGEgaGllcmFyY2h5IG9mIFRDTQ0KCXN1YmxheWVycyBpcyBhIHNlcGFyYXRlIHRvcGlj LiAgRnVydGhlciwgaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhIHNpbXBsZQ0KCXRlY2huaWNhbCBh bmFseXNpcyB0aGF0IGFueSBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5vIG5lZWQgZm9y DQoJRS1OTkkgcGVlci1wYXJ0aXRpb24gd29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBvcGVyYXRp bmcgcGFydGllcy4gIFNvDQoJdGhpcyBpcyBhbHNvIGEgc2VwYXJhdGUgaXNzdWUuICBIb3dldmVy LCBJIHByb3Bvc2UgdGhhdCB0aGlzIGxhdHRlcg0KCXBvaW50IGJlIGNhcHR1cmVkIGluIHRoZSBN UExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdCBkdWUgdG8gaXRzDQoJc3RhbmQtYWxvbmUgYW5kIGdl bmVyaWMgaW1wb3J0YW5jZSwgaWUgdGhpcyBhcHBsaWVzIHRvIG1vcmUgdGhhbiBqdXN0IERQDQoJ T0FNLiAgQmVuIGNhbiB5b3UgcGxlYXNlIGNvbnNpZGVyIHRoaXMgcG9pbnQgYXMvd2hlbiB0aGUg TVBMUy1UUA0KCXJlcXVpcmVtZW50cyBkcmFmdCBpcyB1cGRhdGVkLg0KCQ0KCXJlZ2FyZHMsIE5l aWwNCgkNCgk+IENoZWVycywgSHV1Yi4NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KCW1wbHMtdHAgbWFpbGluZyBsaXN0DQoJbXBscy10cEBpZXRmLm9y Zw0KCWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KCQ0KCQ0K CQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoJWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8gb3RoZXJzLg0KCVRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCglUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg0K ------_=_NextPart_001_01C9C895.6A2C361C Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTA0MDUyMDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5UaGFua3MgU2h1aHVpLDwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTA0 MDUyMDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAw IHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9ODkwNDA1MjA1LTI5MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2Fu cyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+RG8gbm90IGNvbmZ1c2UgcGh5c2ljYWwgaW50ZXJj b25uZWN0IA0Kd2l0aCBFLU5OSS4uLi4uSSdsbCBjb21lIGJhY2smbmJzcDtvbiB0aGlzIHNob3J0 bHkgd2hlbiBkaXNjdXNzaW5nIHRoZSANCmJvdHRvbS1vZi1zdGFjayBzZWN0aW9uIGxheWVyLjwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04 OTA0MDUyMDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAw MDAwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9ODkwNDA1MjA1LTI5MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMg U2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+VGhlIGZpcnN0IHRoaW5nIHRvIHVuZGVyc3Rh bmQgaXMgdGhhdCANCiphbGwqIG5ldHdvcmtzIGFyZSB0aGVyZSB0byB1bHRpbWF0ZWx5IHN1cHBv cnQgb25lIHB1cnBvc2UuLi4uLmFuZCB0aGF0IGlzIHRvIA0KYWxsb3cgY29tbXVuaWNhdGlvbnMg YmV0d2VlbiBwYXJ0aWVzIHRoYXQgYXJlICpleHRlcm5hbCogdG8gdGhlIG5ldHdvcmtzLiZuYnNw OyANClNvIGV2ZXJ5dGhpbmcgd2UgZG8gaW4gbmV0d29ya2luZyBpcyB0aGVyZSB0byB1bHRpbWF0 ZWx5IHN1cHBvcnQgdGhpcyANCm9iamVjdGl2ZS4mbmJzcDsgV2hhdCB0aGlzIG1lYW5zIGlzIHRo YXQgdGhlIERQIG9mIHNvbWUgbmV0d29yayAod2hhdCBJIGNhbGwgdGhlIA0KdG9wLW9mLXN0YWNr IG5ldHdvcmspIE1VU1QgYmUgcHJvdmlkaW5nIGFkYXB0YXRpb24gZnVuY3Rpb25zIGZvciB0aGVz ZSBleHRlcm5hbCANCmFwcGxpY2F0aW9ucy4uLi4uLi5hbmQgdGhlc2UgY2FuIGdlbmVyaWNhbGx5 IGJlIGNsYXNzaWZpZWQgYXMgbWVzc2FnZXMsIGZpbGVzIA0KYW5kIHN0cmVhbXMuJm5ic3A7PC9G T05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5 MDQwNTIwNS0yOTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48U1BBTiBjbGFzcz04OTA0MDUyMDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBT YW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5XZSBjYW4gc2VlIHRoYXQgSVAgaXMgYSB0b3At b2Ytc3RhY2sgDQpuZXR3b3JrIGFzIGl0IGhhcyBVRFAvVENQL1JUUCAoZm9yIGV4YW1wbGUpIGFk YXB0YXRpb25zLiZuYnNwOyBBVE0gd2FzIGFsc28gb25jZSANCih+OTBzKSBpbnRlbmRlZCB0byBi ZSBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGFuZCBpdCBoYWQgaXRzIG93biBhcHBsaWNhdGlvbiAN CmFkYXB0YXRpb25zIGluIHRoZSBmb3JtIG9mIEFBTHMuJm5ic3A7IEF0IG9uZSBzdGFnZSB0aGVy ZSB3ZXJlIDUgb2YgdGhlc2UsIGJ1dCANCmluIHByYWN0aWNlIG9ubHkgYSBjb3VwbGUgd2VyZSBy ZWFsbHkgc3VjY2Vzc2Z1bCBiZWNhdXNlIG9mIHRoZSBnZW5lcmljIG5hdHVyZSANCm9mIG1lc3Nh Z2UvZmlsZS9zdHJlYW0gY2xhc3NpZmljYXRpb24uJm5ic3A7IFRoZSBQU1ROIGlzIGFsc28gdG9w LW9mLXN0YWNrLCBhbmQgDQppdHMgYXBwbGljYXRpb24gYWRhcHRhdGlvbiB3YXMgbWFpbmx5IGZv ciB2b2ljZSAoc3RyZWFtKSANCnN1cHBvcnQuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5MDQwNTIwNS0yOTA0MjAwOT48Rk9OVCANCmZh Y2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTA0MDUyMDUt MjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9 Mj5Nb3N0IG90aGVyIG5ldHdvcmtzIGRvIG5vdCBoYXZlIHRoZXNlIA0KYXBwbGljYXRpb24gYWRh cHRhdGlvbiBmdW5jdGlvbnMuLi4uc28gdGhleSBkbyBub3QgZGlyZWN0bHkgc3VwcG9ydCANCmFw cGxpY2F0aW9ucy4mbmJzcDsgV2hhdCB0aGlzIG1lYW5zIGluIHByYWN0aWNlIGlzIHRoYXQgdGhl c2UgbmV0d29ya3MgKGEgbGlzdCANCndoaWNoIGluY2x1ZGVzJm5ic3A7UERILCBTREgsIE9UTiwg RXRoZXJuZXQsIE1QTFMpIE1VU1QgY2FycnkgYSBmdXJ0aGVyIGxheWVyIA0KbmV0d29yayBhYm92 ZSB0aGVtIHRoYXQgaXMgdG9wLW9mLXN0YWNrLi4uLmxpa2UgSVAuJm5ic3A7IFRoZXJlIGlzIG5v IGNob2ljZSBpbiANCnRoZSBtYXR0ZXIgaGVyZS4mbmJzcDsgU28gd2hpbHN0IHdlIG1pZ2h0IHNh eSB0aGF0IGFuIE1QTFMgbmV0d29yayBpcyBjYXJyeWluZyANCmFuIEUxIFBXIHRoZSBFMSBlbnRp dHkgbXVzdCBpbiB0dXJuIGJlIGNhcnJ5aW5nIHNvbWUgb3RoZXIgdG9wLW9mLXN0YWNrIG5ldHdv cmsgDQoobGlrZSBJUCBvciBQU1ROKSwgZWxzZSBpdCBpcyBzZXJ2aW5nIG5vIHVsdGltYXRlIHB1 cnBvc2UuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTg5MDQwNTIwNS0yOTA0MjAwOT48L1NQQU4+PFNQQU4gDQpjbGFzcz04OTA0MDUyMDUt MjkwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCnNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ QU4gY2xhc3M9ODkwNDA1MjA1LTI5MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIg Y29sb3I9IzgwMDAwMCBzaXplPTI+Tm93IGluIG9yZGVyIHRvIHRyYW5zbWl0IGluZm9ybWF0aW9u IA0Kb3ZlciBnZW9ncmFwaGljIGRpc3RhbmNlIHdlIG11c3QgbW9kdWxhdGUgYW4gRU0gd2F2ZSBv biBzb21lIA0KbWV0YWxsaWMvb3B0aWNhbC9yYWRpbyBtZWRpYS4uLi50aGlzIGlzIHRoZSBib3R0 b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4mbmJzcDsgDQpUaGVzZSBhcmUgaGlnaCBiaXQgcmF0 ZSB0cmFuc3BvcnQgcGlwZXMgd2hvc2UgZnVuY3Rpb24gaXMgdG8gcHJvdmlkZSB0cmFuc3BhcmVu dCANCih3aGljaCBJIGhhdmUgZGVmaW5lZCBwcmV2aW91c2x5KSB0cmFuc3BvcnQgdG8gd2hhdGV2 ZXIgY2xpZW50IGxheWVycyBuZXR3b3JrcyANCnNpdCBhYm92ZSB0aGVtLi4uLmFuZCB3aGVyZSwg YXMgSSBub3RlZCBhYm92ZSwgdGhlcmUgTVVTVCBiZSBhIHRvcC1vZi1zdGFjayANCm5ldHdvcmsg cHJlc2VudCBhcyB0aGUgdWx0aW1hdGUgbGF5ZXIgbmV0d29yayBjbGllbnQgZWxzZSB0aGVyZSBp cyBub3QgZXh0ZXJuYWwgDQpwYXJ0eSBjb21tdW5pY2F0aW9uIHBvc3NpYmxlLjwvRk9OVD48L1NQ QU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTA0MDUyMDUt MjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ QU4gY2xhc3M9ODkwNDA1MjA1LTI5MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIg Y29sb3I9IzgwMDAwMCBzaXplPTI+U28gd2hlbiB3ZSBjb25uZWN0IHRvZ2V0aGVyIDIgDQp0b3At b2Ytc3RhY2sgbmV0d29ya3Mgd2UgZG8gc28gYXQgYSBzZWN0aW9uIGxheWVyIHdoaWNoIGlzIGlu dmFyaWFibHkgY2FycnlpbmcgYSANCnZlcnkgbGFyZ2UgYWdncmVnYXRlIG9mIGFwcGxpY2F0aW9u cy4uLi4uYW5kIG9mIGNvdXJzZSB0aGVzZSBhcHBsaWNhdGlvbnMgY2FuIGJlIA0KYSB0aW1lIHZh cnlpbmcgbWl4IG9mIG1lc3NhZ2UvZmlsZS9zdHJlYW0gY2FzZXMgd2l0aCBhIHNldCBvZiB1bmtu b3duICh0byB0aGUgDQpzZWN0aW9uIGxheWVyKSBpbXBvcnRhbmNlJ3MgKGVyZ28gd2h5IHRyYW5z cGFyZW5jeSBpcyBhbiBlc3NlbnRpYWwgcmVxdWlyZW1lbnQgDQppbiB0cmFuc3BvcnQgbmV0d29y a3MpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz04OTA0MDUyMDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9ODkwNDA1MjA1LTI5MDQyMDA5PjxGT05UIA0KZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+VGhlIHJlYWwgRS1OTklzICh3aGlj aCBjb25zaWRlcnMgYm90aCANCkRQIGFuZCBDUCBjb21wb25lbnRzLi4uLndlIG5ldmVyIHVzdWFs bHkgcGVlciB0aGUgTVAsIGFuZCB3ZSByZXN0cmljdCB0aGUgc2NvcGUgDQpvZiB0aGUgQ1ApIGV4 aXN0IGluIHRoZSB0b3Atb2Ytc3RhY2sgbGF5ZXIgbmV0d29yay4mbmJzcDsgVGhlIHNlY3Rpb24g bGF5ZXIgDQppbnRlcmNvbm5lY3QgaXMgYSBkdW1iIERQIHBpcGUuLi5pdCBqdXN0IHNoaWZ0cyBi aXRzIHRyYW5zcGFyZW50bHkgYW5kIG1haW50YWlucyANCnRoZWlyIG9yZGVyaW5nLiZuYnNwOyBU aGVyZSBpcyBubyBjb25jZXB0IG9mIENQIChvciBNUCkgcGVlcmluZyBvbiB0aGVzZSANCmJvdHRv bS1vZi1zdGFjayBzZWN0aW9uIGxheWVyIGludGVyY29ubmVjdHMuPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5MDQwNTIwNS0yOTA0MjAw OT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPkFzaWRl PSZndDsgSW4gc29tZSBjb3VudHJpZXMgdGhlc2UgDQppbnRlcmNvbm5lY3RzIGhhdmUgdG8gYmUg Y2FyZWZ1bGx5IHNwZWNpZmllZCBpbiBvcmRlciB0byBkaXN0aW5ndWlzaCByZWd1bGF0ZWQgDQph bmQgdW5yZWd1bGF0ZWQgc2VydmljZXMuLi4uLnNvIHRoZXJlIGFyZSBpbXBvcnRhbnQgbGVnYWwv Y29tbWVyY2lhbCANCmNvbnNpZGVyYXRpb25zIGhlcmUsIGl0IGlzIG5vdCBzaW1wbHkgYSB0ZWNo bmljYWwgaXNzdWUuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0 PjxTUEFOIGNsYXNzPTg5MDQwNTIwNS0yOTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMg TVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTA0MDUyMDUtMjkwNDIwMDk+PEZPTlQg DQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5XZSBjYW4gb2YgY291 cnNlIGNyZWF0ZSBFLU5OSXMgaW4gbm9uIA0KdG9wLW9mLXN0YWNrIGxheWVyIG5ldHdvcmtzICh3 ZSBjYW4gZG8gbWFueSB0aGluZ3MgdGhhdCBhcmUgbm90IHVzZWZ1bCkuJm5ic3A7IA0KU28gbGV0 cyBhc3N1bWUgd2UgZG8gdGhpcy4uLi4uYW5kIGxldHMgYXNzdW1lIHdlIGNob29zZSBNUExTIHNp bmNlIHlvdSBtZW50aW9uIA0KdGhpcyBpbiB0aGUgbWFpbCBiZWxvdy4mbmJzcDs8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9ODkwNDA1MjA1 LTI5MDQyMDA5PjxGT05UIA0KZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTg5MDQwNTIwNS0yOTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMi IGNvbG9yPSM4MDAwMDAgc2l6ZT0yPk5vdyBob3cgZG8gZXh0ZXJuYWwgcGFydGllcyB3aG8gd2lz aCANCnRvIGNvbW11bmljYXRlIGludGVyZmFjZSB3aXRoIHRoaXMgTVBMUyBuZXR3b3JrPyZuYnNw OyBDYW4geW91IHN1cHBvcnQgYWxsIHR5cGVzIA0Kb2YgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBs aWNhdGlvbnMgKmRpcmVjdGx5KiBpbnRvIE1QTFM/Jm5ic3A7IEluIHByaW5jaXBsZSB5b3UgDQpj b3VsZCBpZiB5b3UgYWxsb3dlZCBNUExTIHRvIGhhdmUgZW5kIHN5c3RlbSBhcHBsaWNhdGlvbiBh ZGFwdGF0aW9ucyBzdWNoIGFzIA0KVURQL1RDUC9SVFAgb3IgdGhlIGxpa2UuJm5ic3A7IEJ1dCB0 aGVzZSBkb24ndCBleGlzdCB0b2RheSwgYW5kIGluIHRoZSBtb3N0IA0KdXN1YWwgY2FzZSB0aGUg TVBMUyBuZXR3b3JrIHdpbGwgY2FycnkgYW4gSVAgbGF5ZXIgbmV0d29yayBiZWNhdXNlIHRoaXMg Y2FuIA0Kc3VwcG9ydCB0aGUgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMuPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5MDQw NTIwNS0yOTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAg c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTiBjbGFzcz04OTA0MDUyMDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5z IE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5XZSBjYW4gZ28gdGhyb3VnaCBleGFjdGx5IHRoZSBz YW1lIA0KYW5hbHlzaXMgd2l0aCBhbnkgbmV0d29yayB0aGF0IGlzIG5vdCB0b3Atb2Ytc3RhY2ss IGVnIEV0aGVybmV0LiZuYnNwOyBBbmQgd2hlbiANCnlvdSBkbyB0aGlzIHdoYXQgeW91IHJlYWxp c2UgaXMgdGhhdCBhbHRob3VnaCB3ZSBjYW4gY3JlYXRlIHBlZXIgaW50ZXJ3b3JraW5nIG9mIA0K TVBMUyAob3Igd2hhdGV2ZXIpIHRoaXMgaGFzIG5vdCByZWFsbHkgaGVscGVkIHNpbmNlIHdlIG1p Z2h0IGFzIHdlbGwgaGF2ZSBqdXN0IA0KdGVybWluYXRlZCB0aGUgTVBMUyBuZXR3b3JrIGFuZCBw YXNzZWQgdGhlIElQIGxheWVyIGFjcm9zcy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9ODkwNDA1MjA1LTI5MDQyMDA5PjxGT05UIA0KZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJz cDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5MDQwNTIwNS0y OTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0y Pk5vdyB0aGUgYWJvdmUgYmVjb21lcyBldmVuIG1vcmUgDQpzdHJpa2luZyBpbiBpdHMgaW1wb3J0 YW5jZSBpZiB5b3UgY29uc2lkZXIgcGVlciBpbnRlcndvcmtpbmcgb2YgMiBkaWZmZXJlbnQgbm9u IA0KdG9wLW9mLXN0YWNrIG5ldHdvcmtzLi4uLmxldHMgcGljayBNUExTIGFuZCBFdGhlcm5ldCBi ZWNhdXNlIHRoYXQgaXMgd2hhdCBpcyANCm9mdGVuIG1lbnRpb25lZC4mbmJzcDsgPC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5MDQwNTIw NS0yOTA0MjAwOT48Rk9OVCANCmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz04OTA0MDUyMDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1T IiBjb2xvcj0jODAwMDAwIHNpemU9Mj5XaGF0IHdlIGhhdmUgdG8gZG8gbm93IGF0IHRoZSBFLU5O SXMgDQpiZXR3ZWVuIEV0aGVybmV0IGFuZCBNUExTIGlzIGdvIHRocm91Z2ggZWFjaCBEUCBhbmQg Q1AgY29tcG9uZW50IGFuZCBkbyBhIA0KJ3Byb3RvY29sIGNvbnZlcnNpb24nIGV4ZXJjaXNlIHdo ZXJlIHJlcXVpcmVkLi4uLi4uYW5kIHRoZSBmaXJzdCBwcm9ibGVtIHlvdSANCndpbGwgZW5jb3Vu dGVyIGlzIHRoYXQgdGhlcmUgd2lsbCBiZSBsb3RzIG9mIGZ1bmN0aW9uYWwgbWlzbWF0Y2guJm5i c3A7IE1vcmVvdmVyIA0KaWYgb25lIG9yIGJvdGgmbmJzcDtvZiB0aGUgbmV0d29ya3MgY2FuIHN1 cHBvcnQgbXVsdGlwbGUgQ1AgdHlwZXMgbGlrZSBNUExTIGNhbiwgDQplZyBSU1ZQLVRFIHNpZ25h bGxpbmcsIExEUCBzaWduYWxsaW5nLCBCR1A0ICdzaWduYWxsaW5nJywgT1NQRiByb3V0aW5nLCBJ Uy1JUyANCnJvdXRpbmcuLi4uLmFuZCBJIGNvdWxkIGxpc3Qgc2ltaWxhciBmb3IgRXRoZXJuZXQu Li4uLnlvdSBhcmUgZ29pbmcgdG8gaGF2ZSB0byANCmNvbnNpZGVyIGVhY2ggcGFpcmluZyBjYXNl IGluIHR1cm4uJm5ic3A7IEEgbG90IG9mIHdvcmsuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5MDQwNTIwNS0yOTA0MjAwOT48Rk9OVCAN CmZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTA0MDUy MDUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNp emU9Mj5BbmQgd2hlbiB5b3UgaGF2ZSBkb25lIGFsbCB0aGlzIHlvdSANCmFzayB0aGUgcXVlc3Rp b24gJ3doYXQgaXMgaXQgdGhhdCBjYXJyaWVzIHRoZSByZWFsIGV4dGVybmFsIG1lc3NhZ2UvZmls ZS9zdHJlYW0gDQphcHBsaWNhdGlvbnMgaW4gdGhlIERQIGhlcmU/Jy4uLi4uLi5hbmQgbm93IHlv dSBmaW5kIG5vIG5hdGl2ZSBzdXBwb3J0IGZvciB0aGVzZSANCmluIE1QTFMgb3IgRXRoZXJuZXQs IGJ1dCB3aGF0IHdlIGRvIGZpbmQgaXMgdGhhdCBib3RoIG9mIHRoZW0gYXJlIGNhcnJ5aW5nIElQ IA0KYmVjYXVzZSB0aGlzIGRvZXMgc3VwcG9ydCB0aGUgZXh0ZXJuYWwgYXBwbGljYXRpb25zLiZu YnNwOyBOb3cgYXQgdGhpcyBwb2ludCB3ZSANCmhhdmUgZGlzY292ZXJlZCB3aGF0IGlzIHRoZSBj b21tb24gdGhpbmcgYmV0d2VlbiBNUExTIGFuZCBFdGhlcm5ldC4uLi5pdCBpcyB0aGUgDQp0b3At b2Ytc3RhY2sgSVAgbGF5ZXIgbmV0d29yay4mbmJzcDsgQW5kIHNvIHdlIHVsdGltYXRlbHkgcmVh bGlzZSB3ZSBjb3VsZCBoYXZlIA0Kc2F2ZSBvdXJzZWx2ZXMgYSBsb2FkIG9mIHVubmVjZXNzYXJ5 IHdvcmsgYnkgc2ltcGx5IHRlcm1pbmF0aW5nIHRoZSBNUExTIGFuZCANCkV0aGVybmV0IGxheWVy IG5ldHdvcmsgYXQgdGhlIGludGVyd29ya2luZyBwb2ludCBhbmQganVzdCBwYXNzZWQgdGhlIElQ IGxheWVyIA0KbmV0d29yayBhY3Jvc3MuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTg5MDQwNTIwNS0yOTA0MjAwOT48L1NQQU4+Jm5ic3A7 PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTA0MDUyMDUtMjkw NDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5T b3JyeSBJJ3ZlIGhhZCB0byBnbyB0aHJvdWdoIGFsbCB0aGlzIA0KeWV0IGFnYWluIChlc3AgZm9y IGFsbCB0aGUgZm9sa3MgdGhhdCBoYXZlIGFscmVhZHkgdW5kZXJzdG9vZCB0aGUgcG9pbnQpIGJ1 dCBJIA0KZG8gaG9wZSBpdHMgY2xlYXIgbm93IGFuZCB3ZSBjYW4gcHV0IHRoaXMgaXNzdWUgdG8g YmVkLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz04OTA0MDUyMDUtMjkwNDIwMDk+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9ODkwNDA1MjA1LTI5MDQyMDA5PjxGT05UIA0KZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+cmVnYXJkcywgDQpOZWlsPC9GT05U PiZuYnNwOzwvU1BBTj48L0RJVj48QlI+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzgwMDAwMCAy cHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2Fn ZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4PS0x Pg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IHN1Lmh1aUB6dGUuY29t LmNuIA0KICBbbWFpbHRvOnN1Lmh1aUB6dGUuY29tLmNuXSA8QlI+PEI+U2VudDo8L0I+IDI5IEFw cmlsIDIwMDkgMDM6MjI8QlI+PEI+VG86PC9CPiANCiAgSGFycmlzb24sTixOZWlsLENYTSBSPEJS PjxCPkNjOjwvQj4gYWRyaWFuQG9sZGRvZy5jby51azsgDQogIE5pdmVuLWplbmtpbnMsQixCZW4s RE1GIFI7IGhoZWx2b29ydEBjaGVsbG8ubmw7IG1wbHMtdHBAaWV0Zi5vcmc7IA0KICBtcGxzLXRw LWJvdW5jZXNAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IOetlOWkjTogUmU6IFttcGxzLXRw XSBBSVMvRkRJICh3YXMgDQogIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0 aCByZXF1aXJlbWVudHMpPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+PC9ESVY+PEJSPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+SGkgTmVpbCw8L0ZPTlQ+IDxCUj48QlI+PEZPTlQg DQogIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+4oCYaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhIHNp bXBsZSB0ZWNobmljYWwgYW5hbHlzaXMgDQogIHRoYXQgYW55IG5vbiB0b3Atb2Ytc3RhY2sgbmV0 d29yayBoYXMgbm8gbmVlZCBmb3IgRS1OTkkgcGVlci1wYXJ0aXRpb24gd29ya2luZyANCiAgYmV0 d2VlbiBkaWZmZXJlbnQgb3BlcmF0aW5nIHBhcnRpZXMu4oCZPC9GT05UPiA8QlI+PEJSPjxGT05U IGZhY2U9c2Fucy1zZXJpZiANCiAgc2l6ZT0yPkkgY2Fubm90IGFncmVlIHRoaXMgc3RhdGVtZW50 LiA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCiAgc2l6ZT0yPkZvciBleGFtcGxl LCB0aGVyZSBhcmUgdHdvIElQIG5ldHdvcmtzIGJlbG9uZ2luZyB0byB0d28gb3BlcmF0b3JzLCBh IEUxIA0KICBpcyB0cmFuc3BvcnRlZCBmcm9tIEEgbmV0d29yayB0byBCIG5ldHdvcmsgKGUuZy4g RTFvdmVyUFdvdmVySVAgKSwgSVAgDQogIHBhY2tldChub3QgRTEpIHBhc3MgYWNyb3NzIGZvcm0g QSB0byBCIGF0IGJvcmRlciBub2RlLCBzbyB0aGVyZSBpcyBhIEUtTk5JIA0KICBiZXR3ZWVuIHRo ZXNlICZuYnNwO3R3byBJUCBuZXR3b3JrLiBJbiB0aGlzIGNhc2UsIGlzIElQIGEgdG9wLW9mLXN0 YWNrIA0KICBuZXR3b3JrPzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+ Tm93IGxldCB1cyByZXBsYWNlIElQIA0KICBuZXR3b3JrcyBieSBNUExTLVRQIG5ldHdvcmtzIChl LmcuIEUxb3ZlclBXb3Zlck1QTC1UUCksIE1QTFMtVFAgbmV0d29yayBpcyBhdCANCiAgc2FtZSBw b3NpdGlvbiBpbiB0aGUgc3RhY2sgYXMgSVAgbmV0d29yayBpcywgd2h5IGNhbiBJUCBuZXR3b3Jr IGhhdmUgRS1OTkkgYnV0IA0KICBNUExTLVRQIGNhbm5vdD88L0ZPTlQ+IDxCUj48QlI+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj5SZWdhcmQsPC9GT05UPiANCiAgPEJSPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+U3VodWk8L0ZPTlQ+IDxCUj48QlI+PEJSPg0KICA8VEFCTEUgd2lk dGg9IjEwMCUiPg0KICAgIDxUQk9EWT4NCiAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgIDxURCB3 aWR0aD0iMjYlIj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQogICAgICAgIHNpemU9MT48Qj4mbHQ7 bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZndDs8L0I+IDwvRk9OVD48QlI+PEZPTlQgDQogICAgICAg IGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+5Y+R5Lu25Lq6OiAmbmJzcDttcGxzLXRwLWJvdW5jZXNA aWV0Zi5vcmc8L0ZPTlQ+IA0KICAgICAgICA8UD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0x PjIwMDktMDQtMjggMTQ6NDM8L0ZPTlQ+IDwvUD4NCiAgICAgIDxURCB3aWR0aD0iNzMlIj4NCiAg ICAgICAgPFRBQkxFIHdpZHRoPSIxMDAlIj4NCiAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAg PFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgICA8VEQ+DQogICAgICAgICAgICAgIDxESVYgYWxp Z249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7mlLbku7bkuro8L0ZPTlQ+PC9E SVY+DQogICAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4mbHQ7aGhl bHZvb3J0QGNoZWxsby5ubCZndDssIA0KICAgICAgICAgICAgICAmbHQ7YWRyaWFuQG9sZGRvZy5j by51ayZndDssIA0KICAgICAgICAgICAgICAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5j b20mZ3Q7PC9GT05UPiANCiAgICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICAgIDxU RD4NCiAgICAgICAgICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYg c2l6ZT0xPuaKhOmAgTwvRk9OVD48L0RJVj4NCiAgICAgICAgICAgIDxURD48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0xPm1wbHMtdHBAaWV0Zi5vcmc8L0ZPTlQ+IA0KICAgICAgICAgIDxUUiB2 QWxpZ249dG9wPg0KICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJp Z2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+5Li76aKYPC9GT05UPjwvRElWPg0KICAg ICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+UmU6IFttcGxzLXRwXSBB SVMvRkRJICh3YXMgDQogICAgICAgICAgICAgIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAgICAgICAgICAgJm5ic3A7cmVx dWlyZW1lbnRzKTwvRk9OVD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+DQogICAgICAgIDxUQUJM RT4NCiAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAg ICAgICA8VEQ+DQogICAgICAgICAgICA8VEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjwvVFI+ PC9UQk9EWT48L1RBQkxFPjxCUj48QlI+PEJSPjxGT05UIA0KICBzaXplPTI+PFRUPkh1dWIgd3Jv dGUgMjcgQXByaWwgMjAwOSAyMjoyNzxCUj4mZ3Q7IDxCUj4mZ3Q7IEhpIEFkcmlhbiw8QlI+Jmd0 OyANCiAgPEJSPiZndDsgWW91IHdyb3RlOjxCUj4mZ3Q7IDxCUj4mZ3Q7ICZndDsgSXNuJ3QgdGhl IHNvbHV0aW9uIGhlcmUgdGhlIHNhbWUgYXMgDQogIHRoZSBvbmUgSSBwcm9wb3NlZCBmb3IgIlRD TSI/PEJSPiZndDsgPEJSPiZndDsgSW5kZWVkLCBhbmQgdGhhdCB3ZSBkbyBub3QgaGF2ZSANCiAg dG8gYXJvdW5kIGluIGNpcmNsZXMgYWJvdXQgVENNLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEhvdyBhYm91 dDo8QlI+Jmd0OyB0aGUgDQogIHJlcXVpcmVtZW50IGlzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXIgc2hh bGwgaW5mb3JtIGl0cyBjbGllbnRzPEJSPiZndDsgdGhhdCBpdCANCiAgaGFzIGRldGVjdGVkIGEg c2VydmljZSBpbnRlcnVwdGlvbiwgdGhpcyB0byBlbnN1cmUgdGhhdDxCUj4mZ3Q7IHRoZSBjbGll bnRzIA0KICBjYW4gaW5oaWJpdCAodW5uZWNlc3NhcnkpIGFsYXJtcy48QlI+PEJSPk5IPSZndDsg VGhpcyBvbmx5IGFwcGxpZXMgaWYgdGhlIA0KICBjbGllbnQvc2VydmVyIGJpbmRpbmcgaXMgZml4 ZWQuICZuYnNwO0FuZCBvZjxCUj5jb3Vyc2Ugd2F5IGJhY2sgaW4gdGhlIDcwcyANCiAgd2hlbiBi aW5hcnkgYWxsIDFzIHBvcHBlZCBvdXQgb2YgdGhlIGZhaWxlZDxCUj5UVEwgbG9naWMgaW50byB0 aGUgUERIIA0KICB0cmFuc3BvcnQgaGllcmFyY2h5IHRoaXMgd2FzIHRydWUuICZuYnNwO0Fsc286 IG5vPEJSPmxhYmVscyBoZXJlIGFuZCBubyBjbGllbnQgDQogIHRyYWZmaWMgdW5pdHMgdG8gY3Jl YXRlLiAmbmJzcDsgPEJSPjxCUj5XaGVyZSB0aGUgY2xpZW50IGNhbiBkeW5hbWljYWxseSBiZSAN CiAgcmUtcm91dGVkIGluIHJlc3BvbnNlIHRvIGEgc2VydmVyPEJSPmZhaWx1cmUgdGhlIHByb3Bv c2VkIHRleHQgaXMgbm90IHZhbGlkLiANCiAgJm5ic3A7SXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5 IHRoYXQ8QlI+dGhlIHNlcnZlciBoYXMgdG8ga2VlcCB0cmFjayBvZiB3aGVyZSANCiAgaXRzIGNs aWVudCB0cmFmZmljIHJvdXRpbmdzIGhhdmU8QlI+bW92ZWQgdG8uICZuYnNwO0ZvciBleGFtcGxl LCBpZiBJIGNyZWF0ZSANCiAgdGhlIHRvcG9sb2d5IG9mIGFuIElQIGxheWVyIG5ldHdvcms8QlI+ d2l0aCBsaW5rcyBwcm92aWRlZCBieSBTREgsIEV0aGVybmV0LCANCiAgQVRNLCBPVE4sIGV0YyBz ZXJ2ZXJzLCBhbmQgZWFjaCBvZjxCUj50aGVzZSBzZXJ2ZXIgbGlua3MgaXMgcHJvdmlkZWQgYnkg YSANCiAgZGlmZmVyZW50IG9wZXJhdG9yLCB0aGVuIHdoeSBzaG91bGQ8QlI+dGhlIHNlcnZlcnMg bmVlZCBoYXZlIGtub3dsZWRnZSBvZiANCiAgd2hlcmUgdGhlIElQIGZsb3dzIGhhdmUgbW92ZWQg dG8gaW48QlI+cmVzcG9uc2UgdG8gYSBzZXJ2ZXIgbGF5ZXIgZmFpbHVyZSB3aGVuIA0KICB0aGUg bmV3IHJvdXRlcyBoYXZlIGJlZW48QlI+Y2FsY3VsYXRlZCBieSB0aGUgSUdQIGluIHRoZSBJUCBs YXllciBuZXR3b3JrPyANCiAgJm5ic3A7SSBjYW4gYXBwbHkgdGhlIHNhbWU8QlI+bG9naWMgdG8g YW4gU1ZDLWJhc2VkIGNvLXBzL2NvLWNzIG1vZGUgDQogIGNsaWVudC4uLi5pbmRlZWQgdGhlIGNv LWNzIG1vZGU8QlI+UFNUTiBpcyBsaWtlIHRoaXMuPEJSPjxCUj5UaGVzZSANCiAgb2JzZXJ2YXRp b25zIG1ha2UgaXQgcXVpdGUgY2xlYXIgdG8gbWUgYXQgbGVhc3QgdGhhdCBqdXN0IGNvcHlpbmc8 QlI+dGhlIEFJUyANCiAgYmVoYXZpb3VyIG9mIHRoZSBvbGQgdHJhbnNwb3J0IGhpZXJhcmNoaWVz IHRoYXQgaGFkIGZpeGVkPEJSPmNsaWVudC9zZXJ2ZXIgDQogIHJlbGF0aW9uc2hpcHMgaXMgbm90 IGEgc2Vuc2libGUgdGhpbmcgdG8gZG8uPEJSPjxCUj5JTU8gdGhlIG9ubHkgZXNzZW50aWFsIERQ IA0KICBPQU0gcmVxdWlyZW1lbnQgaXMgdGhhdCBlYWNoIGxheWVyIG5ldHdvcms8QlI+c2hvdWxk IGJlIHNlbGYtc3VmZmljaWVudCB3cnQgDQogIE9BTSBhbmQgbm90IHJlbHkgb24gYW55IHNlcnZl ciBsYXllcjxCUj5wcmltaXRpdmVzIGJlaW5nIHBhc3NlZCANCiAgdXB3YXJkcy48QlI+PEJSPk1v cmVvdmVyLCBpdCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0IChpKSB0aGUgZGVmZWN0cyB0aGF0 IA0KICBjYW4gb2NjdXIgaW48QlI+ZWFjaCBvZiB0aGUgMyBuZXR3b3JrIG1vZGVzIGFyZSBub3Qg dGhlIHNhbWUgYW5kIChpaSkgdGhlaXIgDQogIE9BTTxCUj5yZXF1aXJlbWVudHMgYXJlIG5vdCBp ZGVudGljYWxseSB0aGUgc2FtZS4gU28gdGhlIE9BTSB0aGF0IGFwcGxpZXMgDQogIHRvPEJSPnRo ZSBjbC1wcyBtb2RlIChlZyBJUCkgaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBPQU0gdGhhdCBhcHBs aWVzIHRvIA0KICB0aGU8QlI+Y28tcHMgbW9kZSAoZWcgTVBMUy1UUCkgYW5kIG5laXRoZXIgb2Yg dGhlc2UgaXMgaWRlbnRpY2FsbHkgdGhlIHNhbWUgDQogIGFzPEJSPnRoZSBPQU0gdGhhdCBhcHBs aWVzIHRvIHRoZSBjby1jcyBtb2RlIChlZyBTREgpLjxCUj48QlI+Tm90ZSAtIFRoZSBvbmx5IA0K ICBwb2ludCBiZWluZyBjb25zaWRlcmVkIGhlcmUgaXMgdGhlIHJlYWwgY2xpZW50IGFuZDxCUj5z ZXJ2ZXIgdHJhZmZpYyANCiAgcmVsYXRpb25zaGlwLiAmbmJzcDtUaGUgY3JlYXRpb24gb2YgYSBo aWVyYXJjaHkgb2YgVENNPEJSPnN1YmxheWVycyBpcyBhIA0KICBzZXBhcmF0ZSB0b3BpYy4gJm5i c3A7RnVydGhlciwgaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhIHNpbXBsZTxCUj50ZWNobmljYWwg DQogIGFuYWx5c2lzIHRoYXQgYW55IG5vbiB0b3Atb2Ytc3RhY2sgbmV0d29yayBoYXMgbm8gbmVl ZCBmb3I8QlI+RS1OTkkgDQogIHBlZXItcGFydGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJl bnQgb3BlcmF0aW5nIHBhcnRpZXMuICZuYnNwO1NvPEJSPnRoaXMgDQogIGlzIGFsc28gYSBzZXBh cmF0ZSBpc3N1ZS4gJm5ic3A7SG93ZXZlciwgSSBwcm9wb3NlIHRoYXQgdGhpcyBsYXR0ZXI8QlI+ cG9pbnQgDQogIGJlIGNhcHR1cmVkIGluIHRoZSBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdCBk dWUgdG8gaXRzPEJSPnN0YW5kLWFsb25lIGFuZCANCiAgZ2VuZXJpYyBpbXBvcnRhbmNlLCBpZSB0 aGlzIGFwcGxpZXMgdG8gbW9yZSB0aGFuIGp1c3QgRFA8QlI+T0FNLiAmbmJzcDtCZW4gY2FuIA0K ICB5b3UgcGxlYXNlIGNvbnNpZGVyIHRoaXMgcG9pbnQgYXMvd2hlbiB0aGUgTVBMUy1UUDxCUj5y ZXF1aXJlbWVudHMgZHJhZnQgaXMgDQogIHVwZGF0ZWQuPEJSPjxCUj5yZWdhcmRzLCBOZWlsPEJS PjxCUj4mZ3Q7IENoZWVycywgDQogIEh1dWIuPEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPEJSPm1wbHMtdHAgbWFpbGluZyANCiAgbGlzdDxCUj5tcGxz LXRwQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cDxCUj48L1RUPjwvRk9OVD48QlI+PEJSPjxQUkU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L1BS RT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C9C895.6A2C361C-- From Italo.Busi@alcatel-lucent.it Wed Apr 29 00:03:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619E53A6918; Wed, 29 Apr 2009 00:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-2.894, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNMtkk-ozm+l; Wed, 29 Apr 2009 00:02:55 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 1B0B23A6859; Wed, 29 Apr 2009 00:02:54 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3T73msV015123; Wed, 29 Apr 2009 09:04:13 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 09:04:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C898.ACD07EEA" Date: Wed, 29 Apr 2009 09:03:59 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB40220F0E6@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?W21wbHMtdHBdILTwuLQ6IFJlOiAgQUlTL0ZESSAod2FzIEFzc29jaQ==?= =?gb2312?B?YXRlZCBiaWRpcmVjdGlvbmFsCXRyYW5zcG9ydHBhdGhyZXF1aXJlbWVudHMp?= thread-index: AcnIa145h7tB+cs1QC2RDMIRUZMv5QALUqpg References: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> From: "BUSI ITALO" To: , X-OriginalArrivalTime: 29 Apr 2009 07:04:02.0222 (UTC) FILETIME=[AD24BCE0:01C9C898] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls-tp] =?gb2312?b?tPC4tDogUmU6ICBBSVMvRkRJICh3YXMgQXNzb2NpYXRl?= =?gb2312?b?ZCBiaWRpcmVjdGlvbmFsCXRyYW5zcG9ydHBhdGhyZXF1aXJlbWVu?= =?gb2312?b?dHMp?= X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:03:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C898.ACD07EEA Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I agree =20 Italo ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of su.hui@zte.com.cn Sent: Wednesday, April 29, 2009 3:37 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org; BUSI ITALO; mpls-tp-bounces@ietf.org Subject: [mpls-tp] =B4=F0=B8=B4: Re: AIS/FDI (was Associated = bidirectional transportpathrequirements) =09 =09 Hi Neil,=20 =09 I think client/server relationship is fixed in co-cs/co-ps. once a = connection is established, the client/server relationship will not = change until the connection is teardown. server can get the = server/client relationship information when connection is = established/teardown, there is no need of more configuration.=20 =09 Regards,=20 Suhui=20 =09 =09 =09 =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2009-04-28 16:07=20 =CA=D5=BC=FE=C8=CB , , = , =20 =B3=AD=CB=CD mpls-tp@ietf.org=20 =D6=F7=CC=E2 Re: [mpls-tp] AIS/FDI (was Associated bidirectional = transportpathrequirements) =09 Nurit, =09 I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response = to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as = the client) then there is no fixed client/server relationship. =09 Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is = not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? =09 So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' = here...in fact if this is in the OAM requirements then it is technically wrong = and should be removed IMO. =09 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN - IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transportpathrequirements) >=20 > If we agree that the requirement is included, so why do we=20 > keep with the > endless discussions on this requirement? >=20 > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > hhelvoort@chello.nl; Adrian > Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional = transport > pathrequirements) >=20 > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > > Nurit (NSN - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > transport pathrequirements) > >=20 > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be=20 > generated by > > client layers as a result of a failure condition in the=20 > > server layer may > > be suppressed. > > Every thing else is a solution, etc.=20 > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase).=20 > > This requirement is included in the OAM requirement draft.=20 > > Best regards, > > NUrit > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional transport > > path requirements) > >=20 > > Hi Adrian, > >=20 > > You wrote: > >=20 > > > Isn't the solution here the same as the one I proposed for "TCM"? > >=20 > > Indeed, and that we do not have to around in circles about TCM. > >=20 > > How about: > > the requirement is that a server layer shall inform its clients > > that it has detected a service interuption, this to ensure that > > the clients can inhibit (unnecessary) alarms. > >=20 > > Cheers, Huub. > >=20 > > --=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/ > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9C898.ACD07EEA Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable I agree Italo From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 su.hui@zte.com.cn Sent: Wednesday, April 29, 2009 3:37=20 AM To: neil.2.harrison@bt.com Cc: = mpls-tp@ietf.org; BUSI=20 ITALO; mpls-tp-bounces@ietf.org Subject: [mpls-tp] = =B4=F0=B8=B4: Re: AIS/FDI=20 (was Associated bidirectional = transportpathrequirements) Hi Neil, = I think client/server=20 relationship is fixed in = co-cs/co-ps.=20 once a connection is established, the client/server relationship will = not=20 change until the connection is teardown. server can get the = server/client=20 relationship information when connection is established/teardown, = there is no=20 need of more configuration. Regards, Suhui=20 <neil.2.harrison@bt.com> =B7=A2=BC=FE=C8=CB: = mpls-tp-bounces@ietf.org=20 2009-04-28 16:07 =CA=D5=BC=FE=C8=CB <nurit.sprecher@nsn.com>,=20 <Italo.Busi@alcatel-lucent.it>, = <hhelvoort@chello.nl>,=20 <adrian@olddog.co.uk>=20 =B3=AD=CB=CD mpls-tp@ietf.org = =D6=F7=CC=E2 Re: [mpls-tp] AIS/FDI = (was=20 Associated bidirectional =20 = transportpathrequirements) = Nurit, I believe the reason we need this = discussion is that=20 there is an unstated assumption here that the client/server = relationship is=20 fixed. However, if the client can dynamically change its routing in = response to link failures in its topology (because some server = layer=20 network has failed....which may or may not belong to the same = operating=20 party as the client) then there is no fixed client/server=20 relationship. Refer to my post earlier today and consider what = this=20 means in the case of a cl-ps IP client layer network or a some = SVC-based=20 co-ps/co-cs mode client layer network. The key point here is = the=20 *routing process* in the client is independent of the server layer=20 network....so there is not a fixed client/server relationship.=20 Further, there is also no requirement for the server to keep = track of=20 where its client traffic routings are at any epoch.....indeed why = should it=20 in the general case where these are independent layer = networks? So=20 the only OAM requirement that is critical is that the OAM of = the client and=20 server layer networks are independent. It is thus = not sensible to=20 make client layer alarm supression a 'requirement' here...in fact = if this=20 is in the OAM requirements then it is technically wrong and should = be=20 removed IMO. regards, Neil > -----Original = Message----- >=20 From: mpls-tp-bounces@ietf.org > = [mailto:mpls-tp-bounces@ietf.org] On=20 Behalf Of Sprecher, > Nurit (NSN - IL/Hod HaSharon) > = Sent: 28=20 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; = Adrian=20 Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] = AIS/FDI=20 (was Associated bidirectional > = transportpathrequirements) >=20 > If we agree that the requirement is included, so why do we = >=20 keep with the > endless discussions on this requirement? > = > -----Original Message----- > From: ext BUSI ITALO=20 [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April = 28, 2009=20 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); > = hhelvoort@chello.nl; Adrian > Farrel > Cc:=20 mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was = Associated=20 bidirectional transport > pathrequirements) > > I = think=20 that the requirements are defined in section 2.2.8 of >=20 draft-ietf-mpls-tp-oam-requirements-01 > > Italo > = >=20 > -----Original Message----- > > From: = mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, = > > Nurit (NSN - IL/Hod HaSharon) > > Sent: = Tuesday, April=20 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian = Farrel >=20 > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI = (was=20 Associated bidirectional > > transport = pathrequirements) >=20 > > > Huub, > > I think that the requirement is = to=20 provide a mechanism to suppress > > alarms in the networks, = to ensure=20 that alarms that may be > generated by > > client = layers as a=20 result of a failure condition in the > > server layer = may >=20 > be suppressed. > > Every thing else is a solution, etc. = >=20 > I propose to phrase the requirement appropriately and conclude=20 the > > discussion on this in the context of the requirements = (until=20 we are > > getting to the solution phase). > > This = requirement is included in the OAM requirement draft. > > = Best=20 regards, > > NUrit > > > > > >=20 -----Original Message----- > > From: mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub = van=20 Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > = > To:=20 Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: = Re:=20 [mpls-tp] AIS/FDI (was Associated > bidirectional = transport >=20 > path requirements) > > > > Hi Adrian, > = >=20 > > You wrote: > > > > > Isn't the = solution=20 here the same as the one I proposed for "TCM"? > > > = >=20 Indeed, and that we do not have to around in circles about = TCM. > >=20 > > How about: > > the requirement is that a server = layer=20 shall inform its clients > > that it has detected a service=20 interuption, this to ensure that > > the clients can inhibit=20 (unnecessary) alarms. > > > > Cheers, Huub. > = >=20 > > -- > >=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 =20 http://www.van-helvoort.eu/ > >=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 Always remember that you are unique...just like everyone = else... > >=20 _______________________________________________ > > mpls-tp = mailing=20 list > > mpls-tp@ietf.org > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 _______________________________________________ > > mpls-tp = mailing=20 list > > mpls-tp@ietf.org > >=20 https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 _______________________________________________ > mpls-tp = mailing=20 list > mpls-tp@ietf.org >=20 https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing = = list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp= --------------------------------------------= ------------ ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9C898.ACD07EEA-- From maarten.vissers@huawei.com Wed Apr 29 00:17:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E166028B56A for ; Wed, 29 Apr 2009 00:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD7scFLGW3hS for ; Wed, 29 Apr 2009 00:17:26 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CC45E3A683E for ; Wed, 29 Apr 2009 00:17:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU00G1DPN19W@szxga04-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 15:18:37 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU00KM1PN0SC@szxga04-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 15:18:36 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIU00EC1PMQZ5@szxml01-in.huawei.com>; Wed, 29 Apr 2009 15:18:36 +0800 (CST) Date: Wed, 29 Apr 2009 09:18:24 +0200 From: Maarten Vissers In-reply-to: To: andy.bd.reid@bt.com, IBryskin@advaoptical.com Message-id: <008601c9c89a$b53aacd0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AATTltg Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:17:29 -0000 Andy, You speak about "local" and "remote" alarms. I had to read the rest of the sentence three times before I understood that you meant "primary" and "secondary/consequential" alarms. A primary alarm is an alarm that reports a fault cause that needs fixing, whereas a secondary/consequential alarm is a report from a client that it's connection is interrupted due to a server fault. Do I understand your use of "local" and "remote" correct? I agree with you that the main task of fault management is to know if there is a fault that they can repair, what the fault is, where the location of this fault is and then who to send to repair the fault. I agree with you that service management needs to know about the status of the service when the customer calls. I do not agree with you that in general "these guys wants to know that the service is 'down' **before** the customer is on the phone!". I have very explicit information of a few operators that a large number of service contracts will not be as you describe. Values given to me are 90% of service contracts (representing 70% of service connections) are without pro-active monitoring. In those contracts the repair time starts after the report of the customer and verification by the operator. What is important in those cases is that the service manager can simply retrieve status information when the customer is on the phone. The other 10% of service contracts (representing 30% of service connections) are with pro-active monitoring. In those contracts the repair time starts after the defect is detected. I assume that "these guys wants to know that the service is 'down' **before** the customer is on the phone!" is applicable for a subset of those service connections. For the other subset I have understood that it is sufficient when the status/performance information of the service connection can be retrieved instantaneously when the customer is on the phone. Is this also the case in BT? Besides the service connections, we have tunnel/path connections, section connections and physical media connections. Those connections have no direct "service" associated with it; i.e. those connections are part of the network's infrastructure. There is as such no "service manager" interested in the status of those infrastructure connections. The only people interested in alarms from those infrastructure connections are the fault management people. Do I understand this correct? > The service maintenance guys *have* got an alarm - the customer has not > got their service! They also notice that it is not fixing itself. So > they investigate, ie start localising. I do not understand why a service maintenance guy will have to do the fault localization... I have always been told that fault management is responsible for locating a fault. If the fault is an open matrix connection (which either interrupts a tunnel/path connection or a service/channel connection), then the fault management people responsible for the layer network will be triggered by the loss of CC alarm and start the localization procedure. When a network deploys AIS, it is possible to trigger this open matrix fault localization procedure without any complex network correlation procedure. Seems to be advantages... Regards, Maarten -----Original Message----- From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] Sent: woensdag 29 april 2009 0:26 To: maarten.vissers@huawei.com; IBryskin@advaoptical.com Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Maarten, Igor, Before dealing with the specific scenarios, let me go through again what I said in an earlier posting about the way alarm 'suppression' actually works. There are two sides to maintenance - the faulty kit guys who fix faulty cards, mend cable breaks, etc, etc, and end service guys who deal with customer service. 'Suppressed' alarms are only suppressed to the faulty kit guys who fix cards, etc. The distinction between 'local' and 'remote' alarms is very important to ensure that these faulty kit guys are directed to the place where the actual fault lies and not to places affected by, but remote from the actual fault. However, these 'suppressed' alarms are still forwarded to the service maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they want to know whether the end service is 'up' or 'down' irrespective of the cause and irrespective of the presence of AIS. AIS most emphatically does not suppress this alarm! These guys wants to know that the service is 'down' before the customer is on the phone! So to go to Maarten's first example, the faulty kit guys are not getting any alarms telling them to fix broken kit - which is correct. The service maintenance guys *have* got an alarm - the customer has not got their service! They also notice that it is not fixing itself. So they investigate, ie start localising. In practice, the first thing they will do (and most management systems will do it automatically by some form of correlation engine) is check for any corresponding faulty kit alarms. In this case, they will find no faulty kit alarms and suspect a misconfiguration, localise it, and fix it. To go to Maarten's second example, the faulty kit guys are getting an alarm telling them to fix the link between A and B. The service maintenance guys have also got an alarm - again the customer has not got their service. They also notice that it is not fixing itself. So they investigate, ie start localising. Again, the first thing they will do (and most management systems will do it automatically by some form of correlation engine) is check for any corresponding faulty kit alarms. In this case, they will find the corresponding faulty kit alarm and can check of the repair plan and status should the customer call and ask. As these particular scenarios illustrate, the right alarms have been directed to the right maintenance guys. The service guys deal with the service configurations, the faulty kit guys deal with faulty kit. Occasionally, there will be faulty kit which is not reporting itself despite the best design efforts in the equipment. In this case, the service maintenance guys are likely to have a series of alarms which can be correlated to help localise the fault and the diagnosed fault can then be passed to the faulty kit guys for fixing. Another important point. There is little room here for *false* information coming to either set of maintenance guys. When trying to localise a fault, no additional information is better than wrong additional information. That is my concern with the trying to inject packet based AIS. There is significant room for creating false information. As I've already indicted there is AIS specific configuration to do which will be prone to misconfiguration. We should then note that the thing that the AIS is supposed to be identifying is the present of misconfiguration - but achieving this requires configuration. So why should one configuration be more reliable than the other? But there are other scenarios. For example, consider port mapping (or in ITU-T speak, a degenerate subnetwork) where we terminate the section layer on one interface and blindly ship all the packets out on an other interface in a new section. If we assume AIS is being used, a fault in the incoming section should result in the injection of AIS. But how does it know what label values to use? Or does it not inject AIS? In which case we have the poor service maintenance guys actively looking for a configuration error which does not exist. A similar scenario would exist if we choose to use a sort of ADM where the forwarding table was made up of exception (add/drop) label values and a default outgoing port. Again, the same dilemma exists. Andy Andy Reid Chief Network Services Strategist BT Innovate Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 28 April 2009 20:25 > To: 'Igor Bryskin' > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Igor, > > > b) Is it beneficial if a server trail notifies its clients about > a detected problem to suppress the OAM traffic > > The suppression we have been talking about is alarm suppression, not > OAM traffic suppression. > > Loss of CC is intended to detect an open connection fault in a matrix. > E.g. assume a connection that starts in node A, passes through nodes B > and C and ends in node D. > Nodes A, B, C and D have a connection function in which a matrix > connection is to be set up to support this connection from A to D. > > What is now possible is that the matrix connection in node B is > unintentionally removed (i.e. a continuity fault). > Node D will now detect a loss of CC. Node D does not detect any other > faults. > Node C will not detect any fault. > Node B will not detect any fault. > Node A will not detect any fault if the matrix connection in B is > removed in one direction only. > > In order to detect this open matrix connection fault it is required to > report the loss of CC to the management system and to start a fault > localization procedure to locate the faulty matrix (i.e. in node B). > If such reporting is not done, then there is a hidden fault, which > keeps the connection interrupted much longer; i.e. until one or more > customers start to complain that their connections are lost. > Then you hae to find in a big network without any fault report which > node has the fault. > > What happens now if the fault is not an open matrix connection but a > server layer fault (e.g. a link fault between nodes A and B). > Node D will now detect a loss of CC. Node D does not detect any other > faults. > Node C will not detect any fault. > Node B will detect a loss of signal fault. > Node A will not detect any fault if the link from A to B is broken in > one direction only. > > If loss of CC is unconditionally reported, then node D will report > loss of CC. Node B will report loss of signal. > - If node B and node D are managed by the same management system it is > possible to perform a fault correlation in this management system to > filter out the loss of CC from node D. > What is necessary is to know that connection A-D is supported by the > link A to B. In larger multi-layer networks such correlations become > complex. If such correlations are not performed, then the loss of CC > will trigger a fault localisation action, which of course will not > find a matrix fault (i.e. waste of time). > - If node B is managed by another management system then node D, there > is no correlation possible. Node D's management system will see only > the loss of CC and will start fault localization, and will not find > any fault in its part of the network. > > Use of AIS will help in distinguishing between connection interruption > due to an open matrix connection fault and due to server fault. AIS > provides the necessary filter for loss of CC. > > What happens for the case a port detects a signal fail condition is > the following; assume a 10G port that detects a signal fail condition. > This implies that all traffic is lost. > Assume that there are 1000 client connections active (e.g. > with an average bandwidth of 5 Mbit/s). When AIS is to be generated > for those 1000 client conenctions the port has to generate 1000 AIS > frames/packets per second. Each AIS frame/packet is 64 bytes/512 bits. > Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005 > Gbit/s) of traffic in a further empty 10G port. This isn't any real > complexity. > > --------- > > The alternative is to declare that open matrix connections are never a > fault condition (i.e. are always intentional and thus known by network > management). Under such starting point it is not necessary to detect > an open matrix connection as a fault condition. Now it is not longer > necessary to distinguish between connection interruption due to open > matrix and server layer fault as the first condition isn't a fault > anylonger. Under this condition it is not useful that a server trail > informs its clients about a detected server trail problem that > interrupts the client connections. > > If we go for this latter approach and if in future an open matrix > connection would be a fault condition, then this is a hidden fault and > you need a lot more work to locate the fault (there are no alarms that > help you). > > Regards, > Maarten > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: dinsdag 28 april 2009 18:20 > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Shahram, > > I was addressing Neil's comments about the dynamic re-routing, which > is different from protection switchover onto pre-provisioned > protection connection. True, in the latter case the server layer > wouldn't notice that and will keep notifying the client that the trail > is broken. But this does not change anything. The big 2 questions in > my mind are: > > a) Is the OAM of a given layer is (i) self-sufficient and > (ii) scalable enough, so that operator can rely on it completely and > independently from what is happening in the lower layers? > > b) Is it beneficial if a server trail notifies its clients about a > detected problem to suppress the OAM traffic and possibly unnecessary > switchovers until the server trail corrects itself? > > Cheers, > Igor > > > > -----Original Message----- > From: Shahram Davari [mailto:davarish@yahoo.com] > Sent: Tuesday, April 28, 2009 11:57 AM > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Igor, > > Your assumption is that there is a control plane that sets up the > binding between client and server layer and that such binding will be > removed via the control plane when a reroute happens. I think this > assumption is not always true. For example in a linear 1:1 or 1+1 > protection, there is no signalling to withdraw the binding at > intermediate nodes. In > 1:1 there is APS, but that is end-to-end and is sent on the backup > path not working path. > > -Shahram > > > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: April-28-09 11:27 AM > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Shahram, > > Let's assume that connection A-B-C-D-E is dynamically provisioned by a > control plane. As part of such provisioning a binding is created > between this connection and network C at the two adaptation points on > either side of the link provided by network C. When the connection is > torn down, this binding is removed as a part of the cleanup process. > The re-routing of the connection onto A-F-G-E is indistinguishable > from the connection tear down as far as link C is concerned. > > Igor > > -----Original Message----- > From: Shahram Davari [mailto:davarish@yahoo.com] > Sent: Tuesday, April 28, 2009 11:15 AM > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Hi Igor, > > How does the server know the client is rerouted? Assume the following > networks: A-B-C-D-E (working) and A-F-G-E (protection). > Assume each has its own server layer such as MPLS, MPLS-TP, ATM, > SONET, etc. Assume that network C uses MPLS-TP as server layer. > Network C will never know there was a protection switching done for > the client layer. > > -Shahram > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin > Sent: April-28-09 11:05 AM > To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Neil. > > I actually agree with Maarten on this. I don't quite understand why do > you keep talking about fixed client-server relationship. It is fixed > as long as the client layer connection configured this way (statically > or dynamically). > As soon as the connection is re-routed, this relationship is broken > (because this is a part of the re-routing process) and hence the > server trail termination points will know that the server trail now > serves one connection less, whereas some other server trail(s) will > learn that they serve from now on one connection more. These new > client-server relationships are fixed until the next re-routing. > > Cheers, > Igor > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: Tuesday, April 28, 2009 8:48 AM > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Neil, > > > However, if the client can dynamically change its routing > in response > > to link failures in its topology (because some server layer network > > has failed....which may or may not belong to the same > operating party > > as the > > client) then there is no fixed client/server relationship. > > I believe there is a fixed client/server relationship also in this > case in the network. This relationship is broken when the connection > is rerouted. > Such reroute will remove the CP/FP and as such will stop the AIS > generation. > > There is no difference with what we do today in SDH and OTN. > A client/server relationship is fixed until the point in time that the > connection is either teardown or rerouted. When either of the two > cases occur, the AIS generation is stopped. > Until such action is performed, AIS is generated during signal fail > condition period and inserted into the connection. > > In MPLS-TP we have the requirement that MPLS-TP must be able to > operate without control plane. This implies that it will operate > without restoration, and that there will not be frequent rerouteing > ongoing. Result is that client/server relationships will last until > the connection is teardown. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com > Sent: dinsdag 28 april 2009 10:07 > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; > hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > Nurit, > > I believe the reason we need this discussion is that there is an > unstated assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network > has failed....which may or may not belong to the same operating party > as the > client) then there is no fixed client/server relationship. > > Refer to my post earlier today and consider what this means in the > case of a cl-ps IP client layer network or a some SVC-based > co-ps/co-cs mode client layer network. The key point here is the > *routing process* in the client is independent of the server layer > network....so there is not a fixed client/server relationship. > Further, there is also no requirement for the server to keep track of > where its client traffic routings are at any epoch.....indeed why > should it in the general case where these are independent layer > networks? > > So the only OAM requirement that is critical is that the OAM of the > client and server layer networks are independent. It is thus not > sensible to make client layer alarm supression a 'requirement' > here...in fact if this is in the OAM requirements then it is > technically wrong and should be removed IMO. > > regards, Neil > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > Nurit (NSN - > > IL/Hod HaSharon) > > Sent: 28 April 2009 08:46 > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > > > > If we agree that the requirement is included, so why do we > keep with > > the endless discussions on this requirement? > > > > -----Original Message----- > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > Sent: Tuesday, April 28, 2009 10:44 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > > Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > pathrequirements) > > > > I think that the requirements are defined in section 2.2.8 of > > draft-ietf-mpls-tp-oam-requirements-01 > > > > Italo > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > Nurit (NSN > > > - IL/Hod HaSharon) > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > To: hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > > transport pathrequirements) > > > > > > Huub, > > > I think that the requirement is to provide a mechanism to > suppress > > > alarms in the networks, to ensure that alarms that may be > > generated by > > > client layers as a result of a failure condition in the > server layer > > > may be suppressed. > > > Every thing else is a solution, etc. > > > I propose to phrase the requirement appropriately and > conclude the > > > discussion on this in the context of the requirements > (until we are > > > getting to the solution phase). > > > This requirement is included in the OAM requirement draft. > > > Best regards, > > > NUrit > > > > > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On > > > Behalf Of ext Huub van Helvoort > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > To: Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > path requirements) > > > > > > Hi Adrian, > > > > > > You wrote: > > > > > > > Isn't the solution here the same as the one I proposed > for "TCM"? > > > > > > Indeed, and that we do not have to around in circles about TCM. > > > > > > How about: > > > the requirement is that a server layer shall inform its > clients that > > > it has detected a service interuption, this to ensure that the > > > clients can inhibit (unnecessary) alarms. > > > > > > Cheers, Huub. > > > > > > -- > > > ================================================================ > > > http://www.van-helvoort.eu/ > > > ================================================================ > > > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From maarten.vissers@huawei.com Wed Apr 29 00:22:00 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774CC28B56A for ; Wed, 29 Apr 2009 00:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.567 X-Spam-Level: ** X-Spam-Status: No, score=2.567 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7DmQogqkwJ2 for ; Wed, 29 Apr 2009 00:21:57 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A6E513A6963 for ; Wed, 29 Apr 2009 00:21:56 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU00JTQPUIPZ@szxga02-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 15:23:07 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU00A1WPUISJ@szxga02-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 15:23:06 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIU000TEPTWV9@szxml02-in.huawei.com>; Wed, 29 Apr 2009 15:23:06 +0800 (CST) Date: Wed, 29 Apr 2009 09:22:47 +0200 From: Maarten Vissers In-reply-to: To: "'BRUNGARD, DEBORAH A, ATTLABS'" Message-id: <008701c9c89b$4ef8bce0$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_EhpnlXZpIzrKEbzANpO2NQ)" Thread-index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJAABtoogAAkDyVA Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:22:00 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EhpnlXZpIzrKEbzANpO2NQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Deborah, =20 Thank you for confirming that we can speak about ENNI for non-IP layer interconnects. As you indicate, an ENNI also exists when we interconnect = two SDH admin domains via an STM-N. =20 Do you also agree that we can speak about an ENNI when we interconnect a Metro/Carrier Ethernet Network admin domain A with a Metro/Carrier = Etherent Network admin domain B via an 802.3 interface over which the EVC layer = is transported? =20 Regards, Maarten _____ =20 From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: dinsdag 28 april 2009 17:52 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Exactly =A8C G707 defined the ENNI for SDH and G703/G704 for PDH. The = PHY and framing is defined (per layer). This definition is very different from = your earlier email. It does not require supporting PDH<->SDH interworking, or = PDH OAM in SDH, or OAM interworking between a client/server as one of your earlier emails required: =20 >For this case it is necessary to develop ETH<>PW(client) layer=20 > network > interworking specifications. To limit the complexity of such layer=20 > network interworking, it is beneficial to select the MPLS-TP PW OAM = > to > use the Y.7131 OAM PDUs as proposed in draft-bhh-mpls-tp-oam-y1731. = > I.e. > both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs =20 The interconnection of equipment (at one layer) should not put any restrictions on other layers. =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: Tuesday, April 28, 2009 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) =20 Deborah, =20 > And the UNI/ENNI being discussed there is not comparable to your definition. =20 I be more then happy if you give me alternative terms to UNI and ENNI. =20 Just use the example of a customer requesting a 2 Mbit/s service from = the SDH network, of which the first customer location is located behind the network of operator A and the second endpoint is located behind the = network of operator B. Operator A and B interconnect via a STM-1 interface with = each other. The customer connects via a 2 Mbit/s G.703 interface with the networks of operator A and B. =20 What term should I use for the interconnect of the customer to the = networks of operator A and B? I.e. if it is not possible to call this the "UNI", what should it be = called then? =20 What term should I use for the interconnect of the networks of operator = A and B? I.e. if it is not possible to call this the "ENNI", what should it be = called then? =20 Thanks for your help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: "An interface that is used = for the interconnection of customer equipment with a network element of the transport network." =20 _____ =20 From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: maandag 27 april 2009 23:00 To: Greg Mirsky; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Maarten, =20 I think you have oversimplified the discussion in MEF and in so doing = have inaccurately summarized. As Greg says, MEF is oriented towards services (SLA/SLS) and they also recognize that some operators only need simple troubleshooting tools. Considering the on-going discussion in MEF, for = the service operators group, it is questionable if Y1731 should be used by MPLS-TP as a baseline as it is considered inadequate. And I don=A1=AFt = see AT&T=A1=AFs requirements as any different from BT. I think we should = follow Adrian=A1=AFs and Ben=A1=AFs proposal to define the actual requirements = for MPLS-TP before replicating other technologies=A1=AF solutions. =20 And the UNI/ENNI being discussed there is not comparable to your = definition. =20 Deborah =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) =20 Dear Maarten, you definitely know but I'd note that MEF formulates requirements for Carrier Ethernet as a service, i.e. client layer of a transport network, = not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically.=20 Regards, Greg Mirsky 2009/4/27 Maarten Vissers Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don't > use the others). Your company for some years has been asking for less, > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from = those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market > segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must >> not blindly recreate SDH/SONET. If we do so without consideration to >> how operators' needs and requirements may have evolved (and continue >> to evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents of >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =20 --Boundary_(ID_EhpnlXZpIzrKEbzANpO2NQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Deborah, Thank you for confirming that we can speak = about ENNI for=20 non-IP layer interconnects. As you indicate, an ENNI also exists when we = interconnect two SDH admin domains via an STM-N. Do you also agree that we can speak about an = ENNI when we=20 interconnect a Metro/Carrier Ethernet Network admin domain A with a=20 Metro/Carrier Etherent Network admin domain B via an 802.3 interface = over which=20 the EVC layer is transported? Regards, Maarten From: BRUNGARD, DEBORAH A, ATTLABS=20 [mailto:dbrungard@att.com] Sent: dinsdag 28 april 2009=20 17:52 To: Maarten Vissers Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Exactly=20 =A8C G707 defined the ENNI for SDH and G703/G704 for PDH. The PHY and = framing is=20 defined (per layer). This definition is very different from your earlier = email.=20 It does not require supporting PDH<->SDH interworking, or PDH OAM = in SDH,=20 or OAM interworking between a client/server as one of your earlier = emails=20 required: >For this case it is necessary to develop=20 ETH<>PW(client) layer > network >    interworking = specifications. To=20 limit the complexity of such layer >    network interworking, it = is=20 beneficial to select the MPLS-TP PW OAM > to >    use the Y.7131 OAM PDUs = as proposed=20 in draft-bhh-mpls-tp-oam-y1731. > I.e. >    both Ethernet and MPLS-TP = will then=20 use e.g. CCM OAM PDUs The=20 interconnection of equipment (at one layer) should not put any = restrictions on=20 other layers. From: Maarten = Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: Tuesday, April 28, = 2009=20 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Deborah, >=20 And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. I be=20 more then happy if you give me alternative terms to UNI and=20 ENNI. Just=20 use the example of a customer requesting a 2 Mbit/s service from the SDH = network, of which the first customer location is located behind the = network of=20 operator A and the second endpoint is located behind the network of = operator B.=20 Operator A and B interconnect via a STM-1 interface with each other. The = customer connects via a 2 Mbit/s G.703 interface with the networks of = operator A=20 and B. What=20 term should I use for the interconnect of the customer to the networks = of=20 operator A and B? I.e.=20 if it is not possible to call this the "UNI", what should it be called=20 then? What=20 term should I use for the interconnect of the networks of operator A and = B? I.e.=20 if it is not possible to call this the "ENNI", what should it be called=20 then? Thanks=20 for your help. Regards, Maarten PS.=20 Note that G.8012 defines UNI as follows: "An=20 interface that is used for the interconnection of customer equipment = with a=20 network element of the transport network." From: BRUNGARD, = DEBORAH=20 A, ATTLABS [mailto:dbrungard@att.com] Sent: maandag 27 april = 2009=20 23:00 To: Greg Mirsky; Maarten Vissers Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Maarten, I=20 think you have oversimplified the discussion in MEF and in so doing have = inaccurately summarized. As Greg says, MEF is oriented towards services=20 (SLA/SLS) and they also recognize that some operators only need simple=20 troubleshooting tools. Considering the on-going discussion in MEF, for = the=20 service operators group, it is questionable if Y1731 should be used by = MPLS-TP=20 as a baseline as it is considered inadequate. And I don=A1=AFt see = AT&T=A1=AFs=20 requirements as any different from BT. I think we should follow = Adrian=A1=AFs and=20 Ben=A1=AFs proposal to define the actual requirements for MPLS-TP before = replicating=20 other technologies=A1=AF solutions. And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. Deborah From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of=20 Greg Mirsky Sent: Monday, April 27, 2009 2:47 = PM To:=20 Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 We appear to be going around in circles (Re:Associated bidirectional = transport=20 path requirements) Dear Maarten, you = definitely=20 know but I'd note that MEF formulates requirements for Carrier Ethernet = as a=20 service, i.e. client layer of a transport network, not requirements for = the=20 transport network as server layer. Thus requirements expressed by SPs at = MEF are=20 not applicable or transitive, in my view, to MPLS-TP, at least not=20 automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Tom, This AIS discussion has been held in = previous=20 technologies as well, e.g. Ethernet OAM. The result was that AIS = insertion=20 is optional and that Ethernet equipment (see G.8021) can be = configured to=20 insert Ethernet AIS or to not insert Ethernet AIS. > Do you see = our (BT's)=20 requirements to be very divergent from those of other operators = participating=20 in this effort? I see the requirements for OAM that have been = expressed in=20 this mpls-tp discussion by BT representatives to be different from = the=20 requirements expressed by other operator representatives. For=20 example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives = of DT,=20 FT, KPN, KDDI and CT. I also see that the OAM requirements defined in = MEF=20 (with input from e.g. AT&T and Verizon) be different from those = expressed=20 by BT representatives. I see that MEF is requesting to support in = Y.1731=20 frame loss counting for more then one priority level; i.e. an = extension of=20 the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that = the=20 operators active in MEF (e.g. AT&T, Verizon, Sprint) have created = and are=20 creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtual UNI=20 specifications, while representatives of BT state that there can't = be "UNI"=20 or "E-NNI" interfaces associated with packet transport networks, = as those=20 networks are "not top of stack". I see that many operators = require compliance=20 with MEF specifications, including the Ethernet = UNI specification. I=20 see that e.g. KPN provides a Wholesale Broadband Access (WBA) service=20 via rooted-multipoint EVCs, which EVCs terminate outside the KPN = network=20 (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.h= tml=20 and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_= Access_Service.html );=20 i.e. a peer-interconnection case and a potential case for TCM, a = case which=20 according to BT representatives does not exist. I see that the = "message,=20 file, stream" concepts are key to BT's considerations, while I don't = see any=20 of that contributed by other operators. When I look at the telecom = network=20 stack (see attached slide), then message, file stream are important = concepts=20 at Layer 3 (NGN) where those represent the characteristics of the = main=20 services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH = CES, etc"=20 are the important services at Layer 2 (PTN). This raises the question = what=20 the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 = Tunnel/Path layer=20 technology which has to support the IP based Layer 3 Services/Channel = layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has = to=20 support the EVC based Layer 2 Services/Channel=20 layer. Regards, Maarten -----Original Message----- From: Thomas = Nadeau=20 [mailto:tnadeau@lucidvision.com] S= ent:=20 vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: = [mpls-tp] We=20 appear to be going around in circles (Re: Associated bidirectional = transport=20 path requirements) Maartin, >=20 Ben, > > Your company is one of the many operators in the = world, and=20 the number > of nodes outside your network is factors larger then = the=20 number of > nodes inside your network. My experience is that = different=20 operators > have different sets of requirements. Manufacturers = have to=20 support the > superset of those requirements. Each operator will = then=20 deploy the > subset of provided features that fits its needs (and = turn off=20 or don't > use the others). Your company for some years has been = asking=20 for less, > other operators have been asking for more. = Manufacturers thus=20 build > their products with lots of configurability to support all = variations. Do you see = our (BT's)=20 requirements to be very divergent from those of other operators = participating=20 in this effort? Unless our=20 requirements are very different, I am confident vendors will build = (or have=20 built) their devices based on our (sensible) = requirements. > It is=20 my opinion that we should not remove well established features > = like AIS,=20 TCM, frame loss counting, delay measurement, loopback, etc > = before the=20 majority of operators have agreed that such features are > not = longer=20 necessary. Again, that = is your=20 opinion, which frankly seems to diverge from what other operators = have=20 expressed. Furthermore, let me recommend that you get out of the = habit of=20 telling your customers (or potential ones), what they require after = they have=20 been plainly clear about what they want. Unless you think we don't = know what=20 we are talking about. Is this perhaps the case? --Tom >=20 Regards, > Maarten > > -----Original = Message----- >=20 From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org]=20 On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april = 2009=20 0:14 > To: mpls-tp@ietf.org >=20 Subject: [mpls-tp] We appear to be going around in circles (Re: >=20 Associated > bidirectional transport path = requirements) > >=20 Colleagues, > > The current debates appear to be going = around in=20 circles and achieving > nothing of value IMO. Two major operators = have=20 expressed their > opinions and no operator that I can see has = disagreed=20 with those > opinions. > > I apologise for being = direct (and=20 possibly rude) but I am getting > tired of being told by folks who = do not=20 represent operators what > functionality I need or should have in = my=20 networks. > > To put some context on BT's comments in these=20 threads: > I have the largest MPLS network in the UK. > I = have one=20 of the largest MPLS networks globally delivering service to > 173=20 countries with over 200 000 customer ports I have (off the top = of >=20 my > head) > at least another 10 MPLS networks in specific = countries=20 covering at > least 3 continents delivering dedicated services to=20 particular market > segments. > > I have an extremely = large=20 SDH network in the UK consisting of over 30 > 000 switches and = supporting=20 in excess of 1 million circuits. > I have an extremely large SDH = network=20 globally delivering service in > 110 countries. > > I = would=20 like to think my BT colleagues and I might know a little > = something about=20 building large scale networks and the requirements of > those = networks and=20 the needs of the customers that I deliver services > = to. > >=20 Can we please stop these circular arguments which are IMO going > = nowhere=20 and focus on the task in hand which is defining the > requirements = (and=20 later > solutions) being asked for by myself, my company and my = colleagues=20 in > other operators on this list. > > Thanks >=20 Ben > > > -- > > Ben Niven-Jenkins > = IP,=20 Data & Content Architect > Network Infrastructure = Architecture,=20 BT > > E-mail: benjamin.niven-jenkins@bt.c= om >=20 Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = Fax: +44 = (0)1332=20 578827 > > British Telecommunications plc. Registered = office: 81 Newgate=20 Street > London > EC1A 7AJ Registered = in England=20 no: 1800000 > > >=20 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> &g= t;=20 wrote: > >> ben: >> I understand your meaning, = you still=20 wish to resign and make a more >> reliable and effective, easy = to=20 operator and easy to manage packet >> transport network like = me. but=20 why not apply this SDH/SONET in the >> future maybe the = following=20 cause: >> 1 it adopted = circuit=20 switching techonogy to bring lower useful of >> the resource = than PTN=20 network; >> 2 it can't = bear all=20 kinds of traffics like PTN networks it noted >> that we can't = apply=20 SDH/SONET network in the future not because it >> have a = complex OAM=20 functions. while more people like to move the >> advantages of = the OAM = functions in=20 SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of = OAM=20 functions of SDH/SONET . we should >> use and extend the = AIS/FDI=20 functions to MPLS-TP ; >> >> best regards >>=20 liu >> >> >> >> Ben Niven-Jenkins = <benjamin.niven-jenkins@bt.c= om> >>=20 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >>=20 <liu.guoman@zte.com.cn>,=20 "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com> >> = =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> = =D6=F7=CC=E2 >> Re: [mpls-tp] Associated = bidirectional=20 transport path=20 requirements >> >> >> >> >><= BR>>> >>=20 On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> &g= t;>=20 wrote: >> >>> Deborah: >>> maybe what = you said=20 is right. but I can't completely agree your >>=20 opinions. >>> IMO. mpls-tp is regard as transport network = like=20 SDH/SONET. so it >>> should have AIS/FDI fuctions as=20 SDH/SONET. >>> >>> do you think=20 so. >> >> No we must assess the requirements for = packet=20 transport networks >> supporting the needs of operators today = and in=20 the future. We must >> not blindly recreate SDH/SONET. If we do = so=20 without consideration to >> how operators' needs and = requirements may=20 have evolved (and continue >> to evolve in future) we will have = failed=20 IMO and I would severely >> question the value of the work we = will have=20 produced. If we just >> recreate SDH/SONET then what is the = purpose of=20 the work an operator >> would be better off just deploying = existing=20 SDH/SONET equipment. >> >> >>=20 Ben >> >> >> >> >> >&g= t;=20 -------------------------------------------------------- >> ZTE = Information Security Notice: The information contained in = this >> mail=20 is solely property of the sender's organization. This mail >>=20 communication is confidential. Recipients named above are = obligated >>=20 to maintain secrecy and are not permitted to disclose the contents=20 of >> this > communication to others. >> This = email and=20 any files transmitted with it are confidential and >> intended = solely=20 for the use of the individual or entity to whom they >> are = addressed.=20 If you have received this email in error please notify >> the=20 originator of the message. Any views expressed in this = message >> are=20 those of the individual sender. >> This message has been = scanned for=20 viruses and Spam by ZTE Anti-Spam > system. > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_EhpnlXZpIzrKEbzANpO2NQ)-- From nurit.sprecher@nsn.com Wed Apr 29 00:36:54 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B583A6E67 for ; Wed, 29 Apr 2009 00:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3htn7Nyi9f9F for ; Wed, 29 Apr 2009 00:36:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 56B733A6BA9 for ; Wed, 29 Apr 2009 00:36:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3T7bq5w029998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 09:37:52 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3T7bqI9015679; Wed, 29 Apr 2009 09:37:52 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 09:37:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C89D.66F7AD26" Date: Wed, 29 Apr 2009 09:37:46 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A41D8B@DEMUEXC014.nsn-intra.net> In-Reply-To: <4A90369EC3D15C4F91C73F46BBA068E707D738CD@xmb-sjc-22d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Interworking Thread-Index: AcnIkzr/OCtaxBPMQ4GxueQyq0XAMgACdWDw References: <4A90369EC3D15C4F91C73F46BBA068E707D738CD@xmb-sjc-22d.amer.cisco.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Michael T. Wu (mtwu)" , X-OriginalArrivalTime: 29 Apr 2009 07:37:51.0986 (UTC) FILETIME=[66FA2520:01C9C89D] Subject: Re: [mpls-tp] Interworking X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:36:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C89D.66F7AD26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a draft discussing the interworking scenarios with IP/MPLS http://tools.ietf.org/id/draft-martinotti-mpls-tp-interworking-01.txt =20 =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Michael T. Wu (mtwu) Sent: Wednesday, April 29, 2009 9:25 AM To: mpls-tp@ietf.org Subject: [mpls-tp] Interworking =20 Hi, =20 Is there a draft or discussion on the interworking with existing technologies (L2 or L3) and standards (ITU/MEF)? =20 Thanks, Michael ------_=_NextPart_001_01C9C89D.66F7AD26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a draft discussing the interworking scenarios with IP/MPLS http://tools.ietf.org/id/draft-martinotti-mpls-tp-interworking-01.t= xt From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Michael T. Wu = (mtwu) Sent: Wednesday, April = 29, 2009 9:25 AM To: mpls-tp@ietf.org Subject: [mpls-tp] = Interworking Hi, Is there a draft or discussion on the interworking = with existing technologies (L2 or L3) and standards = (ITU/MEF)? Thanks, Michael ------_=_NextPart_001_01C9C89D.66F7AD26-- From diego.caviglia@ericsson.com Wed Apr 29 00:54:49 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135EB3A6C73 for ; Wed, 29 Apr 2009 00:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcVOQooWW32k for ; Wed, 29 Apr 2009 00:54:48 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8D6DE3A68C8 for ; Wed, 29 Apr 2009 00:54:47 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-85-49f80818a437 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 32.53.04357.81808F94; Wed, 29 Apr 2009 09:56:08 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 09:56:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C89F.F407C681" Date: Wed, 29 Apr 2009 09:55:07 +0200 Message-ID: In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A41D8B@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Interworking thread-index: AcnIkzr/OCtaxBPMQ4GxueQyq0XAMgACdWDwAACgC7A= References: <4A90369EC3D15C4F91C73F46BBA068E707D738CD@xmb-sjc-22d.amer.cisco.com> <077E41CFFD002C4CAB7DFA4386A53264A41D8B@DEMUEXC014.nsn-intra.net> From: "Diego Caviglia" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Michael T. Wu (mtwu)" , X-OriginalArrivalTime: 29 Apr 2009 07:56:07.0971 (UTC) FILETIME=[F43C2F30:01C9C89F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls-tp] Interworking X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:54:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C89F.F407C681 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As one of the authors I can say comments are welcome. =20 BR Diego =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: mercoled=EC 29 aprile 2009 9.38 To: ext Michael T. Wu (mtwu); mpls-tp@ietf.org Subject: Re: [mpls-tp] Interworking =20 There is a draft discussing the interworking scenarios with IP/MPLS http://tools.ietf.org/id/draft-martinotti-mpls-tp-interworking-01.txt =20 =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of ext Michael T. Wu (mtwu) Sent: Wednesday, April 29, 2009 9:25 AM To: mpls-tp@ietf.org Subject: [mpls-tp] Interworking =20 Hi, =20 Is there a draft or discussion on the interworking with existing = technologies (L2 or L3) and standards (ITU/MEF)? =20 Thanks, Michael ------_=_NextPart_001_01C9C89F.F407C681 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As one of the authors I can say = comments are welcome. BR Diego From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN = - IL/Hod HaSharon) Sent: mercoled=EC 29 = aprile 2009 9.38 To: ext Michael T. Wu = (mtwu); mpls-tp@ietf.org Subject: Re: [mpls-tp] Interworking There is a draft discussing the interworking scenarios with IP/MPLS http://tools.ietf.org/id/draft-martinotti-mpls-tp-interworking-01.t= xt From: = mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of ext Michael T. Wu (mtwu) Sent: Wednesday, April = 29, 2009 9:25 AM To: mpls-tp@ietf.org Subject: [mpls-tp] = Interworking Hi, Is there a draft or discussion on the interworking = with existing technologies (L2 or L3) and standards = (ITU/MEF)? Thanks, Michael ------_=_NextPart_001_01C9C89F.F407C681-- From nurit.sprecher@nsn.com Wed Apr 29 00:57:18 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C613A683E for ; Wed, 29 Apr 2009 00:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=1.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnHyPNuxQ4Tq for ; Wed, 29 Apr 2009 00:57:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 0B5413A6E6A for ; Wed, 29 Apr 2009 00:57:15 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3T7wYBI013904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 09:58:34 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3T7wXFY032680; Wed, 29 Apr 2009 09:58:34 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 09:58:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 09:58:27 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A41DC9@DEMUEXC014.nsn-intra.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQADJCEfA= References: <077E41CFFD002C4CAB7DFA4386A53264A415D6@DEMUEXC014.nsn-intra.net> <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 29 Apr 2009 07:58:33.0720 (UTC) FILETIME=[4B1BB780:01C9C8A0] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:57:18 -0000 Neil, Thanks for the very good explanation. It really helps me to understand better the context of the long discussion.=20 Personally I got many feedbacks from Tier-1 SPs that they would like to have the capability to suppress alarms in a packet transport environment. Their requirement was that if a server layer (e.g. MPLS-TP link) fails, there is a way to notify the client layer (e.g. LSPs) in order to be able to suppress alarms at the client layer that may result from the fault at the server layer (e.g. MPLS-TP link).=20 Isn't it a logical and reasonable requirement in a transport profile? Also I saw general requirements for inter-layer fault correlation. So can I understand from your mail that you are not happy from such a requirement as well? Best regards, Nurit =20 -----Original Message----- From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Tuesday, April 28, 2009 11:07 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN - IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transportpathrequirements) >=20 > If we agree that the requirement is included, so why do we=20 > keep with the > endless discussions on this requirement? >=20 > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > hhelvoort@chello.nl; Adrian > Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) >=20 > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > > Nurit (NSN - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > transport pathrequirements) > >=20 > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be=20 > generated by > > client layers as a result of a failure condition in the=20 > > server layer may > > be suppressed. > > Every thing else is a solution, etc.=20 > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase).=20 > > This requirement is included in the OAM requirement draft.=20 > > Best regards, > > NUrit > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional transport > > path requirements) > >=20 > > Hi Adrian, > >=20 > > You wrote: > >=20 > > > Isn't the solution here the same as the one I proposed for "TCM"? > >=20 > > Indeed, and that we do not have to around in circles about TCM. > >=20 > > How about: > > the requirement is that a server layer shall inform its clients > > that it has detected a service interuption, this to ensure that > > the clients can inhibit (unnecessary) alarms. > >=20 > > Cheers, Huub. > >=20 > > --=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/ > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From maarten.vissers@huawei.com Wed Apr 29 02:05:01 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DFB3A6D86 for ; Wed, 29 Apr 2009 02:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.568 X-Spam-Level: X-Spam-Status: No, score=0.568 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r160DG7GOn7n for ; Wed, 29 Apr 2009 02:05:00 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BB8073A6BAA for ; Wed, 29 Apr 2009 02:04:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU002IOUKSP9@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 17:05:17 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIU00DYGUKPZZ@szxga03-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 17:05:16 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIU00EN3UKBZ5@szxml01-in.huawei.com>; Wed, 29 Apr 2009 17:05:14 +0800 (CST) Date: Wed, 29 Apr 2009 11:05:02 +0200 From: Maarten Vissers In-reply-to: <4A90369EC3D15C4F91C73F46BBA068E707D738CD@xmb-sjc-22d.amer.cisco.com> To: "'Michael T. Wu (mtwu)'" , mpls-tp@ietf.org Message-id: <00b101c9c8a9$98fbb230$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_LgP8mn+zMGmucNCp9AogCQ)" Thread-index: AcnIkzr/OCtaxBPMQ4GxueQyq0XAMgAE8pQw Subject: Re: [mpls-tp] Interworking X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 09:05:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_LgP8mn+zMGmucNCp9AogCQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Michael, I have been discussing interworking with existing Ethernet technologies on this mailinglist for some time, but we have not made much progress so far. Before we can talk about such "interworking" or "interconnection" we have to agree on the layer stack of MPLS-TP based packet transport network domains. I believe that there are four alternative MPLS-TP based packet transport network layer stacks: (1) (2) (3) (4) ------------ --------------- ------------- ------- | EVC | | EVC & MS-PW | | EVC | | EVC | ------------ --------------- ------------- ------------ | LSP | | LSP | | PW | | PW | ------------ --------------- ------------- ------------ | T.Media | | Trans.Media | | LSP | | LSP | ------------ --------------- ------------- ------------ | T.Media | | T.Media | ------------- ------------ Which of these four stacks do we want to standardize for MPLS-TP based packet transport networks? For Ethernet based packet transport networks the layer stack is: (5) ------------ | EVC | ------------ | EVP | ------------ | T.Media | ------------ For PBB-TE based packet transport networks the layer stack is: (6) ------------ | EVC | ------------ | TESI | ------------ | T.Media | ------------ We will also have to talk about the layer stack of the interface connecting the two technologies. I expect that those layer stacks to interconnect with Ethernet and PBB-TE based packet transport network domains will be: (7) (8) ------------ ----------- | EVC | | EVC | ------------ ----------- | T.Media | | EVP | ------------ ----------- | T.Media | ----------- Interconnection/Interworking Ethernet and MPLS-TP packet transport network domains may then be one of the following cases (note: numbers refer to the layer stacks above): A) (1) - (7) - (5) B) (1) - (8) - (5) C) (2) - (7) - (5) D) (2) - (8) - (5) E) (3) - (7) - (5) F) (3) - (8) - (5) G) (4) - (7) - (5) H) (4) - (8) - (5) In the above cases A to H I have assumed that the two domains that interconnect/interwork have each their own equipment, and interconnection is via an 802.3 interface. In many cases both domains will be sharing an edge node and interconnection is via the switch matrix; i.e. one line port connects to the ethernet domain and the other line port connects to the MPLS-TP domain. This adds another four cases: I) (1) - (5) J) (2) - (5) K) (3) - (5) L) (4) - (5) Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Michael T. Wu (mtwu) Sent: woensdag 29 april 2009 8:25 To: mpls-tp@ietf.org Subject: [mpls-tp] Interworking Hi, Is there a draft or discussion on the interworking with existing technologies (L2 or L3) and standards (ITU/MEF)? Thanks, Michael --Boundary_(ID_LgP8mn+zMGmucNCp9AogCQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Michael, I have been discussing interworking with existing Ethernet technologies on this mailinglist for some time, but we have not made much progress so far. Before we can talk about such "interworking" or "interconnection" we have to agree on the layer stack of MPLS-TP based packet transport network domains. I believe that there are four alternative MPLS-TP based packet transport network layer stacks:     (1)               (2)                (3)             (4) ------------    ---------------     -------------    ------- |   EVC    |    | EVC & MS-PW |     |    EVC    |    | EVC | ------------    ---------------     -------------    ------------ |   LSP    |    |     LSP     |     |    PW     |    |    PW    | ------------    ---------------     -------------    ------------ | T.Media |    | Trans.Media |     |    LSP |    |   LSP    | ------------    ---------------     -------------    ------------                                     | T.Media |    | T.Media |                                     -------------    ------------ Which of these four stacks do we want to standardize for MPLS-TP based packet transport networks? For Ethernet based packet transport networks the layer stack is:     (5) ------------ |   EVC    | ------------ |   EVP    | ------------ | T.Media | ------------ For PBB-TE based packet transport networks the layer stack is:     (6) ------------ |   EVC    | ------------ |   TESI   | ------------ | T.Media | ------------ We will also have to talk about the layer stack of the interface connecting the two technologies. I expect that those layer stacks to interconnect with Ethernet and PBB-TE based packet transport network domains will be:     (7)             (8) ------------    ----------- |   EVC    |    |   EVC   | ------------    ----------- | T.Media |    |   EVP   | ------------    -----------                 | T.Media |                 ----------- Interconnection/Interworking Ethernet and MPLS-TP packet transport network domains may then be one of the following cases (note: numbers refer to the layer stacks above): A)    (1) - (7) - (5) B)    (1) - (8) - (5) C)    (2) - (7) - (5) D)    (2) - (8) - (5) E)    (3) - (7) - (5) F)    (3) - (8) - (5) G)    (4) - (7) - (5) H)    (4) - (8) - (5) In the above cases A to H I have assumed that the two domains that interconnect/interwork have each their own equipment, and interconnection is via an 802.3 interface. In many cases both domains will be sharing an edge node and interconnection is via the switch matrix; i.e. one line port connects to the ethernet domain and the other line port connects to the MPLS-TP domain. This adds another four cases: I)    (1) - (5) J)    (2) - (5) K)    (3) - (5) L)    (4) - (5) Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Michael T. Wu (mtwu) Sent: woensdag 29 april 2009 8:25 To: mpls-tp@ietf.org Subject: [mpls-tp] Interworking Hi, Is there a draft or discussion on the interworking with existing technologies (L2 or L3) and standards (ITU/MEF)? Thanks, Michael --Boundary_(ID_LgP8mn+zMGmucNCp9AogCQ)-- From neil.2.harrison@bt.com Wed Apr 29 02:30:03 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5463A70D7 for ; Wed, 29 Apr 2009 02:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-7aQRGm4pBZ for ; Wed, 29 Apr 2009 02:30:01 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 28A783A695D for ; Wed, 29 Apr 2009 02:30:00 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 10:31:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 10:31:17 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E22A5@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A41DC9@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQADJCEfAAA11LAA== From: To: X-OriginalArrivalTime: 29 Apr 2009 09:31:20.0921 (UTC) FILETIME=[416B2C90:01C9C8AD] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 09:30:03 -0000 Thanks Nurit. Did you see Andy Reid's post dated Tue 28/04/2009 23:26. I believe Andy is addressing your questions here. Andy is out right now but will be responding to any further questions on the explantion he gave later today (I see Maarten has already posted some further questions to Andy). regards, Neil > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > [mailto:nurit.sprecher@nsn.com]=20 > Sent: 29 April 2009 08:58 > To: Harrison,N,Neil,CXM R > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > transportpathrequirements) >=20 > Neil, > Thanks for the very good explanation. It really helps me to understand > better the context of the long discussion.=20 > Personally I got many feedbacks from Tier-1 SPs that they=20 > would like to > have the capability to suppress alarms in a packet transport > environment. Their requirement was that if a server layer=20 > (e.g. MPLS-TP > link) fails, there is a way to notify the client layer (e.g. LSPs) in > order to be able to suppress alarms at the client layer that=20 > may result > from the fault at the server layer (e.g. MPLS-TP link).=20 > Isn't it a logical and reasonable requirement in a transport profile? > Also I saw general requirements for inter-layer fault correlation. So > can I understand from your mail that you are not happy from such a > requirement as well? > Best regards, > Nurit > =20 >=20 >=20 > -----Original Message----- > From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Tuesday, April 28, 2009 11:07 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) >=20 > Nurit, >=20 > I believe the reason we need this discussion is that there is an > unstated assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in=20 > response to > link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating=20 > party as the > client) then there is no fixed client/server relationship. >=20 > Refer to my post earlier today and consider what this means=20 > in the case > of a cl-ps IP client layer network or a some SVC-based=20 > co-ps/co-cs mode > client layer network. The key point here is the *routing process* in > the client is independent of the server layer network....so=20 > there is not > a fixed client/server relationship. Further, there is also no > requirement for the server to keep track of where its client traffic > routings are at any epoch.....indeed why should it in the general case > where these are independent layer networks? >=20 > So the only OAM requirement that is critical is that the OAM of the > client and server layer networks are independent. It is thus not > sensible to make client layer alarm supression a=20 > 'requirement' here...in > fact if this is in the OAM requirements then it is=20 > technically wrong and > should be removed IMO. >=20 > regards, Neil=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > > Nurit (NSN - IL/Hod HaSharon) > > Sent: 28 April 2009 08:46 > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > transportpathrequirements) > >=20 > > If we agree that the requirement is included, so why do we=20 > > keep with the > > endless discussions on this requirement? > >=20 > > -----Original Message----- > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it]=20 > > Sent: Tuesday, April 28, 2009 10:44 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > > hhelvoort@chello.nl; Adrian > > Farrel > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional transport > > pathrequirements) > >=20 > > I think that the requirements are defined in section 2.2.8 of > > draft-ietf-mpls-tp-oam-requirements-01 > >=20 > > Italo > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > > > Nurit (NSN - IL/Hod HaSharon) > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > To: hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > > transport pathrequirements) > > >=20 > > > Huub, > > > I think that the requirement is to provide a mechanism to suppress > > > alarms in the networks, to ensure that alarms that may be=20 > > generated by > > > client layers as a result of a failure condition in the=20 > > > server layer may > > > be suppressed. > > > Every thing else is a solution, etc.=20 > > > I propose to phrase the requirement appropriately and conclude the > > > discussion on this in the context of the requirements=20 > (until we are > > > getting to the solution phase).=20 > > > This requirement is included in the OAM requirement draft.=20 > > > Best regards, > > > NUrit > > >=20 > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On > > > Behalf Of ext Huub van Helvoort > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > To: Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated=20 > > bidirectional transport > > > path requirements) > > >=20 > > > Hi Adrian, > > >=20 > > > You wrote: > > >=20 > > > > Isn't the solution here the same as the one I proposed=20 > for "TCM"? > > >=20 > > > Indeed, and that we do not have to around in circles about TCM. > > >=20 > > > How about: > > > the requirement is that a server layer shall inform its clients > > > that it has detected a service interuption, this to ensure that > > > the clients can inhibit (unnecessary) alarms. > > >=20 > > > Cheers, Huub. > > >=20 > > > --=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > http://www.van-helvoort.eu/ > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Always remember that you are unique...just like everyone else... > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 From Alexander.Vainshtein@ecitele.com Wed Apr 29 02:36:42 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAD13A6B7F for ; Wed, 29 Apr 2009 02:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc7A6cO6xory for ; Wed, 29 Apr 2009 02:36:40 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 068143A70B1 for ; Wed, 29 Apr 2009 02:35:45 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 29 Apr 2009 12:34:41 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 12:36:59 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 29 Apr 2009 12:36:59 +0300 From: Alexander Vainshtein To: Igor Bryskin , Maarten Vissers , "neil.2.harrison@bt.com" , "nurit.sprecher@nsn.com" , "Italo.Busi@alcatel-lucent.it" , "hhelvoort@chello.nl" , "adrian@olddog.co.uk" Date: Wed, 29 Apr 2009 12:36:58 +0300 Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAmohI7 Message-ID: References: <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> <009701c9c7ff$83ca4930$6c02a8c0@china.huawei.com>, <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3457FB@atl-srv-exgen.atl.advaoptical.com> In-Reply-To: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B3457FB@atl-srv-exgen.atl.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90BEILPTMAIL02eci_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2009 09:36:59.0521 (UTC) FILETIME=[0B3D6F10:01C9C8AE] Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 09:36:42 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90BEILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, Maarten, Neil and all, I may be completely wrong, but why should the server (MPLS-TP transport pa= th) be aware of any specific clients that use it, be it a the path terminat= ion point or in the intermediate node? To the best of my understanding, 1. MPLS (not TP) data plane architecture does not require this: * As long as the server LSP is not terminated, LSR does not looks onl= y on the top label * Once the server LSP is terminated (which, IMO, is equivalent to the= top label being popped), switching is done on the next label without "keep= ing in mind" the popped label 2. The MPLS-TP requirements draft does not contain an appropriate require= ment of such awareness. On the contrary, Requirement 25A seems to make such= awareness undesirable. 3. In SONET/SDH the server is not aware of any specific clients: if a ser= ver failure is detected, its consequent action spreads "all ones" over all = potential clients. But this is somewhat difficult to imitate in packet netw= orks 4. In ATM, the server (VPC) termination point is, indeed, fully aware of = all its clients (VPC). But this awareness is dictated by the ATM data plane= where VPI is link-local and VCI is link- and VPI-local. In other words, IMHO and FWIW, server awareness of its clients (or lack the= reof) is dictated by the data plane specifics. As long as we state that MPL= S-TP data plane is the same as that of MPLS, such awareness does not exist = in MPLS-TP. And I do not think that it is correct to derive data plane requ= irements from OAM concepts. Did I miss something important here? Regards, and thanks in advance, Sasha ________________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Igor= Bryskin [IBryskin@advaoptical.com] Sent: Tuesday, April 28, 2009 6:04 PM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.= Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you = keep talking about fixed client-server relationship. It is fixed as long as= the client layer connection configured this way (statically or dynamically= ). As soon as the connection is re-routed, this relationship is broken (bec= ause this is a part of the re-routing process) and hence the server trail t= ermination points will know that the server trail now serves one connection= less, whereas some other server trail(s) will learn that they serve from n= ow on one connection more. These new client-server relationships are fixed = until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-luce= nt.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation= . There is no difference with what we do today in SDH and OTN. A client/serve= r relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generatio= n is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of = a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client i= s independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO= . regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://www.van-helvoort.eu/ > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90BEILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, Maarten, Neil and all, I may be completely wrong, but why should = the server (MPLS-TP transport path) be aware of any specific clients that u= se it, be it a the path termination point or in the intermediate node? To the best of my understanding, MPLS (not TP) data plane architecture does not = require this: As long as the s= erver LSP is not terminated, LSR does not looks only on the top label Once the server L= SP is terminated (which, IMO, is equivalent to the top label being popped),= switching is done on the next label without "keeping in mind" th= e popped label The MPLS-TP requi= rements draft does not contain an appropriate requirement of such awareness= . On the contrary, Requirement 25A seems to make such awareness undesirable= . In SONET/SDH the = server is not aware of any specific clients: if a server failure is detected, its consequent = action spreads "all ones" over all potential clients. But this is somewhat difficult to imitate i= n packet networks In ATM, the serve= r (VPC) termination point is, indeed, fully aware of all its clients (VPC).= But this awareness is dictated by the ATM data plane where VPI is link-loc= al and VCI is link- and VPI-local. In other words, IMHO an= d FWIW, server awareness of its clients (or lack thereof) is dictated by th= e data plane specifics. As long as we state that MPLS-TP data plane is the = same as that of MPLS, such awareness does not exist in MPLS-TP. And I do not think that it is correct to derive= data plane requirements from OAM concepts. Did I miss something im= portant here? Regards, and thanks in = advance,     = ; Sasha &nb= sp; ________________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Igor= Bryskin [IBryskin@advaoptical.com] Sent: Tuesday, April 28, 2009 6:04 PM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.= Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you = keep talking about fixed client-server relationship. It is fixed as long as= the client layer connection configured this way (statically or dynamically= ). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-r= outing process) and hence the server trail termination points will know tha= t the server trail now serves one connection less, whereas some other serve= r trail(s) will learn that they serve from now on one connection more. These new client-server relationshi= ps are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-luce= nt.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathre= quirements) Neil, > However, if the client can dynamically change its routing in response<= br> > to link failures in its topology (because some server layer network ha= s > failed....which may or may not belong to the same operating party as t= he > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in<= br> the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation= . There is no difference with what we do today in SDH and OTN. A client/serve= r relationship is fixed until the point in time that the connection is either= teardown or rerouted. When either of the two cases occur, the AIS generatio= n is stopped. Until such action is performed, AIS is generated during signal<= br> fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result= is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf<= br> Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of = a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the cli= ent is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for= the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client<= br> and server layer networks are independent. It is thus not sensible to= make client layer alarm supression a 'requirement' here...in fact if this is in<= br> the OAM requirements then it is technically wrong and should be removed IMO= . regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -<= br> > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport= > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (N= SN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppres= s > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server la= yer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude th= e > > discussion on this in the context of the requirements (until we a= re > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] = On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for &= quot;TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients t= hat > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >           =          http://www.van-helvoort.eu= / > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Always remember that you are unique...just like everyone else...<= br> > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --_000_A3C5DF08D38B6049839A6F553B331C76A8CEED90BEILPTMAIL02eci_-- From su.hui@zte.com.cn Wed Apr 29 02:36:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1833A6EB3; Wed, 29 Apr 2009 02:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.19 X-Spam-Level: X-Spam-Status: No, score=-92.19 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_81=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev2A4Ao3yv1G; Wed, 29 Apr 2009 02:36:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1EB3628C199; Wed, 29 Apr 2009 02:36:00 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641105171106; Wed, 29 Apr 2009 17:26:14 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 74772.5514055519; Wed, 29 Apr 2009 17:29:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3T9Wvhw059018; Wed, 29 Apr 2009 17:32:59 +0800 (CST) (envelope-from su.hui@zte.com.cn) In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C047E2187@E03MVB2-UKBR.domain1.systemhost.net> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: su.hui@zte.com.cn Date: Wed, 29 Apr 2009 17:30:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-29 17:32:49, Serialize complete at 2009-04-29 17:32:49 Content-Type: multipart/alternative; boundary="=_alternative 0034744D482575A7_=" X-MAIL: mse1.zte.com.cn n3T9Wvhw059018 Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: [mpls-tp] =?gb2312?b?tPC4tDogUkU6IFJlOiAgQUlTL0ZESSAod2FzIEFzc29j?= =?gb2312?b?aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aAlyZXF1aXJlbWVu?= =?gb2312?b?dHMp?= X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 09:36:45 -0000 This is a multipart message in MIME format. --=_alternative 0034744D482575A7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTmVpbKOsDQoNClRoYW5rcyBmb3IgeW91ciByYXBpZCByZXBseS4NCkkgYW0gY29uZnVzZWQg YnkgeW91ciBjb21tZW50cywgYXJlIHlvdSBzdWdnZXN0aW5nIA0KRXZlcnl0aGluZ292ZXJJUG92 ZXJNUExTLVRQPyBBRkFJSywgTVBMUy1UUCBjYW4gY2FycnkgbWFueSBraW5kcyBvZiANCmNsaWVu dHMsIG5vdCBqdXN0IElQLkluIG15IGV4YW1wbGUsIEUxb3ZlclBXb3Zlck1QTFMtVFAsIHRoZXJl IGlzIG5vIElQIA0KbGF5ZXIgYXQgYWxsLg0KQW5kIHlvdSBkb26hr3QgYW5zd2VyIG15IHF1ZXN0 aW9uOiBJUCBpcyBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGluIHRoZSANCmNhc2Ugb2YgRTFvdmVy UFdvdmVySVAsIHdoeSBkb2Vzbid0IE1QTFMtVFAgYmUgYSB0b3Atb2Ytc3RhY2sgbmV0d29yayBp biANCnRoZSBjYXNlIG9mIEUxb3ZlclBXb3Zlck1QTFMtVFA/IFRoZXkgYXJlIGF0IHRoZSBzYW1l IHBvc2l0aW9uIGluIHRoZSANCnN0YWNrLCBhbmQgSSB0aGluayBFMSBpcyChrnJlYWwgZXh0ZXJu YWwgc3RyZWFtIGFwcGxpY2F0aW9uc6GvDQoNClJlZ2FyZHMsDQpTdWh1aS4NCg0KDQoNCjxuZWls LjIuaGFycmlzb25AYnQuY29tPiANCjIwMDktMDQtMjkgMTQ6NDANCg0KytW8/sjLDQo8c3UuaHVp QHp0ZS5jb20uY24+DQqzrcvNDQo8YWRyaWFuQG9sZGRvZy5jby51az4sIDxiZW5qYW1pbi5uaXZl bi1qZW5raW5zQGJ0LmNvbT4sIA0KPGhoZWx2b29ydEBjaGVsbG8ubmw+LCA8bXBscy10cEBpZXRm Lm9yZz4sIDxtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc+DQrW98ziDQpSRTogUmU6IFttcGxzLXRw XSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIA0K cmVxdWlyZW1lbnRzKQ0KDQoNCg0KDQoNCg0KVGhhbmtzIFNodWh1aSwNCiANCkRvIG5vdCBjb25m dXNlIHBoeXNpY2FsIGludGVyY29ubmVjdCB3aXRoIEUtTk5JLi4uLi5JJ2xsIGNvbWUgYmFjayBv biB0aGlzIA0Kc2hvcnRseSB3aGVuIGRpc2N1c3NpbmcgdGhlIGJvdHRvbS1vZi1zdGFjayBzZWN0 aW9uIGxheWVyLg0KIA0KVGhlIGZpcnN0IHRoaW5nIHRvIHVuZGVyc3RhbmQgaXMgdGhhdCAqYWxs KiBuZXR3b3JrcyBhcmUgdGhlcmUgdG8gDQp1bHRpbWF0ZWx5IHN1cHBvcnQgb25lIHB1cnBvc2Uu Li4uLmFuZCB0aGF0IGlzIHRvIGFsbG93IGNvbW11bmljYXRpb25zIA0KYmV0d2VlbiBwYXJ0aWVz IHRoYXQgYXJlICpleHRlcm5hbCogdG8gdGhlIG5ldHdvcmtzLiAgU28gZXZlcnl0aGluZyB3ZSBk byANCmluIG5ldHdvcmtpbmcgaXMgdGhlcmUgdG8gdWx0aW1hdGVseSBzdXBwb3J0IHRoaXMgb2Jq ZWN0aXZlLiAgV2hhdCB0aGlzIA0KbWVhbnMgaXMgdGhhdCB0aGUgRFAgb2Ygc29tZSBuZXR3b3Jr ICh3aGF0IEkgY2FsbCB0aGUgdG9wLW9mLXN0YWNrIA0KbmV0d29yaykgTVVTVCBiZSBwcm92aWRp bmcgYWRhcHRhdGlvbiBmdW5jdGlvbnMgZm9yIHRoZXNlIGV4dGVybmFsIA0KYXBwbGljYXRpb25z Li4uLi4uLmFuZCB0aGVzZSBjYW4gZ2VuZXJpY2FsbHkgYmUgY2xhc3NpZmllZCBhcyBtZXNzYWdl cywgDQpmaWxlcyBhbmQgc3RyZWFtcy4gDQogDQpXZSBjYW4gc2VlIHRoYXQgSVAgaXMgYSB0b3At b2Ytc3RhY2sgbmV0d29yayBhcyBpdCBoYXMgVURQL1RDUC9SVFAgKGZvciANCmV4YW1wbGUpIGFk YXB0YXRpb25zLiAgQVRNIHdhcyBhbHNvIG9uY2UgKH45MHMpIGludGVuZGVkIHRvIGJlIGEgDQp0 b3Atb2Ytc3RhY2sgbmV0d29yayBhbmQgaXQgaGFkIGl0cyBvd24gYXBwbGljYXRpb24gYWRhcHRh dGlvbnMgaW4gdGhlIA0KZm9ybSBvZiBBQUxzLiAgQXQgb25lIHN0YWdlIHRoZXJlIHdlcmUgNSBv ZiB0aGVzZSwgYnV0IGluIHByYWN0aWNlIG9ubHkgYSANCmNvdXBsZSB3ZXJlIHJlYWxseSBzdWNj ZXNzZnVsIGJlY2F1c2Ugb2YgdGhlIGdlbmVyaWMgbmF0dXJlIG9mIA0KbWVzc2FnZS9maWxlL3N0 cmVhbSBjbGFzc2lmaWNhdGlvbi4gIFRoZSBQU1ROIGlzIGFsc28gdG9wLW9mLXN0YWNrLCBhbmQg DQppdHMgYXBwbGljYXRpb24gYWRhcHRhdGlvbiB3YXMgbWFpbmx5IGZvciB2b2ljZSAoc3RyZWFt KSBzdXBwb3J0Lg0KIA0KTW9zdCBvdGhlciBuZXR3b3JrcyBkbyBub3QgaGF2ZSB0aGVzZSBhcHBs aWNhdGlvbiBhZGFwdGF0aW9uIA0KZnVuY3Rpb25zLi4uLnNvIHRoZXkgZG8gbm90IGRpcmVjdGx5 IHN1cHBvcnQgYXBwbGljYXRpb25zLiAgV2hhdCB0aGlzIA0KbWVhbnMgaW4gcHJhY3RpY2UgaXMg dGhhdCB0aGVzZSBuZXR3b3JrcyAoYSBsaXN0IHdoaWNoIGluY2x1ZGVzIFBESCwgU0RILCANCk9U TiwgRXRoZXJuZXQsIE1QTFMpIE1VU1QgY2FycnkgYSBmdXJ0aGVyIGxheWVyIG5ldHdvcmsgYWJv dmUgdGhlbSB0aGF0IGlzIA0KdG9wLW9mLXN0YWNrLi4uLmxpa2UgSVAuICBUaGVyZSBpcyBubyBj aG9pY2UgaW4gdGhlIG1hdHRlciBoZXJlLiAgU28gDQp3aGlsc3Qgd2UgbWlnaHQgc2F5IHRoYXQg YW4gTVBMUyBuZXR3b3JrIGlzIGNhcnJ5aW5nIGFuIEUxIFBXIHRoZSBFMSANCmVudGl0eSBtdXN0 IGluIHR1cm4gYmUgY2Fycnlpbmcgc29tZSBvdGhlciB0b3Atb2Ytc3RhY2sgbmV0d29yayAobGlr ZSBJUCANCm9yIFBTVE4pLCBlbHNlIGl0IGlzIHNlcnZpbmcgbm8gdWx0aW1hdGUgcHVycG9zZS4N CiANCk5vdyBpbiBvcmRlciB0byB0cmFuc21pdCBpbmZvcm1hdGlvbiBvdmVyIGdlb2dyYXBoaWMg ZGlzdGFuY2Ugd2UgbXVzdCANCm1vZHVsYXRlIGFuIEVNIHdhdmUgb24gc29tZSBtZXRhbGxpYy9v cHRpY2FsL3JhZGlvIG1lZGlhLi4uLnRoaXMgaXMgdGhlIA0KYm90dG9tLW9mLXN0YWNrIHNlY3Rp b24gbGF5ZXIuICBUaGVzZSBhcmUgaGlnaCBiaXQgcmF0ZSB0cmFuc3BvcnQgcGlwZXMgDQp3aG9z ZSBmdW5jdGlvbiBpcyB0byBwcm92aWRlIHRyYW5zcGFyZW50ICh3aGljaCBJIGhhdmUgZGVmaW5l ZCBwcmV2aW91c2x5KSANCnRyYW5zcG9ydCB0byB3aGF0ZXZlciBjbGllbnQgbGF5ZXJzIG5ldHdv cmtzIHNpdCBhYm92ZSB0aGVtLi4uLmFuZCB3aGVyZSwgDQphcyBJIG5vdGVkIGFib3ZlLCB0aGVy ZSBNVVNUIGJlIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgcHJlc2VudCBhcyB0aGUgDQp1bHRpbWF0 ZSBsYXllciBuZXR3b3JrIGNsaWVudCBlbHNlIHRoZXJlIGlzIG5vdCBleHRlcm5hbCBwYXJ0eSAN CmNvbW11bmljYXRpb24gcG9zc2libGUuDQogDQpTbyB3aGVuIHdlIGNvbm5lY3QgdG9nZXRoZXIg MiB0b3Atb2Ytc3RhY2sgbmV0d29ya3Mgd2UgZG8gc28gYXQgYSBzZWN0aW9uIA0KbGF5ZXIgd2hp Y2ggaXMgaW52YXJpYWJseSBjYXJyeWluZyBhIHZlcnkgbGFyZ2UgYWdncmVnYXRlIG9mIA0KYXBw bGljYXRpb25zLi4uLi5hbmQgb2YgY291cnNlIHRoZXNlIGFwcGxpY2F0aW9ucyBjYW4gYmUgYSB0 aW1lIHZhcnlpbmcgDQptaXggb2YgbWVzc2FnZS9maWxlL3N0cmVhbSBjYXNlcyB3aXRoIGEgc2V0 IG9mIHVua25vd24gKHRvIHRoZSBzZWN0aW9uIA0KbGF5ZXIpIGltcG9ydGFuY2UncyAoZXJnbyB3 aHkgdHJhbnNwYXJlbmN5IGlzIGFuIGVzc2VudGlhbCByZXF1aXJlbWVudCBpbiANCnRyYW5zcG9y dCBuZXR3b3JrcykuDQogDQpUaGUgcmVhbCBFLU5OSXMgKHdoaWNoIGNvbnNpZGVycyBib3RoIERQ IGFuZCBDUCBjb21wb25lbnRzLi4uLndlIG5ldmVyIA0KdXN1YWxseSBwZWVyIHRoZSBNUCwgYW5k IHdlIHJlc3RyaWN0IHRoZSBzY29wZSBvZiB0aGUgQ1ApIGV4aXN0IGluIHRoZSANCnRvcC1vZi1z dGFjayBsYXllciBuZXR3b3JrLiAgVGhlIHNlY3Rpb24gbGF5ZXIgaW50ZXJjb25uZWN0IGlzIGEg ZHVtYiBEUCANCnBpcGUuLi5pdCBqdXN0IHNoaWZ0cyBiaXRzIHRyYW5zcGFyZW50bHkgYW5kIG1h aW50YWlucyB0aGVpciBvcmRlcmluZy4gDQpUaGVyZSBpcyBubyBjb25jZXB0IG9mIENQIChvciBN UCkgcGVlcmluZyBvbiB0aGVzZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiANCmxheWVyIGludGVy Y29ubmVjdHMuDQpBc2lkZT0+IEluIHNvbWUgY291bnRyaWVzIHRoZXNlIGludGVyY29ubmVjdHMg aGF2ZSB0byBiZSBjYXJlZnVsbHkgDQpzcGVjaWZpZWQgaW4gb3JkZXIgdG8gZGlzdGluZ3Vpc2gg cmVndWxhdGVkIGFuZCB1bnJlZ3VsYXRlZCANCnNlcnZpY2VzLi4uLi5zbyB0aGVyZSBhcmUgaW1w b3J0YW50IGxlZ2FsL2NvbW1lcmNpYWwgY29uc2lkZXJhdGlvbnMgaGVyZSwgDQppdCBpcyBub3Qg c2ltcGx5IGEgdGVjaG5pY2FsIGlzc3VlLg0KIA0KV2UgY2FuIG9mIGNvdXJzZSBjcmVhdGUgRS1O TklzIGluIG5vbiB0b3Atb2Ytc3RhY2sgbGF5ZXIgbmV0d29ya3MgKHdlIGNhbiANCmRvIG1hbnkg dGhpbmdzIHRoYXQgYXJlIG5vdCB1c2VmdWwpLiAgU28gbGV0cyBhc3N1bWUgd2UgZG8gdGhpcy4u Li4uYW5kIA0KbGV0cyBhc3N1bWUgd2UgY2hvb3NlIE1QTFMgc2luY2UgeW91IG1lbnRpb24gdGhp cyBpbiB0aGUgbWFpbCBiZWxvdy4gDQogDQpOb3cgaG93IGRvIGV4dGVybmFsIHBhcnRpZXMgd2hv IHdpc2ggdG8gY29tbXVuaWNhdGUgaW50ZXJmYWNlIHdpdGggdGhpcyANCk1QTFMgbmV0d29yaz8g IENhbiB5b3Ugc3VwcG9ydCBhbGwgdHlwZXMgb2YgbWVzc2FnZS9maWxlL3N0cmVhbSANCmFwcGxp Y2F0aW9ucyAqZGlyZWN0bHkqIGludG8gTVBMUz8gIEluIHByaW5jaXBsZSB5b3UgY291bGQgaWYg eW91IGFsbG93ZWQgDQpNUExTIHRvIGhhdmUgZW5kIHN5c3RlbSBhcHBsaWNhdGlvbiBhZGFwdGF0 aW9ucyBzdWNoIGFzIFVEUC9UQ1AvUlRQIG9yIHRoZSANCmxpa2UuICBCdXQgdGhlc2UgZG9uJ3Qg ZXhpc3QgdG9kYXksIGFuZCBpbiB0aGUgbW9zdCB1c3VhbCBjYXNlIHRoZSBNUExTIA0KbmV0d29y ayB3aWxsIGNhcnJ5IGFuIElQIGxheWVyIG5ldHdvcmsgYmVjYXVzZSB0aGlzIGNhbiBzdXBwb3J0 IHRoZSANCm1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zLg0KIA0KV2UgY2FuIGdvIHRo cm91Z2ggZXhhY3RseSB0aGUgc2FtZSBhbmFseXNpcyB3aXRoIGFueSBuZXR3b3JrIHRoYXQgaXMg bm90IA0KdG9wLW9mLXN0YWNrLCBlZyBFdGhlcm5ldC4gIEFuZCB3aGVuIHlvdSBkbyB0aGlzIHdo YXQgeW91IHJlYWxpc2UgaXMgdGhhdCANCmFsdGhvdWdoIHdlIGNhbiBjcmVhdGUgcGVlciBpbnRl cndvcmtpbmcgb2YgTVBMUyAob3Igd2hhdGV2ZXIpIHRoaXMgaGFzIA0Kbm90IHJlYWxseSBoZWxw ZWQgc2luY2Ugd2UgbWlnaHQgYXMgd2VsbCBoYXZlIGp1c3QgdGVybWluYXRlZCB0aGUgTVBMUyAN Cm5ldHdvcmsgYW5kIHBhc3NlZCB0aGUgSVAgbGF5ZXIgYWNyb3NzLg0KIA0KTm93IHRoZSBhYm92 ZSBiZWNvbWVzIGV2ZW4gbW9yZSBzdHJpa2luZyBpbiBpdHMgaW1wb3J0YW5jZSBpZiB5b3UgY29u c2lkZXIgDQpwZWVyIGludGVyd29ya2luZyBvZiAyIGRpZmZlcmVudCBub24gdG9wLW9mLXN0YWNr IG5ldHdvcmtzLi4uLmxldHMgcGljayANCk1QTFMgYW5kIEV0aGVybmV0IGJlY2F1c2UgdGhhdCBp cyB3aGF0IGlzIG9mdGVuIG1lbnRpb25lZC4gDQogDQpXaGF0IHdlIGhhdmUgdG8gZG8gbm93IGF0 IHRoZSBFLU5OSXMgYmV0d2VlbiBFdGhlcm5ldCBhbmQgTVBMUyBpcyBnbyANCnRocm91Z2ggZWFj aCBEUCBhbmQgQ1AgY29tcG9uZW50IGFuZCBkbyBhICdwcm90b2NvbCBjb252ZXJzaW9uJyBleGVy Y2lzZSANCndoZXJlIHJlcXVpcmVkLi4uLi4uYW5kIHRoZSBmaXJzdCBwcm9ibGVtIHlvdSB3aWxs IGVuY291bnRlciBpcyB0aGF0IHRoZXJlIA0Kd2lsbCBiZSBsb3RzIG9mIGZ1bmN0aW9uYWwgbWlz bWF0Y2guICBNb3Jlb3ZlciBpZiBvbmUgb3IgYm90aCBvZiB0aGUgDQpuZXR3b3JrcyBjYW4gc3Vw cG9ydCBtdWx0aXBsZSBDUCB0eXBlcyBsaWtlIE1QTFMgY2FuLCBlZyBSU1ZQLVRFIA0Kc2lnbmFs bGluZywgTERQIHNpZ25hbGxpbmcsIEJHUDQgJ3NpZ25hbGxpbmcnLCBPU1BGIHJvdXRpbmcsIElT LUlTIA0Kcm91dGluZy4uLi4uYW5kIEkgY291bGQgbGlzdCBzaW1pbGFyIGZvciBFdGhlcm5ldC4u Li4ueW91IGFyZSBnb2luZyB0byANCmhhdmUgdG8gY29uc2lkZXIgZWFjaCBwYWlyaW5nIGNhc2Ug aW4gdHVybi4gIEEgbG90IG9mIHdvcmsuDQogDQpBbmQgd2hlbiB5b3UgaGF2ZSBkb25lIGFsbCB0 aGlzIHlvdSBhc2sgdGhlIHF1ZXN0aW9uICd3aGF0IGlzIGl0IHRoYXQgDQpjYXJyaWVzIHRoZSBy ZWFsIGV4dGVybmFsIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zIGluIHRoZSBEUCAN CmhlcmU/Jy4uLi4uLi5hbmQgbm93IHlvdSBmaW5kIG5vIG5hdGl2ZSBzdXBwb3J0IGZvciB0aGVz ZSBpbiBNUExTIG9yIA0KRXRoZXJuZXQsIGJ1dCB3aGF0IHdlIGRvIGZpbmQgaXMgdGhhdCBib3Ro IG9mIHRoZW0gYXJlIGNhcnJ5aW5nIElQIGJlY2F1c2UgDQp0aGlzIGRvZXMgc3VwcG9ydCB0aGUg ZXh0ZXJuYWwgYXBwbGljYXRpb25zLiAgTm93IGF0IHRoaXMgcG9pbnQgd2UgaGF2ZSANCmRpc2Nv dmVyZWQgd2hhdCBpcyB0aGUgY29tbW9uIHRoaW5nIGJldHdlZW4gTVBMUyBhbmQgRXRoZXJuZXQu Li4uaXQgaXMgdGhlIA0KdG9wLW9mLXN0YWNrIElQIGxheWVyIG5ldHdvcmsuICBBbmQgc28gd2Ug dWx0aW1hdGVseSByZWFsaXNlIHdlIGNvdWxkIGhhdmUgDQpzYXZlIG91cnNlbHZlcyBhIGxvYWQg b2YgdW5uZWNlc3Nhcnkgd29yayBieSBzaW1wbHkgdGVybWluYXRpbmcgdGhlIE1QTFMgDQphbmQg RXRoZXJuZXQgbGF5ZXIgbmV0d29yayBhdCB0aGUgaW50ZXJ3b3JraW5nIHBvaW50IGFuZCBqdXN0 IHBhc3NlZCB0aGUgDQpJUCBsYXllciBuZXR3b3JrIGFjcm9zcy4NCiANClNvcnJ5IEkndmUgaGFk IHRvIGdvIHRocm91Z2ggYWxsIHRoaXMgeWV0IGFnYWluIChlc3AgZm9yIGFsbCB0aGUgZm9sa3Mg DQp0aGF0IGhhdmUgYWxyZWFkeSB1bmRlcnN0b29kIHRoZSBwb2ludCkgYnV0IEkgZG8gaG9wZSBp dHMgY2xlYXIgbm93IGFuZCB3ZSANCmNhbiBwdXQgdGhpcyBpc3N1ZSB0byBiZWQuDQogDQpyZWdh cmRzLCBOZWlsIA0KDQpGcm9tOiBzdS5odWlAenRlLmNvbS5jbiBbbWFpbHRvOnN1Lmh1aUB6dGUu Y29tLmNuXSANClNlbnQ6IDI5IEFwcmlsIDIwMDkgMDM6MjINClRvOiBIYXJyaXNvbixOLE5laWws Q1hNIFINCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBOaXZlbi1qZW5raW5zLEIsQmVuLERNRiBS OyBoaGVsdm9vcnRAY2hlbGxvLm5sOyANCm1wbHMtdHBAaWV0Zi5vcmc7IG1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIA0KdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQoN CkhpIE5laWwsIA0KDQqhrml0IGlzIHF1aXRlIGNsZWFyIGZyb20gYSBzaW1wbGUgdGVjaG5pY2Fs IGFuYWx5c2lzIHRoYXQgYW55IG5vbiANCnRvcC1vZi1zdGFjayBuZXR3b3JrIGhhcyBubyBuZWVk IGZvciBFLU5OSSBwZWVyLXBhcnRpdGlvbiB3b3JraW5nIGJldHdlZW4gDQpkaWZmZXJlbnQgb3Bl cmF0aW5nIHBhcnRpZXMuoa8gDQoNCkkgY2Fubm90IGFncmVlIHRoaXMgc3RhdGVtZW50LiANCkZv ciBleGFtcGxlLCB0aGVyZSBhcmUgdHdvIElQIG5ldHdvcmtzIGJlbG9uZ2luZyB0byB0d28gb3Bl cmF0b3JzLCBhIEUxIGlzIA0KdHJhbnNwb3J0ZWQgZnJvbSBBIG5ldHdvcmsgdG8gQiBuZXR3b3Jr IChlLmcuIEUxb3ZlclBXb3ZlcklQICksIElQIA0KcGFja2V0KG5vdCBFMSkgcGFzcyBhY3Jvc3Mg Zm9ybSBBIHRvIEIgYXQgYm9yZGVyIG5vZGUsIHNvIHRoZXJlIGlzIGEgRS1OTkkgDQpiZXR3ZWVu IHRoZXNlICB0d28gSVAgbmV0d29yay4gSW4gdGhpcyBjYXNlLCBpcyBJUCBhIHRvcC1vZi1zdGFj ayBuZXR3b3JrPyANCg0KTm93IGxldCB1cyByZXBsYWNlIElQIG5ldHdvcmtzIGJ5IE1QTFMtVFAg bmV0d29ya3MgKGUuZy4gDQpFMW92ZXJQV292ZXJNUEwtVFApLCBNUExTLVRQIG5ldHdvcmsgaXMg YXQgc2FtZSBwb3NpdGlvbiBpbiB0aGUgc3RhY2sgYXMgDQpJUCBuZXR3b3JrIGlzLCB3aHkgY2Fu IElQIG5ldHdvcmsgaGF2ZSBFLU5OSSBidXQgTVBMUy1UUCBjYW5ub3Q/IA0KDQpSZWdhcmQsIA0K U3VodWkgDQoNCg0KPG5laWwuMi5oYXJyaXNvbkBidC5jb20+IA0Kt6K8/sjLOiAgbXBscy10cC1i b3VuY2VzQGlldGYub3JnIA0KMjAwOS0wNC0yOCAxNDo0MyANCg0KDQrK1bz+yMsNCjxoaGVsdm9v cnRAY2hlbGxvLm5sPiwgPGFkcmlhbkBvbGRkb2cuY28udWs+LCANCjxiZW5qYW1pbi5uaXZlbi1q ZW5raW5zQGJ0LmNvbT4gDQqzrcvNDQptcGxzLXRwQGlldGYub3JnIA0K1vfM4g0KUmU6IFttcGxz LXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo IA0KcmVxdWlyZW1lbnRzKQ0KDQoNCg0KDQoNCg0KDQoNCkh1dWIgd3JvdGUgMjcgQXByaWwgMjAw OSAyMjoyNw0KPiANCj4gSGkgQWRyaWFuLA0KPiANCj4gWW91IHdyb3RlOg0KPiANCj4gPiBJc24n dCB0aGUgc29sdXRpb24gaGVyZSB0aGUgc2FtZSBhcyB0aGUgb25lIEkgcHJvcG9zZWQgZm9yICJU Q00iPw0KPiANCj4gSW5kZWVkLCBhbmQgdGhhdCB3ZSBkbyBub3QgaGF2ZSB0byBhcm91bmQgaW4g Y2lyY2xlcyBhYm91dCBUQ00uDQo+IA0KPiBIb3cgYWJvdXQ6DQo+IHRoZSByZXF1aXJlbWVudCBp cyB0aGF0IGEgc2VydmVyIGxheWVyIHNoYWxsIGluZm9ybSBpdHMgY2xpZW50cw0KPiB0aGF0IGl0 IGhhcyBkZXRlY3RlZCBhIHNlcnZpY2UgaW50ZXJ1cHRpb24sIHRoaXMgdG8gZW5zdXJlIHRoYXQN Cj4gdGhlIGNsaWVudHMgY2FuIGluaGliaXQgKHVubmVjZXNzYXJ5KSBhbGFybXMuDQoNCk5IPT4g VGhpcyBvbmx5IGFwcGxpZXMgaWYgdGhlIGNsaWVudC9zZXJ2ZXIgYmluZGluZyBpcyBmaXhlZC4g IEFuZCBvZg0KY291cnNlIHdheSBiYWNrIGluIHRoZSA3MHMgd2hlbiBiaW5hcnkgYWxsIDFzIHBv cHBlZCBvdXQgb2YgdGhlIGZhaWxlZA0KVFRMIGxvZ2ljIGludG8gdGhlIFBESCB0cmFuc3BvcnQg aGllcmFyY2h5IHRoaXMgd2FzIHRydWUuICBBbHNvOiBubw0KbGFiZWxzIGhlcmUgYW5kIG5vIGNs aWVudCB0cmFmZmljIHVuaXRzIHRvIGNyZWF0ZS4gDQoNCldoZXJlIHRoZSBjbGllbnQgY2FuIGR5 bmFtaWNhbGx5IGJlIHJlLXJvdXRlZCBpbiByZXNwb25zZSB0byBhIHNlcnZlcg0KZmFpbHVyZSB0 aGUgcHJvcG9zZWQgdGV4dCBpcyBub3QgdmFsaWQuICBJdCBpcyBhbHNvIG5vdCBuZWNlc3Nhcnkg dGhhdA0KdGhlIHNlcnZlciBoYXMgdG8ga2VlcCB0cmFjayBvZiB3aGVyZSBpdHMgY2xpZW50IHRy YWZmaWMgcm91dGluZ3MgaGF2ZQ0KbW92ZWQgdG8uICBGb3IgZXhhbXBsZSwgaWYgSSBjcmVhdGUg dGhlIHRvcG9sb2d5IG9mIGFuIElQIGxheWVyIG5ldHdvcmsNCndpdGggbGlua3MgcHJvdmlkZWQg YnkgU0RILCBFdGhlcm5ldCwgQVRNLCBPVE4sIGV0YyBzZXJ2ZXJzLCBhbmQgZWFjaCBvZg0KdGhl c2Ugc2VydmVyIGxpbmtzIGlzIHByb3ZpZGVkIGJ5IGEgZGlmZmVyZW50IG9wZXJhdG9yLCB0aGVu IHdoeSBzaG91bGQNCnRoZSBzZXJ2ZXJzIG5lZWQgaGF2ZSBrbm93bGVkZ2Ugb2Ygd2hlcmUgdGhl IElQIGZsb3dzIGhhdmUgbW92ZWQgdG8gaW4NCnJlc3BvbnNlIHRvIGEgc2VydmVyIGxheWVyIGZh aWx1cmUgd2hlbiB0aGUgbmV3IHJvdXRlcyBoYXZlIGJlZW4NCmNhbGN1bGF0ZWQgYnkgdGhlIElH UCBpbiB0aGUgSVAgbGF5ZXIgbmV0d29yaz8gIEkgY2FuIGFwcGx5IHRoZSBzYW1lDQpsb2dpYyB0 byBhbiBTVkMtYmFzZWQgY28tcHMvY28tY3MgbW9kZSBjbGllbnQuLi4uaW5kZWVkIHRoZSBjby1j cyBtb2RlDQpQU1ROIGlzIGxpa2UgdGhpcy4NCg0KVGhlc2Ugb2JzZXJ2YXRpb25zIG1ha2UgaXQg cXVpdGUgY2xlYXIgdG8gbWUgYXQgbGVhc3QgdGhhdCBqdXN0IGNvcHlpbmcNCnRoZSBBSVMgYmVo YXZpb3VyIG9mIHRoZSBvbGQgdHJhbnNwb3J0IGhpZXJhcmNoaWVzIHRoYXQgaGFkIGZpeGVkDQpj bGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcHMgaXMgbm90IGEgc2Vuc2libGUgdGhpbmcgdG8gZG8u DQoNCklNTyB0aGUgb25seSBlc3NlbnRpYWwgRFAgT0FNIHJlcXVpcmVtZW50IGlzIHRoYXQgZWFj aCBsYXllciBuZXR3b3JrDQpzaG91bGQgYmUgc2VsZi1zdWZmaWNpZW50IHdydCBPQU0gYW5kIG5v dCByZWx5IG9uIGFueSBzZXJ2ZXIgbGF5ZXINCnByaW1pdGl2ZXMgYmVpbmcgcGFzc2VkIHVwd2Fy ZHMuDQoNCk1vcmVvdmVyLCBpdCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0IChpKSB0aGUgZGVm ZWN0cyB0aGF0IGNhbiBvY2N1ciBpbg0KZWFjaCBvZiB0aGUgMyBuZXR3b3JrIG1vZGVzIGFyZSBu b3QgdGhlIHNhbWUgYW5kIChpaSkgdGhlaXIgT0FNDQpyZXF1aXJlbWVudHMgYXJlIG5vdCBpZGVu dGljYWxseSB0aGUgc2FtZS4gU28gdGhlIE9BTSB0aGF0IGFwcGxpZXMgdG8NCnRoZSBjbC1wcyBt b2RlIChlZyBJUCkgaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvIHRo ZQ0KY28tcHMgbW9kZSAoZWcgTVBMUy1UUCkgYW5kIG5laXRoZXIgb2YgdGhlc2UgaXMgaWRlbnRp Y2FsbHkgdGhlIHNhbWUgYXMNCnRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvIHRoZSBjby1jcyBtb2Rl IChlZyBTREgpLg0KDQpOb3RlIC0gVGhlIG9ubHkgcG9pbnQgYmVpbmcgY29uc2lkZXJlZCBoZXJl IGlzIHRoZSByZWFsIGNsaWVudCBhbmQNCnNlcnZlciB0cmFmZmljIHJlbGF0aW9uc2hpcC4gIFRo ZSBjcmVhdGlvbiBvZiBhIGhpZXJhcmNoeSBvZiBUQ00NCnN1YmxheWVycyBpcyBhIHNlcGFyYXRl IHRvcGljLiAgRnVydGhlciwgaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhIHNpbXBsZQ0KdGVjaG5p Y2FsIGFuYWx5c2lzIHRoYXQgYW55IG5vbiB0b3Atb2Ytc3RhY2sgbmV0d29yayBoYXMgbm8gbmVl ZCBmb3INCkUtTk5JIHBlZXItcGFydGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3Bl cmF0aW5nIHBhcnRpZXMuICBTbw0KdGhpcyBpcyBhbHNvIGEgc2VwYXJhdGUgaXNzdWUuICBIb3dl dmVyLCBJIHByb3Bvc2UgdGhhdCB0aGlzIGxhdHRlcg0KcG9pbnQgYmUgY2FwdHVyZWQgaW4gdGhl IE1QTFMtVFAgcmVxdWlyZW1lbnRzIGRyYWZ0IGR1ZSB0byBpdHMNCnN0YW5kLWFsb25lIGFuZCBn ZW5lcmljIGltcG9ydGFuY2UsIGllIHRoaXMgYXBwbGllcyB0byBtb3JlIHRoYW4ganVzdCBEUA0K T0FNLiAgQmVuIGNhbiB5b3UgcGxlYXNlIGNvbnNpZGVyIHRoaXMgcG9pbnQgYXMvd2hlbiB0aGUg TVBMUy1UUA0KcmVxdWlyZW1lbnRzIGRyYWZ0IGlzIHVwZGF0ZWQuDQoNCnJlZ2FyZHMsIE5laWwN Cg0KPiBDaGVlcnMsIEh1dWIuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0 byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSAN CnN5c3RlbS4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N ClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0034744D482575A7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE5laWyjrDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3VyIHJh cGlkIHJlcGx5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBh bSBjb25mdXNlZCBieSB5b3VyIGNvbW1lbnRzLCBhcmUNCnlvdSBzdWdnZXN0aW5nIEV2ZXJ5dGhp bmdvdmVySVBvdmVyTVBMUy1UUD8gQUZBSUssIE1QTFMtVFAgY2FuIGNhcnJ5IG1hbnkNCmtpbmRz IG9mIGNsaWVudHMsIG5vdCBqdXN0IElQLkluIG15IGV4YW1wbGUsIEUxb3ZlclBXb3Zlck1QTFMt VFAsIHRoZXJlDQppcyBubyBJUCBsYXllciBhdCBhbGwuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgeW91IGRvbqGvdCBhbnN3ZXIgbXkgcXVlc3Rpb246DQpJ UCBpcyBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGluIHRoZSBjYXNlIG9mIEUxb3ZlclBXb3ZlcklQ LCB3aHkgZG9lc24ndA0KTVBMUy1UUCBiZSBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGluIHRoZSBj YXNlIG9mIEUxb3ZlclBXb3Zlck1QTFMtVFA/IFRoZXkNCmFyZSBhdCB0aGUgc2FtZSBwb3NpdGlv biBpbiB0aGUgc3RhY2ssIGFuZCBJIHRoaW5rIEUxIGlzIKGucmVhbCBleHRlcm5hbA0Kc3RyZWFt IGFwcGxpY2F0aW9uc6GvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5SZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+U3VodWkuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPiZsdDtuZWlsLjIuaGFycmlzb25AYnQuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTI5IDE0OjQwPC9mb250Pg0KPHRk IHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtzdS5odWlA enRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDthZHJpYW5Ab2xkZG9nLmNvLnVr Jmd0OywgJmx0O2JlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tJmd0OywNCiZsdDtoaGVsdm9v cnRAY2hlbGxvLm5sJmd0OywgJmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7LCAmbHQ7bXBscy10cC1i b3VuY2VzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFJlOiBbbXBscy10cF0g QUlTL0ZESSAod2FzIEFzc29jaWF0ZWQNCmJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVxdWlyZW1lbnRzKTwvZm9udD48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNv bWljIFNhbnMgTVMiPlRoYW5rcyBTaHVodWksPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2Fu cyBNUyI+RG8gbm90IGNvbmZ1c2UgcGh5c2ljYWwNCmludGVyY29ubmVjdCB3aXRoIEUtTk5JLi4u Li5JJ2xsIGNvbWUgYmFjayBvbiB0aGlzIHNob3J0bHkgd2hlbiBkaXNjdXNzaW5nDQp0aGUgYm90 dG9tLW9mLXN0YWNrIHNlY3Rpb24gbGF5ZXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2Fu cyBNUyI+VGhlIGZpcnN0IHRoaW5nIHRvDQp1bmRlcnN0YW5kIGlzIHRoYXQgKmFsbCogbmV0d29y a3MgYXJlIHRoZXJlIHRvIHVsdGltYXRlbHkgc3VwcG9ydCBvbmUgcHVycG9zZS4uLi4uYW5kDQp0 aGF0IGlzIHRvIGFsbG93IGNvbW11bmljYXRpb25zIGJldHdlZW4gcGFydGllcyB0aGF0IGFyZSAq ZXh0ZXJuYWwqIHRvDQp0aGUgbmV0d29ya3MuICZuYnNwO1NvIGV2ZXJ5dGhpbmcgd2UgZG8gaW4g bmV0d29ya2luZyBpcyB0aGVyZSB0byB1bHRpbWF0ZWx5DQpzdXBwb3J0IHRoaXMgb2JqZWN0aXZl LiAmbmJzcDtXaGF0IHRoaXMgbWVhbnMgaXMgdGhhdCB0aGUgRFAgb2Ygc29tZSBuZXR3b3JrDQoo d2hhdCBJIGNhbGwgdGhlIHRvcC1vZi1zdGFjayBuZXR3b3JrKSBNVVNUIGJlIHByb3ZpZGluZyBh ZGFwdGF0aW9uIGZ1bmN0aW9ucw0KZm9yIHRoZXNlIGV4dGVybmFsIGFwcGxpY2F0aW9ucy4uLi4u Li5hbmQgdGhlc2UgY2FuIGdlbmVyaWNhbGx5IGJlIGNsYXNzaWZpZWQNCmFzIG1lc3NhZ2VzLCBm aWxlcyBhbmQgc3RyZWFtcy4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+V2Ug Y2FuIHNlZSB0aGF0IElQDQppcyBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGFzIGl0IGhhcyBVRFAv VENQL1JUUCAoZm9yIGV4YW1wbGUpIGFkYXB0YXRpb25zLg0KJm5ic3A7QVRNIHdhcyBhbHNvIG9u Y2UgKH45MHMpIGludGVuZGVkIHRvIGJlIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgYW5kDQppdCBo YWQgaXRzIG93biBhcHBsaWNhdGlvbiBhZGFwdGF0aW9ucyBpbiB0aGUgZm9ybSBvZiBBQUxzLiAm bmJzcDtBdCBvbmUNCnN0YWdlIHRoZXJlIHdlcmUgNSBvZiB0aGVzZSwgYnV0IGluIHByYWN0aWNl IG9ubHkgYSBjb3VwbGUgd2VyZSByZWFsbHkNCnN1Y2Nlc3NmdWwgYmVjYXVzZSBvZiB0aGUgZ2Vu ZXJpYyBuYXR1cmUgb2YgbWVzc2FnZS9maWxlL3N0cmVhbSBjbGFzc2lmaWNhdGlvbi4NCiZuYnNw O1RoZSBQU1ROIGlzIGFsc28gdG9wLW9mLXN0YWNrLCBhbmQgaXRzIGFwcGxpY2F0aW9uIGFkYXB0 YXRpb24gd2FzDQptYWlubHkgZm9yIHZvaWNlIChzdHJlYW0pIHN1cHBvcnQuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAw MDAgZmFjZT0iQ29taWMgU2FucyBNUyI+TW9zdCBvdGhlciBuZXR3b3Jrcw0KZG8gbm90IGhhdmUg dGhlc2UgYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMuLi4uc28gdGhleSBkbyBub3Qg ZGlyZWN0bHkNCnN1cHBvcnQgYXBwbGljYXRpb25zLiAmbmJzcDtXaGF0IHRoaXMgbWVhbnMgaW4g cHJhY3RpY2UgaXMgdGhhdCB0aGVzZSBuZXR3b3Jrcw0KKGEgbGlzdCB3aGljaCBpbmNsdWRlcyBQ REgsIFNESCwgT1ROLCBFdGhlcm5ldCwgTVBMUykgTVVTVCBjYXJyeSBhIGZ1cnRoZXINCmxheWVy IG5ldHdvcmsgYWJvdmUgdGhlbSB0aGF0IGlzIHRvcC1vZi1zdGFjay4uLi5saWtlIElQLiAmbmJz cDtUaGVyZSBpcw0Kbm8gY2hvaWNlIGluIHRoZSBtYXR0ZXIgaGVyZS4gJm5ic3A7U28gd2hpbHN0 IHdlIG1pZ2h0IHNheSB0aGF0IGFuIE1QTFMNCm5ldHdvcmsgaXMgY2FycnlpbmcgYW4gRTEgUFcg dGhlIEUxIGVudGl0eSBtdXN0IGluIHR1cm4gYmUgY2Fycnlpbmcgc29tZQ0Kb3RoZXIgdG9wLW9m LXN0YWNrIG5ldHdvcmsgKGxpa2UgSVAgb3IgUFNUTiksIGVsc2UgaXQgaXMgc2VydmluZyBubyB1 bHRpbWF0ZQ0KcHVycG9zZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj5Ob3cg aW4gb3JkZXIgdG8gdHJhbnNtaXQNCmluZm9ybWF0aW9uIG92ZXIgZ2VvZ3JhcGhpYyBkaXN0YW5j ZSB3ZSBtdXN0IG1vZHVsYXRlIGFuIEVNIHdhdmUgb24gc29tZQ0KbWV0YWxsaWMvb3B0aWNhbC9y YWRpbyBtZWRpYS4uLi50aGlzIGlzIHRoZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4N CiZuYnNwO1RoZXNlIGFyZSBoaWdoIGJpdCByYXRlIHRyYW5zcG9ydCBwaXBlcyB3aG9zZSBmdW5j dGlvbiBpcyB0byBwcm92aWRlDQp0cmFuc3BhcmVudCAod2hpY2ggSSBoYXZlIGRlZmluZWQgcHJl dmlvdXNseSkgdHJhbnNwb3J0IHRvIHdoYXRldmVyIGNsaWVudA0KbGF5ZXJzIG5ldHdvcmtzIHNp dCBhYm92ZSB0aGVtLi4uLmFuZCB3aGVyZSwgYXMgSSBub3RlZCBhYm92ZSwgdGhlcmUgTVVTVA0K YmUgYSB0b3Atb2Ytc3RhY2sgbmV0d29yayBwcmVzZW50IGFzIHRoZSB1bHRpbWF0ZSBsYXllciBu ZXR3b3JrIGNsaWVudA0KZWxzZSB0aGVyZSBpcyBub3QgZXh0ZXJuYWwgcGFydHkgY29tbXVuaWNh dGlvbiBwb3NzaWJsZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj5TbyB3aGVu IHdlIGNvbm5lY3QNCnRvZ2V0aGVyIDIgdG9wLW9mLXN0YWNrIG5ldHdvcmtzIHdlIGRvIHNvIGF0 IGEgc2VjdGlvbiBsYXllciB3aGljaCBpcyBpbnZhcmlhYmx5DQpjYXJyeWluZyBhIHZlcnkgbGFy Z2UgYWdncmVnYXRlIG9mIGFwcGxpY2F0aW9ucy4uLi4uYW5kIG9mIGNvdXJzZSB0aGVzZQ0KYXBw bGljYXRpb25zIGNhbiBiZSBhIHRpbWUgdmFyeWluZyBtaXggb2YgbWVzc2FnZS9maWxlL3N0cmVh bSBjYXNlcyB3aXRoDQphIHNldCBvZiB1bmtub3duICh0byB0aGUgc2VjdGlvbiBsYXllcikgaW1w b3J0YW5jZSdzIChlcmdvIHdoeSB0cmFuc3BhcmVuY3kNCmlzIGFuIGVzc2VudGlhbCByZXF1aXJl bWVudCBpbiB0cmFuc3BvcnQgbmV0d29ya3MpLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNh bnMgTVMiPlRoZSByZWFsIEUtTk5JcyAod2hpY2gNCmNvbnNpZGVycyBib3RoIERQIGFuZCBDUCBj b21wb25lbnRzLi4uLndlIG5ldmVyIHVzdWFsbHkgcGVlciB0aGUgTVAsIGFuZA0Kd2UgcmVzdHJp Y3QgdGhlIHNjb3BlIG9mIHRoZSBDUCkgZXhpc3QgaW4gdGhlIHRvcC1vZi1zdGFjayBsYXllciBu ZXR3b3JrLg0KJm5ic3A7VGhlIHNlY3Rpb24gbGF5ZXIgaW50ZXJjb25uZWN0IGlzIGEgZHVtYiBE UCBwaXBlLi4uaXQganVzdCBzaGlmdHMNCmJpdHMgdHJhbnNwYXJlbnRseSBhbmQgbWFpbnRhaW5z IHRoZWlyIG9yZGVyaW5nLiAmbmJzcDtUaGVyZSBpcyBubyBjb25jZXB0DQpvZiBDUCAob3IgTVAp IHBlZXJpbmcgb24gdGhlc2UgYm90dG9tLW9mLXN0YWNrIHNlY3Rpb24gbGF5ZXIgaW50ZXJjb25u ZWN0cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMg U2FucyBNUyI+QXNpZGU9Jmd0OyBJbiBzb21lDQpjb3VudHJpZXMgdGhlc2UgaW50ZXJjb25uZWN0 cyBoYXZlIHRvIGJlIGNhcmVmdWxseSBzcGVjaWZpZWQgaW4gb3JkZXIgdG8NCmRpc3Rpbmd1aXNo IHJlZ3VsYXRlZCBhbmQgdW5yZWd1bGF0ZWQgc2VydmljZXMuLi4uLnNvIHRoZXJlIGFyZSBpbXBv cnRhbnQNCmxlZ2FsL2NvbW1lcmNpYWwgY29uc2lkZXJhdGlvbnMgaGVyZSwgaXQgaXMgbm90IHNp bXBseSBhIHRlY2huaWNhbCBpc3N1ZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1T Ij5XZSBjYW4gb2YgY291cnNlIGNyZWF0ZQ0KRS1OTklzIGluIG5vbiB0b3Atb2Ytc3RhY2sgbGF5 ZXIgbmV0d29ya3MgKHdlIGNhbiBkbyBtYW55IHRoaW5ncyB0aGF0IGFyZQ0Kbm90IHVzZWZ1bCku ICZuYnNwO1NvIGxldHMgYXNzdW1lIHdlIGRvIHRoaXMuLi4uLmFuZCBsZXRzIGFzc3VtZSB3ZSBj aG9vc2UNCk1QTFMgc2luY2UgeW91IG1lbnRpb24gdGhpcyBpbiB0aGUgbWFpbCBiZWxvdy4gPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+Tm93IGhvdyBkbyBleHRlcm5hbA0KcGFy dGllcyB3aG8gd2lzaCB0byBjb21tdW5pY2F0ZSBpbnRlcmZhY2Ugd2l0aCB0aGlzIE1QTFMgbmV0 d29yaz8gJm5ic3A7Q2FuDQp5b3Ugc3VwcG9ydCBhbGwgdHlwZXMgb2YgbWVzc2FnZS9maWxlL3N0 cmVhbSBhcHBsaWNhdGlvbnMgKmRpcmVjdGx5KiBpbnRvDQpNUExTPyAmbmJzcDtJbiBwcmluY2lw bGUgeW91IGNvdWxkIGlmIHlvdSBhbGxvd2VkIE1QTFMgdG8gaGF2ZSBlbmQgc3lzdGVtDQphcHBs aWNhdGlvbiBhZGFwdGF0aW9ucyBzdWNoIGFzIFVEUC9UQ1AvUlRQIG9yIHRoZSBsaWtlLiAmbmJz cDtCdXQgdGhlc2UNCmRvbid0IGV4aXN0IHRvZGF5LCBhbmQgaW4gdGhlIG1vc3QgdXN1YWwgY2Fz ZSB0aGUgTVBMUyBuZXR3b3JrIHdpbGwgY2FycnkNCmFuIElQIGxheWVyIG5ldHdvcmsgYmVjYXVz ZSB0aGlzIGNhbiBzdXBwb3J0IHRoZSBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj5XZSBjYW4gZ28gdGhyb3VnaCBleGFj dGx5DQp0aGUgc2FtZSBhbmFseXNpcyB3aXRoIGFueSBuZXR3b3JrIHRoYXQgaXMgbm90IHRvcC1v Zi1zdGFjaywgZWcgRXRoZXJuZXQuDQombmJzcDtBbmQgd2hlbiB5b3UgZG8gdGhpcyB3aGF0IHlv dSByZWFsaXNlIGlzIHRoYXQgYWx0aG91Z2ggd2UgY2FuIGNyZWF0ZQ0KcGVlciBpbnRlcndvcmtp bmcgb2YgTVBMUyAob3Igd2hhdGV2ZXIpIHRoaXMgaGFzIG5vdCByZWFsbHkgaGVscGVkIHNpbmNl DQp3ZSBtaWdodCBhcyB3ZWxsIGhhdmUganVzdCB0ZXJtaW5hdGVkIHRoZSBNUExTIG5ldHdvcmsg YW5kIHBhc3NlZCB0aGUgSVANCmxheWVyIGFjcm9zcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21p YyBTYW5zIE1TIj5Ob3cgdGhlIGFib3ZlIGJlY29tZXMNCmV2ZW4gbW9yZSBzdHJpa2luZyBpbiBp dHMgaW1wb3J0YW5jZSBpZiB5b3UgY29uc2lkZXIgcGVlciBpbnRlcndvcmtpbmcNCm9mIDIgZGlm ZmVyZW50IG5vbiB0b3Atb2Ytc3RhY2sgbmV0d29ya3MuLi4ubGV0cyBwaWNrIE1QTFMgYW5kIEV0 aGVybmV0DQpiZWNhdXNlIHRoYXQgaXMgd2hhdCBpcyBvZnRlbiBtZW50aW9uZWQuICZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPldoYXQgd2UgaGF2ZSB0byBkbw0Kbm93 IGF0IHRoZSBFLU5OSXMgYmV0d2VlbiBFdGhlcm5ldCBhbmQgTVBMUyBpcyBnbyB0aHJvdWdoIGVh Y2ggRFAgYW5kIENQDQpjb21wb25lbnQgYW5kIGRvIGEgJ3Byb3RvY29sIGNvbnZlcnNpb24nIGV4 ZXJjaXNlIHdoZXJlIHJlcXVpcmVkLi4uLi4uYW5kDQp0aGUgZmlyc3QgcHJvYmxlbSB5b3Ugd2ls bCBlbmNvdW50ZXIgaXMgdGhhdCB0aGVyZSB3aWxsIGJlIGxvdHMgb2YgZnVuY3Rpb25hbA0KbWlz bWF0Y2guICZuYnNwO01vcmVvdmVyIGlmIG9uZSBvciBib3RoIG9mIHRoZSBuZXR3b3JrcyBjYW4g c3VwcG9ydCBtdWx0aXBsZQ0KQ1AgdHlwZXMgbGlrZSBNUExTIGNhbiwgZWcgUlNWUC1URSBzaWdu YWxsaW5nLCBMRFAgc2lnbmFsbGluZywgQkdQNCAnc2lnbmFsbGluZycsDQpPU1BGIHJvdXRpbmcs IElTLUlTIHJvdXRpbmcuLi4uLmFuZCBJIGNvdWxkIGxpc3Qgc2ltaWxhciBmb3IgRXRoZXJuZXQu Li4uLnlvdQ0KYXJlIGdvaW5nIHRvIGhhdmUgdG8gY29uc2lkZXIgZWFjaCBwYWlyaW5nIGNhc2Ug aW4gdHVybi4gJm5ic3A7QSBsb3Qgb2YNCndvcmsuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMg U2FucyBNUyI+QW5kIHdoZW4geW91IGhhdmUgZG9uZQ0KYWxsIHRoaXMgeW91IGFzayB0aGUgcXVl c3Rpb24gJ3doYXQgaXMgaXQgdGhhdCBjYXJyaWVzIHRoZSByZWFsIGV4dGVybmFsDQptZXNzYWdl L2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyBpbiB0aGUgRFAgaGVyZT8nLi4uLi4uLmFuZCBub3cg eW91IGZpbmQNCm5vIG5hdGl2ZSBzdXBwb3J0IGZvciB0aGVzZSBpbiBNUExTIG9yIEV0aGVybmV0 LCBidXQgd2hhdCB3ZSBkbyBmaW5kIGlzDQp0aGF0IGJvdGggb2YgdGhlbSBhcmUgY2Fycnlpbmcg SVAgYmVjYXVzZSB0aGlzIGRvZXMgc3VwcG9ydCB0aGUgZXh0ZXJuYWwNCmFwcGxpY2F0aW9ucy4g Jm5ic3A7Tm93IGF0IHRoaXMgcG9pbnQgd2UgaGF2ZSBkaXNjb3ZlcmVkIHdoYXQgaXMgdGhlIGNv bW1vbg0KdGhpbmcgYmV0d2VlbiBNUExTIGFuZCBFdGhlcm5ldC4uLi5pdCBpcyB0aGUgdG9wLW9m LXN0YWNrIElQIGxheWVyIG5ldHdvcmsuDQombmJzcDtBbmQgc28gd2UgdWx0aW1hdGVseSByZWFs aXNlIHdlIGNvdWxkIGhhdmUgc2F2ZSBvdXJzZWx2ZXMgYSBsb2FkDQpvZiB1bm5lY2Vzc2FyeSB3 b3JrIGJ5IHNpbXBseSB0ZXJtaW5hdGluZyB0aGUgTVBMUyBhbmQgRXRoZXJuZXQgbGF5ZXIgbmV0 d29yaw0KYXQgdGhlIGludGVyd29ya2luZyBwb2ludCBhbmQganVzdCBwYXNzZWQgdGhlIElQIGxh eWVyIG5ldHdvcmsgYWNyb3NzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPlNv cnJ5IEkndmUgaGFkIHRvIGdvDQp0aHJvdWdoIGFsbCB0aGlzIHlldCBhZ2FpbiAoZXNwIGZvciBh bGwgdGhlIGZvbGtzIHRoYXQgaGF2ZSBhbHJlYWR5IHVuZGVyc3Rvb2QNCnRoZSBwb2ludCkgYnV0 IEkgZG8gaG9wZSBpdHMgY2xlYXIgbm93IGFuZCB3ZSBjYW4gcHV0IHRoaXMgaXNzdWUgdG8gYmVk LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPnJlZ2FyZHMsIE5laWw8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjxiPkZyb206PC9iPiBzdS5odWlAenRlLmNvbS5jbiBbbWFpbHRvOnN1Lmh1aUB6 dGUuY29tLmNuXQ0KPGI+PGJyPg0KU2VudDo8L2I+IDI5IEFwcmlsIDIwMDkgMDM6MjI8Yj48YnI+ DQpUbzo8L2I+IEhhcnJpc29uLE4sTmVpbCxDWE0gUjxiPjxicj4NCkNjOjwvYj4gYWRyaWFuQG9s ZGRvZy5jby51azsgTml2ZW4tamVua2lucyxCLEJlbixETUYgUjsgaGhlbHZvb3J0QGNoZWxsby5u bDsNCm1wbHMtdHBAaWV0Zi5vcmc7IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzxiPjxicj4NClN1 YmplY3Q6PC9iPiC08Li0OiBSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwNCnRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cyk8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KSGkgTmVpbCw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCqGuaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhIHNpbXBs ZSB0ZWNobmljYWwgYW5hbHlzaXMgdGhhdCBhbnkgbm9uIHRvcC1vZi1zdGFjaw0KbmV0d29yayBo YXMgbm8gbmVlZCBmb3IgRS1OTkkgcGVlci1wYXJ0aXRpb24gd29ya2luZyBiZXR3ZWVuIGRpZmZl cmVudA0Kb3BlcmF0aW5nIHBhcnRpZXMuoa88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkkgY2Fubm90IGFncmVlIHRo aXMgc3RhdGVtZW50LiA8YnI+DQpGb3IgZXhhbXBsZSwgdGhlcmUgYXJlIHR3byBJUCBuZXR3b3Jr cyBiZWxvbmdpbmcgdG8gdHdvIG9wZXJhdG9ycywgYSBFMQ0KaXMgdHJhbnNwb3J0ZWQgZnJvbSBB IG5ldHdvcmsgdG8gQiBuZXR3b3JrIChlLmcuIEUxb3ZlclBXb3ZlcklQICksIElQIHBhY2tldChu b3QNCkUxKSBwYXNzIGFjcm9zcyBmb3JtIEEgdG8gQiBhdCBib3JkZXIgbm9kZSwgc28gdGhlcmUg aXMgYSBFLU5OSSBiZXR3ZWVuDQp0aGVzZSAmbmJzcDt0d28gSVAgbmV0d29yay4gSW4gdGhpcyBj YXNlLCBpcyBJUCBhIHRvcC1vZi1zdGFjayBuZXR3b3JrPzwvZm9udD48Zm9udCBzaXplPTM+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCk5vdyBsZXQgdXMgcmVw bGFjZSBJUCBuZXR3b3JrcyBieSBNUExTLVRQIG5ldHdvcmtzIChlLmcuIEUxb3ZlclBXb3Zlck1Q TC1UUCksDQpNUExTLVRQIG5ldHdvcmsgaXMgYXQgc2FtZSBwb3NpdGlvbiBpbiB0aGUgc3RhY2sg YXMgSVAgbmV0d29yayBpcywgd2h5DQpjYW4gSVAgbmV0d29yayBoYXZlIEUtTk5JIGJ1dCBNUExT LVRQIGNhbm5vdD88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClJlZ2FyZCw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClN1aHVpPC9mb250Pjxmb250 IHNpemU9Mz4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PiZsdDtuZWlsLjIuaGFycmlzb25AYnQuY29tJmd0OzwvYj4NCjxicj4NCreivP7IyzogJm5ic3A7 bXBscy10cC1ib3VuY2VzQGlldGYub3JnPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDQtMjggMTQ6NDM8L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NiU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lk dGg9OTMlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7aGhlbHZvb3J0QGNoZWxs by5ubCZndDssDQombHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDssICZsdDtiZW5qYW1pbi5uaXZl bi1qZW5raW5zQGJ0LmNvbSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5tcGxzLXRwQGlldGYub3JnPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+UmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZA0KYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQgcGF0aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZXF1aXJlbWVudHMp PC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0 dD48YnI+DQpIdXViIHdyb3RlIDI3IEFwcmlsIDIwMDkgMjI6Mjc8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSGkgQWRyaWFuLDxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3Ugd3JvdGU6PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZndDsgSXNuJ3QgdGhlIHNvbHV0aW9uIGhlcmUgdGhlIHNhbWUgYXMgdGhlIG9u ZSBJIHByb3Bvc2VkIGZvciAmcXVvdDtUQ00mcXVvdDs/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElu ZGVlZCwgYW5kIHRoYXQgd2UgZG8gbm90IGhhdmUgdG8gYXJvdW5kIGluIGNpcmNsZXMgYWJvdXQg VENNLjxicj4NCiZndDsgPGJyPg0KJmd0OyBIb3cgYWJvdXQ6PGJyPg0KJmd0OyB0aGUgcmVxdWly ZW1lbnQgaXMgdGhhdCBhIHNlcnZlciBsYXllciBzaGFsbCBpbmZvcm0gaXRzIGNsaWVudHM8YnI+ DQomZ3Q7IHRoYXQgaXQgaGFzIGRldGVjdGVkIGEgc2VydmljZSBpbnRlcnVwdGlvbiwgdGhpcyB0 byBlbnN1cmUgdGhhdDxicj4NCiZndDsgdGhlIGNsaWVudHMgY2FuIGluaGliaXQgKHVubmVjZXNz YXJ5KSBhbGFybXMuPGJyPg0KPGJyPg0KTkg9Jmd0OyBUaGlzIG9ubHkgYXBwbGllcyBpZiB0aGUg Y2xpZW50L3NlcnZlciBiaW5kaW5nIGlzIGZpeGVkLiAmbmJzcDtBbmQNCm9mPGJyPg0KY291cnNl IHdheSBiYWNrIGluIHRoZSA3MHMgd2hlbiBiaW5hcnkgYWxsIDFzIHBvcHBlZCBvdXQgb2YgdGhl IGZhaWxlZDxicj4NClRUTCBsb2dpYyBpbnRvIHRoZSBQREggdHJhbnNwb3J0IGhpZXJhcmNoeSB0 aGlzIHdhcyB0cnVlLiAmbmJzcDtBbHNvOiBubzxicj4NCmxhYmVscyBoZXJlIGFuZCBubyBjbGll bnQgdHJhZmZpYyB1bml0cyB0byBjcmVhdGUuICZuYnNwOyA8YnI+DQo8YnI+DQpXaGVyZSB0aGUg Y2xpZW50IGNhbiBkeW5hbWljYWxseSBiZSByZS1yb3V0ZWQgaW4gcmVzcG9uc2UgdG8gYSBzZXJ2 ZXI8YnI+DQpmYWlsdXJlIHRoZSBwcm9wb3NlZCB0ZXh0IGlzIG5vdCB2YWxpZC4gJm5ic3A7SXQg aXMgYWxzbyBub3QgbmVjZXNzYXJ5DQp0aGF0PGJyPg0KdGhlIHNlcnZlciBoYXMgdG8ga2VlcCB0 cmFjayBvZiB3aGVyZSBpdHMgY2xpZW50IHRyYWZmaWMgcm91dGluZ3MgaGF2ZTxicj4NCm1vdmVk IHRvLiAmbmJzcDtGb3IgZXhhbXBsZSwgaWYgSSBjcmVhdGUgdGhlIHRvcG9sb2d5IG9mIGFuIElQ IGxheWVyIG5ldHdvcms8YnI+DQp3aXRoIGxpbmtzIHByb3ZpZGVkIGJ5IFNESCwgRXRoZXJuZXQs IEFUTSwgT1ROLCBldGMgc2VydmVycywgYW5kIGVhY2ggb2Y8YnI+DQp0aGVzZSBzZXJ2ZXIgbGlu a3MgaXMgcHJvdmlkZWQgYnkgYSBkaWZmZXJlbnQgb3BlcmF0b3IsIHRoZW4gd2h5IHNob3VsZDxi cj4NCnRoZSBzZXJ2ZXJzIG5lZWQgaGF2ZSBrbm93bGVkZ2Ugb2Ygd2hlcmUgdGhlIElQIGZsb3dz IGhhdmUgbW92ZWQgdG8gaW48YnI+DQpyZXNwb25zZSB0byBhIHNlcnZlciBsYXllciBmYWlsdXJl IHdoZW4gdGhlIG5ldyByb3V0ZXMgaGF2ZSBiZWVuPGJyPg0KY2FsY3VsYXRlZCBieSB0aGUgSUdQ IGluIHRoZSBJUCBsYXllciBuZXR3b3JrPyAmbmJzcDtJIGNhbiBhcHBseSB0aGUgc2FtZTxicj4N CmxvZ2ljIHRvIGFuIFNWQy1iYXNlZCBjby1wcy9jby1jcyBtb2RlIGNsaWVudC4uLi5pbmRlZWQg dGhlIGNvLWNzIG1vZGU8YnI+DQpQU1ROIGlzIGxpa2UgdGhpcy48YnI+DQo8YnI+DQpUaGVzZSBv YnNlcnZhdGlvbnMgbWFrZSBpdCBxdWl0ZSBjbGVhciB0byBtZSBhdCBsZWFzdCB0aGF0IGp1c3Qg Y29weWluZzxicj4NCnRoZSBBSVMgYmVoYXZpb3VyIG9mIHRoZSBvbGQgdHJhbnNwb3J0IGhpZXJh cmNoaWVzIHRoYXQgaGFkIGZpeGVkPGJyPg0KY2xpZW50L3NlcnZlciByZWxhdGlvbnNoaXBzIGlz IG5vdCBhIHNlbnNpYmxlIHRoaW5nIHRvIGRvLjxicj4NCjxicj4NCklNTyB0aGUgb25seSBlc3Nl bnRpYWwgRFAgT0FNIHJlcXVpcmVtZW50IGlzIHRoYXQgZWFjaCBsYXllciBuZXR3b3JrPGJyPg0K c2hvdWxkIGJlIHNlbGYtc3VmZmljaWVudCB3cnQgT0FNIGFuZCBub3QgcmVseSBvbiBhbnkgc2Vy dmVyIGxheWVyPGJyPg0KcHJpbWl0aXZlcyBiZWluZyBwYXNzZWQgdXB3YXJkcy48YnI+DQo8YnI+ DQpNb3Jlb3ZlciwgaXQgc2hvdWxkIGFsc28gYmUgbm90ZWQgdGhhdCAoaSkgdGhlIGRlZmVjdHMg dGhhdCBjYW4gb2NjdXIgaW48YnI+DQplYWNoIG9mIHRoZSAzIG5ldHdvcmsgbW9kZXMgYXJlIG5v dCB0aGUgc2FtZSBhbmQgKGlpKSB0aGVpciBPQU08YnI+DQpyZXF1aXJlbWVudHMgYXJlIG5vdCBp ZGVudGljYWxseSB0aGUgc2FtZS4gU28gdGhlIE9BTSB0aGF0IGFwcGxpZXMgdG88YnI+DQp0aGUg Y2wtcHMgbW9kZSAoZWcgSVApIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgT0FNIHRoYXQgYXBwbGll cyB0byB0aGU8YnI+DQpjby1wcyBtb2RlIChlZyBNUExTLVRQKSBhbmQgbmVpdGhlciBvZiB0aGVz ZSBpcyBpZGVudGljYWxseSB0aGUgc2FtZSBhczxicj4NCnRoZSBPQU0gdGhhdCBhcHBsaWVzIHRv IHRoZSBjby1jcyBtb2RlIChlZyBTREgpLjxicj4NCjxicj4NCk5vdGUgLSBUaGUgb25seSBwb2lu dCBiZWluZyBjb25zaWRlcmVkIGhlcmUgaXMgdGhlIHJlYWwgY2xpZW50IGFuZDxicj4NCnNlcnZl ciB0cmFmZmljIHJlbGF0aW9uc2hpcC4gJm5ic3A7VGhlIGNyZWF0aW9uIG9mIGEgaGllcmFyY2h5 IG9mIFRDTTxicj4NCnN1YmxheWVycyBpcyBhIHNlcGFyYXRlIHRvcGljLiAmbmJzcDtGdXJ0aGVy LCBpdCBpcyBxdWl0ZSBjbGVhciBmcm9tIGENCnNpbXBsZTxicj4NCnRlY2huaWNhbCBhbmFseXNp cyB0aGF0IGFueSBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5vIG5lZWQgZm9yPGJyPg0K RS1OTkkgcGVlci1wYXJ0aXRpb24gd29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBvcGVyYXRpbmcg cGFydGllcy4gJm5ic3A7U288YnI+DQp0aGlzIGlzIGFsc28gYSBzZXBhcmF0ZSBpc3N1ZS4gJm5i c3A7SG93ZXZlciwgSSBwcm9wb3NlIHRoYXQgdGhpcyBsYXR0ZXI8YnI+DQpwb2ludCBiZSBjYXB0 dXJlZCBpbiB0aGUgTVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQgZHVlIHRvIGl0czxicj4NCnN0 YW5kLWFsb25lIGFuZCBnZW5lcmljIGltcG9ydGFuY2UsIGllIHRoaXMgYXBwbGllcyB0byBtb3Jl IHRoYW4ganVzdCBEUDxicj4NCk9BTS4gJm5ic3A7QmVuIGNhbiB5b3UgcGxlYXNlIGNvbnNpZGVy IHRoaXMgcG9pbnQgYXMvd2hlbiB0aGUgTVBMUy1UUDxicj4NCnJlcXVpcmVtZW50cyBkcmFmdCBp cyB1cGRhdGVkLjxicj4NCjxicj4NCnJlZ2FyZHMsIE5laWw8YnI+DQo8YnI+DQomZ3Q7IENoZWVy cywgSHV1Yi48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCm1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KbXBscy10cEBpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDwvdHQ+PC9mb250 Pjxmb250IHNpemU9Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQNCnNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBu b3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YNCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwNCnNlbmRlci48YnI+ DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS48YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt YWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZu YnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNw O21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Bl cm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNw O29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRo aXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0 ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQm bmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8m bmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2lu Jm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5h dG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5i c3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNw O3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZu YnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRp LVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0034744D482575A7_=-- From tnadeau@lucidvision.com Wed Apr 29 03:00:01 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC263A6B55 for ; Wed, 29 Apr 2009 03:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpm3p4bvQOfK for ; Wed, 29 Apr 2009 03:00:00 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id BF4E63A702A for ; Wed, 29 Apr 2009 02:59:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id EFE683D5519E; Wed, 29 Apr 2009 06:01:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU+hXnWHpqKr; Wed, 29 Apr 2009 06:01:20 -0400 (EDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.myfairpoint.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id E5A743D5518D; Wed, 29 Apr 2009 06:01:19 -0400 (EDT) Message-Id: <43390FDA-A83A-460A-9A88-F5FDBA3918D2@lucidvision.com> From: Thomas Nadeau To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A41DC9@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 06:01:08 -0400 References: <077E41CFFD002C4CAB7DFA4386A53264A415D6@DEMUEXC014.nsn-intra.net> <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> <077E41CFFD002C4CAB7DFA4386A53264A41DC9@DEMUEXC014.nsn-intra.net> X-Mailer: Apple Mail (2.930.3) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 10:00:01 -0000 It would be best is these "Tier-1 SPs" would comment directly on the list or contribute to the requirements draft. --Tom On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: > Neil, > Thanks for the very good explanation. It really helps me to understand > better the context of the long discussion. > Personally I got many feedbacks from Tier-1 SPs that they would like > to > have the capability to suppress alarms in a packet transport > environment. Their requirement was that if a server layer (e.g. MPLS- > TP > link) fails, there is a way to notify the client layer (e.g. LSPs) in > order to be able to suppress alarms at the client layer that may > result > from the fault at the server layer (e.g. MPLS-TP link). > Isn't it a logical and reasonable requirement in a transport profile? > Also I saw general requirements for inter-layer fault correlation. So > can I understand from your mail that you are not happy from such a > requirement as well? > Best regards, > Nurit > > > > -----Original Message----- > From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, April 28, 2009 11:07 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > Nurit, > > I believe the reason we need this discussion is that there is an > unstated assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in > response to > link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as > the > client) then there is no fixed client/server relationship. > > Refer to my post earlier today and consider what this means in the > case > of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs > mode > client layer network. The key point here is the *routing process* in > the client is independent of the server layer network....so there is > not > a fixed client/server relationship. Further, there is also no > requirement for the server to keep track of where its client traffic > routings are at any epoch.....indeed why should it in the general case > where these are independent layer networks? > > So the only OAM requirement that is critical is that the OAM of the > client and server layer networks are independent. It is thus not > sensible to make client layer alarm supression a 'requirement' > here...in > fact if this is in the OAM requirements then it is technically wrong > and > should be removed IMO. > > regards, Neil >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >> Nurit (NSN - IL/Hod HaSharon) >> Sent: 28 April 2009 08:46 >> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >> transportpathrequirements) >> >> If we agree that the requirement is included, so why do we >> keep with the >> endless discussions on this requirement? >> >> -----Original Message----- >> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >> Sent: Tuesday, April 28, 2009 10:44 AM >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); >> hhelvoort@chello.nl; Adrian >> Farrel >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional >> transport >> pathrequirements) >> >> I think that the requirements are defined in section 2.2.8 of >> draft-ietf-mpls-tp-oam-requirements-01 >> >> Italo >> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >>> Nurit (NSN - IL/Hod HaSharon) >>> Sent: Tuesday, April 28, 2009 6:56 AM >>> To: hhelvoort@chello.nl; Adrian Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >>> transport pathrequirements) >>> >>> Huub, >>> I think that the requirement is to provide a mechanism to suppress >>> alarms in the networks, to ensure that alarms that may be >> generated by >>> client layers as a result of a failure condition in the >>> server layer may >>> be suppressed. >>> Every thing else is a solution, etc. >>> I propose to phrase the requirement appropriately and conclude the >>> discussion on this in the context of the requirements (until we are >>> getting to the solution phase). >>> This requirement is included in the OAM requirement draft. >>> Best regards, >>> NUrit >>> >>> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>> Behalf Of ext Huub van Helvoort >>> Sent: Tuesday, April 28, 2009 12:27 AM >>> To: Adrian Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated >> bidirectional transport >>> path requirements) >>> >>> Hi Adrian, >>> >>> You wrote: >>> >>>> Isn't the solution here the same as the one I proposed for "TCM"? >>> >>> Indeed, and that we do not have to around in circles about TCM. >>> >>> How about: >>> the requirement is that a server layer shall inform its clients >>> that it has detected a service interuption, this to ensure that >>> the clients can inhibit (unnecessary) alarms. >>> >>> Cheers, Huub. >>> >>> -- >>> ================================================================ >>> http://www.van-helvoort.eu/ >>> ================================================================ >>> Always remember that you are unique...just like everyone else... >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From neil.2.harrison@bt.com Wed Apr 29 03:21:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A00C28C139; Wed, 29 Apr 2009 03:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO5cbJvot+AU; Wed, 29 Apr 2009 03:21:08 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id C95493A6859; Wed, 29 Apr 2009 03:20:38 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 11:21:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C8B4.5472C714" Date: Wed, 29 Apr 2009 11:21:52 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E2328@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnIrh1bzZKiyEU7SWCfmqvn3eMKOgAACMow From: To: X-OriginalArrivalTime: 29 Apr 2009 10:21:59.0925 (UTC) FILETIME=[54CE6250:01C9C8B4] Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 10:21:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C8B4.5472C714 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhhbmtzIFN1aHVpLi4uLi4uc29ycnkgSSBtaXNzZWQgeW91ciBzcGVjaWZpYyBxdWVzdGlvbi4u Li5oYXZlIGEgbG9vayBpbi1saW5lIGFuZCBzZWUgaWYgdGhpcyBoZWxwcy4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJRnJvbTogc3UuaHVpQHp0ZS5jb20uY24gW21h aWx0bzpzdS5odWlAenRlLmNvbS5jbl0gDQoJU2VudDogMjkgQXByaWwgMjAwOSAxMDozMQ0KCVRv OiBIYXJyaXNvbixOLE5laWwsQ1hNIFINCglDYzogYWRyaWFuQG9sZGRvZy5jby51azsgTml2ZW4t amVua2lucyxCLEJlbixETUYgUjsgaGhlbHZvb3J0QGNoZWxsby5ubDsgbXBscy10cEBpZXRmLm9y ZzsgbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoJU3ViamVjdDog562U5aSNOiBSRTogUmU6IFtt cGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBw YXRoIHJlcXVpcmVtZW50cykNCgkNCgkNCg0KCUhpIE5laWzvvIwgDQoJDQoJVGhhbmtzIGZvciB5 b3VyIHJhcGlkIHJlcGx5LiANCglJIGFtIGNvbmZ1c2VkIGJ5IHlvdXIgY29tbWVudHMsIGFyZSB5 b3Ugc3VnZ2VzdGluZyBFdmVyeXRoaW5nb3ZlcklQb3Zlck1QTFMtVFA/IEFGQUlLLCBNUExTLVRQ IGNhbiBjYXJyeSBtYW55IGtpbmRzIG9mIGNsaWVudHMsIG5vdCBqdXN0IElQLkluIG15IGV4YW1w bGUsIEUxb3ZlclBXb3Zlck1QTFMtVFAsIHRoZXJlIGlzIG5vIElQIGxheWVyIGF0IGFsbC4gIA0K CSAgDQoJTkg9PiBGdWxseSB1bmRlcnN0YW5kLiAgSSB3YXMgZ2l2aW5nIElQIGFzIGFuICpleGFt cGxlKiBvZiBhIHRlY2hub2xvZ3kgdGhhdCBjYW4gc3VwcG9ydCByZWFsIGV4dGVybmFsIGFwcGxp Y2F0aW9ucyBiZWNhdXNlIGl0IGhhcyBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9uIGFk YXB0YXRpb24gZnVuY3Rpb25zIGluIHRoZSBmb3JtIG9mIFVEUC9UQ1AvUlRQLiAgIEluIHRoZSBj YXNlIG9mIEUxIHRoYXQgeW91IG5vdGUgKGFzIEUxb3ZlclBXb3Zlck1QTFMtVFApIHlvdSBoYXZl IHRvIGFzayB5b3Vyc2VsZiB3aGF0IHNwZWNpZmljICpleHRlcm5hbCogYXBwbGljYXRpb25zIGRv ZXMgdGhlIEUxIHN1cHBvcnQgaGVyZT8uLi4uLmFsd2F5cyByZW1lbWJlcmluZyB0aGF0ICphbnkq IG5ldHdvcmtpbmcgdGVjaG5vbG9neSBNVVNUIHVsdGltYXRlbHkgc3VwcG9ydCBzb21lIGZvcm0g b2YgKmV4dGVybmFsbHkgc291cmNlZCogaW5mb3JtYXRpb24gc291cmNlIGVsc2UgaXQgaXMgbm90 IHNlcnZpbmcgYW55IHB1cnBvc2UuICBTbyBqdXN0IHN1cHBvcnRpbmcgRTEgb24gaXRzIG93biBk b2VzIG5vdCBwcm92aWRlIHRoaXMuLi4uZm9yIGV4YW1wbGUgYXNrIHlvdXJzZWxmIGhvdyB2b2lj ZSBvciBhbnkgdHlwZSBvZiBtZXNzYWdlL2ZpbGUgZGF0YSBnZXRzIGNhcnJpZWQgYnkgdGhlIEUx Lg0KCSANCglBbmQgeW91IGRvbuKAmXQgYW5zd2VyIG15IHF1ZXN0aW9uOiBJUCBpcyBhIHRvcC1v Zi1zdGFjayBuZXR3b3JrIGluIHRoZSBjYXNlIG9mIEUxb3ZlclBXb3ZlcklQLCB3aHkgZG9lc24n dCBNUExTLVRQIGJlIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgaW4gdGhlIGNhc2Ugb2YgRTFvdmVy UFdvdmVyTVBMUy1UUD8gVGhleSBhcmUgYXQgdGhlIHNhbWUgcG9zaXRpb24gaW4gdGhlIHN0YWNr LCBhbmQgSSB0aGluayBFMSBpcyDigJhyZWFsIGV4dGVybmFsIHN0cmVhbSBhcHBsaWNhdGlvbnPi gJkgDQoJIA0KCU5IPT4gVGhlIHBvaW50IGhlcmUgaXMgdGhhdCAqYW55KiBuZXR3b3JrIG1vZGUv dGVjaG5vbG9neSAoYmUgaXQgY2wtcHMsIGNvLXBzIG9yIGNvLWNzKSBjYW4gYWN0IGFzIHRoZSBz ZXJ2ZXIgZm9yIGFueSBvdGhlciBtb2RlL3RlY2hub2xvZ3kuICBIb3dldmVyLCBub3QgYWxsIHRl Y2hub2xvZ2llcyBjYW4gc3VwcG9ydCBleHRlcm5hbCBhcHBsaWNhdGlvbnMuLi4uLnRvIHN1cHBv cnQgdGhlc2UgdGhlIHRlY2hub2xvZ3kgbXVzdCBoYXZlIGFwcGxpY2F0aW9uIGFkYXB0YXRpb24g ZnVuY3Rpb25zIGZvciB0aGUgbWVzc2FnZS9maWxlL3N0cmVhbSBpbmZvcm1hdGlvbiBzb3VyY2Vz IHRoYXQgYXJlIGdlbmVyYXRlZCBpbiBleHRlcm5hbCBDUEUsIGVnIHBob25lLCBQQywgZXRjLg0K CSANCglNb3N0IHRlY2hub2xvZ2llcyBkbyBub3QgaGF2ZSB0aGVzZSBleHRlcm5hbCBhcHBsaWNh dGlvbiBhZGFwdGF0aW9uIGZ1bmN0aW9ucyBhbmQgc28gdGhlIG9ubHkgam9iIHRoZXkgY2FuIGRv IGlzIGNyZWF0ZSB0aGUgdG9wb2xvZ3kgb2Ygb3RoZXIgbGF5ZXIgbmV0d29ya3MuDQoJIA0KCVNv IHllcyB3ZSBjYW4gdXNlIElQIChjbC1wcykgdG8gY2FycnkgU0RIIFZDNCAoY28tY3MpIGlmIHdl IHdhbnQuLi4uLi4ucHJvYmFibHkgbm90IGEgZ29vZCBpZGVhIGJ1dCBpdCBpcyBmb3Igc3VyZSBw b3NzaWJsZS4gIEhvd2V2ZXIsIGFuIFNESCBWQzQgbmV0d29yayBjYW5ub3QgKmRpcmVjdGx5KiBz dXBwb3J0IGVpdGhlciB2b2ljZSBvciBkYXRhIGJ1dCBhbiBJUCBuZXR3b3JrIGNhbi4uLi4uYmVj YXVzZSBJUCBoYXMgVURQL1RDUC9SVFAgYXBwbGljYXRpb25zIGFkYXB0YXRpb25zIGFuZCBTREgg VkM0IGRvZXMgbm90IGhhdmUgdGhlc2UuICBIYXZpbmcgc2FpZCB0aGF0LCB0aGVyZSBpcyBpbiBw cmluY2lwbGUgbm8gcmVhc29uIHdoeSBhbnkgbW9kZS90ZWNobm9sb2d5IChldmVuIFNESCBWQzQp IGNhbm5vdCBzdXBwb3J0IGV4dGVybmFsIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25z Li4uLi4uaXRzIGp1c3QgdGhhdCBmb3IgbW9zdCB0ZWNobm9sb2dpZXMgdGhlc2UgaGF2ZSBuZXZl ciBiZWVuIHNwZWNpZmllZCBiZWNhdXNlIHRoZXkgd2VyZSBvbmx5IGV2ZXIgaW50ZW5kZWQgdG8g cHJvdmlkZSBhICduZXR3b3JrIGJ1aWxkZXInIHRyYW5zcG9ydCByb2xlLg0KCSANCglBc2lkZT0+ IElmIGEgdGVjaG5vbG9neSBYIGNhbiBzdXBwb3J0IG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGlj YXRpb25zIGRpcmVjdGx5IHRoZW4gaGVyZSB3ZSB3b3VsZCBtb3N0IGRlZmluaXRlbHkgaGF2ZSB0 byBjb25zaWRlciBwZWVyLWludGVyd29ya2luZyB0ZWNobm9sb2d5IFggd2l0aCBib3RoIElQIChJ bnRlcm5ldCkgYW5kIFBTVE4gKHZvaWNlIGNhc2Ugb25seSkuICBJbiBhbGwgb3RoZXIgY2FzZXMg KGllIHdoZXJlIHRlY2hub2xvZ3kgWCBpcyBub3QgdG9wLW9mLXN0YWNrLCBpZSBkb2VzIG5vdCBo YXZlIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMp IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHBlZXItaW50ZXJ3b3JraW5nIGl0IHdpdGggYW55IG90aGVy IHRlY2hub2xvZ3ksIGluY2x1ZGluZyBJUCAoSW50ZXJuZXQpIGFuZCBQU1ROLg0KCSANCgkgDQoJ WW91ciBmaW5hbCBwb2ludCAoIkkgdGhpbmsgRTEgaXMg4oCYcmVhbCBleHRlcm5hbCBzdHJlYW0g YXBwbGljYXRpb25z4oCZIiApIGlzIG5vdCBzdHJpY3RseSBjb3JyZWN0IGJ1dCBJIGNhbiBmdWxs eSB1bmRlcnN0YW5kIHdoeSB5b3Ugc2F5IHRoaXMuICBFMSBiZWxvbmdzIHRvIHRoZSBjby1jcyBt b2RlLiAgV2hlbiB5b3UgYW5hbHlzZSB0aGlzIChhcyBpcyBkb25lIGluIEcuODAwLCB3aGljaCBl eHBsYWlucyB3aHkgdGhlIDMgbmV0d29yayBtb2RlcyBhcmlzZSBmcm9tIGluZm9ybWF0aW9uL3N5 c3RlbXMgdGhlb3J5IGNvbnNpZGVyYXRpb25zKSB5b3UgZmluZCB0aGF0IGluIHRoZSB0aW1lIGRp bWVuc2lvbiB0aGUgY28tY3MgbW9kZSBwYXJ0aXRpb25zIHJlc291cmNlICh0aW1lKSB1cCBpbnRv IHJlZ3VsYXIgdGltZSBzbGljZXMuLi4uc28gdGhpcyBtZWFucyBib3RoIHRoZSBzdGFydCBlcG9j aCAoYW4gaW1wbGljaXQgbGFiZWwpIGFuZCAobW9zdCBjcnVjaWFsbHkpIGl0cyBkdXJhdGlvbiBh cmUgZml4ZWQuICANCgkgDQoJV2l0aG91dCBnb2luZyBpbnRvIG1ham9yIGRldGFpbCBoZXJlIChJ IGhhdmUgcGFwZXIgb24gdGhpcyBJIGNhbiBzZW5kIHlvdSBpZiB5b3Ugd2FudC4uLmp1c3QgYXNr KSB3aGF0IHRoaXMgbWVhbnMgaXMgdGhhdCB0aGUgY28tY3MgbW9kZSBpcyB0aGUgdWx0aW1hdGUg J3Ntb290aGVyL3NoYXBlcicgZm9yIGNsaWVudCB0cmFmZmljLi4uLi4uc28gYXMgeW91IHJpZ2h0 bHkgb2JzZXJ2ZSB0aGlzIGxvb2tzIGxpa2UgYSBzdHJlYW0gY2FzZS4gIEl0J3Mgbm90IGEgc3Bl Y2lmaWMgZXh0ZXJuYWwgYXBwbGljYXRpb24gaG93ZXZlciBsaWtlIGh1bWFuIHZvaWNlIG9yIHZp ZGVvICh0aGVzZSBtdXN0IGdlbmVyYXRlIHJlYWwgKmluZm9ybWF0aW9uKiB0aGF0IGNvbW11bmlj YXRpbmcgcGFydGllcyB1bmRlcnN0YW5kKSBidXQgaXQgZm9yIHN1cmUgaGFzIHRoZSBDQlIgYmVo YXZpb3VyIG9mIGEgc3RyZWFtLiANCgkgDQoJQlRXIHRoZSByZWFzb24gdGhlIGNvLWNzIG1vZGUg aGFzIGJlZW4gZW5kdXJpbmdseSBzdWNjZXNzZnVsIGFzIGEgdHJhbnNwb3J0IG5ldHdvcmsgaXMg YmVjYXVzZSBpdCBwcm92aWRlcyAqdHJhbnNwYXJlbmN5KiB0byBhbGwgY2xpZW50cyAod2hpY2gg aXMgZXhhY3RseSB0aGUgc2ltaWxhciBiZWhhdmlvdXIgb2YgYSBzdHJlYW0gYXMgeW91IG5vdGUp LCBpZQ0KCS0gICAgYWxsIGNsaWVudCBiaXRzIHRyZWF0ZWQgZXF1YWxseSAoYSByZWFsbHkga2V5 IHBvaW50IHRoaXMsIGFzIHRoaXMgbWVhbnMgaXQgcHJvdmlkZXMgZXF1YWwgJ2ltcG9ydGFuY2Un IHRyZWF0bWVudCBvZiB0aGUgdWx0aW1hdGUgaGlnaGVyIGxldmVsIChhbmQgdW5zZWVuL3Vua25v d24gYnkgdGhlIGNvLWNzIHRyYW5zcG9ydCBuZXR3b3JrKSBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFw cGxpY2F0aW9ucykNCgktICAgIGNsaWVudCBiaXQgb3JkZXJpbmcgaXMgcHJlc2VydmVkDQoJLSAg ICBkb2VzIG5vdCB0cnkgYW4gaW5mZXIgbWVhbmluZyBvZiBjbGllbnQgYml0cyBub3IgY2hhbmdl IHRoZW0NCgktICAgIGVuc3VyZXMgdGhlIHRyYWZmaWMgYmVoYXZpb3VyIG9mIGNsaWVudCBYIGNh bm5vdCBpbXBhY3QgdGhlIHBlcmZvcm1hbmNlIGV4cGVyaWVuY2VkIGJ5IHBhcnR5IFkuDQoJIA0K CSANCglyZWdhcmRzLCBOZWlsIA0KCQ0KCVJlZ2FyZHMsIA0KCVN1aHVpLiANCgkNCgkNCgkNCjxu ZWlsLjIuaGFycmlzb25AYnQuY29tPiANCg0KMjAwOS0wNC0yOSAxNDo0MCANCg0K5pS25Lu25Lq6 DQo8c3UuaHVpQHp0ZS5jb20uY24+IA0K5oqE6YCBDQo8YWRyaWFuQG9sZGRvZy5jby51az4sIDxi ZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbT4sIDxoaGVsdm9vcnRAY2hlbGxvLm5sPiwgPG1w bHMtdHBAaWV0Zi5vcmc+LCA8bXBscy10cC1ib3VuY2VzQGlldGYub3JnPiANCuS4u+mimA0KUkU6 IFJlOiBbbXBscy10cF0gQUlTL0ZESSAod2FzIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCAgICAgICAgcmVxdWlyZW1lbnRzKQ0KDQoJDQoNCg0KDQoNCglUaGFua3MgU2h1 aHVpLCANCgkgIA0KCURvIG5vdCBjb25mdXNlIHBoeXNpY2FsIGludGVyY29ubmVjdCB3aXRoIEUt Tk5JLi4uLi5JJ2xsIGNvbWUgYmFjayBvbiB0aGlzIHNob3J0bHkgd2hlbiBkaXNjdXNzaW5nIHRo ZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4gDQoJICANCglUaGUgZmlyc3QgdGhpbmcg dG8gdW5kZXJzdGFuZCBpcyB0aGF0ICphbGwqIG5ldHdvcmtzIGFyZSB0aGVyZSB0byB1bHRpbWF0 ZWx5IHN1cHBvcnQgb25lIHB1cnBvc2UuLi4uLmFuZCB0aGF0IGlzIHRvIGFsbG93IGNvbW11bmlj YXRpb25zIGJldHdlZW4gcGFydGllcyB0aGF0IGFyZSAqZXh0ZXJuYWwqIHRvIHRoZSBuZXR3b3Jr cy4gIFNvIGV2ZXJ5dGhpbmcgd2UgZG8gaW4gbmV0d29ya2luZyBpcyB0aGVyZSB0byB1bHRpbWF0 ZWx5IHN1cHBvcnQgdGhpcyBvYmplY3RpdmUuICBXaGF0IHRoaXMgbWVhbnMgaXMgdGhhdCB0aGUg RFAgb2Ygc29tZSBuZXR3b3JrICh3aGF0IEkgY2FsbCB0aGUgdG9wLW9mLXN0YWNrIG5ldHdvcmsp IE1VU1QgYmUgcHJvdmlkaW5nIGFkYXB0YXRpb24gZnVuY3Rpb25zIGZvciB0aGVzZSBleHRlcm5h bCBhcHBsaWNhdGlvbnMuLi4uLi4uYW5kIHRoZXNlIGNhbiBnZW5lcmljYWxseSBiZSBjbGFzc2lm aWVkIGFzIG1lc3NhZ2VzLCBmaWxlcyBhbmQgc3RyZWFtcy4gDQoJICANCglXZSBjYW4gc2VlIHRo YXQgSVAgaXMgYSB0b3Atb2Ytc3RhY2sgbmV0d29yayBhcyBpdCBoYXMgVURQL1RDUC9SVFAgKGZv ciBleGFtcGxlKSBhZGFwdGF0aW9ucy4gIEFUTSB3YXMgYWxzbyBvbmNlICh+OTBzKSBpbnRlbmRl ZCB0byBiZSBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGFuZCBpdCBoYWQgaXRzIG93biBhcHBsaWNh dGlvbiBhZGFwdGF0aW9ucyBpbiB0aGUgZm9ybSBvZiBBQUxzLiAgQXQgb25lIHN0YWdlIHRoZXJl IHdlcmUgNSBvZiB0aGVzZSwgYnV0IGluIHByYWN0aWNlIG9ubHkgYSBjb3VwbGUgd2VyZSByZWFs bHkgc3VjY2Vzc2Z1bCBiZWNhdXNlIG9mIHRoZSBnZW5lcmljIG5hdHVyZSBvZiBtZXNzYWdlL2Zp bGUvc3RyZWFtIGNsYXNzaWZpY2F0aW9uLiAgVGhlIFBTVE4gaXMgYWxzbyB0b3Atb2Ytc3RhY2ss IGFuZCBpdHMgYXBwbGljYXRpb24gYWRhcHRhdGlvbiB3YXMgbWFpbmx5IGZvciB2b2ljZSAoc3Ry ZWFtKSBzdXBwb3J0LiANCgkgIA0KCU1vc3Qgb3RoZXIgbmV0d29ya3MgZG8gbm90IGhhdmUgdGhl c2UgYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMuLi4uc28gdGhleSBkbyBub3QgZGly ZWN0bHkgc3VwcG9ydCBhcHBsaWNhdGlvbnMuICBXaGF0IHRoaXMgbWVhbnMgaW4gcHJhY3RpY2Ug aXMgdGhhdCB0aGVzZSBuZXR3b3JrcyAoYSBsaXN0IHdoaWNoIGluY2x1ZGVzIFBESCwgU0RILCBP VE4sIEV0aGVybmV0LCBNUExTKSBNVVNUIGNhcnJ5IGEgZnVydGhlciBsYXllciBuZXR3b3JrIGFi b3ZlIHRoZW0gdGhhdCBpcyB0b3Atb2Ytc3RhY2suLi4ubGlrZSBJUC4gIFRoZXJlIGlzIG5vIGNo b2ljZSBpbiB0aGUgbWF0dGVyIGhlcmUuICBTbyB3aGlsc3Qgd2UgbWlnaHQgc2F5IHRoYXQgYW4g TVBMUyBuZXR3b3JrIGlzIGNhcnJ5aW5nIGFuIEUxIFBXIHRoZSBFMSBlbnRpdHkgbXVzdCBpbiB0 dXJuIGJlIGNhcnJ5aW5nIHNvbWUgb3RoZXIgdG9wLW9mLXN0YWNrIG5ldHdvcmsgKGxpa2UgSVAg b3IgUFNUTiksIGVsc2UgaXQgaXMgc2VydmluZyBubyB1bHRpbWF0ZSBwdXJwb3NlLiANCgkgIA0K CU5vdyBpbiBvcmRlciB0byB0cmFuc21pdCBpbmZvcm1hdGlvbiBvdmVyIGdlb2dyYXBoaWMgZGlz dGFuY2Ugd2UgbXVzdCBtb2R1bGF0ZSBhbiBFTSB3YXZlIG9uIHNvbWUgbWV0YWxsaWMvb3B0aWNh bC9yYWRpbyBtZWRpYS4uLi50aGlzIGlzIHRoZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXll ci4gIFRoZXNlIGFyZSBoaWdoIGJpdCByYXRlIHRyYW5zcG9ydCBwaXBlcyB3aG9zZSBmdW5jdGlv biBpcyB0byBwcm92aWRlIHRyYW5zcGFyZW50ICh3aGljaCBJIGhhdmUgZGVmaW5lZCBwcmV2aW91 c2x5KSB0cmFuc3BvcnQgdG8gd2hhdGV2ZXIgY2xpZW50IGxheWVycyBuZXR3b3JrcyBzaXQgYWJv dmUgdGhlbS4uLi5hbmQgd2hlcmUsIGFzIEkgbm90ZWQgYWJvdmUsIHRoZXJlIE1VU1QgYmUgYSB0 b3Atb2Ytc3RhY2sgbmV0d29yayBwcmVzZW50IGFzIHRoZSB1bHRpbWF0ZSBsYXllciBuZXR3b3Jr IGNsaWVudCBlbHNlIHRoZXJlIGlzIG5vdCBleHRlcm5hbCBwYXJ0eSBjb21tdW5pY2F0aW9uIHBv c3NpYmxlLiANCgkgIA0KCVNvIHdoZW4gd2UgY29ubmVjdCB0b2dldGhlciAyIHRvcC1vZi1zdGFj ayBuZXR3b3JrcyB3ZSBkbyBzbyBhdCBhIHNlY3Rpb24gbGF5ZXIgd2hpY2ggaXMgaW52YXJpYWJs eSBjYXJyeWluZyBhIHZlcnkgbGFyZ2UgYWdncmVnYXRlIG9mIGFwcGxpY2F0aW9ucy4uLi4uYW5k IG9mIGNvdXJzZSB0aGVzZSBhcHBsaWNhdGlvbnMgY2FuIGJlIGEgdGltZSB2YXJ5aW5nIG1peCBv ZiBtZXNzYWdlL2ZpbGUvc3RyZWFtIGNhc2VzIHdpdGggYSBzZXQgb2YgdW5rbm93biAodG8gdGhl IHNlY3Rpb24gbGF5ZXIpIGltcG9ydGFuY2UncyAoZXJnbyB3aHkgdHJhbnNwYXJlbmN5IGlzIGFu IGVzc2VudGlhbCByZXF1aXJlbWVudCBpbiB0cmFuc3BvcnQgbmV0d29ya3MpLiANCgkgIA0KCVRo ZSByZWFsIEUtTk5JcyAod2hpY2ggY29uc2lkZXJzIGJvdGggRFAgYW5kIENQIGNvbXBvbmVudHMu Li4ud2UgbmV2ZXIgdXN1YWxseSBwZWVyIHRoZSBNUCwgYW5kIHdlIHJlc3RyaWN0IHRoZSBzY29w ZSBvZiB0aGUgQ1ApIGV4aXN0IGluIHRoZSB0b3Atb2Ytc3RhY2sgbGF5ZXIgbmV0d29yay4gIFRo ZSBzZWN0aW9uIGxheWVyIGludGVyY29ubmVjdCBpcyBhIGR1bWIgRFAgcGlwZS4uLml0IGp1c3Qg c2hpZnRzIGJpdHMgdHJhbnNwYXJlbnRseSBhbmQgbWFpbnRhaW5zIHRoZWlyIG9yZGVyaW5nLiAg VGhlcmUgaXMgbm8gY29uY2VwdCBvZiBDUCAob3IgTVApIHBlZXJpbmcgb24gdGhlc2UgYm90dG9t LW9mLXN0YWNrIHNlY3Rpb24gbGF5ZXIgaW50ZXJjb25uZWN0cy4gDQoJQXNpZGU9PiBJbiBzb21l IGNvdW50cmllcyB0aGVzZSBpbnRlcmNvbm5lY3RzIGhhdmUgdG8gYmUgY2FyZWZ1bGx5IHNwZWNp ZmllZCBpbiBvcmRlciB0byBkaXN0aW5ndWlzaCByZWd1bGF0ZWQgYW5kIHVucmVndWxhdGVkIHNl cnZpY2VzLi4uLi5zbyB0aGVyZSBhcmUgaW1wb3J0YW50IGxlZ2FsL2NvbW1lcmNpYWwgY29uc2lk ZXJhdGlvbnMgaGVyZSwgaXQgaXMgbm90IHNpbXBseSBhIHRlY2huaWNhbCBpc3N1ZS4gDQoJICAN CglXZSBjYW4gb2YgY291cnNlIGNyZWF0ZSBFLU5OSXMgaW4gbm9uIHRvcC1vZi1zdGFjayBsYXll ciBuZXR3b3JrcyAod2UgY2FuIGRvIG1hbnkgdGhpbmdzIHRoYXQgYXJlIG5vdCB1c2VmdWwpLiAg U28gbGV0cyBhc3N1bWUgd2UgZG8gdGhpcy4uLi4uYW5kIGxldHMgYXNzdW1lIHdlIGNob29zZSBN UExTIHNpbmNlIHlvdSBtZW50aW9uIHRoaXMgaW4gdGhlIG1haWwgYmVsb3cuIA0KCSAgDQoJTm93 IGhvdyBkbyBleHRlcm5hbCBwYXJ0aWVzIHdobyB3aXNoIHRvIGNvbW11bmljYXRlIGludGVyZmFj ZSB3aXRoIHRoaXMgTVBMUyBuZXR3b3JrPyAgQ2FuIHlvdSBzdXBwb3J0IGFsbCB0eXBlcyBvZiBt ZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyAqZGlyZWN0bHkqIGludG8gTVBMUz8gIElu IHByaW5jaXBsZSB5b3UgY291bGQgaWYgeW91IGFsbG93ZWQgTVBMUyB0byBoYXZlIGVuZCBzeXN0 ZW0gYXBwbGljYXRpb24gYWRhcHRhdGlvbnMgc3VjaCBhcyBVRFAvVENQL1JUUCBvciB0aGUgbGlr ZS4gIEJ1dCB0aGVzZSBkb24ndCBleGlzdCB0b2RheSwgYW5kIGluIHRoZSBtb3N0IHVzdWFsIGNh c2UgdGhlIE1QTFMgbmV0d29yayB3aWxsIGNhcnJ5IGFuIElQIGxheWVyIG5ldHdvcmsgYmVjYXVz ZSB0aGlzIGNhbiBzdXBwb3J0IHRoZSBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucy4g DQoJICANCglXZSBjYW4gZ28gdGhyb3VnaCBleGFjdGx5IHRoZSBzYW1lIGFuYWx5c2lzIHdpdGgg YW55IG5ldHdvcmsgdGhhdCBpcyBub3QgdG9wLW9mLXN0YWNrLCBlZyBFdGhlcm5ldC4gIEFuZCB3 aGVuIHlvdSBkbyB0aGlzIHdoYXQgeW91IHJlYWxpc2UgaXMgdGhhdCBhbHRob3VnaCB3ZSBjYW4g Y3JlYXRlIHBlZXIgaW50ZXJ3b3JraW5nIG9mIE1QTFMgKG9yIHdoYXRldmVyKSB0aGlzIGhhcyBu b3QgcmVhbGx5IGhlbHBlZCBzaW5jZSB3ZSBtaWdodCBhcyB3ZWxsIGhhdmUganVzdCB0ZXJtaW5h dGVkIHRoZSBNUExTIG5ldHdvcmsgYW5kIHBhc3NlZCB0aGUgSVAgbGF5ZXIgYWNyb3NzLiANCgkg IA0KCU5vdyB0aGUgYWJvdmUgYmVjb21lcyBldmVuIG1vcmUgc3RyaWtpbmcgaW4gaXRzIGltcG9y dGFuY2UgaWYgeW91IGNvbnNpZGVyIHBlZXIgaW50ZXJ3b3JraW5nIG9mIDIgZGlmZmVyZW50IG5v biB0b3Atb2Ytc3RhY2sgbmV0d29ya3MuLi4ubGV0cyBwaWNrIE1QTFMgYW5kIEV0aGVybmV0IGJl Y2F1c2UgdGhhdCBpcyB3aGF0IGlzIG9mdGVuIG1lbnRpb25lZC4gICANCgkgIA0KCVdoYXQgd2Ug aGF2ZSB0byBkbyBub3cgYXQgdGhlIEUtTk5JcyBiZXR3ZWVuIEV0aGVybmV0IGFuZCBNUExTIGlz IGdvIHRocm91Z2ggZWFjaCBEUCBhbmQgQ1AgY29tcG9uZW50IGFuZCBkbyBhICdwcm90b2NvbCBj b252ZXJzaW9uJyBleGVyY2lzZSB3aGVyZSByZXF1aXJlZC4uLi4uLmFuZCB0aGUgZmlyc3QgcHJv YmxlbSB5b3Ugd2lsbCBlbmNvdW50ZXIgaXMgdGhhdCB0aGVyZSB3aWxsIGJlIGxvdHMgb2YgZnVu Y3Rpb25hbCBtaXNtYXRjaC4gIE1vcmVvdmVyIGlmIG9uZSBvciBib3RoIG9mIHRoZSBuZXR3b3Jr cyBjYW4gc3VwcG9ydCBtdWx0aXBsZSBDUCB0eXBlcyBsaWtlIE1QTFMgY2FuLCBlZyBSU1ZQLVRF IHNpZ25hbGxpbmcsIExEUCBzaWduYWxsaW5nLCBCR1A0ICdzaWduYWxsaW5nJywgT1NQRiByb3V0 aW5nLCBJUy1JUyByb3V0aW5nLi4uLi5hbmQgSSBjb3VsZCBsaXN0IHNpbWlsYXIgZm9yIEV0aGVy bmV0Li4uLi55b3UgYXJlIGdvaW5nIHRvIGhhdmUgdG8gY29uc2lkZXIgZWFjaCBwYWlyaW5nIGNh c2UgaW4gdHVybi4gIEEgbG90IG9mIHdvcmsuIA0KCSAgDQoJQW5kIHdoZW4geW91IGhhdmUgZG9u ZSBhbGwgdGhpcyB5b3UgYXNrIHRoZSBxdWVzdGlvbiAnd2hhdCBpcyBpdCB0aGF0IGNhcnJpZXMg dGhlIHJlYWwgZXh0ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMgaW4gdGhl IERQIGhlcmU/Jy4uLi4uLi5hbmQgbm93IHlvdSBmaW5kIG5vIG5hdGl2ZSBzdXBwb3J0IGZvciB0 aGVzZSBpbiBNUExTIG9yIEV0aGVybmV0LCBidXQgd2hhdCB3ZSBkbyBmaW5kIGlzIHRoYXQgYm90 aCBvZiB0aGVtIGFyZSBjYXJyeWluZyBJUCBiZWNhdXNlIHRoaXMgZG9lcyBzdXBwb3J0IHRoZSBl eHRlcm5hbCBhcHBsaWNhdGlvbnMuICBOb3cgYXQgdGhpcyBwb2ludCB3ZSBoYXZlIGRpc2NvdmVy ZWQgd2hhdCBpcyB0aGUgY29tbW9uIHRoaW5nIGJldHdlZW4gTVBMUyBhbmQgRXRoZXJuZXQuLi4u aXQgaXMgdGhlIHRvcC1vZi1zdGFjayBJUCBsYXllciBuZXR3b3JrLiAgQW5kIHNvIHdlIHVsdGlt YXRlbHkgcmVhbGlzZSB3ZSBjb3VsZCBoYXZlIHNhdmUgb3Vyc2VsdmVzIGEgbG9hZCBvZiB1bm5l Y2Vzc2FyeSB3b3JrIGJ5IHNpbXBseSB0ZXJtaW5hdGluZyB0aGUgTVBMUyBhbmQgRXRoZXJuZXQg bGF5ZXIgbmV0d29yayBhdCB0aGUgaW50ZXJ3b3JraW5nIHBvaW50IGFuZCBqdXN0IHBhc3NlZCB0 aGUgSVAgbGF5ZXIgbmV0d29yayBhY3Jvc3MuIA0KCSAgDQoJU29ycnkgSSd2ZSBoYWQgdG8gZ28g dGhyb3VnaCBhbGwgdGhpcyB5ZXQgYWdhaW4gKGVzcCBmb3IgYWxsIHRoZSBmb2xrcyB0aGF0IGhh dmUgYWxyZWFkeSB1bmRlcnN0b29kIHRoZSBwb2ludCkgYnV0IEkgZG8gaG9wZSBpdHMgY2xlYXIg bm93IGFuZCB3ZSBjYW4gcHV0IHRoaXMgaXNzdWUgdG8gYmVkLiANCgkgIA0KCXJlZ2FyZHMsIE5l aWwgDQoJDQoJDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJRnJvbTogc3Uu aHVpQHp0ZS5jb20uY24gW21haWx0bzpzdS5odWlAenRlLmNvbS5jbl0gDQoJU2VudDogMjkgQXBy aWwgMjAwOSAwMzoyMg0KCVRvOiBIYXJyaXNvbixOLE5laWwsQ1hNIFINCglDYzogYWRyaWFuQG9s ZGRvZy5jby51azsgTml2ZW4tamVua2lucyxCLEJlbixETUYgUjsgaGhlbHZvb3J0QGNoZWxsby5u bDsgbXBscy10cEBpZXRmLm9yZzsgbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoJU3ViamVjdDog 562U5aSNOiBSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KCQ0KCQ0KCUhpIE5laWwsIA0KCQ0KCeKA mGl0IGlzIHF1aXRlIGNsZWFyIGZyb20gYSBzaW1wbGUgdGVjaG5pY2FsIGFuYWx5c2lzIHRoYXQg YW55IG5vbiB0b3Atb2Ytc3RhY2sgbmV0d29yayBoYXMgbm8gbmVlZCBmb3IgRS1OTkkgcGVlci1w YXJ0aXRpb24gd29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBvcGVyYXRpbmcgcGFydGllcy7igJkg DQoJDQoJSSBjYW5ub3QgYWdyZWUgdGhpcyBzdGF0ZW1lbnQuIA0KCUZvciBleGFtcGxlLCB0aGVy ZSBhcmUgdHdvIElQIG5ldHdvcmtzIGJlbG9uZ2luZyB0byB0d28gb3BlcmF0b3JzLCBhIEUxIGlz IHRyYW5zcG9ydGVkIGZyb20gQSBuZXR3b3JrIHRvIEIgbmV0d29yayAoZS5nLiBFMW92ZXJQV292 ZXJJUCApLCBJUCBwYWNrZXQobm90IEUxKSBwYXNzIGFjcm9zcyBmb3JtIEEgdG8gQiBhdCBib3Jk ZXIgbm9kZSwgc28gdGhlcmUgaXMgYSBFLU5OSSBiZXR3ZWVuIHRoZXNlICB0d28gSVAgbmV0d29y ay4gSW4gdGhpcyBjYXNlLCBpcyBJUCBhIHRvcC1vZi1zdGFjayBuZXR3b3JrPyANCglOb3cgbGV0 IHVzIHJlcGxhY2UgSVAgbmV0d29ya3MgYnkgTVBMUy1UUCBuZXR3b3JrcyAoZS5nLiBFMW92ZXJQ V292ZXJNUEwtVFApLCBNUExTLVRQIG5ldHdvcmsgaXMgYXQgc2FtZSBwb3NpdGlvbiBpbiB0aGUg c3RhY2sgYXMgSVAgbmV0d29yayBpcywgd2h5IGNhbiBJUCBuZXR3b3JrIGhhdmUgRS1OTkkgYnV0 IE1QTFMtVFAgY2Fubm90PyANCgkNCglSZWdhcmQsIA0KCVN1aHVpIA0KCQ0KCQ0KPG5laWwuMi5o YXJyaXNvbkBidC5jb20+IA0K5Y+R5Lu25Lq6OiAgbXBscy10cC1ib3VuY2VzQGlldGYub3JnIA0K DQoyMDA5LTA0LTI4IDE0OjQzIA0KDQoNCg0K5pS25Lu25Lq6DQo8aGhlbHZvb3J0QGNoZWxsby5u bD4sIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiwgPGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29t PiANCuaKhOmAgQ0KbXBscy10cEBpZXRmLm9yZyANCuS4u+mimA0KUmU6IFttcGxzLXRwXSBBSVMv RkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoICAgICAgICBy ZXF1aXJlbWVudHMpDQoNCg0KCQ0KDQoNCgkNCgkNCgkNCglIdXViIHdyb3RlIDI3IEFwcmlsIDIw MDkgMjI6MjcNCgk+IA0KCT4gSGkgQWRyaWFuLA0KCT4gDQoJPiBZb3Ugd3JvdGU6DQoJPiANCgk+ ID4gSXNuJ3QgdGhlIHNvbHV0aW9uIGhlcmUgdGhlIHNhbWUgYXMgdGhlIG9uZSBJIHByb3Bvc2Vk IGZvciAiVENNIj8NCgk+IA0KCT4gSW5kZWVkLCBhbmQgdGhhdCB3ZSBkbyBub3QgaGF2ZSB0byBh cm91bmQgaW4gY2lyY2xlcyBhYm91dCBUQ00uDQoJPiANCgk+IEhvdyBhYm91dDoNCgk+IHRoZSBy ZXF1aXJlbWVudCBpcyB0aGF0IGEgc2VydmVyIGxheWVyIHNoYWxsIGluZm9ybSBpdHMgY2xpZW50 cw0KCT4gdGhhdCBpdCBoYXMgZGV0ZWN0ZWQgYSBzZXJ2aWNlIGludGVydXB0aW9uLCB0aGlzIHRv IGVuc3VyZSB0aGF0DQoJPiB0aGUgY2xpZW50cyBjYW4gaW5oaWJpdCAodW5uZWNlc3NhcnkpIGFs YXJtcy4NCgkNCglOSD0+IFRoaXMgb25seSBhcHBsaWVzIGlmIHRoZSBjbGllbnQvc2VydmVyIGJp bmRpbmcgaXMgZml4ZWQuICBBbmQgb2YNCgljb3Vyc2Ugd2F5IGJhY2sgaW4gdGhlIDcwcyB3aGVu IGJpbmFyeSBhbGwgMXMgcG9wcGVkIG91dCBvZiB0aGUgZmFpbGVkDQoJVFRMIGxvZ2ljIGludG8g dGhlIFBESCB0cmFuc3BvcnQgaGllcmFyY2h5IHRoaXMgd2FzIHRydWUuICBBbHNvOiBubw0KCWxh YmVscyBoZXJlIGFuZCBubyBjbGllbnQgdHJhZmZpYyB1bml0cyB0byBjcmVhdGUuICAgDQoJDQoJ V2hlcmUgdGhlIGNsaWVudCBjYW4gZHluYW1pY2FsbHkgYmUgcmUtcm91dGVkIGluIHJlc3BvbnNl IHRvIGEgc2VydmVyDQoJZmFpbHVyZSB0aGUgcHJvcG9zZWQgdGV4dCBpcyBub3QgdmFsaWQuICBJ dCBpcyBhbHNvIG5vdCBuZWNlc3NhcnkgdGhhdA0KCXRoZSBzZXJ2ZXIgaGFzIHRvIGtlZXAgdHJh Y2sgb2Ygd2hlcmUgaXRzIGNsaWVudCB0cmFmZmljIHJvdXRpbmdzIGhhdmUNCgltb3ZlZCB0by4g IEZvciBleGFtcGxlLCBpZiBJIGNyZWF0ZSB0aGUgdG9wb2xvZ3kgb2YgYW4gSVAgbGF5ZXIgbmV0 d29yaw0KCXdpdGggbGlua3MgcHJvdmlkZWQgYnkgU0RILCBFdGhlcm5ldCwgQVRNLCBPVE4sIGV0 YyBzZXJ2ZXJzLCBhbmQgZWFjaCBvZg0KCXRoZXNlIHNlcnZlciBsaW5rcyBpcyBwcm92aWRlZCBi eSBhIGRpZmZlcmVudCBvcGVyYXRvciwgdGhlbiB3aHkgc2hvdWxkDQoJdGhlIHNlcnZlcnMgbmVl ZCBoYXZlIGtub3dsZWRnZSBvZiB3aGVyZSB0aGUgSVAgZmxvd3MgaGF2ZSBtb3ZlZCB0byBpbg0K CXJlc3BvbnNlIHRvIGEgc2VydmVyIGxheWVyIGZhaWx1cmUgd2hlbiB0aGUgbmV3IHJvdXRlcyBo YXZlIGJlZW4NCgljYWxjdWxhdGVkIGJ5IHRoZSBJR1AgaW4gdGhlIElQIGxheWVyIG5ldHdvcms/ ICBJIGNhbiBhcHBseSB0aGUgc2FtZQ0KCWxvZ2ljIHRvIGFuIFNWQy1iYXNlZCBjby1wcy9jby1j cyBtb2RlIGNsaWVudC4uLi5pbmRlZWQgdGhlIGNvLWNzIG1vZGUNCglQU1ROIGlzIGxpa2UgdGhp cy4NCgkNCglUaGVzZSBvYnNlcnZhdGlvbnMgbWFrZSBpdCBxdWl0ZSBjbGVhciB0byBtZSBhdCBs ZWFzdCB0aGF0IGp1c3QgY29weWluZw0KCXRoZSBBSVMgYmVoYXZpb3VyIG9mIHRoZSBvbGQgdHJh bnNwb3J0IGhpZXJhcmNoaWVzIHRoYXQgaGFkIGZpeGVkDQoJY2xpZW50L3NlcnZlciByZWxhdGlv bnNoaXBzIGlzIG5vdCBhIHNlbnNpYmxlIHRoaW5nIHRvIGRvLg0KCQ0KCUlNTyB0aGUgb25seSBl c3NlbnRpYWwgRFAgT0FNIHJlcXVpcmVtZW50IGlzIHRoYXQgZWFjaCBsYXllciBuZXR3b3JrDQoJ c2hvdWxkIGJlIHNlbGYtc3VmZmljaWVudCB3cnQgT0FNIGFuZCBub3QgcmVseSBvbiBhbnkgc2Vy dmVyIGxheWVyDQoJcHJpbWl0aXZlcyBiZWluZyBwYXNzZWQgdXB3YXJkcy4NCgkNCglNb3Jlb3Zl ciwgaXQgc2hvdWxkIGFsc28gYmUgbm90ZWQgdGhhdCAoaSkgdGhlIGRlZmVjdHMgdGhhdCBjYW4g b2NjdXIgaW4NCgllYWNoIG9mIHRoZSAzIG5ldHdvcmsgbW9kZXMgYXJlIG5vdCB0aGUgc2FtZSBh bmQgKGlpKSB0aGVpciBPQU0NCglyZXF1aXJlbWVudHMgYXJlIG5vdCBpZGVudGljYWxseSB0aGUg c2FtZS4gU28gdGhlIE9BTSB0aGF0IGFwcGxpZXMgdG8NCgl0aGUgY2wtcHMgbW9kZSAoZWcgSVAp IGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgT0FNIHRoYXQgYXBwbGllcyB0byB0aGUNCgljby1wcyBt b2RlIChlZyBNUExTLVRQKSBhbmQgbmVpdGhlciBvZiB0aGVzZSBpcyBpZGVudGljYWxseSB0aGUg c2FtZSBhcw0KCXRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvIHRoZSBjby1jcyBtb2RlIChlZyBTREgp Lg0KCQ0KCU5vdGUgLSBUaGUgb25seSBwb2ludCBiZWluZyBjb25zaWRlcmVkIGhlcmUgaXMgdGhl IHJlYWwgY2xpZW50IGFuZA0KCXNlcnZlciB0cmFmZmljIHJlbGF0aW9uc2hpcC4gIFRoZSBjcmVh dGlvbiBvZiBhIGhpZXJhcmNoeSBvZiBUQ00NCglzdWJsYXllcnMgaXMgYSBzZXBhcmF0ZSB0b3Bp Yy4gIEZ1cnRoZXIsIGl0IGlzIHF1aXRlIGNsZWFyIGZyb20gYSBzaW1wbGUNCgl0ZWNobmljYWwg YW5hbHlzaXMgdGhhdCBhbnkgbm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIGhhcyBubyBuZWVkIGZv cg0KCUUtTk5JIHBlZXItcGFydGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0 aW5nIHBhcnRpZXMuICBTbw0KCXRoaXMgaXMgYWxzbyBhIHNlcGFyYXRlIGlzc3VlLiAgSG93ZXZl ciwgSSBwcm9wb3NlIHRoYXQgdGhpcyBsYXR0ZXINCglwb2ludCBiZSBjYXB0dXJlZCBpbiB0aGUg TVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQgZHVlIHRvIGl0cw0KCXN0YW5kLWFsb25lIGFuZCBn ZW5lcmljIGltcG9ydGFuY2UsIGllIHRoaXMgYXBwbGllcyB0byBtb3JlIHRoYW4ganVzdCBEUA0K CU9BTS4gIEJlbiBjYW4geW91IHBsZWFzZSBjb25zaWRlciB0aGlzIHBvaW50IGFzL3doZW4gdGhl IE1QTFMtVFANCglyZXF1aXJlbWVudHMgZHJhZnQgaXMgdXBkYXRlZC4NCgkNCglyZWdhcmRzLCBO ZWlsDQoJDQoJPiBDaGVlcnMsIEh1dWIuDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCgltcGxzLXRwIG1haWxpbmcgbGlzdA0KCW1wbHMtdHBAaWV0Zi5v cmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCgkNCgkN CgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KCVpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy4NCglUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBz eXN0ZW0uDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCglaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoJVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy Lg0KCVRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KDQo= ------_=_NextPart_001_01C9C8B4.5472C714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5UaGFua3MgU3VodWkuLi4uLi5z b3JyeSBJIG1pc3NlZCB5b3VyIA0Kc3BlY2lmaWMgcXVlc3Rpb24uLi4uaGF2ZSBhIGxvb2sgaW4t bGluZSBhbmQgc2VlIGlmIHRoaXMgDQpoZWxwcy48L0ZPTlQ+PC9TUEFOPjwvRElWPjxCUj4NCjxC TE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZU OiA1cHg7IEJPUkRFUi1MRUZUOiAjODAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgi Pg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBh bGlnbj1sZWZ0Pg0KICA8SFIgdGFiSW5kZXg9LTE+DQogIDxGT05UIGZhY2U9VGFob21hIHNpemU9 Mj48Qj5Gcm9tOjwvQj4gc3UuaHVpQHp0ZS5jb20uY24gDQogIFttYWlsdG86c3UuaHVpQHp0ZS5j b20uY25dIDxCUj48Qj5TZW50OjwvQj4gMjkgQXByaWwgMjAwOSAxMDozMTxCUj48Qj5Ubzo8L0I+ IA0KICBIYXJyaXNvbixOLE5laWwsQ1hNIFI8QlI+PEI+Q2M6PC9CPiBhZHJpYW5Ab2xkZG9nLmNv LnVrOyANCiAgTml2ZW4tamVua2lucyxCLEJlbixETUYgUjsgaGhlbHZvb3J0QGNoZWxsby5ubDsg bXBscy10cEBpZXRmLm9yZzsgDQogIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzxCUj48Qj5TdWJq ZWN0OjwvQj4g562U5aSNOiBSRTogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgDQogIEFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpPEJSPjwvRk9O VD48QlI+PC9ESVY+DQogIDxESVY+PC9ESVY+DQogIDxESVY+PEJSPjxGT05UIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTI+SGkgTmVpbO+8jDwvRk9OVD4gPEJSPjxCUj48Rk9OVCANCiAgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj5UaGFua3MgZm9yIHlvdXIgcmFwaWQgcmVwbHkuPC9GT05UPiA8QlI+PEZP TlQgDQogIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+SSBhbSBjb25mdXNlZCBieSB5b3VyIGNvbW1l bnRzLCBhcmUgeW91IHN1Z2dlc3RpbmcgDQogIEV2ZXJ5dGhpbmdvdmVySVBvdmVyTVBMUy1UUD8g QUZBSUssIE1QTFMtVFAgY2FuIGNhcnJ5IG1hbnkga2luZHMgb2YgY2xpZW50cywgDQogIG5vdCBq dXN0IElQLkluIG15IGV4YW1wbGUsIEUxb3ZlclBXb3Zlck1QTFMtVFAsIHRoZXJlIGlzIG5vIElQ IGxheWVyIGF0IA0KICBhbGwuPC9GT05UPiZuYnNwOzxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMi PjxGT05UIGNvbG9yPSM4MDAwMDA+PEZPTlQgDQogIHNpemU9Mj48U1BBTiBjbGFzcz04OTkyODM4 MDktMjkwNDIwMDk+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRElWPg0KICA8 RElWPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxGT05UIGNvbG9yPSM4MDAwMDA+PEZPTlQg c2l6ZT0yPjxTUEFOIA0KICBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+Jm5ic3A7PC9TUEFOPjxT UEFOIA0KICBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0ZP TlQ+PC9GT05UPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTg5OTI4MzgwOS0yOTA0MjAwOT48 Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+Tkg9Jmd0 OyBGdWxseSB1bmRlcnN0YW5kLiZuYnNwOyBJIHdhcyBnaXZpbmcgSVAgYXMgYW4gKmV4YW1wbGUq IG9mIGEgDQogIHRlY2hub2xvZ3kgdGhhdCBjYW4gc3VwcG9ydCByZWFsIGV4dGVybmFsIGFwcGxp Y2F0aW9ucyBiZWNhdXNlIGl0IGhhcyANCiAgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlv biBhZGFwdGF0aW9uIGZ1bmN0aW9ucyBpbiB0aGUgZm9ybSBvZiANCiAgVURQL1RDUC9SVFAuJm5i c3A7Jm5ic3A7IEluIHRoZSBjYXNlIG9mIEUxIHRoYXQgeW91IG5vdGUgKGFzIA0KICBFMW92ZXJQ V292ZXJNUExTLVRQKSB5b3UgaGF2ZSB0byBhc2sgeW91cnNlbGYgd2hhdCBzcGVjaWZpYyAqZXh0 ZXJuYWwqIA0KICBhcHBsaWNhdGlvbnMgZG9lcyB0aGUgRTEgc3VwcG9ydCBoZXJlPy4uLi4uYWx3 YXlzIHJlbWVtYmVyaW5nIHRoYXQgKmFueSogDQogIG5ldHdvcmtpbmcgdGVjaG5vbG9neSBNVVNU IHVsdGltYXRlbHkgc3VwcG9ydCBzb21lIGZvcm0gb2YgKmV4dGVybmFsbHkgDQogIHNvdXJjZWQq IGluZm9ybWF0aW9uIHNvdXJjZSBlbHNlIGl0IGlzIG5vdCBzZXJ2aW5nIGFueSBwdXJwb3NlLiZu YnNwOyBTbyBqdXN0IA0KICBzdXBwb3J0aW5nIEUxIG9uIGl0cyBvd24gZG9lcyBub3QgcHJvdmlk ZSB0aGlzLi4uLmZvciBleGFtcGxlIGFzayB5b3Vyc2VsZiBob3cgDQogIHZvaWNlIG9yIGFueSB0 eXBlIG9mIG1lc3NhZ2UvZmlsZSBkYXRhIGdldHMgY2FycmllZCBieSB0aGUgDQogIEUxLjwvRk9O VD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9ODk5MjgzODA5LTI5MDQyMDA5PiZu YnNwOzwvU1BBTj48QlI+PEZPTlQgDQogIGZhY2U9c2Fucy1zZXJpZj48Rk9OVCBzaXplPTI+QW5k IHlvdSBkb27igJl0IGFuc3dlciBteSBxdWVzdGlvbjogSVAgaXMgYSANCiAgdG9wLW9mLXN0YWNr IG5ldHdvcmsgaW4gdGhlIGNhc2Ugb2YgRTFvdmVyUFdvdmVySVAsIHdoeSBkb2Vzbid0IE1QTFMt VFAgYmUgYSANCiAgdG9wLW9mLXN0YWNrIG5ldHdvcmsgaW4gdGhlIGNhc2Ugb2YgRTFvdmVyUFdv dmVyTVBMUy1UUD8gVGhleSBhcmUgYXQgdGhlIHNhbWUgDQogIHBvc2l0aW9uIGluIHRoZSBzdGFj aywgYW5kIEkgdGhpbmsgRTEgaXMg4oCYcmVhbCBleHRlcm5hbCBzdHJlYW0gDQogIGFwcGxpY2F0 aW9uc+KAmTxTUEFOIGNsYXNzPTg5OTI4MzgwOS0yOTA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBT YW5zIE1TIiANCiAgY29sb3I9IzgwMDAwMD4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZP TlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1zYW5zLXNlcmlmPjxGT05UIGZhY2U9IkNvbWlj IFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj48U1BBTiBjbGFzcz04OTkyODM4MDkt MjkwNDIwMDk+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz04OTkyODM4MDktMjkwNDIw MDk+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDA+Tkg9Jmd0OyBU aGUgcG9pbnQgaGVyZSBpcyB0aGF0ICphbnkqIA0KICBuZXR3b3JrIG1vZGUvdGVjaG5vbG9neSAo YmUgaXQgY2wtcHMsIGNvLXBzIG9yIGNvLWNzKSBjYW4gYWN0IGFzIHRoZSBzZXJ2ZXIgDQogIGZv ciBhbnkgb3RoZXIgbW9kZS90ZWNobm9sb2d5LiZuYnNwOyBIb3dldmVyLCBub3QgYWxsIHRlY2hu b2xvZ2llcyBjYW4gc3VwcG9ydCANCiAgZXh0ZXJuYWwgYXBwbGljYXRpb25zLi4uLi50byBzdXBw b3J0IHRoZXNlIHRoZSB0ZWNobm9sb2d5IG11c3QgaGF2ZSANCiAgYXBwbGljYXRpb24gYWRhcHRh dGlvbiBmdW5jdGlvbnMgZm9yIHRoZSBtZXNzYWdlL2ZpbGUvc3RyZWFtIGluZm9ybWF0aW9uIA0K ICBzb3VyY2VzIHRoYXQgYXJlIGdlbmVyYXRlZCBpbiBleHRlcm5hbCBDUEUsIGVnIHBob25lLCBQ QywgDQogIGV0Yy48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZP TlQgZmFjZT1zYW5zLXNlcmlmPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgDQogIHNpemU9Mj48U1BBTiBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+PC9TUEFOPjwvRk9O VD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1zYW5zLXNlcmlmPjxGT05U IGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj48U1BBTiBjbGFz cz04OTkyODM4MDktMjkwNDIwMDk+TW9zdCB0ZWNobm9sb2dpZXMgZG8gbm90IGhhdmUgdGhlc2Ug DQogIGV4dGVybmFsIGFwcGxpY2F0aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zIGFuZCBzbyB0aGUg b25seSBqb2IgdGhleSBjYW4gZG8gaXMgDQogIGNyZWF0ZSB0aGUgdG9wb2xvZ3kgb2Ygb3RoZXIg bGF5ZXIgbmV0d29ya3MuPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmPjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9ODk5MjgzODA5LTI5 MDQyMDA5PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxTUEFOIA0KICBjbGFzcz04OTkyODM4MDktMjkw NDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0y PiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9ODk5MjgzODA5 LTI5MDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNp emU9Mj5TbyB5ZXMgd2UgY2FuIHVzZSBJUCAoY2wtcHMpIHRvIGNhcnJ5Jm5ic3A7U0RIIFZDNCAo Y28tY3MpIGlmIHdlIA0KICB3YW50Li4uLi4uLnByb2JhYmx5IG5vdCBhIGdvb2QgaWRlYSBidXQg aXQgaXMgZm9yIHN1cmUgDQogIHBvc3NpYmxlLjwvRk9OVD4mbmJzcDs8Rk9OVCBmYWNlPSJDb21p YyBTYW5zIE1TIj48Rk9OVCBjb2xvcj0jODAwMDAwIHNpemU9Mj4gDQogIEhvd2V2ZXIsIGFuIFNE SCBWQzQgbmV0d29yayBjYW5ub3QgKmRpcmVjdGx5KiBzdXBwb3J0IGVpdGhlciB2b2ljZSBvciBk YXRhIGJ1dCANCiAgYW4gSVAgbmV0d29yayBjYW4uLi4uLmJlY2F1c2UgSVAgaGFzIFVEUC9UQ1Av UlRQJm5ic3A7YXBwbGljYXRpb25zIGFkYXB0YXRpb25zIA0KICBhbmQgU0RIIFZDNCBkb2VzIG5v dCBoYXZlIHRoZXNlLiZuYnNwOyBIYXZpbmcgc2FpZCB0aGF0LCB0aGVyZSBpcyBpbiBwcmluY2lw bGUgDQogIG5vIHJlYXNvbiB3aHkgYW55IG1vZGUvdGVjaG5vbG9neSAoZXZlbiBTREggVkM0KSBj YW5ub3QgDQogIHN1cHBvcnQmbmJzcDtleHRlcm5hbCZuYnNwO21lc3NhZ2UvZmlsZS9zdHJlYW0g YXBwbGljYXRpb25zLi4uLi4uaXRzIGp1c3QgdGhhdCANCiAgZm9yIG1vc3QgdGVjaG5vbG9naWVz IHRoZXNlIGhhdmUgbmV2ZXIgYmVlbiBzcGVjaWZpZWQgYmVjYXVzZSB0aGV5IHdlcmUgb25seSAN CiAgZXZlciBpbnRlbmRlZCB0byBwcm92aWRlIGEgJ25ldHdvcmsgYnVpbGRlcicgdHJhbnNwb3J0 IA0KICByb2xlLjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNz PTg5OTI4MzgwOS0yOTA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAw MDAwIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBj bGFzcz04OTkyODM4MDktMjkwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9 IzgwMDAwMCANCiAgc2l6ZT0yPkFzaWRlPSZndDsgSWYgYSB0ZWNobm9sb2d5IFggY2FuIHN1cHBv cnQgbWVzc2FnZS9maWxlL3N0cmVhbSANCiAgYXBwbGljYXRpb25zIGRpcmVjdGx5IHRoZW4gaGVy ZSB3ZSB3b3VsZCBtb3N0IGRlZmluaXRlbHkgaGF2ZSB0byBjb25zaWRlciANCiAgcGVlci1pbnRl cndvcmtpbmcgdGVjaG5vbG9neSBYIHdpdGggYm90aCBJUCAoSW50ZXJuZXQpIGFuZCBQU1ROICh2 b2ljZSBjYXNlIA0KICBvbmx5KS4mbmJzcDsgSW4gYWxsIG90aGVyIGNhc2VzIChpZSB3aGVyZSB0 ZWNobm9sb2d5IFggaXMgbm90IHRvcC1vZi1zdGFjaywgaWUgDQogIGRvZXMgbm90IGhhdmUgbWVz c2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbiBhZGFwdGF0aW9uIGZ1bmN0aW9ucykgdGhlcmUg aXMgDQogIG5vIG5lZWQgZm9yIHBlZXItaW50ZXJ3b3JraW5nIGl0IHdpdGggYW55IG90aGVyIHRl Y2hub2xvZ3ksIGluY2x1ZGluZyBJUCANCiAgKEludGVybmV0KSBhbmQgUFNUTi48L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTg5OTI4MzgwOS0yOTA0MjAwOT48Rk9OVCBm YWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+PC9GT05UPjwvU1BB Tj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+PEZP TlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9ODk5MjgzODA5LTI5MDQyMDA5 PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj5Zb3Vy IGZpbmFsIHBvaW50ICgiPEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDAwPkkgdGhpbmsgRTEg aXMg4oCYcmVhbCANCiAgZXh0ZXJuYWwgc3RyZWFtIGFwcGxpY2F0aW9uc+KAmSI8L0ZPTlQ+PFNQ QU4gY2xhc3M9ODk5MjgzODA5LTI5MDQyMDA5PjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1T IiBjb2xvcj0jODAwMDAwPiZuYnNwOzwvRk9OVD48L1NQQU4+KSBpcyBub3Qgc3RyaWN0bHkgDQog IGNvcnJlY3QgYnV0IEkgY2FuIGZ1bGx5IHVuZGVyc3RhbmQgd2h5IHlvdSBzYXkgdGhpcy4mbmJz cDsgRTEgYmVsb25ncyB0byB0aGUgDQogIGNvLWNzIG1vZGUuJm5ic3A7IFdoZW4geW91IGFuYWx5 c2UgdGhpcyAoYXMgaXMgZG9uZSBpbiBHLjgwMCwgd2hpY2ggZXhwbGFpbnMgDQogIHdoeSB0aGUg MyBuZXR3b3JrIG1vZGVzIGFyaXNlIGZyb20gaW5mb3JtYXRpb24vc3lzdGVtcyB0aGVvcnkgY29u c2lkZXJhdGlvbnMpIA0KICB5b3UgZmluZCB0aGF0IGluIHRoZSB0aW1lIGRpbWVuc2lvbiB0aGUg Y28tY3MgbW9kZSBwYXJ0aXRpb25zIHJlc291cmNlICh0aW1lKSANCiAgdXAgaW50byByZWd1bGFy IHRpbWUgc2xpY2VzLi4uLnNvIHRoaXMgbWVhbnMgYm90aCB0aGUgc3RhcnQgZXBvY2ggKGFuIGlt cGxpY2l0IA0KICBsYWJlbCkgYW5kIChtb3N0IGNydWNpYWxseSkgaXRzIGR1cmF0aW9uIGFyZSBm aXhlZC4mbmJzcDsgPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz04OTky ODM4MDktMjkwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCAN CiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9 ODk5MjgzODA5LTI5MDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgDQogIHNpemU9Mj5XaXRob3V0IGdvaW5nIGludG8gbWFqb3IgZGV0YWlsIGhlcmUgKEkgaGF2 ZSBwYXBlciBvbiB0aGlzIEkgY2FuIHNlbmQgDQogIHlvdSBpZiB5b3Ugd2FudC4uLmp1c3QgYXNr KSB3aGF0IHRoaXMgbWVhbnMgaXMgdGhhdCB0aGUgY28tY3MgbW9kZSBpcyB0aGUgDQogIHVsdGlt YXRlICdzbW9vdGhlci9zaGFwZXInIGZvciBjbGllbnQgdHJhZmZpYy4uLi4uLnNvIGFzIHlvdSBy aWdodGx5IG9ic2VydmUgDQogIHRoaXMgbG9va3MgbGlrZSBhIHN0cmVhbSBjYXNlLiZuYnNwOyBJ dCdzIG5vdCBhIHNwZWNpZmljIGV4dGVybmFsIGFwcGxpY2F0aW9uIA0KICBob3dldmVyIGxpa2Ug aHVtYW4gdm9pY2Ugb3IgdmlkZW8gKHRoZXNlIG11c3QgZ2VuZXJhdGUgcmVhbCAqaW5mb3JtYXRp b24qIHRoYXQgDQogIGNvbW11bmljYXRpbmcgcGFydGllcyB1bmRlcnN0YW5kKSBidXQgaXQgZm9y IHN1cmUgaGFzIHRoZSBDQlIgYmVoYXZpb3VyIG9mIGEgDQogIHN0cmVhbS4mbmJzcDs8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTg5OTI4MzgwOS0yOTA0MjAwOT48Rk9O VCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+ PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPkJUVyB0 aGUgcmVhc29uIHRoZSBjby1jcyBtb2RlIGhhcyBiZWVuIGVuZHVyaW5nbHkgc3VjY2Vzc2Z1bCBh cyBhIA0KICB0cmFuc3BvcnQgbmV0d29yayBpcyZuYnNwO2JlY2F1c2UgaXQgcHJvdmlkZXMgKnRy YW5zcGFyZW5jeSogdG8gYWxsIGNsaWVudHMgDQogICh3aGljaCBpcyBleGFjdGx5IHRoZSBzaW1p bGFyIGJlaGF2aW91ciBvZiBhIHN0cmVhbSBhcyB5b3Ugbm90ZSksIA0KICBpZTwvRk9OVD48L1NQ QU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9ODk5MjgzODA5LTI5MDQyMDA5PjxGT05UIGZh Y2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj4tJm5ic3A7Jm5ic3A7 Jm5ic3A7IGFsbCBjbGllbnQgYml0cyB0cmVhdGVkIGVxdWFsbHkgKGEgcmVhbGx5IGtleSBwb2lu dCANCiAgdGhpcywgYXMgdGhpcyBtZWFucyBpdCBwcm92aWRlcyBlcXVhbCAnaW1wb3J0YW5jZScg dHJlYXRtZW50IG9mIHRoZSB1bHRpbWF0ZSANCiAgaGlnaGVyIGxldmVsIChhbmQgdW5zZWVuL3Vu a25vd24gYnkgdGhlIGNvLWNzIHRyYW5zcG9ydCBuZXR3b3JrKSANCiAgbWVzc2FnZS9maWxlL3N0 cmVhbSBhcHBsaWNhdGlvbnMpPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFz cz04OTkyODM4MDktMjkwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9Izgw MDAwMCANCiAgc2l6ZT0yPi0mbmJzcDsmbmJzcDsmbmJzcDsgY2xpZW50IGJpdCBvcmRlcmluZyBp cyANCnByZXNlcnZlZDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9ODk5 MjgzODA5LTI5MDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAg DQogIHNpemU9Mj4tJm5ic3A7Jm5ic3A7Jm5ic3A7IGRvZXMgbm90IHRyeSBhbiBpbmZlciBtZWFu aW5nIG9mIGNsaWVudCBiaXRzIG5vciANCiAgY2hhbmdlIHRoZW08L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICA8RElWPjxTUEFOIGNsYXNzPTg5OTI4MzgwOS0yOTA0MjAwOT48Rk9OVCBmYWNlPSJDb21p YyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+LSZuYnNwOyZuYnNwOyZuYnNwOyBl bnN1cmVzIHRoZSB0cmFmZmljIGJlaGF2aW91ciBvZiBjbGllbnQgWCBjYW5ub3QgDQogIGltcGFj dCB0aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQgYnkgcGFydHkgWS48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTg5OTI4MzgwOS0yOTA0MjAwOT48Rk9OVCBmYWNlPSJD b21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJz cDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+PC9TUEFOPjxT UEFOIA0KICBjbGFzcz04OTkyODM4MDktMjkwNDIwMDk+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBN UyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9ODk5MjgzODA5LTI5MDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNh bnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj5yZWdhcmRzLCBOZWlsPC9GT05UPiZuYnNw OzwvU1BBTj48QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCiAgc2l6ZT0yPlJlZ2FyZHMs PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj5TdWh1aS48L0ZPTlQ+IA0K ICA8QlI+PEJSPjxCUj48L0RJVj4NCiAgPFRBQkxFIHdpZHRoPSIxMDAlIj4NCiAgICA8VEJPRFk+ DQogICAgPFRSIHZBbGlnbj10b3A+DQogICAgICA8VEQgd2lkdGg9IjI2JSI+PEZPTlQgZmFjZT1z YW5zLXNlcmlmIA0KICAgICAgICBzaXplPTE+PEI+Jmx0O25laWwuMi5oYXJyaXNvbkBidC5jb20m Z3Q7PC9CPiA8L0ZPTlQ+DQogICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+ MjAwOS0wNC0yOSAxNDo0MDwvRk9OVD4gPC9QPg0KICAgICAgPFREIHdpZHRoPSI3MyUiPg0KICAg ICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICA8 VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgPERJViBhbGln bj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuaUtuS7tuS6ujwvRk9OVD48L0RJ Vj4NCiAgICAgICAgICAgIDxURD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPiZsdDtzdS5o dWlAenRlLmNvbS5jbiZndDs8L0ZPTlQ+IA0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAg ICAgICAgICAgPFREPg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTE+5oqE6YCBPC9GT05UPjwvRElWPg0KICAgICAgICAgICAgPFREPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+Jmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7LCAN CiAgICAgICAgICAgICAgJmx0O2JlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tJmd0OywgDQog ICAgICAgICAgICAgICZsdDtoaGVsdm9vcnRAY2hlbGxvLm5sJmd0OywgJmx0O21wbHMtdHBAaWV0 Zi5vcmcmZ3Q7LCANCiAgICAgICAgICAgICAgJmx0O21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyZn dDs8L0ZPTlQ+IA0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFREPg0K ICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTE+5Li76aKYPC9GT05UPjwvRElWPg0KICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTE+UkU6IFJlOiBbbXBscy10cF0gQUlTL0ZESSAod2FzIA0KICAgICAgICAgICAg ICBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggJm5ic3A7ICZuYnNwOyAm bmJzcDsgDQogICAgICAgICAgICAgICZuYnNwO3JlcXVpcmVtZW50cyk8L0ZPTlQ+PC9UUj48L1RC T0RZPjwvVEFCTEU+PEJSPg0KICAgICAgICA8VEFCTEU+DQogICAgICAgICAgPFRCT0RZPg0KICAg ICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgPFRE PjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PEJSPjxC Uj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+VGhh bmtzIFNodWh1aSw8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJS PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPkRvIA0KICBu b3QgY29uZnVzZSBwaHlzaWNhbCBpbnRlcmNvbm5lY3Qgd2l0aCBFLU5OSS4uLi4uSSdsbCBjb21l IGJhY2sgb24gdGhpcyANCiAgc2hvcnRseSB3aGVuIGRpc2N1c3NpbmcgdGhlIGJvdHRvbS1vZi1z dGFjayBzZWN0aW9uIGxheWVyLjwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTM+Jm5ic3A7PC9G T05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+ VGhlIA0KICBmaXJzdCB0aGluZyB0byB1bmRlcnN0YW5kIGlzIHRoYXQgKmFsbCogbmV0d29ya3Mg YXJlIHRoZXJlIHRvIHVsdGltYXRlbHkgDQogIHN1cHBvcnQgb25lIHB1cnBvc2UuLi4uLmFuZCB0 aGF0IGlzIHRvIGFsbG93IGNvbW11bmljYXRpb25zIGJldHdlZW4gcGFydGllcyANCiAgdGhhdCBh cmUgKmV4dGVybmFsKiB0byB0aGUgbmV0d29ya3MuICZuYnNwO1NvIGV2ZXJ5dGhpbmcgd2UgZG8g aW4gbmV0d29ya2luZyANCiAgaXMgdGhlcmUgdG8gdWx0aW1hdGVseSBzdXBwb3J0IHRoaXMgb2Jq ZWN0aXZlLiAmbmJzcDtXaGF0IHRoaXMgbWVhbnMgaXMgdGhhdCANCiAgdGhlIERQIG9mIHNvbWUg bmV0d29yayAod2hhdCBJIGNhbGwgdGhlIHRvcC1vZi1zdGFjayBuZXR3b3JrKSBNVVNUIGJlIA0K ICBwcm92aWRpbmcgYWRhcHRhdGlvbiBmdW5jdGlvbnMgZm9yIHRoZXNlIGV4dGVybmFsIGFwcGxp Y2F0aW9ucy4uLi4uLi5hbmQgdGhlc2UgDQogIGNhbiBnZW5lcmljYWxseSBiZSBjbGFzc2lmaWVk IGFzIG1lc3NhZ2VzLCBmaWxlcyBhbmQgc3RyZWFtcy4gPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6 ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4 MDAwMDAgc2l6ZT0yPldlIA0KICBjYW4gc2VlIHRoYXQgSVAgaXMgYSB0b3Atb2Ytc3RhY2sgbmV0 d29yayBhcyBpdCBoYXMgVURQL1RDUC9SVFAgKGZvciBleGFtcGxlKSANCiAgYWRhcHRhdGlvbnMu ICZuYnNwO0FUTSB3YXMgYWxzbyBvbmNlICh+OTBzKSBpbnRlbmRlZCB0byBiZSBhIHRvcC1vZi1z dGFjayANCiAgbmV0d29yayBhbmQgaXQgaGFkIGl0cyBvd24gYXBwbGljYXRpb24gYWRhcHRhdGlv bnMgaW4gdGhlIGZvcm0gb2YgQUFMcy4gDQogICZuYnNwO0F0IG9uZSBzdGFnZSB0aGVyZSB3ZXJl IDUgb2YgdGhlc2UsIGJ1dCBpbiBwcmFjdGljZSBvbmx5IGEgY291cGxlIHdlcmUgDQogIHJlYWxs eSBzdWNjZXNzZnVsIGJlY2F1c2Ugb2YgdGhlIGdlbmVyaWMgbmF0dXJlIG9mIG1lc3NhZ2UvZmls ZS9zdHJlYW0gDQogIGNsYXNzaWZpY2F0aW9uLiAmbmJzcDtUaGUgUFNUTiBpcyBhbHNvIHRvcC1v Zi1zdGFjaywgYW5kIGl0cyBhcHBsaWNhdGlvbiANCiAgYWRhcHRhdGlvbiB3YXMgbWFpbmx5IGZv ciB2b2ljZSAoc3RyZWFtKSBzdXBwb3J0LjwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTM+Jm5i c3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBz aXplPTI+TW9zdCANCiAgb3RoZXIgbmV0d29ya3MgZG8gbm90IGhhdmUgdGhlc2UgYXBwbGljYXRp b24gYWRhcHRhdGlvbiBmdW5jdGlvbnMuLi4uc28gdGhleSANCiAgZG8gbm90IGRpcmVjdGx5IHN1 cHBvcnQgYXBwbGljYXRpb25zLiAmbmJzcDtXaGF0IHRoaXMgbWVhbnMgaW4gcHJhY3RpY2UgaXMg DQogIHRoYXQgdGhlc2UgbmV0d29ya3MgKGEgbGlzdCB3aGljaCBpbmNsdWRlcyBQREgsIFNESCwg T1ROLCBFdGhlcm5ldCwgTVBMUykgTVVTVCANCiAgY2FycnkgYSBmdXJ0aGVyIGxheWVyIG5ldHdv cmsgYWJvdmUgdGhlbSB0aGF0IGlzIHRvcC1vZi1zdGFjay4uLi5saWtlIElQLiANCiAgJm5ic3A7 VGhlcmUgaXMgbm8gY2hvaWNlIGluIHRoZSBtYXR0ZXIgaGVyZS4gJm5ic3A7U28gd2hpbHN0IHdl IG1pZ2h0IHNheSB0aGF0IA0KICBhbiBNUExTIG5ldHdvcmsgaXMgY2FycnlpbmcgYW4gRTEgUFcg dGhlIEUxIGVudGl0eSBtdXN0IGluIHR1cm4gYmUgY2FycnlpbmcgDQogIHNvbWUgb3RoZXIgdG9w LW9mLXN0YWNrIG5ldHdvcmsgKGxpa2UgSVAgb3IgUFNUTiksIGVsc2UgaXQgaXMgc2VydmluZyBu byANCiAgdWx0aW1hdGUgcHVycG9zZS48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7PC9G T05UPiA8QlI+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6 ZT0yPk5vdyBpbiBvcmRlciB0byB0cmFuc21pdCBpbmZvcm1hdGlvbiANCiAgb3ZlciBnZW9ncmFw aGljIGRpc3RhbmNlIHdlIG11c3QgbW9kdWxhdGUgYW4gRU0gd2F2ZSBvbiBzb21lIA0KICBtZXRh bGxpYy9vcHRpY2FsL3JhZGlvIG1lZGlhLi4uLnRoaXMgaXMgdGhlIGJvdHRvbS1vZi1zdGFjayBz ZWN0aW9uIGxheWVyLiANCiAgJm5ic3A7VGhlc2UgYXJlIGhpZ2ggYml0IHJhdGUgdHJhbnNwb3J0 IHBpcGVzIHdob3NlIGZ1bmN0aW9uIGlzIHRvIHByb3ZpZGUgDQogIHRyYW5zcGFyZW50ICh3aGlj aCBJIGhhdmUgZGVmaW5lZCBwcmV2aW91c2x5KSB0cmFuc3BvcnQgdG8gd2hhdGV2ZXIgY2xpZW50 IA0KICBsYXllcnMgbmV0d29ya3Mgc2l0IGFib3ZlIHRoZW0uLi4uYW5kIHdoZXJlLCBhcyBJIG5v dGVkIGFib3ZlLCB0aGVyZSBNVVNUIGJlIGEgDQogIHRvcC1vZi1zdGFjayBuZXR3b3JrIHByZXNl bnQgYXMgdGhlIHVsdGltYXRlIGxheWVyIG5ldHdvcmsgY2xpZW50IGVsc2UgdGhlcmUgDQogIGlz IG5vdCBleHRlcm5hbCBwYXJ0eSBjb21tdW5pY2F0aW9uIHBvc3NpYmxlLjwvRk9OVD4gPEJSPjxG T05UIA0KICBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBN UyIgY29sb3I9IzgwMDAwMCBzaXplPTI+U28gDQogIHdoZW4gd2UgY29ubmVjdCB0b2dldGhlciAy IHRvcC1vZi1zdGFjayBuZXR3b3JrcyB3ZSBkbyBzbyBhdCBhIHNlY3Rpb24gbGF5ZXIgDQogIHdo aWNoIGlzIGludmFyaWFibHkgY2FycnlpbmcgYSB2ZXJ5IGxhcmdlIGFnZ3JlZ2F0ZSBvZiBhcHBs aWNhdGlvbnMuLi4uLmFuZCBvZiANCiAgY291cnNlIHRoZXNlIGFwcGxpY2F0aW9ucyBjYW4gYmUg YSB0aW1lIHZhcnlpbmcgbWl4IG9mIG1lc3NhZ2UvZmlsZS9zdHJlYW0gDQogIGNhc2VzIHdpdGgg YSBzZXQgb2YgdW5rbm93biAodG8gdGhlIHNlY3Rpb24gbGF5ZXIpIGltcG9ydGFuY2UncyAoZXJn byB3aHkgDQogIHRyYW5zcGFyZW5jeSBpcyBhbiBlc3NlbnRpYWwgcmVxdWlyZW1lbnQgaW4gdHJh bnNwb3J0IG5ldHdvcmtzKS48L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9O VD4gPEJSPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9 Mj5UaGUgcmVhbCBFLU5OSXMgKHdoaWNoIGNvbnNpZGVycyBib3RoIERQIGFuZCBDUCBjb21wb25l bnRzLi4uLndlIG5ldmVyIA0KICB1c3VhbGx5IHBlZXIgdGhlIE1QLCBhbmQgd2UgcmVzdHJpY3Qg dGhlIHNjb3BlIG9mIHRoZSBDUCkgZXhpc3QgaW4gdGhlIA0KICB0b3Atb2Ytc3RhY2sgbGF5ZXIg bmV0d29yay4gJm5ic3A7VGhlIHNlY3Rpb24gbGF5ZXIgaW50ZXJjb25uZWN0IGlzIGEgZHVtYiBE UCANCiAgcGlwZS4uLml0IGp1c3Qgc2hpZnRzIGJpdHMgdHJhbnNwYXJlbnRseSBhbmQgbWFpbnRh aW5zIHRoZWlyIG9yZGVyaW5nLiANCiAgJm5ic3A7VGhlcmUgaXMgbm8gY29uY2VwdCBvZiBDUCAo b3IgTVApIHBlZXJpbmcgb24gdGhlc2UgYm90dG9tLW9mLXN0YWNrIA0KICBzZWN0aW9uIGxheWVy IGludGVyY29ubmVjdHMuPC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgDQog IGNvbG9yPSM4MDAwMDAgc2l6ZT0yPkFzaWRlPSZndDsgSW4gc29tZSBjb3VudHJpZXMgdGhlc2Ug aW50ZXJjb25uZWN0cyBoYXZlIHRvIA0KICBiZSBjYXJlZnVsbHkgc3BlY2lmaWVkIGluIG9yZGVy IHRvIGRpc3Rpbmd1aXNoIHJlZ3VsYXRlZCBhbmQgdW5yZWd1bGF0ZWQgDQogIHNlcnZpY2VzLi4u Li5zbyB0aGVyZSBhcmUgaW1wb3J0YW50IGxlZ2FsL2NvbW1lcmNpYWwgY29uc2lkZXJhdGlvbnMg aGVyZSwgaXQgDQogIGlzIG5vdCBzaW1wbHkgYSB0ZWNobmljYWwgaXNzdWUuPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gDQogIDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5z IE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5XZSBjYW4gb2YgY291cnNlIGNyZWF0ZSANCiAgRS1O TklzIGluIG5vbiB0b3Atb2Ytc3RhY2sgbGF5ZXIgbmV0d29ya3MgKHdlIGNhbiBkbyBtYW55IHRo aW5ncyB0aGF0IGFyZSBub3QgDQogIHVzZWZ1bCkuICZuYnNwO1NvIGxldHMgYXNzdW1lIHdlIGRv IHRoaXMuLi4uLmFuZCBsZXRzIGFzc3VtZSB3ZSBjaG9vc2UgTVBMUyANCiAgc2luY2UgeW91IG1l bnRpb24gdGhpcyBpbiB0aGUgbWFpbCBiZWxvdy4gPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6ZT0z PiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgc2l6ZT0yPk5vdyANCiAgaG93IGRvIGV4dGVybmFsIHBhcnRpZXMgd2hvIHdpc2ggdG8gY29t bXVuaWNhdGUgaW50ZXJmYWNlIHdpdGggdGhpcyBNUExTIA0KICBuZXR3b3JrPyAmbmJzcDtDYW4g eW91IHN1cHBvcnQgYWxsIHR5cGVzIG9mIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25z IA0KICAqZGlyZWN0bHkqIGludG8gTVBMUz8gJm5ic3A7SW4gcHJpbmNpcGxlIHlvdSBjb3VsZCBp ZiB5b3UgYWxsb3dlZCBNUExTIHRvIGhhdmUgDQogIGVuZCBzeXN0ZW0gYXBwbGljYXRpb24gYWRh cHRhdGlvbnMgc3VjaCBhcyBVRFAvVENQL1JUUCBvciB0aGUgbGlrZS4gJm5ic3A7QnV0IA0KICB0 aGVzZSBkb24ndCBleGlzdCB0b2RheSwgYW5kIGluIHRoZSBtb3N0IHVzdWFsIGNhc2UgdGhlIE1Q TFMgbmV0d29yayB3aWxsIA0KICBjYXJyeSBhbiBJUCBsYXllciBuZXR3b3JrIGJlY2F1c2UgdGhp cyBjYW4gc3VwcG9ydCB0aGUgbWVzc2FnZS9maWxlL3N0cmVhbSANCiAgYXBwbGljYXRpb25zLjwv Rk9OVD4gPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+V2UgY2FuIGdvIHRocm91Z2ggZXhh Y3RseSB0aGUgc2FtZSANCiAgYW5hbHlzaXMgd2l0aCBhbnkgbmV0d29yayB0aGF0IGlzIG5vdCB0 b3Atb2Ytc3RhY2ssIGVnIEV0aGVybmV0LiAmbmJzcDtBbmQgDQogIHdoZW4geW91IGRvIHRoaXMg d2hhdCB5b3UgcmVhbGlzZSBpcyB0aGF0IGFsdGhvdWdoIHdlIGNhbiBjcmVhdGUgcGVlciANCiAg aW50ZXJ3b3JraW5nIG9mIE1QTFMgKG9yIHdoYXRldmVyKSB0aGlzIGhhcyBub3QgcmVhbGx5IGhl bHBlZCBzaW5jZSB3ZSBtaWdodCANCiAgYXMgd2VsbCBoYXZlIGp1c3QgdGVybWluYXRlZCB0aGUg TVBMUyBuZXR3b3JrIGFuZCBwYXNzZWQgdGhlIElQIGxheWVyIA0KICBhY3Jvc3MuPC9GT05UPiA8 QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9IkNvbWljIFNhbnMg TVMiIA0KICBjb2xvcj0jODAwMDAwIHNpemU9Mj5Ob3cgdGhlIGFib3ZlIGJlY29tZXMgZXZlbiBt b3JlIHN0cmlraW5nIGluIGl0cyANCiAgaW1wb3J0YW5jZSBpZiB5b3UgY29uc2lkZXIgcGVlciBp bnRlcndvcmtpbmcgb2YgMiBkaWZmZXJlbnQgbm9uIHRvcC1vZi1zdGFjayANCiAgbmV0d29ya3Mu Li4ubGV0cyBwaWNrIE1QTFMgYW5kIEV0aGVybmV0IGJlY2F1c2UgdGhhdCBpcyB3aGF0IGlzIG9m dGVuIA0KICBtZW50aW9uZWQuICZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8 L0ZPTlQ+IDxCUj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBz aXplPTI+V2hhdCB3ZSBoYXZlIHRvIGRvIG5vdyBhdCB0aGUgRS1OTklzIA0KICBiZXR3ZWVuIEV0 aGVybmV0IGFuZCBNUExTIGlzIGdvIHRocm91Z2ggZWFjaCBEUCBhbmQgQ1AgY29tcG9uZW50IGFu ZCBkbyBhIA0KICAncHJvdG9jb2wgY29udmVyc2lvbicgZXhlcmNpc2Ugd2hlcmUgcmVxdWlyZWQu Li4uLi5hbmQgdGhlIGZpcnN0IHByb2JsZW0geW91IA0KICB3aWxsIGVuY291bnRlciBpcyB0aGF0 IHRoZXJlIHdpbGwgYmUgbG90cyBvZiBmdW5jdGlvbmFsIG1pc21hdGNoLiANCiAgJm5ic3A7TW9y ZW92ZXIgaWYgb25lIG9yIGJvdGggb2YgdGhlIG5ldHdvcmtzIGNhbiBzdXBwb3J0IG11bHRpcGxl IENQIHR5cGVzIA0KICBsaWtlIE1QTFMgY2FuLCBlZyBSU1ZQLVRFIHNpZ25hbGxpbmcsIExEUCBz aWduYWxsaW5nLCBCR1A0ICdzaWduYWxsaW5nJywgT1NQRiANCiAgcm91dGluZywgSVMtSVMgcm91 dGluZy4uLi4uYW5kIEkgY291bGQgbGlzdCBzaW1pbGFyIGZvciBFdGhlcm5ldC4uLi4ueW91IGFy ZSANCiAgZ29pbmcgdG8gaGF2ZSB0byBjb25zaWRlciBlYWNoIHBhaXJpbmcgY2FzZSBpbiB0dXJu LiAmbmJzcDtBIGxvdCBvZiANCiAgd29yay48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7 PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgDQogIGNvbG9yPSM4MDAwMDAg c2l6ZT0yPkFuZCB3aGVuIHlvdSBoYXZlIGRvbmUgYWxsIHRoaXMgeW91IGFzayB0aGUgcXVlc3Rp b24gDQogICd3aGF0IGlzIGl0IHRoYXQgY2FycmllcyB0aGUgcmVhbCBleHRlcm5hbCBtZXNzYWdl L2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyBpbiANCiAgdGhlIERQIGhlcmU/Jy4uLi4uLi5hbmQg bm93IHlvdSBmaW5kIG5vIG5hdGl2ZSBzdXBwb3J0IGZvciB0aGVzZSBpbiBNUExTIG9yIA0KICBF dGhlcm5ldCwgYnV0IHdoYXQgd2UgZG8gZmluZCBpcyB0aGF0IGJvdGggb2YgdGhlbSBhcmUgY2Fy cnlpbmcgSVAgYmVjYXVzZSANCiAgdGhpcyBkb2VzIHN1cHBvcnQgdGhlIGV4dGVybmFsIGFwcGxp Y2F0aW9ucy4gJm5ic3A7Tm93IGF0IHRoaXMgcG9pbnQgd2UgaGF2ZSANCiAgZGlzY292ZXJlZCB3 aGF0IGlzIHRoZSBjb21tb24gdGhpbmcgYmV0d2VlbiBNUExTIGFuZCBFdGhlcm5ldC4uLi5pdCBp cyB0aGUgDQogIHRvcC1vZi1zdGFjayBJUCBsYXllciBuZXR3b3JrLiAmbmJzcDtBbmQgc28gd2Ug dWx0aW1hdGVseSByZWFsaXNlIHdlIGNvdWxkIA0KICBoYXZlIHNhdmUgb3Vyc2VsdmVzIGEgbG9h ZCBvZiB1bm5lY2Vzc2FyeSB3b3JrIGJ5IHNpbXBseSB0ZXJtaW5hdGluZyB0aGUgTVBMUyANCiAg YW5kIEV0aGVybmV0IGxheWVyIG5ldHdvcmsgYXQgdGhlIGludGVyd29ya2luZyBwb2ludCBhbmQg anVzdCBwYXNzZWQgdGhlIElQIA0KICBsYXllciBuZXR3b3JrIGFjcm9zcy48L0ZPTlQ+IDxCUj48 Rk9OVCBzaXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMg TVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPlNvcnJ5IEkndmUgaGFkIHRvIGdvIHRocm91Z2ggYWxs IA0KICB0aGlzIHlldCBhZ2FpbiAoZXNwIGZvciBhbGwgdGhlIGZvbGtzIHRoYXQgaGF2ZSBhbHJl YWR5IHVuZGVyc3Rvb2QgdGhlIHBvaW50KSANCiAgYnV0IEkgZG8gaG9wZSBpdHMgY2xlYXIgbm93 IGFuZCB3ZSBjYW4gcHV0IHRoaXMgaXNzdWUgdG8gYmVkLjwvRk9OVD4gPEJSPjxGT05UIA0KICBz aXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9 IzgwMDAwMCANCiAgc2l6ZT0yPnJlZ2FyZHMsIE5laWw8L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8L0ZP TlQ+PEJSPjxCUj4NCiAgPEhSPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8 L0I+IHN1Lmh1aUB6dGUuY29tLmNuIA0KICBbbWFpbHRvOnN1Lmh1aUB6dGUuY29tLmNuXSA8Qj48 QlI+U2VudDo8L0I+IDI5IEFwcmlsIDIwMDkgMDM6MjI8Qj48QlI+VG86PC9CPiANCiAgSGFycmlz b24sTixOZWlsLENYTSBSPEI+PEJSPkNjOjwvQj4gYWRyaWFuQG9sZGRvZy5jby51azsgDQogIE5p dmVuLWplbmtpbnMsQixCZW4sRE1GIFI7IGhoZWx2b29ydEBjaGVsbG8ubmw7IG1wbHMtdHBAaWV0 Zi5vcmc7IA0KICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8Qj48QlI+U3ViamVjdDo8L0I+IOet lOWkjTogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgDQogIEFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpPC9GT05UPjxGT05UIA0KICBzaXplPTM+ PEJSPjwvRk9OVD48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48QlI+SGkgTmVpbCw8 L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mz4gPEJSPjwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYg c2l6ZT0yPjxCUj7igJhpdCBpcyBxdWl0ZSBjbGVhciBmcm9tIGEgDQogIHNpbXBsZSB0ZWNobmlj YWwgYW5hbHlzaXMgdGhhdCBhbnkgbm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIGhhcyBubyBuZWVk IGZvciANCiAgRS1OTkkgcGVlci1wYXJ0aXRpb24gd29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBv cGVyYXRpbmcgcGFydGllcy7igJk8L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mz4gPEJSPjwvRk9OVD48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5JIGNhbm5vdCBhZ3JlZSB0aGlzIA0KICBz dGF0ZW1lbnQuIDxCUj5Gb3IgZXhhbXBsZSwgdGhlcmUgYXJlIHR3byBJUCBuZXR3b3JrcyBiZWxv bmdpbmcgdG8gdHdvIA0KICBvcGVyYXRvcnMsIGEgRTEgaXMgdHJhbnNwb3J0ZWQgZnJvbSBBIG5l dHdvcmsgdG8gQiBuZXR3b3JrIChlLmcuIA0KICBFMW92ZXJQV292ZXJJUCApLCBJUCBwYWNrZXQo bm90IEUxKSBwYXNzIGFjcm9zcyBmb3JtIEEgdG8gQiBhdCBib3JkZXIgbm9kZSwgc28gDQogIHRo ZXJlIGlzIGEgRS1OTkkgYmV0d2VlbiB0aGVzZSAmbmJzcDt0d28gSVAgbmV0d29yay4gSW4gdGhp cyBjYXNlLCBpcyBJUCBhIA0KICB0b3Atb2Ytc3RhY2sgbmV0d29yaz88L0ZPTlQ+PEZPTlQgc2l6 ZT0zPiA8L0ZPTlQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICBzaXplPTI+PEJSPk5vdyBsZXQg dXMgcmVwbGFjZSBJUCBuZXR3b3JrcyBieSBNUExTLVRQIG5ldHdvcmtzIChlLmcuIA0KICBFMW92 ZXJQV292ZXJNUEwtVFApLCBNUExTLVRQIG5ldHdvcmsgaXMgYXQgc2FtZSBwb3NpdGlvbiBpbiB0 aGUgc3RhY2sgYXMgSVAgDQogIG5ldHdvcmsgaXMsIHdoeSBjYW4gSVAgbmV0d29yayBoYXZlIEUt Tk5JIGJ1dCBNUExTLVRQIGNhbm5vdD88L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mz4gPEJSPjwvRk9O VD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5SZWdhcmQsPC9GT05UPjxGT05UIA0K ICBzaXplPTM+IDwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5TdWh1aTwv Rk9OVD48Rk9OVCBzaXplPTM+IA0KICA8QlI+PEJSPjwvRk9OVD4NCiAgPFRBQkxFIHdpZHRoPSIx MDAlIj4NCiAgICA8VEJPRFk+DQogICAgPFRSIHZBbGlnbj10b3A+DQogICAgICA8VEQgd2lkdGg9 IjI2JSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgICBzaXplPTE+PEI+Jmx0O25laWwu Mi5oYXJyaXNvbkBidC5jb20mZ3Q7PC9CPiA8QlI+5Y+R5Lu25Lq6OiANCiAgICAgICAgJm5ic3A7 bXBscy10cC1ib3VuY2VzQGlldGYub3JnPC9GT05UPjxGT05UIHNpemU9Mz4gPC9GT05UPg0KICAg ICAgICA8UD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPjIwMDktMDQtMjggMTQ6NDM8L0ZP TlQ+PEZPTlQgc2l6ZT0zPiANCiAgICAgICAgPC9GT05UPjwvUD4NCiAgICAgIDxURCB3aWR0aD0i NzMlIj48QlI+DQogICAgICAgIDxUQUJMRSB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgPFRCT0RZ Pg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFREIHdpZHRoPSI2JSI+ DQogICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9MT7mlLbku7bkuro8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICA8VEQgd2lkdGg9IjkzJSI+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgICAgICAgICBzaXplPTE+Jmx0O2hoZWx2b29y dEBjaGVsbG8ubmwmZ3Q7LCAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDssIA0KICAgICAgICAg ICAgICAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7PC9GT05UPjxGT05UIHNp emU9Mz4gPC9GT05UPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFRE Pg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTE+5oqE6YCBPC9GT05UPjwvRElWPg0KICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTE+bXBscy10cEBpZXRmLm9yZzwvRk9OVD48Rk9OVCANCiAgICAgICAgICAg ICAgc2l6ZT0zPiA8L0ZPTlQ+DQogICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAg ICA8VEQ+DQogICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9MT7kuLvpopg8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICA8VEQ+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9MT5SZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyANCiAgICAgICAg ICAgICAgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoICZuYnNwOyAmbmJz cDsgJm5ic3A7IA0KICAgICAgICAgICAgICAmbmJzcDtyZXF1aXJlbWVudHMpPC9GT05UPjwvVFI+ PC9UQk9EWT48L1RBQkxFPjxCUj48QlI+DQogICAgICAgIDxUQUJMRSB3aWR0aD0iMTAwJSI+DQog ICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAg PFREIHdpZHRoPSI1MCUiPg0KICAgICAgICAgICAgPFREIHdpZHRoPSI1MCUiPjwvVFI+PC9UQk9E WT48L1RBQkxFPjxCUj48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PEZPTlQgDQogIHNpemU9Mz48 QlI+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTI+PFRUPjxCUj5IdXViIHdyb3RlIDI3IEFwcmlsIDIw MDkgDQogIDIyOjI3PEJSPiZndDsgPEJSPiZndDsgSGkgQWRyaWFuLDxCUj4mZ3Q7IDxCUj4mZ3Q7 IFlvdSB3cm90ZTo8QlI+Jmd0OyA8QlI+Jmd0OyANCiAgJmd0OyBJc24ndCB0aGUgc29sdXRpb24g aGVyZSB0aGUgc2FtZSBhcyB0aGUgb25lIEkgcHJvcG9zZWQgZm9yICJUQ00iPzxCUj4mZ3Q7IA0K ICA8QlI+Jmd0OyBJbmRlZWQsIGFuZCB0aGF0IHdlIGRvIG5vdCBoYXZlIHRvIGFyb3VuZCBpbiBj aXJjbGVzIGFib3V0IA0KICBUQ00uPEJSPiZndDsgPEJSPiZndDsgSG93IGFib3V0OjxCUj4mZ3Q7 IHRoZSByZXF1aXJlbWVudCBpcyB0aGF0IGEgc2VydmVyIA0KICBsYXllciBzaGFsbCBpbmZvcm0g aXRzIGNsaWVudHM8QlI+Jmd0OyB0aGF0IGl0IGhhcyBkZXRlY3RlZCBhIHNlcnZpY2UgDQogIGlu dGVydXB0aW9uLCB0aGlzIHRvIGVuc3VyZSB0aGF0PEJSPiZndDsgdGhlIGNsaWVudHMgY2FuIGlu aGliaXQgKHVubmVjZXNzYXJ5KSANCiAgYWxhcm1zLjxCUj48QlI+Tkg9Jmd0OyBUaGlzIG9ubHkg YXBwbGllcyBpZiB0aGUgY2xpZW50L3NlcnZlciBiaW5kaW5nIGlzIA0KICBmaXhlZC4gJm5ic3A7 QW5kIG9mPEJSPmNvdXJzZSB3YXkgYmFjayBpbiB0aGUgNzBzIHdoZW4gYmluYXJ5IGFsbCAxcyBw b3BwZWQgDQogIG91dCBvZiB0aGUgZmFpbGVkPEJSPlRUTCBsb2dpYyBpbnRvIHRoZSBQREggdHJh bnNwb3J0IGhpZXJhcmNoeSB0aGlzIHdhcyB0cnVlLiANCiAgJm5ic3A7QWxzbzogbm88QlI+bGFi ZWxzIGhlcmUgYW5kIG5vIGNsaWVudCB0cmFmZmljIHVuaXRzIHRvIGNyZWF0ZS4gJm5ic3A7IA0K ICA8QlI+PEJSPldoZXJlIHRoZSBjbGllbnQgY2FuIGR5bmFtaWNhbGx5IGJlIHJlLXJvdXRlZCBp biByZXNwb25zZSB0byBhIA0KICBzZXJ2ZXI8QlI+ZmFpbHVyZSB0aGUgcHJvcG9zZWQgdGV4dCBp cyBub3QgdmFsaWQuICZuYnNwO0l0IGlzIGFsc28gbm90IA0KICBuZWNlc3NhcnkgdGhhdDxCUj50 aGUgc2VydmVyIGhhcyB0byBrZWVwIHRyYWNrIG9mIHdoZXJlIGl0cyBjbGllbnQgdHJhZmZpYyAN CiAgcm91dGluZ3MgaGF2ZTxCUj5tb3ZlZCB0by4gJm5ic3A7Rm9yIGV4YW1wbGUsIGlmIEkgY3Jl YXRlIHRoZSB0b3BvbG9neSBvZiBhbiANCiAgSVAgbGF5ZXIgbmV0d29yazxCUj53aXRoIGxpbmtz IHByb3ZpZGVkIGJ5IFNESCwgRXRoZXJuZXQsIEFUTSwgT1ROLCBldGMgDQogIHNlcnZlcnMsIGFu ZCBlYWNoIG9mPEJSPnRoZXNlIHNlcnZlciBsaW5rcyBpcyBwcm92aWRlZCBieSBhIGRpZmZlcmVu dCANCiAgb3BlcmF0b3IsIHRoZW4gd2h5IHNob3VsZDxCUj50aGUgc2VydmVycyBuZWVkIGhhdmUg a25vd2xlZGdlIG9mIHdoZXJlIHRoZSBJUCANCiAgZmxvd3MgaGF2ZSBtb3ZlZCB0byBpbjxCUj5y ZXNwb25zZSB0byBhIHNlcnZlciBsYXllciBmYWlsdXJlIHdoZW4gdGhlIG5ldyANCiAgcm91dGVz IGhhdmUgYmVlbjxCUj5jYWxjdWxhdGVkIGJ5IHRoZSBJR1AgaW4gdGhlIElQIGxheWVyIG5ldHdv cms/ICZuYnNwO0kgY2FuIA0KICBhcHBseSB0aGUgc2FtZTxCUj5sb2dpYyB0byBhbiBTVkMtYmFz ZWQgY28tcHMvY28tY3MgbW9kZSBjbGllbnQuLi4uaW5kZWVkIHRoZSANCiAgY28tY3MgbW9kZTxC Uj5QU1ROIGlzIGxpa2UgdGhpcy48QlI+PEJSPlRoZXNlIG9ic2VydmF0aW9ucyBtYWtlIGl0IHF1 aXRlIGNsZWFyIA0KICB0byBtZSBhdCBsZWFzdCB0aGF0IGp1c3QgY29weWluZzxCUj50aGUgQUlT IGJlaGF2aW91ciBvZiB0aGUgb2xkIHRyYW5zcG9ydCANCiAgaGllcmFyY2hpZXMgdGhhdCBoYWQg Zml4ZWQ8QlI+Y2xpZW50L3NlcnZlciByZWxhdGlvbnNoaXBzIGlzIG5vdCBhIHNlbnNpYmxlIA0K ICB0aGluZyB0byBkby48QlI+PEJSPklNTyB0aGUgb25seSBlc3NlbnRpYWwgRFAgT0FNIHJlcXVp cmVtZW50IGlzIHRoYXQgZWFjaCANCiAgbGF5ZXIgbmV0d29yazxCUj5zaG91bGQgYmUgc2VsZi1z dWZmaWNpZW50IHdydCBPQU0gYW5kIG5vdCByZWx5IG9uIGFueSBzZXJ2ZXIgDQogIGxheWVyPEJS PnByaW1pdGl2ZXMgYmVpbmcgcGFzc2VkIHVwd2FyZHMuPEJSPjxCUj5Nb3Jlb3ZlciwgaXQgc2hv dWxkIGFsc28gYmUgDQogIG5vdGVkIHRoYXQgKGkpIHRoZSBkZWZlY3RzIHRoYXQgY2FuIG9jY3Vy IGluPEJSPmVhY2ggb2YgdGhlIDMgbmV0d29yayBtb2RlcyANCiAgYXJlIG5vdCB0aGUgc2FtZSBh bmQgKGlpKSB0aGVpciBPQU08QlI+cmVxdWlyZW1lbnRzIGFyZSBub3QgaWRlbnRpY2FsbHkgdGhl IA0KICBzYW1lLiBTbyB0aGUgT0FNIHRoYXQgYXBwbGllcyB0bzxCUj50aGUgY2wtcHMgbW9kZSAo ZWcgSVApIGlzIG5vdCB0aGUgc2FtZSBhcyANCiAgdGhlIE9BTSB0aGF0IGFwcGxpZXMgdG8gdGhl PEJSPmNvLXBzIG1vZGUgKGVnIE1QTFMtVFApIGFuZCBuZWl0aGVyIG9mIHRoZXNlIGlzIA0KICBp ZGVudGljYWxseSB0aGUgc2FtZSBhczxCUj50aGUgT0FNIHRoYXQgYXBwbGllcyB0byB0aGUgY28t Y3MgbW9kZSAoZWcgDQogIFNESCkuPEJSPjxCUj5Ob3RlIC0gVGhlIG9ubHkgcG9pbnQgYmVpbmcg Y29uc2lkZXJlZCBoZXJlIGlzIHRoZSByZWFsIGNsaWVudCANCiAgYW5kPEJSPnNlcnZlciB0cmFm ZmljIHJlbGF0aW9uc2hpcC4gJm5ic3A7VGhlIGNyZWF0aW9uIG9mIGEgaGllcmFyY2h5IG9mIA0K ICBUQ008QlI+c3VibGF5ZXJzIGlzIGEgc2VwYXJhdGUgdG9waWMuICZuYnNwO0Z1cnRoZXIsIGl0 IGlzIHF1aXRlIGNsZWFyIGZyb20gYSANCiAgc2ltcGxlPEJSPnRlY2huaWNhbCBhbmFseXNpcyB0 aGF0IGFueSBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5vIG5lZWQgDQogIGZvcjxCUj5F LU5OSSBwZWVyLXBhcnRpdGlvbiB3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50IG9wZXJhdGluZyBw YXJ0aWVzLiANCiAgJm5ic3A7U288QlI+dGhpcyBpcyBhbHNvIGEgc2VwYXJhdGUgaXNzdWUuICZu YnNwO0hvd2V2ZXIsIEkgcHJvcG9zZSB0aGF0IHRoaXMgDQogIGxhdHRlcjxCUj5wb2ludCBiZSBj YXB0dXJlZCBpbiB0aGUgTVBMUy1UUCByZXF1aXJlbWVudHMgZHJhZnQgZHVlIHRvIA0KICBpdHM8 QlI+c3RhbmQtYWxvbmUgYW5kIGdlbmVyaWMgaW1wb3J0YW5jZSwgaWUgdGhpcyBhcHBsaWVzIHRv IG1vcmUgdGhhbiBqdXN0IA0KICBEUDxCUj5PQU0uICZuYnNwO0JlbiBjYW4geW91IHBsZWFzZSBj b25zaWRlciB0aGlzIHBvaW50IGFzL3doZW4gdGhlIA0KICBNUExTLVRQPEJSPnJlcXVpcmVtZW50 cyBkcmFmdCBpcyB1cGRhdGVkLjxCUj48QlI+cmVnYXJkcywgTmVpbDxCUj48QlI+Jmd0OyANCiAg Q2hlZXJzLCBIdXViLjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj5tcGxzLXRwIA0KICBtYWlsaW5nIA0KICBsaXN0PEJSPm1wbHMtdHBAaWV0Zi5v cmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPC9UVD48 L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9 Mz48VFQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08QlI+WlRFIA0KICBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSANCiAgcHJvcGVydHkgb2YgdGhl IHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQogIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSANCiAgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0KICBvdGhlcnMuPEJSPlRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0K ICBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgDQogIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCiAgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IA0KICB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuPEJSPlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIA0KICBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48QlI+ PC9UVD48L0ZPTlQ+PEJSPjxCUj48UFJFPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3Vy aXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJv cGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZu YnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlk ZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5i c3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQm bmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5i c3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkm bmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5i c3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJz cDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJz cDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90 aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2Fn ZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVl biZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZu YnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9QUkU+PC9CTE9D S1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C9C8B4.5472C714-- From maarten.vissers@huawei.com Wed Apr 29 05:04:12 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C948C3A6C77 for ; Wed, 29 Apr 2009 05:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.54 X-Spam-Level: X-Spam-Status: No, score=0.54 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqW2qR48tdf1 for ; Wed, 29 Apr 2009 05:04:10 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D8A0E3A6963 for ; Wed, 29 Apr 2009 05:04:09 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIV007AT2WXVC@szxga02-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 20:05:21 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIV00FCG2WW53@szxga02-in.huawei.com> for mpls-tp@ietf.org; Wed, 29 Apr 2009 20:05:20 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIV00KXW2W7U0@szxml02-in.huawei.com>; Wed, 29 Apr 2009 20:05:20 +0800 (CST) Date: Wed, 29 Apr 2009 14:04:58 +0200 From: Maarten Vissers In-reply-to: To: 'Alexander Vainshtein' Message-id: <000901c9c8c2$bc4f8b30$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_NVQ0wHtv38s4AL3Vo9Xe5w)" Thread-index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAmohI7AAURASA= Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 12:04:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NVQ0wHtv38s4AL3Vo9Xe5w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sasha, See inline.. _____ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: woensdag 29 april 2009 11:37 To: Igor Bryskin; Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Maarten, Neil and all, I may be completely wrong, but why should the server (MPLS-TP transport path) be aware of any specific clients that use it, be it a the path termination point or in the intermediate node? [mv] The MPLS-TP LSP itself is not aware of any of its clients. It is the LSP-to-client adaptation function that is aware of the clients of the LSP. And this adaptation function has to be aware of the clients as it has to demultiplex and decapsulate the client signals from the LSP. To the best of my understanding, 1. MPLS (not TP) data plane architecture does not require this: * As long as the server LSP is not terminated, LSR does not looks only on the top label [mv] correct. * Once the server LSP is terminated (which, IMO, is equivalent to the top label being popped), switching is done on the next label without "keeping in mind" the popped label * [mv] correct. This next label identifies a client and the adaptation function which extracts this client is aware of the client type; e.g. LSP, PW, EVC,.. 2. The MPLS-TP requirements draft does not contain an appropriate requirement of such awareness. On the contrary, Requirement 25A seems to make such awareness undesirable. [mv] You have to distinguish between the layer network and the interlayer adaptation function which interconnects layer networks. Within the layer network (i.e. within the LSP trails) there is no client awareness. Within the adaptation functions at the end of the LSP trail there is complete client awareness. 3. In SONET/SDH the server is not aware of any specific clients: if a server failure is detected, its consequent action spreads "all ones" over all potential clients. But this is somewhat difficult to imitate in packet networks [mv] If you look at OTN equipment standard G.798, you will see that client specific AIS is inserted in the adaptation sink functions. AIS is not longer inserted in the termination sink functions in G.798 (see e.g. 14.2.1.2/G.798). This change with respect to AIS insertion in termination sink functions was introduced first in the ATM equipment specifications (I.732), which followed in time the SDH equipment specification (G.783). In the case of Ethernet, you also find that the ETHx_FT_Sk function does not insert AIS; AIS is inserted by the next adaptation sink function (G.8021). 4. In ATM, the server (VPC) termination point is, indeed, fully aware of all its clients (VPC). But this awareness is dictated by the ATM data plane where VPI is link-local and VCI is link- and VPI-local. [mv] In ATM the VPI and VCI are "per interface" labels. In MPLS-TP the Labels should also be per interface labels. I.e. when an LSP to EVC adaptation sink function receives a packet with an EVC (i.e. PW) label value that is not registered it has to discard this packet and increment an unexpected packet counter. Not discarding such packets with unregistered label values on a port will introduce a security risk in a transport network. In other words, IMHO and FWIW, server awareness of its clients (or lack thereof) is dictated by the data plane specifics. As long as we state that MPLS-TP data plane is the same as that of MPLS, such awareness does not exist in MPLS-TP. And I do not think that it is correct to derive data plane requirements from OAM concepts. [mv] MPLS-TP dataplane should use the per-interface label space. Then there is no problem, as all active client labels are registered on every port. REgards, Maarten Did I miss something important here? Regards, and thanks in advance, Sasha ________________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin [IBryskin@advaoptical.com] Sent: Tuesday, April 28, 2009 6:04 PM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connection less, whereas some other server trail(s) will learn that they serve from now on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation. There is no difference with what we do today in SDH and OTN. A client/server relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generation is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > ================================================================ > > http://www.van-helvoort.eu/ > > ================================================================ > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_NVQ0wHtv38s4AL3Vo9Xe5w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Sasha, See inline.. From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: woensdag 29 april 2009 11:37 To: Igor Bryskin; Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Igor, Maarten, Neil and all, I may be completely wrong, but why should the server (MPLS-TP transport path) be aware of any specific clients that use it, be it a the path termination point or in the intermediate node? [mv] The MPLS-TP LSP itself is not aware of any of its clients. It is the LSP-to-client adaptation function that is aware of the clients of the LSP. And this adaptation function has to be aware of the clients as it has to demultiplex and decapsulate the client signals from the LSP. To the best of my understanding, MPLS (not TP) data plane architecture does not require this: As long as the server LSP is not terminated, LSR does not looks only on the top label   [mv] correct. Once the server LSP is terminated (which, IMO, is equivalent to the top label being popped), switching is done on the next label without "keeping in mind" the popped label [mv] correct. This next label identifies a client and the adaptation function which extracts this client is aware of the client type; e.g. LSP, PW, EVC,..   The MPLS-TP requirements draft does not contain an appropriate requirement of such awareness. On the contrary, Requirement 25A seems to make such awareness undesirable.  [mv] You have to distinguish between the layer network and the interlayer adaptation function which interconnects layer networks. Within the layer network (i.e. within the LSP trails) there is no client awareness. Within the adaptation functions at the end of the LSP trail there is complete client awareness. In SONET/SDH the server is not aware of any specific clients: if a server failure is detected, its consequent action spreads "all ones" over all potential clients. But this is somewhat difficult to imitate in packet networks  [mv] If you look at OTN equipment standard G.798, you will see that client specific AIS is inserted in the adaptation sink functions. AIS is not longer inserted in the termination sink functions in G.798 (see e.g. 14.2.1.2/G.798). This change with respect to AIS insertion in termination sink functions was introduced first in the ATM equipment specifications (I.732), which followed in time the SDH equipment specification (G.783). In the case of Ethernet, you also find that the ETHx_FT_Sk function does not insert AIS; AIS is inserted by the next adaptation sink function (G.8021). In ATM, the server (VPC) termination point is, indeed, fully aware of all its clients (VPC). But this awareness is dictated by the ATM data plane where VPI is link-local and VCI is link- and VPI-local. [mv] In ATM the VPI and VCI are "per interface" labels. In MPLS-TP the Labels should also be per interface labels. I.e. when an LSP to EVC adaptation sink function receives a packet with an EVC (i.e. PW) label value that is not registered it has to discard this packet and increment an unexpected packet counter. Not discarding such packets with unregistered label values on a port will introduce a security risk in a transport network. In other words, IMHO and FWIW, server awareness of its clients (or lack thereof) is dictated by the data plane specifics. As long as we state that MPLS-TP data plane is the same as that of MPLS, such awareness does not exist in MPLS-TP. And I do not think that it is correct to derive data plane requirements from OAM concepts. [mv] MPLS-TP dataplane should use the per-interface label space. Then there is no problem, as all active client labels are registered on every port. REgards, Maarten Did I miss something important here? Regards, and thanks in advance,      Sasha ________________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin [IBryskin@advaoptical.com] Sent: Tuesday, April 28, 2009 6:04 PM To: Maarten Vissers; neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil. I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connection less, whereas some other server trail(s) will learn that they serve from now on one connection more. These new client-server relationships are fixed until the next re-routing. Cheers, Igor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Tuesday, April 28, 2009 8:48 AM To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Neil, > However, if the client can dynamically change its routing in response > to link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as the > client) then there is no fixed client/server relationship. I believe there is a fixed client/server relationship also in this case in the network. This relationship is broken when the connection is rerouted. Such reroute will remove the CP/FP and as such will stop the AIS generation. There is no difference with what we do today in SDH and OTN. A client/server relationship is fixed until the point in time that the connection is either teardown or rerouted. When either of the two cases occur, the AIS generation is stopped. Until such action is performed, AIS is generated during signal fail condition period and inserted into the connection. In MPLS-TP we have the requirement that MPLS-TP must be able to operate without control plane. This implies that it will operate without restoration, and that there will not be frequent rerouteing ongoing. Result is that client/server relationships will last until the connection is teardown. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: dinsdag 28 april 2009 10:07 To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Nurit, I believe the reason we need this discussion is that there is an unstated assumption here that the client/server relationship is fixed. However, if the client can dynamically change its routing in response to link failures in its topology (because some server layer network has failed....which may or may not belong to the same operating party as the client) then there is no fixed client/server relationship. Refer to my post earlier today and consider what this means in the case of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client layer network. The key point here is the *routing process* in the client is independent of the server layer network....so there is not a fixed client/server relationship. Further, there is also no requirement for the server to keep track of where its client traffic routings are at any epoch.....indeed why should it in the general case where these are independent layer networks? So the only OAM requirement that is critical is that the OAM of the client and server layer networks are independent. It is thus not sensible to make client layer alarm supression a 'requirement' here...in fact if this is in the OAM requirements then it is technically wrong and should be removed IMO. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - > IL/Hod HaSharon) > Sent: 28 April 2009 08:46 > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > If we agree that the requirement is included, so why do we keep with > the endless discussions on this requirement? > > -----Original Message----- > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Tuesday, April 28, 2009 10:44 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > Adrian Farrel > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport > pathrequirements) > > I think that the requirements are defined in section 2.2.8 of > draft-ietf-mpls-tp-oam-requirements-01 > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > > - IL/Hod HaSharon) > > Sent: Tuesday, April 28, 2009 6:56 AM > > To: hhelvoort@chello.nl; Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transport pathrequirements) > > > > Huub, > > I think that the requirement is to provide a mechanism to suppress > > alarms in the networks, to ensure that alarms that may be > generated by > > client layers as a result of a failure condition in the server layer > > may be suppressed. > > Every thing else is a solution, etc. > > I propose to phrase the requirement appropriately and conclude the > > discussion on this in the context of the requirements (until we are > > getting to the solution phase). > > This requirement is included in the OAM requirement draft. > > Best regards, > > NUrit > > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of ext Huub van Helvoort > > Sent: Tuesday, April 28, 2009 12:27 AM > > To: Adrian Farrel > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectional transport > > path requirements) > > > > Hi Adrian, > > > > You wrote: > > > > > Isn't the solution here the same as the one I proposed for "TCM"? > > > > Indeed, and that we do not have to around in circles about TCM. > > > > How about: > > the requirement is that a server layer shall inform its clients that > > it has detected a service interuption, this to ensure that the > > clients can inhibit (unnecessary) alarms. > > > > Cheers, Huub. > > > > -- > > ================================================================ > >                    http://www.van-helvoort.eu/ > > ================================================================ > > Always remember that you are unique...just like everyone else... > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_NVQ0wHtv38s4AL3Vo9Xe5w)-- From andy.bd.reid@bt.com Wed Apr 29 06:36:56 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D533A6D7D for ; Wed, 29 Apr 2009 06:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[AWL=2.848, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFLyGjrV0FXA for ; Wed, 29 Apr 2009 06:36:55 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E109C3A70DE for ; Wed, 29 Apr 2009 06:36:54 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 14:38:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 14:38:07 +0100 Message-ID: In-Reply-To: <006301c9c891$2cc37570$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AASESoQAA810HA= From: To: X-OriginalArrivalTime: 29 Apr 2009 13:38:16.0008 (UTC) FILETIME=[BFE60C80:01C9C8CF] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:36:56 -0000 Maarten,=20 > Can you list what the "AIS specific configuration" is that we=20 > have to do? > I don't know of any such "AIS specific configuration". Forwarding is a lookup keyed on the label value giving back an outgoing port and a new label value followed by passing of the packet to the port and swapping the label value. AIS insertion is a lookup keyed on a server trail id (if this is not implicit) of a set of label values followed by the creation of packets with these label values followed by either passing the packets to the forwarding engine (if the lookup is of incoming labels) or to output port (if the lookup is of outgoing labels). These are quite different operations even if there are some circumstances when entries may be inserted into each lookup table at the same time - locked as you put it. Also, in circuit switching, AIS does not require any label look up operation. > > For example, consider port mapping (or in ITU-T speak, a degenerate > > subnetwork) where we terminate the section layer on one=20 > interface and=20 > > blindly ship all the packets out on an other interface in a new=20 > > section. >=20 > I am interested to learn in which types of equipment this=20 > occurs, or at which location in a network this occurs. I have=20 > not come across this so far in transport network equipment=20 > designs. I.e.=20 > this seems to be a non-existing case in transport networks. >=20 > I have come across a port-based service. No this is not a port-based service. The Ethernet equivalent would be a two port bridge. The sections are terminated, packets are passed, but there is no bridge learning. Andy Andy Reid Chief Network Services Strategist BT Innovate =20 Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com =20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. From andy.bd.reid@bt.com Wed Apr 29 06:58:45 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AEDA28B56A for ; Wed, 29 Apr 2009 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=2.441, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q939+bH-nc0L for ; Wed, 29 Apr 2009 06:58:44 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 545613A67F3 for ; Wed, 29 Apr 2009 06:58:44 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 14:38:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 14:38:07 +0100 Message-ID: In-Reply-To: <006301c9c891$2cc37570$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AASESoQAA810HA= From: To: X-OriginalArrivalTime: 29 Apr 2009 13:38:16.0008 (UTC) FILETIME=[BFE60C80:01C9C8CF] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:58:45 -0000 Maarten,=20 > Can you list what the "AIS specific configuration" is that we=20 > have to do? > I don't know of any such "AIS specific configuration". Forwarding is a lookup keyed on the label value giving back an outgoing port and a new label value followed by passing of the packet to the port and swapping the label value. AIS insertion is a lookup keyed on a server trail id (if this is not implicit) of a set of label values followed by the creation of packets with these label values followed by either passing the packets to the forwarding engine (if the lookup is of incoming labels) or to output port (if the lookup is of outgoing labels). These are quite different operations even if there are some circumstances when entries may be inserted into each lookup table at the same time - locked as you put it. Also, in circuit switching, AIS does not require any label look up operation. > > For example, consider port mapping (or in ITU-T speak, a degenerate > > subnetwork) where we terminate the section layer on one=20 > interface and=20 > > blindly ship all the packets out on an other interface in a new=20 > > section. >=20 > I am interested to learn in which types of equipment this=20 > occurs, or at which location in a network this occurs. I have=20 > not come across this so far in transport network equipment=20 > designs. I.e.=20 > this seems to be a non-existing case in transport networks. >=20 > I have come across a port-based service. No this is not a port-based service. The Ethernet equivalent would be a two port bridge. The sections are terminated, packets are passed, but there is no bridge learning. Andy Andy Reid Chief Network Services Strategist BT Innovate =20 Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com =20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. From andy.bd.reid@bt.com Wed Apr 29 07:44:41 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAFB28C225 for ; Wed, 29 Apr 2009 07:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=1.836, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iQNl9YSF7E6 for ; Wed, 29 Apr 2009 07:44:38 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 74D293A67F3 for ; Wed, 29 Apr 2009 07:44:33 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 15:45:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 15:45:52 +0100 Message-ID: In-Reply-To: <008601c9c89a$b53aacd0$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AATTltgAA8a1TA= From: To: , X-OriginalArrivalTime: 29 Apr 2009 14:45:54.0521 (UTC) FILETIME=[32F5FC90:01C9C8D9] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:44:41 -0000 Maarten, >From this, you are agreeing the basic operational model. I was trying to be both concise and reasonably general to different maintenance scenarios (and the posting was still pretty long). In the detailed scenario you describe, the distinction between 'proactive' and 'reactive' maintenance is whether the guy wants the alarm raised to him immediately and he will deal with it ahead of any trouble ticket raised by a customer or whether the guy only wants to know the alarm status in front of him at the time the customer raises the trouble ticket. In both cases the 'suppressed' alarm is still needed in the higher level management system. Exact procedures for fault locations will vary, I'm sure, as do the systems available to help. Importantly, there will inevitably be a variety of residual faults which occur which do also sit neatly into prior assumptions of what can go wrong. So fault localisation *must* include procedures to deal with things which do not say 'I am broken, fix me'. What is damaging to the fault localisation process is if there is false information around. Andy =20 Andy Reid Chief Network Services Strategist BT Innovate =20 Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com =20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. =20 > -----Original Message----- > From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 > Sent: 29 April 2009 08:18 > To: Reid,ABD,Andy,CXM R; IBryskin@advaoptical.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated=20 > bidirectionaltransportpathrequirements) >=20 > Andy, >=20 > You speak about "local" and "remote" alarms. I had to read=20 > the rest of the sentence three times before I understood that=20 > you meant "primary" and "secondary/consequential" alarms.=20 > A primary alarm is an alarm that reports a fault cause that=20 > needs fixing, whereas a secondary/consequential alarm is a=20 > report from a client that it's connection is interrupted due=20 > to a server fault. > Do I understand your use of "local" and "remote" correct? >=20 > I agree with you that the main task of fault management is to=20 > know if there is a fault that they can repair, what the fault=20 > is, where the location of this fault is and then who to send=20 > to repair the fault. >=20 > I agree with you that service management needs to know about=20 > the status of the service when the customer calls. I do not=20 > agree with you that in general "these guys wants to know that=20 > the service is 'down' **before** the customer is on the phone!". >=20 > I have very explicit information of a few operators that a=20 > large number of service contracts will not be as you=20 > describe. Values given to me are 90% of service contracts=20 > (representing 70% of service connections) are without=20 > pro-active monitoring. In those contracts the repair time=20 > starts after the report of the customer and verification by=20 > the operator. What is important in those cases is that the=20 > service manager can simply retrieve status information when=20 > the customer is on the phone. >=20 > The other 10% of service contracts (representing 30% of=20 > service connections) are with pro-active monitoring. In those=20 > contracts the repair time starts after the defect is=20 > detected. I assume that "these guys wants to know that the=20 > service is 'down' **before** the customer is on the phone!"=20 > is applicable for a subset of those service connections. For=20 > the other subset I have understood that it is sufficient when=20 > the status/performance information of the service connection=20 > can be retrieved instantaneously when the customer is on the=20 > phone. Is this also the case in BT? >=20 > Besides the service connections, we have tunnel/path=20 > connections, section connections and physical media=20 > connections. Those connections have no direct "service"=20 > associated with it; i.e. those connections are part of the=20 > network's infrastructure. There is as such no "service=20 > manager" interested in the status of those infrastructure=20 > connections. The only people interested in alarms from those=20 > infrastructure connections are the fault management people.=20 > Do I understand this correct? >=20 > > The service maintenance guys *have* got an alarm - the customer has=20 > > not got their service! They also notice that it is not=20 > fixing itself.=20 > > So they investigate, ie start localising. >=20 > I do not understand why a service maintenance guy will have=20 > to do the fault localization... I have always been told that=20 > fault management is responsible for locating a fault. If the=20 > fault is an open matrix connection (which either interrupts a=20 > tunnel/path connection or a service/channel connection), then=20 > the fault management people responsible for the layer network=20 > will be triggered by the loss of CC alarm and start the=20 > localization procedure. >=20 > When a network deploys AIS, it is possible to trigger this=20 > open matrix fault localization procedure without any complex=20 > network correlation procedure. > Seems to be advantages... >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] > Sent: woensdag 29 april 2009 0:26 > To: maarten.vissers@huawei.com; IBryskin@advaoptical.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Maarten, Igor, >=20 > Before dealing with the specific scenarios, let me go through=20 > again what I said in an earlier posting about the way alarm=20 > 'suppression' actually works. >=20 > There are two sides to maintenance - the faulty kit guys who=20 > fix faulty cards, mend cable breaks, etc, etc, and end=20 > service guys who deal with customer service. 'Suppressed'=20 > alarms are only suppressed to the faulty kit guys who fix=20 > cards, etc. The distinction between 'local' and 'remote'=20 > alarms is very important to ensure that these faulty kit guys=20 > are directed to the place where the actual fault lies and not=20 > to places affected by, but remote from the actual fault. >=20 > However, these 'suppressed' alarms are still forwarded to the=20 > service maintenance guys. So when SONET/SDH is carrying an E1=20 > or a T3, they want to know whether the end service is 'up' or=20 > 'down' irrespective of the cause and irrespective of the=20 > presence of AIS. AIS most emphatically does not suppress this=20 > alarm! These guys wants to know that the service is 'down'=20 > before the customer is on the phone! >=20 > So to go to Maarten's first example, the faulty kit guys are=20 > not getting any alarms telling them to fix broken kit - which=20 > is correct. >=20 > The service maintenance guys *have* got an alarm - the=20 > customer has not got their service! They also notice that it=20 > is not fixing itself. So they investigate, ie start=20 > localising. In practice, the first thing they will do (and=20 > most management systems will do it automatically by some form=20 > of correlation engine) is check for any corresponding faulty=20 > kit alarms. In this case, they will find no faulty kit alarms=20 > and suspect a misconfiguration, localise it, and fix it. >=20 > To go to Maarten's second example, the faulty kit guys are=20 > getting an alarm telling them to fix the link between A and B. >=20 > The service maintenance guys have also got an alarm - again=20 > the customer has not got their service. They also notice that=20 > it is not fixing itself. So they investigate, ie start=20 > localising. Again, the first thing they will do (and most=20 > management systems will do it automatically by some form of=20 > correlation engine) is check for any corresponding faulty kit=20 > alarms. In this case, they will find the corresponding faulty=20 > kit alarm and can check of the repair plan and status should=20 > the customer call and ask. >=20 > As these particular scenarios illustrate, the right alarms=20 > have been directed to the right maintenance guys. The service=20 > guys deal with the service configurations, the faulty kit=20 > guys deal with faulty kit. >=20 > Occasionally, there will be faulty kit which is not reporting=20 > itself despite the best design efforts in the equipment. In=20 > this case, the service maintenance guys are likely to have a=20 > series of alarms which can be correlated to help localise the=20 > fault and the diagnosed fault can then be passed to the=20 > faulty kit guys for fixing. >=20 > Another important point. There is little room here for=20 > *false* information coming to either set of maintenance guys.=20 > When trying to localise a fault, no additional information is=20 > better than wrong additional information. >=20 > That is my concern with the trying to inject packet based=20 > AIS. There is significant room for creating false=20 > information. As I've already indicted there is AIS specific=20 > configuration to do which will be prone to misconfiguration.=20 > We should then note that the thing that the AIS is supposed=20 > to be identifying is the present of misconfiguration - but=20 > achieving this requires configuration. So why should one=20 > configuration be more reliable than the other? >=20 > But there are other scenarios. For example, consider port=20 > mapping (or in ITU-T speak, a degenerate subnetwork) where we=20 > terminate the section layer on one interface and blindly ship=20 > all the packets out on an other interface in a new section.=20 > If we assume AIS is being used, a fault in the incoming=20 > section should result in the injection of AIS. But how does=20 > it know what label values to use? Or does it not inject AIS?=20 > In which case we have the poor service maintenance guys=20 > actively looking for a configuration error which does not=20 > exist. A similar scenario would exist if we choose to use a=20 > sort of ADM where the forwarding table was made up of=20 > exception (add/drop) label values and a default outgoing=20 > port. Again, the same dilemma exists. >=20 > Andy >=20 >=20 >=20 >=20 > Andy Reid > Chief Network Services Strategist > BT Innovate > =20 >=20 > Office: +44 (0)1277 322038 > Mobile: +44 (0)7917 025451 > Fax : +44 (0)1277 324015 > Email: andy.bd.reid@bt.com >=20 > =20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ=20 > Registered in England no. 1800000 This electronic message=20 > contains information from British Telecommunications plc=20 > which may be privileged or confidential. The information is=20 > intended to be for the use of the individual(s) or entity=20 > named above. If you are not the intended recipient be aware=20 > that any disclosure, copying, distribution or use of the=20 > contents of this information is prohibited. If you have=20 > received this electronic message in error, please notify us=20 > by telephone or email (to the numbers or address above) immediately. > Activity and use of the British Telecommunications plc email=20 > system is monitored to secure its effective operation and for=20 > other lawful business purposes. Communications using this=20 > system will also be monitored and may be recorded to secure=20 > effective operation and for other lawful business purposes. >=20 > =20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > Sent: 28 April 2009 20:25 > > To: 'Igor Bryskin' > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Igor, > >=20 > > > b) Is it beneficial if a server trail notifies its clients about > > a detected problem to suppress the OAM traffic > >=20 > > The suppression we have been talking about is alarm=20 > suppression, not=20 > > OAM traffic suppression. > >=20 > > Loss of CC is intended to detect an open connection fault=20 > in a matrix. > > E.g. assume a connection that starts in node A, passes=20 > through nodes B=20 > > and C and ends in node D. > > Nodes A, B, C and D have a connection function in which a matrix=20 > > connection is to be set up to support this connection from A to D. > >=20 > > What is now possible is that the matrix connection in node B is=20 > > unintentionally removed (i.e. a continuity fault). > > Node D will now detect a loss of CC. Node D does not detect=20 > any other=20 > > faults. > > Node C will not detect any fault. > > Node B will not detect any fault. > > Node A will not detect any fault if the matrix connection in B is=20 > > removed in one direction only. > >=20 > > In order to detect this open matrix connection fault it is=20 > required to=20 > > report the loss of CC to the management system and to start a fault=20 > > localization procedure to locate the faulty matrix (i.e. in node B). > > If such reporting is not done, then there is a hidden fault, which=20 > > keeps the connection interrupted much longer; i.e. until=20 > one or more=20 > > customers start to complain that their connections are lost. > > Then you hae to find in a big network without any fault=20 > report which=20 > > node has the fault. > >=20 > > What happens now if the fault is not an open matrix=20 > connection but a=20 > > server layer fault (e.g. a link fault between nodes A and B). > > Node D will now detect a loss of CC. Node D does not detect=20 > any other=20 > > faults. > > Node C will not detect any fault. > > Node B will detect a loss of signal fault. > > Node A will not detect any fault if the link from A to B is=20 > broken in=20 > > one direction only. > >=20 > > If loss of CC is unconditionally reported, then node D will report=20 > > loss of CC. Node B will report loss of signal. > > - If node B and node D are managed by the same management=20 > system it is=20 > > possible to perform a fault correlation in this management=20 > system to=20 > > filter out the loss of CC from node D. > > What is necessary is to know that connection A-D is=20 > supported by the=20 > > link A to B. In larger multi-layer networks such=20 > correlations become=20 > > complex. If such correlations are not performed, then the=20 > loss of CC=20 > > will trigger a fault localisation action, which of course will not=20 > > find a matrix fault (i.e. waste of time). > > - If node B is managed by another management system then=20 > node D, there=20 > > is no correlation possible. Node D's management system will=20 > see only=20 > > the loss of CC and will start fault localization, and will not find=20 > > any fault in its part of the network. > >=20 > > Use of AIS will help in distinguishing between connection=20 > interruption=20 > > due to an open matrix connection fault and due to server fault. AIS=20 > > provides the necessary filter for loss of CC. > >=20 > > What happens for the case a port detects a signal fail condition is=20 > > the following; assume a 10G port that detects a signal fail=20 > condition. > > This implies that all traffic is lost. > > Assume that there are 1000 client connections active (e.g.=20 > > with an average bandwidth of 5 Mbit/s). When AIS is to be generated=20 > > for those 1000 client conenctions the port has to generate 1000 AIS=20 > > frames/packets per second. Each AIS frame/packet is 64=20 > bytes/512 bits. > > Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005 > > Gbit/s) of traffic in a further empty 10G port. This isn't any real=20 > > complexity. > >=20 > > --------- > >=20 > > The alternative is to declare that open matrix connections=20 > are never a=20 > > fault condition (i.e. are always intentional and thus known=20 > by network=20 > > management). Under such starting point it is not necessary=20 > to detect=20 > > an open matrix connection as a fault condition. Now it is=20 > not longer=20 > > necessary to distinguish between connection interruption=20 > due to open=20 > > matrix and server layer fault as the first condition isn't a fault=20 > > anylonger. Under this condition it is not useful that a=20 > server trail=20 > > informs its clients about a detected server trail problem that=20 > > interrupts the client connections. > >=20 > > If we go for this latter approach and if in future an open matrix=20 > > connection would be a fault condition, then this is a=20 > hidden fault and=20 > > you need a lot more work to locate the fault (there are no=20 > alarms that=20 > > help you). > >=20 > > Regards, > > Maarten > >=20 > >=20 > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: dinsdag 28 april 2009 18:20 > > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Shahram, > >=20 > > I was addressing Neil's comments about the dynamic=20 > re-routing, which=20 > > is different from protection switchover onto pre-provisioned=20 > > protection connection. True, in the latter case the server layer=20 > > wouldn't notice that and will keep notifying the client=20 > that the trail=20 > > is broken. But this does not change anything. The big 2=20 > questions in=20 > > my mind are: > >=20 > > a) Is the OAM of a given layer is (i) self-sufficient and > > (ii) scalable enough, so that operator can rely on it=20 > completely and=20 > > independently from what is happening in the lower layers? > >=20 > > b) Is it beneficial if a server trail notifies its clients about a=20 > > detected problem to suppress the OAM traffic and possibly=20 > unnecessary=20 > > switchovers until the server trail corrects itself? > >=20 > > Cheers, > > Igor > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davarish@yahoo.com] > > Sent: Tuesday, April 28, 2009 11:57 AM > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Igor, > >=20 > > Your assumption is that there is a control plane that sets up the=20 > > binding between client and server layer and that such=20 > binding will be=20 > > removed via the control plane when a reroute happens. I think this=20 > > assumption is not always true. For example in a linear 1:1 or 1+1=20 > > protection, there is no signalling to withdraw the binding at=20 > > intermediate nodes. In > > 1:1 there is APS, but that is end-to-end and is sent on the backup=20 > > path not working path. > >=20 > > -Shahram > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: April-28-09 11:27 AM > > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Shahram, > >=20 > > Let's assume that connection A-B-C-D-E is dynamically=20 > provisioned by a=20 > > control plane. As part of such provisioning a binding is created=20 > > between this connection and network C at the two adaptation=20 > points on=20 > > either side of the link provided by network C. When the=20 > connection is=20 > > torn down, this binding is removed as a part of the cleanup process. > > The re-routing of the connection onto A-F-G-E is indistinguishable=20 > > from the connection tear down as far as link C is concerned. > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davarish@yahoo.com] > > Sent: Tuesday, April 28, 2009 11:15 AM > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Hi Igor, > >=20 > > How does the server know the client is rerouted? Assume the=20 > following > > networks: A-B-C-D-E (working) and A-F-G-E (protection).=20 > > Assume each has its own server layer such as MPLS, MPLS-TP, ATM,=20 > > SONET, etc. Assume that network C uses MPLS-TP as server layer. > > Network C will never know there was a protection switching done for=20 > > the client layer. > >=20 > > -Shahram > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin > > Sent: April-28-09 11:05 AM > > To: Maarten Vissers; neil.2.harrison@bt.com;=20 > nurit.sprecher@nsn.com;=20 > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl;=20 > adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Neil. > >=20 > > I actually agree with Maarten on this. I don't quite=20 > understand why do=20 > > you keep talking about fixed client-server relationship. It=20 > is fixed=20 > > as long as the client layer connection configured this way=20 > (statically=20 > > or dynamically). > > As soon as the connection is re-routed, this relationship is broken=20 > > (because this is a part of the re-routing process) and hence the=20 > > server trail termination points will know that the server trail now=20 > > serves one connection less, whereas some other server trail(s) will=20 > > learn that they serve from now on one connection more. These new=20 > > client-server relationships are fixed until the next re-routing. > >=20 > > Cheers, > > Igor > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > Sent: Tuesday, April 28, 2009 8:48 AM > > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com;=20 > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl;=20 > adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Neil, > >=20 > > > However, if the client can dynamically change its routing > > in response > > > to link failures in its topology (because some server=20 > layer network=20 > > > has failed....which may or may not belong to the same > > operating party > > > as the > > > client) then there is no fixed client/server relationship.=20 > >=20 > > I believe there is a fixed client/server relationship also in this=20 > > case in the network. This relationship is broken when the=20 > connection=20 > > is rerouted. > > Such reroute will remove the CP/FP and as such will stop the AIS=20 > > generation. > >=20 > > There is no difference with what we do today in SDH and OTN.=20 > > A client/server relationship is fixed until the point in=20 > time that the=20 > > connection is either teardown or rerouted. When either of the two=20 > > cases occur, the AIS generation is stopped. > > Until such action is performed, AIS is generated during signal fail=20 > > condition period and inserted into the connection. > >=20 > > In MPLS-TP we have the requirement that MPLS-TP must be able to=20 > > operate without control plane. This implies that it will operate=20 > > without restoration, and that there will not be frequent rerouteing=20 > > ongoing. Result is that client/server relationships will last until=20 > > the connection is teardown. > >=20 > > Regards, > > Maarten > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 > neil.2.harrison@bt.com > > Sent: dinsdag 28 april 2009 10:07 > > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Nurit, > >=20 > > I believe the reason we need this discussion is that there is an=20 > > unstated assumption here that the client/server=20 > relationship is fixed. > > However, if the client can dynamically change its routing=20 > in response=20 > > to link failures in its topology (because some server layer network=20 > > has failed....which may or may not belong to the same=20 > operating party=20 > > as the > > client) then there is no fixed client/server relationship. > >=20 > > Refer to my post earlier today and consider what this means in the=20 > > case of a cl-ps IP client layer network or a some SVC-based=20 > > co-ps/co-cs mode client layer network. The key point here is the=20 > > *routing process* in the client is independent of the server layer=20 > > network....so there is not a fixed client/server relationship. > > Further, there is also no requirement for the server to=20 > keep track of=20 > > where its client traffic routings are at any epoch.....indeed why=20 > > should it in the general case where these are independent layer=20 > > networks? > >=20 > > So the only OAM requirement that is critical is that the OAM of the=20 > > client and server layer networks are independent. It is thus not=20 > > sensible to make client layer alarm supression a 'requirement' > > here...in fact if this is in the OAM requirements then it is=20 > > technically wrong and should be removed IMO. > >=20 > > regards, Neil > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > Nurit (NSN - > > > IL/Hod HaSharon) > > > Sent: 28 April 2009 08:46 > > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > > transportpathrequirements) > > >=20 > > > If we agree that the requirement is included, so why do we > > keep with > > > the endless discussions on this requirement? > > >=20 > > > -----Original Message----- > > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > > Sent: Tuesday, April 28, 2009 10:44 AM > > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > > > Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > pathrequirements) > > >=20 > > > I think that the requirements are defined in section 2.2.8 of > > > draft-ietf-mpls-tp-oam-requirements-01 > > >=20 > > > Italo > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > Nurit (NSN > > > > - IL/Hod HaSharon) > > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > > To: hhelvoort@chello.nl; Adrian Farrel > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > > > transport pathrequirements) > > > >=20 > > > > Huub, > > > > I think that the requirement is to provide a mechanism to > > suppress > > > > alarms in the networks, to ensure that alarms that may be > > > generated by > > > > client layers as a result of a failure condition in the > > server layer > > > > may be suppressed. > > > > Every thing else is a solution, etc.=20 > > > > I propose to phrase the requirement appropriately and > > conclude the > > > > discussion on this in the context of the requirements > > (until we are > > > > getting to the solution phase). > > > > This requirement is included in the OAM requirement draft.=20 > > > > Best regards, > > > > NUrit > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On > > > > Behalf Of ext Huub van Helvoort > > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > > To: Adrian Farrel > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > bidirectional transport > > > > path requirements) > > > >=20 > > > > Hi Adrian, > > > >=20 > > > > You wrote: > > > >=20 > > > > > Isn't the solution here the same as the one I proposed > > for "TCM"? > > > >=20 > > > > Indeed, and that we do not have to around in circles about TCM. > > > >=20 > > > > How about: > > > > the requirement is that a server layer shall inform its > > clients that > > > > it has detected a service interuption, this to ensure that the=20 > > > > clients can inhibit (unnecessary) alarms. > > > >=20 > > > > Cheers, Huub. > > > >=20 > > > > -- > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > http://www.van-helvoort.eu/=20 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Always remember that you are unique...just like everyone else... > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 >=20 From dbrungard@att.com Wed Apr 29 08:04:22 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D393B3A69D1 for ; Wed, 29 Apr 2009 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.371 X-Spam-Level: X-Spam-Status: No, score=-104.371 tagged_above=-999 required=5 tests=[AWL=-1.823, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCrl7gfKYLpz for ; Wed, 29 Apr 2009 08:04:19 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 5C6703A67F3 for ; Wed, 29 Apr 2009 08:04:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1241017538!37322199!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 29969 invoked from network); 29 Apr 2009 15:05:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Apr 2009 15:05:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3TF5cwN011501 for ; Wed, 29 Apr 2009 11:05:38 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3TF5X28011408 for ; Wed, 29 Apr 2009 11:05:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C8DB.F131D2D5" Date: Wed, 29 Apr 2009 11:05:31 -0400 Message-ID: In-Reply-To: <008701c9c89b$4ef8bce0$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Thread-Index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJAABtoogAAkDyVAAA3bmWA= References: <008701c9c89b$4ef8bce0$6c02a8c0@china.huawei.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Maarten Vissers" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:04:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C8DB.F131D2D5 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, =20 I only have confirmed that what you have given as an example of an ENNI = below is G707 and G704. You missed the point. This is a typical ITU = interface standard. It can be used as an INNI, ENNI, or UNI. Since you = are twisting words, I=A1=AFll try to be clearer. =20 Yes, we need interface standards. If we have standards and have defined = the technology properly, we do not need your =A1=B0interworking = ENNI=A1=B1. You have twisted the definition of a standard interface = used between (hopefully) all equipment, within a domain and between = domains, to rationalize your =A1=B0ENNI=A1=B1. Two operators (or Forum) = agreeing on a physical encapsulation, J1, vlans, or label to be used may = be described in the industry as interworking, but then it can be said = that every interface is interworking. The fiber connectors are = interworking. Instead of saying, I=A1=AFm connecting the fiber, we will = say, we are interworking the fiber. This is silly. Rather than use a = much hyped non-specific term, here, in ITU and IETF, we should be = specific.=20 =20 The ENNI/UNIs defined in MPLS Forum and MEF are a profile of existing = standards. They provide a consistent interpretation of an existing = standard for the members of the Forum (i.e. improved readability for the = members, as we all know, ITU Recommendations and IETF RFCs are often not = standalone documents or not easy reading for non-involved readers). It = is questionable for IETF or ITU to define an ENNI or UNI as it will be = difficult for all the members to agree =A8C otherwise all the options = should not be in the original standard if they were not needed. =20 Connecting two networks together using a standard physical layer is not = really an ENNI (as Neil has said over and over). If we start defining = UNI/ENNI/INNI for all the technologies in ITU and IETF, we will have an = operational nightmare. =20 Deborah =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: Wednesday, April 29, 2009 3:23 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) =20 Deborah, =20 Thank you for confirming that we can speak about ENNI for non-IP layer = interconnects. As you indicate, an ENNI also exists when we interconnect = two SDH admin domains via an STM-N. =20 Do you also agree that we can speak about an ENNI when we interconnect a = Metro/Carrier Ethernet Network admin domain A with a Metro/Carrier = Etherent Network admin domain B via an 802.3 interface over which the = EVC layer is transported? =20 Regards, Maarten =20 ________________________________ From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: dinsdag 28 april 2009 17:52 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) Exactly =A8C G707 defined the ENNI for SDH and G703/G704 for PDH. The = PHY and framing is defined (per layer). This definition is very = different from your earlier email. It does not require supporting = PDH<->SDH interworking, or PDH OAM in SDH, or OAM interworking between a = client/server as one of your earlier emails required: =20 >For this case it is necessary to develop ETH<>PW(client) layer=20 > network > interworking specifications. To limit the complexity of such layer=20 > network interworking, it is beneficial to select the MPLS-TP PW OAM = > to > use the Y.7131 OAM PDUs as proposed in draft-bhh-mpls-tp-oam-y1731. = > I.e. > both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs =20 The interconnection of equipment (at one layer) should not put any = restrictions on other layers. =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: Tuesday, April 28, 2009 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) =20 Deborah, =20 > And the UNI/ENNI being discussed there is not comparable to your = definition. =20 I be more then happy if you give me alternative terms to UNI and ENNI. =20 Just use the example of a customer requesting a 2 Mbit/s service from = the SDH network, of which the first customer location is located behind = the network of operator A and the second endpoint is located behind the = network of operator B. Operator A and B interconnect via a STM-1 = interface with each other. The customer connects via a 2 Mbit/s G.703 = interface with the networks of operator A and B. =20 What term should I use for the interconnect of the customer to the = networks of operator A and B? I.e. if it is not possible to call this the "UNI", what should it be = called then? =20 What term should I use for the interconnect of the networks of operator = A and B? I.e. if it is not possible to call this the "ENNI", what should it be = called then? =20 Thanks for your help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: "An interface that is used = for the interconnection of customer equipment with a network element of = the transport network." =20 ________________________________ From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: maandag 27 april 2009 23:00 To: Greg Mirsky; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) Maarten, =20 I think you have oversimplified the discussion in MEF and in so doing = have inaccurately summarized. As Greg says, MEF is oriented towards = services (SLA/SLS) and they also recognize that some operators only need = simple troubleshooting tools. Considering the on-going discussion in = MEF, for the service operators group, it is questionable if Y1731 should = be used by MPLS-TP as a baseline as it is considered inadequate. And I = don=A1=AFt see AT&T=A1=AFs requirements as any different from BT. I = think we should follow Adrian=A1=AFs and Ben=A1=AFs proposal to define = the actual requirements for MPLS-TP before replicating other = technologies=A1=AF solutions. =20 And the UNI/ENNI being discussed there is not comparable to your = definition. =20 Deborah =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles = (Re:Associated bidirectional transport path requirements) =20 Dear Maarten, you definitely know but I'd note that MEF formulates requirements for = Carrier Ethernet as a service, i.e. client layer of a transport network, = not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, = in my view, to MPLS-TP, at least not automatically.=20 Regards, Greg Mirsky 2009/4/27 Maarten Vissers Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don't > use the others). Your company for some years has been asking for less, > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from = those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market > segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must >> not blindly recreate SDH/SONET. If we do so without consideration to >> how operators' needs and requirements may have evolved (and continue >> to evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents of >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =20 ------_=_NextPart_001_01C9C8DB.F131D2D5 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Maarten, I only have confirmed that what you have given as an = example of an ENNI below is G707 and G704. You missed the point. This is a typical = ITU interface standard. It can be used as an INNI, ENNI, or UNI. Since you are = twisting words, I=A1=AFll try to be clearer. Yes, we need interface standards. If we have standards = and have defined the technology properly, we do not need your =A1=B0interworking = ENNI=A1=B1. You have twisted the definition of a standard interface used between = (hopefully) all equipment, within a domain and between domains, to rationalize your = =A1=B0ENNI=A1=B1. Two operators (or Forum) agreeing on a physical encapsulation, J1, = vlans, or label to be used may be described in the industry as interworking, but then it = can be said that every interface is interworking. The fiber connectors are interworking. Instead of saying, I=A1=AFm connecting the fiber, we will = say, we are interworking the fiber. This is silly. Rather than use a much hyped non-specific = term, here, in ITU and IETF, we should be specific. The ENNI/UNIs defined in MPLS Forum and MEF are a profile = of existing standards. They provide a consistent interpretation of an = existing standard for the members of the Forum (i.e. improved readability for the members, as we all know, ITU Recommendations and IETF RFCs are often not standalone documents or not easy reading for non-involved readers). It = is questionable for IETF or ITU to define an ENNI or UNI as it will be = difficult for all the members to agree =A8C otherwise all the options should not = be in the original standard if they were not needed. Connecting two networks together using a standard = physical layer is not really an ENNI (as Neil has said over and over). If we start = defining UNI/ENNI/INNI for all the technologies in ITU and IETF, we will have an operational nightmare. Deborah From:= Maarten = Vissers [mailto:maarten.vissers@huawei.com] Sent: Wednesday, April 29, 2009 3:23 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Deborah, Thank you for confirming that we can speak about ENNI for = non-IP layer interconnects. As you indicate, an ENNI also exists when we = interconnect two SDH admin domains via an STM-N. Do you also agree that we can speak about an ENNI when we interconnect a Metro/Carrier Ethernet Network admin domain A with a Metro/Carrier Etherent Network admin domain B via an 802.3 interface = over which the EVC layer is transported? Regards, Maarten From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] Sent: dinsdag 28 april 2009 17:52 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Exactly =A8C G707 defined the ENNI for SDH and G703/G704 = for PDH. The PHY and framing is defined (per layer). This definition is very = different from your earlier email. It does not require supporting PDH<->SDH interworking, or PDH OAM in SDH, or OAM interworking between a = client/server as one of your earlier emails required: >For this case it is necessary to develop ETH<>PW(client) layer > network >    interworking = specifications. To limit the complexity of such layer >    network interworking, it = is beneficial to select the MPLS-TP PW OAM > to >    use the Y.7131 OAM PDUs = as proposed in draft-bhh-mpls-tp-oam-y1731. > I.e. >    both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs The interconnection of equipment (at one layer) should = not put any restrictions on other layers. From:= Maarten = Vissers [mailto:maarten.vissers@huawei.com] Sent: Tuesday, April 28, 2009 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Deborah, > And the UNI/ENNI being discussed there is not comparable = to your definition. I be more then happy if you give me alternative terms to UNI = and ENNI. Just use the example of a customer requesting a 2 Mbit/s = service from the SDH network, of which the first customer location is located = behind the network of operator A and the second endpoint is located behind the = network of operator B. Operator A and B interconnect via a STM-1 interface with = each other. The customer connects via a 2 Mbit/s G.703 interface with the = networks of operator A and B. What term should I use for the interconnect of the = customer to the networks of operator A and B? I.e. if it is not possible to call this the = "UNI", what should it be called then? What term should I use for the interconnect of the = networks of operator A and B? I.e. if it is not possible to call this the = "ENNI", what should it be called then? Thanks for your help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: = "An interface that is used for the interconnection of customer equipment = with a network element of the transport network." From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] Sent: maandag 27 april 2009 23:00 To: Greg Mirsky; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Maarten, I think you have oversimplified the discussion in MEF and = in so doing have inaccurately summarized. As Greg says, MEF is oriented = towards services (SLA/SLS) and they also recognize that some operators only need = simple troubleshooting tools. Considering the on-going discussion in MEF, for = the service operators group, it is questionable if Y1731 should be used by MPLS-TP = as a baseline as it is considered inadequate. And I don=A1=AFt see = AT&T=A1=AFs requirements as any different from BT. I think we should follow = Adrian=A1=AFs and Ben=A1=AFs proposal to define the actual requirements for MPLS-TP before = replicating other technologies=A1=AF solutions. And the UNI/ENNI being discussed there is not comparable = to your definition. Deborah From:= mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path = requirements) Dear Maarten, you definitely know but I'd note that MEF formulates requirements for = Carrier Ethernet as a service, i.e. client layer of a transport network, not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, in my view, to = MPLS-TP, at least not automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Tom, This AIS discussion has been held in previous technologies as well, = e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not = insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those = of other operators participating in this effort? I see the requirements for OAM that have been = expressed in this mpls-tp discussion by BT representatives to be different from the = requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, = FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed = by BT representatives. I see that MEF is requesting to support in Y.1731 = frame loss counting for more then one priority level; i.e. an extension of = the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) = have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, as those networks are "not top of stack". I see that many = operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services= .html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadban= d_Access_Service.html ); i.e. a peer-interconnection case and a potential case for TCM, a = case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to = BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) = where those represent the characteristics of the main services (data, = voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope = of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the = number > of nodes outside your network is factors larger then the number = of > nodes inside your network. My experience is that different = operators > have different sets of requirements. Manufacturers have to support = the > superset of those requirements. Each operator will then deploy = the > subset of provided features that fits its needs (and turn off or = don't > use the others). Your company for some years has been asking for = less, > other operators have been asking for more. Manufacturers thus = build > their products with lots of configurability to support all = variations. Do you see our = (BT's) requirements to be very divergent from those of other operators participating in this effort? Unless our requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established = features > like AIS, TCM, frame loss counting, delay measurement, loopback, = etc > before the majority of operators have agreed that such features = are > not longer necessary. Again, that is = your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), = what they require after they have been plainly clear about what they = want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and = achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with = those > opinions. > > I apologise for being direct (and possibly rude) but I am = getting > tired of being told by folks who do not represent operators = what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service = to > 173 countries with over 200 000 customer ports I have (off the top = of > my > head) > at least another 10 MPLS networks in specific countries covering = at > least 3 continents delivering dedicated services to particular = market > segments. > > I have an extremely large SDH network in the UK consisting of over = 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service = in > 110 countries. > > I would like to think my BT colleagues and I might know a = little > something about building large scale networks and the requirements = of > those networks and the needs of the customers that I deliver = services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues = in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.c= om > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a = more >> reliable and effective, easy to operator and easy to manage = packet >> transport network like me. but why not apply this SDH/SONET in = the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because = it >> have a complex OAM functions. while more people like to move = the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we = should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins <benjamin.niven-jenkins@bt.c= om> >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> <liu.guoman@zte.com.cn>, "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com> >> =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path = requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree = your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. = so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport = networks >> supporting the needs of operators today and in the future. We = must >> not blindly recreate SDH/SONET. If we do so without = consideration to >> how operators' needs and requirements may have evolved (and = continue >> to evolve in future) we will have failed IMO and I would = severely >> question the value of the work we will have produced. If we = just >> recreate SDH/SONET then what is the purpose of the work an = operator >> would be better off just deploying existing SDH/SONET = equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in = this >> mail is solely property of the sender's organization. This = mail >> communication is confidential. Recipients named above are = obligated >> to maintain secrecy and are not permitted to disclose the = contents of >> this > communication to others. >> This email and any files transmitted with it are confidential = and >> intended solely for the use of the individual or entity to whom = they >> are addressed. If you have received this email in error please = notify >> the originator of the message. Any views expressed in this = message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE = Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp<= /o:p> _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp<= /o:p> ------_=_NextPart_001_01C9C8DB.F131D2D5-- From neil.2.harrison@bt.com Wed Apr 29 08:07:17 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365A43A6A50 for ; Wed, 29 Apr 2009 08:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INIsb0JfSkwx for ; Wed, 29 Apr 2009 08:07:14 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 46A333A6CCA for ; Wed, 29 Apr 2009 08:07:11 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 16:08:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C8DC.5BA886BC" Date: Wed, 29 Apr 2009 16:08:33 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E25BB@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) Thread-Index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJAABtoogAAkDyVAAA3bmWAAAoO+QA== From: To: , X-OriginalArrivalTime: 29 Apr 2009 15:08:31.0419 (UTC) FILETIME=[5BBC30B0:01C9C8DC] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:07:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C8DC.5BA886BC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 V2VsbCBzYWlkIERlYm9yYWguICByZWdhcmRzLCBOZWlsDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KCUZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJSVU5HQVJELCBERUJPUkFI IEEsIEFUVExBQlMNCglTZW50OiAyOSBBcHJpbCAyMDA5IDE2OjA2DQoJVG86IE1hYXJ0ZW4gVmlz c2Vycw0KCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJU3ViamVjdDogUmU6IFttcGxzLXRwXSBXZSBh cHBlYXIgdG8gYmUgZ29pbmcgYXJvdW5kIGluIGNpcmNsZXMoUmU6QXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCgkNCgkNCg0KCU1hYXJ0ZW4sDQoN CgkgDQoNCglJIG9ubHkgaGF2ZSBjb25maXJtZWQgdGhhdCB3aGF0IHlvdSBoYXZlIGdpdmVuIGFz IGFuIGV4YW1wbGUgb2YgYW4gRU5OSSBiZWxvdyBpcyBHNzA3IGFuZCBHNzA0LiBZb3UgbWlzc2Vk IHRoZSBwb2ludC4gVGhpcyBpcyBhIHR5cGljYWwgSVRVIGludGVyZmFjZSBzdGFuZGFyZC4gSXQg Y2FuIGJlIHVzZWQgYXMgYW4gSU5OSSwgRU5OSSwgb3IgVU5JLiBTaW5jZSB5b3UgYXJlIHR3aXN0 aW5nIHdvcmRzLCBJ4oCZbGwgdHJ5IHRvIGJlIGNsZWFyZXIuDQoNCgkgDQoNCglZZXMsIHdlIG5l ZWQgaW50ZXJmYWNlIHN0YW5kYXJkcy4gSWYgd2UgaGF2ZSBzdGFuZGFyZHMgYW5kIGhhdmUgZGVm aW5lZCB0aGUgdGVjaG5vbG9neSBwcm9wZXJseSwgd2UgZG8gbm90IG5lZWQgeW91ciDigJxpbnRl cndvcmtpbmcgRU5OSeKAnS4gIFlvdSBoYXZlIHR3aXN0ZWQgdGhlIGRlZmluaXRpb24gb2YgYSBz dGFuZGFyZCBpbnRlcmZhY2UgdXNlZCBiZXR3ZWVuIChob3BlZnVsbHkpIGFsbCBlcXVpcG1lbnQs IHdpdGhpbiBhIGRvbWFpbiBhbmQgYmV0d2VlbiBkb21haW5zLCB0byByYXRpb25hbGl6ZSB5b3Vy IOKAnEVOTknigJ0uIFR3byBvcGVyYXRvcnMgKG9yIEZvcnVtKSBhZ3JlZWluZyBvbiBhIHBoeXNp Y2FsIGVuY2Fwc3VsYXRpb24sIEoxLCB2bGFucywgb3IgbGFiZWwgdG8gYmUgdXNlZCBtYXkgYmUg ZGVzY3JpYmVkIGluIHRoZSBpbmR1c3RyeSBhcyBpbnRlcndvcmtpbmcsIGJ1dCB0aGVuIGl0IGNh biBiZSBzYWlkIHRoYXQgZXZlcnkgaW50ZXJmYWNlIGlzIGludGVyd29ya2luZy4gVGhlIGZpYmVy IGNvbm5lY3RvcnMgYXJlIGludGVyd29ya2luZy4gSW5zdGVhZCBvZiBzYXlpbmcsIEnigJltIGNv bm5lY3RpbmcgdGhlIGZpYmVyLCB3ZSB3aWxsIHNheSwgd2UgYXJlIGludGVyd29ya2luZyB0aGUg ZmliZXIuIFRoaXMgaXMgc2lsbHkuIFJhdGhlciB0aGFuIHVzZSBhIG11Y2ggaHlwZWQgbm9uLXNw ZWNpZmljIHRlcm0sIGhlcmUsIGluIElUVSBhbmQgSUVURiwgd2Ugc2hvdWxkIGJlIHNwZWNpZmlj LiANCg0KCSANCg0KCVRoZSBFTk5JL1VOSXMgZGVmaW5lZCBpbiBNUExTIEZvcnVtIGFuZCBNRUYg YXJlIGEgcHJvZmlsZSBvZiBleGlzdGluZyBzdGFuZGFyZHMuIFRoZXkgcHJvdmlkZSBhIGNvbnNp c3RlbnQgaW50ZXJwcmV0YXRpb24gb2YgYW4gZXhpc3Rpbmcgc3RhbmRhcmQgZm9yIHRoZSBtZW1i ZXJzIG9mIHRoZSBGb3J1bSAoaS5lLiBpbXByb3ZlZCByZWFkYWJpbGl0eSBmb3IgdGhlIG1lbWJl cnMsIGFzIHdlIGFsbCBrbm93LCBJVFUgUmVjb21tZW5kYXRpb25zIGFuZCBJRVRGIFJGQ3MgYXJl IG9mdGVuIG5vdCBzdGFuZGFsb25lIGRvY3VtZW50cyBvciBub3QgZWFzeSByZWFkaW5nIGZvciBu b24taW52b2x2ZWQgcmVhZGVycykuIEl0IGlzIHF1ZXN0aW9uYWJsZSBmb3IgSUVURiBvciBJVFUg dG8gZGVmaW5lIGFuIEVOTkkgb3IgVU5JIGFzIGl0IHdpbGwgYmUgZGlmZmljdWx0IGZvciBhbGwg dGhlIG1lbWJlcnMgdG8gYWdyZWUg4oCTIG90aGVyd2lzZSBhbGwgdGhlIG9wdGlvbnMgc2hvdWxk IG5vdCBiZSBpbiB0aGUgb3JpZ2luYWwgc3RhbmRhcmQgaWYgdGhleSB3ZXJlIG5vdCBuZWVkZWQu DQoNCgkgDQoNCglDb25uZWN0aW5nIHR3byBuZXR3b3JrcyB0b2dldGhlciB1c2luZyBhIHN0YW5k YXJkIHBoeXNpY2FsIGxheWVyIGlzIG5vdCByZWFsbHkgYW4gRU5OSSAoYXMgTmVpbCBoYXMgc2Fp ZCBvdmVyIGFuZCBvdmVyKS4gSWYgd2Ugc3RhcnQgZGVmaW5pbmcgVU5JL0VOTkkvSU5OSSBmb3Ig YWxsIHRoZSB0ZWNobm9sb2dpZXMgaW4gSVRVIGFuZCBJRVRGLCB3ZSB3aWxsIGhhdmUgYW4gb3Bl cmF0aW9uYWwgbmlnaHRtYXJlLg0KDQoJIA0KDQoJRGVib3JhaA0KDQoJIA0KDQoJRnJvbTogTWFh cnRlbiBWaXNzZXJzIFttYWlsdG86bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dIA0KCVNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgMzoyMyBBTQ0KCVRvOiBCUlVOR0FSRCwgREVCT1JB SCBBLCBBVFRMQUJTDQoJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCglTdWJqZWN0OiBSRTogW21wbHMt dHBdIFdlIGFwcGVhciB0byBiZSBnb2luZyBhcm91bmQgaW4gY2lyY2xlcyAoUmU6QXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCg0KCSANCg0KCURl Ym9yYWgsDQoNCgkgDQoNCglUaGFuayB5b3UgZm9yIGNvbmZpcm1pbmcgdGhhdCB3ZSBjYW4gc3Bl YWsgYWJvdXQgRU5OSSBmb3Igbm9uLUlQIGxheWVyIGludGVyY29ubmVjdHMuIEFzIHlvdSBpbmRp Y2F0ZSwgYW4gRU5OSSBhbHNvIGV4aXN0cyB3aGVuIHdlIGludGVyY29ubmVjdCB0d28gU0RIIGFk bWluIGRvbWFpbnMgdmlhIGFuIFNUTS1OLg0KDQoJIA0KDQoJRG8geW91IGFsc28gYWdyZWUgdGhh dCB3ZSBjYW4gc3BlYWsgYWJvdXQgYW4gRU5OSSB3aGVuIHdlIGludGVyY29ubmVjdCBhIE1ldHJv L0NhcnJpZXIgRXRoZXJuZXQgTmV0d29yayBhZG1pbiBkb21haW4gQSB3aXRoIGEgTWV0cm8vQ2Fy cmllciBFdGhlcmVudCBOZXR3b3JrIGFkbWluIGRvbWFpbiBCIHZpYSBhbiA4MDIuMyBpbnRlcmZh Y2Ugb3ZlciB3aGljaCB0aGUgRVZDIGxheWVyIGlzIHRyYW5zcG9ydGVkPw0KDQoJIA0KDQoJUmVn YXJkcywNCg0KCU1hYXJ0ZW4NCg0KCSANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KCUZyb206IEJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlMgW21haWx0bzpkYnJ1bmdh cmRAYXR0LmNvbV0gDQoJU2VudDogZGluc2RhZyAyOCBhcHJpbCAyMDA5IDE3OjUyDQoJVG86IE1h YXJ0ZW4gVmlzc2Vycw0KCUNjOiBtcGxzLXRwQGlldGYub3JnDQoJU3ViamVjdDogUkU6IFttcGxz LXRwXSBXZSBhcHBlYXIgdG8gYmUgZ29pbmcgYXJvdW5kIGluIGNpcmNsZXMgKFJlOkFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQoNCglFeGFjdGx5 IOKAkyBHNzA3IGRlZmluZWQgdGhlIEVOTkkgZm9yIFNESCBhbmQgRzcwMy9HNzA0IGZvciBQREgu IFRoZSBQSFkgYW5kIGZyYW1pbmcgaXMgZGVmaW5lZCAocGVyIGxheWVyKS4gVGhpcyBkZWZpbml0 aW9uIGlzIHZlcnkgZGlmZmVyZW50IGZyb20geW91ciBlYXJsaWVyIGVtYWlsLiBJdCBkb2VzIG5v dCByZXF1aXJlIHN1cHBvcnRpbmcgUERIPC0+U0RIIGludGVyd29ya2luZywgb3IgUERIIE9BTSBp biBTREgsIG9yIE9BTSBpbnRlcndvcmtpbmcgYmV0d2VlbiBhIGNsaWVudC9zZXJ2ZXIgYXMgb25l IG9mIHlvdXIgZWFybGllciBlbWFpbHMgcmVxdWlyZWQ6DQoNCgkgDQoNCgk+Rm9yIHRoaXMgY2Fz ZSBpdCBpcyBuZWNlc3NhcnkgdG8gZGV2ZWxvcCBFVEg8PlBXKGNsaWVudCkgbGF5ZXIgDQoNCgk+ IG5ldHdvcmsNCg0KCT4gICAgaW50ZXJ3b3JraW5nIHNwZWNpZmljYXRpb25zLiBUbyBsaW1pdCB0 aGUgY29tcGxleGl0eSBvZiBzdWNoIGxheWVyIA0KDQoJPiAgICBuZXR3b3JrIGludGVyd29ya2lu ZywgaXQgaXMgYmVuZWZpY2lhbCB0byBzZWxlY3QgdGhlIE1QTFMtVFAgUFcgT0FNIA0KDQoJPiB0 bw0KDQoJPiAgICB1c2UgdGhlIFkuNzEzMSBPQU0gUERVcyBhcyBwcm9wb3NlZCBpbiBkcmFmdC1i aGgtbXBscy10cC1vYW0teTE3MzEuIA0KDQoJPiBJLmUuDQoNCgk+ICAgIGJvdGggRXRoZXJuZXQg YW5kIE1QTFMtVFAgd2lsbCB0aGVuIHVzZSBlLmcuIENDTSBPQU0gUERVcw0KDQoJIA0KDQoJVGhl IGludGVyY29ubmVjdGlvbiBvZiBlcXVpcG1lbnQgKGF0IG9uZSBsYXllcikgc2hvdWxkIG5vdCBw dXQgYW55IHJlc3RyaWN0aW9ucyBvbiBvdGhlciBsYXllcnMuDQoNCgkgDQoNCglGcm9tOiBNYWFy dGVuIFZpc3NlcnMgW21haWx0bzptYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbV0gDQoJU2VudDog VHVlc2RheSwgQXByaWwgMjgsIDIwMDkgNzowMSBBTQ0KCVRvOiBCUlVOR0FSRCwgREVCT1JBSCBB LCBBVFRMQUJTDQoJQ2M6IG1wbHMtdHBAaWV0Zi5vcmcNCglTdWJqZWN0OiBSRTogW21wbHMtdHBd IFdlIGFwcGVhciB0byBiZSBnb2luZyBhcm91bmQgaW4gY2lyY2xlcyAoUmU6QXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCg0KCSANCg0KCURlYm9y YWgsDQoNCgkgDQoNCgk+IEFuZCB0aGUgVU5JL0VOTkkgYmVpbmcgZGlzY3Vzc2VkIHRoZXJlIGlz IG5vdCBjb21wYXJhYmxlIHRvIHlvdXIgZGVmaW5pdGlvbi4NCg0KCSANCg0KCUkgYmUgbW9yZSB0 aGVuIGhhcHB5IGlmIHlvdSBnaXZlIG1lIGFsdGVybmF0aXZlIHRlcm1zIHRvIFVOSSBhbmQgRU5O SS4NCg0KCSANCg0KCUp1c3QgdXNlIHRoZSBleGFtcGxlIG9mIGEgY3VzdG9tZXIgcmVxdWVzdGlu ZyBhIDIgTWJpdC9zIHNlcnZpY2UgZnJvbSB0aGUgU0RIIG5ldHdvcmssIG9mIHdoaWNoIHRoZSBm aXJzdCBjdXN0b21lciBsb2NhdGlvbiBpcyBsb2NhdGVkIGJlaGluZCB0aGUgbmV0d29yayBvZiBv cGVyYXRvciBBIGFuZCB0aGUgc2Vjb25kIGVuZHBvaW50IGlzIGxvY2F0ZWQgYmVoaW5kIHRoZSBu ZXR3b3JrIG9mIG9wZXJhdG9yIEIuIE9wZXJhdG9yIEEgYW5kIEIgaW50ZXJjb25uZWN0IHZpYSBh IFNUTS0xIGludGVyZmFjZSB3aXRoIGVhY2ggb3RoZXIuIFRoZSBjdXN0b21lciBjb25uZWN0cyB2 aWEgYSAyIE1iaXQvcyBHLjcwMyBpbnRlcmZhY2Ugd2l0aCB0aGUgbmV0d29ya3Mgb2Ygb3BlcmF0 b3IgQSBhbmQgQi4NCg0KCSANCg0KCVdoYXQgdGVybSBzaG91bGQgSSB1c2UgZm9yIHRoZSBpbnRl cmNvbm5lY3Qgb2YgdGhlIGN1c3RvbWVyIHRvIHRoZSBuZXR3b3JrcyBvZiBvcGVyYXRvciBBIGFu ZCBCPw0KDQoJSS5lLiBpZiBpdCBpcyBub3QgcG9zc2libGUgdG8gY2FsbCB0aGlzIHRoZSAiVU5J Iiwgd2hhdCBzaG91bGQgaXQgYmUgY2FsbGVkIHRoZW4/DQoNCgkgDQoNCglXaGF0IHRlcm0gc2hv dWxkIEkgdXNlIGZvciB0aGUgaW50ZXJjb25uZWN0IG9mIHRoZSBuZXR3b3JrcyBvZiBvcGVyYXRv ciBBIGFuZCBCPw0KDQoJSS5lLiBpZiBpdCBpcyBub3QgcG9zc2libGUgdG8gY2FsbCB0aGlzIHRo ZSAiRU5OSSIsIHdoYXQgc2hvdWxkIGl0IGJlIGNhbGxlZCB0aGVuPw0KDQoJIA0KDQoJVGhhbmtz IGZvciB5b3VyIGhlbHAuDQoNCglSZWdhcmRzLA0KDQoJTWFhcnRlbg0KDQoJUFMuIE5vdGUgdGhh dCBHLjgwMTIgZGVmaW5lcyBVTkkgYXMgZm9sbG93czogIkFuIGludGVyZmFjZSB0aGF0IGlzIHVz ZWQgZm9yIHRoZSBpbnRlcmNvbm5lY3Rpb24gb2YgY3VzdG9tZXIgZXF1aXBtZW50IHdpdGggYSBu ZXR3b3JrIGVsZW1lbnQgb2YgdGhlIHRyYW5zcG9ydCBuZXR3b3JrLiINCg0KCSANCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCUZyb206IEJSVU5HQVJELCBERUJPUkFIIEEs IEFUVExBQlMgW21haWx0bzpkYnJ1bmdhcmRAYXR0LmNvbV0gDQoJU2VudDogbWFhbmRhZyAyNyBh cHJpbCAyMDA5IDIzOjAwDQoJVG86IEdyZWcgTWlyc2t5OyBNYWFydGVuIFZpc3NlcnMNCglDYzog bXBscy10cEBpZXRmLm9yZw0KCVN1YmplY3Q6IFJFOiBbbXBscy10cF0gV2UgYXBwZWFyIHRvIGJl IGdvaW5nIGFyb3VuZCBpbiBjaXJjbGVzIChSZTpBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJh bnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQoJTWFhcnRlbiwNCg0KCSANCg0KCUkgdGhpbmsg eW91IGhhdmUgb3ZlcnNpbXBsaWZpZWQgdGhlIGRpc2N1c3Npb24gaW4gTUVGIGFuZCBpbiBzbyBk b2luZyBoYXZlIGluYWNjdXJhdGVseSBzdW1tYXJpemVkLiBBcyBHcmVnIHNheXMsIE1FRiBpcyBv cmllbnRlZCB0b3dhcmRzIHNlcnZpY2VzIChTTEEvU0xTKSBhbmQgdGhleSBhbHNvIHJlY29nbml6 ZSB0aGF0IHNvbWUgb3BlcmF0b3JzIG9ubHkgbmVlZCBzaW1wbGUgdHJvdWJsZXNob290aW5nIHRv b2xzLiBDb25zaWRlcmluZyB0aGUgb24tZ29pbmcgZGlzY3Vzc2lvbiBpbiBNRUYsIGZvciB0aGUg c2VydmljZSBvcGVyYXRvcnMgZ3JvdXAsIGl0IGlzIHF1ZXN0aW9uYWJsZSBpZiBZMTczMSBzaG91 bGQgYmUgdXNlZCBieSBNUExTLVRQIGFzIGEgYmFzZWxpbmUgYXMgaXQgaXMgY29uc2lkZXJlZCBp bmFkZXF1YXRlLiBBbmQgSSBkb27igJl0IHNlZSBBVCZU4oCZcyByZXF1aXJlbWVudHMgYXMgYW55 IGRpZmZlcmVudCBmcm9tIEJULiBJIHRoaW5rIHdlIHNob3VsZCBmb2xsb3cgQWRyaWFu4oCZcyBh bmQgQmVu4oCZcyBwcm9wb3NhbCB0byBkZWZpbmUgdGhlIGFjdHVhbCByZXF1aXJlbWVudHMgZm9y IE1QTFMtVFAgYmVmb3JlIHJlcGxpY2F0aW5nIG90aGVyIHRlY2hub2xvZ2llc+KAmSBzb2x1dGlv bnMuDQoNCgkgDQoNCglBbmQgdGhlIFVOSS9FTk5JIGJlaW5nIGRpc2N1c3NlZCB0aGVyZSBpcyBu b3QgY29tcGFyYWJsZSB0byB5b3VyIGRlZmluaXRpb24uDQoNCgkgDQoNCglEZWJvcmFoDQoNCgkg DQoNCglGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnIE1pcnNreQ0KCVNlbnQ6IE1vbmRheSwgQXBy aWwgMjcsIDIwMDkgMjo0NyBQTQ0KCVRvOiBNYWFydGVuIFZpc3NlcnMNCglDYzogbXBscy10cEBp ZXRmLm9yZw0KCVN1YmplY3Q6IFJlOiBbbXBscy10cF0gV2UgYXBwZWFyIHRvIGJlIGdvaW5nIGFy b3VuZCBpbiBjaXJjbGVzIChSZTpBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzKQ0KDQoJIA0KDQoJRGVhciBNYWFydGVuLA0KCXlvdSBkZWZpbml0ZWx5 IGtub3cgYnV0IEknZCBub3RlIHRoYXQgTUVGIGZvcm11bGF0ZXMgcmVxdWlyZW1lbnRzIGZvciBD YXJyaWVyIEV0aGVybmV0IGFzIGEgc2VydmljZSwgaS5lLiBjbGllbnQgbGF5ZXIgb2YgYSB0cmFu c3BvcnQgbmV0d29yaywgbm90IHJlcXVpcmVtZW50cyBmb3IgdGhlIHRyYW5zcG9ydCBuZXR3b3Jr IGFzIHNlcnZlciBsYXllci4gVGh1cyByZXF1aXJlbWVudHMgZXhwcmVzc2VkIGJ5IFNQcyBhdCBN RUYgYXJlIG5vdCBhcHBsaWNhYmxlIG9yIHRyYW5zaXRpdmUsIGluIG15IHZpZXcsIHRvIE1QTFMt VFAsIGF0IGxlYXN0IG5vdCBhdXRvbWF0aWNhbGx5LiANCgkNCglSZWdhcmRzLA0KCUdyZWcgTWly c2t5DQoNCgkyMDA5LzQvMjcgTWFhcnRlbiBWaXNzZXJzIDxtYWFydGVuLnZpc3NlcnNAaHVhd2Vp LmNvbT4NCg0KCVRvbSwNCgkNCglUaGlzIEFJUyBkaXNjdXNzaW9uIGhhcyBiZWVuIGhlbGQgaW4g cHJldmlvdXMgdGVjaG5vbG9naWVzIGFzIHdlbGwsIGUuZy4NCglFdGhlcm5ldCBPQU0uDQoJVGhl IHJlc3VsdCB3YXMgdGhhdCBBSVMgaW5zZXJ0aW9uIGlzIG9wdGlvbmFsIGFuZCB0aGF0IEV0aGVy bmV0IGVxdWlwbWVudA0KCShzZWUgRy44MDIxKSBjYW4gYmUgY29uZmlndXJlZCB0byBpbnNlcnQg RXRoZXJuZXQgQUlTIG9yIHRvIG5vdCBpbnNlcnQNCglFdGhlcm5ldCBBSVMuDQoNCgkNCgk+IERv IHlvdSBzZWUgb3VyIChCVCdzKSByZXF1aXJlbWVudHMgdG8gYmUgdmVyeSBkaXZlcmdlbnQgZnJv bSB0aG9zZSBvZg0KCW90aGVyIG9wZXJhdG9ycyBwYXJ0aWNpcGF0aW5nIGluIHRoaXMgZWZmb3J0 Pw0KDQoJSSBzZWUgdGhlIHJlcXVpcmVtZW50cyBmb3IgT0FNIHRoYXQgaGF2ZSBiZWVuIGV4cHJl c3NlZCBpbiB0aGlzIG1wbHMtdHANCglkaXNjdXNzaW9uIGJ5IEJUIHJlcHJlc2VudGF0aXZlcyB0 byBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgcmVxdWlyZW1lbnRzDQoJZXhwcmVzc2VkIGJ5IG90aGVy IG9wZXJhdG9yIHJlcHJlc2VudGF0aXZlcy4gRm9yIGV4YW1wbGUNCglkcmFmdC1iaGgtbXBscy10 cC1vYW0teTE3MzEgaXMgY28tYXV0aG9yZWQgYnkgcmVwcmVzZW50YXRpdmVzIG9mIERULCBGVCwN CglLUE4sIEtEREkgYW5kIENULiBJIGFsc28gc2VlIHRoYXQgdGhlIE9BTSByZXF1aXJlbWVudHMg ZGVmaW5lZCBpbiBNRUYgKHdpdGgNCglpbnB1dCBmcm9tIGUuZy4gQVQmVCBhbmQgVmVyaXpvbikg YmUgZGlmZmVyZW50IGZyb20gdGhvc2UgZXhwcmVzc2VkIGJ5IEJUDQoJcmVwcmVzZW50YXRpdmVz LiBJIHNlZSB0aGF0IE1FRiBpcyByZXF1ZXN0aW5nIHRvIHN1cHBvcnQgaW4gWS4xNzMxIGZyYW1l DQoJbG9zcyBjb3VudGluZyBmb3IgbW9yZSB0aGVuIG9uZSBwcmlvcml0eSBsZXZlbDsgaS5lLiBh biBleHRlbnNpb24gb2YgdGhlDQoJZXhpc3RpbmcgY2FwYWJpbGl0eSB0aGF0IHN1cHBvcnQgZnJh bWUgbG9zcyBjb3VudGluZyBmb3IgYSBzaW5nbGUgcHJpb3JpdHkNCgkoaS5lLiBhIGNhc2Ugb2Yg bW9yZSBPQU0sIG5vdCBsZXNzIE9BTSkuDQoJDQoJSSBzZWUgdGhhdCB0aGUgb3BlcmF0b3JzIGFj dGl2ZSBpbiBNRUYgKGUuZy4gQVQmVCwgVmVyaXpvbiwgU3ByaW50KSBoYXZlDQoJY3JlYXRlZCBh bmQgYXJlIGNyZWF0aW5nIEV0aGVybmV0IFVOSSwgRXRoZXJuZXQgRS1OTkkgYW5kIEV0aGVybmV0 IFZpcnR1YWwNCglVTkkgc3BlY2lmaWNhdGlvbnMsIHdoaWxlIHJlcHJlc2VudGF0aXZlcyBvZiBC VCBzdGF0ZSB0aGF0IHRoZXJlIGNhbid0IGJlDQoJIlVOSSIgb3IgIkUtTk5JIiBpbnRlcmZhY2Vz IGFzc29jaWF0ZWQgd2l0aCBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzLCBhcw0KCXRob3NlIG5l dHdvcmtzIGFyZSAibm90IHRvcCBvZiBzdGFjayIuIEkgc2VlIHRoYXQgbWFueSBvcGVyYXRvcnMg cmVxdWlyZQ0KCWNvbXBsaWFuY2Ugd2l0aCBNRUYgc3BlY2lmaWNhdGlvbnMsIGluY2x1ZGluZyB0 aGUgRXRoZXJuZXQgVU5JDQoJc3BlY2lmaWNhdGlvbi4NCgkNCglJIHNlZSB0aGF0IGUuZy4gS1BO IHByb3ZpZGVzIGEgV2hvbGVzYWxlIEJyb2FkYmFuZCBBY2Nlc3MgKFdCQSkgc2VydmljZSB2aWEN Cglyb290ZWQtbXVsdGlwb2ludCBFVkNzLCB3aGljaCBFVkNzIHRlcm1pbmF0ZSBvdXRzaWRlIHRo ZSBLUE4gbmV0d29yayAocmVmZXINCgl0byBodHRwOi8vd3d3Lmtwbi13aG9sZXNhbGUuY29tL25s LzE2NzItQnJvYWRiYW5kX1NlcnZpY2VzLmh0bWwgYW5kDQoJaHR0cDovL3d3dy5rcG4td2hvbGVz YWxlLmNvbS9ubC8xOTM2LVdob2xlc2FsZV9Ccm9hZGJhbmRfQWNjZXNzX1NlcnZpY2UuaHRtbA0K CSk7IGkuZS4gYSBwZWVyLWludGVyY29ubmVjdGlvbiBjYXNlIGFuZCBhIHBvdGVudGlhbCBjYXNl IGZvciBUQ00sIGEgY2FzZQ0KCXdoaWNoIGFjY29yZGluZyB0byBCVCByZXByZXNlbnRhdGl2ZXMg ZG9lcyBub3QgZXhpc3QuDQoJDQoJSSBzZWUgdGhhdCB0aGUgIm1lc3NhZ2UsIGZpbGUsIHN0cmVh bSIgY29uY2VwdHMgYXJlIGtleSB0byBCVCdzDQoJY29uc2lkZXJhdGlvbnMsIHdoaWxlIEkgZG9u J3Qgc2VlIGFueSBvZiB0aGF0IGNvbnRyaWJ1dGVkIGJ5IG90aGVyDQoJb3BlcmF0b3JzLiBXaGVu IEkgbG9vayBhdCB0aGUgdGVsZWNvbSBuZXR3b3JrIHN0YWNrIChzZWUgYXR0YWNoZWQgc2xpZGUp LA0KCXRoZW4gbWVzc2FnZSwgZmlsZSBzdHJlYW0gYXJlIGltcG9ydGFudCBjb25jZXB0cyBhdCBM YXllciAzIChOR04pIHdoZXJlDQoJdGhvc2UgcmVwcmVzZW50IHRoZSBjaGFyYWN0ZXJpc3RpY3Mg b2YgdGhlIG1haW4gc2VydmljZXMgKGRhdGEsIHZvaWNlLA0KCXZpZGVvKSwgd2hlcmVhcyAiRS1M aW5lLCBFLVRyZWUsIEUtTEFOLCBQREggQ0VTLCBldGMiIGFyZSB0aGUgaW1wb3J0YW50DQoJc2Vy dmljZXMgYXQgTGF5ZXIgMiAoUFROKS4gVGhpcyByYWlzZXMgdGhlIHF1ZXN0aW9uIHdoYXQgdGhl IHNjb3BlIG9mDQoJTVBMUy1UUCBpcyBmb3IgeW91Og0KCUEpIE1QTFMtVFAgaXMgYSBMYXllciAz IFR1bm5lbC9QYXRoIGxheWVyIHRlY2hub2xvZ3kgd2hpY2ggaGFzIHRvIHN1cHBvcnQNCgl0aGUg SVAgYmFzZWQgTGF5ZXIgMyBTZXJ2aWNlcy9DaGFubmVsIGxheWVyDQoJQikgTVBMUy1UUCBpcyBh IExheWVyIDIgVHVubmVsL1BhdGggbGF5ZXIgdGVjaG5vbG9neSB3aGljaCBoYXMgdG8gc3VwcG9y dA0KCXRoZSBFVkMgYmFzZWQgTGF5ZXIgMiBTZXJ2aWNlcy9DaGFubmVsIGxheWVyLg0KCQ0KCVJl Z2FyZHMsDQoJTWFhcnRlbg0KDQoJDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9t OiBUaG9tYXMgTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQoJU2VudDog dnJpamRhZyAyNCBhcHJpbCAyMDA5IDE1OjM1DQoJVG86IE1hYXJ0ZW4gVmlzc2Vycw0KDQoJQ2M6 ICdCZW4gTml2ZW4tSmVua2lucyc7IG1wbHMtdHBAaWV0Zi5vcmcNCglTdWJqZWN0OiBSZTogW21w bHMtdHBdIFdlIGFwcGVhciB0byBiZSBnb2luZyBhcm91bmQgaW4gY2lyY2xlcyAoUmU6DQoJQXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cykNCgkNCgkN CgkgICAgICAgTWFhcnRpbiwNCgkNCgk+IEJlbiwNCgk+DQoJPiBZb3VyIGNvbXBhbnkgaXMgb25l IG9mIHRoZSBtYW55IG9wZXJhdG9ycyBpbiB0aGUgd29ybGQsIGFuZCB0aGUgbnVtYmVyDQoJPiBv ZiBub2RlcyBvdXRzaWRlIHlvdXIgbmV0d29yayBpcyBmYWN0b3JzIGxhcmdlciB0aGVuIHRoZSBu dW1iZXIgb2YNCgk+IG5vZGVzIGluc2lkZSB5b3VyIG5ldHdvcmsuIE15IGV4cGVyaWVuY2UgaXMg dGhhdCBkaWZmZXJlbnQgb3BlcmF0b3JzDQoJPiBoYXZlIGRpZmZlcmVudCBzZXRzIG9mIHJlcXVp cmVtZW50cy4gTWFudWZhY3R1cmVycyBoYXZlIHRvIHN1cHBvcnQgdGhlDQoJPiBzdXBlcnNldCBv ZiB0aG9zZSByZXF1aXJlbWVudHMuIEVhY2ggb3BlcmF0b3Igd2lsbCB0aGVuIGRlcGxveSB0aGUN Cgk+IHN1YnNldCBvZiBwcm92aWRlZCBmZWF0dXJlcyB0aGF0IGZpdHMgaXRzIG5lZWRzIChhbmQg dHVybiBvZmYgb3IgZG9uJ3QNCgk+IHVzZSB0aGUgb3RoZXJzKS4gWW91ciBjb21wYW55IGZvciBz b21lIHllYXJzIGhhcyBiZWVuIGFza2luZyBmb3IgbGVzcywNCgk+IG90aGVyIG9wZXJhdG9ycyBo YXZlIGJlZW4gYXNraW5nIGZvciBtb3JlLiBNYW51ZmFjdHVyZXJzIHRodXMgYnVpbGQNCgk+IHRo ZWlyIHByb2R1Y3RzIHdpdGggbG90cyBvZiBjb25maWd1cmFiaWxpdHkgdG8gc3VwcG9ydCBhbGwg dmFyaWF0aW9ucy4NCgkNCgkgICAgICAgRG8geW91IHNlZSBvdXIgKEJUJ3MpIHJlcXVpcmVtZW50 cyB0byBiZSB2ZXJ5IGRpdmVyZ2VudCBmcm9tIHRob3NlDQoJb2Ygb3RoZXIgb3BlcmF0b3JzIHBh cnRpY2lwYXRpbmcgaW4gdGhpcyBlZmZvcnQ/ICBVbmxlc3Mgb3VyIHJlcXVpcmVtZW50cw0KCWFy ZSB2ZXJ5IGRpZmZlcmVudCwgSSBhbSBjb25maWRlbnQgdmVuZG9ycyB3aWxsIGJ1aWxkIChvciBo YXZlIGJ1aWx0KSB0aGVpcg0KCWRldmljZXMgYmFzZWQgb24gb3VyIChzZW5zaWJsZSkgcmVxdWly ZW1lbnRzLg0KCQ0KCT4gSXQgaXMgbXkgb3BpbmlvbiB0aGF0IHdlIHNob3VsZCBub3QgcmVtb3Zl IHdlbGwgZXN0YWJsaXNoZWQgZmVhdHVyZXMNCgk+IGxpa2UgQUlTLCBUQ00sIGZyYW1lIGxvc3Mg Y291bnRpbmcsIGRlbGF5IG1lYXN1cmVtZW50LCBsb29wYmFjaywgZXRjDQoJPiBiZWZvcmUgdGhl IG1ham9yaXR5IG9mIG9wZXJhdG9ycyBoYXZlIGFncmVlZCB0aGF0IHN1Y2ggZmVhdHVyZXMgYXJl DQoJPiBub3QgbG9uZ2VyIG5lY2Vzc2FyeS4NCgkNCgkgICAgICAgQWdhaW4sIHRoYXQgaXMgeW91 ciBvcGluaW9uLCB3aGljaCBmcmFua2x5IHNlZW1zIHRvIGRpdmVyZ2UgZnJvbQ0KCXdoYXQgb3Ro ZXIgb3BlcmF0b3JzIGhhdmUgZXhwcmVzc2VkLiBGdXJ0aGVybW9yZSwgbGV0IG1lIHJlY29tbWVu ZCB0aGF0IHlvdQ0KCWdldCBvdXQgb2YgdGhlIGhhYml0IG9mIHRlbGxpbmcgeW91ciBjdXN0b21l cnMgKG9yIHBvdGVudGlhbCBvbmVzKSwgd2hhdA0KCXRoZXkgcmVxdWlyZSBhZnRlciB0aGV5IGhh dmUgYmVlbiBwbGFpbmx5IGNsZWFyIGFib3V0IHdoYXQgdGhleSB3YW50Lg0KCVVubGVzcyB5b3Ug dGhpbmsgd2UgZG9uJ3Qga25vdyB3aGF0IHdlIGFyZSB0YWxraW5nIGFib3V0LiBJcyB0aGlzIHBl cmhhcHMNCgl0aGUgY2FzZT8NCgkNCgkgICAgICAgLS1Ub20NCgkNCgkNCgkNCgkNCgk+IFJlZ2Fy ZHMsDQoJPiBNYWFydGVuDQoJPg0KCT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+IEZy b206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZ10gT24NCgk+IEJlaGFsZiBPZiBCZW4gTml2ZW4tSmVua2lucw0KCT4gU2VudDogdnJpamRh ZyAyNCBhcHJpbCAyMDA5IDA6MTQNCgk+IFRvOiBtcGxzLXRwQGlldGYub3JnDQoJPiBTdWJqZWN0 OiBbbXBscy10cF0gV2UgYXBwZWFyIHRvIGJlIGdvaW5nIGFyb3VuZCBpbiBjaXJjbGVzIChSZToN Cgk+IEFzc29jaWF0ZWQNCgk+IGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1l bnRzKQ0KCT4NCgk+IENvbGxlYWd1ZXMsDQoJPg0KCT4gVGhlIGN1cnJlbnQgZGViYXRlcyBhcHBl YXIgdG8gYmUgZ29pbmcgYXJvdW5kIGluIGNpcmNsZXMgYW5kIGFjaGlldmluZw0KCT4gbm90aGlu ZyBvZiB2YWx1ZSBJTU8uIFR3byBtYWpvciBvcGVyYXRvcnMgaGF2ZSBleHByZXNzZWQgdGhlaXIN Cgk+IG9waW5pb25zIGFuZCBubyBvcGVyYXRvciB0aGF0IEkgY2FuIHNlZSBoYXMgZGlzYWdyZWVk IHdpdGggdGhvc2UNCgk+IG9waW5pb25zLg0KCT4NCgk+IEkgYXBvbG9naXNlIGZvciBiZWluZyBk aXJlY3QgKGFuZCBwb3NzaWJseSBydWRlKSBidXQgSSBhbSBnZXR0aW5nDQoJPiB0aXJlZCBvZiBi ZWluZyB0b2xkIGJ5IGZvbGtzIHdobyBkbyBub3QgcmVwcmVzZW50IG9wZXJhdG9ycyB3aGF0DQoJ PiBmdW5jdGlvbmFsaXR5IEkgbmVlZCBvciBzaG91bGQgaGF2ZSBpbiBteSBuZXR3b3Jrcy4NCgk+ DQoJPiBUbyBwdXQgc29tZSBjb250ZXh0IG9uIEJUJ3MgY29tbWVudHMgaW4gdGhlc2UgdGhyZWFk czoNCgk+IEkgaGF2ZSB0aGUgbGFyZ2VzdCBNUExTIG5ldHdvcmsgaW4gdGhlIFVLLg0KCT4gSSBo YXZlIG9uZSBvZiB0aGUgbGFyZ2VzdCBNUExTIG5ldHdvcmtzIGdsb2JhbGx5IGRlbGl2ZXJpbmcg c2VydmljZSB0bw0KCT4gMTczIGNvdW50cmllcyB3aXRoIG92ZXIgMjAwIDAwMCBjdXN0b21lciBw b3J0cyBJIGhhdmUgKG9mZiB0aGUgdG9wIG9mDQoJPiBteQ0KCT4gaGVhZCkNCgk+IGF0IGxlYXN0 IGFub3RoZXIgMTAgTVBMUyBuZXR3b3JrcyBpbiBzcGVjaWZpYyBjb3VudHJpZXMgY292ZXJpbmcg YXQNCgk+IGxlYXN0IDMgY29udGluZW50cyBkZWxpdmVyaW5nIGRlZGljYXRlZCBzZXJ2aWNlcyB0 byBwYXJ0aWN1bGFyIG1hcmtldA0KCT4gc2VnbWVudHMuDQoJPg0KCT4gSSBoYXZlIGFuIGV4dHJl bWVseSBsYXJnZSBTREggbmV0d29yayBpbiB0aGUgVUsgY29uc2lzdGluZyBvZiBvdmVyIDMwDQoJ PiAwMDAgc3dpdGNoZXMgYW5kIHN1cHBvcnRpbmcgaW4gZXhjZXNzIG9mIDEgbWlsbGlvbiBjaXJj dWl0cy4NCgk+IEkgaGF2ZSBhbiBleHRyZW1lbHkgbGFyZ2UgU0RIIG5ldHdvcmsgZ2xvYmFsbHkg ZGVsaXZlcmluZyBzZXJ2aWNlIGluDQoJPiAxMTAgY291bnRyaWVzLg0KCT4NCgk+IEkgd291bGQg bGlrZSB0byB0aGluayBteSBCVCBjb2xsZWFndWVzIGFuZCBJIG1pZ2h0IGtub3cgYSBsaXR0bGUN Cgk+IHNvbWV0aGluZyBhYm91dCBidWlsZGluZyBsYXJnZSBzY2FsZSBuZXR3b3JrcyBhbmQgdGhl IHJlcXVpcmVtZW50cyBvZg0KCT4gdGhvc2UgbmV0d29ya3MgYW5kIHRoZSBuZWVkcyBvZiB0aGUg Y3VzdG9tZXJzIHRoYXQgSSBkZWxpdmVyIHNlcnZpY2VzDQoJPiB0by4NCgk+DQoJPiBDYW4gd2Ug cGxlYXNlIHN0b3AgdGhlc2UgY2lyY3VsYXIgYXJndW1lbnRzIHdoaWNoIGFyZSBJTU8gZ29pbmcN Cgk+IG5vd2hlcmUgYW5kIGZvY3VzIG9uIHRoZSB0YXNrIGluIGhhbmQgd2hpY2ggaXMgZGVmaW5p bmcgdGhlDQoJPiByZXF1aXJlbWVudHMgKGFuZCBsYXRlcg0KCT4gc29sdXRpb25zKSBiZWluZyBh c2tlZCBmb3IgYnkgbXlzZWxmLCBteSBjb21wYW55IGFuZCBteSBjb2xsZWFndWVzIGluDQoJPiBv dGhlciBvcGVyYXRvcnMgb24gdGhpcyBsaXN0Lg0KCT4NCgk+IFRoYW5rcw0KCT4gQmVuDQoJPg0K CT4NCgk+IC0tDQoJPg0KCT4gQmVuIE5pdmVuLUplbmtpbnMNCgk+IElQLCBEYXRhICYgQ29udGVu dCBBcmNoaXRlY3QNCgk+IE5ldHdvcmsgSW5mcmFzdHJ1Y3R1cmUgQXJjaGl0ZWN0dXJlLCBCVA0K CT4NCgk+IEUtbWFpbDogYmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20NCgk+IE9mZmljZTog KzQ0ICgwKTE0NzMgNjQ4MjI1DQoJPiBNb2JpbGU6ICs0NCAoMCk3OTE4IDA3NzIwNQ0KCT4gICBG YXg6ICs0NCAoMCkxMzMyIDU3ODgyNw0KCT4NCgk+IEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25z IHBsYy4gUmVnaXN0ZXJlZCBvZmZpY2U6ICA4MSBOZXdnYXRlIFN0cmVldA0KCT4gTG9uZG9uDQoJ PiBFQzFBIDdBSiAgIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogIDE4MDAwMDANCgk+DQoJPg0K CT4gT24gMjMvMDQvMjAwOSAwNzoyMywgImxpdS5ndW9tYW5AenRlLmNvbS5jbiIgPGxpdS5ndW9t YW5AenRlLmNvbS5jbj4NCgk+IHdyb3RlOg0KCT4NCgk+PiBiZW46DQoJPj4gSSB1bmRlcnN0YW5k IHlvdXIgbWVhbmluZywgeW91IHN0aWxsIHdpc2ggdG8gcmVzaWduIGFuZCBtYWtlIGEgbW9yZQ0K CT4+IHJlbGlhYmxlIGFuZCBlZmZlY3RpdmUsIGVhc3kgdG8gb3BlcmF0b3IgYW5kIGVhc3kgdG8g bWFuYWdlIHBhY2tldA0KCT4+IHRyYW5zcG9ydCBuZXR3b3JrIGxpa2UgbWUuIGJ1dCB3aHkgbm90 IGFwcGx5IHRoaXMgU0RIL1NPTkVUIGluIHRoZQ0KCT4+IGZ1dHVyZSBtYXliZSB0aGUgZm9sbG93 aW5nIGNhdXNlOg0KCT4+ICAgMSBpdCBhZG9wdGVkIGNpcmN1aXQgc3dpdGNoaW5nIHRlY2hvbm9n eSB0byBicmluZyBsb3dlciB1c2VmdWwgb2YNCgk+PiB0aGUgcmVzb3VyY2UgdGhhbiBQVE4gbmV0 d29yazsNCgk+PiAgIDIgaXQgY2FuJ3QgYmVhciBhbGwga2luZHMgb2YgdHJhZmZpY3MgbGlrZSBQ VE4gbmV0d29ya3MgaXQgbm90ZWQNCgk+PiB0aGF0IHdlIGNhbid0IGFwcGx5IFNESC9TT05FVCBu ZXR3b3JrIGluIHRoZSBmdXR1cmUgbm90IGJlY2F1c2UgaXQNCgk+PiBoYXZlIGEgY29tcGxleCBP QU0gZnVuY3Rpb25zLiB3aGlsZSBtb3JlIHBlb3BsZSBsaWtlIHRvIG1vdmUgdGhlDQoJPj4gYWR2 YW50YWdlcyBvZiAgdGhlIE9BTSBmdW5jdGlvbnMgaW4gU0RIL1NPTkVUIHRvIFBUTiBuZXR3b3Jr cy4gYW5kDQoJPj4gQUlTL0ZESSBmdW5jdGlvbiBpcyBhIGtpbmQgb2YgT0FNIGZ1bmN0aW9ucyBv ZiBTREgvU09ORVQgLiB3ZSBzaG91bGQNCgk+PiB1c2UgYW5kIGV4dGVuZCB0aGUgQUlTL0ZESSBm dW5jdGlvbnMgdG8gTVBMUy1UUCA7DQoJPj4NCgk+PiBiZXN0IHJlZ2FyZHMNCgk+PiBsaXUNCgk+ Pg0KCT4+DQoJPj4NCgk+PiBCZW4gTml2ZW4tSmVua2lucyA8YmVuamFtaW4ubml2ZW4tamVua2lu c0BidC5jb20+DQoJPj4gMjAwOS0wNC0yMyAwNzo1OA0KCT4+DQoJPj4g5pS25Lu25Lq6DQoJPj4g PGxpdS5ndW9tYW5AenRlLmNvbS5jbj4sICJCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTIg0K CT4+IDxkYnJ1bmdhcmRAYXR0LmNvbT4NCgk+PiDmioTpgIENCgk+PiA8bXBscy10cEBpZXRmLm9y Zz4NCgk+PiDkuLvpopgNCgk+PiBSZTogW21wbHMtdHBdIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMNCgk+Pg0KCT4+DQoJPj4NCgk+Pg0KCT4+DQoJ Pj4NCgk+PiBPbiAyMS8wNC8yMDA5IDAyOjU5LCAibGl1Lmd1b21hbkB6dGUuY29tLmNuIiA8bGl1 Lmd1b21hbkB6dGUuY29tLmNuPg0KCT4+IHdyb3RlOg0KCT4+DQoJPj4+IERlYm9yYWg6DQoJPj4+ IG1heWJlIHdoYXQgeW91IHNhaWQgaXMgcmlnaHQuIGJ1dCBJIGNhbid0IGNvbXBsZXRlbHkgYWdy ZWUgeW91cg0KCT4+IG9waW5pb25zLg0KCT4+PiBJTU8uIG1wbHMtdHAgaXMgcmVnYXJkIGFzIHRy YW5zcG9ydCBuZXR3b3JrIGxpa2UgU0RIL1NPTkVULiBzbyBpdA0KCT4+PiBzaG91bGQgaGF2ZSBB SVMvRkRJIGZ1Y3Rpb25zIGFzIFNESC9TT05FVC4NCgk+Pj4NCgk+Pj4gZG8geW91IHRoaW5rIHNv Lg0KCT4+DQoJPj4gTm8gd2UgbXVzdCBhc3Nlc3MgdGhlIHJlcXVpcmVtZW50cyBmb3IgcGFja2V0 IHRyYW5zcG9ydCBuZXR3b3Jrcw0KCT4+IHN1cHBvcnRpbmcgdGhlIG5lZWRzIG9mIG9wZXJhdG9y cyB0b2RheSBhbmQgaW4gdGhlIGZ1dHVyZS4gV2UgbXVzdA0KCT4+IG5vdCBibGluZGx5IHJlY3Jl YXRlIFNESC9TT05FVC4gSWYgd2UgZG8gc28gd2l0aG91dCBjb25zaWRlcmF0aW9uIHRvDQoJPj4g aG93IG9wZXJhdG9ycycgbmVlZHMgYW5kIHJlcXVpcmVtZW50cyBtYXkgaGF2ZSBldm9sdmVkIChh bmQgY29udGludWUNCgk+PiB0byBldm9sdmUgaW4gZnV0dXJlKSB3ZSB3aWxsIGhhdmUgZmFpbGVk IElNTyBhbmQgSSB3b3VsZCBzZXZlcmVseQ0KCT4+IHF1ZXN0aW9uIHRoZSB2YWx1ZSBvZiB0aGUg d29yayB3ZSB3aWxsIGhhdmUgcHJvZHVjZWQuIElmIHdlIGp1c3QNCgk+PiByZWNyZWF0ZSBTREgv U09ORVQgdGhlbiB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSB3b3JrIGFuIG9wZXJhdG9yDQoJ Pj4gd291bGQgYmUgYmV0dGVyIG9mZiBqdXN0IGRlcGxveWluZyBleGlzdGluZyBTREgvU09ORVQg ZXF1aXBtZW50Lg0KCT4+DQoJPj4NCgk+PiBCZW4NCgk+Pg0KCT4+DQoJPj4NCgk+Pg0KCT4+DQoJ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCgk+PiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMNCgk+PiBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwNCgk+PiBjb21tdW5pY2F0aW9uIGlzIGNvbmZp ZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkDQoJPj4gdG8gbWFp bnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mDQoJPj4gdGhpcw0KCT4gY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoJPj4gVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQNCgk+PiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleQ0KCT4+IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeQ0KCT4+IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZQ0KCT4+ IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJPj4gVGhpcyBtZXNzYWdlIGhh cyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbQ0KCT4g c3lzdGVtLg0KCT4NCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoJPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KCT4gbXBscy10cEBpZXRmLm9yZw0KCT4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoJPg0KCT4NCgk+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJPiBtcGxz LXRwIG1haWxpbmcgbGlzdA0KCT4gbXBscy10cEBpZXRmLm9yZw0KCT4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwDQoNCgkNCglfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCW1wbHMtdHAgbWFpbGluZyBsaXN0DQoJbXBs cy10cEBpZXRmLm9yZw0KCWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cA0KDQoJIA0KDQo= ------_=_NextPart_001_01C9C8DC.5BA886BC Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGh0 dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjM0OTIiIG5hbWU9R0VORVJBVE9SPjwh LS1baWYgIW1zb10+DQo8U1RZTEU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwv U1RZTEU+DQo8IVtlbmRpZl0tLT4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25z ICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1 biI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlNpbVN1biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0 DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9TVFlMRT4NCjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9E WSBsYW5nPUVOLVVTIHZMaW5rPXB1cnBsZSBsaW5rPWJsdWU+DQo8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48U1BBTiBjbGFzcz01NTQ0NDA3MTUtMjkwNDIwMDk+PEZPTlQgDQpmYWNlPSJDb21pYyBT YW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5XZWxsIHNhaWQgRGVib3JhaC4mbmJzcDsgcmVn YXJkcywgDQpOZWlsPC9GT05UPjwvU1BBTj48L0RJVj48QlI+DQo8QkxPQ0tRVU9URSBkaXI9bHRy IA0Kc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVG VDogIzgwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1P dXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhS IHRhYkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZyANCiAgW21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5v cmddIDxCPk9uIEJlaGFsZiBPZiA8L0I+QlJVTkdBUkQsIERFQk9SQUggQSwgDQogIEFUVExBQlM8 QlI+PEI+U2VudDo8L0I+IDI5IEFwcmlsIDIwMDkgMTY6MDY8QlI+PEI+VG86PC9CPiBNYWFydGVu IA0KICBWaXNzZXJzPEJSPjxCPkNjOjwvQj4gbXBscy10cEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0 OjwvQj4gUmU6IFttcGxzLXRwXSBXZSANCiAgYXBwZWFyIHRvIGJlIGdvaW5nIGFyb3VuZCBpbiBj aXJjbGVzKFJlOkFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgDQogIHBhdGggcmVx dWlyZW1lbnRzKTxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8RElWIGNs YXNzPVNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05U LVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJyI+TWFhcnRlbiw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn Ij5JIA0KICBvbmx5IGhhdmUgY29uZmlybWVkIHRoYXQgd2hhdCB5b3UgaGF2ZSBnaXZlbiBhcyBh biBleGFtcGxlIG9mIGFuIEVOTkkgYmVsb3cgaXMgDQogIEc3MDcgYW5kIEc3MDQuIFlvdSBtaXNz ZWQgdGhlIHBvaW50LiBUaGlzIGlzIGEgdHlwaWNhbCBJVFUgaW50ZXJmYWNlIHN0YW5kYXJkLiAN CiAgSXQgY2FuIGJlIHVzZWQgYXMgYW4gSU5OSSwgRU5OSSwgb3IgVU5JLiBTaW5jZSB5b3UgYXJl IHR3aXN0aW5nIHdvcmRzLCBJ4oCZbGwgDQogIHRyeSB0byBiZSBjbGVhcmVyLjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1z ZXJpZiciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1G QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPlllcywgDQogIHdlIG5lZWQgaW50ZXJmYWNl IHN0YW5kYXJkcy4gSWYgd2UgaGF2ZSBzdGFuZGFyZHMgYW5kIGhhdmUgZGVmaW5lZCB0aGUgDQog IHRlY2hub2xvZ3kgcHJvcGVybHksIHdlIGRvIG5vdCBuZWVkIHlvdXIg4oCcaW50ZXJ3b3JraW5n IEVOTknigJ0uICZuYnNwO1lvdSBoYXZlIA0KICB0d2lzdGVkIHRoZSBkZWZpbml0aW9uIG9mIGEg c3RhbmRhcmQgaW50ZXJmYWNlIHVzZWQgYmV0d2VlbiAoaG9wZWZ1bGx5KSBhbGwgDQogIGVxdWlw bWVudCwgd2l0aGluIGEgZG9tYWluIGFuZCBiZXR3ZWVuIGRvbWFpbnMsIHRvIHJhdGlvbmFsaXpl IHlvdXIg4oCcRU5OSeKAnS4gDQogIFR3byBvcGVyYXRvcnMgKG9yIEZvcnVtKSBhZ3JlZWluZyBv biBhIHBoeXNpY2FsIGVuY2Fwc3VsYXRpb24sIEoxLCB2bGFucywgb3IgDQogIGxhYmVsIHRvIGJl IHVzZWQgbWF5IGJlIGRlc2NyaWJlZCBpbiB0aGUgaW5kdXN0cnkgYXMgaW50ZXJ3b3JraW5nLCBi dXQgdGhlbiBpdCANCiAgY2FuIGJlIHNhaWQgdGhhdCBldmVyeSBpbnRlcmZhY2UgaXMgaW50ZXJ3 b3JraW5nLiBUaGUgZmliZXIgY29ubmVjdG9ycyBhcmUgDQogIGludGVyd29ya2luZy4gSW5zdGVh ZCBvZiBzYXlpbmcsIEnigJltIGNvbm5lY3RpbmcgdGhlIGZpYmVyLCB3ZSB3aWxsIHNheSwgd2Ug YXJlIA0KICBpbnRlcndvcmtpbmcgdGhlIGZpYmVyLiBUaGlzIGlzIHNpbGx5LiBSYXRoZXIgdGhh biB1c2UgYSBtdWNoIGh5cGVkIA0KICBub24tc3BlY2lmaWMgdGVybSwgaGVyZSwgaW4gSVRVIGFu ZCBJRVRGLCB3ZSBzaG91bGQgYmUgc3BlY2lmaWMuIA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsg Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj48bzpw PiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg c3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2Fs aWJyaScsJ3NhbnMtc2VyaWYnIj5UaGUgDQogIEVOTkkvVU5JcyBkZWZpbmVkIGluIE1QTFMgRm9y dW0gYW5kIE1FRiBhcmUgYSBwcm9maWxlIG9mIGV4aXN0aW5nIHN0YW5kYXJkcy4gDQogIFRoZXkg cHJvdmlkZSBhIGNvbnNpc3RlbnQgaW50ZXJwcmV0YXRpb24gb2YgYW4gZXhpc3Rpbmcgc3RhbmRh cmQgZm9yIHRoZSANCiAgbWVtYmVycyBvZiB0aGUgRm9ydW0gKGkuZS4gaW1wcm92ZWQgcmVhZGFi aWxpdHkgZm9yIHRoZSBtZW1iZXJzLCBhcyB3ZSBhbGwgDQogIGtub3csIElUVSBSZWNvbW1lbmRh dGlvbnMgYW5kIElFVEYgUkZDcyBhcmUgb2Z0ZW4gbm90IHN0YW5kYWxvbmUgZG9jdW1lbnRzIG9y IA0KICBub3QgZWFzeSByZWFkaW5nIGZvciBub24taW52b2x2ZWQgcmVhZGVycykuIEl0IGlzIHF1 ZXN0aW9uYWJsZSBmb3IgSUVURiBvciBJVFUgDQogIHRvIGRlZmluZSBhbiBFTk5JIG9yIFVOSSBh cyBpdCB3aWxsIGJlIGRpZmZpY3VsdCBmb3IgYWxsIHRoZSBtZW1iZXJzIHRvIGFncmVlIA0KICDi gJMgb3RoZXJ3aXNlIGFsbCB0aGUgb3B0aW9ucyBzaG91bGQgbm90IGJlIGluIHRoZSBvcmlnaW5h bCBzdGFuZGFyZCBpZiB0aGV5IA0KICB3ZXJlIG5vdCBuZWVkZWQuPG86cD48L286cD48L1NQQU4+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEx cHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+ PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJyI+Q29ubmVjdGluZyANCiAgdHdvIG5ldHdvcmtzIHRvZ2V0 aGVyIHVzaW5nIGEgc3RhbmRhcmQgcGh5c2ljYWwgbGF5ZXIgaXMgbm90IHJlYWxseSBhbiBFTk5J IA0KICAoYXMgTmVpbCBoYXMgc2FpZCBvdmVyIGFuZCBvdmVyKS4gSWYgd2Ugc3RhcnQgZGVmaW5p bmcgVU5JL0VOTkkvSU5OSSBmb3IgYWxsIA0KICB0aGUgdGVjaG5vbG9naWVzIGluIElUVSBhbmQg SUVURiwgd2Ugd2lsbCBoYXZlIGFuIG9wZXJhdGlvbmFsIA0KICBuaWdodG1hcmUuPG86cD48L286 cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05U LVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05U LUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+RGVib3JhaDxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZici PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPERJVj4NCiAgPERJViANCiAgc3R5bGU9 IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogI2I1YzRkZiAxcHQgc29saWQ7IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLUJPVFRPTTog MGluOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQ7IEJPUkRFUi1C T1RUT006IG1lZGl1bSBub25lIj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn Ij5Gcm9tOjwvU1BBTj48L0I+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPiBNYWFydGVuIFZpc3NlcnMgDQogIFttYWls dG86bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb21dIDxCUj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5 LCBBcHJpbCAyOSwgMjAwOSANCiAgMzoyMyBBTTxCUj48Qj5Ubzo8L0I+IEJSVU5HQVJELCBERUJP UkFIIEEsIEFUVExBQlM8QlI+PEI+Q2M6PC9CPiANCiAgbXBscy10cEBpZXRmLm9yZzxCUj48Qj5T dWJqZWN0OjwvQj4gUkU6IFttcGxzLXRwXSBXZSBhcHBlYXIgdG8gYmUgZ29pbmcgYXJvdW5kIA0K ICBpbiBjaXJjbGVzIChSZTpBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgg DQogIHJlcXVpcmVtZW50cyk8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5EZWJvcmFoLDwvU1BBTj48bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nLCdzZXJpZiciPiZuYnNwOzwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5UaGFuayANCiAgeW91 IGZvciBjb25maXJtaW5nIHRoYXQgd2UgY2FuIHNwZWFrIGFib3V0IEVOTkkgZm9yIG5vbi1JUCBs YXllciANCiAgaW50ZXJjb25uZWN0cy4gQXMgeW91IGluZGljYXRlLCBhbiBFTk5JIGFsc28gZXhp c3RzIHdoZW4gd2UgaW50ZXJjb25uZWN0IHR3byANCiAgU0RIIGFkbWluIGRvbWFpbnMgdmlhIGFu IFNUTS1OLjwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZiciPiZuYnNw OzwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcs J3NhbnMtc2VyaWYnIj5EbyB5b3UgDQogIGFsc28gYWdyZWUgdGhhdCB3ZSBjYW4gc3BlYWsgYWJv dXQgYW4gRU5OSSB3aGVuIHdlIGludGVyY29ubmVjdCBhIA0KICBNZXRyby9DYXJyaWVyIEV0aGVy bmV0IE5ldHdvcmsgYWRtaW4gZG9tYWluIEEgd2l0aCBhIE1ldHJvL0NhcnJpZXIgRXRoZXJlbnQg DQogIE5ldHdvcmsgYWRtaW4gZG9tYWluIEIgdmlhIGFuIDgwMi4zIGludGVyZmFjZSBvdmVyIHdo aWNoIHRoZSBFVkMgbGF5ZXIgaXMgDQogIHRyYW5zcG9ydGVkPzwvU1BBTj48bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nLCdzZXJpZiciPiZuYnNwOzwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5SZWdhcmRzLDwvU1BB Tj48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMt c2VyaWYnIj5NYWFydGVuPC9TUEFOPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJU RVhULUFMSUdOOiBjZW50ZXIiIGFsaWduPWNlbnRlcj4NCiAgPEhSIGFsaWduPWNlbnRlciB3aWR0 aD0iMTAwJSIgU0laRT0yPg0KICA8L0RJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU4tQk9UVE9NOiAxMnB0Ij48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+RnJvbTo8L1NQQU4+PC9CPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMt c2VyaWYnIj4gQlJVTkdBUkQsIERFQk9SQUggDQogIEEsIEFUVExBQlMgW21haWx0bzpkYnJ1bmdh cmRAYXR0LmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBkaW5zZGFnIDI4IGFwcmlsIDIwMDkgDQogIDE3 OjUyPEJSPjxCPlRvOjwvQj4gTWFhcnRlbiBWaXNzZXJzPEJSPjxCPkNjOjwvQj4gDQogIG1wbHMt dHBAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBbbXBscy10cF0gV2UgYXBwZWFyIHRv IGJlIGdvaW5nIGFyb3VuZCANCiAgaW4gY2lyY2xlcyAoUmU6QXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCBwYXRoIA0KICByZXF1aXJlbWVudHMpPC9TUEFOPjxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7 IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+RXhh Y3RseSANCiAg4oCTIEc3MDcgZGVmaW5lZCB0aGUgRU5OSSBmb3IgU0RIIGFuZCBHNzAzL0c3MDQg Zm9yIFBESC4gVGhlIFBIWSBhbmQgZnJhbWluZyBpcyANCiAgZGVmaW5lZCAocGVyIGxheWVyKS4g VGhpcyBkZWZpbml0aW9uIGlzIHZlcnkgZGlmZmVyZW50IGZyb20geW91ciBlYXJsaWVyIA0KICBl bWFpbC4gSXQgZG9lcyBub3QgcmVxdWlyZSBzdXBwb3J0aW5nIFBESCZsdDstJmd0O1NESCBpbnRl cndvcmtpbmcsIG9yIFBESCBPQU0gDQogIGluIFNESCwgb3IgT0FNIGludGVyd29ya2luZyBiZXR3 ZWVuIGEgY2xpZW50L3NlcnZlciBhcyBvbmUgb2YgeW91ciBlYXJsaWVyIA0KICBlbWFpbHMgcmVx dWlyZWQ6PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0O0ZvciB0aGlzIGNhc2UgaXQgaXMgbmVjZXNzYXJ5IHRv IGRldmVsb3AgDQogIEVUSCZsdDsmZ3Q7UFcoY2xpZW50KSBsYXllciA8bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgbmV0d29yazxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRlcndvcmtpbmcg c3BlY2lmaWNhdGlvbnMuIFRvIA0KICBsaW1pdCB0aGUgY29tcGxleGl0eSBvZiBzdWNoIGxheWVy IDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBuZXR3b3JrIGludGVyd29ya2luZywgaXQgaXMgDQogIGJlbmVmaWNpYWwgdG8gc2Vs ZWN0IHRoZSBNUExTLVRQIFBXIE9BTSA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgdG88bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlIHRoZSBZLjcxMzEgT0FNIFBEVXMgYXMgDQogIHByb3Bv c2VkIGluIGRyYWZ0LWJoaC1tcGxzLXRwLW9hbS15MTczMS4gPG86cD48L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IEkuZS48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPiZndDs8U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnIj4mbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+IGJvdGggDQogIEV0aGVybmV0 IGFuZCBNUExTLVRQIHdpbGwgdGhlbiB1c2UgZS5nLiBDQ00gT0FNIFBEVXM8bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0 OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPjxv OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZiciPlRoZSANCiAgaW50ZXJjb25uZWN0aW9uIG9mIGVxdWlwbWVu dCAoYXQgb25lIGxheWVyKSBzaG91bGQgbm90IHB1dCBhbnkgcmVzdHJpY3Rpb25zIG9uIA0KICBv dGhlciBsYXllcnMuPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZB TUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9Q Pg0KICA8RElWPg0KICA8RElWIA0KICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsg UEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgUEFERElO Ry1MRUZUOiAwaW47IFBBRERJTkctQk9UVE9NOiAwaW47IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1UT1A6IDNwdDsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPkZyb206PC9TUEFOPjwvQj48U1BBTiANCiAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlm JyI+IE1hYXJ0ZW4gVmlzc2VycyANCiAgW21haWx0bzptYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNv bV0gPEJSPjxCPlNlbnQ6PC9CPiBUdWVzZGF5LCBBcHJpbCAyOCwgMjAwOSANCiAgNzowMSBBTTxC Uj48Qj5Ubzo8L0I+IEJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlM8QlI+PEI+Q2M6PC9CPiAN CiAgbXBscy10cEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6IFttcGxzLXRwXSBXZSBh cHBlYXIgdG8gYmUgZ29pbmcgYXJvdW5kIA0KICBpbiBjaXJjbGVzIChSZTpBc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQogIHJlcXVpcmVtZW50cyk8bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5E ZWJvcmFoLDwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZiciPiZuYnNw OzwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6 ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj4mZ3Q7IA0KICA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdz YW5zLXNlcmlmJyI+QW5kIA0KICB0aGUgVU5JL0VOTkkgYmVpbmcgZGlzY3Vzc2VkIHRoZXJlIGlz IG5vdCBjb21wYXJhYmxlIHRvIHlvdXIgDQogIGRlZmluaXRpb24uPC9TUEFOPjxvOnA+PC9vOnA+ PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJyI+Jm5ic3A7PC9TUEFOPjxv OnA+PC9vOnA+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogJ0Fy aWFsJywnc2Fucy1zZXJpZiciPkkgYmUgDQogIG1vcmUgdGhlbiBoYXBweSBpZiB5b3UgZ2l2ZSBt ZSBhbHRlcm5hdGl2ZSB0ZXJtcyB0byBVTkkgYW5kIA0KICBFTk5JLjwvU1BBTj48bzpwPjwvbzpw PjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZiciPiZuYnNwOzwvU1BBTj48 bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6 ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPkp1c3QgDQogIHVzZSB0aGUgZXhhbXBsZSBvZiBhIGN1 c3RvbWVyIHJlcXVlc3RpbmcgYSAyIE1iaXQvcyBzZXJ2aWNlIGZyb20gdGhlIFNESCANCiAgbmV0 d29yaywgb2Ygd2hpY2ggdGhlIGZpcnN0IGN1c3RvbWVyIGxvY2F0aW9uIGlzIGxvY2F0ZWQgYmVo aW5kIHRoZSBuZXR3b3JrIG9mIA0KICBvcGVyYXRvciBBIGFuZCB0aGUgc2Vjb25kIGVuZHBvaW50 IGlzIGxvY2F0ZWQgYmVoaW5kIHRoZSBuZXR3b3JrIG9mIG9wZXJhdG9yIA0KICBCLiBPcGVyYXRv ciBBIGFuZCBCIGludGVyY29ubmVjdCB2aWEgYSBTVE0tMSBpbnRlcmZhY2Ugd2l0aCBlYWNoIG90 aGVyLiBUaGUgDQogIGN1c3RvbWVyIGNvbm5lY3RzIHZpYSBhIDIgTWJpdC9zIEcuNzAzIGludGVy ZmFjZSB3aXRoIHRoZSBuZXR3b3JrcyBvZiBvcGVyYXRvciANCiAgQSBhbmQgQi48L1NQQU4+PG86 cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnIj4mbmJzcDs8 L1NQQU4+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQt RkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5XaGF0IA0KICB0ZXJtIHNob3VsZCBJIHVz ZSBmb3IgdGhlIGludGVyY29ubmVjdCBvZiB0aGUgY3VzdG9tZXIgdG8gdGhlIG5ldHdvcmtzIG9m IA0KICBvcGVyYXRvciBBIGFuZCBCPzwvU1BBTj48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJ Vj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0 OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPkku ZS4gDQogIGlmIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBjYWxsIHRoaXMgdGhlICJVTkkiLCB3aGF0 IHNob3VsZCBpdCBiZSBjYWxsZWQgDQogIHRoZW4/PC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwvRElW Pg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZB TUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJyI+Jm5ic3A7PC9TUEFOPjxvOnA+PC9vOnA+ PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmkn LCdzYW5zLXNlcmlmJyI+V2hhdCANCiAgdGVybSBzaG91bGQgSSB1c2UgZm9yIHRoZSBpbnRlcmNv bm5lY3Qgb2YgdGhlIG5ldHdvcmtzIG9mIG9wZXJhdG9yIEEgYW5kIA0KICBCPzwvU1BBTj48bzpw PjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZiciPkkuZS4gDQogIGlmIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBj YWxsIHRoaXMgdGhlICJFTk5JIiwgd2hhdCBzaG91bGQgaXQgYmUgY2FsbGVkIA0KICB0aGVuPzwv U1BBTj48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZici PiZuYnNwOzwvU1BBTj48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3 ZDsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPlRoYW5rcyANCiAgZm9yIHlv dXIgaGVscC48L1NQQU4+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5 N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5SZWdhcmRzLDwvU1BBTj48 bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6 ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPk1hYXJ0ZW48L1NQQU4+PG86cD48L286cD48L1A+PC9E SVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMt c2VyaWYnIj5QUy4gDQogIE5vdGUgdGhhdCBHLjgwMTIgZGVmaW5lcyBVTkkgYXMgZm9sbG93czog IjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBG T05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJyI+QW4gDQogIGludGVyZmFjZSB0aGF0 IGlzIHVzZWQgZm9yIHRoZSBpbnRlcmNvbm5lY3Rpb24gb2YgY3VzdG9tZXIgZXF1aXBtZW50IHdp dGggYSANCiAgbmV0d29yayBlbGVtZW50IG9mIHRoZSB0cmFuc3BvcnQgbmV0d29yay48L1NQQU4+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZB TUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+IjwvU1BBTj48bzpwPjwvbzpwPjwvUD48L0RJ Vj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZiciPiZuYnNwOzwvU1BBTj48bzpwPjwvbzpw PjwvUD48L0RJVj4NCiAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNl bnRlciIgYWxpZ249Y2VudGVyPg0KICA8SFIgYWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpF PTI+DQogIDwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006 IDEycHQiPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnIj5Gcm9tOjwvU1BBTj48L0I+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPiBCUlVO R0FSRCwgREVCT1JBSCANCiAgQSwgQVRUTEFCUyBbbWFpbHRvOmRicnVuZ2FyZEBhdHQuY29tXSA8 QlI+PEI+U2VudDo8L0I+IG1hYW5kYWcgMjcgYXByaWwgMjAwOSANCiAgMjM6MDA8QlI+PEI+VG86 PC9CPiBHcmVnIE1pcnNreTsgTWFhcnRlbiBWaXNzZXJzPEJSPjxCPkNjOjwvQj4gDQogIG1wbHMt dHBAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBbbXBscy10cF0gV2UgYXBwZWFyIHRv IGJlIGdvaW5nIGFyb3VuZCANCiAgaW4gY2lyY2xlcyAoUmU6QXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIHRyYW5zcG9ydCBwYXRoIA0KICByZXF1aXJlbWVudHMpPC9TUEFOPjxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7 IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+TWFh cnRlbiw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn Q2FsaWJyaScsJ3NhbnMtc2VyaWYnIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6 ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5JIA0KICB0aGlu ayB5b3UgaGF2ZSBvdmVyc2ltcGxpZmllZCB0aGUgZGlzY3Vzc2lvbiBpbiBNRUYgYW5kIGluIHNv IGRvaW5nIGhhdmUgDQogIGluYWNjdXJhdGVseSBzdW1tYXJpemVkLiBBcyBHcmVnIHNheXMsIE1F RiBpcyBvcmllbnRlZCB0b3dhcmRzIHNlcnZpY2VzIA0KICAoU0xBL1NMUykgYW5kIHRoZXkgYWxz byByZWNvZ25pemUgdGhhdCBzb21lIG9wZXJhdG9ycyBvbmx5IG5lZWQgc2ltcGxlIA0KICB0cm91 Ymxlc2hvb3RpbmcgdG9vbHMuIENvbnNpZGVyaW5nIHRoZSBvbi1nb2luZyBkaXNjdXNzaW9uIGlu IE1FRiwgZm9yIHRoZSANCiAgc2VydmljZSBvcGVyYXRvcnMgZ3JvdXAsIGl0IGlzIHF1ZXN0aW9u YWJsZSBpZiBZMTczMSBzaG91bGQgYmUgdXNlZCBieSBNUExTLVRQIA0KICBhcyBhIGJhc2VsaW5l IGFzIGl0IGlzIGNvbnNpZGVyZWQgaW5hZGVxdWF0ZS4gQW5kIEkgZG9u4oCZdCBzZWUgQVQmYW1w O1TigJlzIA0KICByZXF1aXJlbWVudHMgYXMgYW55IGRpZmZlcmVudCBmcm9tIEJULiBJIHRoaW5r IHdlIHNob3VsZCBmb2xsb3cgQWRyaWFu4oCZcyBhbmQgDQogIEJlbuKAmXMgcHJvcG9zYWwgdG8g ZGVmaW5lIHRoZSBhY3R1YWwgcmVxdWlyZW1lbnRzIGZvciBNUExTLVRQIGJlZm9yZSANCiAgcmVw bGljYXRpbmcgb3RoZXIgdGVjaG5vbG9naWVz4oCZIHNvbHV0aW9ucy48bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZ OiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5BbmQgDQogIHRoZSBVTkkvRU5OSSBiZWluZyBkaXNj dXNzZWQgdGhlcmUgaXMgbm90IGNvbXBhcmFibGUgdG8geW91ciANCiAgZGVmaW5pdGlvbi48bzpw PjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScs J3NhbnMtc2VyaWYnIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7 IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5EZWJvcmFoPG86cD48L286cD48 L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl cmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8RElWIA0KICBzdHlsZT0iQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAj YjVjNGRmIDFwdCBzb2xpZDsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctQk9UVE9NOiAwaW47 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdDsgQk9SREVSLUJPVFRP TTogbWVkaXVtIG5vbmUiPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPkZy b206PC9TUEFOPjwvQj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+IA0KICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAgPC9C PkdyZWcgTWlyc2t5PEJSPjxCPlNlbnQ6PC9CPiBNb25kYXksIEFwcmlsIDI3LCAyMDA5IDI6NDcg UE08QlI+PEI+VG86PC9CPiANCiAgTWFhcnRlbiBWaXNzZXJzPEJSPjxCPkNjOjwvQj4gbXBscy10 cEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IA0KICBbbXBscy10cF0gV2UgYXBwZWFy IHRvIGJlIGdvaW5nIGFyb3VuZCBpbiBjaXJjbGVzIChSZTpBc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgDQogIHRyYW5zcG9ydCBwYXRoIHJlcXVpcmVtZW50cyk8bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0Ij5EZWFyIE1hYXJ0ZW4s PEJSPnlvdSBkZWZpbml0ZWx5IA0KICBrbm93IGJ1dCBJJ2Qgbm90ZSB0aGF0IE1FRiBmb3JtdWxh dGVzIHJlcXVpcmVtZW50cyBmb3IgQ2FycmllciBFdGhlcm5ldCBhcyBhIA0KICBzZXJ2aWNlLCBp LmUuIGNsaWVudCBsYXllciBvZiBhIHRyYW5zcG9ydCBuZXR3b3JrLCBub3QgcmVxdWlyZW1lbnRz IGZvciB0aGUgDQogIHRyYW5zcG9ydCBuZXR3b3JrIGFzIHNlcnZlciBsYXllci4gVGh1cyByZXF1 aXJlbWVudHMgZXhwcmVzc2VkIGJ5IFNQcyBhdCBNRUYgDQogIGFyZSBub3QgYXBwbGljYWJsZSBv ciB0cmFuc2l0aXZlLCBpbiBteSB2aWV3LCB0byBNUExTLVRQLCBhdCBsZWFzdCBub3QgDQogIGF1 dG9tYXRpY2FsbHkuIDxCUj48QlI+UmVnYXJkcyw8QlI+R3JlZyBNaXJza3k8bzpwPjwvbzpwPjwv UD4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjIwMDkvNC8yNyBNYWFydGVuIFZpc3Nl cnMgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20iPm1h YXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPC9BPiZndDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPlRvbSw8QlI+PEJSPlRoaXMgQUlTIGRpc2N1c3Npb24gaGFzIGJlZW4gaGVs ZCBpbiBwcmV2aW91cyANCiAgdGVjaG5vbG9naWVzIGFzIHdlbGwsIGUuZy48QlI+RXRoZXJuZXQg T0FNLjxCUj5UaGUgcmVzdWx0IHdhcyB0aGF0IEFJUyANCiAgaW5zZXJ0aW9uIGlzIG9wdGlvbmFs IGFuZCB0aGF0IEV0aGVybmV0IGVxdWlwbWVudDxCUj4oc2VlIEcuODAyMSkgY2FuIGJlIA0KICBj b25maWd1cmVkIHRvIGluc2VydCBFdGhlcm5ldCBBSVMgb3IgdG8gbm90IGluc2VydDxCUj5FdGhl cm5ldCANCiAgQUlTLjxvOnA+PC9vOnA+PC9QPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxCUj4mZ3Q7IERvIHlvdSBzZWUgb3VyIChC VCdzKSANCiAgcmVxdWlyZW1lbnRzIHRvIGJlIHZlcnkgZGl2ZXJnZW50IGZyb20gdGhvc2Ugb2Y8 QlI+b3RoZXIgb3BlcmF0b3JzIA0KICBwYXJ0aWNpcGF0aW5nIGluIHRoaXMgZWZmb3J0PzxvOnA+ PC9vOnA+PC9QPjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+SSBzZWUgdGhlIHJlcXVpcmVt ZW50cyBmb3IgT0FNIHRoYXQgaGF2ZSBiZWVuIGV4cHJlc3NlZCBpbiANCiAgdGhpcyBtcGxzLXRw PEJSPmRpc2N1c3Npb24gYnkgQlQgcmVwcmVzZW50YXRpdmVzIHRvIGJlIGRpZmZlcmVudCBmcm9t IHRoZSANCiAgcmVxdWlyZW1lbnRzPEJSPmV4cHJlc3NlZCBieSBvdGhlciBvcGVyYXRvciByZXBy ZXNlbnRhdGl2ZXMuIEZvciANCiAgZXhhbXBsZTxCUj5kcmFmdC1iaGgtbXBscy10cC1vYW0teTE3 MzEgaXMgY28tYXV0aG9yZWQgYnkgcmVwcmVzZW50YXRpdmVzIG9mIA0KICBEVCwgRlQsPEJSPktQ TiwgS0RESSBhbmQgQ1QuIEkgYWxzbyBzZWUgdGhhdCB0aGUgT0FNIHJlcXVpcmVtZW50cyBkZWZp bmVkIGluIA0KICBNRUYgKHdpdGg8QlI+aW5wdXQgZnJvbSBlLmcuIEFUJmFtcDtUIGFuZCBWZXJp em9uKSBiZSBkaWZmZXJlbnQgZnJvbSB0aG9zZSANCiAgZXhwcmVzc2VkIGJ5IEJUPEJSPnJlcHJl c2VudGF0aXZlcy4gSSBzZWUgdGhhdCBNRUYgaXMgcmVxdWVzdGluZyB0byBzdXBwb3J0IGluIA0K ICBZLjE3MzEgZnJhbWU8QlI+bG9zcyBjb3VudGluZyBmb3IgbW9yZSB0aGVuIG9uZSBwcmlvcml0 eSBsZXZlbDsgaS5lLiBhbiANCiAgZXh0ZW5zaW9uIG9mIHRoZTxCUj5leGlzdGluZyBjYXBhYmls aXR5IHRoYXQgc3VwcG9ydCBmcmFtZSBsb3NzIGNvdW50aW5nIGZvciBhIA0KICBzaW5nbGUgcHJp b3JpdHk8QlI+KGkuZS4gYSBjYXNlIG9mIG1vcmUgT0FNLCBub3QgbGVzcyBPQU0pLjxCUj48QlI+ SSBzZWUgdGhhdCANCiAgdGhlIG9wZXJhdG9ycyBhY3RpdmUgaW4gTUVGIChlLmcuIEFUJmFtcDtU LCBWZXJpem9uLCBTcHJpbnQpIGhhdmU8QlI+Y3JlYXRlZCANCiAgYW5kIGFyZSBjcmVhdGluZyBF dGhlcm5ldCBVTkksIEV0aGVybmV0IEUtTk5JIGFuZCBFdGhlcm5ldCBWaXJ0dWFsPEJSPlVOSSAN CiAgc3BlY2lmaWNhdGlvbnMsIHdoaWxlIHJlcHJlc2VudGF0aXZlcyBvZiBCVCBzdGF0ZSB0aGF0 IHRoZXJlIGNhbid0IGJlPEJSPiJVTkkiIA0KICBvciAiRS1OTkkiIGludGVyZmFjZXMgYXNzb2Np YXRlZCB3aXRoIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MsIGFzPEJSPnRob3NlIA0KICBuZXR3 b3JrcyBhcmUgIm5vdCB0b3Agb2Ygc3RhY2siLiBJIHNlZSB0aGF0IG1hbnkgb3BlcmF0b3JzIA0K ICByZXF1aXJlPEJSPmNvbXBsaWFuY2Ugd2l0aCBNRUYgc3BlY2lmaWNhdGlvbnMsIGluY2x1ZGlu ZyB0aGUgRXRoZXJuZXQgDQogIFVOSTxCUj5zcGVjaWZpY2F0aW9uLjxCUj48QlI+SSBzZWUgdGhh dCBlLmcuIEtQTiBwcm92aWRlcyBhIFdob2xlc2FsZSANCiAgQnJvYWRiYW5kIEFjY2VzcyAoV0JB KSBzZXJ2aWNlIHZpYTxCUj5yb290ZWQtbXVsdGlwb2ludCBFVkNzLCB3aGljaCBFVkNzIA0KICB0 ZXJtaW5hdGUgb3V0c2lkZSB0aGUgS1BOIG5ldHdvcmsgKHJlZmVyPEJSPnRvIDxBIA0KICBocmVm PSJodHRwOi8vd3d3Lmtwbi13aG9sZXNhbGUuY29tL25sLzE2NzItQnJvYWRiYW5kX1NlcnZpY2Vz Lmh0bWwiIA0KICB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cua3BuLXdob2xlc2FsZS5jb20vbmwv MTY3Mi1Ccm9hZGJhbmRfU2VydmljZXMuaHRtbDwvQT4gDQogIGFuZDxCUj48QSANCiAgaHJlZj0i aHR0cDovL3d3dy5rcG4td2hvbGVzYWxlLmNvbS9ubC8xOTM2LVdob2xlc2FsZV9Ccm9hZGJhbmRf QWNjZXNzX1NlcnZpY2UuaHRtbCIgDQogIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5rcG4td2hv bGVzYWxlLmNvbS9ubC8xOTM2LVdob2xlc2FsZV9Ccm9hZGJhbmRfQWNjZXNzX1NlcnZpY2UuaHRt bDwvQT48QlI+KTsgDQogIGkuZS4gYSBwZWVyLWludGVyY29ubmVjdGlvbiBjYXNlIGFuZCBhIHBv dGVudGlhbCBjYXNlIGZvciBUQ00sIGEgY2FzZTxCUj53aGljaCANCiAgYWNjb3JkaW5nIHRvIEJU IHJlcHJlc2VudGF0aXZlcyBkb2VzIG5vdCBleGlzdC48QlI+PEJSPkkgc2VlIHRoYXQgdGhlIA0K ICAibWVzc2FnZSwgZmlsZSwgc3RyZWFtIiBjb25jZXB0cyBhcmUga2V5IHRvIEJUJ3M8QlI+Y29u c2lkZXJhdGlvbnMsIHdoaWxlIEkgDQogIGRvbid0IHNlZSBhbnkgb2YgdGhhdCBjb250cmlidXRl ZCBieSBvdGhlcjxCUj5vcGVyYXRvcnMuIFdoZW4gSSBsb29rIGF0IHRoZSANCiAgdGVsZWNvbSBu ZXR3b3JrIHN0YWNrIChzZWUgYXR0YWNoZWQgc2xpZGUpLDxCUj50aGVuIG1lc3NhZ2UsIGZpbGUg c3RyZWFtIGFyZSANCiAgaW1wb3J0YW50IGNvbmNlcHRzIGF0IExheWVyIDMgKE5HTikgd2hlcmU8 QlI+dGhvc2UgcmVwcmVzZW50IHRoZSANCiAgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBtYWluIHNl cnZpY2VzIChkYXRhLCB2b2ljZSw8QlI+dmlkZW8pLCB3aGVyZWFzICJFLUxpbmUsIA0KICBFLVRy ZWUsIEUtTEFOLCBQREggQ0VTLCBldGMiIGFyZSB0aGUgaW1wb3J0YW50PEJSPnNlcnZpY2VzIGF0 IExheWVyIDIgKFBUTikuIA0KICBUaGlzIHJhaXNlcyB0aGUgcXVlc3Rpb24gd2hhdCB0aGUgc2Nv cGUgb2Y8QlI+TVBMUy1UUCBpcyBmb3IgeW91OjxCUj5BKSANCiAgTVBMUy1UUCBpcyBhIExheWVy IDMgVHVubmVsL1BhdGggbGF5ZXIgdGVjaG5vbG9neSB3aGljaCBoYXMgdG8gc3VwcG9ydDxCUj50 aGUgDQogIElQIGJhc2VkIExheWVyIDMgU2VydmljZXMvQ2hhbm5lbCBsYXllcjxCUj5CKSBNUExT LVRQIGlzIGEgTGF5ZXIgMiBUdW5uZWwvUGF0aCANCiAgbGF5ZXIgdGVjaG5vbG9neSB3aGljaCBo YXMgdG8gc3VwcG9ydDxCUj50aGUgRVZDIGJhc2VkIExheWVyIDIgDQogIFNlcnZpY2VzL0NoYW5u ZWwgbGF5ZXIuPEJSPjxCUj5SZWdhcmRzLDxCUj48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiAjODg4 ODg4Ij5NYWFydGVuPC9TUEFOPjxvOnA+PC9vOnA+PC9QPg0KICA8RElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEJSPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPkZyb206IFRob21hcyBO YWRlYXUgDQogIFttYWlsdG86PEEgDQogIGhyZWY9Im1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9u LmNvbSI+dG5hZGVhdUBsdWNpZHZpc2lvbi5jb208L0E+XTxCUj5TZW50OiANCiAgdnJpamRhZyAy NCBhcHJpbCAyMDA5IDE1OjM1PEJSPlRvOiBNYWFydGVuIFZpc3NlcnM8bzpwPjwvbzpwPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPkNjOiAnQmVuIE5p dmVuLUplbmtpbnMnOyA8QSANCiAgaHJlZj0ibWFpbHRvOm1wbHMtdHBAaWV0Zi5vcmciPm1wbHMt dHBAaWV0Zi5vcmc8L0E+PEJSPlN1YmplY3Q6IFJlOiBbbXBscy10cF0gDQogIFdlIGFwcGVhciB0 byBiZSBnb2luZyBhcm91bmQgaW4gY2lyY2xlcyAoUmU6PEJSPkFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCANCiAgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTxCUj48QlI+PEJSPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPiZuYnNwOzwvU1BB Tj4gPFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+ Jm5ic3A7PC9TUEFOPiA8U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3Nh bnMtc2VyaWYnIj4mbmJzcDs8L1NQQU4+IDxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZiciPiZuYnNwOzwvU1BBTj5NYWFydGluLDxCUj48QlI+Jmd0OyAN CiAgQmVuLDxCUj4mZ3Q7PEJSPiZndDsgWW91ciBjb21wYW55IGlzIG9uZSBvZiB0aGUgbWFueSBv cGVyYXRvcnMgaW4gdGhlIHdvcmxkLCANCiAgYW5kIHRoZSBudW1iZXI8QlI+Jmd0OyBvZiBub2Rl cyBvdXRzaWRlIHlvdXIgbmV0d29yayBpcyBmYWN0b3JzIGxhcmdlciB0aGVuIA0KICB0aGUgbnVt YmVyIG9mPEJSPiZndDsgbm9kZXMgaW5zaWRlIHlvdXIgbmV0d29yay4gTXkgZXhwZXJpZW5jZSBp cyB0aGF0IA0KICBkaWZmZXJlbnQgb3BlcmF0b3JzPEJSPiZndDsgaGF2ZSBkaWZmZXJlbnQgc2V0 cyBvZiByZXF1aXJlbWVudHMuIE1hbnVmYWN0dXJlcnMgDQogIGhhdmUgdG8gc3VwcG9ydCB0aGU8 QlI+Jmd0OyBzdXBlcnNldCBvZiB0aG9zZSByZXF1aXJlbWVudHMuIEVhY2ggb3BlcmF0b3Igd2ls bCANCiAgdGhlbiBkZXBsb3kgdGhlPEJSPiZndDsgc3Vic2V0IG9mIHByb3ZpZGVkIGZlYXR1cmVz IHRoYXQgZml0cyBpdHMgbmVlZHMgKGFuZCANCiAgdHVybiBvZmYgb3IgZG9uJ3Q8QlI+Jmd0OyB1 c2UgdGhlIG90aGVycykuIFlvdXIgY29tcGFueSBmb3Igc29tZSB5ZWFycyBoYXMgDQogIGJlZW4g YXNraW5nIGZvciBsZXNzLDxCUj4mZ3Q7IG90aGVyIG9wZXJhdG9ycyBoYXZlIGJlZW4gYXNraW5n IGZvciBtb3JlLiANCiAgTWFudWZhY3R1cmVycyB0aHVzIGJ1aWxkPEJSPiZndDsgdGhlaXIgcHJv ZHVjdHMgd2l0aCBsb3RzIG9mIGNvbmZpZ3VyYWJpbGl0eSANCiAgdG8gc3VwcG9ydCBhbGwgdmFy aWF0aW9ucy48QlI+PEJSPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZiciPiZuYnNwOzwvU1BBTj4gPFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJyI+Jm5ic3A7PC9TUEFOPiA8U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj4mbmJzcDs8L1NQQU4+IDxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPiZuYnNwOzwvU1BB Tj5EbyB5b3Ugc2VlIG91ciAoQlQncykgDQogIHJlcXVpcmVtZW50cyB0byBiZSB2ZXJ5IGRpdmVy Z2VudCBmcm9tIHRob3NlPEJSPm9mIG90aGVyIG9wZXJhdG9ycyANCiAgcGFydGljaXBhdGluZyBp biB0aGlzIGVmZm9ydD8gPFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdz YW5zLXNlcmlmJyI+Jm5ic3A7PC9TUEFOPlVubGVzcyBvdXIgDQogIHJlcXVpcmVtZW50czxCUj5h cmUgdmVyeSBkaWZmZXJlbnQsIEkgYW0gY29uZmlkZW50IHZlbmRvcnMgd2lsbCBidWlsZCAob3Ig aGF2ZSANCiAgYnVpbHQpIHRoZWlyPEJSPmRldmljZXMgYmFzZWQgb24gb3VyIChzZW5zaWJsZSkg cmVxdWlyZW1lbnRzLjxCUj48QlI+Jmd0OyBJdCANCiAgaXMgbXkgb3BpbmlvbiB0aGF0IHdlIHNo b3VsZCBub3QgcmVtb3ZlIHdlbGwgZXN0YWJsaXNoZWQgZmVhdHVyZXM8QlI+Jmd0OyBsaWtlIA0K ICBBSVMsIFRDTSwgZnJhbWUgbG9zcyBjb3VudGluZywgZGVsYXkgbWVhc3VyZW1lbnQsIGxvb3Bi YWNrLCBldGM8QlI+Jmd0OyBiZWZvcmUgDQogIHRoZSBtYWpvcml0eSBvZiBvcGVyYXRvcnMgaGF2 ZSBhZ3JlZWQgdGhhdCBzdWNoIGZlYXR1cmVzIGFyZTxCUj4mZ3Q7IG5vdCANCiAgbG9uZ2VyIG5l Y2Vzc2FyeS48QlI+PEJSPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZiciPiZuYnNwOzwvU1BBTj4gPFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJyI+Jm5ic3A7PC9TUEFOPiA8U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj4mbmJzcDs8L1NQQU4+IDxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPiZuYnNwOzwvU1BB Tj5BZ2FpbiwgdGhhdCBpcyB5b3VyIA0KICBvcGluaW9uLCB3aGljaCBmcmFua2x5IHNlZW1zIHRv IGRpdmVyZ2UgZnJvbTxCUj53aGF0IG90aGVyIG9wZXJhdG9ycyBoYXZlIA0KICBleHByZXNzZWQu IEZ1cnRoZXJtb3JlLCBsZXQgbWUgcmVjb21tZW5kIHRoYXQgeW91PEJSPmdldCBvdXQgb2YgdGhl IGhhYml0IG9mIA0KICB0ZWxsaW5nIHlvdXIgY3VzdG9tZXJzIChvciBwb3RlbnRpYWwgb25lcyks IHdoYXQ8QlI+dGhleSByZXF1aXJlIGFmdGVyIHRoZXkgDQogIGhhdmUgYmVlbiBwbGFpbmx5IGNs ZWFyIGFib3V0IHdoYXQgdGhleSB3YW50LjxCUj5Vbmxlc3MgeW91IHRoaW5rIHdlIGRvbid0IA0K ICBrbm93IHdoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQuIElzIHRoaXMgcGVyaGFwczxCUj50aGUg Y2FzZT88QlI+PEJSPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fu cy1zZXJpZiciPiZuYnNwOzwvU1BBTj4gPFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nh bGlicmknLCdzYW5zLXNlcmlmJyI+Jm5ic3A7PC9TUEFOPiA8U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj4mbmJzcDs8L1NQQU4+IDxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPiZuYnNwOzwvU1BBTj4t LVRvbTxCUj48QlI+PEJSPjxCUj48QlI+Jmd0OyANCiAgUmVnYXJkcyw8QlI+Jmd0OyBNYWFydGVu PEJSPiZndDs8QlI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7IA0KICBG cm9tOiA8QSBocmVmPSJtYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnIj5tcGxzLXRwLWJv dW5jZXNAaWV0Zi5vcmc8L0E+IA0KICBbbWFpbHRvOjxBIA0KICBocmVmPSJtYWlsdG86bXBscy10 cC1ib3VuY2VzQGlldGYub3JnIj5tcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8L0E+XSANCiAgT248 QlI+Jmd0OyBCZWhhbGYgT2YgQmVuIE5pdmVuLUplbmtpbnM8QlI+Jmd0OyBTZW50OiB2cmlqZGFn IDI0IGFwcmlsIDIwMDkgDQogIDA6MTQ8QlI+Jmd0OyBUbzogPEEgDQogIGhyZWY9Im1haWx0bzpt cGxzLXRwQGlldGYub3JnIj5tcGxzLXRwQGlldGYub3JnPC9BPjxCUj4mZ3Q7IFN1YmplY3Q6IFtt cGxzLXRwXSANCiAgV2UgYXBwZWFyIHRvIGJlIGdvaW5nIGFyb3VuZCBpbiBjaXJjbGVzIChSZTo8 QlI+Jmd0OyBBc3NvY2lhdGVkPEJSPiZndDsgDQogIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggcmVxdWlyZW1lbnRzKTxCUj4mZ3Q7PEJSPiZndDsgDQogIENvbGxlYWd1ZXMsPEJSPiZndDs8 QlI+Jmd0OyBUaGUgY3VycmVudCBkZWJhdGVzIGFwcGVhciB0byBiZSBnb2luZyBhcm91bmQgaW4g DQogIGNpcmNsZXMgYW5kIGFjaGlldmluZzxCUj4mZ3Q7IG5vdGhpbmcgb2YgdmFsdWUgSU1PLiBU d28gbWFqb3Igb3BlcmF0b3JzIGhhdmUgDQogIGV4cHJlc3NlZCB0aGVpcjxCUj4mZ3Q7IG9waW5p b25zIGFuZCBubyBvcGVyYXRvciB0aGF0IEkgY2FuIHNlZSBoYXMgZGlzYWdyZWVkIA0KICB3aXRo IHRob3NlPEJSPiZndDsgb3BpbmlvbnMuPEJSPiZndDs8QlI+Jmd0OyBJIGFwb2xvZ2lzZSBmb3Ig YmVpbmcgZGlyZWN0IChhbmQgDQogIHBvc3NpYmx5IHJ1ZGUpIGJ1dCBJIGFtIGdldHRpbmc8QlI+ Jmd0OyB0aXJlZCBvZiBiZWluZyB0b2xkIGJ5IGZvbGtzIHdobyBkbyANCiAgbm90IHJlcHJlc2Vu dCBvcGVyYXRvcnMgd2hhdDxCUj4mZ3Q7IGZ1bmN0aW9uYWxpdHkgSSBuZWVkIG9yIHNob3VsZCBo YXZlIGluIG15IA0KICBuZXR3b3Jrcy48QlI+Jmd0OzxCUj4mZ3Q7IFRvIHB1dCBzb21lIGNvbnRl eHQgb24gQlQncyBjb21tZW50cyBpbiB0aGVzZSANCiAgdGhyZWFkczo8QlI+Jmd0OyBJIGhhdmUg dGhlIGxhcmdlc3QgTVBMUyBuZXR3b3JrIGluIHRoZSBVSy48QlI+Jmd0OyBJIGhhdmUgb25lIA0K ICBvZiB0aGUgbGFyZ2VzdCBNUExTIG5ldHdvcmtzIGdsb2JhbGx5IGRlbGl2ZXJpbmcgc2Vydmlj ZSB0bzxCUj4mZ3Q7IDE3MyANCiAgY291bnRyaWVzIHdpdGggb3ZlciAyMDAgMDAwIGN1c3RvbWVy IHBvcnRzIEkgaGF2ZSAob2ZmIHRoZSB0b3Agb2Y8QlI+Jmd0OyANCiAgbXk8QlI+Jmd0OyBoZWFk KTxCUj4mZ3Q7IGF0IGxlYXN0IGFub3RoZXIgMTAgTVBMUyBuZXR3b3JrcyBpbiBzcGVjaWZpYyAN CiAgY291bnRyaWVzIGNvdmVyaW5nIGF0PEJSPiZndDsgbGVhc3QgMyBjb250aW5lbnRzIGRlbGl2 ZXJpbmcgZGVkaWNhdGVkIHNlcnZpY2VzIA0KICB0byBwYXJ0aWN1bGFyIG1hcmtldDxCUj4mZ3Q7 IHNlZ21lbnRzLjxCUj4mZ3Q7PEJSPiZndDsgSSBoYXZlIGFuIGV4dHJlbWVseSANCiAgbGFyZ2Ug U0RIIG5ldHdvcmsgaW4gdGhlIFVLIGNvbnNpc3Rpbmcgb2Ygb3ZlciAzMDxCUj4mZ3Q7IDAwMCBz d2l0Y2hlcyBhbmQgDQogIHN1cHBvcnRpbmcgaW4gZXhjZXNzIG9mIDEgbWlsbGlvbiBjaXJjdWl0 cy48QlI+Jmd0OyBJIGhhdmUgYW4gZXh0cmVtZWx5IGxhcmdlIA0KICBTREggbmV0d29yayBnbG9i YWxseSBkZWxpdmVyaW5nIHNlcnZpY2UgaW48QlI+Jmd0OyAxMTAgDQogIGNvdW50cmllcy48QlI+ Jmd0OzxCUj4mZ3Q7IEkgd291bGQgbGlrZSB0byB0aGluayBteSBCVCBjb2xsZWFndWVzIGFuZCBJ IG1pZ2h0IA0KICBrbm93IGEgbGl0dGxlPEJSPiZndDsgc29tZXRoaW5nIGFib3V0IGJ1aWxkaW5n IGxhcmdlIHNjYWxlIG5ldHdvcmtzIGFuZCB0aGUgDQogIHJlcXVpcmVtZW50cyBvZjxCUj4mZ3Q7 IHRob3NlIG5ldHdvcmtzIGFuZCB0aGUgbmVlZHMgb2YgdGhlIGN1c3RvbWVycyB0aGF0IEkgDQog IGRlbGl2ZXIgc2VydmljZXM8QlI+Jmd0OyB0by48QlI+Jmd0OzxCUj4mZ3Q7IENhbiB3ZSBwbGVh c2Ugc3RvcCB0aGVzZSBjaXJjdWxhciANCiAgYXJndW1lbnRzIHdoaWNoIGFyZSBJTU8gZ29pbmc8 QlI+Jmd0OyBub3doZXJlIGFuZCBmb2N1cyBvbiB0aGUgdGFzayBpbiBoYW5kIA0KICB3aGljaCBp cyBkZWZpbmluZyB0aGU8QlI+Jmd0OyByZXF1aXJlbWVudHMgKGFuZCBsYXRlcjxCUj4mZ3Q7IHNv bHV0aW9ucykgYmVpbmcgDQogIGFza2VkIGZvciBieSBteXNlbGYsIG15IGNvbXBhbnkgYW5kIG15 IGNvbGxlYWd1ZXMgaW48QlI+Jmd0OyBvdGhlciBvcGVyYXRvcnMgDQogIG9uIHRoaXMgbGlzdC48 QlI+Jmd0OzxCUj4mZ3Q7IFRoYW5rczxCUj4mZ3Q7IEJlbjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0 OyANCiAgLS08QlI+Jmd0OzxCUj4mZ3Q7IEJlbiBOaXZlbi1KZW5raW5zPEJSPiZndDsgSVAsIERh dGEgJmFtcDsgQ29udGVudCANCiAgQXJjaGl0ZWN0PEJSPiZndDsgTmV0d29yayBJbmZyYXN0cnVj dHVyZSBBcmNoaXRlY3R1cmUsIEJUPEJSPiZndDs8QlI+Jmd0OyANCiAgRS1tYWlsOiA8QSANCiAg aHJlZj0ibWFpbHRvOmJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tIj5iZW5qYW1pbi5uaXZl bi1qZW5raW5zQGJ0LmNvbTwvQT48QlI+Jmd0OyANCiAgT2ZmaWNlOiArNDQgKDApMTQ3MyA2NDgy MjU8QlI+Jmd0OyBNb2JpbGU6ICs0NCAoMCk3OTE4IDA3NzIwNTxCUj4mZ3Q7IDxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPiZuYnNwOzwvU1BBTj4g RmF4OiArNDQgKDApMTMzMiANCiAgNTc4ODI3PEJSPiZndDs8QlI+Jmd0OyBCcml0aXNoIFRlbGVj b21tdW5pY2F0aW9ucyBwbGMuIFJlZ2lzdGVyZWQgb2ZmaWNlOiANCiAgPFNQQU4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj4mbmJzcDs8L1NQQU4+ODEgTmV3Z2F0 ZSANCiAgU3RyZWV0PEJSPiZndDsgTG9uZG9uPEJSPiZndDsgRUMxQSA3QUogPFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+Jm5ic3A7PC9TUEFOPiBS ZWdpc3RlcmVkIGluIA0KICBFbmdsYW5kIG5vOiA8U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj4mbmJzcDs8L1NQQU4+MTgwMDAwMDxCUj4mZ3Q7PEJS PiZndDs8QlI+Jmd0OyANCiAgT24gMjMvMDQvMjAwOSAwNzoyMywgIjxBIA0KICBocmVmPSJtYWls dG86bGl1Lmd1b21hbkB6dGUuY29tLmNuIj5saXUuZ3VvbWFuQHp0ZS5jb20uY248L0E+IiAmbHQ7 PEEgDQogIGhyZWY9Im1haWx0bzpsaXUuZ3VvbWFuQHp0ZS5jb20uY24iPmxpdS5ndW9tYW5AenRl LmNvbS5jbjwvQT4mZ3Q7PEJSPiZndDsgDQogIHdyb3RlOjxCUj4mZ3Q7PEJSPiZndDsmZ3Q7IGJl bjo8QlI+Jmd0OyZndDsgSSB1bmRlcnN0YW5kIHlvdXIgbWVhbmluZywgeW91IA0KICBzdGlsbCB3 aXNoIHRvIHJlc2lnbiBhbmQgbWFrZSBhIG1vcmU8QlI+Jmd0OyZndDsgcmVsaWFibGUgYW5kIGVm ZmVjdGl2ZSwgZWFzeSANCiAgdG8gb3BlcmF0b3IgYW5kIGVhc3kgdG8gbWFuYWdlIHBhY2tldDxC Uj4mZ3Q7Jmd0OyB0cmFuc3BvcnQgbmV0d29yayBsaWtlIG1lLiANCiAgYnV0IHdoeSBub3QgYXBw bHkgdGhpcyBTREgvU09ORVQgaW4gdGhlPEJSPiZndDsmZ3Q7IGZ1dHVyZSBtYXliZSB0aGUgZm9s bG93aW5nIA0KICBjYXVzZTo8QlI+Jmd0OyZndDsgPFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+Jm5ic3A7PC9TUEFOPiAxIGl0IGFkb3B0ZWQgY2ly Y3VpdCANCiAgc3dpdGNoaW5nIHRlY2hvbm9neSB0byBicmluZyBsb3dlciB1c2VmdWwgb2Y8QlI+ Jmd0OyZndDsgdGhlIHJlc291cmNlIHRoYW4gUFROIA0KICBuZXR3b3JrOzxCUj4mZ3Q7Jmd0OyA8 U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj4mbmJz cDs8L1NQQU4+IDIgaXQgY2FuJ3QgYmVhciBhbGwgDQogIGtpbmRzIG9mIHRyYWZmaWNzIGxpa2Ug UFROIG5ldHdvcmtzIGl0IG5vdGVkPEJSPiZndDsmZ3Q7IHRoYXQgd2UgY2FuJ3QgYXBwbHkgDQog IFNESC9TT05FVCBuZXR3b3JrIGluIHRoZSBmdXR1cmUgbm90IGJlY2F1c2UgaXQ8QlI+Jmd0OyZn dDsgaGF2ZSBhIGNvbXBsZXggT0FNIA0KICBmdW5jdGlvbnMuIHdoaWxlIG1vcmUgcGVvcGxlIGxp a2UgdG8gbW92ZSB0aGU8QlI+Jmd0OyZndDsgYWR2YW50YWdlcyBvZiA8U1BBTiANCiAgc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj4mbmJzcDs8L1NQQU4+dGhlIE9B TSBmdW5jdGlvbnMgaW4gDQogIFNESC9TT05FVCB0byBQVE4gbmV0d29ya3MuIGFuZDxCUj4mZ3Q7 Jmd0OyBBSVMvRkRJIGZ1bmN0aW9uIGlzIGEga2luZCBvZiBPQU0gDQogIGZ1bmN0aW9ucyBvZiBT REgvU09ORVQgLiB3ZSBzaG91bGQ8QlI+Jmd0OyZndDsgdXNlIGFuZCBleHRlbmQgdGhlIEFJUy9G REkgDQogIGZ1bmN0aW9ucyB0byBNUExTLVRQIDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgYmVz dCByZWdhcmRzPEJSPiZndDsmZ3Q7IA0KICBsaXU8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+ Jmd0OyZndDs8QlI+Jmd0OyZndDsgQmVuIE5pdmVuLUplbmtpbnMgJmx0OzxBIA0KICBocmVmPSJt YWlsdG86YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20iPmJlbmphbWluLm5pdmVuLWplbmtp bnNAYnQuY29tPC9BPiZndDs8QlI+Jmd0OyZndDsgDQogIDIwMDktMDQtMjMgMDc6NTg8QlI+Jmd0 OyZndDs8QlI+Jmd0OyZndDsgPFNQQU4gDQogIGxhbmc9WkgtQ04+5pS25Lu25Lq6PC9TUEFOPjxC Uj4mZ3Q7Jmd0OyAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzpsaXUuZ3VvbWFuQHp0ZS5jb20uY24i PmxpdS5ndW9tYW5AenRlLmNvbS5jbjwvQT4mZ3Q7LCAiQlJVTkdBUkQsIA0KICBERUJPUkFIIEEs IEFUVExBQlMiPEJSPiZndDsmZ3Q7ICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOmRicnVuZ2FyZEBh dHQuY29tIj5kYnJ1bmdhcmRAYXR0LmNvbTwvQT4mZ3Q7PEJSPiZndDsmZ3Q7IDxTUEFOIA0KICBs YW5nPVpILUNOPuaKhOmAgTwvU1BBTj48QlI+Jmd0OyZndDsgJmx0OzxBIA0KICBocmVmPSJtYWls dG86bXBscy10cEBpZXRmLm9yZyI+bXBscy10cEBpZXRmLm9yZzwvQT4mZ3Q7PEJSPiZndDsmZ3Q7 IDxTUEFOIA0KICBsYW5nPVpILUNOPuS4u+mimDwvU1BBTj48QlI+Jmd0OyZndDsgUmU6IFttcGxz LXRwXSBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgDQogIHRyYW5zcG9ydCBwYXRoIA0KICByZXF1 aXJlbWVudHM8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8 QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgDQogIE9uIDIxLzA0LzIwMDkgMDI6 NTksICI8QSANCiAgaHJlZj0ibWFpbHRvOmxpdS5ndW9tYW5AenRlLmNvbS5jbiI+bGl1Lmd1b21h bkB6dGUuY29tLmNuPC9BPiIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86bGl1Lmd1b21hbkB6dGUu Y29tLmNuIj5saXUuZ3VvbWFuQHp0ZS5jb20uY248L0E+Jmd0OzxCUj4mZ3Q7Jmd0OyANCiAgd3Jv dGU6PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyBEZWJvcmFoOjxCUj4mZ3Q7Jmd0OyZndDsg bWF5YmUgd2hhdCB5b3UgDQogIHNhaWQgaXMgcmlnaHQuIGJ1dCBJIGNhbid0IGNvbXBsZXRlbHkg YWdyZWUgeW91cjxCUj4mZ3Q7Jmd0OyANCiAgb3BpbmlvbnMuPEJSPiZndDsmZ3Q7Jmd0OyBJTU8u IG1wbHMtdHAgaXMgcmVnYXJkIGFzIHRyYW5zcG9ydCBuZXR3b3JrIGxpa2UgDQogIFNESC9TT05F VC4gc28gaXQ8QlI+Jmd0OyZndDsmZ3Q7IHNob3VsZCBoYXZlIEFJUy9GREkgZnVjdGlvbnMgYXMg DQogIFNESC9TT05FVC48QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyBkbyB5b3UgdGhp bmsgDQogIHNvLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBObyB3ZSBtdXN0IGFzc2VzcyB0aGUg cmVxdWlyZW1lbnRzIGZvciBwYWNrZXQgDQogIHRyYW5zcG9ydCBuZXR3b3JrczxCUj4mZ3Q7Jmd0 OyBzdXBwb3J0aW5nIHRoZSBuZWVkcyBvZiBvcGVyYXRvcnMgdG9kYXkgYW5kIGluIA0KICB0aGUg ZnV0dXJlLiBXZSBtdXN0PEJSPiZndDsmZ3Q7IG5vdCBibGluZGx5IHJlY3JlYXRlIFNESC9TT05F VC4gSWYgd2UgZG8gc28gDQogIHdpdGhvdXQgY29uc2lkZXJhdGlvbiB0bzxCUj4mZ3Q7Jmd0OyBo b3cgb3BlcmF0b3JzJyBuZWVkcyBhbmQgcmVxdWlyZW1lbnRzIG1heSANCiAgaGF2ZSBldm9sdmVk IChhbmQgY29udGludWU8QlI+Jmd0OyZndDsgdG8gZXZvbHZlIGluIGZ1dHVyZSkgd2Ugd2lsbCBo YXZlIA0KICBmYWlsZWQgSU1PIGFuZCBJIHdvdWxkIHNldmVyZWx5PEJSPiZndDsmZ3Q7IHF1ZXN0 aW9uIHRoZSB2YWx1ZSBvZiB0aGUgd29yayB3ZSANCiAgd2lsbCBoYXZlIHByb2R1Y2VkLiBJZiB3 ZSBqdXN0PEJSPiZndDsmZ3Q7IHJlY3JlYXRlIFNESC9TT05FVCB0aGVuIHdoYXQgaXMgdGhlIA0K ICBwdXJwb3NlIG9mIHRoZSB3b3JrIGFuIG9wZXJhdG9yPEJSPiZndDsmZ3Q7IHdvdWxkIGJlIGJl dHRlciBvZmYganVzdCBkZXBsb3lpbmcgDQogIGV4aXN0aW5nIFNESC9TT05FVCBlcXVpcG1lbnQu PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IA0KICBCZW48QlI+Jmd0OyZndDs8 QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZn dDsgDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPEJSPiZndDsmZ3Q7IFpURSANCiAgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXM8QlI+Jmd0OyZndDsgDQogIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbDxC Uj4mZ3Q7Jmd0OyANCiAgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIA0KICBvYmxpZ2F0ZWQ8QlI+Jmd0OyZndDsgdG8gbWFpbnRhaW4gc2Vj cmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgDQogIHRoZSBjb250ZW50cyBv ZjxCUj4mZ3Q7Jmd0OyB0aGlzPEJSPiZndDsgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuPEJSPiZn dDsmZ3Q7IA0KICBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZDxCUj4mZ3Q7Jmd0OyANCiAgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIA0KICB0aGV5PEJSPiZn dDsmZ3Q7IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgDQogIHBsZWFzZSBub3RpZnk8QlI+Jmd0OyZndDsgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgDQogIGluIHRoaXMgbWVzc2FnZTxCUj4mZ3Q7 Jmd0OyBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjxCUj4mZ3Q7Jmd0OyANCiAg VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF IEFudGktU3BhbTxCUj4mZ3Q7IA0KICBzeXN0ZW0uPEJSPiZndDs8QlI+Jmd0OyANCiAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBtcGxzLXRw IG1haWxpbmcgDQogIGxpc3Q8QlI+Jmd0OyA8QSBocmVmPSJtYWlsdG86bXBscy10cEBpZXRmLm9y ZyI+bXBscy10cEBpZXRmLm9yZzwvQT48QlI+Jmd0OyA8QSANCiAgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwIiANCiAgdGFyZ2V0PV9ibGFuaz5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8L0E+PEJSPiZndDs8QlI+ Jmd0OzxCUj4mZ3Q7IA0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj4mZ3Q7IG1wbHMtdHAgbWFpbGluZyANCiAgbGlzdDxCUj4mZ3Q7IDxBIGhyZWY9 Im1haWx0bzptcGxzLXRwQGlldGYub3JnIj5tcGxzLXRwQGlldGYub3JnPC9BPjxCUj4mZ3Q7IDxB IA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHAi IA0KICB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscy10cDwvQT48bzpwPjwvbzpwPjwvUD48L0RJVj48L0RJVj4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsIA0KICBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCI+PEJSPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPm1wbHMtdHAgDQogIG1haWxpbmcgbGlz dDxCUj48QSBocmVmPSJtYWlsdG86bXBscy10cEBpZXRmLm9yZyI+bXBscy10cEBpZXRmLm9yZzwv QT48QlI+PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscy10cCIgDQogIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzLXRwPC9BPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU TUw+DQo= ------_=_NextPart_001_01C9C8DC.5BA886BC-- From BETTS01@nortel.com Wed Apr 29 08:10:04 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5C53A6CCA for ; Wed, 29 Apr 2009 08:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.423 X-Spam-Level: X-Spam-Status: No, score=-5.423 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC0KhuAK-atB for ; Wed, 29 Apr 2009 08:10:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F11723A6C2D for ; Wed, 29 Apr 2009 08:10:00 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3TFBIV03147; Wed, 29 Apr 2009 15:11:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 11:11:15 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516F4CC27@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AATTltgAA8a1TAAAuYvEA== References: <008601c9c89a$b53aacd0$6c02a8c0@china.huawei.com> From: "Malcolm Betts" To: , , Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:10:04 -0000 Andy, Maarten, Without going into all of the details, I think that you are describing a function that should be performed by the element management alarm reporting and control function.=20 i.e. does a certain condition, or combination of conditions, result in an autonomous notification to a management system, or is it simply a condition that is reported "on demand". >From the perspective of this discussion we should focus on the primitives that are delivered to the alarm reporting and control function. The key "information elements" that must be provided are: 1) Has the trail failed 2) Has the failure been caused by i) a "local" fault i.e. in the equipment or on an incoming link: or ii) by a "remote" fault i.e. in another node or on an incoming link that terminates on a remote node. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of andy.bd.reid@bt.com Sent: Wednesday, April 29, 2009 10:46 AM To: maarten.vissers@huawei.com; IBryskin@advaoptical.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) Maarten, >From this, you are agreeing the basic operational model. I was trying to be both concise and reasonably general to different maintenance scenarios (and the posting was still pretty long). In the detailed scenario you describe, the distinction between 'proactive' and 'reactive' maintenance is whether the guy wants the alarm raised to him immediately and he will deal with it ahead of any trouble ticket raised by a customer or whether the guy only wants to know the alarm status in front of him at the time the customer raises the trouble ticket. In both cases the 'suppressed' alarm is still needed in the higher level management system. Exact procedures for fault locations will vary, I'm sure, as do the systems available to help. Importantly, there will inevitably be a variety of residual faults which occur which do also sit neatly into prior assumptions of what can go wrong. So fault localisation *must* include procedures to deal with things which do not say 'I am broken, fix me'. What is damaging to the fault localisation process is if there is false information around. Andy =20 Andy Reid Chief Network Services Strategist BT Innovate =20 Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com =20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. =20 > -----Original Message----- > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > Sent: 29 April 2009 08:18 > To: Reid,ABD,Andy,CXM R; IBryskin@advaoptical.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Andy, >=20 > You speak about "local" and "remote" alarms. I had to read the rest of > the sentence three times before I understood that you meant "primary"=20 > and "secondary/consequential" alarms. > A primary alarm is an alarm that reports a fault cause that needs=20 > fixing, whereas a secondary/consequential alarm is a report from a=20 > client that it's connection is interrupted due to a server fault. > Do I understand your use of "local" and "remote" correct? >=20 > I agree with you that the main task of fault management is to know if=20 > there is a fault that they can repair, what the fault is, where the=20 > location of this fault is and then who to send to repair the fault. >=20 > I agree with you that service management needs to know about the=20 > status of the service when the customer calls. I do not agree with you > that in general "these guys wants to know that the service is 'down'=20 > **before** the customer is on the phone!". >=20 > I have very explicit information of a few operators that a large=20 > number of service contracts will not be as you describe. Values given=20 > to me are 90% of service contracts (representing 70% of service=20 > connections) are without pro-active monitoring. In those contracts the > repair time starts after the report of the customer and verification=20 > by the operator. What is important in those cases is that the service=20 > manager can simply retrieve status information when the customer is on > the phone. >=20 > The other 10% of service contracts (representing 30% of service=20 > connections) are with pro-active monitoring. In those contracts the=20 > repair time starts after the defect is detected. I assume that "these=20 > guys wants to know that the service is 'down' **before** the customer=20 > is on the phone!" > is applicable for a subset of those service connections. For the other > subset I have understood that it is sufficient when the=20 > status/performance information of the service connection can be=20 > retrieved instantaneously when the customer is on the phone. Is this=20 > also the case in BT? >=20 > Besides the service connections, we have tunnel/path connections,=20 > section connections and physical media connections. Those connections=20 > have no direct "service" > associated with it; i.e. those connections are part of the network's=20 > infrastructure. There is as such no "service manager" interested in=20 > the status of those infrastructure connections. The only people=20 > interested in alarms from those infrastructure connections are the=20 > fault management people. > Do I understand this correct? >=20 > > The service maintenance guys *have* got an alarm - the customer has=20 > > not got their service! They also notice that it is not > fixing itself.=20 > > So they investigate, ie start localising. >=20 > I do not understand why a service maintenance guy will have to do the=20 > fault localization... I have always been told that fault management is > responsible for locating a fault. If the fault is an open matrix=20 > connection (which either interrupts a tunnel/path connection or a=20 > service/channel connection), then the fault management people=20 > responsible for the layer network will be triggered by the loss of CC=20 > alarm and start the localization procedure. >=20 > When a network deploys AIS, it is possible to trigger this open matrix > fault localization procedure without any complex network correlation=20 > procedure. > Seems to be advantages... >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] > Sent: woensdag 29 april 2009 0:26 > To: maarten.vissers@huawei.com; IBryskin@advaoptical.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > Maarten, Igor, >=20 > Before dealing with the specific scenarios, let me go through again=20 > what I said in an earlier posting about the way alarm 'suppression'=20 > actually works. >=20 > There are two sides to maintenance - the faulty kit guys who fix=20 > faulty cards, mend cable breaks, etc, etc, and end service guys who=20 > deal with customer service. 'Suppressed' > alarms are only suppressed to the faulty kit guys who fix cards, etc.=20 > The distinction between 'local' and 'remote' > alarms is very important to ensure that these faulty kit guys are=20 > directed to the place where the actual fault lies and not to places=20 > affected by, but remote from the actual fault. >=20 > However, these 'suppressed' alarms are still forwarded to the service=20 > maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they=20 > want to know whether the end service is 'up' or 'down' irrespective of > the cause and irrespective of the presence of AIS. AIS most=20 > emphatically does not suppress this alarm! These guys wants to know=20 > that the service is 'down' > before the customer is on the phone! >=20 > So to go to Maarten's first example, the faulty kit guys are not=20 > getting any alarms telling them to fix broken kit - which is correct. >=20 > The service maintenance guys *have* got an alarm - the customer has=20 > not got their service! They also notice that it is not fixing itself.=20 > So they investigate, ie start localising. In practice, the first thing > they will do (and most management systems will do it automatically by=20 > some form of correlation engine) is check for any corresponding faulty > kit alarms. In this case, they will find no faulty kit alarms and=20 > suspect a misconfiguration, localise it, and fix it. >=20 > To go to Maarten's second example, the faulty kit guys are getting an=20 > alarm telling them to fix the link between A and B. >=20 > The service maintenance guys have also got an alarm - again the=20 > customer has not got their service. They also notice that it is not=20 > fixing itself. So they investigate, ie start localising. Again, the=20 > first thing they will do (and most management systems will do it=20 > automatically by some form of correlation engine) is check for any=20 > corresponding faulty kit alarms. In this case, they will find the=20 > corresponding faulty kit alarm and can check of the repair plan and=20 > status should the customer call and ask. >=20 > As these particular scenarios illustrate, the right alarms have been=20 > directed to the right maintenance guys. The service guys deal with the > service configurations, the faulty kit guys deal with faulty kit. >=20 > Occasionally, there will be faulty kit which is not reporting itself=20 > despite the best design efforts in the equipment. In this case, the=20 > service maintenance guys are likely to have a series of alarms which=20 > can be correlated to help localise the fault and the diagnosed fault=20 > can then be passed to the faulty kit guys for fixing. >=20 > Another important point. There is little room here for > *false* information coming to either set of maintenance guys.=20 > When trying to localise a fault, no additional information is better=20 > than wrong additional information. >=20 > That is my concern with the trying to inject packet based AIS. There=20 > is significant room for creating false information. As I've already=20 > indicted there is AIS specific configuration to do which will be prone > to misconfiguration. > We should then note that the thing that the AIS is supposed to be=20 > identifying is the present of misconfiguration - but achieving this=20 > requires configuration. So why should one configuration be more=20 > reliable than the other? >=20 > But there are other scenarios. For example, consider port mapping (or=20 > in ITU-T speak, a degenerate subnetwork) where we terminate the=20 > section layer on one interface and blindly ship all the packets out on > an other interface in a new section. > If we assume AIS is being used, a fault in the incoming section should > result in the injection of AIS. But how does it know what label values > to use? Or does it not inject AIS? > In which case we have the poor service maintenance guys actively=20 > looking for a configuration error which does not exist. A similar=20 > scenario would exist if we choose to use a sort of ADM where the=20 > forwarding table was made up of exception (add/drop) label values and=20 > a default outgoing port. Again, the same dilemma exists. >=20 > Andy >=20 >=20 >=20 >=20 > Andy Reid > Chief Network Services Strategist > BT Innovate > =20 >=20 > Office: +44 (0)1277 322038 > Mobile: +44 (0)7917 025451 > Fax : +44 (0)1277 324015 > Email: andy.bd.reid@bt.com >=20 > =20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in=20 > England no. 1800000 This electronic message contains information from=20 > British Telecommunications plc which may be privileged or=20 > confidential. The information is intended to be for the use of the=20 > individual(s) or entity named above. If you are not the intended=20 > recipient be aware that any disclosure, copying, distribution or use=20 > of the contents of this information is prohibited. If you have=20 > received this electronic message in error, please notify us by=20 > telephone or email (to the numbers or address above) immediately. > Activity and use of the British Telecommunications plc email system is > monitored to secure its effective operation and for other lawful=20 > business purposes. Communications using this system will also be=20 > monitored and may be recorded to secure effective operation and for=20 > other lawful business purposes. >=20 > =20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > Sent: 28 April 2009 20:25 > > To: 'Igor Bryskin' > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Igor, > >=20 > > > b) Is it beneficial if a server trail notifies its clients about > > a detected problem to suppress the OAM traffic > >=20 > > The suppression we have been talking about is alarm > suppression, not > > OAM traffic suppression. > >=20 > > Loss of CC is intended to detect an open connection fault > in a matrix. > > E.g. assume a connection that starts in node A, passes > through nodes B > > and C and ends in node D. > > Nodes A, B, C and D have a connection function in which a matrix=20 > > connection is to be set up to support this connection from A to D. > >=20 > > What is now possible is that the matrix connection in node B is=20 > > unintentionally removed (i.e. a continuity fault). > > Node D will now detect a loss of CC. Node D does not detect > any other > > faults. > > Node C will not detect any fault. > > Node B will not detect any fault. > > Node A will not detect any fault if the matrix connection in B is=20 > > removed in one direction only. > >=20 > > In order to detect this open matrix connection fault it is > required to > > report the loss of CC to the management system and to start a fault=20 > > localization procedure to locate the faulty matrix (i.e. in node B). > > If such reporting is not done, then there is a hidden fault, which=20 > > keeps the connection interrupted much longer; i.e. until > one or more > > customers start to complain that their connections are lost. > > Then you hae to find in a big network without any fault > report which > > node has the fault. > >=20 > > What happens now if the fault is not an open matrix > connection but a > > server layer fault (e.g. a link fault between nodes A and B). > > Node D will now detect a loss of CC. Node D does not detect > any other > > faults. > > Node C will not detect any fault. > > Node B will detect a loss of signal fault. > > Node A will not detect any fault if the link from A to B is > broken in > > one direction only. > >=20 > > If loss of CC is unconditionally reported, then node D will report=20 > > loss of CC. Node B will report loss of signal. > > - If node B and node D are managed by the same management > system it is > > possible to perform a fault correlation in this management > system to > > filter out the loss of CC from node D. > > What is necessary is to know that connection A-D is > supported by the > > link A to B. In larger multi-layer networks such > correlations become > > complex. If such correlations are not performed, then the > loss of CC > > will trigger a fault localisation action, which of course will not=20 > > find a matrix fault (i.e. waste of time). > > - If node B is managed by another management system then > node D, there > > is no correlation possible. Node D's management system will > see only > > the loss of CC and will start fault localization, and will not find=20 > > any fault in its part of the network. > >=20 > > Use of AIS will help in distinguishing between connection > interruption > > due to an open matrix connection fault and due to server fault. AIS=20 > > provides the necessary filter for loss of CC. > >=20 > > What happens for the case a port detects a signal fail condition is=20 > > the following; assume a 10G port that detects a signal fail > condition. > > This implies that all traffic is lost. > > Assume that there are 1000 client connections active (e.g.=20 > > with an average bandwidth of 5 Mbit/s). When AIS is to be generated=20 > > for those 1000 client conenctions the port has to generate 1000 AIS=20 > > frames/packets per second. Each AIS frame/packet is 64 > bytes/512 bits. > > Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005 > > Gbit/s) of traffic in a further empty 10G port. This isn't any real=20 > > complexity. > >=20 > > --------- > >=20 > > The alternative is to declare that open matrix connections > are never a > > fault condition (i.e. are always intentional and thus known > by network > > management). Under such starting point it is not necessary > to detect > > an open matrix connection as a fault condition. Now it is > not longer > > necessary to distinguish between connection interruption > due to open > > matrix and server layer fault as the first condition isn't a fault=20 > > anylonger. Under this condition it is not useful that a > server trail > > informs its clients about a detected server trail problem that=20 > > interrupts the client connections. > >=20 > > If we go for this latter approach and if in future an open matrix=20 > > connection would be a fault condition, then this is a > hidden fault and > > you need a lot more work to locate the fault (there are no > alarms that > > help you). > >=20 > > Regards, > > Maarten > >=20 > >=20 > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: dinsdag 28 april 2009 18:20 > > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Shahram, > >=20 > > I was addressing Neil's comments about the dynamic > re-routing, which > > is different from protection switchover onto pre-provisioned=20 > > protection connection. True, in the latter case the server layer=20 > > wouldn't notice that and will keep notifying the client > that the trail > > is broken. But this does not change anything. The big 2 > questions in > > my mind are: > >=20 > > a) Is the OAM of a given layer is (i) self-sufficient and > > (ii) scalable enough, so that operator can rely on it > completely and > > independently from what is happening in the lower layers? > >=20 > > b) Is it beneficial if a server trail notifies its clients about a=20 > > detected problem to suppress the OAM traffic and possibly > unnecessary > > switchovers until the server trail corrects itself? > >=20 > > Cheers, > > Igor > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davarish@yahoo.com] > > Sent: Tuesday, April 28, 2009 11:57 AM > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Igor, > >=20 > > Your assumption is that there is a control plane that sets up the=20 > > binding between client and server layer and that such > binding will be > > removed via the control plane when a reroute happens. I think this=20 > > assumption is not always true. For example in a linear 1:1 or 1+1=20 > > protection, there is no signalling to withdraw the binding at=20 > > intermediate nodes. In > > 1:1 there is APS, but that is end-to-end and is sent on the backup=20 > > path not working path. > >=20 > > -Shahram > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > Sent: April-28-09 11:27 AM > > To: davarish@yahoo.com; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Shahram, > >=20 > > Let's assume that connection A-B-C-D-E is dynamically > provisioned by a > > control plane. As part of such provisioning a binding is created=20 > > between this connection and network C at the two adaptation > points on > > either side of the link provided by network C. When the > connection is > > torn down, this binding is removed as a part of the cleanup process. > > The re-routing of the connection onto A-F-G-E is indistinguishable=20 > > from the connection tear down as far as link C is concerned. > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davarish@yahoo.com] > > Sent: Tuesday, April 28, 2009 11:15 AM > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Hi Igor, > >=20 > > How does the server know the client is rerouted? Assume the > following > > networks: A-B-C-D-E (working) and A-F-G-E (protection).=20 > > Assume each has its own server layer such as MPLS, MPLS-TP, ATM,=20 > > SONET, etc. Assume that network C uses MPLS-TP as server layer. > > Network C will never know there was a protection switching done for=20 > > the client layer. > >=20 > > -Shahram > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin > > Sent: April-28-09 11:05 AM > > To: Maarten Vissers; neil.2.harrison@bt.com; > nurit.sprecher@nsn.com; > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Neil. > >=20 > > I actually agree with Maarten on this. I don't quite > understand why do > > you keep talking about fixed client-server relationship. It > is fixed > > as long as the client layer connection configured this way > (statically > > or dynamically). > > As soon as the connection is re-routed, this relationship is broken=20 > > (because this is a part of the re-routing process) and hence the=20 > > server trail termination points will know that the server trail now=20 > > serves one connection less, whereas some other server trail(s) will=20 > > learn that they serve from now on one connection more. These new=20 > > client-server relationships are fixed until the next re-routing. > >=20 > > Cheers, > > Igor > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > Sent: Tuesday, April 28, 2009 8:48 AM > > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com;=20 > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Neil, > >=20 > > > However, if the client can dynamically change its routing > > in response > > > to link failures in its topology (because some server > layer network > > > has failed....which may or may not belong to the same > > operating party > > > as the > > > client) then there is no fixed client/server relationship.=20 > >=20 > > I believe there is a fixed client/server relationship also in this=20 > > case in the network. This relationship is broken when the > connection > > is rerouted. > > Such reroute will remove the CP/FP and as such will stop the AIS=20 > > generation. > >=20 > > There is no difference with what we do today in SDH and OTN.=20 > > A client/server relationship is fixed until the point in > time that the > > connection is either teardown or rerouted. When either of the two=20 > > cases occur, the AIS generation is stopped. > > Until such action is performed, AIS is generated during signal fail=20 > > condition period and inserted into the connection. > >=20 > > In MPLS-TP we have the requirement that MPLS-TP must be able to=20 > > operate without control plane. This implies that it will operate=20 > > without restoration, and that there will not be frequent rerouteing=20 > > ongoing. Result is that client/server relationships will last until=20 > > the connection is teardown. > >=20 > > Regards, > > Maarten > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > neil.2.harrison@bt.com > > Sent: dinsdag 28 april 2009 10:07 > > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Nurit, > >=20 > > I believe the reason we need this discussion is that there is an=20 > > unstated assumption here that the client/server > relationship is fixed. > > However, if the client can dynamically change its routing > in response > > to link failures in its topology (because some server layer network=20 > > has failed....which may or may not belong to the same > operating party > > as the > > client) then there is no fixed client/server relationship. > >=20 > > Refer to my post earlier today and consider what this means in the=20 > > case of a cl-ps IP client layer network or a some SVC-based=20 > > co-ps/co-cs mode client layer network. The key point here is the=20 > > *routing process* in the client is independent of the server layer=20 > > network....so there is not a fixed client/server relationship. > > Further, there is also no requirement for the server to > keep track of > > where its client traffic routings are at any epoch.....indeed why=20 > > should it in the general case where these are independent layer=20 > > networks? > >=20 > > So the only OAM requirement that is critical is that the OAM of the=20 > > client and server layer networks are independent. It is thus not=20 > > sensible to make client layer alarm supression a 'requirement' > > here...in fact if this is in the OAM requirements then it is=20 > > technically wrong and should be removed IMO. > >=20 > > regards, Neil > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > Nurit (NSN - > > > IL/Hod HaSharon) > > > Sent: 28 April 2009 08:46 > > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > > transportpathrequirements) > > >=20 > > > If we agree that the requirement is included, so why do we > > keep with > > > the endless discussions on this requirement? > > >=20 > > > -----Original Message----- > > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > > Sent: Tuesday, April 28, 2009 10:44 AM > > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > > > Adrian Farrel > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectional transport > > > pathrequirements) > > >=20 > > > I think that the requirements are defined in section 2.2.8 of > > > draft-ietf-mpls-tp-oam-requirements-01 > > >=20 > > > Italo > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > Nurit (NSN > > > > - IL/Hod HaSharon) > > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > > To: hhelvoort@chello.nl; Adrian Farrel > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > > > transport pathrequirements) > > > >=20 > > > > Huub, > > > > I think that the requirement is to provide a mechanism to > > suppress > > > > alarms in the networks, to ensure that alarms that may be > > > generated by > > > > client layers as a result of a failure condition in the > > server layer > > > > may be suppressed. > > > > Every thing else is a solution, etc.=20 > > > > I propose to phrase the requirement appropriately and > > conclude the > > > > discussion on this in the context of the requirements > > (until we are > > > > getting to the solution phase). > > > > This requirement is included in the OAM requirement draft.=20 > > > > Best regards, > > > > NUrit > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On > > > > Behalf Of ext Huub van Helvoort > > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > > To: Adrian Farrel > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > bidirectional transport > > > > path requirements) > > > >=20 > > > > Hi Adrian, > > > >=20 > > > > You wrote: > > > >=20 > > > > > Isn't the solution here the same as the one I proposed > > for "TCM"? > > > >=20 > > > > Indeed, and that we do not have to around in circles about TCM. > > > >=20 > > > > How about: > > > > the requirement is that a server layer shall inform its > > clients that > > > > it has detected a service interuption, this to ensure that the=20 > > > > clients can inhibit (unnecessary) alarms. > > > >=20 > > > > Cheers, Huub. > > > >=20 > > > > -- > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > http://www.van-helvoort.eu/=20 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Always remember that you are unique...just like everyone else... > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Wed Apr 29 09:05:33 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379CD3A6E30 for ; Wed, 29 Apr 2009 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.54 X-Spam-Level: ** X-Spam-Status: No, score=2.54 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU-txmDI-AwN for ; Wed, 29 Apr 2009 09:05:30 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1CEC43A6B39 for ; Wed, 29 Apr 2009 09:05:29 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIV000HDE34C5@szxga04-in.huawei.com> for mpls-tp@ietf.org; Thu, 30 Apr 2009 00:06:40 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIV006ZQE344D@szxga04-in.huawei.com> for mpls-tp@ietf.org; Thu, 30 Apr 2009 00:06:40 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIV00HV6E2WTQ@szxml01-in.huawei.com>; Thu, 30 Apr 2009 00:06:40 +0800 (CST) Date: Wed, 29 Apr 2009 18:06:35 +0200 From: Maarten Vissers In-reply-to: To: "'BRUNGARD, DEBORAH A, ATTLABS'" Message-id: <006201c9c8e4$7aa28620$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_gzc7GGOawkIgnGSHr+6m7Q)" Thread-index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJAABtoogAAkDyVAAA3bmWAABEo/YA== Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 16:05:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gzc7GGOawkIgnGSHr+6m7Q) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Deborah, =20 You are going far beyond my question. Let me try to clarify by using a figure, In this figure there is an admin domain A and an admin domain B. These two domains are interconnected via an 802.3 interface over which = the EVC layer is continued. My question is how we should refer to this = interface between domains A and B? Is this interface referred to as ENNI? If it is = not referred to as ENNI, what is then the name to use for this class of interfaces? =20 =20 (A) (B)=20 ------------------------------------ | EVC EVC | ------------------------------------ | Tunnel | |802.3| | Tunnel | ------------ ------- -----------=20 | T.Media | ^ | T.Media | ------------ | ----------- |=20 ENNI? =20 Regards, Maarten _____ =20 From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: woensdag 29 april 2009 17:06 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Maarten, =20 I only have confirmed that what you have given as an example of an ENNI below is G707 and G704. You missed the point. This is a typical ITU interface standard. It can be used as an INNI, ENNI, or UNI. Since you = are twisting words, I=A1=AFll try to be clearer. =20 Yes, we need interface standards. If we have standards and have defined = the technology properly, we do not need your =A1=B0interworking ENNI=A1=B1. = You have twisted the definition of a standard interface used between (hopefully) = all equipment, within a domain and between domains, to rationalize your =A1=B0ENNI=A1=B1. Two operators (or Forum) agreeing on a physical = encapsulation, J1, vlans, or label to be used may be described in the industry as = interworking, but then it can be said that every interface is interworking. The fiber connectors are interworking. Instead of saying, I=A1=AFm connecting the = fiber, we will say, we are interworking the fiber. This is silly. Rather than = use a much hyped non-specific term, here, in ITU and IETF, we should be = specific.=20 =20 The ENNI/UNIs defined in MPLS Forum and MEF are a profile of existing standards. They provide a consistent interpretation of an existing = standard for the members of the Forum (i.e. improved readability for the members, = as we all know, ITU Recommendations and IETF RFCs are often not standalone documents or not easy reading for non-involved readers). It is = questionable for IETF or ITU to define an ENNI or UNI as it will be difficult for all = the members to agree =A8C otherwise all the options should not be in the = original standard if they were not needed. =20 Connecting two networks together using a standard physical layer is not really an ENNI (as Neil has said over and over). If we start defining UNI/ENNI/INNI for all the technologies in ITU and IETF, we will have an operational nightmare. =20 Deborah =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: Wednesday, April 29, 2009 3:23 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) =20 Deborah, =20 Thank you for confirming that we can speak about ENNI for non-IP layer interconnects. As you indicate, an ENNI also exists when we interconnect = two SDH admin domains via an STM-N. =20 Do you also agree that we can speak about an ENNI when we interconnect a Metro/Carrier Ethernet Network admin domain A with a Metro/Carrier = Etherent Network admin domain B via an 802.3 interface over which the EVC layer = is transported? =20 Regards, Maarten =20 _____ =20 From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: dinsdag 28 april 2009 17:52 To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Exactly =A8C G707 defined the ENNI for SDH and G703/G704 for PDH. The = PHY and framing is defined (per layer). This definition is very different from = your earlier email. It does not require supporting PDH<->SDH interworking, or = PDH OAM in SDH, or OAM interworking between a client/server as one of your earlier emails required: =20 >For this case it is necessary to develop ETH<>PW(client) layer=20 > network > interworking specifications. To limit the complexity of such layer=20 > network interworking, it is beneficial to select the MPLS-TP PW OAM = > to > use the Y.7131 OAM PDUs as proposed in draft-bhh-mpls-tp-oam-y1731. = > I.e. > both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs =20 The interconnection of equipment (at one layer) should not put any restrictions on other layers. =20 From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: Tuesday, April 28, 2009 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) =20 Deborah, =20 > And the UNI/ENNI being discussed there is not comparable to your definition. =20 I be more then happy if you give me alternative terms to UNI and ENNI. =20 Just use the example of a customer requesting a 2 Mbit/s service from = the SDH network, of which the first customer location is located behind the network of operator A and the second endpoint is located behind the = network of operator B. Operator A and B interconnect via a STM-1 interface with = each other. The customer connects via a 2 Mbit/s G.703 interface with the networks of operator A and B. =20 What term should I use for the interconnect of the customer to the = networks of operator A and B? I.e. if it is not possible to call this the "UNI", what should it be = called then? =20 What term should I use for the interconnect of the networks of operator = A and B? I.e. if it is not possible to call this the "ENNI", what should it be = called then? =20 Thanks for your help. Regards, Maarten PS. Note that G.8012 defines UNI as follows: "An interface that is used = for the interconnection of customer equipment with a network element of the transport network." =20 _____ =20 From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: maandag 27 april 2009 23:00 To: Greg Mirsky; Maarten Vissers Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) Maarten, =20 I think you have oversimplified the discussion in MEF and in so doing = have inaccurately summarized. As Greg says, MEF is oriented towards services (SLA/SLS) and they also recognize that some operators only need simple troubleshooting tools. Considering the on-going discussion in MEF, for = the service operators group, it is questionable if Y1731 should be used by MPLS-TP as a baseline as it is considered inadequate. And I don=A1=AFt = see AT&T=A1=AFs requirements as any different from BT. I think we should = follow Adrian=A1=AFs and Ben=A1=AFs proposal to define the actual requirements = for MPLS-TP before replicating other technologies=A1=AF solutions. =20 And the UNI/ENNI being discussed there is not comparable to your = definition. =20 Deborah =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To: Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) =20 Dear Maarten, you definitely know but I'd note that MEF formulates requirements for Carrier Ethernet as a service, i.e. client layer of a transport network, = not requirements for the transport network as server layer. Thus = requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically.=20 Regards, Greg Mirsky 2009/4/27 Maarten Vissers Tom, This AIS discussion has been held in previous technologies as well, e.g. Ethernet OAM. The result was that AIS insertion is optional and that Ethernet = equipment (see G.8021) can be configured to insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's) requirements to be very divergent from those of other operators participating in this effort? I see the requirements for OAM that have been expressed in this mpls-tp discussion by BT representatives to be different from the requirements expressed by other operator representatives. For example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, KPN, KDDI and CT. I also see that the OAM requirements defined in MEF = (with input from e.g. AT&T and Verizon) be different from those expressed by = BT representatives. I see that MEF is requesting to support in Y.1731 frame loss counting for more then one priority level; i.e. an extension of the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet = Virtual UNI specifications, while representatives of BT state that there can't = be "UNI" or "E-NNI" interfaces associated with packet transport networks, = as those networks are "not top of stack". I see that many operators require compliance with MEF specifications, including the Ethernet UNI specification. I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service = via rooted-multipoint EVCs, which EVCs terminate outside the KPN network = (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml ); i.e. a peer-interconnection case and a potential case for TCM, a case which according to BT representatives does not exist. I see that the "message, file, stream" concepts are key to BT's considerations, while I don't see any of that contributed by other operators. When I look at the telecom network stack (see attached = slide), then message, file stream are important concepts at Layer 3 (NGN) where those represent the characteristics of the main services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important services at Layer 2 (PTN). This raises the question what the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to = support the IP based Layer 3 Services/Channel layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to = support the EVC based Layer 2 Services/Channel layer. Regards, Maarten -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re: Associated bidirectional transport path requirements) Maartin, > Ben, > > Your company is one of the many operators in the world, and the number > of nodes outside your network is factors larger then the number of > nodes inside your network. My experience is that different operators > have different sets of requirements. Manufacturers have to support the > superset of those requirements. Each operator will then deploy the > subset of provided features that fits its needs (and turn off or don't > use the others). Your company for some years has been asking for less, > other operators have been asking for more. Manufacturers thus build > their products with lots of configurability to support all variations. Do you see our (BT's) requirements to be very divergent from = those of other operators participating in this effort? Unless our = requirements are very different, I am confident vendors will build (or have built) = their devices based on our (sensible) requirements. > It is my opinion that we should not remove well established features > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > before the majority of operators have agreed that such features are > not longer necessary. Again, that is your opinion, which frankly seems to diverge from what other operators have expressed. Furthermore, let me recommend that = you get out of the habit of telling your customers (or potential ones), what they require after they have been plainly clear about what they want. Unless you think we don't know what we are talking about. Is this = perhaps the case? --Tom > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009 0:14 > To: mpls-tp@ietf.org > Subject: [mpls-tp] We appear to be going around in circles (Re: > Associated > bidirectional transport path requirements) > > Colleagues, > > The current debates appear to be going around in circles and achieving > nothing of value IMO. Two major operators have expressed their > opinions and no operator that I can see has disagreed with those > opinions. > > I apologise for being direct (and possibly rude) but I am getting > tired of being told by folks who do not represent operators what > functionality I need or should have in my networks. > > To put some context on BT's comments in these threads: > I have the largest MPLS network in the UK. > I have one of the largest MPLS networks globally delivering service to > 173 countries with over 200 000 customer ports I have (off the top of > my > head) > at least another 10 MPLS networks in specific countries covering at > least 3 continents delivering dedicated services to particular market > segments. > > I have an extremely large SDH network in the UK consisting of over 30 > 000 switches and supporting in excess of 1 million circuits. > I have an extremely large SDH network globally delivering service in > 110 countries. > > I would like to think my BT colleagues and I might know a little > something about building large scale networks and the requirements of > those networks and the needs of the customers that I deliver services > to. > > Can we please stop these circular arguments which are IMO going > nowhere and focus on the task in hand which is defining the > requirements (and later > solutions) being asked for by myself, my company and my colleagues in > other operators on this list. > > Thanks > Ben > > > -- > > Ben Niven-Jenkins > IP, Data & Content Architect > Network Infrastructure Architecture, BT > > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 > > British Telecommunications plc. Registered office: 81 Newgate Street > London > EC1A 7AJ Registered in England no: 1800000 > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > wrote: > >> ben: >> I understand your meaning, you still wish to resign and make a more >> reliable and effective, easy to operator and easy to manage packet >> transport network like me. but why not apply this SDH/SONET in the >> future maybe the following cause: >> 1 it adopted circuit switching techonogy to bring lower useful of >> the resource than PTN network; >> 2 it can't bear all kinds of traffics like PTN networks it noted >> that we can't apply SDH/SONET network in the future not because it >> have a complex OAM functions. while more people like to move the >> advantages of the OAM functions in SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should >> use and extend the AIS/FDI functions to MPLS-TP ; >> >> best regards >> liu >> >> >> >> Ben Niven-Jenkins >> 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >> , "BRUNGARD, DEBORAH A, ATTLABS" >> >> =B3=AD=CB=CD >> >> =D6=F7=CC=E2 >> Re: [mpls-tp] Associated bidirectional transport path requirements >> >> >> >> >> >> >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" >> wrote: >> >>> Deborah: >>> maybe what you said is right. but I can't completely agree your >> opinions. >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it >>> should have AIS/FDI fuctions as SDH/SONET. >>> >>> do you think so. >> >> No we must assess the requirements for packet transport networks >> supporting the needs of operators today and in the future. We must >> not blindly recreate SDH/SONET. If we do so without consideration to >> how operators' needs and requirements may have evolved (and continue >> to evolve in future) we will have failed IMO and I would severely >> question the value of the work we will have produced. If we just >> recreate SDH/SONET then what is the purpose of the work an operator >> would be better off just deploying existing SDH/SONET equipment. >> >> >> Ben >> >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents of >> this > communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message >> are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =20 --Boundary_(ID_gzc7GGOawkIgnGSHr+6m7Q) Content-type: text/html; charset=GB2312 Content-transfer-encoding: quoted-printable Deborah, You are going far beyond my question. Let me = try to clarify=20 by using a figure, In this figure there is an admin domain A and an = admin domain=20 B. These two domains are interconnected via an 802.3 interface over = which the=20 EVC layer is continued. My question is how we should refer to this = interface=20 between domains A and B? Is this interface referred to as ENNI? If it is = not=20 referred to as ENNI, what is then the name to use for this class of=20 interfaces?     (A)      =                (B) ------------------------------------ |   EVC             &nbs= p;        EVC  =20 | ------------------------------------ | Tunnel |   |802.3|   | Tunnel = | ------------   = -------   ----------- | = T.Media |      ^      | = T.Media=20 | ------------      |   &n= bsp; -----------           &nbs= p;      =20 |           &nbs= p;     =20 ENNI? Regards, Maarten From: BRUNGARD, DEBORAH A, ATTLABS=20 [mailto:dbrungard@att.com] Sent: woensdag 29 april 2009=20 17:06 To: Maarten Vissers Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Maarten, I=20 only have confirmed that what you have given as an example of an ENNI = below is=20 G707 and G704. You missed the point. This is a typical ITU interface = standard.=20 It can be used as an INNI, ENNI, or UNI. Since you are twisting words, = I=A1=AFll try=20 to be clearer. Yes,=20 we need interface standards. If we have standards and have defined the=20 technology properly, we do not need your =A1=B0interworking ENNI=A1=B1. = You have=20 twisted the definition of a standard interface used between (hopefully) = all=20 equipment, within a domain and between domains, to rationalize your = =A1=B0ENNI=A1=B1. Two=20 operators (or Forum) agreeing on a physical encapsulation, J1, vlans, or = label=20 to be used may be described in the industry as interworking, but then it = can be=20 said that every interface is interworking. The fiber connectors are=20 interworking. Instead of saying, I=A1=AFm connecting the fiber, we will = say, we are=20 interworking the fiber. This is silly. Rather than use a much hyped = non-specific=20 term, here, in ITU and IETF, we should be specific. = The=20 ENNI/UNIs defined in MPLS Forum and MEF are a profile of existing = standards.=20 They provide a consistent interpretation of an existing standard for the = members=20 of the Forum (i.e. improved readability for the members, as we all know, = ITU=20 Recommendations and IETF RFCs are often not standalone documents or not = easy=20 reading for non-involved readers). It is questionable for IETF or ITU to = define=20 an ENNI or UNI as it will be difficult for all the members to agree =A8C = otherwise=20 all the options should not be in the original standard if they were not=20 needed. Connecting=20 two networks together using a standard physical layer is not really an = ENNI (as=20 Neil has said over and over). If we start defining UNI/ENNI/INNI for all = the=20 technologies in ITU and IETF, we will have an operational=20 nightmare. Deborah From: Maarten = Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: Wednesday, April = 29, 2009=20 3:23 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Deborah, Thank=20 you for confirming that we can speak about ENNI for non-IP layer = interconnects.=20 As you indicate, an ENNI also exists when we interconnect two SDH admin = domains=20 via an STM-N. Do you=20 also agree that we can speak about an ENNI when we interconnect a = Metro/Carrier=20 Ethernet Network admin domain A with a Metro/Carrier Etherent Network = admin=20 domain B via an 802.3 interface over which the EVC layer is=20 transported? Regards, Maarten From: BRUNGARD, = DEBORAH=20 A, ATTLABS [mailto:dbrungard@att.com] Sent: dinsdag 28 april = 2009=20 17:52 To: Maarten Vissers Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Exactly=20 =A8C G707 defined the ENNI for SDH and G703/G704 for PDH. The PHY and = framing is=20 defined (per layer). This definition is very different from your earlier = email.=20 It does not require supporting PDH<->SDH interworking, or PDH OAM = in SDH,=20 or OAM interworking between a client/server as one of your earlier = emails=20 required: >For this case it is necessary to develop=20 ETH<>PW(client) layer > network >    interworking = specifications. To=20 limit the complexity of such layer >    network interworking, it = is=20 beneficial to select the MPLS-TP PW OAM > to >    use the Y.7131 OAM PDUs = as proposed=20 in draft-bhh-mpls-tp-oam-y1731. > I.e. >    both=20 Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs The=20 interconnection of equipment (at one layer) should not put any = restrictions on=20 other layers. From: Maarten = Vissers=20 [mailto:maarten.vissers@huawei.com] Sent: Tuesday, April 28, = 2009=20 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Deborah, >=20 And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. I be=20 more then happy if you give me alternative terms to UNI and=20 ENNI. Just=20 use the example of a customer requesting a 2 Mbit/s service from the SDH = network, of which the first customer location is located behind the = network of=20 operator A and the second endpoint is located behind the network of = operator B.=20 Operator A and B interconnect via a STM-1 interface with each other. The = customer connects via a 2 Mbit/s G.703 interface with the networks of = operator A=20 and B. What=20 term should I use for the interconnect of the customer to the networks = of=20 operator A and B? I.e.=20 if it is not possible to call this the "UNI", what should it be called=20 then? What=20 term should I use for the interconnect of the networks of operator A and = B? I.e.=20 if it is not possible to call this the "ENNI", what should it be called=20 then? Thanks=20 for your help. Regards, Maarten PS.=20 Note that G.8012 defines UNI as follows: "An=20 interface that is used for the interconnection of customer equipment = with a=20 network element of the transport network." From: BRUNGARD, = DEBORAH=20 A, ATTLABS [mailto:dbrungard@att.com] Sent: maandag 27 april = 2009=20 23:00 To: Greg Mirsky; Maarten Vissers Cc:=20 mpls-tp@ietf.org Subject: RE: [mpls-tp] We appear to be going = around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Maarten, I=20 think you have oversimplified the discussion in MEF and in so doing have = inaccurately summarized. As Greg says, MEF is oriented towards services=20 (SLA/SLS) and they also recognize that some operators only need simple=20 troubleshooting tools. Considering the on-going discussion in MEF, for = the=20 service operators group, it is questionable if Y1731 should be used by = MPLS-TP=20 as a baseline as it is considered inadequate. And I don=A1=AFt see = AT&T=A1=AFs=20 requirements as any different from BT. I think we should follow = Adrian=A1=AFs and=20 Ben=A1=AFs proposal to define the actual requirements for MPLS-TP before = replicating=20 other technologies=A1=AF solutions. And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. Deborah From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of=20 Greg Mirsky Sent: Monday, April 27, 2009 2:47 = PM To:=20 Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: = [mpls-tp]=20 We appear to be going around in circles (Re:Associated bidirectional = transport=20 path requirements) Dear Maarten, you = definitely=20 know but I'd note that MEF formulates requirements for Carrier Ethernet = as a=20 service, i.e. client layer of a transport network, not requirements for = the=20 transport network as server layer. Thus requirements expressed by SPs at = MEF are=20 not applicable or transitive, in my view, to MPLS-TP, at least not=20 automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com= > Tom, This AIS discussion has been held in = previous=20 technologies as well, e.g. Ethernet OAM. The result was that AIS = insertion=20 is optional and that Ethernet equipment (see G.8021) can be = configured to=20 insert Ethernet AIS or to not insert Ethernet AIS. > Do you see = our (BT's)=20 requirements to be very divergent from those of other operators = participating=20 in this effort? I see the requirements for OAM that have been = expressed in=20 this mpls-tp discussion by BT representatives to be different from = the=20 requirements expressed by other operator representatives. For=20 example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives = of DT,=20 FT, KPN, KDDI and CT. I also see that the OAM requirements defined in = MEF=20 (with input from e.g. AT&T and Verizon) be different from those = expressed=20 by BT representatives. I see that MEF is requesting to support in = Y.1731=20 frame loss counting for more then one priority level; i.e. an = extension of=20 the existing capability that support frame loss counting for a single = priority (i.e. a case of more OAM, not less OAM). I see that = the=20 operators active in MEF (e.g. AT&T, Verizon, Sprint) have created = and are=20 creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtual UNI=20 specifications, while representatives of BT state that there can't = be "UNI"=20 or "E-NNI" interfaces associated with packet transport networks, = as those=20 networks are "not top of stack". I see that many operators = require compliance=20 with MEF specifications, including the Ethernet = UNI specification. I=20 see that e.g. KPN provides a Wholesale Broadband Access (WBA) service=20 via rooted-multipoint EVCs, which EVCs terminate outside the KPN = network=20 (refer to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.h= tml=20 and http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_= Access_Service.html );=20 i.e. a peer-interconnection case and a potential case for TCM, a = case which=20 according to BT representatives does not exist. I see that the = "message,=20 file, stream" concepts are key to BT's considerations, while I don't = see any=20 of that contributed by other operators. When I look at the telecom = network=20 stack (see attached slide), then message, file stream are important = concepts=20 at Layer 3 (NGN) where those represent the characteristics of the = main=20 services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH = CES, etc"=20 are the important services at Layer 2 (PTN). This raises the question = what=20 the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 = Tunnel/Path layer=20 technology which has to support the IP based Layer 3 Services/Channel = layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has = to=20 support the EVC based Layer 2 Services/Channel=20 layer. Regards, Maarten -----Original Message----- From: Thomas = Nadeau=20 [mailto:tnadeau@lucidvision.com] S= ent:=20 vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: = [mpls-tp] We=20 appear to be going around in circles (Re: Associated bidirectional = transport=20 path requirements) Maartin, >=20 Ben, > > Your company is one of the many operators in the = world, and=20 the number > of nodes outside your network is factors larger then = the=20 number of > nodes inside your network. My experience is that = different=20 operators > have different sets of requirements. Manufacturers = have to=20 support the > superset of those requirements. Each operator will = then=20 deploy the > subset of provided features that fits its needs (and = turn off=20 or don't > use the others). Your company for some years has been = asking=20 for less, > other operators have been asking for more. = Manufacturers thus=20 build > their products with lots of configurability to support all = variations. Do you see = our (BT's)=20 requirements to be very divergent from those of other operators = participating=20 in this effort? Unless our=20 requirements are very different, I am confident vendors will build = (or have=20 built) their devices based on our (sensible) = requirements. > It is=20 my opinion that we should not remove well established features > = like AIS,=20 TCM, frame loss counting, delay measurement, loopback, etc > = before the=20 majority of operators have agreed that such features are > not = longer=20 necessary. Again, that = is your=20 opinion, which frankly seems to diverge from what other operators = have=20 expressed. Furthermore, let me recommend that you get out of the = habit of=20 telling your customers (or potential ones), what they require after = they have=20 been plainly clear about what they want. Unless you think we don't = know what=20 we are talking about. Is this perhaps the case? --Tom >=20 Regards, > Maarten > > -----Original = Message----- >=20 From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org]=20 On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april = 2009=20 0:14 > To: mpls-tp@ietf.org >=20 Subject: [mpls-tp] We appear to be going around in circles (Re: >=20 Associated > bidirectional transport path = requirements) > >=20 Colleagues, > > The current debates appear to be going = around in=20 circles and achieving > nothing of value IMO. Two major operators = have=20 expressed their > opinions and no operator that I can see has = disagreed=20 with those > opinions. > > I apologise for being = direct (and=20 possibly rude) but I am getting > tired of being told by folks who = do not=20 represent operators what > functionality I need or should have in = my=20 networks. > > To put some context on BT's comments in these=20 threads: > I have the largest MPLS network in the UK. > I = have one=20 of the largest MPLS networks globally delivering service to > 173=20 countries with over 200 000 customer ports I have (off the top = of >=20 my > head) > at least another 10 MPLS networks in specific = countries=20 covering at > least 3 continents delivering dedicated services to=20 particular market > segments. > > I have an extremely = large=20 SDH network in the UK consisting of over 30 > 000 switches and = supporting=20 in excess of 1 million circuits. > I have an extremely large SDH = network=20 globally delivering service in > 110 countries. > > I = would=20 like to think my BT colleagues and I might know a little > = something about=20 building large scale networks and the requirements of > those = networks and=20 the needs of the customers that I deliver services > = to. > >=20 Can we please stop these circular arguments which are IMO going > = nowhere=20 and focus on the task in hand which is defining the > requirements = (and=20 later > solutions) being asked for by myself, my company and my = colleagues=20 in > other operators on this list. > > Thanks >=20 Ben > > > -- > > Ben Niven-Jenkins > = IP,=20 Data & Content Architect > Network Infrastructure = Architecture,=20 BT > > E-mail: benjamin.niven-jenkins@bt.c= om >=20 Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > = Fax: +44 = (0)1332=20 578827 > > British Telecommunications plc. Registered = office: 81 Newgate=20 Street > London > EC1A 7AJ Registered = in England=20 no: 1800000 > > >=20 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> &g= t;=20 wrote: > >> ben: >> I understand your meaning, = you still=20 wish to resign and make a more >> reliable and effective, easy = to=20 operator and easy to manage packet >> transport network like = me. but=20 why not apply this SDH/SONET in the >> future maybe the = following=20 cause: >> 1 it adopted = circuit=20 switching techonogy to bring lower useful of >> the resource = than PTN=20 network; >> 2 it can't = bear all=20 kinds of traffics like PTN networks it noted >> that we can't = apply=20 SDH/SONET network in the future not because it >> have a = complex OAM=20 functions. while more people like to move the >> advantages of = the OAM = functions in=20 SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of = OAM=20 functions of SDH/SONET . we should >> use and extend the = AIS/FDI=20 functions to MPLS-TP ; >> >> best regards >>=20 liu >> >> >> >> Ben Niven-Jenkins = <benjamin.niven-jenkins@bt.c= om> >>=20 2009-04-23 07:58 >> >> =CA=D5=BC=FE=C8=CB >>=20 <liu.guoman@zte.com.cn>,=20 "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com> >> = =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> = =D6=F7=CC=E2 >> Re: [mpls-tp] Associated = bidirectional=20 transport path=20 requirements >> >> >> >> >><= BR>>> >>=20 On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> &g= t;>=20 wrote: >> >>> Deborah: >>> maybe what = you said=20 is right. but I can't completely agree your >>=20 opinions. >>> IMO. mpls-tp is regard as transport network = like=20 SDH/SONET. so it >>> should have AIS/FDI fuctions as=20 SDH/SONET. >>> >>> do you think=20 so. >> >> No we must assess the requirements for = packet=20 transport networks >> supporting the needs of operators today = and in=20 the future. We must >> not blindly recreate SDH/SONET. If we do = so=20 without consideration to >> how operators' needs and = requirements may=20 have evolved (and continue >> to evolve in future) we will have = failed=20 IMO and I would severely >> question the value of the work we = will have=20 produced. If we just >> recreate SDH/SONET then what is the = purpose of=20 the work an operator >> would be better off just deploying = existing=20 SDH/SONET equipment. >> >> >>=20 Ben >> >> >> >> >> >&g= t;=20 -------------------------------------------------------- >> ZTE = Information Security Notice: The information contained in = this >> mail=20 is solely property of the sender's organization. This mail >>=20 communication is confidential. Recipients named above are = obligated >>=20 to maintain secrecy and are not permitted to disclose the contents=20 of >> this > communication to others. >> This = email and=20 any files transmitted with it are confidential and >> intended = solely=20 for the use of the individual or entity to whom they >> are = addressed.=20 If you have received this email in error please notify >> the=20 originator of the message. Any views expressed in this = message >> are=20 those of the individual sender. >> This message has been = scanned for=20 viruses and Spam by ZTE Anti-Spam > system. > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >= > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp=20 mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_gzc7GGOawkIgnGSHr+6m7Q)-- From andy.bd.reid@bt.com Wed Apr 29 09:05:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FC23A7167 for ; Wed, 29 Apr 2009 09:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=1.632, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcD9FqTRBSDb for ; Wed, 29 Apr 2009 09:05:34 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 864743A6B39 for ; Wed, 29 Apr 2009 09:05:33 -0700 (PDT) Received: from E03MVW2-UKDY.domain1.systemhost.net ([193.113.30.50]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 17:06:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 17:06:52 +0100 Message-ID: In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516F4CC27@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AATTltgAA8a1TAAAuYvEAACQFFA From: To: , , X-OriginalArrivalTime: 29 Apr 2009 16:06:54.0974 (UTC) FILETIME=[840441E0:01C9C8E4] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 16:05:37 -0000 Malcolm, I think this could be suitable way forward. Andy Andy Reid Chief Network Services Strategist BT Innovate =20 Office: +44 (0)1277 322038 Mobile: +44 (0)7917 025451 Fax : +44 (0)1277 324015 Email: andy.bd.reid@bt.com =20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000=20 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. =20 > -----Original Message----- > From: Malcolm Betts [mailto:betts01@nortel.com]=20 > Sent: 29 April 2009 16:11 > To: Reid,ABD,Andy,CXM R; maarten.vissers@huawei.com;=20 > IBryskin@advaoptical.com > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was=20 > Associatedbidirectionaltransportpathrequirements) >=20 > Andy, Maarten, >=20 > Without going into all of the details, I think that you are=20 > describing a function that should be performed by the element=20 > management alarm reporting and control function.=20 >=20 > i.e. does a certain condition, or combination of conditions,=20 > result in an autonomous notification to a management system,=20 > or is it simply a condition that is reported "on demand". >=20 > From the perspective of this discussion we should focus on=20 > the primitives that are delivered to the alarm reporting and=20 > control function. >=20 > The key "information elements" that must be provided are: > 1) Has the trail failed > 2) Has the failure been caused by i) a "local" fault i.e. in=20 > the equipment or on an incoming link: or ii) by a "remote"=20 > fault i.e. in another node or on an incoming link that=20 > terminates on a remote node. >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of andy.bd.reid@bt.com > Sent: Wednesday, April 29, 2009 10:46 AM > To: maarten.vissers@huawei.com; IBryskin@advaoptical.com > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) >=20 > Maarten, >=20 > From this, you are agreeing the basic operational model. I=20 > was trying to be both concise and reasonably general to=20 > different maintenance scenarios (and the posting was still=20 > pretty long). In the detailed scenario you describe, the=20 > distinction between 'proactive' and 'reactive' maintenance is=20 > whether the guy wants the alarm raised to him immediately and=20 > he will deal with it ahead of any trouble ticket raised by a=20 > customer or whether the guy only wants to know the alarm=20 > status in front of him at the time the customer raises the=20 > trouble ticket. In both cases the 'suppressed' alarm is still=20 > needed in the higher level management system. >=20 > Exact procedures for fault locations will vary, I'm sure, as=20 > do the systems available to help. Importantly, there will=20 > inevitably be a variety of residual faults which occur which=20 > do also sit neatly into prior assumptions of what can go=20 > wrong. So fault localisation *must* include procedures to=20 > deal with things which do not say 'I am broken, fix me'. What=20 > is damaging to the fault localisation process is if there is=20 > false information around. >=20 > Andy > =20 >=20 > Andy Reid > Chief Network Services Strategist > BT Innovate > =20 >=20 > Office: +44 (0)1277 322038 > Mobile: +44 (0)7917 025451 > Fax : +44 (0)1277 324015 > Email: andy.bd.reid@bt.com >=20 > =20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ=20 > Registered in England no. 1800000 This electronic message=20 > contains information from British Telecommunications plc=20 > which may be privileged or confidential. > The information is intended to be for the use of the=20 > individual(s) or entity named above. If you are not the=20 > intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information is=20 > prohibited. If you have received this electronic message in=20 > error, please notify us by telephone or email (to the numbers=20 > or address above) immediately. > Activity and use of the British Telecommunications plc email=20 > system is monitored to secure its effective operation and for=20 > other lawful business purposes. Communications using this=20 > system will also be monitored and may be recorded to secure=20 > effective operation and for other lawful business purposes. >=20 > =20 >=20 > > -----Original Message----- > > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > > Sent: 29 April 2009 08:18 > > To: Reid,ABD,Andy,CXM R; IBryskin@advaoptical.com > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Andy, > >=20 > > You speak about "local" and "remote" alarms. I had to read=20 > the rest of >=20 > > the sentence three times before I understood that you meant=20 > "primary"=20 > > and "secondary/consequential" alarms. > > A primary alarm is an alarm that reports a fault cause that needs=20 > > fixing, whereas a secondary/consequential alarm is a report from a=20 > > client that it's connection is interrupted due to a server fault. > > Do I understand your use of "local" and "remote" correct? > >=20 > > I agree with you that the main task of fault management is=20 > to know if=20 > > there is a fault that they can repair, what the fault is, where the=20 > > location of this fault is and then who to send to repair the fault. > >=20 > > I agree with you that service management needs to know about the=20 > > status of the service when the customer calls. I do not=20 > agree with you >=20 > > that in general "these guys wants to know that the service=20 > is 'down'=20 > > **before** the customer is on the phone!". > >=20 > > I have very explicit information of a few operators that a large=20 > > number of service contracts will not be as you describe.=20 > Values given=20 > > to me are 90% of service contracts (representing 70% of service > > connections) are without pro-active monitoring. In those=20 > contracts the >=20 > > repair time starts after the report of the customer and=20 > verification=20 > > by the operator. What is important in those cases is that=20 > the service=20 > > manager can simply retrieve status information when the=20 > customer is on >=20 > > the phone. > >=20 > > The other 10% of service contracts (representing 30% of service > > connections) are with pro-active monitoring. In those contracts the=20 > > repair time starts after the defect is detected. I assume=20 > that "these=20 > > guys wants to know that the service is 'down' **before**=20 > the customer=20 > > is on the phone!" > > is applicable for a subset of those service connections.=20 > For the other >=20 > > subset I have understood that it is sufficient when the=20 > > status/performance information of the service connection can be=20 > > retrieved instantaneously when the customer is on the=20 > phone. Is this=20 > > also the case in BT? > >=20 > > Besides the service connections, we have tunnel/path connections,=20 > > section connections and physical media connections. Those=20 > connections=20 > > have no direct "service" > > associated with it; i.e. those connections are part of the=20 > network's=20 > > infrastructure. There is as such no "service manager" interested in=20 > > the status of those infrastructure connections. The only people=20 > > interested in alarms from those infrastructure connections are the=20 > > fault management people. > > Do I understand this correct? > >=20 > > > The service maintenance guys *have* got an alarm - the=20 > customer has=20 > > > not got their service! They also notice that it is not > > fixing itself.=20 > > > So they investigate, ie start localising. > >=20 > > I do not understand why a service maintenance guy will have=20 > to do the=20 > > fault localization... I have always been told that fault=20 > management is >=20 > > responsible for locating a fault. If the fault is an open matrix=20 > > connection (which either interrupts a tunnel/path connection or a=20 > > service/channel connection), then the fault management people=20 > > responsible for the layer network will be triggered by the=20 > loss of CC=20 > > alarm and start the localization procedure. > >=20 > > When a network deploys AIS, it is possible to trigger this=20 > open matrix >=20 > > fault localization procedure without any complex network=20 > correlation=20 > > procedure. > > Seems to be advantages... > >=20 > > Regards, > > Maarten > >=20 > > -----Original Message----- > > From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] > > Sent: woensdag 29 april 2009 0:26 > > To: maarten.vissers@huawei.com; IBryskin@advaoptical.com > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > Maarten, Igor, > >=20 > > Before dealing with the specific scenarios, let me go through again=20 > > what I said in an earlier posting about the way alarm 'suppression' > > actually works. > >=20 > > There are two sides to maintenance - the faulty kit guys who fix=20 > > faulty cards, mend cable breaks, etc, etc, and end service guys who=20 > > deal with customer service. 'Suppressed' > > alarms are only suppressed to the faulty kit guys who fix=20 > cards, etc.=20 > > The distinction between 'local' and 'remote' > > alarms is very important to ensure that these faulty kit guys are=20 > > directed to the place where the actual fault lies and not to places=20 > > affected by, but remote from the actual fault. > >=20 > > However, these 'suppressed' alarms are still forwarded to=20 > the service=20 > > maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they=20 > > want to know whether the end service is 'up' or 'down'=20 > irrespective of >=20 > > the cause and irrespective of the presence of AIS. AIS most=20 > > emphatically does not suppress this alarm! These guys wants to know=20 > > that the service is 'down' > > before the customer is on the phone! > >=20 > > So to go to Maarten's first example, the faulty kit guys are not=20 > > getting any alarms telling them to fix broken kit - which=20 > is correct. > >=20 > > The service maintenance guys *have* got an alarm - the customer has=20 > > not got their service! They also notice that it is not=20 > fixing itself. > > So they investigate, ie start localising. In practice, the=20 > first thing >=20 > > they will do (and most management systems will do it=20 > automatically by=20 > > some form of correlation engine) is check for any=20 > corresponding faulty >=20 > > kit alarms. In this case, they will find no faulty kit alarms and=20 > > suspect a misconfiguration, localise it, and fix it. > >=20 > > To go to Maarten's second example, the faulty kit guys are=20 > getting an=20 > > alarm telling them to fix the link between A and B. > >=20 > > The service maintenance guys have also got an alarm - again the=20 > > customer has not got their service. They also notice that it is not=20 > > fixing itself. So they investigate, ie start localising. Again, the=20 > > first thing they will do (and most management systems will do it=20 > > automatically by some form of correlation engine) is check for any=20 > > corresponding faulty kit alarms. In this case, they will find the=20 > > corresponding faulty kit alarm and can check of the repair plan and=20 > > status should the customer call and ask. > >=20 > > As these particular scenarios illustrate, the right alarms=20 > have been=20 > > directed to the right maintenance guys. The service guys=20 > deal with the >=20 > > service configurations, the faulty kit guys deal with faulty kit. > >=20 > > Occasionally, there will be faulty kit which is not=20 > reporting itself=20 > > despite the best design efforts in the equipment. In this case, the=20 > > service maintenance guys are likely to have a series of=20 > alarms which=20 > > can be correlated to help localise the fault and the=20 > diagnosed fault=20 > > can then be passed to the faulty kit guys for fixing. > >=20 > > Another important point. There is little room here for > > *false* information coming to either set of maintenance guys.=20 > > When trying to localise a fault, no additional information=20 > is better=20 > > than wrong additional information. > >=20 > > That is my concern with the trying to inject packet based=20 > AIS. There=20 > > is significant room for creating false information. As I've already=20 > > indicted there is AIS specific configuration to do which=20 > will be prone >=20 > > to misconfiguration. > > We should then note that the thing that the AIS is supposed to be=20 > > identifying is the present of misconfiguration - but achieving this=20 > > requires configuration. So why should one configuration be more=20 > > reliable than the other? > >=20 > > But there are other scenarios. For example, consider port=20 > mapping (or=20 > > in ITU-T speak, a degenerate subnetwork) where we terminate the=20 > > section layer on one interface and blindly ship all the=20 > packets out on >=20 > > an other interface in a new section. > > If we assume AIS is being used, a fault in the incoming=20 > section should >=20 > > result in the injection of AIS. But how does it know what=20 > label values >=20 > > to use? Or does it not inject AIS? > > In which case we have the poor service maintenance guys actively=20 > > looking for a configuration error which does not exist. A similar=20 > > scenario would exist if we choose to use a sort of ADM where the=20 > > forwarding table was made up of exception (add/drop) label=20 > values and=20 > > a default outgoing port. Again, the same dilemma exists. > >=20 > > Andy > >=20 > >=20 > >=20 > >=20 > > Andy Reid > > Chief Network Services Strategist > > BT Innovate > > =20 > >=20 > > Office: +44 (0)1277 322038 > > Mobile: +44 (0)7917 025451 > > Fax : +44 (0)1277 324015 > > Email: andy.bd.reid@bt.com > >=20 > > =20 > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ Registered in=20 > > England no. 1800000 This electronic message contains=20 > information from=20 > > British Telecommunications plc which may be privileged or=20 > > confidential. The information is intended to be for the use of the > > individual(s) or entity named above. If you are not the intended=20 > > recipient be aware that any disclosure, copying,=20 > distribution or use=20 > > of the contents of this information is prohibited. If you have=20 > > received this electronic message in error, please notify us by=20 > > telephone or email (to the numbers or address above) immediately. > > Activity and use of the British Telecommunications plc=20 > email system is >=20 > > monitored to secure its effective operation and for other lawful=20 > > business purposes. Communications using this system will also be=20 > > monitored and may be recorded to secure effective operation and for=20 > > other lawful business purposes. > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > > Sent: 28 April 2009 20:25 > > > To: 'Igor Bryskin' > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Igor, > > >=20 > > > > b) Is it beneficial if a server trail notifies its clients about > > > a detected problem to suppress the OAM traffic > > >=20 > > > The suppression we have been talking about is alarm > > suppression, not > > > OAM traffic suppression. > > >=20 > > > Loss of CC is intended to detect an open connection fault > > in a matrix. > > > E.g. assume a connection that starts in node A, passes > > through nodes B > > > and C and ends in node D. > > > Nodes A, B, C and D have a connection function in which a matrix=20 > > > connection is to be set up to support this connection from A to D. > > >=20 > > > What is now possible is that the matrix connection in node B is=20 > > > unintentionally removed (i.e. a continuity fault). > > > Node D will now detect a loss of CC. Node D does not detect > > any other > > > faults. > > > Node C will not detect any fault. > > > Node B will not detect any fault. > > > Node A will not detect any fault if the matrix connection in B is=20 > > > removed in one direction only. > > >=20 > > > In order to detect this open matrix connection fault it is > > required to > > > report the loss of CC to the management system and to=20 > start a fault=20 > > > localization procedure to locate the faulty matrix (i.e.=20 > in node B). > > > If such reporting is not done, then there is a hidden=20 > fault, which=20 > > > keeps the connection interrupted much longer; i.e. until > > one or more > > > customers start to complain that their connections are lost. > > > Then you hae to find in a big network without any fault > > report which > > > node has the fault. > > >=20 > > > What happens now if the fault is not an open matrix > > connection but a > > > server layer fault (e.g. a link fault between nodes A and B). > > > Node D will now detect a loss of CC. Node D does not detect > > any other > > > faults. > > > Node C will not detect any fault. > > > Node B will detect a loss of signal fault. > > > Node A will not detect any fault if the link from A to B is > > broken in > > > one direction only. > > >=20 > > > If loss of CC is unconditionally reported, then node D=20 > will report=20 > > > loss of CC. Node B will report loss of signal. > > > - If node B and node D are managed by the same management > > system it is > > > possible to perform a fault correlation in this management > > system to > > > filter out the loss of CC from node D. > > > What is necessary is to know that connection A-D is > > supported by the > > > link A to B. In larger multi-layer networks such > > correlations become > > > complex. If such correlations are not performed, then the > > loss of CC > > > will trigger a fault localisation action, which of course=20 > will not=20 > > > find a matrix fault (i.e. waste of time). > > > - If node B is managed by another management system then > > node D, there > > > is no correlation possible. Node D's management system will > > see only > > > the loss of CC and will start fault localization, and=20 > will not find=20 > > > any fault in its part of the network. > > >=20 > > > Use of AIS will help in distinguishing between connection > > interruption > > > due to an open matrix connection fault and due to server=20 > fault. AIS=20 > > > provides the necessary filter for loss of CC. > > >=20 > > > What happens for the case a port detects a signal fail=20 > condition is=20 > > > the following; assume a 10G port that detects a signal fail > > condition. > > > This implies that all traffic is lost. > > > Assume that there are 1000 client connections active (e.g.=20 > > > with an average bandwidth of 5 Mbit/s). When AIS is to be=20 > generated=20 > > > for those 1000 client conenctions the port has to=20 > generate 1000 AIS=20 > > > frames/packets per second. Each AIS frame/packet is 64 > > bytes/512 bits. > > > Those 1000 AIS frames/packets thus generate 512 kbit/s=20 > (i.e. 0.0005 > > > Gbit/s) of traffic in a further empty 10G port. This=20 > isn't any real=20 > > > complexity. > > >=20 > > > --------- > > >=20 > > > The alternative is to declare that open matrix connections > > are never a > > > fault condition (i.e. are always intentional and thus known > > by network > > > management). Under such starting point it is not necessary > > to detect > > > an open matrix connection as a fault condition. Now it is > > not longer > > > necessary to distinguish between connection interruption > > due to open > > > matrix and server layer fault as the first condition=20 > isn't a fault=20 > > > anylonger. Under this condition it is not useful that a > > server trail > > > informs its clients about a detected server trail problem that=20 > > > interrupts the client connections. > > >=20 > > > If we go for this latter approach and if in future an open matrix=20 > > > connection would be a fault condition, then this is a > > hidden fault and > > > you need a lot more work to locate the fault (there are no > > alarms that > > > help you). > > >=20 > > > Regards, > > > Maarten > > >=20 > > >=20 > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: dinsdag 28 april 2009 18:20 > > > To: davarish@yahoo.com; 'Maarten Vissers';=20 > neil.2.harrison@bt.com;=20 > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Shahram, > > >=20 > > > I was addressing Neil's comments about the dynamic > > re-routing, which > > > is different from protection switchover onto pre-provisioned=20 > > > protection connection. True, in the latter case the server layer=20 > > > wouldn't notice that and will keep notifying the client > > that the trail > > > is broken. But this does not change anything. The big 2 > > questions in > > > my mind are: > > >=20 > > > a) Is the OAM of a given layer is (i) self-sufficient and > > > (ii) scalable enough, so that operator can rely on it > > completely and > > > independently from what is happening in the lower layers? > > >=20 > > > b) Is it beneficial if a server trail notifies its=20 > clients about a=20 > > > detected problem to suppress the OAM traffic and possibly > > unnecessary > > > switchovers until the server trail corrects itself? > > >=20 > > > Cheers, > > > Igor > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: Shahram Davari [mailto:davarish@yahoo.com] > > > Sent: Tuesday, April 28, 2009 11:57 AM > > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Igor, > > >=20 > > > Your assumption is that there is a control plane that sets up the=20 > > > binding between client and server layer and that such > > binding will be > > > removed via the control plane when a reroute happens. I=20 > think this=20 > > > assumption is not always true. For example in a linear 1:1 or 1+1=20 > > > protection, there is no signalling to withdraw the binding at=20 > > > intermediate nodes. In > > > 1:1 there is APS, but that is end-to-end and is sent on=20 > the backup=20 > > > path not working path. > > >=20 > > > -Shahram > > >=20 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > Sent: April-28-09 11:27 AM > > > To: davarish@yahoo.com; 'Maarten Vissers';=20 > neil.2.harrison@bt.com;=20 > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Shahram, > > >=20 > > > Let's assume that connection A-B-C-D-E is dynamically > > provisioned by a > > > control plane. As part of such provisioning a binding is created=20 > > > between this connection and network C at the two adaptation > > points on > > > either side of the link provided by network C. When the > > connection is > > > torn down, this binding is removed as a part of the=20 > cleanup process. > > > The re-routing of the connection onto A-F-G-E is=20 > indistinguishable=20 > > > from the connection tear down as far as link C is concerned. > > >=20 > > > Igor > > >=20 > > > -----Original Message----- > > > From: Shahram Davari [mailto:davarish@yahoo.com] > > > Sent: Tuesday, April 28, 2009 11:15 AM > > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Hi Igor, > > >=20 > > > How does the server know the client is rerouted? Assume the > > following > > > networks: A-B-C-D-E (working) and A-F-G-E (protection).=20 > > > Assume each has its own server layer such as MPLS, MPLS-TP, ATM,=20 > > > SONET, etc. Assume that network C uses MPLS-TP as server layer. > > > Network C will never know there was a protection=20 > switching done for=20 > > > the client layer. > > >=20 > > > -Shahram > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin > > > Sent: April-28-09 11:05 AM > > > To: Maarten Vissers; neil.2.harrison@bt.com; > > nurit.sprecher@nsn.com; > > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > > adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Neil. > > >=20 > > > I actually agree with Maarten on this. I don't quite > > understand why do > > > you keep talking about fixed client-server relationship. It > > is fixed > > > as long as the client layer connection configured this way > > (statically > > > or dynamically). > > > As soon as the connection is re-routed, this relationship=20 > is broken=20 > > > (because this is a part of the re-routing process) and hence the=20 > > > server trail termination points will know that the server=20 > trail now=20 > > > serves one connection less, whereas some other server=20 > trail(s) will=20 > > > learn that they serve from now on one connection more. These new=20 > > > client-server relationships are fixed until the next re-routing. > > >=20 > > > Cheers, > > > Igor > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > > Sent: Tuesday, April 28, 2009 8:48 AM > > > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com;=20 > > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > > adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Neil, > > >=20 > > > > However, if the client can dynamically change its routing > > > in response > > > > to link failures in its topology (because some server > > layer network > > > > has failed....which may or may not belong to the same > > > operating party > > > > as the > > > > client) then there is no fixed client/server relationship.=20 > > >=20 > > > I believe there is a fixed client/server relationship=20 > also in this=20 > > > case in the network. This relationship is broken when the > > connection > > > is rerouted. > > > Such reroute will remove the CP/FP and as such will stop the AIS=20 > > > generation. > > >=20 > > > There is no difference with what we do today in SDH and OTN.=20 > > > A client/server relationship is fixed until the point in > > time that the > > > connection is either teardown or rerouted. When either of the two=20 > > > cases occur, the AIS generation is stopped. > > > Until such action is performed, AIS is generated during=20 > signal fail=20 > > > condition period and inserted into the connection. > > >=20 > > > In MPLS-TP we have the requirement that MPLS-TP must be able to=20 > > > operate without control plane. This implies that it will operate=20 > > > without restoration, and that there will not be frequent=20 > rerouteing=20 > > > ongoing. Result is that client/server relationships will=20 > last until=20 > > > the connection is teardown. > > >=20 > > > Regards, > > > Maarten > > >=20 > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > neil.2.harrison@bt.com > > > Sent: dinsdag 28 april 2009 10:07 > > > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Nurit, > > >=20 > > > I believe the reason we need this discussion is that there is an=20 > > > unstated assumption here that the client/server > > relationship is fixed. > > > However, if the client can dynamically change its routing > > in response > > > to link failures in its topology (because some server=20 > layer network=20 > > > has failed....which may or may not belong to the same > > operating party > > > as the > > > client) then there is no fixed client/server relationship. > > >=20 > > > Refer to my post earlier today and consider what this=20 > means in the=20 > > > case of a cl-ps IP client layer network or a some SVC-based=20 > > > co-ps/co-cs mode client layer network. The key point here is the=20 > > > *routing process* in the client is independent of the=20 > server layer=20 > > > network....so there is not a fixed client/server relationship. > > > Further, there is also no requirement for the server to > > keep track of > > > where its client traffic routings are at any epoch.....indeed why=20 > > > should it in the general case where these are independent layer=20 > > > networks? > > >=20 > > > So the only OAM requirement that is critical is that the=20 > OAM of the=20 > > > client and server layer networks are independent. It is thus not=20 > > > sensible to make client layer alarm supression a 'requirement' > > > here...in fact if this is in the OAM requirements then it is=20 > > > technically wrong and should be removed IMO. > > >=20 > > > regards, Neil > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > > Nurit (NSN - > > > > IL/Hod HaSharon) > > > > Sent: 28 April 2009 08:46 > > > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > > > transportpathrequirements) > > > >=20 > > > > If we agree that the requirement is included, so why do we > > > keep with > > > > the endless discussions on this requirement? > > > >=20 > > > > -----Original Message----- > > > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > > > Sent: Tuesday, April 28, 2009 10:44 AM > > > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > hhelvoort@chello.nl;=20 > > > > Adrian Farrel > > > > Cc: mpls-tp@ietf.org > > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > bidirectional transport > > > > pathrequirements) > > > >=20 > > > > I think that the requirements are defined in section 2.2.8 of > > > > draft-ietf-mpls-tp-oam-requirements-01 > > > >=20 > > > > Italo > > > >=20 > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > > Nurit (NSN > > > > > - IL/Hod HaSharon) > > > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > > > To: hhelvoort@chello.nl; Adrian Farrel > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > > > > transport pathrequirements) > > > > >=20 > > > > > Huub, > > > > > I think that the requirement is to provide a mechanism to > > > suppress > > > > > alarms in the networks, to ensure that alarms that may be > > > > generated by > > > > > client layers as a result of a failure condition in the > > > server layer > > > > > may be suppressed. > > > > > Every thing else is a solution, etc.=20 > > > > > I propose to phrase the requirement appropriately and > > > conclude the > > > > > discussion on this in the context of the requirements > > > (until we are > > > > > getting to the solution phase). > > > > > This requirement is included in the OAM requirement draft.=20 > > > > > Best regards, > > > > > NUrit > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On > > > > > Behalf Of ext Huub van Helvoort > > > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > > > To: Adrian Farrel > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > > bidirectional transport > > > > > path requirements) > > > > >=20 > > > > > Hi Adrian, > > > > >=20 > > > > > You wrote: > > > > >=20 > > > > > > Isn't the solution here the same as the one I proposed > > > for "TCM"? > > > > >=20 > > > > > Indeed, and that we do not have to around in circles=20 > about TCM. > > > > >=20 > > > > > How about: > > > > > the requirement is that a server layer shall inform its > > > clients that > > > > > it has detected a service interuption, this to ensure=20 > that the=20 > > > > > clients can inhibit (unnecessary) alarms. > > > > >=20 > > > > > Cheers, Huub. > > > > >=20 > > > > > -- > > > > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > http://www.van-helvoort.eu/=20 > > > > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > Always remember that you are unique...just like=20 > everyone else... > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > >=20 > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From neil.2.harrison@bt.com Wed Apr 29 09:14:57 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DA63A6F11 for ; Wed, 29 Apr 2009 09:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voRMmGLrbCu7 for ; Wed, 29 Apr 2009 09:14:55 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 5E3B63A69BD for ; Wed, 29 Apr 2009 09:14:54 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 17:16:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 17:16:10 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E264C@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) Thread-Index: AcnHfummXONhxnFGTPmWS2jqvKiAqwAPibFwAAXilNAAACjkQAAAOQGQAAoNMNAABLruQAAAhN2AAABVyUAAAPWLIAAAhWrwAAYbeoAABMnv0AATTltgAA8a1TAAAuYvEAACQFFAAABQLHA= From: To: , , , X-OriginalArrivalTime: 29 Apr 2009 16:16:15.0327 (UTC) FILETIME=[D20356F0:01C9C8E5] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 16:14:58 -0000 It also works for me Malcolm. regards, Neil =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of andy.bd.reid@bt.com > Sent: 29 April 2009 17:07 > To: betts01@nortel.com; maarten.vissers@huawei.com;=20 > IBryskin@advaoptical.com > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI=20 > (wasAssociatedbidirectionaltransportpathrequirements) >=20 > Malcolm, >=20 > I think this could be suitable way forward. >=20 > Andy >=20 > Andy Reid > Chief Network Services Strategist > BT Innovate > =20 >=20 > Office: +44 (0)1277 322038 > Mobile: +44 (0)7917 025451 > Fax : +44 (0)1277 324015 > Email: andy.bd.reid@bt.com >=20 > =20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000=20 > This electronic message contains information from British > Telecommunications plc which may be privileged or confidential. The > information is intended to be for the use of the=20 > individual(s) or entity > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this=20 > electronic message > in error, please notify us by telephone or email (to the numbers or > address above) immediately. > Activity and use of the British Telecommunications plc email system is > monitored to secure its effective operation and for other lawful > business purposes. Communications using this system will also be > monitored and may be recorded to secure effective operation and for > other lawful business purposes. >=20 > =20 >=20 > > -----Original Message----- > > From: Malcolm Betts [mailto:betts01@nortel.com]=20 > > Sent: 29 April 2009 16:11 > > To: Reid,ABD,Andy,CXM R; maarten.vissers@huawei.com;=20 > > IBryskin@advaoptical.com > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was=20 > > Associatedbidirectionaltransportpathrequirements) > >=20 > > Andy, Maarten, > >=20 > > Without going into all of the details, I think that you are=20 > > describing a function that should be performed by the element=20 > > management alarm reporting and control function.=20 > >=20 > > i.e. does a certain condition, or combination of conditions,=20 > > result in an autonomous notification to a management system,=20 > > or is it simply a condition that is reported "on demand". > >=20 > > From the perspective of this discussion we should focus on=20 > > the primitives that are delivered to the alarm reporting and=20 > > control function. > >=20 > > The key "information elements" that must be provided are: > > 1) Has the trail failed > > 2) Has the failure been caused by i) a "local" fault i.e. in=20 > > the equipment or on an incoming link: or ii) by a "remote"=20 > > fault i.e. in another node or on an incoming link that=20 > > terminates on a remote node. > >=20 > > Malcolm Betts > > Nortel Networks > > Phone: +1 613 763 7860 (ESN 393) > > email: betts01@nortel.com > >=20 > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of andy.bd.reid@bt.com > > Sent: Wednesday, April 29, 2009 10:46 AM > > To: maarten.vissers@huawei.com; IBryskin@advaoptical.com > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was > > Associatedbidirectionaltransportpathrequirements) > >=20 > > Maarten, > >=20 > > From this, you are agreeing the basic operational model. I=20 > > was trying to be both concise and reasonably general to=20 > > different maintenance scenarios (and the posting was still=20 > > pretty long). In the detailed scenario you describe, the=20 > > distinction between 'proactive' and 'reactive' maintenance is=20 > > whether the guy wants the alarm raised to him immediately and=20 > > he will deal with it ahead of any trouble ticket raised by a=20 > > customer or whether the guy only wants to know the alarm=20 > > status in front of him at the time the customer raises the=20 > > trouble ticket. In both cases the 'suppressed' alarm is still=20 > > needed in the higher level management system. > >=20 > > Exact procedures for fault locations will vary, I'm sure, as=20 > > do the systems available to help. Importantly, there will=20 > > inevitably be a variety of residual faults which occur which=20 > > do also sit neatly into prior assumptions of what can go=20 > > wrong. So fault localisation *must* include procedures to=20 > > deal with things which do not say 'I am broken, fix me'. What=20 > > is damaging to the fault localisation process is if there is=20 > > false information around. > >=20 > > Andy > > =20 > >=20 > > Andy Reid > > Chief Network Services Strategist > > BT Innovate > > =20 > >=20 > > Office: +44 (0)1277 322038 > > Mobile: +44 (0)7917 025451 > > Fax : +44 (0)1277 324015 > > Email: andy.bd.reid@bt.com > >=20 > > =20 > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ=20 > > Registered in England no. 1800000 This electronic message=20 > > contains information from British Telecommunications plc=20 > > which may be privileged or confidential. > > The information is intended to be for the use of the=20 > > individual(s) or entity named above. If you are not the=20 > > intended recipient be aware that any disclosure, copying,=20 > > distribution or use of the contents of this information is=20 > > prohibited. If you have received this electronic message in=20 > > error, please notify us by telephone or email (to the numbers=20 > > or address above) immediately. > > Activity and use of the British Telecommunications plc email=20 > > system is monitored to secure its effective operation and for=20 > > other lawful business purposes. Communications using this=20 > > system will also be monitored and may be recorded to secure=20 > > effective operation and for other lawful business purposes. > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > > > Sent: 29 April 2009 08:18 > > > To: Reid,ABD,Andy,CXM R; IBryskin@advaoptical.com > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Andy, > > >=20 > > > You speak about "local" and "remote" alarms. I had to read=20 > > the rest of > >=20 > > > the sentence three times before I understood that you meant=20 > > "primary"=20 > > > and "secondary/consequential" alarms. > > > A primary alarm is an alarm that reports a fault cause that needs=20 > > > fixing, whereas a secondary/consequential alarm is a=20 > report from a=20 > > > client that it's connection is interrupted due to a server fault. > > > Do I understand your use of "local" and "remote" correct? > > >=20 > > > I agree with you that the main task of fault management is=20 > > to know if=20 > > > there is a fault that they can repair, what the fault is,=20 > where the=20 > > > location of this fault is and then who to send to repair=20 > the fault. > > >=20 > > > I agree with you that service management needs to know about the=20 > > > status of the service when the customer calls. I do not=20 > > agree with you > >=20 > > > that in general "these guys wants to know that the service=20 > > is 'down'=20 > > > **before** the customer is on the phone!". > > >=20 > > > I have very explicit information of a few operators that a large=20 > > > number of service contracts will not be as you describe.=20 > > Values given=20 > > > to me are 90% of service contracts (representing 70% of service > > > connections) are without pro-active monitoring. In those=20 > > contracts the > >=20 > > > repair time starts after the report of the customer and=20 > > verification=20 > > > by the operator. What is important in those cases is that=20 > > the service=20 > > > manager can simply retrieve status information when the=20 > > customer is on > >=20 > > > the phone. > > >=20 > > > The other 10% of service contracts (representing 30% of service > > > connections) are with pro-active monitoring. In those=20 > contracts the=20 > > > repair time starts after the defect is detected. I assume=20 > > that "these=20 > > > guys wants to know that the service is 'down' **before**=20 > > the customer=20 > > > is on the phone!" > > > is applicable for a subset of those service connections.=20 > > For the other > >=20 > > > subset I have understood that it is sufficient when the=20 > > > status/performance information of the service connection can be=20 > > > retrieved instantaneously when the customer is on the=20 > > phone. Is this=20 > > > also the case in BT? > > >=20 > > > Besides the service connections, we have tunnel/path connections,=20 > > > section connections and physical media connections. Those=20 > > connections=20 > > > have no direct "service" > > > associated with it; i.e. those connections are part of the=20 > > network's=20 > > > infrastructure. There is as such no "service manager"=20 > interested in=20 > > > the status of those infrastructure connections. The only people=20 > > > interested in alarms from those infrastructure=20 > connections are the=20 > > > fault management people. > > > Do I understand this correct? > > >=20 > > > > The service maintenance guys *have* got an alarm - the=20 > > customer has=20 > > > > not got their service! They also notice that it is not > > > fixing itself.=20 > > > > So they investigate, ie start localising. > > >=20 > > > I do not understand why a service maintenance guy will have=20 > > to do the=20 > > > fault localization... I have always been told that fault=20 > > management is > >=20 > > > responsible for locating a fault. If the fault is an open matrix=20 > > > connection (which either interrupts a tunnel/path connection or a=20 > > > service/channel connection), then the fault management people=20 > > > responsible for the layer network will be triggered by the=20 > > loss of CC=20 > > > alarm and start the localization procedure. > > >=20 > > > When a network deploys AIS, it is possible to trigger this=20 > > open matrix > >=20 > > > fault localization procedure without any complex network=20 > > correlation=20 > > > procedure. > > > Seems to be advantages... > > >=20 > > > Regards, > > > Maarten > > >=20 > > > -----Original Message----- > > > From: andy.bd.reid@bt.com [mailto:andy.bd.reid@bt.com] > > > Sent: woensdag 29 april 2009 0:26 > > > To: maarten.vissers@huawei.com; IBryskin@advaoptical.com > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > bidirectionaltransportpathrequirements) > > >=20 > > > Maarten, Igor, > > >=20 > > > Before dealing with the specific scenarios, let me go=20 > through again=20 > > > what I said in an earlier posting about the way alarm=20 > 'suppression' > > > actually works. > > >=20 > > > There are two sides to maintenance - the faulty kit guys who fix=20 > > > faulty cards, mend cable breaks, etc, etc, and end=20 > service guys who=20 > > > deal with customer service. 'Suppressed' > > > alarms are only suppressed to the faulty kit guys who fix=20 > > cards, etc.=20 > > > The distinction between 'local' and 'remote' > > > alarms is very important to ensure that these faulty kit guys are=20 > > > directed to the place where the actual fault lies and not=20 > to places=20 > > > affected by, but remote from the actual fault. > > >=20 > > > However, these 'suppressed' alarms are still forwarded to=20 > > the service=20 > > > maintenance guys. So when SONET/SDH is carrying an E1 or=20 > a T3, they=20 > > > want to know whether the end service is 'up' or 'down'=20 > > irrespective of > >=20 > > > the cause and irrespective of the presence of AIS. AIS most=20 > > > emphatically does not suppress this alarm! These guys=20 > wants to know=20 > > > that the service is 'down' > > > before the customer is on the phone! > > >=20 > > > So to go to Maarten's first example, the faulty kit guys are not=20 > > > getting any alarms telling them to fix broken kit - which=20 > > is correct. > > >=20 > > > The service maintenance guys *have* got an alarm - the=20 > customer has=20 > > > not got their service! They also notice that it is not=20 > > fixing itself. > > > So they investigate, ie start localising. In practice, the=20 > > first thing > >=20 > > > they will do (and most management systems will do it=20 > > automatically by=20 > > > some form of correlation engine) is check for any=20 > > corresponding faulty > >=20 > > > kit alarms. In this case, they will find no faulty kit alarms and=20 > > > suspect a misconfiguration, localise it, and fix it. > > >=20 > > > To go to Maarten's second example, the faulty kit guys are=20 > > getting an=20 > > > alarm telling them to fix the link between A and B. > > >=20 > > > The service maintenance guys have also got an alarm - again the=20 > > > customer has not got their service. They also notice that=20 > it is not=20 > > > fixing itself. So they investigate, ie start localising.=20 > Again, the=20 > > > first thing they will do (and most management systems will do it=20 > > > automatically by some form of correlation engine) is=20 > check for any=20 > > > corresponding faulty kit alarms. In this case, they will find the=20 > > > corresponding faulty kit alarm and can check of the=20 > repair plan and=20 > > > status should the customer call and ask. > > >=20 > > > As these particular scenarios illustrate, the right alarms=20 > > have been=20 > > > directed to the right maintenance guys. The service guys=20 > > deal with the > >=20 > > > service configurations, the faulty kit guys deal with faulty kit. > > >=20 > > > Occasionally, there will be faulty kit which is not=20 > > reporting itself=20 > > > despite the best design efforts in the equipment. In this=20 > case, the=20 > > > service maintenance guys are likely to have a series of=20 > > alarms which=20 > > > can be correlated to help localise the fault and the=20 > > diagnosed fault=20 > > > can then be passed to the faulty kit guys for fixing. > > >=20 > > > Another important point. There is little room here for > > > *false* information coming to either set of maintenance guys.=20 > > > When trying to localise a fault, no additional information=20 > > is better=20 > > > than wrong additional information. > > >=20 > > > That is my concern with the trying to inject packet based=20 > > AIS. There=20 > > > is significant room for creating false information. As=20 > I've already=20 > > > indicted there is AIS specific configuration to do which=20 > > will be prone > >=20 > > > to misconfiguration. > > > We should then note that the thing that the AIS is supposed to be=20 > > > identifying is the present of misconfiguration - but=20 > achieving this=20 > > > requires configuration. So why should one configuration be more=20 > > > reliable than the other? > > >=20 > > > But there are other scenarios. For example, consider port=20 > > mapping (or=20 > > > in ITU-T speak, a degenerate subnetwork) where we terminate the=20 > > > section layer on one interface and blindly ship all the=20 > > packets out on > >=20 > > > an other interface in a new section. > > > If we assume AIS is being used, a fault in the incoming=20 > > section should > >=20 > > > result in the injection of AIS. But how does it know what=20 > > label values > >=20 > > > to use? Or does it not inject AIS? > > > In which case we have the poor service maintenance guys actively=20 > > > looking for a configuration error which does not exist. A similar=20 > > > scenario would exist if we choose to use a sort of ADM where the=20 > > > forwarding table was made up of exception (add/drop) label=20 > > values and=20 > > > a default outgoing port. Again, the same dilemma exists. > > >=20 > > > Andy > > >=20 > > >=20 > > >=20 > > >=20 > > > Andy Reid > > > Chief Network Services Strategist > > > BT Innovate > > > =20 > > >=20 > > > Office: +44 (0)1277 322038 > > > Mobile: +44 (0)7917 025451 > > > Fax : +44 (0)1277 324015 > > > Email: andy.bd.reid@bt.com > > >=20 > > > =20 > > > British Telecommunications plc > > > Registered office: 81 Newgate Street London EC1A 7AJ=20 > Registered in=20 > > > England no. 1800000 This electronic message contains=20 > > information from=20 > > > British Telecommunications plc which may be privileged or=20 > > > confidential. The information is intended to be for the use of the > > > individual(s) or entity named above. If you are not the intended=20 > > > recipient be aware that any disclosure, copying,=20 > > distribution or use=20 > > > of the contents of this information is prohibited. If you have=20 > > > received this electronic message in error, please notify us by=20 > > > telephone or email (to the numbers or address above) immediately. > > > Activity and use of the British Telecommunications plc=20 > > email system is > >=20 > > > monitored to secure its effective operation and for other lawful=20 > > > business purposes. Communications using this system will also be=20 > > > monitored and may be recorded to secure effective=20 > operation and for=20 > > > other lawful business purposes. > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > > > Sent: 28 April 2009 20:25 > > > > To: 'Igor Bryskin' > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Igor, > > > >=20 > > > > > b) Is it beneficial if a server trail notifies its=20 > clients about > > > > a detected problem to suppress the OAM traffic > > > >=20 > > > > The suppression we have been talking about is alarm > > > suppression, not > > > > OAM traffic suppression. > > > >=20 > > > > Loss of CC is intended to detect an open connection fault > > > in a matrix. > > > > E.g. assume a connection that starts in node A, passes > > > through nodes B > > > > and C and ends in node D. > > > > Nodes A, B, C and D have a connection function in which=20 > a matrix=20 > > > > connection is to be set up to support this connection=20 > from A to D. > > > >=20 > > > > What is now possible is that the matrix connection in node B is=20 > > > > unintentionally removed (i.e. a continuity fault). > > > > Node D will now detect a loss of CC. Node D does not detect > > > any other > > > > faults. > > > > Node C will not detect any fault. > > > > Node B will not detect any fault. > > > > Node A will not detect any fault if the matrix=20 > connection in B is=20 > > > > removed in one direction only. > > > >=20 > > > > In order to detect this open matrix connection fault it is > > > required to > > > > report the loss of CC to the management system and to=20 > > start a fault=20 > > > > localization procedure to locate the faulty matrix (i.e.=20 > > in node B). > > > > If such reporting is not done, then there is a hidden=20 > > fault, which=20 > > > > keeps the connection interrupted much longer; i.e. until > > > one or more > > > > customers start to complain that their connections are lost. > > > > Then you hae to find in a big network without any fault > > > report which > > > > node has the fault. > > > >=20 > > > > What happens now if the fault is not an open matrix > > > connection but a > > > > server layer fault (e.g. a link fault between nodes A and B). > > > > Node D will now detect a loss of CC. Node D does not detect > > > any other > > > > faults. > > > > Node C will not detect any fault. > > > > Node B will detect a loss of signal fault. > > > > Node A will not detect any fault if the link from A to B is > > > broken in > > > > one direction only. > > > >=20 > > > > If loss of CC is unconditionally reported, then node D=20 > > will report=20 > > > > loss of CC. Node B will report loss of signal. > > > > - If node B and node D are managed by the same management > > > system it is > > > > possible to perform a fault correlation in this management > > > system to > > > > filter out the loss of CC from node D. > > > > What is necessary is to know that connection A-D is > > > supported by the > > > > link A to B. In larger multi-layer networks such > > > correlations become > > > > complex. If such correlations are not performed, then the > > > loss of CC > > > > will trigger a fault localisation action, which of course=20 > > will not=20 > > > > find a matrix fault (i.e. waste of time). > > > > - If node B is managed by another management system then > > > node D, there > > > > is no correlation possible. Node D's management system will > > > see only > > > > the loss of CC and will start fault localization, and=20 > > will not find=20 > > > > any fault in its part of the network. > > > >=20 > > > > Use of AIS will help in distinguishing between connection > > > interruption > > > > due to an open matrix connection fault and due to server=20 > > fault. AIS=20 > > > > provides the necessary filter for loss of CC. > > > >=20 > > > > What happens for the case a port detects a signal fail=20 > > condition is=20 > > > > the following; assume a 10G port that detects a signal fail > > > condition. > > > > This implies that all traffic is lost. > > > > Assume that there are 1000 client connections active (e.g.=20 > > > > with an average bandwidth of 5 Mbit/s). When AIS is to be=20 > > generated=20 > > > > for those 1000 client conenctions the port has to=20 > > generate 1000 AIS=20 > > > > frames/packets per second. Each AIS frame/packet is 64 > > > bytes/512 bits. > > > > Those 1000 AIS frames/packets thus generate 512 kbit/s=20 > > (i.e. 0.0005 > > > > Gbit/s) of traffic in a further empty 10G port. This=20 > > isn't any real=20 > > > > complexity. > > > >=20 > > > > --------- > > > >=20 > > > > The alternative is to declare that open matrix connections > > > are never a > > > > fault condition (i.e. are always intentional and thus known > > > by network > > > > management). Under such starting point it is not necessary > > > to detect > > > > an open matrix connection as a fault condition. Now it is > > > not longer > > > > necessary to distinguish between connection interruption > > > due to open > > > > matrix and server layer fault as the first condition=20 > > isn't a fault=20 > > > > anylonger. Under this condition it is not useful that a > > > server trail > > > > informs its clients about a detected server trail problem that=20 > > > > interrupts the client connections. > > > >=20 > > > > If we go for this latter approach and if in future an=20 > open matrix=20 > > > > connection would be a fault condition, then this is a > > > hidden fault and > > > > you need a lot more work to locate the fault (there are no > > > alarms that > > > > help you). > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: dinsdag 28 april 2009 18:20 > > > > To: davarish@yahoo.com; 'Maarten Vissers';=20 > > neil.2.harrison@bt.com;=20 > > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > > Cc: mpls-tp@ietf.org > > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Shahram, > > > >=20 > > > > I was addressing Neil's comments about the dynamic > > > re-routing, which > > > > is different from protection switchover onto pre-provisioned=20 > > > > protection connection. True, in the latter case the=20 > server layer=20 > > > > wouldn't notice that and will keep notifying the client > > > that the trail > > > > is broken. But this does not change anything. The big 2 > > > questions in > > > > my mind are: > > > >=20 > > > > a) Is the OAM of a given layer is (i) self-sufficient and > > > > (ii) scalable enough, so that operator can rely on it > > > completely and > > > > independently from what is happening in the lower layers? > > > >=20 > > > > b) Is it beneficial if a server trail notifies its=20 > > clients about a=20 > > > > detected problem to suppress the OAM traffic and possibly > > > unnecessary > > > > switchovers until the server trail corrects itself? > > > >=20 > > > > Cheers, > > > > Igor > > > >=20 > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:davarish@yahoo.com] > > > > Sent: Tuesday, April 28, 2009 11:57 AM > > > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > > Cc: mpls-tp@ietf.org > > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Igor, > > > >=20 > > > > Your assumption is that there is a control plane that=20 > sets up the=20 > > > > binding between client and server layer and that such > > > binding will be > > > > removed via the control plane when a reroute happens. I=20 > > think this=20 > > > > assumption is not always true. For example in a linear=20 > 1:1 or 1+1=20 > > > > protection, there is no signalling to withdraw the binding at=20 > > > > intermediate nodes. In > > > > 1:1 there is APS, but that is end-to-end and is sent on=20 > > the backup=20 > > > > path not working path. > > > >=20 > > > > -Shahram > > > >=20 > > > > =20 > > > >=20 > > > > -----Original Message----- > > > > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > > > Sent: April-28-09 11:27 AM > > > > To: davarish@yahoo.com; 'Maarten Vissers';=20 > > neil.2.harrison@bt.com;=20 > > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > > Cc: mpls-tp@ietf.org > > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Shahram, > > > >=20 > > > > Let's assume that connection A-B-C-D-E is dynamically > > > provisioned by a > > > > control plane. As part of such provisioning a binding=20 > is created=20 > > > > between this connection and network C at the two adaptation > > > points on > > > > either side of the link provided by network C. When the > > > connection is > > > > torn down, this binding is removed as a part of the=20 > > cleanup process. > > > > The re-routing of the connection onto A-F-G-E is=20 > > indistinguishable=20 > > > > from the connection tear down as far as link C is concerned. > > > >=20 > > > > Igor > > > >=20 > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:davarish@yahoo.com] > > > > Sent: Tuesday, April 28, 2009 11:15 AM > > > > To: Igor Bryskin; 'Maarten Vissers'; neil.2.harrison@bt.com;=20 > > > > nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > > Cc: mpls-tp@ietf.org > > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Hi Igor, > > > >=20 > > > > How does the server know the client is rerouted? Assume the > > > following > > > > networks: A-B-C-D-E (working) and A-F-G-E (protection).=20 > > > > Assume each has its own server layer such as MPLS,=20 > MPLS-TP, ATM,=20 > > > > SONET, etc. Assume that network C uses MPLS-TP as server layer. > > > > Network C will never know there was a protection=20 > > switching done for=20 > > > > the client layer. > > > >=20 > > > > -Shahram > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin > > > > Sent: April-28-09 11:05 AM > > > > To: Maarten Vissers; neil.2.harrison@bt.com; > > > nurit.sprecher@nsn.com; > > > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > > > adrian@olddog.co.uk > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Neil. > > > >=20 > > > > I actually agree with Maarten on this. I don't quite > > > understand why do > > > > you keep talking about fixed client-server relationship. It > > > is fixed > > > > as long as the client layer connection configured this way > > > (statically > > > > or dynamically). > > > > As soon as the connection is re-routed, this relationship=20 > > is broken=20 > > > > (because this is a part of the re-routing process) and=20 > hence the=20 > > > > server trail termination points will know that the server=20 > > trail now=20 > > > > serves one connection less, whereas some other server=20 > > trail(s) will=20 > > > > learn that they serve from now on one connection more.=20 > These new=20 > > > > client-server relationships are fixed until the next re-routing. > > > >=20 > > > > Cheers, > > > > Igor > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > > > Sent: Tuesday, April 28, 2009 8:48 AM > > > > To: neil.2.harrison@bt.com; nurit.sprecher@nsn.com;=20 > > > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > > > adrian@olddog.co.uk > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Neil, > > > >=20 > > > > > However, if the client can dynamically change its routing > > > > in response > > > > > to link failures in its topology (because some server > > > layer network > > > > > has failed....which may or may not belong to the same > > > > operating party > > > > > as the > > > > > client) then there is no fixed client/server relationship.=20 > > > >=20 > > > > I believe there is a fixed client/server relationship=20 > > also in this=20 > > > > case in the network. This relationship is broken when the > > > connection > > > > is rerouted. > > > > Such reroute will remove the CP/FP and as such will=20 > stop the AIS=20 > > > > generation. > > > >=20 > > > > There is no difference with what we do today in SDH and OTN.=20 > > > > A client/server relationship is fixed until the point in > > > time that the > > > > connection is either teardown or rerouted. When either=20 > of the two=20 > > > > cases occur, the AIS generation is stopped. > > > > Until such action is performed, AIS is generated during=20 > > signal fail=20 > > > > condition period and inserted into the connection. > > > >=20 > > > > In MPLS-TP we have the requirement that MPLS-TP must be able to=20 > > > > operate without control plane. This implies that it=20 > will operate=20 > > > > without restoration, and that there will not be frequent=20 > > rerouteing=20 > > > > ongoing. Result is that client/server relationships will=20 > > last until=20 > > > > the connection is teardown. > > > >=20 > > > > Regards, > > > > Maarten > > > >=20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of > > > neil.2.harrison@bt.com > > > > Sent: dinsdag 28 april 2009 10:07 > > > > To: nurit.sprecher@nsn.com; Italo.Busi@alcatel-lucent.it;=20 > > > > hhelvoort@chello.nl; adrian@olddog.co.uk > > > > Cc: mpls-tp@ietf.org > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > > bidirectionaltransportpathrequirements) > > > >=20 > > > > Nurit, > > > >=20 > > > > I believe the reason we need this discussion is that=20 > there is an=20 > > > > unstated assumption here that the client/server > > > relationship is fixed. > > > > However, if the client can dynamically change its routing > > > in response > > > > to link failures in its topology (because some server=20 > > layer network=20 > > > > has failed....which may or may not belong to the same > > > operating party > > > > as the > > > > client) then there is no fixed client/server relationship. > > > >=20 > > > > Refer to my post earlier today and consider what this=20 > > means in the=20 > > > > case of a cl-ps IP client layer network or a some SVC-based=20 > > > > co-ps/co-cs mode client layer network. The key point=20 > here is the=20 > > > > *routing process* in the client is independent of the=20 > > server layer=20 > > > > network....so there is not a fixed client/server relationship. > > > > Further, there is also no requirement for the server to > > > keep track of > > > > where its client traffic routings are at any=20 > epoch.....indeed why=20 > > > > should it in the general case where these are independent layer=20 > > > > networks? > > > >=20 > > > > So the only OAM requirement that is critical is that the=20 > > OAM of the=20 > > > > client and server layer networks are independent. It=20 > is thus not=20 > > > > sensible to make client layer alarm supression a 'requirement' > > > > here...in fact if this is in the OAM requirements then it is=20 > > > > technically wrong and should be removed IMO. > > > >=20 > > > > regards, Neil > > > > > -----Original Message----- > > > > > From: mpls-tp-bounces@ietf.org > > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > > > Nurit (NSN - > > > > > IL/Hod HaSharon) > > > > > Sent: 28 April 2009 08:46 > > > > > To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > > > > transportpathrequirements) > > > > >=20 > > > > > If we agree that the requirement is included, so why do we > > > > keep with > > > > > the endless discussions on this requirement? > > > > >=20 > > > > > -----Original Message----- > > > > > From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > > > > Sent: Tuesday, April 28, 2009 10:44 AM > > > > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > > hhelvoort@chello.nl;=20 > > > > > Adrian Farrel > > > > > Cc: mpls-tp@ietf.org > > > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated > > > > bidirectional transport > > > > > pathrequirements) > > > > >=20 > > > > > I think that the requirements are defined in section 2.2.8 of > > > > > draft-ietf-mpls-tp-oam-requirements-01 > > > > >=20 > > > > > Italo > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: mpls-tp-bounces@ietf.org > > > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > > > > Nurit (NSN > > > > > > - IL/Hod HaSharon) > > > > > > Sent: Tuesday, April 28, 2009 6:56 AM > > > > > > To: hhelvoort@chello.nl; Adrian Farrel > > > > > > Cc: mpls-tp@ietf.org > > > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated=20 > bidirectional=20 > > > > > > transport pathrequirements) > > > > > >=20 > > > > > > Huub, > > > > > > I think that the requirement is to provide a mechanism to > > > > suppress > > > > > > alarms in the networks, to ensure that alarms that may be > > > > > generated by > > > > > > client layers as a result of a failure condition in the > > > > server layer > > > > > > may be suppressed. > > > > > > Every thing else is a solution, etc.=20 > > > > > > I propose to phrase the requirement appropriately and > > > > conclude the > > > > > > discussion on this in the context of the requirements > > > > (until we are > > > > > > getting to the solution phase). > > > > > > This requirement is included in the OAM requirement draft.=20 > > > > > > Best regards, > > > > > > NUrit > > > > > >=20 > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On > > > > > > Behalf Of ext Huub van Helvoort > > > > > > Sent: Tuesday, April 28, 2009 12:27 AM > > > > > > To: Adrian Farrel > > > > > > Cc: mpls-tp@ietf.org > > > > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > > > > bidirectional transport > > > > > > path requirements) > > > > > >=20 > > > > > > Hi Adrian, > > > > > >=20 > > > > > > You wrote: > > > > > >=20 > > > > > > > Isn't the solution here the same as the one I proposed > > > > for "TCM"? > > > > > >=20 > > > > > > Indeed, and that we do not have to around in circles=20 > > about TCM. > > > > > >=20 > > > > > > How about: > > > > > > the requirement is that a server layer shall inform its > > > > clients that > > > > > > it has detected a service interuption, this to ensure=20 > > that the=20 > > > > > > clients can inhibit (unnecessary) alarms. > > > > > >=20 > > > > > > Cheers, Huub. > > > > > >=20 > > > > > > -- > > > > > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > http://www.van-helvoort.eu/=20 > > > > > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Always remember that you are unique...just like=20 > > everyone else... > > > > > > _______________________________________________ > > > > > > mpls-tp mailing list > > > > > > mpls-tp@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > > > > > mpls-tp mailing list > > > > > > mpls-tp@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > >=20 > > > > > _______________________________________________ > > > > > mpls-tp mailing list > > > > > mpls-tp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > >=20 > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From nurit.sprecher@nsn.com Wed Apr 29 10:56:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2558F3A6B12 for ; Wed, 29 Apr 2009 10:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.407 X-Spam-Level: X-Spam-Status: No, score=-5.407 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLOnfVWuSxwl for ; Wed, 29 Apr 2009 10:56:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id D3E833A7195 for ; Wed, 29 Apr 2009 10:56:01 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3THvLso030139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 19:57:21 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3THvLKX030475; Wed, 29 Apr 2009 19:57:21 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 19:57:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 19:57:12 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net> In-Reply-To: <43390FDA-A83A-460A-9A88-F5FDBA3918D2@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) Thread-Index: AcnIsXcTm9FBL9rkQFC9YRk9CsewQgAQmpvQ References: <077E41CFFD002C4CAB7DFA4386A53264A415D6@DEMUEXC014.nsn-intra.net> <2ECAA42C79676B42AEBAC11229CA7D0C0479DC47@E03MVB2-UKBR.domain1.systemhost.net> <077E41CFFD002C4CAB7DFA4386A53264A41DC9@DEMUEXC014.nsn-intra.net> <43390FDA-A83A-460A-9A88-F5FDBA3918D2@lucidvision.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Thomas Nadeau" X-OriginalArrivalTime: 29 Apr 2009 17:57:21.0240 (UTC) FILETIME=[F1943580:01C9C8F3] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:56:20 -0000 I agree! -----Original Message----- From: ext Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Wednesday, April 29, 2009 1:01 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) It would be best is these "Tier-1 SPs" would comment directly on the =20 list or contribute to the requirements draft. --Tom On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) =20 wrote: > Neil, > Thanks for the very good explanation. It really helps me to understand > better the context of the long discussion. > Personally I got many feedbacks from Tier-1 SPs that they would like =20 > to > have the capability to suppress alarms in a packet transport > environment. Their requirement was that if a server layer (e.g. MPLS-=20 > TP > link) fails, there is a way to notify the client layer (e.g. LSPs) in > order to be able to suppress alarms at the client layer that may =20 > result > from the fault at the server layer (e.g. MPLS-TP link). > Isn't it a logical and reasonable requirement in a transport profile? > Also I saw general requirements for inter-layer fault correlation. So > can I understand from your mail that you are not happy from such a > requirement as well? > Best regards, > Nurit > > > > -----Original Message----- > From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, April 28, 2009 11:07 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > Nurit, > > I believe the reason we need this discussion is that there is an > unstated assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in =20 > response to > link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as =20 > the > client) then there is no fixed client/server relationship. > > Refer to my post earlier today and consider what this means in the =20 > case > of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs =20 > mode > client layer network. The key point here is the *routing process* in > the client is independent of the server layer network....so there is =20 > not > a fixed client/server relationship. Further, there is also no > requirement for the server to keep track of where its client traffic > routings are at any epoch.....indeed why should it in the general case > where these are independent layer networks? > > So the only OAM requirement that is critical is that the OAM of the > client and server layer networks are independent. It is thus not > sensible to make client layer alarm supression a 'requirement' =20 > here...in > fact if this is in the OAM requirements then it is technically wrong =20 > and > should be removed IMO. > > regards, Neil >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >> Nurit (NSN - IL/Hod HaSharon) >> Sent: 28 April 2009 08:46 >> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >> transportpathrequirements) >> >> If we agree that the requirement is included, so why do we >> keep with the >> endless discussions on this requirement? >> >> -----Original Message----- >> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >> Sent: Tuesday, April 28, 2009 10:44 AM >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); >> hhelvoort@chello.nl; Adrian >> Farrel >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional =20 >> transport >> pathrequirements) >> >> I think that the requirements are defined in section 2.2.8 of >> draft-ietf-mpls-tp-oam-requirements-01 >> >> Italo >> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >>> Nurit (NSN - IL/Hod HaSharon) >>> Sent: Tuesday, April 28, 2009 6:56 AM >>> To: hhelvoort@chello.nl; Adrian Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >>> transport pathrequirements) >>> >>> Huub, >>> I think that the requirement is to provide a mechanism to suppress >>> alarms in the networks, to ensure that alarms that may be >> generated by >>> client layers as a result of a failure condition in the >>> server layer may >>> be suppressed. >>> Every thing else is a solution, etc. >>> I propose to phrase the requirement appropriately and conclude the >>> discussion on this in the context of the requirements (until we are >>> getting to the solution phase). >>> This requirement is included in the OAM requirement draft. >>> Best regards, >>> NUrit >>> >>> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>> Behalf Of ext Huub van Helvoort >>> Sent: Tuesday, April 28, 2009 12:27 AM >>> To: Adrian Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated >> bidirectional transport >>> path requirements) >>> >>> Hi Adrian, >>> >>> You wrote: >>> >>>> Isn't the solution here the same as the one I proposed for "TCM"? >>> >>> Indeed, and that we do not have to around in circles about TCM. >>> >>> How about: >>> the requirement is that a server layer shall inform its clients >>> that it has detected a service interuption, this to ensure that >>> the clients can inhibit (unnecessary) alarms. >>> >>> Cheers, Huub. >>> >>> --=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> http://www.van-helvoort.eu/ >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Always remember that you are unique...just like everyone else... >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From gregimirsky@gmail.com Wed Apr 29 11:22:50 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7F83A6A4D for ; Wed, 29 Apr 2009 11:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=-1.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prR1Y1Xm-pf3 for ; Wed, 29 Apr 2009 11:22:28 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 41BC228B797 for ; Wed, 29 Apr 2009 11:22:27 -0700 (PDT) Received: by bwz7 with SMTP id 7so1344759bwz.37 for ; Wed, 29 Apr 2009 11:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DW1azG5GPE1aBYx66ZkqzOD3AA4qq5L7KyWHyQRueF4=; b=jUsjUe7hprbsqsqnpc24XfeZAVAQU4mXXG5hASBnYXRQEst4532pAFyTQ+jl4fh60t F95fisa8EE4w8G3nDgcFO+trKEaE2YEcyATAM5T6S930LA+4+oT9+dYxHWeR6vn8O6vd 6Ds5nP7sVZRpjZB9xoBp0nzMKPaeVx4uVa6O0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ApHQpu0fXRzYgE/amKpAYLyky08ViWQ6jsC5L7krfm2kV+YcA/D/sxg0ERQ65UfnhG wTVNE9YhBdEfCWLI27b2vJxgzv4yWSXBHIEM2v+qyL8vSOb9+zYSwKX1yjl0lKztkiNJ 9NbLCF4i1kteINh4Q3p9sv/JmP7uBXxRxqcPg= MIME-Version: 1.0 Received: by 10.103.213.10 with SMTP id p10mr420022muq.49.1241029427921; Wed, 29 Apr 2009 11:23:47 -0700 (PDT) In-Reply-To: <006201c9c8e4$7aa28620$6c02a8c0@china.huawei.com> References: <006201c9c8e4$7aa28620$6c02a8c0@china.huawei.com> Date: Wed, 29 Apr 2009 14:23:47 -0400 Message-ID: <787be2780904291123q1f36eb7dg6bc1aa0015e54229@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=001636c5b2443503ea0468b5aeaf Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:22:50 -0000 --001636c5b2443503ea0468b5aeaf Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, in my view the answer to your question depends upon answer to "What Tunnel = A and Tunnel B are?" Regards, Greg 2009/4/29 Maarten Vissers > Deborah, > > You are going far beyond my question. Let me try to clarify by using a > figure, In this figure there is an admin domain A and an admin domain B. > These two domains are interconnected via an 802.3 interface over which th= e > EVC layer is continued. My question is how we should refer to this interf= ace > between domains A and B? Is this interface referred to as ENNI? If it is = not > referred to as ENNI, what is then the name to use for this class of > interfaces? > > (A) (B) > ------------------------------------ > | EVC EVC | > ------------------------------------ > | Tunnel | |802.3| | Tunnel | > ------------ ------- ----------- > | T.Media | ^ | T.Media | > ------------ | ----------- > | > ENNI? > > Regards, > Maarten > > ------------------------------ > *From:* BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > *Sent:* woensdag 29 april 2009 17:06 > > *To:* Maarten Vissers > *Cc:* mpls-tp@ietf.org > *Subject:* RE: [mpls-tp] We appear to be going around in circles > (Re:Associated bidirectional transport path requirements) > > Maarten, > > > > I only have confirmed that what you have given as an example of an ENNI > below is G707 and G704. You missed the point. This is a typical ITU > interface standard. It can be used as an INNI, ENNI, or UNI. Since you ar= e > twisting words, I=A1=AFll try to be clearer. > > > > Yes, we need interface standards. If we have standards and have defined t= he > technology properly, we do not need your =A1=B0interworking ENNI=A1=B1. = You have > twisted the definition of a standard interface used between (hopefully) a= ll > equipment, within a domain and between domains, to rationalize your =A1= =B0ENNI=A1=B1. > Two operators (or Forum) agreeing on a physical encapsulation, J1, vlans,= or > label to be used may be described in the industry as interworking, but th= en > it can be said that every interface is interworking. The fiber connectors > are interworking. Instead of saying, I=A1=AFm connecting the fiber, we wi= ll say, > we are interworking the fiber. This is silly. Rather than use a much hype= d > non-specific term, here, in ITU and IETF, we should be specific. > > > > The ENNI/UNIs defined in MPLS Forum and MEF are a profile of existing > standards. They provide a consistent interpretation of an existing standa= rd > for the members of the Forum (i.e. improved readability for the members, = as > we all know, ITU Recommendations and IETF RFCs are often not standalone > documents or not easy reading for non-involved readers). It is questionab= le > for IETF or ITU to define an ENNI or UNI as it will be difficult for all = the > members to agree =A8C otherwise all the options should not be in the orig= inal > standard if they were not needed. > > > > Connecting two networks together using a standard physical layer is not > really an ENNI (as Neil has said over and over). If we start defining > UNI/ENNI/INNI for all the technologies in ITU and IETF, we will have an > operational nightmare. > > > > Deborah > > > > *From:* Maarten Vissers [mailto:maarten.vissers@huawei.com] > *Sent:* Wednesday, April 29, 2009 3:23 AM > *To:* BRUNGARD, DEBORAH A, ATTLABS > *Cc:* mpls-tp@ietf.org > *Subject:* RE: [mpls-tp] We appear to be going around in circles > (Re:Associated bidirectional transport path requirements) > > > > Deborah, > > > > Thank you for confirming that we can speak about ENNI for non-IP layer > interconnects. As you indicate, an ENNI also exists when we interconnect = two > SDH admin domains via an STM-N. > > > > Do you also agree that we can speak about an ENNI when we interconnect a > Metro/Carrier Ethernet Network admin domain A with a Metro/Carrier Ethere= nt > Network admin domain B via an 802.3 interface over which the EVC layer is > transported? > > > > Regards, > > Maarten > > > ------------------------------ > > *From:* BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > *Sent:* dinsdag 28 april 2009 17:52 > *To:* Maarten Vissers > *Cc:* mpls-tp@ietf.org > *Subject:* RE: [mpls-tp] We appear to be going around in circles > (Re:Associated bidirectional transport path requirements) > > Exactly =A8C G707 defined the ENNI for SDH and G703/G704 for PDH. The PHY= and > framing is defined (per layer). This definition is very different from yo= ur > earlier email. It does not require supporting PDH<->SDH interworking, or = PDH > OAM in SDH, or OAM interworking between a client/server as one of your > earlier emails required: > > > > >For this case it is necessary to develop ETH<>PW(client) layer > > > network > > > interworking specifications. To limit the complexity of such layer > > > network interworking, it is beneficial to select the MPLS-TP PW OAM > > > to > > > use the Y.7131 OAM PDUs as proposed in draft-bhh-mpls-tp-oam-y1731. > > > I.e. > > > both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs > > > > The interconnection of equipment (at one layer) should not put any > restrictions on other layers. > > > > *From:* Maarten Vissers [mailto:maarten.vissers@huawei.com] > *Sent:* Tuesday, April 28, 2009 7:01 AM > *To:* BRUNGARD, DEBORAH A, ATTLABS > *Cc:* mpls-tp@ietf.org > *Subject:* RE: [mpls-tp] We appear to be going around in circles > (Re:Associated bidirectional transport path requirements) > > > > Deborah, > > > > > And the UNI/ENNI being discussed there is not comparable to your > definition. > > > > I be more then happy if you give me alternative terms to UNI and ENNI. > > > > Just use the example of a customer requesting a 2 Mbit/s service from the > SDH network, of which the first customer location is located behind the > network of operator A and the second endpoint is located behind the netwo= rk > of operator B. Operator A and B interconnect via a STM-1 interface with e= ach > other. The customer connects via a 2 Mbit/s G.703 interface with the > networks of operator A and B. > > > > What term should I use for the interconnect of the customer to the networ= ks > of operator A and B? > > I.e. if it is not possible to call this the "UNI", what should it be call= ed > then? > > > > What term should I use for the interconnect of the networks of operator A > and B? > > I.e. if it is not possible to call this the "ENNI", what should it be > called then? > > > > Thanks for your help. > > Regards, > > Maarten > > PS. Note that G.8012 defines UNI as follows: "An interface that is used > for the interconnection of customer equipment with a network element of t= he > transport network." > > > ------------------------------ > > *From:* BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > *Sent:* maandag 27 april 2009 23:00 > *To:* Greg Mirsky; Maarten Vissers > *Cc:* mpls-tp@ietf.org > *Subject:* RE: [mpls-tp] We appear to be going around in circles > (Re:Associated bidirectional transport path requirements) > > Maarten, > > > > I think you have oversimplified the discussion in MEF and in so doing hav= e > inaccurately summarized. As Greg says, MEF is oriented towards services > (SLA/SLS) and they also recognize that some operators only need simple > troubleshooting tools. Considering the on-going discussion in MEF, for th= e > service operators group, it is questionable if Y1731 should be used by > MPLS-TP as a baseline as it is considered inadequate. And I don=A1=AFt se= e AT&T=A1=AFs > requirements as any different from BT. I think we should follow Adrian=A1= =AFs and > Ben=A1=AFs proposal to define the actual requirements for MPLS-TP before > replicating other technologies=A1=AF solutions. > > > > And the UNI/ENNI being discussed there is not comparable to your > definition. > > > > Deborah > > > > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *Greg Mirsky > *Sent:* Monday, April 27, 2009 2:47 PM > *To:* Maarten Vissers > *Cc:* mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] We appear to be going around in circles > (Re:Associated bidirectional transport path requirements) > > > > Dear Maarten, > you definitely know but I'd note that MEF formulates requirements for > Carrier Ethernet as a service, i.e. client layer of a transport network, = not > requirements for the transport network as server layer. Thus requirements > expressed by SPs at MEF are not applicable or transitive, in my view, to > MPLS-TP, at least not automatically. > > Regards, > Greg Mirsky > > 2009/4/27 Maarten Vissers > > Tom, > > This AIS discussion has been held in previous technologies as well, e.g. > Ethernet OAM. > The result was that AIS insertion is optional and that Ethernet equipment > (see G.8021) can be configured to insert Ethernet AIS or to not insert > Ethernet AIS. > > > > Do you see our (BT's) requirements to be very divergent from those of > other operators participating in this effort? > > I see the requirements for OAM that have been expressed in this mpls-tp > discussion by BT representatives to be different from the requirements > expressed by other operator representatives. For example > draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT, > KPN, KDDI and CT. I also see that the OAM requirements defined in MEF (wi= th > input from e.g. AT&T and Verizon) be different from those expressed by BT > representatives. I see that MEF is requesting to support in Y.1731 frame > loss counting for more then one priority level; i.e. an extension of the > existing capability that support frame loss counting for a single priorit= y > (i.e. a case of more OAM, not less OAM). > > I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have > created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtua= l > UNI specifications, while representatives of BT state that there can't be > "UNI" or "E-NNI" interfaces associated with packet transport networks, as > those networks are "not top of stack". I see that many operators require > compliance with MEF specifications, including the Ethernet UNI > specification. > > I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service v= ia > rooted-multipoint EVCs, which EVCs terminate outside the KPN network (ref= er > to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and > > http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.h= tml > ); i.e. a peer-interconnection case and a potential case for TCM, a case > which according to BT representatives does not exist. > > I see that the "message, file, stream" concepts are key to BT's > considerations, while I don't see any of that contributed by other > operators. When I look at the telecom network stack (see attached slide), > then message, file stream are important concepts at Layer 3 (NGN) where > those represent the characteristics of the main services (data, voice, > video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important > services at Layer 2 (PTN). This raises the question what the scope of > MPLS-TP is for you: > A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to support > the IP based Layer 3 Services/Channel layer > B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to support > the EVC based Layer 2 Services/Channel layer. > > Regards, > Maarten > > > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: vrijdag 24 april 2009 15:35 > To: Maarten Vissers > > Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) > > > Maartin, > > > Ben, > > > > Your company is one of the many operators in the world, and the number > > of nodes outside your network is factors larger then the number of > > nodes inside your network. My experience is that different operators > > have different sets of requirements. Manufacturers have to support the > > superset of those requirements. Each operator will then deploy the > > subset of provided features that fits its needs (and turn off or don't > > use the others). Your company for some years has been asking for less, > > other operators have been asking for more. Manufacturers thus build > > their products with lots of configurability to support all variations. > > Do you see our (BT's) requirements to be very divergent from those > of other operators participating in this effort? Unless our requirements > are very different, I am confident vendors will build (or have built) the= ir > devices based on our (sensible) requirements. > > > It is my opinion that we should not remove well established features > > like AIS, TCM, frame loss counting, delay measurement, loopback, etc > > before the majority of operators have agreed that such features are > > not longer necessary. > > Again, that is your opinion, which frankly seems to diverge from > what other operators have expressed. Furthermore, let me recommend that y= ou > get out of the habit of telling your customers (or potential ones), what > they require after they have been plainly clear about what they want. > Unless you think we don't know what we are talking about. Is this perhaps > the case? > > --Tom > > > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of Ben Niven-Jenkins > > Sent: vrijdag 24 april 2009 0:14 > > To: mpls-tp@ietf.org > > Subject: [mpls-tp] We appear to be going around in circles (Re: > > Associated > > bidirectional transport path requirements) > > > > Colleagues, > > > > The current debates appear to be going around in circles and achieving > > nothing of value IMO. Two major operators have expressed their > > opinions and no operator that I can see has disagreed with those > > opinions. > > > > I apologise for being direct (and possibly rude) but I am getting > > tired of being told by folks who do not represent operators what > > functionality I need or should have in my networks. > > > > To put some context on BT's comments in these threads: > > I have the largest MPLS network in the UK. > > I have one of the largest MPLS networks globally delivering service to > > 173 countries with over 200 000 customer ports I have (off the top of > > my > > head) > > at least another 10 MPLS networks in specific countries covering at > > least 3 continents delivering dedicated services to particular market > > segments. > > > > I have an extremely large SDH network in the UK consisting of over 30 > > 000 switches and supporting in excess of 1 million circuits. > > I have an extremely large SDH network globally delivering service in > > 110 countries. > > > > I would like to think my BT colleagues and I might know a little > > something about building large scale networks and the requirements of > > those networks and the needs of the customers that I deliver services > > to. > > > > Can we please stop these circular arguments which are IMO going > > nowhere and focus on the task in hand which is defining the > > requirements (and later > > solutions) being asked for by myself, my company and my colleagues in > > other operators on this list. > > > > Thanks > > Ben > > > > > > -- > > > > Ben Niven-Jenkins > > IP, Data & Content Architect > > Network Infrastructure Architecture, BT > > > > E-mail: benjamin.niven-jenkins@bt.com > > Office: +44 (0)1473 648225 > > Mobile: +44 (0)7918 077205 > > Fax: +44 (0)1332 578827 > > > > British Telecommunications plc. Registered office: 81 Newgate Street > > London > > EC1A 7AJ Registered in England no: 1800000 > > > > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > > wrote: > > > >> ben: > >> I understand your meaning, you still wish to resign and make a more > >> reliable and effective, easy to operator and easy to manage packet > >> transport network like me. but why not apply this SDH/SONET in the > >> future maybe the following cause: > >> 1 it adopted circuit switching techonogy to bring lower useful of > >> the resource than PTN network; > >> 2 it can't bear all kinds of traffics like PTN networks it noted > >> that we can't apply SDH/SONET network in the future not because it > >> have a complex OAM functions. while more people like to move the > >> advantages of the OAM functions in SDH/SONET to PTN networks. and > >> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should > >> use and extend the AIS/FDI functions to MPLS-TP ; > >> > >> best regards > >> liu > >> > >> > >> > >> Ben Niven-Jenkins > >> 2009-04-23 07:58 > >> > >> =CA=D5=BC=FE=C8=CB > >> , "BRUNGARD, DEBORAH A, ATTLABS" > >> > >> =B3=AD=CB=CD > >> > >> =D6=F7=CC=E2 > >> Re: [mpls-tp] Associated bidirectional transport path requirements > >> > >> > >> > >> > >> > >> > >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn" > >> wrote: > >> > >>> Deborah: > >>> maybe what you said is right. but I can't completely agree your > >> opinions. > >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it > >>> should have AIS/FDI fuctions as SDH/SONET. > >>> > >>> do you think so. > >> > >> No we must assess the requirements for packet transport networks > >> supporting the needs of operators today and in the future. We must > >> not blindly recreate SDH/SONET. If we do so without consideration to > >> how operators' needs and requirements may have evolved (and continue > >> to evolve in future) we will have failed IMO and I would severely > >> question the value of the work we will have produced. If we just > >> recreate SDH/SONET then what is the purpose of the work an operator > >> would be better off just deploying existing SDH/SONET equipment. > >> > >> > >> Ben > >> > >> > >> > >> > >> > >> -------------------------------------------------------- > >> ZTE Information Security Notice: The information contained in this > >> mail is solely property of the sender's organization. This mail > >> communication is confidential. Recipients named above are obligated > >> to maintain secrecy and are not permitted to disclose the contents of > >> this > > communication to others. > >> This email and any files transmitted with it are confidential and > >> intended solely for the use of the individual or entity to whom they > >> are addressed. If you have received this email in error please notify > >> the originator of the message. Any views expressed in this message > >> are those of the individual sender. > >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > --001636c5b2443503ea0468b5aeaf Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Maarten, in my view the answer to your question depends upon answer= to "What Tunnel A and Tunnel B are?" Regards, Greg = 2009/4/29 Maarten Vissers = <maarten.vissers@huawei.co= m> Deborah, You are going far beyond my question. Let me try to clarify=20 by using a figure, In this figure there is an admin domain A and an admin d= omain=20 B. These two domains are interconnected via an 802.3 interface over which t= he=20 EVC layer is continued. My question is how we should refer to this interfac= e=20 between domains A and B? Is this interface referred to as ENNI? If it is no= t=20 referred to as ENNI, what is then the name to use for this class of=20 interfaces?     (A)     &nbs= p;          =      (B) <= /div> ------------------------------------ |   EVC      &n= bsp;               EVC  =20 | ------------------------------------ | Tunnel | &= nbsp; |802.3|   | Tunne= l | ------------   ------- &nbs= p; ----------- | T.Media |   &= nbsp; ^      | T.Me= dia=20 | ------------   = ;   |      -----------            &n= bsp;     =20 |            &n= bsp;    =20 ENNI?<= /div> Regards, Maarten From: BRUNGARD, D= EBORAH A, ATTLABS=20 [mailto:dbrungard@at= t.com] Sent: woensdag 29 april 2009=20 17:06 To: Maarten Vissers Cc:=20 mpls-tp@ietf.org<= br>Subject: RE: [mpls-tp] We appear to be going around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Maarten, <= /p> I=20 only have confirmed that what you have given as an example of an ENNI below= is=20 G707 and G704. You missed the point. This is a typical ITU interface standa= rd.=20 It can be used as an INNI, ENNI, or UNI. Since you are twisting words, I&rs= quo;ll try=20 to be clearer. <= /p> Yes,=20 we need interface standards. If we have standards and have defined the=20 technology properly, we do not need your “interworking ENNI”. &= nbsp;You have=20 twisted the definition of a standard interface used between (hopefully) all= =20 equipment, within a domain and between domains, to rationalize your “= ENNI”. Two=20 operators (or Forum) agreeing on a physical encapsulation, J1, vlans, or la= bel=20 to be used may be described in the industry as interworking, but then it ca= n be=20 said that every interface is interworking. The fiber connectors are=20 interworking. Instead of saying, I’m connecting the fiber, we will sa= y, we are=20 interworking the fiber. This is silly. Rather than use a much hyped non-spe= cific=20 term, here, in ITU and IETF, we should be specific. <= /p> The=20 ENNI/UNIs defined in MPLS Forum and MEF are a profile of existing standards= .=20 They provide a consistent interpretation of an existing standard for the me= mbers=20 of the Forum (i.e. improved readability for the members, as we all know, IT= U=20 Recommendations and IETF RFCs are often not standalone documents or not eas= y=20 reading for non-involved readers). It is questionable for IETF or ITU to de= fine=20 an ENNI or UNI as it will be difficult for all the members to agree –= otherwise=20 all the options should not be in the original standard if they were not=20 needed. <= /p> Connecting=20 two networks together using a standard physical layer is not really an ENNI= (as=20 Neil has said over and over). If we start defining UNI/ENNI/INNI for all th= e=20 technologies in ITU and IETF, we will have an operational=20 nightmare. <= /p> Deborah= <= /p> From: Maarten Vissers=20 [mailto:maa= rten.vissers@huawei.com] Sent: Wednesday, April 29, 2009=20 3:23 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org<= br>Subject: RE: [mpls-tp] We appear to be going around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Deborah, = Thank=20 you for confirming that we can speak about ENNI for non-IP layer interconne= cts.=20 As you indicate, an ENNI also exists when we interconnect two SDH admin dom= ains=20 via an STM-N. = Do you=20 also agree that we can speak about an ENNI when we interconnect a Metro/Car= rier=20 Ethernet Network admin domain A with a Metro/Carrier Etherent Network admin= =20 domain B via an 802.3 interface over which the EVC layer is=20 transported? = Regards, Maarten From:= BRUNGARD, DEBORAH=20 A, ATTLABS [mailto:d= brungard@att.com] Sent: dinsdag 28 april 2009=20 17:52 To: Maarten Vissers Cc:=20 mpls-tp@ietf.org<= br>Subject: RE: [mpls-tp] We appear to be going around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Exactly=20 – G707 defined the ENNI for SDH and G703/G704 for PDH. The PHY and fr= aming is=20 defined (per layer). This definition is very different from your earlier em= ail.=20 It does not require supporting PDH<->SDH interworking, or PDH OAM in = SDH,=20 or OAM interworking between a client/server as one of your earlier emails= =20 required: <= /p> >For this case it is necessary to develop=20 ETH<>PW(client) layer > network >    interworking specifications. To=20 limit the complexity of such layer >    network interworking, it is=20 beneficial to select the MPLS-TP PW OAM > to >    use the Y.7131 OAM PDUs as proposed=20 in draft-bhh-mpls-tp-oam-y1731. > I.e. >    both=20 Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs <= /p> The=20 interconnection of equipment (at one layer) should not put any restrictions= on=20 other layers. <= /p> From: Maarten Vissers=20 [mailto:maa= rten.vissers@huawei.com] Sent: Tuesday, April 28, 2009=20 7:01 AM To: BRUNGARD, DEBORAH A, ATTLABS Cc:=20 mpls-tp@ietf.org<= br>Subject: RE: [mpls-tp] We appear to be going around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Deborah, = >=20 And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. = I be=20 more then happy if you give me alternative terms to UNI and=20 ENNI. = Just=20 use the example of a customer requesting a 2 Mbit/s service from the SDH=20 network, of which the first customer location is located behind the network= of=20 operator A and the second endpoint is located behind the network of operato= r B.=20 Operator A and B interconnect via a STM-1 interface with each other. The=20 customer connects via a 2 Mbit/s G.703 interface with the networks of opera= tor A=20 and B. = What=20 term should I use for the interconnect of the customer to the networks of= =20 operator A and B? I.e.=20 if it is not possible to call this the "UNI", what should it be c= alled=20 then? = What=20 term should I use for the interconnect of the networks of operator A and=20 B? I.e.=20 if it is not possible to call this the "ENNI", what should it be = called=20 then? = Thanks=20 for your help. Regards, Maarten= PS.=20 Note that G.8012 defines UNI as follows: "An=20 interface that is used for the interconnection of customer equipment with a= =20 network element of the transport network." = From:= BRUNGARD, DEBORAH=20 A, ATTLABS [mailto:d= brungard@att.com] Sent: maandag 27 april 2009=20 23:00 To: Greg Mirsky; Maarten Vissers Cc:=20 mpls-tp@ietf.org<= br>Subject: RE: [mpls-tp] We appear to be going around=20 in circles (Re:Associated bidirectional transport path=20 requirements) Maarten, <= /p> I=20 think you have oversimplified the discussion in MEF and in so doing have=20 inaccurately summarized. As Greg says, MEF is oriented towards services=20 (SLA/SLS) and they also recognize that some operators only need simple=20 troubleshooting tools. Considering the on-going discussion in MEF, for the= =20 service operators group, it is questionable if Y1731 should be used by MPLS= -TP=20 as a baseline as it is considered inadequate. And I don’t see AT&= T’s=20 requirements as any different from BT. I think we should follow Adrian&rsqu= o;s and=20 Ben’s proposal to define the actual requirements for MPLS-TP before r= eplicating=20 other technologies’ solutions. <= /p> And=20 the UNI/ENNI being discussed there is not comparable to your=20 definition. <= /p> Deborah= <= /p> From:=20 mpls-tp-bounc= es@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 Greg Mirsky Sent: Monday, April 27, 2009 2:47 PM To:=20 Maarten Vissers Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp]=20 We appear to be going around in circles (Re:Associated bidirectional transp= ort=20 path requirements) Dear Maarten, you definitely=20 know but I'd note that MEF formulates requirements for Carrier Ethernet= as a=20 service, i.e. client layer of a transport network, not requirements for the= =20 transport network as server layer. Thus requirements expressed by SPs at ME= F are=20 not applicable or transitive, in my view, to MPLS-TP, at least not=20 automatically. Regards, Greg Mirsky 2009/4/27 Maarten Vissers <maarten.vissers@huawei.com> Tom, This AIS discussion has been held in previous=20 technologies as well, e.g. Ethernet OAM. The result was that AIS inse= rtion=20 is optional and that Ethernet equipment (see G.8021) can be configured t= o=20 insert Ethernet AIS or to not insert Ethernet AIS. > Do you see our (BT's)=20 requirements to be very divergent from those of other operators particip= ating=20 in this effort? I see the requirements for OAM that have been expressed in=20 this mpls-tp discussion by BT representatives to be different from the= =20 requirements expressed by other operator representatives. For=20 example draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of= DT,=20 FT, KPN, KDDI and CT. I also see that the OAM requirements defined in ME= F=20 (with input from e.g. AT&T and Verizon) be different from those expr= essed=20 by BT representatives. I see that MEF is requesting to support in Y.1731= =20 frame loss counting for more then one priority level; i.e. an extension = of=20 the existing capability that support frame loss counting for a single=20 priority (i.e. a case of more OAM, not less OAM). I see that the= =20 operators active in MEF (e.g. AT&T, Verizon, Sprint) have created an= d are=20 creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtual UNI=20 specifications, while representatives of BT state that there can't be"UNI"=20 or "E-NNI" interfaces associated with packet transport networks, = as those=20 networks are "not top of stack". I see that many operators requir= e compliance=20 with MEF specifications, including the Ethernet UNI specification. I=20 see that e.g. KPN provides a Wholesale Broadband Access (WBA) service=20 via rooted-multipoint EVCs, which EVCs terminate outside the KPN network= =20 (refer to http://www.kpn-wholesale.com/nl/1672-Broadband= _Services.html=20 and http://www.kpn-wholesale.com/nl/1936= -Wholesale_Broadband_Access_Service.html );=20 i.e. a peer-interconnection case and a potential case for TCM, a case wh= ich=20 according to BT representatives does not exist. I see that the "= ;message,=20 file, stream" concepts are key to BT's considerations, while I = don't see any=20 of that contributed by other operators. When I look at the telecom netwo= rk=20 stack (see attached slide), then message, file stream are important conc= epts=20 at Layer 3 (NGN) where those represent the characteristics of the main= =20 services (data, voice, video), whereas "E-Line, E-Tree, E-LAN, PDH = CES, etc"=20 are the important services at Layer 2 (PTN). This raises the question wh= at=20 the scope of MPLS-TP is for you: A) MPLS-TP is a Layer 3 Tunnel/Path = layer=20 technology which has to support the IP based Layer 3 Services/Channel=20 layer B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to= =20 support the EVC based Layer 2 Services/Channel=20 layer. Regards, Maarte= n -----Original Message----- From: Thomas Nadeau=20 [mailto:tnadea= u@lucidvision.com] Sent:=20 vrijdag 24 april 2009 15:35 To: Maarten Vissers Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org Subject: Re: [mpls-tp] We=20 appear to be going around in circles (Re: Associated bidirectional trans= port=20 path requirements) Maartin, >=20 Ben, > > Your company is one of the many operators in the world= , and=20 the number > of nodes outside your network is factors larger then the= =20 number of > nodes inside your network. My experience is that differen= t=20 operators > have different sets of requirements. Manufacturers have t= o=20 support the > superset of those requirements. Each operator will then= =20 deploy the > subset of provided features that fits its needs (and tur= n off=20 or don't > use the others). Your company for some years has been = asking=20 for less, > other operators have been asking for more. Manufacturers = thus=20 build > their products with lots of configurability to support all=20 variations. Do you see our (BT's)=20 requirements to be very divergent from those of other operators particip= ating=20 in this effort? Unless our=20 requirements are very different, I am confident vendors will build (or h= ave=20 built) their devices based on our (sensible) requirements. > I= t is=20 my opinion that we should not remove well established features > like= AIS,=20 TCM, frame loss counting, delay measurement, loopback, etc > before t= he=20 majority of operators have agreed that such features are > not longer= =20 necessary. Again, that is your=20 opinion, which frankly seems to diverge from what other operators have= =20 expressed. Furthermore, let me recommend that you get out of the habit o= f=20 telling your customers (or potential ones), what they require after they= have=20 been plainly clear about what they want. Unless you think we don't k= now what=20 we are talking about. Is this perhaps the case? --Tom = >=20 Regards, > Maarten > > -----Original Message----- >= =20 From: mpls-tp= -bounces@ietf.org=20 [mailto:mpls-= tp-bounces@ietf.org]=20 On > Behalf Of Ben Niven-Jenkins > Sent: vrijdag 24 april 2009= =20 0:14 > To: mpls= -tp@ietf.org >=20 Subject: [mpls-tp] We appear to be going around in circles (Re: >=20 Associated > bidirectional transport path requirements) > &g= t;=20 Colleagues, > > The current debates appear to be going around i= n=20 circles and achieving > nothing of value IMO. Two major operators hav= e=20 expressed their > opinions and no operator that I can see has disagre= ed=20 with those > opinions. > > I apologise for being direct (= and=20 possibly rude) but I am getting > tired of being told by folks who do= not=20 represent operators what > functionality I need or should have in my= =20 networks. > > To put some context on BT's comments in these= =20 threads: > I have the largest MPLS network in the UK. > I have = one=20 of the largest MPLS networks globally delivering service to > 173=20 countries with over 200 000 customer ports I have (off the top of >= =20 my > head) > at least another 10 MPLS networks in specific coun= tries=20 covering at > least 3 continents delivering dedicated services to=20 particular market > segments. > > I have an extremely lar= ge=20 SDH network in the UK consisting of over 30 > 000 switches and suppor= ting=20 in excess of 1 million circuits. > I have an extremely large SDH netw= ork=20 globally delivering service in > 110 countries. > > I wou= ld=20 like to think my BT colleagues and I might know a little > something = about=20 building large scale networks and the requirements of > those network= s and=20 the needs of the customers that I deliver services > to. > &= gt;=20 Can we please stop these circular arguments which are IMO going > now= here=20 and focus on the task in hand which is defining the > requirements (a= nd=20 later > solutions) being asked for by myself, my company and my colle= agues=20 in > other operators on this list. > > Thanks >=20 Ben > > > -- > > Ben Niven-Jenkins > IP= ,=20 Data & Content Architect > Network Infrastructure Architecture,= =20 BT > > E-mail: benjamin.niven-jenkins@bt.com >=20 Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332=20 578827 > > British Telecommunications plc. Registered office: <= span> 81 Newgate=20 Street > London > EC1A 7AJ Registered in En= gland=20 no: 1800000 > > >=20 On 23/04/2009 07:23, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> >=20 wrote: > >> ben: >> I understand your meaning, you = still=20 wish to resign and make a more >> reliable and effective, easy to= =20 operator and easy to manage packet >> transport network like me. b= ut=20 why not apply this SDH/SONET in the >> future maybe the following= =20 cause: >> 1 it adopted circuit=20 switching techonogy to bring lower useful of >> the resource than = PTN=20 network; >> 2 it can't bear all=20 kinds of traffics like PTN networks it noted >> that we can't = apply=20 SDH/SONET network in the future not because it >> have a complex O= AM=20 functions. while more people like to move the >> advantages of the OAM functions in=20 SDH/SONET to PTN networks. and >> AIS/FDI function is a kind of OA= M=20 functions of SDH/SONET . we should >> use and extend the AIS/FDI= =20 functions to MPLS-TP ; >> >> best regards >>=20 liu >> >> >> >> Ben Niven-Jenkins <<= a href=3D"mailto:benjamin.niven-jenkins@bt.com" target=3D"_blank">benjamin.= niven-jenkins@bt.com> >>=20 2009-04-23 07:58 >> >> =CA=D5=BC=FE= =C8=CB >>=20 <liu.guoman@z= te.com.cn>,=20 "BRUNGARD, DEBORAH A, ATTLABS" >> <dbrungard@att.com> >> = =B3=AD=CB=CD >> <mpls-tp@ietf.org> >> =D6=F7=CC=E2 >> Re: [mpls-tp]= Associated bidirectional=20 transport path=20 requirements >> >> >> >> >>>> >>=20 On 21/04/2009 02:59, "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> >>= =20 wrote: >> >>> Deborah: >>> maybe what you = said=20 is right. but I can't completely agree your >>=20 opinions. >>> IMO. mpls-tp is regard as transport network like= =20 SDH/SONET. so it >>> should have AIS/FDI fuctions as=20 SDH/SONET. >>> >>> do you think=20 so. >> >> No we must assess the requirements for packet= =20 transport networks >> supporting the needs of operators today and = in=20 the future. We must >> not blindly recreate SDH/SONET. If we do so= =20 without consideration to >> how operators' needs and requireme= nts may=20 have evolved (and continue >> to evolve in future) we will have fa= iled=20 IMO and I would severely >> question the value of the work we will= have=20 produced. If we just >> recreate SDH/SONET then what is the purpos= e of=20 the work an operator >> would be better off just deploying existin= g=20 SDH/SONET equipment. >> >> >>=20 Ben >> >> >> >> >> >>= =20 -------------------------------------------------------- >> ZTE=20 Information Security Notice: The information contained in this >> = mail=20 is solely property of the sender's organization. This mail >>= =20 communication is confidential. Recipients named above are obligated >= >=20 to maintain secrecy and are not permitted to disclose the contents=20 of >> this > communication to others. >> This email= and=20 any files transmitted with it are confidential and >> intended sol= ely=20 for the use of the individual or entity to whom they >> are addres= sed.=20 If you have received this email in error please notify >> the=20 originator of the message. Any views expressed in this message >> = are=20 those of the individual sender. >> This message has been scanned f= or=20 viruses and Spam by ZTE Anti-Spam > system. > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@= ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp = > > >=20 _______________________________________________ > mpls-tp mailing=20 list > mpls-tp@= ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp= _____________________________________= __________ mpls-tp=20 mailing list mpls-= tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --001636c5b2443503ea0468b5aeaf-- From jingr@ties.itu.ch Wed Apr 29 18:43:51 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C283A7146 for ; Wed, 29 Apr 2009 18:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfoExGHoiaVn for ; Wed, 29 Apr 2009 18:43:50 -0700 (PDT) Received: from protext01.itu.ch (protext01.itu.ch [156.106.192.41]) by core3.amsl.com (Postfix) with ESMTP id 86FEE3A68FE for ; Wed, 29 Apr 2009 18:43:50 -0700 (PDT) Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Apr 2009 03:45:12 +0200 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1241055911414; Thu, 30 Apr 2009 03:45:11 +0200 Received: from ties.itu.ch (ties.itu.ch [156.106.192.33]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id n3U1j72p210319; Thu, 30 Apr 2009 03:45:09 +0200 (MEST) Received: from localhost (tokaj.itu.ch [156.106.192.34]) by ties.itu.ch (8.14.3/8.14.3) with ESMTP id n3U1j7LU021571; Thu, 30 Apr 2009 03:45:07 +0200 (CEST) Received: from 156.106.192.159 ( [156.106.192.159]) as user jingr@ties.itu.ch by gold.itu.ch with HTTP; Thu, 30 Apr 2009 03:45:07 +0200 Message-ID: <1241055907.49f902a335587@gold.itu.ch> Date: Thu, 30 Apr 2009 03:45:07 +0200 From: ruiquan.jing@ties.itu.int To: maarten.vissers@huawei.com, mpls-tp@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 156.106.192.159 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (mail6.itu.ch [156.106.192.22]); Thu, 30 Apr 2009 03:45:11 +0200 (MEST) X-OriginalArrivalTime: 30 Apr 2009 01:45:12.0179 (UTC) FILETIME=[4D299430:01C9C935] Subject: Re: [mpls-tp] Interworking X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 01:52:17 -0000 Hi Maarten�� What's difference between (3) and (4)? And for (3) and (4), with PW do you mean SS-PW or both SS-PW and MS-PW? I think it should include both. IMO, I think we should choose (4) with the addition of PDH/SDH/ATM etc. client beside EVC. Best Regards Jing Ruiquan -------------------------------------------------------------------------------- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: Wednesday, April 29, 2009 5:05 PM To: 'Michael T. Wu (mtwu)'; mpls-tp@ietf.org Subject: Re: [mpls-tp] Interworking Michael, I have been discussing interworking with existing Ethernet technologies on this mailinglist for some time, but we have not made much progress so far. Before we can talk about such "interworking" or "interconnection" we have to agree on the layer stack of MPLS-TP based packet transport network domains. I believe that there are four alternative MPLS-TP based packet transport network layer stacks: (1) (2) (3) (4) ------------ --------------- ------------- ------- | EVC | | EVC & MS-PW | | EVC | | EVC | ------------ --------------- ------------- ------------ | LSP | | LSP | | PW | | PW | ------------ --------------- ------------- ------------ | T.Media | | Trans.Media | | LSP | | LSP | ------------ --------------- ------------- ------------ | T.Media | | T.Media | ------------- ------------ Which of these four stacks do we want to standardize for MPLS-TP based packet transport networks? For Ethernet based packet transport networks the layer stack is: (5) ------------ | EVC | ------------ | EVP | ------------ | T.Media | ------------ For PBB-TE based packet transport networks the layer stack is: (6) ------------ | EVC | ------------ | TESI | ------------ | T.Media | ------------ We will also have to talk about the layer stack of the interface connecting the two technologies. I expect that those layer stacks to interconnect with Ethernet and PBB-TE based packet transport network domains will be: (7) (8) ------------ ----------- | EVC | | EVC | ------------ ----------- | T.Media | | EVP | ------------ ----------- | T.Media | ----------- Interconnection/Interworking Ethernet and MPLS-TP packet transport network domains may then be one of the following cases (note: numbers refer to the layer stacks above): A) (1) - (7) - (5) B) (1) - (8) - (5) C) (2) - (7) - (5) D) (2) - (8) - (5) E) (3) - (7) - (5) F) (3) - (8) - (5) G) (4) - (7) - (5) H) (4) - (8) - (5) In the above cases A to H I have assumed that the two domains that interconnect/interwork have each their own equipment, and interconnection is via an 802.3 interface. In many cases both domains will be sharing an edge node and interconnection is via the switch matrix; i.e. one line port connects to the ethernet domain and the other line port connects to the MPLS-TP domain. This adds another four cases: I) (1) - (5) J) (2) - (5) K) (3) - (5) L) (4) - (5) Regards, Maarten -------------------------------------------------------------------------------- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Michael T. Wu (mtwu) Sent: woensdag 29 april 2009 8:25 To: mpls-tp@ietf.org Subject: [mpls-tp] Interworking Hi, Is there a draft or discussion on the interworking with existing technologies (L2 or L3) and standards (ITU/MEF)? Thanks, Michael From su.hui@zte.com.cn Wed Apr 29 19:03:14 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7A43A6ECE; Wed, 29 Apr 2009 19:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.89 X-Spam-Level: X-Spam-Status: No, score=-91.89 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_81=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyu-q5rUjDUT; Wed, 29 Apr 2009 19:03:11 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 0B95D3A6B81; Wed, 29 Apr 2009 19:03:09 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101105171106; Thu, 30 Apr 2009 09:56:36 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 74772.5514055519; Thu, 30 Apr 2009 10:00:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3U21ncC099093; Thu, 30 Apr 2009 10:01:49 +0800 (CST) (envelope-from su.hui@zte.com.cn) In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C047E2328@E03MVB2-UKBR.domain1.systemhost.net> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: su.hui@zte.com.cn Date: Thu, 30 Apr 2009 09:59:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-30 10:01:46, Serialize complete at 2009-04-30 10:01:46 Content-Type: multipart/alternative; boundary="=_alternative 000B290C482575A8_=" X-MAIL: mse2.zte.com.cn n3U21ncC099093 Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: [mpls-tp] =?gb2312?b?tPC4tDogUkU6IFJFOiBSZTogIEFJUy9GREkgKHdhcyBB?= =?gb2312?b?c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgJcmVxdWly?= =?gb2312?b?ZW1lbnRzKQ==?= X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 02:03:14 -0000 This is a multipart message in MIME format. --=_alternative 000B290C482575A8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTmVpbCwNCg0KSSB0aGluayBJIG1pc3VuZGVyc3Rvb2QgdGhlIHdvcmRzIKGudG9wLW9mLXN0 YWNrIG5ldHdvcmuhryAsIEl0IGRvZXNuoa90IA0KbWVhbiBhIG5ldHdvcmsgaXMgYWN0dWFsbHkg YXQgdG9wIG9mIHRoZSBzdGFjaywgc28gbm8gbWF0dGVyIHdoYXQgbGF5ZXIgSVAgDQpuZXR3b3Jr IGlzIGFjdHVhbGx5IGF0LCBJUCBuZXR3b3JrIGlzIGFsd2F5cyBhIKGudG9wLW9mLXN0YWNrIG5l dHdvcmuhryANCmJlY2F1c2UgaXQgY2FuIKGuc3VwcG9ydCBleHRlcm5hbCBtZXNzYWdlL2ZpbGUv c3RyZWFtIGFwcGxpY2F0aW9uc6GvLiBJcyANCm15IHVuZGVyc3RhbmRpbmcgcmlnaHQ/DQoNCkJ1 dCBJIHN0aWxsIGNhbm5vdCBhZ3JlZSB0aGUgYXNzZXJ0aW9uIHRoYXQgoa5hbnkgbm9uIHRvcC1v Zi1zdGFjayBuZXR3b3JrIA0KaGFzIG5vIG5lZWQgZm9yIEUtTk5JIHBlZXItcGFydGl0aW9uIHdv cmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0aW5nIA0KcGFydGllc6GvLiBBcyB5b3Ugc2Fp ZCBTREggaXMgbm90IGEgdG9wLW9mLXN0YWNrIG5ldHdvcmssIGJ1dCBWQzQgDQpjb25uZWN0aW9u cyBjYW4gcGFzcyB0aHJvdWdoIG11bHRpIG9wZXJhdG9yoa9zIGRvbWFpbnMsIHNvIHRoZSBpbnRl cmZhY2UgDQpiZXR3ZWVuIGRpZmZlcmVudCBkb21haW5zIGlzIEUtTk5JLiANCg0KUmVnYXJkcywN ClN1aHVpLg0KDQoNCg0KDQo8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbT4gDQoyMDA5LTA0LTI5IDE4 OjIxDQoNCsrVvP7Iyw0KPHN1Lmh1aUB6dGUuY29tLmNuPg0Ks63LzQ0KPGFkcmlhbkBvbGRkb2cu Y28udWs+LCA8YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20+LCANCjxoaGVsdm9vcnRAY2hl bGxvLm5sPiwgPG1wbHMtdHBAaWV0Zi5vcmc+LCA8bXBscy10cC1ib3VuY2VzQGlldGYub3JnPg0K 1vfM4g0KUkU6IFJFOiBSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggDQpyZXF1aXJlbWVudHMpDQoNCg0KDQoNCg0KDQpUaGFu a3MgU3VodWkuLi4uLi5zb3JyeSBJIG1pc3NlZCB5b3VyIHNwZWNpZmljIHF1ZXN0aW9uLi4uLmhh dmUgYSBsb29rIA0KaW4tbGluZSBhbmQgc2VlIGlmIHRoaXMgaGVscHMuDQoNCkZyb206IHN1Lmh1 aUB6dGUuY29tLmNuIFttYWlsdG86c3UuaHVpQHp0ZS5jb20uY25dIA0KU2VudDogMjkgQXByaWwg MjAwOSAxMDozMQ0KVG86IEhhcnJpc29uLE4sTmVpbCxDWE0gUg0KQ2M6IGFkcmlhbkBvbGRkb2cu Y28udWs7IE5pdmVuLWplbmtpbnMsQixCZW4sRE1GIFI7IGhoZWx2b29ydEBjaGVsbG8ubmw7IA0K bXBscy10cEBpZXRmLm9yZzsgbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQpTdWJqZWN0OiC08Li0 OiBSRTogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IA0KdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KDQoNCkhpIE5laWyjrCANCg0KVGhhbmtz IGZvciB5b3VyIHJhcGlkIHJlcGx5LiANCkkgYW0gY29uZnVzZWQgYnkgeW91ciBjb21tZW50cywg YXJlIHlvdSBzdWdnZXN0aW5nIA0KRXZlcnl0aGluZ292ZXJJUG92ZXJNUExTLVRQPyBBRkFJSywg TVBMUy1UUCBjYW4gY2FycnkgbWFueSBraW5kcyBvZiANCmNsaWVudHMsIG5vdCBqdXN0IElQLklu IG15IGV4YW1wbGUsIEUxb3ZlclBXb3Zlck1QTFMtVFAsIHRoZXJlIGlzIG5vIElQIA0KbGF5ZXIg YXQgYWxsLiAgDQogDQpOSD0+IEZ1bGx5IHVuZGVyc3RhbmQuICBJIHdhcyBnaXZpbmcgSVAgYXMg YW4gKmV4YW1wbGUqIG9mIGEgdGVjaG5vbG9neSANCnRoYXQgY2FuIHN1cHBvcnQgcmVhbCBleHRl cm5hbCBhcHBsaWNhdGlvbnMgYmVjYXVzZSBpdCBoYXMgDQptZXNzYWdlL2ZpbGUvc3RyZWFtIGFw cGxpY2F0aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zIGluIHRoZSBmb3JtIG9mIA0KVURQL1RDUC9S VFAuICAgSW4gdGhlIGNhc2Ugb2YgRTEgdGhhdCB5b3Ugbm90ZSAoYXMgRTFvdmVyUFdvdmVyTVBM Uy1UUCkgDQp5b3UgaGF2ZSB0byBhc2sgeW91cnNlbGYgd2hhdCBzcGVjaWZpYyAqZXh0ZXJuYWwq IGFwcGxpY2F0aW9ucyBkb2VzIHRoZSBFMSANCnN1cHBvcnQgaGVyZT8uLi4uLmFsd2F5cyByZW1l bWJlcmluZyB0aGF0ICphbnkqIG5ldHdvcmtpbmcgdGVjaG5vbG9neSBNVVNUIA0KdWx0aW1hdGVs eSBzdXBwb3J0IHNvbWUgZm9ybSBvZiAqZXh0ZXJuYWxseSBzb3VyY2VkKiBpbmZvcm1hdGlvbiBz b3VyY2UgDQplbHNlIGl0IGlzIG5vdCBzZXJ2aW5nIGFueSBwdXJwb3NlLiAgU28ganVzdCBzdXBw b3J0aW5nIEUxIG9uIGl0cyBvd24gZG9lcyANCm5vdCBwcm92aWRlIHRoaXMuLi4uZm9yIGV4YW1w bGUgYXNrIHlvdXJzZWxmIGhvdyB2b2ljZSBvciBhbnkgdHlwZSBvZiANCm1lc3NhZ2UvZmlsZSBk YXRhIGdldHMgY2FycmllZCBieSB0aGUgRTEuDQogDQpBbmQgeW91IGRvbqGvdCBhbnN3ZXIgbXkg cXVlc3Rpb246IElQIGlzIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgaW4gdGhlIA0KY2FzZSBvZiBF MW92ZXJQV292ZXJJUCwgd2h5IGRvZXNuJ3QgTVBMUy1UUCBiZSBhIHRvcC1vZi1zdGFjayBuZXR3 b3JrIGluIA0KdGhlIGNhc2Ugb2YgRTFvdmVyUFdvdmVyTVBMUy1UUD8gVGhleSBhcmUgYXQgdGhl IHNhbWUgcG9zaXRpb24gaW4gdGhlIA0Kc3RhY2ssIGFuZCBJIHRoaW5rIEUxIGlzIKGucmVhbCBl eHRlcm5hbCBzdHJlYW0gYXBwbGljYXRpb25zoa8gDQogDQpOSD0+IFRoZSBwb2ludCBoZXJlIGlz IHRoYXQgKmFueSogbmV0d29yayBtb2RlL3RlY2hub2xvZ3kgKGJlIGl0IGNsLXBzLCANCmNvLXBz IG9yIGNvLWNzKSBjYW4gYWN0IGFzIHRoZSBzZXJ2ZXIgZm9yIGFueSBvdGhlciBtb2RlL3RlY2hu b2xvZ3kuIA0KSG93ZXZlciwgbm90IGFsbCB0ZWNobm9sb2dpZXMgY2FuIHN1cHBvcnQgZXh0ZXJu YWwgYXBwbGljYXRpb25zLi4uLi50byANCnN1cHBvcnQgdGhlc2UgdGhlIHRlY2hub2xvZ3kgbXVz dCBoYXZlIGFwcGxpY2F0aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zIA0KZm9yIHRoZSBtZXNzYWdl L2ZpbGUvc3RyZWFtIGluZm9ybWF0aW9uIHNvdXJjZXMgdGhhdCBhcmUgZ2VuZXJhdGVkIGluIA0K ZXh0ZXJuYWwgQ1BFLCBlZyBwaG9uZSwgUEMsIGV0Yy4NCiANCk1vc3QgdGVjaG5vbG9naWVzIGRv IG5vdCBoYXZlIHRoZXNlIGV4dGVybmFsIGFwcGxpY2F0aW9uIGFkYXB0YXRpb24gDQpmdW5jdGlv bnMgYW5kIHNvIHRoZSBvbmx5IGpvYiB0aGV5IGNhbiBkbyBpcyBjcmVhdGUgdGhlIHRvcG9sb2d5 IG9mIG90aGVyIA0KbGF5ZXIgbmV0d29ya3MuDQogDQpTbyB5ZXMgd2UgY2FuIHVzZSBJUCAoY2wt cHMpIHRvIGNhcnJ5IFNESCBWQzQgKGNvLWNzKSBpZiB3ZSANCndhbnQuLi4uLi4ucHJvYmFibHkg bm90IGEgZ29vZCBpZGVhIGJ1dCBpdCBpcyBmb3Igc3VyZSBwb3NzaWJsZS4gIEhvd2V2ZXIsIA0K YW4gU0RIIFZDNCBuZXR3b3JrIGNhbm5vdCAqZGlyZWN0bHkqIHN1cHBvcnQgZWl0aGVyIHZvaWNl IG9yIGRhdGEgYnV0IGFuIA0KSVAgbmV0d29yayBjYW4uLi4uLmJlY2F1c2UgSVAgaGFzIFVEUC9U Q1AvUlRQIGFwcGxpY2F0aW9ucyBhZGFwdGF0aW9ucyBhbmQgDQpTREggVkM0IGRvZXMgbm90IGhh dmUgdGhlc2UuICBIYXZpbmcgc2FpZCB0aGF0LCB0aGVyZSBpcyBpbiBwcmluY2lwbGUgbm8gDQpy ZWFzb24gd2h5IGFueSBtb2RlL3RlY2hub2xvZ3kgKGV2ZW4gU0RIIFZDNCkgY2Fubm90IHN1cHBv cnQgZXh0ZXJuYWwgDQptZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucy4uLi4uLml0cyBq dXN0IHRoYXQgZm9yIG1vc3QgdGVjaG5vbG9naWVzIA0KdGhlc2UgaGF2ZSBuZXZlciBiZWVuIHNw ZWNpZmllZCBiZWNhdXNlIHRoZXkgd2VyZSBvbmx5IGV2ZXIgaW50ZW5kZWQgdG8gDQpwcm92aWRl IGEgJ25ldHdvcmsgYnVpbGRlcicgdHJhbnNwb3J0IHJvbGUuDQogDQpBc2lkZT0+IElmIGEgdGVj aG5vbG9neSBYIGNhbiBzdXBwb3J0IG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zIA0K ZGlyZWN0bHkgdGhlbiBoZXJlIHdlIHdvdWxkIG1vc3QgZGVmaW5pdGVseSBoYXZlIHRvIGNvbnNp ZGVyIA0KcGVlci1pbnRlcndvcmtpbmcgdGVjaG5vbG9neSBYIHdpdGggYm90aCBJUCAoSW50ZXJu ZXQpIGFuZCBQU1ROICh2b2ljZSANCmNhc2Ugb25seSkuICBJbiBhbGwgb3RoZXIgY2FzZXMgKGll IHdoZXJlIHRlY2hub2xvZ3kgWCBpcyBub3QgDQp0b3Atb2Ytc3RhY2ssIGllIGRvZXMgbm90IGhh dmUgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbiBhZGFwdGF0aW9uIA0KZnVuY3Rpb25z KSB0aGVyZSBpcyBubyBuZWVkIGZvciBwZWVyLWludGVyd29ya2luZyBpdCB3aXRoIGFueSBvdGhl ciANCnRlY2hub2xvZ3ksIGluY2x1ZGluZyBJUCAoSW50ZXJuZXQpIGFuZCBQU1ROLg0KIA0KIA0K WW91ciBmaW5hbCBwb2ludCAoIkkgdGhpbmsgRTEgaXMgoa5yZWFsIGV4dGVybmFsIHN0cmVhbSBh cHBsaWNhdGlvbnOhryIgKSANCmlzIG5vdCBzdHJpY3RseSBjb3JyZWN0IGJ1dCBJIGNhbiBmdWxs eSB1bmRlcnN0YW5kIHdoeSB5b3Ugc2F5IHRoaXMuICBFMSANCmJlbG9uZ3MgdG8gdGhlIGNvLWNz IG1vZGUuICBXaGVuIHlvdSBhbmFseXNlIHRoaXMgKGFzIGlzIGRvbmUgaW4gRy44MDAsIA0Kd2hp Y2ggZXhwbGFpbnMgd2h5IHRoZSAzIG5ldHdvcmsgbW9kZXMgYXJpc2UgZnJvbSBpbmZvcm1hdGlv bi9zeXN0ZW1zIA0KdGhlb3J5IGNvbnNpZGVyYXRpb25zKSB5b3UgZmluZCB0aGF0IGluIHRoZSB0 aW1lIGRpbWVuc2lvbiB0aGUgY28tY3MgbW9kZSANCnBhcnRpdGlvbnMgcmVzb3VyY2UgKHRpbWUp IHVwIGludG8gcmVndWxhciB0aW1lIHNsaWNlcy4uLi5zbyB0aGlzIG1lYW5zIA0KYm90aCB0aGUg c3RhcnQgZXBvY2ggKGFuIGltcGxpY2l0IGxhYmVsKSBhbmQgKG1vc3QgY3J1Y2lhbGx5KSBpdHMg ZHVyYXRpb24gDQphcmUgZml4ZWQuIA0KIA0KV2l0aG91dCBnb2luZyBpbnRvIG1ham9yIGRldGFp bCBoZXJlIChJIGhhdmUgcGFwZXIgb24gdGhpcyBJIGNhbiBzZW5kIHlvdSANCmlmIHlvdSB3YW50 Li4uanVzdCBhc2spIHdoYXQgdGhpcyBtZWFucyBpcyB0aGF0IHRoZSBjby1jcyBtb2RlIGlzIHRo ZSANCnVsdGltYXRlICdzbW9vdGhlci9zaGFwZXInIGZvciBjbGllbnQgdHJhZmZpYy4uLi4uLnNv IGFzIHlvdSByaWdodGx5IA0Kb2JzZXJ2ZSB0aGlzIGxvb2tzIGxpa2UgYSBzdHJlYW0gY2FzZS4g IEl0J3Mgbm90IGEgc3BlY2lmaWMgZXh0ZXJuYWwgDQphcHBsaWNhdGlvbiBob3dldmVyIGxpa2Ug aHVtYW4gdm9pY2Ugb3IgdmlkZW8gKHRoZXNlIG11c3QgZ2VuZXJhdGUgcmVhbCANCippbmZvcm1h dGlvbiogdGhhdCBjb21tdW5pY2F0aW5nIHBhcnRpZXMgdW5kZXJzdGFuZCkgYnV0IGl0IGZvciBz dXJlIGhhcyANCnRoZSBDQlIgYmVoYXZpb3VyIG9mIGEgc3RyZWFtLiANCiANCkJUVyB0aGUgcmVh c29uIHRoZSBjby1jcyBtb2RlIGhhcyBiZWVuIGVuZHVyaW5nbHkgc3VjY2Vzc2Z1bCBhcyBhIA0K dHJhbnNwb3J0IG5ldHdvcmsgaXMgYmVjYXVzZSBpdCBwcm92aWRlcyAqdHJhbnNwYXJlbmN5KiB0 byBhbGwgY2xpZW50cyANCih3aGljaCBpcyBleGFjdGx5IHRoZSBzaW1pbGFyIGJlaGF2aW91ciBv ZiBhIHN0cmVhbSBhcyB5b3Ugbm90ZSksIGllDQotICAgIGFsbCBjbGllbnQgYml0cyB0cmVhdGVk IGVxdWFsbHkgKGEgcmVhbGx5IGtleSBwb2ludCB0aGlzLCBhcyB0aGlzIA0KbWVhbnMgaXQgcHJv dmlkZXMgZXF1YWwgJ2ltcG9ydGFuY2UnIHRyZWF0bWVudCBvZiB0aGUgdWx0aW1hdGUgaGlnaGVy IA0KbGV2ZWwgKGFuZCB1bnNlZW4vdW5rbm93biBieSB0aGUgY28tY3MgdHJhbnNwb3J0IG5ldHdv cmspIA0KbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMpDQotICAgIGNsaWVudCBiaXQg b3JkZXJpbmcgaXMgcHJlc2VydmVkDQotICAgIGRvZXMgbm90IHRyeSBhbiBpbmZlciBtZWFuaW5n IG9mIGNsaWVudCBiaXRzIG5vciBjaGFuZ2UgdGhlbQ0KLSAgICBlbnN1cmVzIHRoZSB0cmFmZmlj IGJlaGF2aW91ciBvZiBjbGllbnQgWCBjYW5ub3QgaW1wYWN0IHRoZSANCnBlcmZvcm1hbmNlIGV4 cGVyaWVuY2VkIGJ5IHBhcnR5IFkuDQogDQogDQpyZWdhcmRzLCBOZWlsIA0KDQpSZWdhcmRzLCAN ClN1aHVpLiANCg0KDQo8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbT4gDQoyMDA5LTA0LTI5IDE0OjQw IA0KDQoNCsrVvP7Iyw0KPHN1Lmh1aUB6dGUuY29tLmNuPiANCrOty80NCjxhZHJpYW5Ab2xkZG9n LmNvLnVrPiwgPGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tPiwgDQo8aGhlbHZvb3J0QGNo ZWxsby5ubD4sIDxtcGxzLXRwQGlldGYub3JnPiwgPG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZz4g DQrW98ziDQpSRTogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoICANCnJlcXVpcmVtZW50cykNCg0KDQoNCg0KDQoNCg0KDQpU aGFua3MgU2h1aHVpLCANCiAgDQpEbyBub3QgY29uZnVzZSBwaHlzaWNhbCBpbnRlcmNvbm5lY3Qg d2l0aCBFLU5OSS4uLi4uSSdsbCBjb21lIGJhY2sgb24gdGhpcyANCnNob3J0bHkgd2hlbiBkaXNj dXNzaW5nIHRoZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4gDQogIA0KVGhlIGZpcnN0 IHRoaW5nIHRvIHVuZGVyc3RhbmQgaXMgdGhhdCAqYWxsKiBuZXR3b3JrcyBhcmUgdGhlcmUgdG8g DQp1bHRpbWF0ZWx5IHN1cHBvcnQgb25lIHB1cnBvc2UuLi4uLmFuZCB0aGF0IGlzIHRvIGFsbG93 IGNvbW11bmljYXRpb25zIA0KYmV0d2VlbiBwYXJ0aWVzIHRoYXQgYXJlICpleHRlcm5hbCogdG8g dGhlIG5ldHdvcmtzLiAgU28gZXZlcnl0aGluZyB3ZSBkbyANCmluIG5ldHdvcmtpbmcgaXMgdGhl cmUgdG8gdWx0aW1hdGVseSBzdXBwb3J0IHRoaXMgb2JqZWN0aXZlLiAgV2hhdCB0aGlzIA0KbWVh bnMgaXMgdGhhdCB0aGUgRFAgb2Ygc29tZSBuZXR3b3JrICh3aGF0IEkgY2FsbCB0aGUgdG9wLW9m LXN0YWNrIA0KbmV0d29yaykgTVVTVCBiZSBwcm92aWRpbmcgYWRhcHRhdGlvbiBmdW5jdGlvbnMg Zm9yIHRoZXNlIGV4dGVybmFsIA0KYXBwbGljYXRpb25zLi4uLi4uLmFuZCB0aGVzZSBjYW4gZ2Vu ZXJpY2FsbHkgYmUgY2xhc3NpZmllZCBhcyBtZXNzYWdlcywgDQpmaWxlcyBhbmQgc3RyZWFtcy4g DQogIA0KV2UgY2FuIHNlZSB0aGF0IElQIGlzIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgYXMgaXQg aGFzIFVEUC9UQ1AvUlRQIChmb3IgDQpleGFtcGxlKSBhZGFwdGF0aW9ucy4gIEFUTSB3YXMgYWxz byBvbmNlICh+OTBzKSBpbnRlbmRlZCB0byBiZSBhIA0KdG9wLW9mLXN0YWNrIG5ldHdvcmsgYW5k IGl0IGhhZCBpdHMgb3duIGFwcGxpY2F0aW9uIGFkYXB0YXRpb25zIGluIHRoZSANCmZvcm0gb2Yg QUFMcy4gIEF0IG9uZSBzdGFnZSB0aGVyZSB3ZXJlIDUgb2YgdGhlc2UsIGJ1dCBpbiBwcmFjdGlj ZSBvbmx5IGEgDQpjb3VwbGUgd2VyZSByZWFsbHkgc3VjY2Vzc2Z1bCBiZWNhdXNlIG9mIHRoZSBn ZW5lcmljIG5hdHVyZSBvZiANCm1lc3NhZ2UvZmlsZS9zdHJlYW0gY2xhc3NpZmljYXRpb24uICBU aGUgUFNUTiBpcyBhbHNvIHRvcC1vZi1zdGFjaywgYW5kIA0KaXRzIGFwcGxpY2F0aW9uIGFkYXB0 YXRpb24gd2FzIG1haW5seSBmb3Igdm9pY2UgKHN0cmVhbSkgc3VwcG9ydC4gDQogIA0KTW9zdCBv dGhlciBuZXR3b3JrcyBkbyBub3QgaGF2ZSB0aGVzZSBhcHBsaWNhdGlvbiBhZGFwdGF0aW9uIA0K ZnVuY3Rpb25zLi4uLnNvIHRoZXkgZG8gbm90IGRpcmVjdGx5IHN1cHBvcnQgYXBwbGljYXRpb25z LiAgV2hhdCB0aGlzIA0KbWVhbnMgaW4gcHJhY3RpY2UgaXMgdGhhdCB0aGVzZSBuZXR3b3JrcyAo YSBsaXN0IHdoaWNoIGluY2x1ZGVzIFBESCwgU0RILCANCk9UTiwgRXRoZXJuZXQsIE1QTFMpIE1V U1QgY2FycnkgYSBmdXJ0aGVyIGxheWVyIG5ldHdvcmsgYWJvdmUgdGhlbSB0aGF0IGlzIA0KdG9w LW9mLXN0YWNrLi4uLmxpa2UgSVAuICBUaGVyZSBpcyBubyBjaG9pY2UgaW4gdGhlIG1hdHRlciBo ZXJlLiAgU28gDQp3aGlsc3Qgd2UgbWlnaHQgc2F5IHRoYXQgYW4gTVBMUyBuZXR3b3JrIGlzIGNh cnJ5aW5nIGFuIEUxIFBXIHRoZSBFMSANCmVudGl0eSBtdXN0IGluIHR1cm4gYmUgY2Fycnlpbmcg c29tZSBvdGhlciB0b3Atb2Ytc3RhY2sgbmV0d29yayAobGlrZSBJUCANCm9yIFBTVE4pLCBlbHNl IGl0IGlzIHNlcnZpbmcgbm8gdWx0aW1hdGUgcHVycG9zZS4gDQogIA0KTm93IGluIG9yZGVyIHRv IHRyYW5zbWl0IGluZm9ybWF0aW9uIG92ZXIgZ2VvZ3JhcGhpYyBkaXN0YW5jZSB3ZSBtdXN0IA0K bW9kdWxhdGUgYW4gRU0gd2F2ZSBvbiBzb21lIG1ldGFsbGljL29wdGljYWwvcmFkaW8gbWVkaWEu Li4udGhpcyBpcyB0aGUgDQpib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4gIFRoZXNlIGFy ZSBoaWdoIGJpdCByYXRlIHRyYW5zcG9ydCBwaXBlcyANCndob3NlIGZ1bmN0aW9uIGlzIHRvIHBy b3ZpZGUgdHJhbnNwYXJlbnQgKHdoaWNoIEkgaGF2ZSBkZWZpbmVkIHByZXZpb3VzbHkpIA0KdHJh bnNwb3J0IHRvIHdoYXRldmVyIGNsaWVudCBsYXllcnMgbmV0d29ya3Mgc2l0IGFib3ZlIHRoZW0u Li4uYW5kIHdoZXJlLCANCmFzIEkgbm90ZWQgYWJvdmUsIHRoZXJlIE1VU1QgYmUgYSB0b3Atb2Yt c3RhY2sgbmV0d29yayBwcmVzZW50IGFzIHRoZSANCnVsdGltYXRlIGxheWVyIG5ldHdvcmsgY2xp ZW50IGVsc2UgdGhlcmUgaXMgbm90IGV4dGVybmFsIHBhcnR5IA0KY29tbXVuaWNhdGlvbiBwb3Nz aWJsZS4gDQogIA0KU28gd2hlbiB3ZSBjb25uZWN0IHRvZ2V0aGVyIDIgdG9wLW9mLXN0YWNrIG5l dHdvcmtzIHdlIGRvIHNvIGF0IGEgc2VjdGlvbiANCmxheWVyIHdoaWNoIGlzIGludmFyaWFibHkg Y2FycnlpbmcgYSB2ZXJ5IGxhcmdlIGFnZ3JlZ2F0ZSBvZiANCmFwcGxpY2F0aW9ucy4uLi4uYW5k IG9mIGNvdXJzZSB0aGVzZSBhcHBsaWNhdGlvbnMgY2FuIGJlIGEgdGltZSB2YXJ5aW5nIA0KbWl4 IG9mIG1lc3NhZ2UvZmlsZS9zdHJlYW0gY2FzZXMgd2l0aCBhIHNldCBvZiB1bmtub3duICh0byB0 aGUgc2VjdGlvbiANCmxheWVyKSBpbXBvcnRhbmNlJ3MgKGVyZ28gd2h5IHRyYW5zcGFyZW5jeSBp cyBhbiBlc3NlbnRpYWwgcmVxdWlyZW1lbnQgaW4gDQp0cmFuc3BvcnQgbmV0d29ya3MpLiANCiAg DQpUaGUgcmVhbCBFLU5OSXMgKHdoaWNoIGNvbnNpZGVycyBib3RoIERQIGFuZCBDUCBjb21wb25l bnRzLi4uLndlIG5ldmVyIA0KdXN1YWxseSBwZWVyIHRoZSBNUCwgYW5kIHdlIHJlc3RyaWN0IHRo ZSBzY29wZSBvZiB0aGUgQ1ApIGV4aXN0IGluIHRoZSANCnRvcC1vZi1zdGFjayBsYXllciBuZXR3 b3JrLiAgVGhlIHNlY3Rpb24gbGF5ZXIgaW50ZXJjb25uZWN0IGlzIGEgZHVtYiBEUCANCnBpcGUu Li5pdCBqdXN0IHNoaWZ0cyBiaXRzIHRyYW5zcGFyZW50bHkgYW5kIG1haW50YWlucyB0aGVpciBv cmRlcmluZy4gDQpUaGVyZSBpcyBubyBjb25jZXB0IG9mIENQIChvciBNUCkgcGVlcmluZyBvbiB0 aGVzZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiANCmxheWVyIGludGVyY29ubmVjdHMuIA0KQXNp ZGU9PiBJbiBzb21lIGNvdW50cmllcyB0aGVzZSBpbnRlcmNvbm5lY3RzIGhhdmUgdG8gYmUgY2Fy ZWZ1bGx5IA0Kc3BlY2lmaWVkIGluIG9yZGVyIHRvIGRpc3Rpbmd1aXNoIHJlZ3VsYXRlZCBhbmQg dW5yZWd1bGF0ZWQgDQpzZXJ2aWNlcy4uLi4uc28gdGhlcmUgYXJlIGltcG9ydGFudCBsZWdhbC9j b21tZXJjaWFsIGNvbnNpZGVyYXRpb25zIGhlcmUsIA0KaXQgaXMgbm90IHNpbXBseSBhIHRlY2hu aWNhbCBpc3N1ZS4gDQogIA0KV2UgY2FuIG9mIGNvdXJzZSBjcmVhdGUgRS1OTklzIGluIG5vbiB0 b3Atb2Ytc3RhY2sgbGF5ZXIgbmV0d29ya3MgKHdlIGNhbiANCmRvIG1hbnkgdGhpbmdzIHRoYXQg YXJlIG5vdCB1c2VmdWwpLiAgU28gbGV0cyBhc3N1bWUgd2UgZG8gdGhpcy4uLi4uYW5kIA0KbGV0 cyBhc3N1bWUgd2UgY2hvb3NlIE1QTFMgc2luY2UgeW91IG1lbnRpb24gdGhpcyBpbiB0aGUgbWFp bCBiZWxvdy4gDQogIA0KTm93IGhvdyBkbyBleHRlcm5hbCBwYXJ0aWVzIHdobyB3aXNoIHRvIGNv bW11bmljYXRlIGludGVyZmFjZSB3aXRoIHRoaXMgDQpNUExTIG5ldHdvcms/ICBDYW4geW91IHN1 cHBvcnQgYWxsIHR5cGVzIG9mIG1lc3NhZ2UvZmlsZS9zdHJlYW0gDQphcHBsaWNhdGlvbnMgKmRp cmVjdGx5KiBpbnRvIE1QTFM/ICBJbiBwcmluY2lwbGUgeW91IGNvdWxkIGlmIHlvdSBhbGxvd2Vk IA0KTVBMUyB0byBoYXZlIGVuZCBzeXN0ZW0gYXBwbGljYXRpb24gYWRhcHRhdGlvbnMgc3VjaCBh cyBVRFAvVENQL1JUUCBvciB0aGUgDQpsaWtlLiAgQnV0IHRoZXNlIGRvbid0IGV4aXN0IHRvZGF5 LCBhbmQgaW4gdGhlIG1vc3QgdXN1YWwgY2FzZSB0aGUgTVBMUyANCm5ldHdvcmsgd2lsbCBjYXJy eSBhbiBJUCBsYXllciBuZXR3b3JrIGJlY2F1c2UgdGhpcyBjYW4gc3VwcG9ydCB0aGUgDQptZXNz YWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucy4gDQogIA0KV2UgY2FuIGdvIHRocm91Z2ggZXhh Y3RseSB0aGUgc2FtZSBhbmFseXNpcyB3aXRoIGFueSBuZXR3b3JrIHRoYXQgaXMgbm90IA0KdG9w LW9mLXN0YWNrLCBlZyBFdGhlcm5ldC4gIEFuZCB3aGVuIHlvdSBkbyB0aGlzIHdoYXQgeW91IHJl YWxpc2UgaXMgdGhhdCANCmFsdGhvdWdoIHdlIGNhbiBjcmVhdGUgcGVlciBpbnRlcndvcmtpbmcg b2YgTVBMUyAob3Igd2hhdGV2ZXIpIHRoaXMgaGFzIA0Kbm90IHJlYWxseSBoZWxwZWQgc2luY2Ug d2UgbWlnaHQgYXMgd2VsbCBoYXZlIGp1c3QgdGVybWluYXRlZCB0aGUgTVBMUyANCm5ldHdvcmsg YW5kIHBhc3NlZCB0aGUgSVAgbGF5ZXIgYWNyb3NzLiANCiAgDQpOb3cgdGhlIGFib3ZlIGJlY29t ZXMgZXZlbiBtb3JlIHN0cmlraW5nIGluIGl0cyBpbXBvcnRhbmNlIGlmIHlvdSBjb25zaWRlciAN CnBlZXIgaW50ZXJ3b3JraW5nIG9mIDIgZGlmZmVyZW50IG5vbiB0b3Atb2Ytc3RhY2sgbmV0d29y a3MuLi4ubGV0cyBwaWNrIA0KTVBMUyBhbmQgRXRoZXJuZXQgYmVjYXVzZSB0aGF0IGlzIHdoYXQg aXMgb2Z0ZW4gbWVudGlvbmVkLiAgIA0KICANCldoYXQgd2UgaGF2ZSB0byBkbyBub3cgYXQgdGhl IEUtTk5JcyBiZXR3ZWVuIEV0aGVybmV0IGFuZCBNUExTIGlzIGdvIA0KdGhyb3VnaCBlYWNoIERQ IGFuZCBDUCBjb21wb25lbnQgYW5kIGRvIGEgJ3Byb3RvY29sIGNvbnZlcnNpb24nIGV4ZXJjaXNl IA0Kd2hlcmUgcmVxdWlyZWQuLi4uLi5hbmQgdGhlIGZpcnN0IHByb2JsZW0geW91IHdpbGwgZW5j b3VudGVyIGlzIHRoYXQgdGhlcmUgDQp3aWxsIGJlIGxvdHMgb2YgZnVuY3Rpb25hbCBtaXNtYXRj aC4gIE1vcmVvdmVyIGlmIG9uZSBvciBib3RoIG9mIHRoZSANCm5ldHdvcmtzIGNhbiBzdXBwb3J0 IG11bHRpcGxlIENQIHR5cGVzIGxpa2UgTVBMUyBjYW4sIGVnIFJTVlAtVEUgDQpzaWduYWxsaW5n LCBMRFAgc2lnbmFsbGluZywgQkdQNCAnc2lnbmFsbGluZycsIE9TUEYgcm91dGluZywgSVMtSVMg DQpyb3V0aW5nLi4uLi5hbmQgSSBjb3VsZCBsaXN0IHNpbWlsYXIgZm9yIEV0aGVybmV0Li4uLi55 b3UgYXJlIGdvaW5nIHRvIA0KaGF2ZSB0byBjb25zaWRlciBlYWNoIHBhaXJpbmcgY2FzZSBpbiB0 dXJuLiAgQSBsb3Qgb2Ygd29yay4gDQogIA0KQW5kIHdoZW4geW91IGhhdmUgZG9uZSBhbGwgdGhp cyB5b3UgYXNrIHRoZSBxdWVzdGlvbiAnd2hhdCBpcyBpdCB0aGF0IA0KY2FycmllcyB0aGUgcmVh bCBleHRlcm5hbCBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyBpbiB0aGUgRFAgDQpo ZXJlPycuLi4uLi4uYW5kIG5vdyB5b3UgZmluZCBubyBuYXRpdmUgc3VwcG9ydCBmb3IgdGhlc2Ug aW4gTVBMUyBvciANCkV0aGVybmV0LCBidXQgd2hhdCB3ZSBkbyBmaW5kIGlzIHRoYXQgYm90aCBv ZiB0aGVtIGFyZSBjYXJyeWluZyBJUCBiZWNhdXNlIA0KdGhpcyBkb2VzIHN1cHBvcnQgdGhlIGV4 dGVybmFsIGFwcGxpY2F0aW9ucy4gIE5vdyBhdCB0aGlzIHBvaW50IHdlIGhhdmUgDQpkaXNjb3Zl cmVkIHdoYXQgaXMgdGhlIGNvbW1vbiB0aGluZyBiZXR3ZWVuIE1QTFMgYW5kIEV0aGVybmV0Li4u Lml0IGlzIHRoZSANCnRvcC1vZi1zdGFjayBJUCBsYXllciBuZXR3b3JrLiAgQW5kIHNvIHdlIHVs dGltYXRlbHkgcmVhbGlzZSB3ZSBjb3VsZCBoYXZlIA0Kc2F2ZSBvdXJzZWx2ZXMgYSBsb2FkIG9m IHVubmVjZXNzYXJ5IHdvcmsgYnkgc2ltcGx5IHRlcm1pbmF0aW5nIHRoZSBNUExTIA0KYW5kIEV0 aGVybmV0IGxheWVyIG5ldHdvcmsgYXQgdGhlIGludGVyd29ya2luZyBwb2ludCBhbmQganVzdCBw YXNzZWQgdGhlIA0KSVAgbGF5ZXIgbmV0d29yayBhY3Jvc3MuIA0KICANClNvcnJ5IEkndmUgaGFk IHRvIGdvIHRocm91Z2ggYWxsIHRoaXMgeWV0IGFnYWluIChlc3AgZm9yIGFsbCB0aGUgZm9sa3Mg DQp0aGF0IGhhdmUgYWxyZWFkeSB1bmRlcnN0b29kIHRoZSBwb2ludCkgYnV0IEkgZG8gaG9wZSBp dHMgY2xlYXIgbm93IGFuZCB3ZSANCmNhbiBwdXQgdGhpcyBpc3N1ZSB0byBiZWQuIA0KICANCnJl Z2FyZHMsIE5laWwgDQoNCkZyb206IHN1Lmh1aUB6dGUuY29tLmNuIFttYWlsdG86c3UuaHVpQHp0 ZS5jb20uY25dIA0KU2VudDogMjkgQXByaWwgMjAwOSAwMzoyMg0KVG86IEhhcnJpc29uLE4sTmVp bCxDWE0gUg0KQ2M6IGFkcmlhbkBvbGRkb2cuY28udWs7IE5pdmVuLWplbmtpbnMsQixCZW4sRE1G IFI7IGhoZWx2b29ydEBjaGVsbG8ubmw7IA0KbXBscy10cEBpZXRmLm9yZzsgbXBscy10cC1ib3Vu Y2VzQGlldGYub3JnDQpTdWJqZWN0OiC08Li0OiBSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBB c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgDQp0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQoN Cg0KSGkgTmVpbCwgDQoNCqGuaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhIHNpbXBsZSB0ZWNobmlj YWwgYW5hbHlzaXMgdGhhdCBhbnkgbm9uIA0KdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5vIG5l ZWQgZm9yIEUtTk5JIHBlZXItcGFydGl0aW9uIHdvcmtpbmcgYmV0d2VlbiANCmRpZmZlcmVudCBv cGVyYXRpbmcgcGFydGllcy6hryANCg0KSSBjYW5ub3QgYWdyZWUgdGhpcyBzdGF0ZW1lbnQuIA0K Rm9yIGV4YW1wbGUsIHRoZXJlIGFyZSB0d28gSVAgbmV0d29ya3MgYmVsb25naW5nIHRvIHR3byBv cGVyYXRvcnMsIGEgRTEgaXMgDQp0cmFuc3BvcnRlZCBmcm9tIEEgbmV0d29yayB0byBCIG5ldHdv cmsgKGUuZy4gRTFvdmVyUFdvdmVySVAgKSwgSVAgDQpwYWNrZXQobm90IEUxKSBwYXNzIGFjcm9z cyBmb3JtIEEgdG8gQiBhdCBib3JkZXIgbm9kZSwgc28gdGhlcmUgaXMgYSBFLU5OSSANCmJldHdl ZW4gdGhlc2UgIHR3byBJUCBuZXR3b3JrLiBJbiB0aGlzIGNhc2UsIGlzIElQIGEgdG9wLW9mLXN0 YWNrIG5ldHdvcms/IA0KDQpOb3cgbGV0IHVzIHJlcGxhY2UgSVAgbmV0d29ya3MgYnkgTVBMUy1U UCBuZXR3b3JrcyAoZS5nLiANCkUxb3ZlclBXb3Zlck1QTC1UUCksIE1QTFMtVFAgbmV0d29yayBp cyBhdCBzYW1lIHBvc2l0aW9uIGluIHRoZSBzdGFjayBhcyANCklQIG5ldHdvcmsgaXMsIHdoeSBj YW4gSVAgbmV0d29yayBoYXZlIEUtTk5JIGJ1dCBNUExTLVRQIGNhbm5vdD8gDQoNClJlZ2FyZCwg DQpTdWh1aSANCg0KPG5laWwuMi5oYXJyaXNvbkBidC5jb20+IA0Kt6K8/sjLOiAgbXBscy10cC1i b3VuY2VzQGlldGYub3JnIA0KMjAwOS0wNC0yOCAxNDo0MyANCg0KDQrK1bz+yMsNCjxoaGVsdm9v cnRAY2hlbGxvLm5sPiwgPGFkcmlhbkBvbGRkb2cuY28udWs+LCANCjxiZW5qYW1pbi5uaXZlbi1q ZW5raW5zQGJ0LmNvbT4gDQqzrcvNDQptcGxzLXRwQGlldGYub3JnIA0K1vfM4g0KUmU6IFttcGxz LXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo IA0KcmVxdWlyZW1lbnRzKQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIdXViIHdyb3RlIDI3IEFwcmls IDIwMDkgMjI6MjcNCj4gDQo+IEhpIEFkcmlhbiwNCj4gDQo+IFlvdSB3cm90ZToNCj4gDQo+ID4g SXNuJ3QgdGhlIHNvbHV0aW9uIGhlcmUgdGhlIHNhbWUgYXMgdGhlIG9uZSBJIHByb3Bvc2VkIGZv ciAiVENNIj8NCj4gDQo+IEluZGVlZCwgYW5kIHRoYXQgd2UgZG8gbm90IGhhdmUgdG8gYXJvdW5k IGluIGNpcmNsZXMgYWJvdXQgVENNLg0KPiANCj4gSG93IGFib3V0Og0KPiB0aGUgcmVxdWlyZW1l bnQgaXMgdGhhdCBhIHNlcnZlciBsYXllciBzaGFsbCBpbmZvcm0gaXRzIGNsaWVudHMNCj4gdGhh dCBpdCBoYXMgZGV0ZWN0ZWQgYSBzZXJ2aWNlIGludGVydXB0aW9uLCB0aGlzIHRvIGVuc3VyZSB0 aGF0DQo+IHRoZSBjbGllbnRzIGNhbiBpbmhpYml0ICh1bm5lY2Vzc2FyeSkgYWxhcm1zLg0KDQpO SD0+IFRoaXMgb25seSBhcHBsaWVzIGlmIHRoZSBjbGllbnQvc2VydmVyIGJpbmRpbmcgaXMgZml4 ZWQuICBBbmQgb2YNCmNvdXJzZSB3YXkgYmFjayBpbiB0aGUgNzBzIHdoZW4gYmluYXJ5IGFsbCAx cyBwb3BwZWQgb3V0IG9mIHRoZSBmYWlsZWQNClRUTCBsb2dpYyBpbnRvIHRoZSBQREggdHJhbnNw b3J0IGhpZXJhcmNoeSB0aGlzIHdhcyB0cnVlLiAgQWxzbzogbm8NCmxhYmVscyBoZXJlIGFuZCBu byBjbGllbnQgdHJhZmZpYyB1bml0cyB0byBjcmVhdGUuIA0KDQpXaGVyZSB0aGUgY2xpZW50IGNh biBkeW5hbWljYWxseSBiZSByZS1yb3V0ZWQgaW4gcmVzcG9uc2UgdG8gYSBzZXJ2ZXINCmZhaWx1 cmUgdGhlIHByb3Bvc2VkIHRleHQgaXMgbm90IHZhbGlkLiAgSXQgaXMgYWxzbyBub3QgbmVjZXNz YXJ5IHRoYXQNCnRoZSBzZXJ2ZXIgaGFzIHRvIGtlZXAgdHJhY2sgb2Ygd2hlcmUgaXRzIGNsaWVu dCB0cmFmZmljIHJvdXRpbmdzIGhhdmUNCm1vdmVkIHRvLiAgRm9yIGV4YW1wbGUsIGlmIEkgY3Jl YXRlIHRoZSB0b3BvbG9neSBvZiBhbiBJUCBsYXllciBuZXR3b3JrDQp3aXRoIGxpbmtzIHByb3Zp ZGVkIGJ5IFNESCwgRXRoZXJuZXQsIEFUTSwgT1ROLCBldGMgc2VydmVycywgYW5kIGVhY2ggb2YN CnRoZXNlIHNlcnZlciBsaW5rcyBpcyBwcm92aWRlZCBieSBhIGRpZmZlcmVudCBvcGVyYXRvciwg dGhlbiB3aHkgc2hvdWxkDQp0aGUgc2VydmVycyBuZWVkIGhhdmUga25vd2xlZGdlIG9mIHdoZXJl IHRoZSBJUCBmbG93cyBoYXZlIG1vdmVkIHRvIGluDQpyZXNwb25zZSB0byBhIHNlcnZlciBsYXll ciBmYWlsdXJlIHdoZW4gdGhlIG5ldyByb3V0ZXMgaGF2ZSBiZWVuDQpjYWxjdWxhdGVkIGJ5IHRo ZSBJR1AgaW4gdGhlIElQIGxheWVyIG5ldHdvcms/ICBJIGNhbiBhcHBseSB0aGUgc2FtZQ0KbG9n aWMgdG8gYW4gU1ZDLWJhc2VkIGNvLXBzL2NvLWNzIG1vZGUgY2xpZW50Li4uLmluZGVlZCB0aGUg Y28tY3MgbW9kZQ0KUFNUTiBpcyBsaWtlIHRoaXMuDQoNClRoZXNlIG9ic2VydmF0aW9ucyBtYWtl IGl0IHF1aXRlIGNsZWFyIHRvIG1lIGF0IGxlYXN0IHRoYXQganVzdCBjb3B5aW5nDQp0aGUgQUlT IGJlaGF2aW91ciBvZiB0aGUgb2xkIHRyYW5zcG9ydCBoaWVyYXJjaGllcyB0aGF0IGhhZCBmaXhl ZA0KY2xpZW50L3NlcnZlciByZWxhdGlvbnNoaXBzIGlzIG5vdCBhIHNlbnNpYmxlIHRoaW5nIHRv IGRvLg0KDQpJTU8gdGhlIG9ubHkgZXNzZW50aWFsIERQIE9BTSByZXF1aXJlbWVudCBpcyB0aGF0 IGVhY2ggbGF5ZXIgbmV0d29yaw0Kc2hvdWxkIGJlIHNlbGYtc3VmZmljaWVudCB3cnQgT0FNIGFu ZCBub3QgcmVseSBvbiBhbnkgc2VydmVyIGxheWVyDQpwcmltaXRpdmVzIGJlaW5nIHBhc3NlZCB1 cHdhcmRzLg0KDQpNb3Jlb3ZlciwgaXQgc2hvdWxkIGFsc28gYmUgbm90ZWQgdGhhdCAoaSkgdGhl IGRlZmVjdHMgdGhhdCBjYW4gb2NjdXIgaW4NCmVhY2ggb2YgdGhlIDMgbmV0d29yayBtb2RlcyBh cmUgbm90IHRoZSBzYW1lIGFuZCAoaWkpIHRoZWlyIE9BTQ0KcmVxdWlyZW1lbnRzIGFyZSBub3Qg aWRlbnRpY2FsbHkgdGhlIHNhbWUuIFNvIHRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvDQp0aGUgY2wt cHMgbW9kZSAoZWcgSVApIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgT0FNIHRoYXQgYXBwbGllcyB0 byB0aGUNCmNvLXBzIG1vZGUgKGVnIE1QTFMtVFApIGFuZCBuZWl0aGVyIG9mIHRoZXNlIGlzIGlk ZW50aWNhbGx5IHRoZSBzYW1lIGFzDQp0aGUgT0FNIHRoYXQgYXBwbGllcyB0byB0aGUgY28tY3Mg bW9kZSAoZWcgU0RIKS4NCg0KTm90ZSAtIFRoZSBvbmx5IHBvaW50IGJlaW5nIGNvbnNpZGVyZWQg aGVyZSBpcyB0aGUgcmVhbCBjbGllbnQgYW5kDQpzZXJ2ZXIgdHJhZmZpYyByZWxhdGlvbnNoaXAu ICBUaGUgY3JlYXRpb24gb2YgYSBoaWVyYXJjaHkgb2YgVENNDQpzdWJsYXllcnMgaXMgYSBzZXBh cmF0ZSB0b3BpYy4gIEZ1cnRoZXIsIGl0IGlzIHF1aXRlIGNsZWFyIGZyb20gYSBzaW1wbGUNCnRl Y2huaWNhbCBhbmFseXNpcyB0aGF0IGFueSBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5v IG5lZWQgZm9yDQpFLU5OSSBwZWVyLXBhcnRpdGlvbiB3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50 IG9wZXJhdGluZyBwYXJ0aWVzLiAgU28NCnRoaXMgaXMgYWxzbyBhIHNlcGFyYXRlIGlzc3VlLiAg SG93ZXZlciwgSSBwcm9wb3NlIHRoYXQgdGhpcyBsYXR0ZXINCnBvaW50IGJlIGNhcHR1cmVkIGlu IHRoZSBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdCBkdWUgdG8gaXRzDQpzdGFuZC1hbG9uZSBh bmQgZ2VuZXJpYyBpbXBvcnRhbmNlLCBpZSB0aGlzIGFwcGxpZXMgdG8gbW9yZSB0aGFuIGp1c3Qg RFANCk9BTS4gIEJlbiBjYW4geW91IHBsZWFzZSBjb25zaWRlciB0aGlzIHBvaW50IGFzL3doZW4g dGhlIE1QTFMtVFANCnJlcXVpcmVtZW50cyBkcmFmdCBpcyB1cGRhdGVkLg0KDQpyZWdhcmRzLCBO ZWlsDQoNCj4gQ2hlZXJzLCBIdXViLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gDQpvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gDQpzeXN0ZW0uDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0K Y29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFp bnRhaW4gc2VjcmVjeSBhbmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5k aXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3Ro ZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000B290C482575A8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE5laWwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIEkgbWlzdW5kZXJz dG9vZCB0aGUgd29yZHMgoa50b3Atb2Ytc3RhY2sNCm5ldHdvcmuhryAsIEl0IGRvZXNuoa90IG1l YW4gYSBuZXR3b3JrIGlzIGFjdHVhbGx5IGF0IHRvcCBvZiB0aGUgc3RhY2ssDQpzbyBubyBtYXR0 ZXIgd2hhdCBsYXllciBJUCBuZXR3b3JrIGlzIGFjdHVhbGx5IGF0LCBJUCBuZXR3b3JrIGlzIGFs d2F5cw0KYSChrnRvcC1vZi1zdGFjayBuZXR3b3Jroa8gYmVjYXVzZSBpdCBjYW4goa5zdXBwb3J0 IGV4dGVybmFsIG1lc3NhZ2UvZmlsZS9zdHJlYW0NCmFwcGxpY2F0aW9uc6GvLiBJcyBteSB1bmRl cnN0YW5kaW5nIHJpZ2h0PzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+QnV0IEkgc3RpbGwgY2Fubm90IGFncmVlIHRoZSBhc3NlcnRpb24NCnRoYXQgoa5h bnkgbm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIGhhcyBubyBuZWVkIGZvciBFLU5OSSBwZWVyLXBh cnRpdGlvbg0Kd29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBvcGVyYXRpbmcgcGFydGllc6GvLiBB cyB5b3Ugc2FpZCBTREggaXMgbm90DQphIHRvcC1vZi1zdGFjayBuZXR3b3JrLCBidXQgVkM0IGNv bm5lY3Rpb25zIGNhbiBwYXNzIHRocm91Z2ggbXVsdGkgb3BlcmF0b3Khr3MNCmRvbWFpbnMsIHNv IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBkaWZmZXJlbnQgZG9tYWlucyBpcyBFLU5OSS4gPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U3VodWkuPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZsdDtuZWls LjIuaGFycmlzb25AYnQuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDA5LTA0LTI5IDE4OjIxPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtzdS5odWlAenRlLmNvbS5jbiZndDs8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPiZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgJmx0O2Jlbmph bWluLm5pdmVuLWplbmtpbnNAYnQuY29tJmd0OywNCiZsdDtoaGVsdm9vcnRAY2hlbGxvLm5sJmd0 OywgJmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7LCAmbHQ7bXBscy10cC1ib3VuY2VzQGlldGYub3Jn Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFJFOiBSZTogW21wbHMtdHBdIEFJUy9GREkgKHdh cyBBc3NvY2lhdGVkDQpiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3JlcXVpcmVtZW50cyk8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1T Ij5UaGFua3MgU3VodWkuLi4uLi5zb3JyeQ0KSSBtaXNzZWQgeW91ciBzcGVjaWZpYyBxdWVzdGlv bi4uLi5oYXZlIGEgbG9vayBpbi1saW5lIGFuZCBzZWUgaWYgdGhpcw0KaGVscHMuPC9mb250Pg0K PGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBz dS5odWlAenRlLmNvbS5jbiBbbWFpbHRvOnN1Lmh1aUB6dGUuY29tLmNuXQ0KPGI+PGJyPg0KU2Vu dDo8L2I+IDI5IEFwcmlsIDIwMDkgMTA6MzE8Yj48YnI+DQpUbzo8L2I+IEhhcnJpc29uLE4sTmVp bCxDWE0gUjxiPjxicj4NCkNjOjwvYj4gYWRyaWFuQG9sZGRvZy5jby51azsgTml2ZW4tamVua2lu cyxCLEJlbixETUYgUjsgaGhlbHZvb3J0QGNoZWxsby5ubDsNCm1wbHMtdHBAaWV0Zi5vcmc7IG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiC08Li0OiBSRTogUmU6 IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQp0cmFuc3Bv cnQgcGF0aCByZXF1aXJlbWVudHMpPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIE5laWyjrDwvZm9udD48 Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KVGhhbmtzIGZvciB5b3VyIHJhcGlkIHJlcGx5LjwvZm9udD48Zm9udCBzaXplPTM+IDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSSBhbSBjb25mdXNlZCBi eSB5b3VyIGNvbW1lbnRzLCBhcmUgeW91IHN1Z2dlc3RpbmcgRXZlcnl0aGluZ292ZXJJUG92ZXJN UExTLVRQPw0KQUZBSUssIE1QTFMtVFAgY2FuIGNhcnJ5IG1hbnkga2luZHMgb2YgY2xpZW50cywg bm90IGp1c3QgSVAuSW4gbXkgZXhhbXBsZSwNCkUxb3ZlclBXb3Zlck1QTFMtVFAsIHRoZXJlIGlz IG5vIElQIGxheWVyIGF0IGFsbC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwOyA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBN UyI+Tkg9Jmd0OyBGdWxseSB1bmRlcnN0YW5kLg0KJm5ic3A7SSB3YXMgZ2l2aW5nIElQIGFzIGFu ICpleGFtcGxlKiBvZiBhIHRlY2hub2xvZ3kgdGhhdCBjYW4gc3VwcG9ydA0KcmVhbCBleHRlcm5h bCBhcHBsaWNhdGlvbnMgYmVjYXVzZSBpdCBoYXMgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNh dGlvbg0KYWRhcHRhdGlvbiBmdW5jdGlvbnMgaW4gdGhlIGZvcm0gb2YgVURQL1RDUC9SVFAuICZu YnNwOyBJbiB0aGUgY2FzZSBvZg0KRTEgdGhhdCB5b3Ugbm90ZSAoYXMgRTFvdmVyUFdvdmVyTVBM Uy1UUCkgeW91IGhhdmUgdG8gYXNrIHlvdXJzZWxmIHdoYXQNCnNwZWNpZmljICpleHRlcm5hbCog YXBwbGljYXRpb25zIGRvZXMgdGhlIEUxIHN1cHBvcnQgaGVyZT8uLi4uLmFsd2F5cyByZW1lbWJl cmluZw0KdGhhdCAqYW55KiBuZXR3b3JraW5nIHRlY2hub2xvZ3kgTVVTVCB1bHRpbWF0ZWx5IHN1 cHBvcnQgc29tZSBmb3JtIG9mICpleHRlcm5hbGx5DQpzb3VyY2VkKiBpbmZvcm1hdGlvbiBzb3Vy Y2UgZWxzZSBpdCBpcyBub3Qgc2VydmluZyBhbnkgcHVycG9zZS4gJm5ic3A7U28NCmp1c3Qgc3Vw cG9ydGluZyBFMSBvbiBpdHMgb3duIGRvZXMgbm90IHByb3ZpZGUgdGhpcy4uLi5mb3IgZXhhbXBs ZSBhc2sNCnlvdXJzZWxmIGhvdyB2b2ljZSBvciBhbnkgdHlwZSBvZiBtZXNzYWdlL2ZpbGUgZGF0 YSBnZXRzIGNhcnJpZWQgYnkgdGhlDQpFMS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQW5kIHlvdSBkb26h r3QgYW5zd2VyIG15IHF1ZXN0aW9uOiBJUCBpcyBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGluIHRo ZQ0KY2FzZSBvZiBFMW92ZXJQV292ZXJJUCwgd2h5IGRvZXNuJ3QgTVBMUy1UUCBiZSBhIHRvcC1v Zi1zdGFjayBuZXR3b3JrIGluDQp0aGUgY2FzZSBvZiBFMW92ZXJQV292ZXJNUExTLVRQPyBUaGV5 IGFyZSBhdCB0aGUgc2FtZSBwb3NpdGlvbiBpbiB0aGUgc3RhY2ssDQphbmQgSSB0aGluayBFMSBp cyChrnJlYWwgZXh0ZXJuYWwgc3RyZWFtIGFwcGxpY2F0aW9uc6GvPC9mb250Pjxmb250IHNpemU9 MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPg0KPC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFj ZT0iQ29taWMgU2FucyBNUyI+Tkg9Jmd0OyBUaGUgcG9pbnQgaGVyZQ0KaXMgdGhhdCAqYW55KiBu ZXR3b3JrIG1vZGUvdGVjaG5vbG9neSAoYmUgaXQgY2wtcHMsIGNvLXBzIG9yIGNvLWNzKSBjYW4N CmFjdCBhcyB0aGUgc2VydmVyIGZvciBhbnkgb3RoZXIgbW9kZS90ZWNobm9sb2d5LiAmbmJzcDtI b3dldmVyLCBub3QgYWxsDQp0ZWNobm9sb2dpZXMgY2FuIHN1cHBvcnQgZXh0ZXJuYWwgYXBwbGlj YXRpb25zLi4uLi50byBzdXBwb3J0IHRoZXNlIHRoZQ0KdGVjaG5vbG9neSBtdXN0IGhhdmUgYXBw bGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMgZm9yIHRoZSBtZXNzYWdlL2ZpbGUvc3RyZWFt DQppbmZvcm1hdGlvbiBzb3VyY2VzIHRoYXQgYXJlIGdlbmVyYXRlZCBpbiBleHRlcm5hbCBDUEUs IGVnIHBob25lLCBQQywgZXRjLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPk1v c3QgdGVjaG5vbG9naWVzIGRvDQpub3QgaGF2ZSB0aGVzZSBleHRlcm5hbCBhcHBsaWNhdGlvbiBh ZGFwdGF0aW9uIGZ1bmN0aW9ucyBhbmQgc28gdGhlIG9ubHkNCmpvYiB0aGV5IGNhbiBkbyBpcyBj cmVhdGUgdGhlIHRvcG9sb2d5IG9mIG90aGVyIGxheWVyIG5ldHdvcmtzLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+ U28geWVzIHdlIGNhbiB1c2UgSVANCihjbC1wcykgdG8gY2FycnkgU0RIIFZDNCAoY28tY3MpIGlm IHdlIHdhbnQuLi4uLi4ucHJvYmFibHkgbm90IGEgZ29vZCBpZGVhDQpidXQgaXQgaXMgZm9yIHN1 cmUgcG9zc2libGUuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xv cj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwO0hvd2V2ZXIsDQphbiBTREggVkM0 IG5ldHdvcmsgY2Fubm90ICpkaXJlY3RseSogc3VwcG9ydCBlaXRoZXIgdm9pY2Ugb3IgZGF0YSBi dXQgYW4NCklQIG5ldHdvcmsgY2FuLi4uLi5iZWNhdXNlIElQIGhhcyBVRFAvVENQL1JUUCBhcHBs aWNhdGlvbnMgYWRhcHRhdGlvbnMNCmFuZCBTREggVkM0IGRvZXMgbm90IGhhdmUgdGhlc2UuICZu YnNwO0hhdmluZyBzYWlkIHRoYXQsIHRoZXJlIGlzIGluIHByaW5jaXBsZQ0Kbm8gcmVhc29uIHdo eSBhbnkgbW9kZS90ZWNobm9sb2d5IChldmVuIFNESCBWQzQpIGNhbm5vdCBzdXBwb3J0IGV4dGVy bmFsDQptZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucy4uLi4uLml0cyBqdXN0IHRoYXQg Zm9yIG1vc3QgdGVjaG5vbG9naWVzDQp0aGVzZSBoYXZlIG5ldmVyIGJlZW4gc3BlY2lmaWVkIGJl Y2F1c2UgdGhleSB3ZXJlIG9ubHkgZXZlciBpbnRlbmRlZCB0bw0KcHJvdmlkZSBhICduZXR3b3Jr IGJ1aWxkZXInIHRyYW5zcG9ydCByb2xlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMg TVMiPkFzaWRlPSZndDsgSWYgYSB0ZWNobm9sb2d5DQpYIGNhbiBzdXBwb3J0IG1lc3NhZ2UvZmls ZS9zdHJlYW0gYXBwbGljYXRpb25zIGRpcmVjdGx5IHRoZW4gaGVyZSB3ZSB3b3VsZA0KbW9zdCBk ZWZpbml0ZWx5IGhhdmUgdG8gY29uc2lkZXIgcGVlci1pbnRlcndvcmtpbmcgdGVjaG5vbG9neSBY IHdpdGggYm90aA0KSVAgKEludGVybmV0KSBhbmQgUFNUTiAodm9pY2UgY2FzZSBvbmx5KS4gJm5i c3A7SW4gYWxsIG90aGVyIGNhc2VzIChpZQ0Kd2hlcmUgdGVjaG5vbG9neSBYIGlzIG5vdCB0b3At b2Ytc3RhY2ssIGllIGRvZXMgbm90IGhhdmUgbWVzc2FnZS9maWxlL3N0cmVhbQ0KYXBwbGljYXRp b24gYWRhcHRhdGlvbiBmdW5jdGlvbnMpIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHBlZXItaW50ZXJ3 b3JraW5nDQppdCB3aXRoIGFueSBvdGhlciB0ZWNobm9sb2d5LCBpbmNsdWRpbmcgSVAgKEludGVy bmV0KSBhbmQgUFNUTi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAw MDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPllvdXIgZmluYWwgcG9pbnQgKCZxdW90OzwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkkNCnRoaW5rIEUxIGlzIKGucmVhbCBleHRlcm5hbCBz dHJlYW0gYXBwbGljYXRpb25zoa8mcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAw MDAgZmFjZT0iQ29taWMgU2FucyBNUyI+DQopIGlzIG5vdCBzdHJpY3RseSBjb3JyZWN0IGJ1dCBJ IGNhbiBmdWxseSB1bmRlcnN0YW5kIHdoeSB5b3Ugc2F5IHRoaXMuDQombmJzcDtFMSBiZWxvbmdz IHRvIHRoZSBjby1jcyBtb2RlLiAmbmJzcDtXaGVuIHlvdSBhbmFseXNlIHRoaXMgKGFzIGlzDQpk b25lIGluIEcuODAwLCB3aGljaCBleHBsYWlucyB3aHkgdGhlIDMgbmV0d29yayBtb2RlcyBhcmlz ZSBmcm9tIGluZm9ybWF0aW9uL3N5c3RlbXMNCnRoZW9yeSBjb25zaWRlcmF0aW9ucykgeW91IGZp bmQgdGhhdCBpbiB0aGUgdGltZSBkaW1lbnNpb24gdGhlIGNvLWNzIG1vZGUNCnBhcnRpdGlvbnMg cmVzb3VyY2UgKHRpbWUpIHVwIGludG8gcmVndWxhciB0aW1lIHNsaWNlcy4uLi5zbyB0aGlzIG1l YW5zDQpib3RoIHRoZSBzdGFydCBlcG9jaCAoYW4gaW1wbGljaXQgbGFiZWwpIGFuZCAobW9zdCBj cnVjaWFsbHkpIGl0cyBkdXJhdGlvbg0KYXJlIGZpeGVkLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBm YWNlPSJDb21pYyBTYW5zIE1TIj5XaXRob3V0IGdvaW5nIGludG8NCm1ham9yIGRldGFpbCBoZXJl IChJIGhhdmUgcGFwZXIgb24gdGhpcyBJIGNhbiBzZW5kIHlvdSBpZiB5b3Ugd2FudC4uLmp1c3QN CmFzaykgd2hhdCB0aGlzIG1lYW5zIGlzIHRoYXQgdGhlIGNvLWNzIG1vZGUgaXMgdGhlIHVsdGlt YXRlICdzbW9vdGhlci9zaGFwZXInDQpmb3IgY2xpZW50IHRyYWZmaWMuLi4uLi5zbyBhcyB5b3Ug cmlnaHRseSBvYnNlcnZlIHRoaXMgbG9va3MgbGlrZSBhIHN0cmVhbQ0KY2FzZS4gJm5ic3A7SXQn cyBub3QgYSBzcGVjaWZpYyBleHRlcm5hbCBhcHBsaWNhdGlvbiBob3dldmVyIGxpa2UgaHVtYW4N CnZvaWNlIG9yIHZpZGVvICh0aGVzZSBtdXN0IGdlbmVyYXRlIHJlYWwgKmluZm9ybWF0aW9uKiB0 aGF0IGNvbW11bmljYXRpbmcNCnBhcnRpZXMgdW5kZXJzdGFuZCkgYnV0IGl0IGZvciBzdXJlIGhh cyB0aGUgQ0JSIGJlaGF2aW91ciBvZiBhIHN0cmVhbS4NCjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNv bWljIFNhbnMgTVMiPkJUVyB0aGUgcmVhc29uIHRoZQ0KY28tY3MgbW9kZSBoYXMgYmVlbiBlbmR1 cmluZ2x5IHN1Y2Nlc3NmdWwgYXMgYSB0cmFuc3BvcnQgbmV0d29yayBpcyBiZWNhdXNlDQppdCBw cm92aWRlcyAqdHJhbnNwYXJlbmN5KiB0byBhbGwgY2xpZW50cyAod2hpY2ggaXMgZXhhY3RseSB0 aGUgc2ltaWxhcg0KYmVoYXZpb3VyIG9mIGEgc3RyZWFtIGFzIHlvdSBub3RlKSwgaWU8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+LSAm bmJzcDsgJm5ic3A7YWxsDQpjbGllbnQgYml0cyB0cmVhdGVkIGVxdWFsbHkgKGEgcmVhbGx5IGtl eSBwb2ludCB0aGlzLCBhcyB0aGlzIG1lYW5zIGl0DQpwcm92aWRlcyBlcXVhbCAnaW1wb3J0YW5j ZScgdHJlYXRtZW50IG9mIHRoZSB1bHRpbWF0ZSBoaWdoZXIgbGV2ZWwgKGFuZA0KdW5zZWVuL3Vu a25vd24gYnkgdGhlIGNvLWNzIHRyYW5zcG9ydCBuZXR3b3JrKSBtZXNzYWdlL2ZpbGUvc3RyZWFt IGFwcGxpY2F0aW9ucyk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFj ZT0iQ29taWMgU2FucyBNUyI+LSAmbmJzcDsgJm5ic3A7Y2xpZW50DQpiaXQgb3JkZXJpbmcgaXMg cHJlc2VydmVkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNv bWljIFNhbnMgTVMiPi0gJm5ic3A7ICZuYnNwO2RvZXMNCm5vdCB0cnkgYW4gaW5mZXIgbWVhbmlu ZyBvZiBjbGllbnQgYml0cyBub3IgY2hhbmdlIHRoZW08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+LSAmbmJzcDsgJm5ic3A7ZW5zdXJl cw0KdGhlIHRyYWZmaWMgYmVoYXZpb3VyIG9mIGNsaWVudCBYIGNhbm5vdCBpbXBhY3QgdGhlIHBl cmZvcm1hbmNlIGV4cGVyaWVuY2VkDQpieSBwYXJ0eSBZLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNv bWljIFNhbnMgTVMiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAw MCBmYWNlPSJDb21pYyBTYW5zIE1TIj5yZWdhcmRzLCBOZWlsPC9mb250Pjxmb250IHNpemU9Mz4N Cjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KUmVnYXJk cyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NClN1aHVpLjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjxicj4NCjwvZm9udD4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTglPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mbHQ7bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZn dDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0w NC0yOSAxNDo0MDwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9ODElPg0K PGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01JT4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05NCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZsdDtzdS5odWlAenRlLmNvbS5jbiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDssICZsdDtiZW5qYW1pbi5uaXZl bi1qZW5raW5zQGJ0LmNvbSZndDssDQombHQ7aGhlbHZvb3J0QGNoZWxsby5ubCZndDssICZsdDtt cGxzLXRwQGlldGYub3JnJmd0OywgJmx0O21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyZndDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogUmU6IFttcGxzLXRwXSBB SVMvRkRJICh3YXMgQXNzb2NpYXRlZA0KYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZXF1aXJlbWVudHMpPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUw JT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9 Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29t aWMgU2FucyBNUyI+PGJyPg0KVGhhbmtzIFNodWh1aSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+ DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNh bnMgTVMiPjxicj4NCkRvIG5vdCBjb25mdXNlIHBoeXNpY2FsIGludGVyY29ubmVjdCB3aXRoIEUt Tk5JLi4uLi5JJ2xsIGNvbWUgYmFjayBvbiB0aGlzDQpzaG9ydGx5IHdoZW4gZGlzY3Vzc2luZyB0 aGUgYm90dG9tLW9mLXN0YWNrIHNlY3Rpb24gbGF5ZXIuPC9mb250Pjxmb250IHNpemU9Mz4NCjxi cj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMg U2FucyBNUyI+PGJyPg0KVGhlIGZpcnN0IHRoaW5nIHRvIHVuZGVyc3RhbmQgaXMgdGhhdCAqYWxs KiBuZXR3b3JrcyBhcmUgdGhlcmUgdG8gdWx0aW1hdGVseQ0Kc3VwcG9ydCBvbmUgcHVycG9zZS4u Li4uYW5kIHRoYXQgaXMgdG8gYWxsb3cgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBwYXJ0aWVzDQp0 aGF0IGFyZSAqZXh0ZXJuYWwqIHRvIHRoZSBuZXR3b3Jrcy4gJm5ic3A7U28gZXZlcnl0aGluZyB3 ZSBkbyBpbiBuZXR3b3JraW5nDQppcyB0aGVyZSB0byB1bHRpbWF0ZWx5IHN1cHBvcnQgdGhpcyBv YmplY3RpdmUuICZuYnNwO1doYXQgdGhpcyBtZWFucyBpcw0KdGhhdCB0aGUgRFAgb2Ygc29tZSBu ZXR3b3JrICh3aGF0IEkgY2FsbCB0aGUgdG9wLW9mLXN0YWNrIG5ldHdvcmspIE1VU1QNCmJlIHBy b3ZpZGluZyBhZGFwdGF0aW9uIGZ1bmN0aW9ucyBmb3IgdGhlc2UgZXh0ZXJuYWwgYXBwbGljYXRp b25zLi4uLi4uLmFuZA0KdGhlc2UgY2FuIGdlbmVyaWNhbGx5IGJlIGNsYXNzaWZpZWQgYXMgbWVz c2FnZXMsIGZpbGVzIGFuZCBzdHJlYW1zLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCiAmbmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+ PGJyPg0KV2UgY2FuIHNlZSB0aGF0IElQIGlzIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgYXMgaXQg aGFzIFVEUC9UQ1AvUlRQIChmb3INCmV4YW1wbGUpIGFkYXB0YXRpb25zLiAmbmJzcDtBVE0gd2Fz IGFsc28gb25jZSAofjkwcykgaW50ZW5kZWQgdG8gYmUgYSB0b3Atb2Ytc3RhY2sNCm5ldHdvcmsg YW5kIGl0IGhhZCBpdHMgb3duIGFwcGxpY2F0aW9uIGFkYXB0YXRpb25zIGluIHRoZSBmb3JtIG9m IEFBTHMuDQombmJzcDtBdCBvbmUgc3RhZ2UgdGhlcmUgd2VyZSA1IG9mIHRoZXNlLCBidXQgaW4g cHJhY3RpY2Ugb25seSBhIGNvdXBsZQ0Kd2VyZSByZWFsbHkgc3VjY2Vzc2Z1bCBiZWNhdXNlIG9m IHRoZSBnZW5lcmljIG5hdHVyZSBvZiBtZXNzYWdlL2ZpbGUvc3RyZWFtDQpjbGFzc2lmaWNhdGlv bi4gJm5ic3A7VGhlIFBTVE4gaXMgYWxzbyB0b3Atb2Ytc3RhY2ssIGFuZCBpdHMgYXBwbGljYXRp b24NCmFkYXB0YXRpb24gd2FzIG1haW5seSBmb3Igdm9pY2UgKHN0cmVhbSkgc3VwcG9ydC48L2Zv bnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j ODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxicj4NCk1vc3Qgb3RoZXIgbmV0d29ya3MgZG8g bm90IGhhdmUgdGhlc2UgYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMuLi4uc28NCnRo ZXkgZG8gbm90IGRpcmVjdGx5IHN1cHBvcnQgYXBwbGljYXRpb25zLiAmbmJzcDtXaGF0IHRoaXMg bWVhbnMgaW4gcHJhY3RpY2UNCmlzIHRoYXQgdGhlc2UgbmV0d29ya3MgKGEgbGlzdCB3aGljaCBp bmNsdWRlcyBQREgsIFNESCwgT1ROLCBFdGhlcm5ldCwNCk1QTFMpIE1VU1QgY2FycnkgYSBmdXJ0 aGVyIGxheWVyIG5ldHdvcmsgYWJvdmUgdGhlbSB0aGF0IGlzIHRvcC1vZi1zdGFjay4uLi5saWtl DQpJUC4gJm5ic3A7VGhlcmUgaXMgbm8gY2hvaWNlIGluIHRoZSBtYXR0ZXIgaGVyZS4gJm5ic3A7 U28gd2hpbHN0IHdlIG1pZ2h0DQpzYXkgdGhhdCBhbiBNUExTIG5ldHdvcmsgaXMgY2Fycnlpbmcg YW4gRTEgUFcgdGhlIEUxIGVudGl0eSBtdXN0IGluIHR1cm4NCmJlIGNhcnJ5aW5nIHNvbWUgb3Ro ZXIgdG9wLW9mLXN0YWNrIG5ldHdvcmsgKGxpa2UgSVAgb3IgUFNUTiksIGVsc2UgaXQNCmlzIHNl cnZpbmcgbm8gdWx0aW1hdGUgcHVycG9zZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQogJm5i c3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxicj4NCk5vdyBpbiBvcmRlciB0byB0cmFuc21pdCBpbmZvcm1hdGlvbiBvdmVyIGdlb2dyYXBo aWMgZGlzdGFuY2Ugd2UgbXVzdCBtb2R1bGF0ZQ0KYW4gRU0gd2F2ZSBvbiBzb21lIG1ldGFsbGlj L29wdGljYWwvcmFkaW8gbWVkaWEuLi4udGhpcyBpcyB0aGUgYm90dG9tLW9mLXN0YWNrDQpzZWN0 aW9uIGxheWVyLiAmbmJzcDtUaGVzZSBhcmUgaGlnaCBiaXQgcmF0ZSB0cmFuc3BvcnQgcGlwZXMg d2hvc2UgZnVuY3Rpb24NCmlzIHRvIHByb3ZpZGUgdHJhbnNwYXJlbnQgKHdoaWNoIEkgaGF2ZSBk ZWZpbmVkIHByZXZpb3VzbHkpIHRyYW5zcG9ydCB0bw0Kd2hhdGV2ZXIgY2xpZW50IGxheWVycyBu ZXR3b3JrcyBzaXQgYWJvdmUgdGhlbS4uLi5hbmQgd2hlcmUsIGFzIEkgbm90ZWQNCmFib3ZlLCB0 aGVyZSBNVVNUIGJlIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgcHJlc2VudCBhcyB0aGUgdWx0aW1h dGUgbGF5ZXINCm5ldHdvcmsgY2xpZW50IGVsc2UgdGhlcmUgaXMgbm90IGV4dGVybmFsIHBhcnR5 IGNvbW11bmljYXRpb24gcG9zc2libGUuPC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCiAmbmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+ PGJyPg0KU28gd2hlbiB3ZSBjb25uZWN0IHRvZ2V0aGVyIDIgdG9wLW9mLXN0YWNrIG5ldHdvcmtz IHdlIGRvIHNvIGF0IGEgc2VjdGlvbg0KbGF5ZXIgd2hpY2ggaXMgaW52YXJpYWJseSBjYXJyeWlu ZyBhIHZlcnkgbGFyZ2UgYWdncmVnYXRlIG9mIGFwcGxpY2F0aW9ucy4uLi4uYW5kDQpvZiBjb3Vy c2UgdGhlc2UgYXBwbGljYXRpb25zIGNhbiBiZSBhIHRpbWUgdmFyeWluZyBtaXggb2YgbWVzc2Fn ZS9maWxlL3N0cmVhbQ0KY2FzZXMgd2l0aCBhIHNldCBvZiB1bmtub3duICh0byB0aGUgc2VjdGlv biBsYXllcikgaW1wb3J0YW5jZSdzIChlcmdvIHdoeQ0KdHJhbnNwYXJlbmN5IGlzIGFuIGVzc2Vu dGlhbCByZXF1aXJlbWVudCBpbiB0cmFuc3BvcnQgbmV0d29ya3MpLjwvZm9udD48Zm9udCBzaXpl PTM+DQo8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9 IkNvbWljIFNhbnMgTVMiPjxicj4NClRoZSByZWFsIEUtTk5JcyAod2hpY2ggY29uc2lkZXJzIGJv dGggRFAgYW5kIENQIGNvbXBvbmVudHMuLi4ud2UgbmV2ZXINCnVzdWFsbHkgcGVlciB0aGUgTVAs IGFuZCB3ZSByZXN0cmljdCB0aGUgc2NvcGUgb2YgdGhlIENQKSBleGlzdCBpbiB0aGUNCnRvcC1v Zi1zdGFjayBsYXllciBuZXR3b3JrLiAmbmJzcDtUaGUgc2VjdGlvbiBsYXllciBpbnRlcmNvbm5l Y3QgaXMgYSBkdW1iDQpEUCBwaXBlLi4uaXQganVzdCBzaGlmdHMgYml0cyB0cmFuc3BhcmVudGx5 IGFuZCBtYWludGFpbnMgdGhlaXIgb3JkZXJpbmcuDQombmJzcDtUaGVyZSBpcyBubyBjb25jZXB0 IG9mIENQIChvciBNUCkgcGVlcmluZyBvbiB0aGVzZSBib3R0b20tb2Ytc3RhY2sNCnNlY3Rpb24g bGF5ZXIgaW50ZXJjb25uZWN0cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29taWMgU2FucyBNUyI+PGJyPg0KQXNpZGU9Jmd0OyBJ biBzb21lIGNvdW50cmllcyB0aGVzZSBpbnRlcmNvbm5lY3RzIGhhdmUgdG8gYmUgY2FyZWZ1bGx5 IHNwZWNpZmllZA0KaW4gb3JkZXIgdG8gZGlzdGluZ3Vpc2ggcmVndWxhdGVkIGFuZCB1bnJlZ3Vs YXRlZCBzZXJ2aWNlcy4uLi4uc28gdGhlcmUNCmFyZSBpbXBvcnRhbnQgbGVnYWwvY29tbWVyY2lh bCBjb25zaWRlcmF0aW9ucyBoZXJlLCBpdCBpcyBub3Qgc2ltcGx5IGENCnRlY2huaWNhbCBpc3N1 ZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxicj4NCldlIGNhbiBvZiBjb3Vyc2Ug Y3JlYXRlIEUtTk5JcyBpbiBub24gdG9wLW9mLXN0YWNrIGxheWVyIG5ldHdvcmtzICh3ZSBjYW4N CmRvIG1hbnkgdGhpbmdzIHRoYXQgYXJlIG5vdCB1c2VmdWwpLiAmbmJzcDtTbyBsZXRzIGFzc3Vt ZSB3ZSBkbyB0aGlzLi4uLi5hbmQNCmxldHMgYXNzdW1lIHdlIGNob29zZSBNUExTIHNpbmNlIHlv dSBtZW50aW9uIHRoaXMgaW4gdGhlIG1haWwgYmVsb3cuIDwvZm9udD48Zm9udCBzaXplPTM+PGJy Pg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBT YW5zIE1TIj48YnI+DQpOb3cgaG93IGRvIGV4dGVybmFsIHBhcnRpZXMgd2hvIHdpc2ggdG8gY29t bXVuaWNhdGUgaW50ZXJmYWNlIHdpdGggdGhpcw0KTVBMUyBuZXR3b3JrPyAmbmJzcDtDYW4geW91 IHN1cHBvcnQgYWxsIHR5cGVzIG9mIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zDQoq ZGlyZWN0bHkqIGludG8gTVBMUz8gJm5ic3A7SW4gcHJpbmNpcGxlIHlvdSBjb3VsZCBpZiB5b3Ug YWxsb3dlZCBNUExTDQp0byBoYXZlIGVuZCBzeXN0ZW0gYXBwbGljYXRpb24gYWRhcHRhdGlvbnMg c3VjaCBhcyBVRFAvVENQL1JUUCBvciB0aGUgbGlrZS4NCiZuYnNwO0J1dCB0aGVzZSBkb24ndCBl eGlzdCB0b2RheSwgYW5kIGluIHRoZSBtb3N0IHVzdWFsIGNhc2UgdGhlIE1QTFMNCm5ldHdvcmsg d2lsbCBjYXJyeSBhbiBJUCBsYXllciBuZXR3b3JrIGJlY2F1c2UgdGhpcyBjYW4gc3VwcG9ydCB0 aGUgbWVzc2FnZS9maWxlL3N0cmVhbQ0KYXBwbGljYXRpb25zLjwvZm9udD48Zm9udCBzaXplPTM+ IDxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwMDAgZmFjZT0iQ29t aWMgU2FucyBNUyI+PGJyPg0KV2UgY2FuIGdvIHRocm91Z2ggZXhhY3RseSB0aGUgc2FtZSBhbmFs eXNpcyB3aXRoIGFueSBuZXR3b3JrIHRoYXQgaXMgbm90DQp0b3Atb2Ytc3RhY2ssIGVnIEV0aGVy bmV0LiAmbmJzcDtBbmQgd2hlbiB5b3UgZG8gdGhpcyB3aGF0IHlvdSByZWFsaXNlDQppcyB0aGF0 IGFsdGhvdWdoIHdlIGNhbiBjcmVhdGUgcGVlciBpbnRlcndvcmtpbmcgb2YgTVBMUyAob3Igd2hh dGV2ZXIpDQp0aGlzIGhhcyBub3QgcmVhbGx5IGhlbHBlZCBzaW5jZSB3ZSBtaWdodCBhcyB3ZWxs IGhhdmUganVzdCB0ZXJtaW5hdGVkDQp0aGUgTVBMUyBuZXR3b3JrIGFuZCBwYXNzZWQgdGhlIElQ IGxheWVyIGFjcm9zcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQogJm5ic3A7PC9mb250Pjxm b250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxicj4NCk5vdyB0 aGUgYWJvdmUgYmVjb21lcyBldmVuIG1vcmUgc3RyaWtpbmcgaW4gaXRzIGltcG9ydGFuY2UgaWYg eW91IGNvbnNpZGVyDQpwZWVyIGludGVyd29ya2luZyBvZiAyIGRpZmZlcmVudCBub24gdG9wLW9m LXN0YWNrIG5ldHdvcmtzLi4uLmxldHMgcGljaw0KTVBMUyBhbmQgRXRoZXJuZXQgYmVjYXVzZSB0 aGF0IGlzIHdoYXQgaXMgb2Z0ZW4gbWVudGlvbmVkLiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z Pg0KPGJyPg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJD b21pYyBTYW5zIE1TIj48YnI+DQpXaGF0IHdlIGhhdmUgdG8gZG8gbm93IGF0IHRoZSBFLU5OSXMg YmV0d2VlbiBFdGhlcm5ldCBhbmQgTVBMUyBpcyBnbyB0aHJvdWdoDQplYWNoIERQIGFuZCBDUCBj b21wb25lbnQgYW5kIGRvIGEgJ3Byb3RvY29sIGNvbnZlcnNpb24nIGV4ZXJjaXNlIHdoZXJlDQpy ZXF1aXJlZC4uLi4uLmFuZCB0aGUgZmlyc3QgcHJvYmxlbSB5b3Ugd2lsbCBlbmNvdW50ZXIgaXMg dGhhdCB0aGVyZSB3aWxsDQpiZSBsb3RzIG9mIGZ1bmN0aW9uYWwgbWlzbWF0Y2guICZuYnNwO01v cmVvdmVyIGlmIG9uZSBvciBib3RoIG9mIHRoZSBuZXR3b3Jrcw0KY2FuIHN1cHBvcnQgbXVsdGlw bGUgQ1AgdHlwZXMgbGlrZSBNUExTIGNhbiwgZWcgUlNWUC1URSBzaWduYWxsaW5nLCBMRFANCnNp Z25hbGxpbmcsIEJHUDQgJ3NpZ25hbGxpbmcnLCBPU1BGIHJvdXRpbmcsIElTLUlTIHJvdXRpbmcu Li4uLmFuZCBJIGNvdWxkDQpsaXN0IHNpbWlsYXIgZm9yIEV0aGVybmV0Li4uLi55b3UgYXJlIGdv aW5nIHRvIGhhdmUgdG8gY29uc2lkZXIgZWFjaCBwYWlyaW5nDQpjYXNlIGluIHR1cm4uICZuYnNw O0EgbG90IG9mIHdvcmsuPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KICZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj48YnI+DQpBbmQg d2hlbiB5b3UgaGF2ZSBkb25lIGFsbCB0aGlzIHlvdSBhc2sgdGhlIHF1ZXN0aW9uICd3aGF0IGlz IGl0IHRoYXQgY2Fycmllcw0KdGhlIHJlYWwgZXh0ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSBh cHBsaWNhdGlvbnMgaW4gdGhlIERQIGhlcmU/Jy4uLi4uLi5hbmQNCm5vdyB5b3UgZmluZCBubyBu YXRpdmUgc3VwcG9ydCBmb3IgdGhlc2UgaW4gTVBMUyBvciBFdGhlcm5ldCwgYnV0IHdoYXQNCndl IGRvIGZpbmQgaXMgdGhhdCBib3RoIG9mIHRoZW0gYXJlIGNhcnJ5aW5nIElQIGJlY2F1c2UgdGhp cyBkb2VzIHN1cHBvcnQNCnRoZSBleHRlcm5hbCBhcHBsaWNhdGlvbnMuICZuYnNwO05vdyBhdCB0 aGlzIHBvaW50IHdlIGhhdmUgZGlzY292ZXJlZCB3aGF0DQppcyB0aGUgY29tbW9uIHRoaW5nIGJl dHdlZW4gTVBMUyBhbmQgRXRoZXJuZXQuLi4uaXQgaXMgdGhlIHRvcC1vZi1zdGFjaw0KSVAgbGF5 ZXIgbmV0d29yay4gJm5ic3A7QW5kIHNvIHdlIHVsdGltYXRlbHkgcmVhbGlzZSB3ZSBjb3VsZCBo YXZlIHNhdmUNCm91cnNlbHZlcyBhIGxvYWQgb2YgdW5uZWNlc3Nhcnkgd29yayBieSBzaW1wbHkg dGVybWluYXRpbmcgdGhlIE1QTFMgYW5kDQpFdGhlcm5ldCBsYXllciBuZXR3b3JrIGF0IHRoZSBp bnRlcndvcmtpbmcgcG9pbnQgYW5kIGp1c3QgcGFzc2VkIHRoZSBJUA0KbGF5ZXIgbmV0d29yayBh Y3Jvc3MuPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KICZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb21pYyBTYW5zIE1TIj48YnI+DQpTb3JyeSBJJ3ZlIGhh ZCB0byBnbyB0aHJvdWdoIGFsbCB0aGlzIHlldCBhZ2FpbiAoZXNwIGZvciBhbGwgdGhlIGZvbGtz DQp0aGF0IGhhdmUgYWxyZWFkeSB1bmRlcnN0b29kIHRoZSBwb2ludCkgYnV0IEkgZG8gaG9wZSBp dHMgY2xlYXIgbm93IGFuZA0Kd2UgY2FuIHB1dCB0aGlzIGlzc3VlIHRvIGJlZC48L2ZvbnQ+PGZv bnQgc2l6ZT0zPiA8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAw IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxicj4NCnJlZ2FyZHMsIE5laWw8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ PGI+RnJvbTo8L2I+IHN1Lmh1aUB6dGUuY29tLmNuIFttYWlsdG86c3UuaHVpQHp0ZS5jb20uY25d DQo8Yj48YnI+DQpTZW50OjwvYj4gMjkgQXByaWwgMjAwOSAwMzoyMjxiPjxicj4NClRvOjwvYj4g SGFycmlzb24sTixOZWlsLENYTSBSPGI+PGJyPg0KQ2M6PC9iPiBhZHJpYW5Ab2xkZG9nLmNvLnVr OyBOaXZlbi1qZW5raW5zLEIsQmVuLERNRiBSOyBoaGVsdm9vcnRAY2hlbGxvLm5sOw0KbXBscy10 cEBpZXRmLm9yZzsgbXBscy10cC1ib3VuY2VzQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+ ILTwuLQ6IFJlOiBbbXBscy10cF0gQUlTL0ZESSAod2FzIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bA0KdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKTwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0K PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpIaSBOZWls LDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPGJyPg0Koa5pdCBpcyBxdWl0ZSBjbGVhciBmcm9tIGEgc2ltcGxlIHRlY2huaWNh bCBhbmFseXNpcyB0aGF0IGFueSBub24gdG9wLW9mLXN0YWNrDQpuZXR3b3JrIGhhcyBubyBuZWVk IGZvciBFLU5OSSBwZWVyLXBhcnRpdGlvbiB3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50DQpvcGVy YXRpbmcgcGFydGllcy6hrzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KSSBjYW5ub3QgYWdyZWUgdGhpcyBzdGF0ZW1l bnQuIDxicj4NCkZvciBleGFtcGxlLCB0aGVyZSBhcmUgdHdvIElQIG5ldHdvcmtzIGJlbG9uZ2lu ZyB0byB0d28gb3BlcmF0b3JzLCBhIEUxDQppcyB0cmFuc3BvcnRlZCBmcm9tIEEgbmV0d29yayB0 byBCIG5ldHdvcmsgKGUuZy4gRTFvdmVyUFdvdmVySVAgKSwgSVAgcGFja2V0KG5vdA0KRTEpIHBh c3MgYWNyb3NzIGZvcm0gQSB0byBCIGF0IGJvcmRlciBub2RlLCBzbyB0aGVyZSBpcyBhIEUtTk5J IGJldHdlZW4NCnRoZXNlICZuYnNwO3R3byBJUCBuZXR3b3JrLiBJbiB0aGlzIGNhc2UsIGlzIElQ IGEgdG9wLW9mLXN0YWNrIG5ldHdvcms/PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KTm93IGxldCB1cyByZXBsYWNlIElQIG5l dHdvcmtzIGJ5IE1QTFMtVFAgbmV0d29ya3MgKGUuZy4gRTFvdmVyUFdvdmVyTVBMLVRQKSwNCk1Q TFMtVFAgbmV0d29yayBpcyBhdCBzYW1lIHBvc2l0aW9uIGluIHRoZSBzdGFjayBhcyBJUCBuZXR3 b3JrIGlzLCB3aHkNCmNhbiBJUCBuZXR3b3JrIGhhdmUgRS1OTkkgYnV0IE1QTFMtVFAgY2Fubm90 PzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPGJyPg0KUmVnYXJkLDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU3VodWk8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8 YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmx0O25laWwuMi5oYXJy aXNvbkBidC5jb20mZ3Q7PC9iPg0KPGJyPg0Kt6K8/sjLOiAmbmJzcDttcGxzLXRwLWJvdW5jZXNA aWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0yOCAxNDo0MzwvZm9udD48Zm9udCBzaXplPTM+DQo8L2Zv bnQ+DQo8dGQgd2lkdGg9NzMlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD02JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MyU+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtoaGVsdm9vcnRAY2hlbGxvLm5sJmd0OywNCiZsdDth ZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgJmx0O2JlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29t Jmd0OzwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHMtdHBAaWV0 Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW21wbHMt dHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkDQpiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlcXVpcmVtZW50cyk8L2ZvbnQ+PC90YWJsZT4N Cjxicj48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250 IHNpemU9Mj48dHQ+PGJyPg0KPGJyPg0KSHV1YiB3cm90ZSAyNyBBcHJpbCAyMDA5IDIyOjI3PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEhpIEFkcmlhbiw8YnI+DQomZ3Q7IDxicj4NCiZndDsgWW91IHdy b3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IElzbid0IHRoZSBzb2x1dGlvbiBoZXJlIHRo ZSBzYW1lIGFzIHRoZSBvbmUgSSBwcm9wb3NlZCBmb3IgJnF1b3Q7VENNJnF1b3Q7Pzxicj4NCiZn dDsgPGJyPg0KJmd0OyBJbmRlZWQsIGFuZCB0aGF0IHdlIGRvIG5vdCBoYXZlIHRvIGFyb3VuZCBp biBjaXJjbGVzIGFib3V0IFRDTS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSG93IGFib3V0Ojxicj4N CiZndDsgdGhlIHJlcXVpcmVtZW50IGlzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXIgc2hhbGwgaW5mb3Jt IGl0cyBjbGllbnRzPGJyPg0KJmd0OyB0aGF0IGl0IGhhcyBkZXRlY3RlZCBhIHNlcnZpY2UgaW50 ZXJ1cHRpb24sIHRoaXMgdG8gZW5zdXJlIHRoYXQ8YnI+DQomZ3Q7IHRoZSBjbGllbnRzIGNhbiBp bmhpYml0ICh1bm5lY2Vzc2FyeSkgYWxhcm1zLjxicj4NCjxicj4NCk5IPSZndDsgVGhpcyBvbmx5 IGFwcGxpZXMgaWYgdGhlIGNsaWVudC9zZXJ2ZXIgYmluZGluZyBpcyBmaXhlZC4gJm5ic3A7QW5k DQpvZjxicj4NCmNvdXJzZSB3YXkgYmFjayBpbiB0aGUgNzBzIHdoZW4gYmluYXJ5IGFsbCAxcyBw b3BwZWQgb3V0IG9mIHRoZSBmYWlsZWQ8YnI+DQpUVEwgbG9naWMgaW50byB0aGUgUERIIHRyYW5z cG9ydCBoaWVyYXJjaHkgdGhpcyB3YXMgdHJ1ZS4gJm5ic3A7QWxzbzogbm88YnI+DQpsYWJlbHMg aGVyZSBhbmQgbm8gY2xpZW50IHRyYWZmaWMgdW5pdHMgdG8gY3JlYXRlLiAmbmJzcDsgPGJyPg0K PGJyPg0KV2hlcmUgdGhlIGNsaWVudCBjYW4gZHluYW1pY2FsbHkgYmUgcmUtcm91dGVkIGluIHJl c3BvbnNlIHRvIGEgc2VydmVyPGJyPg0KZmFpbHVyZSB0aGUgcHJvcG9zZWQgdGV4dCBpcyBub3Qg dmFsaWQuICZuYnNwO0l0IGlzIGFsc28gbm90IG5lY2Vzc2FyeQ0KdGhhdDxicj4NCnRoZSBzZXJ2 ZXIgaGFzIHRvIGtlZXAgdHJhY2sgb2Ygd2hlcmUgaXRzIGNsaWVudCB0cmFmZmljIHJvdXRpbmdz IGhhdmU8YnI+DQptb3ZlZCB0by4gJm5ic3A7Rm9yIGV4YW1wbGUsIGlmIEkgY3JlYXRlIHRoZSB0 b3BvbG9neSBvZiBhbiBJUCBsYXllciBuZXR3b3JrPGJyPg0Kd2l0aCBsaW5rcyBwcm92aWRlZCBi eSBTREgsIEV0aGVybmV0LCBBVE0sIE9UTiwgZXRjIHNlcnZlcnMsIGFuZCBlYWNoIG9mPGJyPg0K dGhlc2Ugc2VydmVyIGxpbmtzIGlzIHByb3ZpZGVkIGJ5IGEgZGlmZmVyZW50IG9wZXJhdG9yLCB0 aGVuIHdoeSBzaG91bGQ8YnI+DQp0aGUgc2VydmVycyBuZWVkIGhhdmUga25vd2xlZGdlIG9mIHdo ZXJlIHRoZSBJUCBmbG93cyBoYXZlIG1vdmVkIHRvIGluPGJyPg0KcmVzcG9uc2UgdG8gYSBzZXJ2 ZXIgbGF5ZXIgZmFpbHVyZSB3aGVuIHRoZSBuZXcgcm91dGVzIGhhdmUgYmVlbjxicj4NCmNhbGN1 bGF0ZWQgYnkgdGhlIElHUCBpbiB0aGUgSVAgbGF5ZXIgbmV0d29yaz8gJm5ic3A7SSBjYW4gYXBw bHkgdGhlIHNhbWU8YnI+DQpsb2dpYyB0byBhbiBTVkMtYmFzZWQgY28tcHMvY28tY3MgbW9kZSBj bGllbnQuLi4uaW5kZWVkIHRoZSBjby1jcyBtb2RlPGJyPg0KUFNUTiBpcyBsaWtlIHRoaXMuPGJy Pg0KPGJyPg0KVGhlc2Ugb2JzZXJ2YXRpb25zIG1ha2UgaXQgcXVpdGUgY2xlYXIgdG8gbWUgYXQg bGVhc3QgdGhhdCBqdXN0IGNvcHlpbmc8YnI+DQp0aGUgQUlTIGJlaGF2aW91ciBvZiB0aGUgb2xk IHRyYW5zcG9ydCBoaWVyYXJjaGllcyB0aGF0IGhhZCBmaXhlZDxicj4NCmNsaWVudC9zZXJ2ZXIg cmVsYXRpb25zaGlwcyBpcyBub3QgYSBzZW5zaWJsZSB0aGluZyB0byBkby48YnI+DQo8YnI+DQpJ TU8gdGhlIG9ubHkgZXNzZW50aWFsIERQIE9BTSByZXF1aXJlbWVudCBpcyB0aGF0IGVhY2ggbGF5 ZXIgbmV0d29yazxicj4NCnNob3VsZCBiZSBzZWxmLXN1ZmZpY2llbnQgd3J0IE9BTSBhbmQgbm90 IHJlbHkgb24gYW55IHNlcnZlciBsYXllcjxicj4NCnByaW1pdGl2ZXMgYmVpbmcgcGFzc2VkIHVw d2FyZHMuPGJyPg0KPGJyPg0KTW9yZW92ZXIsIGl0IHNob3VsZCBhbHNvIGJlIG5vdGVkIHRoYXQg KGkpIHRoZSBkZWZlY3RzIHRoYXQgY2FuIG9jY3VyIGluPGJyPg0KZWFjaCBvZiB0aGUgMyBuZXR3 b3JrIG1vZGVzIGFyZSBub3QgdGhlIHNhbWUgYW5kIChpaSkgdGhlaXIgT0FNPGJyPg0KcmVxdWly ZW1lbnRzIGFyZSBub3QgaWRlbnRpY2FsbHkgdGhlIHNhbWUuIFNvIHRoZSBPQU0gdGhhdCBhcHBs aWVzIHRvPGJyPg0KdGhlIGNsLXBzIG1vZGUgKGVnIElQKSBpcyBub3QgdGhlIHNhbWUgYXMgdGhl IE9BTSB0aGF0IGFwcGxpZXMgdG8gdGhlPGJyPg0KY28tcHMgbW9kZSAoZWcgTVBMUy1UUCkgYW5k IG5laXRoZXIgb2YgdGhlc2UgaXMgaWRlbnRpY2FsbHkgdGhlIHNhbWUgYXM8YnI+DQp0aGUgT0FN IHRoYXQgYXBwbGllcyB0byB0aGUgY28tY3MgbW9kZSAoZWcgU0RIKS48YnI+DQo8YnI+DQpOb3Rl IC0gVGhlIG9ubHkgcG9pbnQgYmVpbmcgY29uc2lkZXJlZCBoZXJlIGlzIHRoZSByZWFsIGNsaWVu dCBhbmQ8YnI+DQpzZXJ2ZXIgdHJhZmZpYyByZWxhdGlvbnNoaXAuICZuYnNwO1RoZSBjcmVhdGlv biBvZiBhIGhpZXJhcmNoeSBvZiBUQ008YnI+DQpzdWJsYXllcnMgaXMgYSBzZXBhcmF0ZSB0b3Bp Yy4gJm5ic3A7RnVydGhlciwgaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhDQpzaW1wbGU8YnI+DQp0 ZWNobmljYWwgYW5hbHlzaXMgdGhhdCBhbnkgbm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIGhhcyBu byBuZWVkIGZvcjxicj4NCkUtTk5JIHBlZXItcGFydGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZm ZXJlbnQgb3BlcmF0aW5nIHBhcnRpZXMuICZuYnNwO1NvPGJyPg0KdGhpcyBpcyBhbHNvIGEgc2Vw YXJhdGUgaXNzdWUuICZuYnNwO0hvd2V2ZXIsIEkgcHJvcG9zZSB0aGF0IHRoaXMgbGF0dGVyPGJy Pg0KcG9pbnQgYmUgY2FwdHVyZWQgaW4gdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzIGRyYWZ0IGR1 ZSB0byBpdHM8YnI+DQpzdGFuZC1hbG9uZSBhbmQgZ2VuZXJpYyBpbXBvcnRhbmNlLCBpZSB0aGlz IGFwcGxpZXMgdG8gbW9yZSB0aGFuIGp1c3QgRFA8YnI+DQpPQU0uICZuYnNwO0JlbiBjYW4geW91 IHBsZWFzZSBjb25zaWRlciB0aGlzIHBvaW50IGFzL3doZW4gdGhlIE1QTFMtVFA8YnI+DQpyZXF1 aXJlbWVudHMgZHJhZnQgaXMgdXBkYXRlZC48YnI+DQo8YnI+DQpyZWdhcmRzLCBOZWlsPGJyPg0K PGJyPg0KJmd0OyBDaGVlcnMsIEh1dWIuPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCm1wbHMt dHBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMtdHA8L3R0PjwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNp emU9Mz48dHQ+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVu ZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsDQpzZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPC90dD48L2ZvbnQ+PGZvbnQgc2l6 ZT0zPjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0Pi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwNCmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3Qg cGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24g dG8NCm90aGVycy48YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZv cm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtp cyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIn cyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRp b24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQm bmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4m bmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5i c3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0 aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2Vt YWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dp dGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVu ZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20m bmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7 aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJv ciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNz ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVz c2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNl cyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNw O3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000B290C482575A8_=-- From maarten.vissers@huawei.com Wed Apr 29 21:25:20 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EFB3A6959 for ; Wed, 29 Apr 2009 21:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=2.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyA259k4c9Nk for ; Wed, 29 Apr 2009 21:25:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 843C13A7133 for ; Wed, 29 Apr 2009 21:25:14 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIW00BK2CCA5V@szxga01-in.huawei.com> for mpls-tp@ietf.org; Thu, 30 Apr 2009 12:26:35 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIW002A1CCAIC@szxga01-in.huawei.com> for mpls-tp@ietf.org; Thu, 30 Apr 2009 12:26:34 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIW00JNWCC4KA@szxml02-in.huawei.com> for mpls-tp@ietf.org; Thu, 30 Apr 2009 12:26:34 +0800 (CST) Date: Thu, 30 Apr 2009 06:26:30 +0200 From: Maarten Vissers In-reply-to: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net> To: mpls-tp@ietf.org Message-id: <002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnIsXcTm9FBL9rkQFC9YRk9CsewQgAQmpvQABW/9iA= Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 04:25:20 -0000 We are discussing a change of a general fault management principle. This change will impact the following recommendations: G.806 (generic), G.7710 (generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN), G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and G.8121/G.8112/G.8151 (MPLS-TP). This proposed change has implications beyond the scope of MPLS-TP and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: woensdag 29 april 2009 19:57 To: ext Thomas Nadeau Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) I agree! -----Original Message----- From: ext Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Wednesday, April 29, 2009 1:01 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements) It would be best is these "Tier-1 SPs" would comment directly on the list or contribute to the requirements draft. --Tom On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: > Neil, > Thanks for the very good explanation. It really helps me to understand > better the context of the long discussion. > Personally I got many feedbacks from Tier-1 SPs that they would like > to > have the capability to suppress alarms in a packet transport > environment. Their requirement was that if a server layer (e.g. MPLS- > TP > link) fails, there is a way to notify the client layer (e.g. LSPs) in > order to be able to suppress alarms at the client layer that may > result > from the fault at the server layer (e.g. MPLS-TP link). > Isn't it a logical and reasonable requirement in a transport profile? > Also I saw general requirements for inter-layer fault correlation. So > can I understand from your mail that you are not happy from such a > requirement as well? > Best regards, > Nurit > > > > -----Original Message----- > From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, April 28, 2009 11:07 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > Nurit, > > I believe the reason we need this discussion is that there is an > unstated assumption here that the client/server relationship is fixed. > However, if the client can dynamically change its routing in > response to > link failures in its topology (because some server layer network has > failed....which may or may not belong to the same operating party as > the > client) then there is no fixed client/server relationship. > > Refer to my post earlier today and consider what this means in the > case > of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs > mode > client layer network. The key point here is the *routing process* in > the client is independent of the server layer network....so there is > not > a fixed client/server relationship. Further, there is also no > requirement for the server to keep track of where its client traffic > routings are at any epoch.....indeed why should it in the general case > where these are independent layer networks? > > So the only OAM requirement that is critical is that the OAM of the > client and server layer networks are independent. It is thus not > sensible to make client layer alarm supression a 'requirement' > here...in > fact if this is in the OAM requirements then it is technically wrong > and > should be removed IMO. > > regards, Neil >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >> Nurit (NSN - IL/Hod HaSharon) >> Sent: 28 April 2009 08:46 >> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >> transportpathrequirements) >> >> If we agree that the requirement is included, so why do we >> keep with the >> endless discussions on this requirement? >> >> -----Original Message----- >> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >> Sent: Tuesday, April 28, 2009 10:44 AM >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); >> hhelvoort@chello.nl; Adrian >> Farrel >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional >> transport >> pathrequirements) >> >> I think that the requirements are defined in section 2.2.8 of >> draft-ietf-mpls-tp-oam-requirements-01 >> >> Italo >> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >>> Nurit (NSN - IL/Hod HaSharon) >>> Sent: Tuesday, April 28, 2009 6:56 AM >>> To: hhelvoort@chello.nl; Adrian Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >>> transport pathrequirements) >>> >>> Huub, >>> I think that the requirement is to provide a mechanism to suppress >>> alarms in the networks, to ensure that alarms that may be >> generated by >>> client layers as a result of a failure condition in the >>> server layer may >>> be suppressed. >>> Every thing else is a solution, etc. >>> I propose to phrase the requirement appropriately and conclude the >>> discussion on this in the context of the requirements (until we are >>> getting to the solution phase). >>> This requirement is included in the OAM requirement draft. >>> Best regards, >>> NUrit >>> >>> >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>> Behalf Of ext Huub van Helvoort >>> Sent: Tuesday, April 28, 2009 12:27 AM >>> To: Adrian Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated >> bidirectional transport >>> path requirements) >>> >>> Hi Adrian, >>> >>> You wrote: >>> >>>> Isn't the solution here the same as the one I proposed for "TCM"? >>> >>> Indeed, and that we do not have to around in circles about TCM. >>> >>> How about: >>> the requirement is that a server layer shall inform its clients >>> that it has detected a service interuption, this to ensure that >>> the clients can inhibit (unnecessary) alarms. >>> >>> Cheers, Huub. >>> >>> -- >>> ================================================================ >>> http://www.van-helvoort.eu/ >>> ================================================================ >>> Always remember that you are unique...just like everyone else... >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Wed Apr 29 21:53:53 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A213A6D70 for ; Wed, 29 Apr 2009 21:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.489 X-Spam-Level: X-Spam-Status: No, score=0.489 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mCcQ+AezlUZ for ; Wed, 29 Apr 2009 21:53:51 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 693603A6D0D for ; Wed, 29 Apr 2009 21:53:48 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIW007JJDNOZY@szxga02-in.huawei.com> for mpls-tp@ietf.org; Thu, 30 Apr 2009 12:55:00 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIW003FIDNO1M@szxga02-in.huawei.com> for mpls-tp@ietf.org; Thu, 30 Apr 2009 12:55:00 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIW009DJDNIEW@szxml01-in.huawei.com>; Thu, 30 Apr 2009 12:55:00 +0800 (CST) Date: Thu, 30 Apr 2009 06:54:57 +0200 From: Maarten Vissers In-reply-to: <1241055907.49f902a335587@gold.itu.ch> To: ruiquan.jing@ties.itu.int, mpls-tp@ietf.org Message-id: <002a01c9c94f$d29a0b80$6802a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcnJNYPk8HcXMPP2SleG6EH4DlSCFwAFz7Kw Subject: Re: [mpls-tp] Interworking X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 04:53:53 -0000 Hi Jing, The difference between (3) and (4) is the following: (3) all services are supported via the EVC layer; i.e. the EVC layer is = the service/channel layer and starts/ends at the UNI-N ports. The PW is a = SS-PW layer and monitors p2p EVC link connections. PE nodes switch/bridge only EVC signals (as all customer service signals = are supported via EVCs). ------ (4) the p2p and p2mp services are supported via the PW layer (MS-PW) and = the rmp and mp2mp services are supported via the EVC layer; i.e. the PW = layer is the service/channel layer for p2p/p2mp services and for those services start/end at the UNI-N ports, while the EVC layer is the service/channel layer for rmp/mp2mp services and for those services start/end at the = UNI-N ports. Rmp/mp2mp customer services (Ethernet) are either clients of the EVC = layer, or peer with the EVC layer. P2p/p2mp customer services (PDH, SDH, ATM, Ethernet, ..) are clients fo = the PW layer (and may in future also peer with the PW layer). PE nodes will be able to switch/bridge both PW and EVC signals. Switch fabrics must support as such PW switching and Ethernet = bridging/switching. PW connections terminate on the UNI-N ports for the case of p2p/p2mp services.=20 PW connections terminate on the NNI ports for the case of rmp/mp2mp services.=20 ------ Interconnecting a MPLS-TP domain according to layer stack (4) with an Ethernet domain with layer stack (5) via an 802.3 interface results in = the following for rmp/mp2mp services (Ethernet E-Tree, E-LAN): (5) (4) ----------------------------------- | EVC EVC EVC | ---------------------------------------- | EVP | | 802.3 | | PW | ------------ --------- ------------ | T.Media | | LSP | ------------ ------------ | T.Media | ------------ And for p2p/p2mp services (Ethernet E-Line, PDH CES, ATM, SDH CES, ..) = it will be: (5) (4) ------- | EVC | ---------------------------------------- | EVC EVC X PW | ---------------------------------------- | EVP | | 802.3 | | LSP | ------------ --------- ------------ | T.Media | | T.Media | ------------ ------------ Regards, Maarten -----Original Message----- From: ruiquan.jing@ties.itu.int [mailto:ruiquan.jing@ties.itu.int]=20 Sent: donderdag 30 april 2009 3:45 To: maarten.vissers@huawei.com; mpls-tp@ietf.org Subject: RE: [mpls-tp] Interworking Hi Maarten=A3=AC What's difference between (3) and (4)? And for (3) and (4), with PW do = you mean SS-PW or both SS-PW and MS-PW? I think it should include both.=20 IMO, I think we should choose (4) with the addition of PDH/SDH/ATM etc. client beside EVC. Best Regards Jing Ruiquan -------------------------------------------------------------------------= --- ---- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Maarten Vissers Sent: Wednesday, April 29, 2009 5:05 PM To: 'Michael T. Wu (mtwu)'; mpls-tp@ietf.org Subject: Re: [mpls-tp] Interworking Michael, I have been discussing interworking with existing Ethernet technologies = on this=20 mailinglist for some time, but we have not made much progress so far. = Before we=20 can talk about such "interworking" or "interconnection" we have to agree = on the=20 layer stack of MPLS-TP based packet transport network domains. I believe that there are four alternative MPLS-TP based packet transport = network layer stacks: (1) (2) (3) (4) ------------ --------------- ------------- ------- | EVC | | EVC & MS-PW | | EVC | | EVC | ------------ --------------- ------------- ------------ | LSP | | LSP | | PW | | PW | ------------ --------------- ------------- ------------ | T.Media | | Trans.Media | | LSP | | LSP | ------------ --------------- ------------- ------------ | T.Media | | T.Media | ------------- ------------ Which of these four stacks do we want to standardize for MPLS-TP based packet=20 transport networks? For Ethernet based packet transport networks the layer stack is: (5) ------------ | EVC | ------------ | EVP | ------------ | T.Media | ------------ For PBB-TE based packet transport networks the layer stack is: (6) ------------ | EVC | ------------ | TESI | ------------ | T.Media | ------------ We will also have to talk about the layer stack of the interface = connecting the=20 two technologies. I expect that those layer stacks to interconnect with=20 Ethernet and PBB-TE based packet transport network domains will be: (7) (8)=20 ------------ ----------- | EVC | | EVC | ------------ ----------- | T.Media | | EVP | ------------ -----------=20 | T.Media | -----------=20 Interconnection/Interworking Ethernet and MPLS-TP packet transport = network=20 domains may then be one of the following cases (note: numbers refer to = the=20 layer stacks above): A) (1) - (7) - (5) B) (1) - (8) - (5) C) (2) - (7) - (5) D) (2) - (8) - (5) E) (3) - (7) - (5) F) (3) - (8) - (5) G) (4) - (7) - (5) H) (4) - (8) - (5) In the above cases A to H I have assumed that the two domains that=20 interconnect/interwork have each their own equipment, and = interconnection is via an 802.3 interface. In many cases both domains will be sharing an = edge node=20 and interconnection is via the switch matrix; i.e. one line port = connects to the ethernet domain and the other line port connects to the MPLS-TP = domain.=20 This adds another four cases: I) (1) - (5) J) (2) - (5) K) (3) - (5) L) (4) - (5) Regards, Maarten -------------------------------------------------------------------------= --- ---- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of=20 Michael T. Wu (mtwu) Sent: woensdag 29 april 2009 8:25 To: mpls-tp@ietf.org Subject: [mpls-tp] Interworking Hi, Is there a draft or discussion on the interworking with existing technologies=20 (L2 or L3) and standards (ITU/MEF)? Thanks, Michael From hklam@alcatel-lucent.com Wed Apr 29 21:59:10 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CBD3A6D70 for ; Wed, 29 Apr 2009 21:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmF59RJReg80 for ; Wed, 29 Apr 2009 21:59:09 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 27A613A69A7 for ; Wed, 29 Apr 2009 21:59:08 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n3U50HCE010192; Thu, 30 Apr 2009 00:00:17 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 00:00:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 23:59:22 -0500 Message-ID: In-Reply-To: <002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnIsXcTm9FBL9rkQFC9YRk9CsewQgAQmpvQABW/9iAAAOdA0A== References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net> <002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> From: "Lam, Hing-Kam $Kam$" To: X-OriginalArrivalTime: 30 Apr 2009 05:00:17.0023 (UTC) FILETIME=[8DCB08F0:01C9C950] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 04:59:10 -0000 All I can say is that the impact of this proposed change is very serious.=20 Doesn't MPLS-TP suppose to meet the ITU-T transport requirements instead of changing the ITU-T transport requirements? Regards, Kam > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Maarten Vissers > Sent: Thursday, April 30, 2009 12:27 AM > To: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > We are discussing a change of a general fault management principle. This > change will impact the following recommendations: G.806 (generic), G.7710 > (generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN), > G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and > G.8121/G.8112/G.8151 > (MPLS-TP). This proposed change has implications beyond the scope of MPLS- > TP > and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: woensdag 29 april 2009 19:57 > To: ext Thomas Nadeau > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > I agree! >=20 > -----Original Message----- > From: ext Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Wednesday, April 29, 2009 1:01 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) >=20 >=20 > It would be best is these "Tier-1 SPs" would comment directly on > the > list or contribute to the requirements draft. >=20 > --Tom >=20 >=20 > On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) > wrote: >=20 > > Neil, > > Thanks for the very good explanation. It really helps me to understand > > better the context of the long discussion. > > Personally I got many feedbacks from Tier-1 SPs that they would like > > to > > have the capability to suppress alarms in a packet transport > > environment. Their requirement was that if a server layer (e.g. MPLS- > > TP > > link) fails, there is a way to notify the client layer (e.g. LSPs) in > > order to be able to suppress alarms at the client layer that may > > result > > from the fault at the server layer (e.g. MPLS-TP link). > > Isn't it a logical and reasonable requirement in a transport profile? > > Also I saw general requirements for inter-layer fault correlation. So > > can I understand from your mail that you are not happy from such a > > requirement as well? > > Best regards, > > Nurit > > > > > > > > -----Original Message----- > > From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Tuesday, April 28, 2009 11:07 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > > > > Nurit, > > > > I believe the reason we need this discussion is that there is an > > unstated assumption here that the client/server relationship is fixed. > > However, if the client can dynamically change its routing in > > response to > > link failures in its topology (because some server layer network has > > failed....which may or may not belong to the same operating party as > > the > > client) then there is no fixed client/server relationship. > > > > Refer to my post earlier today and consider what this means in the > > case > > of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs > > mode > > client layer network. The key point here is the *routing process* in > > the client is independent of the server layer network....so there is > > not > > a fixed client/server relationship. Further, there is also no > > requirement for the server to keep track of where its client traffic > > routings are at any epoch.....indeed why should it in the general case > > where these are independent layer networks? > > > > So the only OAM requirement that is critical is that the OAM of the > > client and server layer networks are independent. It is thus not > > sensible to make client layer alarm supression a 'requirement' > > here...in > > fact if this is in the OAM requirements then it is technically wrong > > and > > should be removed IMO. > > > > regards, Neil > >> -----Original Message----- > >> From: mpls-tp-bounces@ietf.org > >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > >> Nurit (NSN - IL/Hod HaSharon) > >> Sent: 28 April 2009 08:46 > >> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > >> Cc: mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > >> transportpathrequirements) > >> > >> If we agree that the requirement is included, so why do we > >> keep with the > >> endless discussions on this requirement? > >> > >> -----Original Message----- > >> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > >> Sent: Tuesday, April 28, 2009 10:44 AM > >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); > >> hhelvoort@chello.nl; Adrian > >> Farrel > >> Cc: mpls-tp@ietf.org > >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > >> transport > >> pathrequirements) > >> > >> I think that the requirements are defined in section 2.2.8 of > >> draft-ietf-mpls-tp-oam-requirements-01 > >> > >> Italo > >> > >>> -----Original Message----- > >>> From: mpls-tp-bounces@ietf.org > >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, > >>> Nurit (NSN - IL/Hod HaSharon) > >>> Sent: Tuesday, April 28, 2009 6:56 AM > >>> To: hhelvoort@chello.nl; Adrian Farrel > >>> Cc: mpls-tp@ietf.org > >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > >>> transport pathrequirements) > >>> > >>> Huub, > >>> I think that the requirement is to provide a mechanism to suppress > >>> alarms in the networks, to ensure that alarms that may be > >> generated by > >>> client layers as a result of a failure condition in the > >>> server layer may > >>> be suppressed. > >>> Every thing else is a solution, etc. > >>> I propose to phrase the requirement appropriately and conclude the > >>> discussion on this in the context of the requirements (until we are > >>> getting to the solution phase). > >>> This requirement is included in the OAM requirement draft. > >>> Best regards, > >>> NUrit > >>> > >>> > >>> -----Original Message----- > >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > >>> Behalf Of ext Huub van Helvoort > >>> Sent: Tuesday, April 28, 2009 12:27 AM > >>> To: Adrian Farrel > >>> Cc: mpls-tp@ietf.org > >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated > >> bidirectional transport > >>> path requirements) > >>> > >>> Hi Adrian, > >>> > >>> You wrote: > >>> > >>>> Isn't the solution here the same as the one I proposed for "TCM"? > >>> > >>> Indeed, and that we do not have to around in circles about TCM. > >>> > >>> How about: > >>> the requirement is that a server layer shall inform its clients > >>> that it has detected a service interuption, this to ensure that > >>> the clients can inhibit (unnecessary) alarms. > >>> > >>> Cheers, Huub. > >>> > >>> -- > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> http://www.van-helvoort.eu/ > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> Always remember that you are unique...just like everyone else... > >>> _______________________________________________ > >>> mpls-tp mailing list > >>> mpls-tp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>> _______________________________________________ > >>> mpls-tp mailing list > >>> mpls-tp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>> > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > >> > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From neil.2.harrison@bt.com Wed Apr 29 23:26:51 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4103A6CCF; Wed, 29 Apr 2009 23:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1BMq0oru9uw; Wed, 29 Apr 2009 23:26:47 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id DF8643A68A4; Wed, 29 Apr 2009 23:26:46 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 07:28:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C95C.D4138268" Date: Thu, 30 Apr 2009 07:28:03 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E27A3@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) Thread-Index: AcnJOAzJjzYibq4MTlmF9pJ+EsN1rAAHdXCA From: To: X-OriginalArrivalTime: 30 Apr 2009 06:28:07.0950 (UTC) FILETIME=[D382AAE0:01C9C95C] Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:26:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C95C.D4138268 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhhbmtzIFN1aHVpDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCUZy b206IHN1Lmh1aUB6dGUuY29tLmNuIFttYWlsdG86c3UuaHVpQHp0ZS5jb20uY25dIA0KCVNlbnQ6 IDMwIEFwcmlsIDIwMDkgMDM6MDANCglUbzogSGFycmlzb24sTixOZWlsLENYTSBSDQoJQ2M6IGFk cmlhbkBvbGRkb2cuY28udWs7IE5pdmVuLWplbmtpbnMsQixCZW4sRE1GIFI7IGhoZWx2b29ydEBj aGVsbG8ubmw7IG1wbHMtdHBAaWV0Zi5vcmc7IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KCVN1 YmplY3Q6IOetlOWkjTogUkU6IFJFOiBSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1lbnRzKQ0KCQ0KCQ0KDQoJ SGkgTmVpbCwgDQoJDQoJSSB0aGluayBJIG1pc3VuZGVyc3Rvb2QgdGhlIHdvcmRzIOKAmHRvcC1v Zi1zdGFjayBuZXR3b3Jr4oCZICwgSXQgZG9lc27igJl0IG1lYW4gYSBuZXR3b3JrIGlzIGFjdHVh bGx5IGF0IHRvcCBvZiB0aGUgc3RhY2ssIHNvIG5vIG1hdHRlciB3aGF0IGxheWVyIElQIG5ldHdv cmsgaXMgYWN0dWFsbHkgYXQsIElQIG5ldHdvcmsgaXMgYWx3YXlzIGEg4oCYdG9wLW9mLXN0YWNr IG5ldHdvcmvigJkgYmVjYXVzZSBpdCBjYW4g4oCYc3VwcG9ydCBleHRlcm5hbCBtZXNzYWdlL2Zp bGUvc3RyZWFtIGFwcGxpY2F0aW9uc+KAmS4gSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodD8gDQoJ IA0KCU5IPT4gWWVzLiAgIFRoZXJlIGlzIHByb2JhYmx5IGEgYmV0dGVyIHRlcm0gZm9yIGl0LCBi dXQgaXQgd2FzIHRoZSBleHByZXNzaW9uIHRoYXQgZmlyc3QgY2FtZSB0byBtaW5kIHdoZW4gSSB3 YW50ZWQgYSBzaG9ydGhhbmQgd2F5IHRvIGRlZmluZToNCgktICAgIHRoZSBuZXR3b3JrIHRoYXQg ZGlyZWN0bHkgc3VwcG9ydHMgZXh0ZXJuYWwgYXBwbGljYXRpb25zIC0gIHRvcC1vZi1zdGFjay4N CgktICAgIHRoZSAgbmV0d29yayB0aGF0IG1vZHVsYXRlcyB0aGUgRU0gd2F2ZSBvbiBtZXRhbGxp Yy9vcHRpY2FsL3JhZGlvIG1lZGlhIC0gYm90dG9tLW9mLXN0YWNrDQoJIA0KCU5vdGUgLSBzb21l IG5ldHdvcmsgdGVjaG5vbG9naWVzIGNhbm5vdCBjdXJyZW50bHkgZnVsZmlsIGVpdGhlciBvZiB0 aGVzZSByb2xlcy4uLi5pbmRlZWQgTVBMUyBpcyBsaWtlIHRoaXMuIA0KCQ0KCUJvdGggdGhlc2Ug bmV0d29ya3MgbXVzdCBiZSBwcmVzZW50IGluIGFsbCBwcmFjdGljYWwgbmV0d29ya2luZyBzaXR1 YXRpb25zOg0KCS0gICAgaWYgdGhlIGZvcm1lciBpcyBub3QgcHJlc2VudCB0aGUgbmV0d29ya2lu ZyBvZiB0aGUgbG93ZXIgbGF5ZXJzIGlzIHNlcnZpbmcgbm8gcHVycG9zZXM7DQoJLSAgICBpZiB0 aGUgbGF0dGVyIGlzIG5vdCBwcmVzZW50IHdlIGNhbm5vdCBzZW5kIGluZm9ybWF0aW9uIGFjcm9z cyBnZW9ncmFwaGljIGRpc3RhbmNlLi4uLi4uYW5kIGp1c3QgYXMgSSBhbmQgRGVib3JhaCBoYXZl IHJlcGVhdGVkbHkgcG9pbnRlZCBvdXQgdGhlIG1lcmUgdGhhdCB0aGVyZSBpcyBwaHlzaWNhbCBp bnRlcmZhY2UvY29ubmVjdGlvbiBoZXJlIGRvZXMgKm5vdCogbWVhbiB0aGlzIGlzIGFuIEUtTk5J LiANCgkgDQoJQW4gRS1OTkkgbXVzdCBjb25zaWRlciBhbGwgRFAgYW5kIENQIGNvbXBvbmVudHMg dGhhdCBhcmUgdXNlZCBieSBhbiBvcGVyYXRpbmcgcGFydHkgaW4gdGhlaXIgb3duIGRvbWFpbiBm b3Igc29tZSBuZXR3b3JrIG1vZGUvdGVjaG5vbG9neSBYLi4uLi5zbyB0aGlzIGlzIG11Y2ggbW9y ZSB0aGFuIHNpbXBseSBPQU0uICBJbiBwYXJ0aWN1bGFyIGl0IG11c3QgY29uc2lkZXIgdGhlIERQ IGludGVyd29ya2luZyBvZiB0aGUgZW5kLXN5c3RlbSBhcHBsaWNhdGlvbiBhZGFwdGF0aW9uIGZ1 bmN0aW9ucyB0aGF0IHN1cHBvcnQgZXh0ZXJuYWwgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNh dGlvbnMsIGFuZCBpZiB0aGVzZSBhcmUgKm5vdCogcHJlc2VudCB0aGVuIG5ldHdvcmsgWCBNVVNU IGJlIHN1cHBvcnRpbmcgYSBoaWdoZXIgbGF5ZXIgbmV0d29yayBZIGJ5IGRlZmluaXRpb24uICBX ZSB0aGVyZWZvcmUgb2JzZXJ2ZSB0aGF0IHBlZXItcGFydGl0aW9uIGludGVyd29ya2luZyBhdCBu ZXR3b3JrIFggaXMgbm90IG5lY2Vzc2FyeS4gIE5ldHdvcmsgWCBjYW4gYmUgZnVsbHkgdGVybWlu YXRlZCBhdCB0aGUgaW50ZXJ3b3JraW5nIHBvaW50IGFuZCBuZXR3b3JrIFkgcGFzc2VkIHRyYW5z cGFyZW50bHkuICBUaGUgYWJvdmUgaXMgcmVjdXJzaXZlIHVwd2FyZHMgdW50aWwgd2UgY29tZSB0 byB0aGUgcmVhbCB0b3Atb2Ytc3RhY2sgbmV0d29yayBhbmQgaXQgaXMgaGVyZSB0aGF0IEUtTk5J cyBhcmUgZXNzZW50aWFsLi4uLi5hbmQgaW5kZWVkIHRoaXMgaXMgZXhhY3RseSB3aGF0IHdlIHNl ZSBmb3IgdGhlIHB1YmxpYyBuZXR3b3JrcyBvZiB0aGUgSW50ZXJuZXQgYW5kIHRoZSBQU1ROLg0K CSANCgkNCglCdXQgSSBzdGlsbCBjYW5ub3QgYWdyZWUgdGhlIGFzc2VydGlvbiB0aGF0IOKAmGFu eSBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmsgaGFzIG5vIG5lZWQgZm9yIEUtTk5JIHBlZXItcGFy dGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0aW5nIHBhcnRpZXPigJkuIEFz IHlvdSBzYWlkIFNESCBpcyBub3QgYSB0b3Atb2Ytc3RhY2sgbmV0d29yaywgYnV0IFZDNCBjb25u ZWN0aW9ucyBjYW4gcGFzcyB0aHJvdWdoIG11bHRpIG9wZXJhdG9y4oCZcyBkb21haW5zLCBzbyB0 aGUgaW50ZXJmYWNlIGJldHdlZW4gZGlmZmVyZW50IGRvbWFpbnMgaXMgRS1OTkkuICANCgkgDQoJ Tkg9PiBObywgdGhpcyBpcyBub3QgY29ycmVjdC4gIFdlIGNhbiBvZiBjb3Vyc2UgY3JlYXRlIEUt Tk5JcyBmb3IgYW55IG5ldHdvcmsvbW9kZSB3ZSBsaWtlLCBidXQgd2hhdCBJIGFtIHNob3dpbmcg aXMgdGhhdCB0aGlzIGlzIG5vdCB0ZWNobmljYWxseSBuZWNlc3NhcnkgZm9yIG5ldHdvcmtzIHRo YXQgYXJlIG5vdCB0b3Atb2Ytc3RhY2suICBJbiBmYWN0IGl0IGlzIGFjdHVhbGx5IG11Y2ggbW9y ZSBzZXJpb3VzIHRoYW4gc2ltcGx5ICJub3QgbmVjZXNzYXJ5IiwgYmVjYXVzZSB3aGVuIHlvdSBj cmVhdGUgc3VjaCBwZWVyLXBhcnRpdGlvbnMgYmV0d2VlbiBkaWZmZXJlbnQgcGFydGllcyB5b3Ug YXJlIGZvcmNpbmcgdGhlbSB0byBldm9sdmUgdGhlaXIgbmV0d29ya3MgKHRoYXQgaGF2ZSBzdWNo IHBlZXIgcGFydGl0aW9ucykgaW4gbG9jay1zdGVwIChhbmQgdGhlcmUgYXJlIGFsc28gcmVndWxh dG9yeSBmYWN0b3JzIHRvIGNvbnNpZGVyIGhlcmUgLSBhbHNvIHNlZSBBc2lkZSBiZWxvdykuICAg Rm9yIHRoZSB2YXN0IG1ham9yaXR5IG9mIHByYWN0aWNhbCBzaXR1YXRpb25zIGEgY2xpZW50L3Nl cnZlciByZWxhdGlvbnNoaXAgaXMgbW9yZSByZWxldmFudCwgc2FmZXIgYW5kIGltcG9ydGFudC4N CgkgDQoJVGhpcyBzaXR1YXRpb24gd291bGQgYmUgZXZlbiBtb3JlIHVuYWNjZXB0YWJsZSBzaG91 bGQgc3VjaCBwZWVyLXBhcnRpdGlvbnMgYmUgYmV0d2VlbiBkaWZmZXJlbnQgbW9kZXMvdGVjaG5v bG9naWVzLCBlZyBFdGhlcm5ldCBhbmQgTVBMUyBpbnRlcndvcmtpbmcuICBUaGlzIGlzIG1vc3Qg ZGVmaW5pdGVseSBub3QgYSBnb29kIGlkZWEgYW5kIHdlIGluIEJUIHdpbGwgbm90IHN1cHBvcnQg dGhpcy4gDQoJIA0KCUFzaWRlPT4gVGhpcyBkb2VzIG5vdCBwcmV2ZW50IG9wZXJhdGluZyBwYXJ0 aWVzIGhhdmluZyBwcml2YXRlIGJpbGF0ZXJhbCBwZWVyLXBhcnRpdGlvbiByZWxhdGlvbnNoaXBz IGluIHNvbWUgbm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIHRlY2hub2xvZ3kuICAgSG93ZXZlciwg dGhpcyB3b3VsZCBuZWVkIHRvIGNvbnNpZGVyIGFueSBsZWdhbC9jb21tZXJjaWFsIHJlZ3VsYXRv cnkgZnJhbWV3b3JrIHRoYXQgaXMgaW4gZm9yY2Ugd2hlcmUgdGhpcyBpcyBiZWluZyBjb25zaWRl cmVkLg0KCSANCglOZWlsIEhhcnJpc29uDQoJQ2hpZWYgTmV0d29yayBPcGVyYXRpb25zIFN0cmF0 ZWdpc3QNCglCVCBJbm5vdmF0ZQ0KCQ0KCVRlbDogKzQ0ICgwKSAxIDYwNCA4MjAgMDUyDQoJRW1h aWw6IG5laWwuMi5oYXJyaXNvbkBidC5jb20gPG1haWx0bzpuZWlsLjIuaGFycmlzb25AYnQuY29t PiANCglXZWI6IHd3dy5idC5jb20gPGh0dHA6Ly93d3cuYnQuY29tLz4gIA0KCVRoaXMgZW1haWwg Y29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZp ZGVudGlhbC4NCglJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0 eSBuYW1lZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5kZWQNCglyZWNpcGllbnQsIG5v dGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcyBp bmZvcm1hdGlvbg0KCWlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2UgbGV0IG1lIGtub3cgaW1tZWRpYXRlbHkNCglvbiB0aGUgZW1haWwg YWRkcmVzcyBhYm92ZS4gVGhhbmsgeW91Lg0KCVdlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwg YW5kIG1heSByZWNvcmQgeW91ciBlbWFpbHMuIA0KCUJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25z IHBsYw0KCVJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3 QUoNCglSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDE4MDAwMDAgDQoNCgkNCglSZWdhcmRzLCAN CglTdWh1aS4gDQoJDQoJDQoJDQoJDQo8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbT4gDQoNCjIwMDkt MDQtMjkgMTg6MjEgDQoNCuaUtuS7tuS6ug0KPHN1Lmh1aUB6dGUuY29tLmNuPiANCuaKhOmAgQ0K PGFkcmlhbkBvbGRkb2cuY28udWs+LCA8YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20+LCA8 aGhlbHZvb3J0QGNoZWxsby5ubD4sIDxtcGxzLXRwQGlldGYub3JnPiwgPG1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZz4gDQrkuLvpopgNClJFOiBSRTogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMg QXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRoICAgICAgICByZXF1aXJlbWVu dHMpDQoNCgkNCg0KDQoNCg0KCVRoYW5rcyBTdWh1aS4uLi4uLnNvcnJ5IEkgbWlzc2VkIHlvdXIg c3BlY2lmaWMgcXVlc3Rpb24uLi4uaGF2ZSBhIGxvb2sgaW4tbGluZSBhbmQgc2VlIGlmIHRoaXMg aGVscHMuIA0KCQ0KCQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCUZyb206 IHN1Lmh1aUB6dGUuY29tLmNuIFttYWlsdG86c3UuaHVpQHp0ZS5jb20uY25dIA0KCVNlbnQ6IDI5 IEFwcmlsIDIwMDkgMTA6MzENCglUbzogSGFycmlzb24sTixOZWlsLENYTSBSDQoJQ2M6IGFkcmlh bkBvbGRkb2cuY28udWs7IE5pdmVuLWplbmtpbnMsQixCZW4sRE1GIFI7IGhoZWx2b29ydEBjaGVs bG8ubmw7IG1wbHMtdHBAaWV0Zi5vcmc7IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KCVN1Ympl Y3Q6IOetlOWkjTogUkU6IFJlOiBbbXBscy10cF0gQUlTL0ZESSAod2FzIEFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1aXJlbWVudHMpDQoJDQoJDQoJSGkgTmVpbO+8 jCANCgkNCglUaGFua3MgZm9yIHlvdXIgcmFwaWQgcmVwbHkuIA0KCUkgYW0gY29uZnVzZWQgYnkg eW91ciBjb21tZW50cywgYXJlIHlvdSBzdWdnZXN0aW5nIEV2ZXJ5dGhpbmdvdmVySVBvdmVyTVBM Uy1UUD8gQUZBSUssIE1QTFMtVFAgY2FuIGNhcnJ5IG1hbnkga2luZHMgb2YgY2xpZW50cywgbm90 IGp1c3QgSVAuSW4gbXkgZXhhbXBsZSwgRTFvdmVyUFdvdmVyTVBMUy1UUCwgdGhlcmUgaXMgbm8g SVAgbGF5ZXIgYXQgYWxsLiAgIA0KCSAgDQoJTkg9PiBGdWxseSB1bmRlcnN0YW5kLiAgSSB3YXMg Z2l2aW5nIElQIGFzIGFuICpleGFtcGxlKiBvZiBhIHRlY2hub2xvZ3kgdGhhdCBjYW4gc3VwcG9y dCByZWFsIGV4dGVybmFsIGFwcGxpY2F0aW9ucyBiZWNhdXNlIGl0IGhhcyBtZXNzYWdlL2ZpbGUv c3RyZWFtIGFwcGxpY2F0aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zIGluIHRoZSBmb3JtIG9mIFVE UC9UQ1AvUlRQLiAgIEluIHRoZSBjYXNlIG9mIEUxIHRoYXQgeW91IG5vdGUgKGFzIEUxb3ZlclBX b3Zlck1QTFMtVFApIHlvdSBoYXZlIHRvIGFzayB5b3Vyc2VsZiB3aGF0IHNwZWNpZmljICpleHRl cm5hbCogYXBwbGljYXRpb25zIGRvZXMgdGhlIEUxIHN1cHBvcnQgaGVyZT8uLi4uLmFsd2F5cyBy ZW1lbWJlcmluZyB0aGF0ICphbnkqIG5ldHdvcmtpbmcgdGVjaG5vbG9neSBNVVNUIHVsdGltYXRl bHkgc3VwcG9ydCBzb21lIGZvcm0gb2YgKmV4dGVybmFsbHkgc291cmNlZCogaW5mb3JtYXRpb24g c291cmNlIGVsc2UgaXQgaXMgbm90IHNlcnZpbmcgYW55IHB1cnBvc2UuICBTbyBqdXN0IHN1cHBv cnRpbmcgRTEgb24gaXRzIG93biBkb2VzIG5vdCBwcm92aWRlIHRoaXMuLi4uZm9yIGV4YW1wbGUg YXNrIHlvdXJzZWxmIGhvdyB2b2ljZSBvciBhbnkgdHlwZSBvZiBtZXNzYWdlL2ZpbGUgZGF0YSBn ZXRzIGNhcnJpZWQgYnkgdGhlIEUxLiANCgkgDQoJQW5kIHlvdSBkb27igJl0IGFuc3dlciBteSBx dWVzdGlvbjogSVAgaXMgYSB0b3Atb2Ytc3RhY2sgbmV0d29yayBpbiB0aGUgY2FzZSBvZiBFMW92 ZXJQV292ZXJJUCwgd2h5IGRvZXNuJ3QgTVBMUy1UUCBiZSBhIHRvcC1vZi1zdGFjayBuZXR3b3Jr IGluIHRoZSBjYXNlIG9mIEUxb3ZlclBXb3Zlck1QTFMtVFA/IFRoZXkgYXJlIGF0IHRoZSBzYW1l IHBvc2l0aW9uIGluIHRoZSBzdGFjaywgYW5kIEkgdGhpbmsgRTEgaXMg4oCYcmVhbCBleHRlcm5h bCBzdHJlYW0gYXBwbGljYXRpb25z4oCZIA0KCSAgDQoJTkg9PiBUaGUgcG9pbnQgaGVyZSBpcyB0 aGF0ICphbnkqIG5ldHdvcmsgbW9kZS90ZWNobm9sb2d5IChiZSBpdCBjbC1wcywgY28tcHMgb3Ig Y28tY3MpIGNhbiBhY3QgYXMgdGhlIHNlcnZlciBmb3IgYW55IG90aGVyIG1vZGUvdGVjaG5vbG9n eS4gIEhvd2V2ZXIsIG5vdCBhbGwgdGVjaG5vbG9naWVzIGNhbiBzdXBwb3J0IGV4dGVybmFsIGFw cGxpY2F0aW9ucy4uLi4udG8gc3VwcG9ydCB0aGVzZSB0aGUgdGVjaG5vbG9neSBtdXN0IGhhdmUg YXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMgZm9yIHRoZSBtZXNzYWdlL2ZpbGUvc3Ry ZWFtIGluZm9ybWF0aW9uIHNvdXJjZXMgdGhhdCBhcmUgZ2VuZXJhdGVkIGluIGV4dGVybmFsIENQ RSwgZWcgcGhvbmUsIFBDLCBldGMuIA0KCSAgDQoJTW9zdCB0ZWNobm9sb2dpZXMgZG8gbm90IGhh dmUgdGhlc2UgZXh0ZXJuYWwgYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMgYW5kIHNv IHRoZSBvbmx5IGpvYiB0aGV5IGNhbiBkbyBpcyBjcmVhdGUgdGhlIHRvcG9sb2d5IG9mIG90aGVy IGxheWVyIG5ldHdvcmtzLiANCgkgIA0KCVNvIHllcyB3ZSBjYW4gdXNlIElQIChjbC1wcykgdG8g Y2FycnkgU0RIIFZDNCAoY28tY3MpIGlmIHdlIHdhbnQuLi4uLi4ucHJvYmFibHkgbm90IGEgZ29v ZCBpZGVhIGJ1dCBpdCBpcyBmb3Igc3VyZSBwb3NzaWJsZS4gIEhvd2V2ZXIsIGFuIFNESCBWQzQg bmV0d29yayBjYW5ub3QgKmRpcmVjdGx5KiBzdXBwb3J0IGVpdGhlciB2b2ljZSBvciBkYXRhIGJ1 dCBhbiBJUCBuZXR3b3JrIGNhbi4uLi4uYmVjYXVzZSBJUCBoYXMgVURQL1RDUC9SVFAgYXBwbGlj YXRpb25zIGFkYXB0YXRpb25zIGFuZCBTREggVkM0IGRvZXMgbm90IGhhdmUgdGhlc2UuICBIYXZp bmcgc2FpZCB0aGF0LCB0aGVyZSBpcyBpbiBwcmluY2lwbGUgbm8gcmVhc29uIHdoeSBhbnkgbW9k ZS90ZWNobm9sb2d5IChldmVuIFNESCBWQzQpIGNhbm5vdCBzdXBwb3J0IGV4dGVybmFsIG1lc3Nh Z2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zLi4uLi4uaXRzIGp1c3QgdGhhdCBmb3IgbW9zdCB0 ZWNobm9sb2dpZXMgdGhlc2UgaGF2ZSBuZXZlciBiZWVuIHNwZWNpZmllZCBiZWNhdXNlIHRoZXkg d2VyZSBvbmx5IGV2ZXIgaW50ZW5kZWQgdG8gcHJvdmlkZSBhICduZXR3b3JrIGJ1aWxkZXInIHRy YW5zcG9ydCByb2xlLiANCgkgIA0KCUFzaWRlPT4gSWYgYSB0ZWNobm9sb2d5IFggY2FuIHN1cHBv cnQgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBsaWNhdGlvbnMgZGlyZWN0bHkgdGhlbiBoZXJlIHdl IHdvdWxkIG1vc3QgZGVmaW5pdGVseSBoYXZlIHRvIGNvbnNpZGVyIHBlZXItaW50ZXJ3b3JraW5n IHRlY2hub2xvZ3kgWCB3aXRoIGJvdGggSVAgKEludGVybmV0KSBhbmQgUFNUTiAodm9pY2UgY2Fz ZSBvbmx5KS4gIEluIGFsbCBvdGhlciBjYXNlcyAoaWUgd2hlcmUgdGVjaG5vbG9neSBYIGlzIG5v dCB0b3Atb2Ytc3RhY2ssIGllIGRvZXMgbm90IGhhdmUgbWVzc2FnZS9maWxlL3N0cmVhbSBhcHBs aWNhdGlvbiBhZGFwdGF0aW9uIGZ1bmN0aW9ucykgdGhlcmUgaXMgbm8gbmVlZCBmb3IgcGVlci1p bnRlcndvcmtpbmcgaXQgd2l0aCBhbnkgb3RoZXIgdGVjaG5vbG9neSwgaW5jbHVkaW5nIElQIChJ bnRlcm5ldCkgYW5kIFBTVE4uIA0KCSAgDQoJICANCglZb3VyIGZpbmFsIHBvaW50ICgiSSB0aGlu ayBFMSBpcyDigJhyZWFsIGV4dGVybmFsIHN0cmVhbSBhcHBsaWNhdGlvbnPigJkiICkgaXMgbm90 IHN0cmljdGx5IGNvcnJlY3QgYnV0IEkgY2FuIGZ1bGx5IHVuZGVyc3RhbmQgd2h5IHlvdSBzYXkg dGhpcy4gIEUxIGJlbG9uZ3MgdG8gdGhlIGNvLWNzIG1vZGUuICBXaGVuIHlvdSBhbmFseXNlIHRo aXMgKGFzIGlzIGRvbmUgaW4gRy44MDAsIHdoaWNoIGV4cGxhaW5zIHdoeSB0aGUgMyBuZXR3b3Jr IG1vZGVzIGFyaXNlIGZyb20gaW5mb3JtYXRpb24vc3lzdGVtcyB0aGVvcnkgY29uc2lkZXJhdGlv bnMpIHlvdSBmaW5kIHRoYXQgaW4gdGhlIHRpbWUgZGltZW5zaW9uIHRoZSBjby1jcyBtb2RlIHBh cnRpdGlvbnMgcmVzb3VyY2UgKHRpbWUpIHVwIGludG8gcmVndWxhciB0aW1lIHNsaWNlcy4uLi5z byB0aGlzIG1lYW5zIGJvdGggdGhlIHN0YXJ0IGVwb2NoIChhbiBpbXBsaWNpdCBsYWJlbCkgYW5k IChtb3N0IGNydWNpYWxseSkgaXRzIGR1cmF0aW9uIGFyZSBmaXhlZC4gICANCgkgIA0KCVdpdGhv dXQgZ29pbmcgaW50byBtYWpvciBkZXRhaWwgaGVyZSAoSSBoYXZlIHBhcGVyIG9uIHRoaXMgSSBj YW4gc2VuZCB5b3UgaWYgeW91IHdhbnQuLi5qdXN0IGFzaykgd2hhdCB0aGlzIG1lYW5zIGlzIHRo YXQgdGhlIGNvLWNzIG1vZGUgaXMgdGhlIHVsdGltYXRlICdzbW9vdGhlci9zaGFwZXInIGZvciBj bGllbnQgdHJhZmZpYy4uLi4uLnNvIGFzIHlvdSByaWdodGx5IG9ic2VydmUgdGhpcyBsb29rcyBs aWtlIGEgc3RyZWFtIGNhc2UuICBJdCdzIG5vdCBhIHNwZWNpZmljIGV4dGVybmFsIGFwcGxpY2F0 aW9uIGhvd2V2ZXIgbGlrZSBodW1hbiB2b2ljZSBvciB2aWRlbyAodGhlc2UgbXVzdCBnZW5lcmF0 ZSByZWFsICppbmZvcm1hdGlvbiogdGhhdCBjb21tdW5pY2F0aW5nIHBhcnRpZXMgdW5kZXJzdGFu ZCkgYnV0IGl0IGZvciBzdXJlIGhhcyB0aGUgQ0JSIGJlaGF2aW91ciBvZiBhIHN0cmVhbS4gDQoJ ICANCglCVFcgdGhlIHJlYXNvbiB0aGUgY28tY3MgbW9kZSBoYXMgYmVlbiBlbmR1cmluZ2x5IHN1 Y2Nlc3NmdWwgYXMgYSB0cmFuc3BvcnQgbmV0d29yayBpcyBiZWNhdXNlIGl0IHByb3ZpZGVzICp0 cmFuc3BhcmVuY3kqIHRvIGFsbCBjbGllbnRzICh3aGljaCBpcyBleGFjdGx5IHRoZSBzaW1pbGFy IGJlaGF2aW91ciBvZiBhIHN0cmVhbSBhcyB5b3Ugbm90ZSksIGllIA0KCS0gICAgYWxsIGNsaWVu dCBiaXRzIHRyZWF0ZWQgZXF1YWxseSAoYSByZWFsbHkga2V5IHBvaW50IHRoaXMsIGFzIHRoaXMg bWVhbnMgaXQgcHJvdmlkZXMgZXF1YWwgJ2ltcG9ydGFuY2UnIHRyZWF0bWVudCBvZiB0aGUgdWx0 aW1hdGUgaGlnaGVyIGxldmVsIChhbmQgdW5zZWVuL3Vua25vd24gYnkgdGhlIGNvLWNzIHRyYW5z cG9ydCBuZXR3b3JrKSBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucykgDQoJLSAgICBj bGllbnQgYml0IG9yZGVyaW5nIGlzIHByZXNlcnZlZCANCgktICAgIGRvZXMgbm90IHRyeSBhbiBp bmZlciBtZWFuaW5nIG9mIGNsaWVudCBiaXRzIG5vciBjaGFuZ2UgdGhlbSANCgktICAgIGVuc3Vy ZXMgdGhlIHRyYWZmaWMgYmVoYXZpb3VyIG9mIGNsaWVudCBYIGNhbm5vdCBpbXBhY3QgdGhlIHBl cmZvcm1hbmNlIGV4cGVyaWVuY2VkIGJ5IHBhcnR5IFkuIA0KCSAgDQoJICANCglyZWdhcmRzLCBO ZWlsIA0KCQ0KCVJlZ2FyZHMsIA0KCVN1aHVpLiANCgkNCgkNCjxuZWlsLjIuaGFycmlzb25AYnQu Y29tPiANCg0KMjAwOS0wNC0yOSAxNDo0MCANCg0KDQoNCuaUtuS7tuS6ug0KPHN1Lmh1aUB6dGUu Y29tLmNuPiANCuaKhOmAgQ0KPGFkcmlhbkBvbGRkb2cuY28udWs+LCA8YmVuamFtaW4ubml2ZW4t amVua2luc0BidC5jb20+LCA8aGhlbHZvb3J0QGNoZWxsby5ubD4sIDxtcGxzLXRwQGlldGYub3Jn PiwgPG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZz4gDQrkuLvpopgNClJFOiBSZTogW21wbHMtdHBd IEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggICAg ICAgIHJlcXVpcmVtZW50cykNCg0KDQoJDQoNCg0KCQ0KCQ0KCQ0KCVRoYW5rcyBTaHVodWksIA0K CSANCglEbyBub3QgY29uZnVzZSBwaHlzaWNhbCBpbnRlcmNvbm5lY3Qgd2l0aCBFLU5OSS4uLi4u SSdsbCBjb21lIGJhY2sgb24gdGhpcyBzaG9ydGx5IHdoZW4gZGlzY3Vzc2luZyB0aGUgYm90dG9t LW9mLXN0YWNrIHNlY3Rpb24gbGF5ZXIuIA0KCSANCglUaGUgZmlyc3QgdGhpbmcgdG8gdW5kZXJz dGFuZCBpcyB0aGF0ICphbGwqIG5ldHdvcmtzIGFyZSB0aGVyZSB0byB1bHRpbWF0ZWx5IHN1cHBv cnQgb25lIHB1cnBvc2UuLi4uLmFuZCB0aGF0IGlzIHRvIGFsbG93IGNvbW11bmljYXRpb25zIGJl dHdlZW4gcGFydGllcyB0aGF0IGFyZSAqZXh0ZXJuYWwqIHRvIHRoZSBuZXR3b3Jrcy4gIFNvIGV2 ZXJ5dGhpbmcgd2UgZG8gaW4gbmV0d29ya2luZyBpcyB0aGVyZSB0byB1bHRpbWF0ZWx5IHN1cHBv cnQgdGhpcyBvYmplY3RpdmUuICBXaGF0IHRoaXMgbWVhbnMgaXMgdGhhdCB0aGUgRFAgb2Ygc29t ZSBuZXR3b3JrICh3aGF0IEkgY2FsbCB0aGUgdG9wLW9mLXN0YWNrIG5ldHdvcmspIE1VU1QgYmUg cHJvdmlkaW5nIGFkYXB0YXRpb24gZnVuY3Rpb25zIGZvciB0aGVzZSBleHRlcm5hbCBhcHBsaWNh dGlvbnMuLi4uLi4uYW5kIHRoZXNlIGNhbiBnZW5lcmljYWxseSBiZSBjbGFzc2lmaWVkIGFzIG1l c3NhZ2VzLCBmaWxlcyBhbmQgc3RyZWFtcy4gDQoJIA0KCVdlIGNhbiBzZWUgdGhhdCBJUCBpcyBh IHRvcC1vZi1zdGFjayBuZXR3b3JrIGFzIGl0IGhhcyBVRFAvVENQL1JUUCAoZm9yIGV4YW1wbGUp IGFkYXB0YXRpb25zLiAgQVRNIHdhcyBhbHNvIG9uY2UgKH45MHMpIGludGVuZGVkIHRvIGJlIGEg dG9wLW9mLXN0YWNrIG5ldHdvcmsgYW5kIGl0IGhhZCBpdHMgb3duIGFwcGxpY2F0aW9uIGFkYXB0 YXRpb25zIGluIHRoZSBmb3JtIG9mIEFBTHMuICBBdCBvbmUgc3RhZ2UgdGhlcmUgd2VyZSA1IG9m IHRoZXNlLCBidXQgaW4gcHJhY3RpY2Ugb25seSBhIGNvdXBsZSB3ZXJlIHJlYWxseSBzdWNjZXNz ZnVsIGJlY2F1c2Ugb2YgdGhlIGdlbmVyaWMgbmF0dXJlIG9mIG1lc3NhZ2UvZmlsZS9zdHJlYW0g Y2xhc3NpZmljYXRpb24uICBUaGUgUFNUTiBpcyBhbHNvIHRvcC1vZi1zdGFjaywgYW5kIGl0cyBh cHBsaWNhdGlvbiBhZGFwdGF0aW9uIHdhcyBtYWlubHkgZm9yIHZvaWNlIChzdHJlYW0pIHN1cHBv cnQuIA0KCSANCglNb3N0IG90aGVyIG5ldHdvcmtzIGRvIG5vdCBoYXZlIHRoZXNlIGFwcGxpY2F0 aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zLi4uLnNvIHRoZXkgZG8gbm90IGRpcmVjdGx5IHN1cHBv cnQgYXBwbGljYXRpb25zLiAgV2hhdCB0aGlzIG1lYW5zIGluIHByYWN0aWNlIGlzIHRoYXQgdGhl c2UgbmV0d29ya3MgKGEgbGlzdCB3aGljaCBpbmNsdWRlcyBQREgsIFNESCwgT1ROLCBFdGhlcm5l dCwgTVBMUykgTVVTVCBjYXJyeSBhIGZ1cnRoZXIgbGF5ZXIgbmV0d29yayBhYm92ZSB0aGVtIHRo YXQgaXMgdG9wLW9mLXN0YWNrLi4uLmxpa2UgSVAuICBUaGVyZSBpcyBubyBjaG9pY2UgaW4gdGhl IG1hdHRlciBoZXJlLiAgU28gd2hpbHN0IHdlIG1pZ2h0IHNheSB0aGF0IGFuIE1QTFMgbmV0d29y ayBpcyBjYXJyeWluZyBhbiBFMSBQVyB0aGUgRTEgZW50aXR5IG11c3QgaW4gdHVybiBiZSBjYXJy eWluZyBzb21lIG90aGVyIHRvcC1vZi1zdGFjayBuZXR3b3JrIChsaWtlIElQIG9yIFBTVE4pLCBl bHNlIGl0IGlzIHNlcnZpbmcgbm8gdWx0aW1hdGUgcHVycG9zZS4gDQoJIA0KCU5vdyBpbiBvcmRl ciB0byB0cmFuc21pdCBpbmZvcm1hdGlvbiBvdmVyIGdlb2dyYXBoaWMgZGlzdGFuY2Ugd2UgbXVz dCBtb2R1bGF0ZSBhbiBFTSB3YXZlIG9uIHNvbWUgbWV0YWxsaWMvb3B0aWNhbC9yYWRpbyBtZWRp YS4uLi50aGlzIGlzIHRoZSBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci4gIFRoZXNlIGFy ZSBoaWdoIGJpdCByYXRlIHRyYW5zcG9ydCBwaXBlcyB3aG9zZSBmdW5jdGlvbiBpcyB0byBwcm92 aWRlIHRyYW5zcGFyZW50ICh3aGljaCBJIGhhdmUgZGVmaW5lZCBwcmV2aW91c2x5KSB0cmFuc3Bv cnQgdG8gd2hhdGV2ZXIgY2xpZW50IGxheWVycyBuZXR3b3JrcyBzaXQgYWJvdmUgdGhlbS4uLi5h bmQgd2hlcmUsIGFzIEkgbm90ZWQgYWJvdmUsIHRoZXJlIE1VU1QgYmUgYSB0b3Atb2Ytc3RhY2sg bmV0d29yayBwcmVzZW50IGFzIHRoZSB1bHRpbWF0ZSBsYXllciBuZXR3b3JrIGNsaWVudCBlbHNl IHRoZXJlIGlzIG5vdCBleHRlcm5hbCBwYXJ0eSBjb21tdW5pY2F0aW9uIHBvc3NpYmxlLiANCgkg DQoJU28gd2hlbiB3ZSBjb25uZWN0IHRvZ2V0aGVyIDIgdG9wLW9mLXN0YWNrIG5ldHdvcmtzIHdl IGRvIHNvIGF0IGEgc2VjdGlvbiBsYXllciB3aGljaCBpcyBpbnZhcmlhYmx5IGNhcnJ5aW5nIGEg dmVyeSBsYXJnZSBhZ2dyZWdhdGUgb2YgYXBwbGljYXRpb25zLi4uLi5hbmQgb2YgY291cnNlIHRo ZXNlIGFwcGxpY2F0aW9ucyBjYW4gYmUgYSB0aW1lIHZhcnlpbmcgbWl4IG9mIG1lc3NhZ2UvZmls ZS9zdHJlYW0gY2FzZXMgd2l0aCBhIHNldCBvZiB1bmtub3duICh0byB0aGUgc2VjdGlvbiBsYXll cikgaW1wb3J0YW5jZSdzIChlcmdvIHdoeSB0cmFuc3BhcmVuY3kgaXMgYW4gZXNzZW50aWFsIHJl cXVpcmVtZW50IGluIHRyYW5zcG9ydCBuZXR3b3JrcykuIA0KCSANCglUaGUgcmVhbCBFLU5OSXMg KHdoaWNoIGNvbnNpZGVycyBib3RoIERQIGFuZCBDUCBjb21wb25lbnRzLi4uLndlIG5ldmVyIHVz dWFsbHkgcGVlciB0aGUgTVAsIGFuZCB3ZSByZXN0cmljdCB0aGUgc2NvcGUgb2YgdGhlIENQKSBl eGlzdCBpbiB0aGUgdG9wLW9mLXN0YWNrIGxheWVyIG5ldHdvcmsuICBUaGUgc2VjdGlvbiBsYXll ciBpbnRlcmNvbm5lY3QgaXMgYSBkdW1iIERQIHBpcGUuLi5pdCBqdXN0IHNoaWZ0cyBiaXRzIHRy YW5zcGFyZW50bHkgYW5kIG1haW50YWlucyB0aGVpciBvcmRlcmluZy4gIFRoZXJlIGlzIG5vIGNv bmNlcHQgb2YgQ1AgKG9yIE1QKSBwZWVyaW5nIG9uIHRoZXNlIGJvdHRvbS1vZi1zdGFjayBzZWN0 aW9uIGxheWVyIGludGVyY29ubmVjdHMuIA0KCUFzaWRlPT4gSW4gc29tZSBjb3VudHJpZXMgdGhl c2UgaW50ZXJjb25uZWN0cyBoYXZlIHRvIGJlIGNhcmVmdWxseSBzcGVjaWZpZWQgaW4gb3JkZXIg dG8gZGlzdGluZ3Vpc2ggcmVndWxhdGVkIGFuZCB1bnJlZ3VsYXRlZCBzZXJ2aWNlcy4uLi4uc28g dGhlcmUgYXJlIGltcG9ydGFudCBsZWdhbC9jb21tZXJjaWFsIGNvbnNpZGVyYXRpb25zIGhlcmUs IGl0IGlzIG5vdCBzaW1wbHkgYSB0ZWNobmljYWwgaXNzdWUuIA0KCSANCglXZSBjYW4gb2YgY291 cnNlIGNyZWF0ZSBFLU5OSXMgaW4gbm9uIHRvcC1vZi1zdGFjayBsYXllciBuZXR3b3JrcyAod2Ug Y2FuIGRvIG1hbnkgdGhpbmdzIHRoYXQgYXJlIG5vdCB1c2VmdWwpLiAgU28gbGV0cyBhc3N1bWUg d2UgZG8gdGhpcy4uLi4uYW5kIGxldHMgYXNzdW1lIHdlIGNob29zZSBNUExTIHNpbmNlIHlvdSBt ZW50aW9uIHRoaXMgaW4gdGhlIG1haWwgYmVsb3cuIA0KCSANCglOb3cgaG93IGRvIGV4dGVybmFs IHBhcnRpZXMgd2hvIHdpc2ggdG8gY29tbXVuaWNhdGUgaW50ZXJmYWNlIHdpdGggdGhpcyBNUExT IG5ldHdvcms/ICBDYW4geW91IHN1cHBvcnQgYWxsIHR5cGVzIG9mIG1lc3NhZ2UvZmlsZS9zdHJl YW0gYXBwbGljYXRpb25zICpkaXJlY3RseSogaW50byBNUExTPyAgSW4gcHJpbmNpcGxlIHlvdSBj b3VsZCBpZiB5b3UgYWxsb3dlZCBNUExTIHRvIGhhdmUgZW5kIHN5c3RlbSBhcHBsaWNhdGlvbiBh ZGFwdGF0aW9ucyBzdWNoIGFzIFVEUC9UQ1AvUlRQIG9yIHRoZSBsaWtlLiAgQnV0IHRoZXNlIGRv bid0IGV4aXN0IHRvZGF5LCBhbmQgaW4gdGhlIG1vc3QgdXN1YWwgY2FzZSB0aGUgTVBMUyBuZXR3 b3JrIHdpbGwgY2FycnkgYW4gSVAgbGF5ZXIgbmV0d29yayBiZWNhdXNlIHRoaXMgY2FuIHN1cHBv cnQgdGhlIG1lc3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zLiANCgkgDQoJV2UgY2FuIGdv IHRocm91Z2ggZXhhY3RseSB0aGUgc2FtZSBhbmFseXNpcyB3aXRoIGFueSBuZXR3b3JrIHRoYXQg aXMgbm90IHRvcC1vZi1zdGFjaywgZWcgRXRoZXJuZXQuICBBbmQgd2hlbiB5b3UgZG8gdGhpcyB3 aGF0IHlvdSByZWFsaXNlIGlzIHRoYXQgYWx0aG91Z2ggd2UgY2FuIGNyZWF0ZSBwZWVyIGludGVy d29ya2luZyBvZiBNUExTIChvciB3aGF0ZXZlcikgdGhpcyBoYXMgbm90IHJlYWxseSBoZWxwZWQg c2luY2Ugd2UgbWlnaHQgYXMgd2VsbCBoYXZlIGp1c3QgdGVybWluYXRlZCB0aGUgTVBMUyBuZXR3 b3JrIGFuZCBwYXNzZWQgdGhlIElQIGxheWVyIGFjcm9zcy4gDQoJIA0KCU5vdyB0aGUgYWJvdmUg YmVjb21lcyBldmVuIG1vcmUgc3RyaWtpbmcgaW4gaXRzIGltcG9ydGFuY2UgaWYgeW91IGNvbnNp ZGVyIHBlZXIgaW50ZXJ3b3JraW5nIG9mIDIgZGlmZmVyZW50IG5vbiB0b3Atb2Ytc3RhY2sgbmV0 d29ya3MuLi4ubGV0cyBwaWNrIE1QTFMgYW5kIEV0aGVybmV0IGJlY2F1c2UgdGhhdCBpcyB3aGF0 IGlzIG9mdGVuIG1lbnRpb25lZC4gICANCgkgDQoJV2hhdCB3ZSBoYXZlIHRvIGRvIG5vdyBhdCB0 aGUgRS1OTklzIGJldHdlZW4gRXRoZXJuZXQgYW5kIE1QTFMgaXMgZ28gdGhyb3VnaCBlYWNoIERQ IGFuZCBDUCBjb21wb25lbnQgYW5kIGRvIGEgJ3Byb3RvY29sIGNvbnZlcnNpb24nIGV4ZXJjaXNl IHdoZXJlIHJlcXVpcmVkLi4uLi4uYW5kIHRoZSBmaXJzdCBwcm9ibGVtIHlvdSB3aWxsIGVuY291 bnRlciBpcyB0aGF0IHRoZXJlIHdpbGwgYmUgbG90cyBvZiBmdW5jdGlvbmFsIG1pc21hdGNoLiAg TW9yZW92ZXIgaWYgb25lIG9yIGJvdGggb2YgdGhlIG5ldHdvcmtzIGNhbiBzdXBwb3J0IG11bHRp cGxlIENQIHR5cGVzIGxpa2UgTVBMUyBjYW4sIGVnIFJTVlAtVEUgc2lnbmFsbGluZywgTERQIHNp Z25hbGxpbmcsIEJHUDQgJ3NpZ25hbGxpbmcnLCBPU1BGIHJvdXRpbmcsIElTLUlTIHJvdXRpbmcu Li4uLmFuZCBJIGNvdWxkIGxpc3Qgc2ltaWxhciBmb3IgRXRoZXJuZXQuLi4uLnlvdSBhcmUgZ29p bmcgdG8gaGF2ZSB0byBjb25zaWRlciBlYWNoIHBhaXJpbmcgY2FzZSBpbiB0dXJuLiAgQSBsb3Qg b2Ygd29yay4gDQoJIA0KCUFuZCB3aGVuIHlvdSBoYXZlIGRvbmUgYWxsIHRoaXMgeW91IGFzayB0 aGUgcXVlc3Rpb24gJ3doYXQgaXMgaXQgdGhhdCBjYXJyaWVzIHRoZSByZWFsIGV4dGVybmFsIG1l c3NhZ2UvZmlsZS9zdHJlYW0gYXBwbGljYXRpb25zIGluIHRoZSBEUCBoZXJlPycuLi4uLi4uYW5k IG5vdyB5b3UgZmluZCBubyBuYXRpdmUgc3VwcG9ydCBmb3IgdGhlc2UgaW4gTVBMUyBvciBFdGhl cm5ldCwgYnV0IHdoYXQgd2UgZG8gZmluZCBpcyB0aGF0IGJvdGggb2YgdGhlbSBhcmUgY2Fycnlp bmcgSVAgYmVjYXVzZSB0aGlzIGRvZXMgc3VwcG9ydCB0aGUgZXh0ZXJuYWwgYXBwbGljYXRpb25z LiAgTm93IGF0IHRoaXMgcG9pbnQgd2UgaGF2ZSBkaXNjb3ZlcmVkIHdoYXQgaXMgdGhlIGNvbW1v biB0aGluZyBiZXR3ZWVuIE1QTFMgYW5kIEV0aGVybmV0Li4uLml0IGlzIHRoZSB0b3Atb2Ytc3Rh Y2sgSVAgbGF5ZXIgbmV0d29yay4gIEFuZCBzbyB3ZSB1bHRpbWF0ZWx5IHJlYWxpc2Ugd2UgY291 bGQgaGF2ZSBzYXZlIG91cnNlbHZlcyBhIGxvYWQgb2YgdW5uZWNlc3Nhcnkgd29yayBieSBzaW1w bHkgdGVybWluYXRpbmcgdGhlIE1QTFMgYW5kIEV0aGVybmV0IGxheWVyIG5ldHdvcmsgYXQgdGhl IGludGVyd29ya2luZyBwb2ludCBhbmQganVzdCBwYXNzZWQgdGhlIElQIGxheWVyIG5ldHdvcmsg YWNyb3NzLiANCgkgDQoJU29ycnkgSSd2ZSBoYWQgdG8gZ28gdGhyb3VnaCBhbGwgdGhpcyB5ZXQg YWdhaW4gKGVzcCBmb3IgYWxsIHRoZSBmb2xrcyB0aGF0IGhhdmUgYWxyZWFkeSB1bmRlcnN0b29k IHRoZSBwb2ludCkgYnV0IEkgZG8gaG9wZSBpdHMgY2xlYXIgbm93IGFuZCB3ZSBjYW4gcHV0IHRo aXMgaXNzdWUgdG8gYmVkLiANCgkgDQoJcmVnYXJkcywgTmVpbCANCgkNCgkNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCglGcm9tOiBzdS5odWlAenRlLmNvbS5jbiBbbWFpbHRv OnN1Lmh1aUB6dGUuY29tLmNuXSANCglTZW50OiAyOSBBcHJpbCAyMDA5IDAzOjIyDQoJVG86IEhh cnJpc29uLE4sTmVpbCxDWE0gUg0KCUNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBOaXZlbi1qZW5r aW5zLEIsQmVuLERNRiBSOyBoaGVsdm9vcnRAY2hlbGxvLm5sOyBtcGxzLXRwQGlldGYub3JnOyBt cGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcNCglTdWJqZWN0OiDnrZTlpI06IFJlOiBbbXBscy10cF0g QUlTL0ZESSAod2FzIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCByZXF1 aXJlbWVudHMpDQoJDQoJDQoJSGkgTmVpbCwgDQoJDQoJ4oCYaXQgaXMgcXVpdGUgY2xlYXIgZnJv bSBhIHNpbXBsZSB0ZWNobmljYWwgYW5hbHlzaXMgdGhhdCBhbnkgbm9uIHRvcC1vZi1zdGFjayBu ZXR3b3JrIGhhcyBubyBuZWVkIGZvciBFLU5OSSBwZWVyLXBhcnRpdGlvbiB3b3JraW5nIGJldHdl ZW4gZGlmZmVyZW50IG9wZXJhdGluZyBwYXJ0aWVzLuKAmSANCgkNCglJIGNhbm5vdCBhZ3JlZSB0 aGlzIHN0YXRlbWVudC4gDQoJRm9yIGV4YW1wbGUsIHRoZXJlIGFyZSB0d28gSVAgbmV0d29ya3Mg YmVsb25naW5nIHRvIHR3byBvcGVyYXRvcnMsIGEgRTEgaXMgdHJhbnNwb3J0ZWQgZnJvbSBBIG5l dHdvcmsgdG8gQiBuZXR3b3JrIChlLmcuIEUxb3ZlclBXb3ZlcklQICksIElQIHBhY2tldChub3Qg RTEpIHBhc3MgYWNyb3NzIGZvcm0gQSB0byBCIGF0IGJvcmRlciBub2RlLCBzbyB0aGVyZSBpcyBh IEUtTk5JIGJldHdlZW4gdGhlc2UgIHR3byBJUCBuZXR3b3JrLiBJbiB0aGlzIGNhc2UsIGlzIElQ IGEgdG9wLW9mLXN0YWNrIG5ldHdvcms/IA0KCU5vdyBsZXQgdXMgcmVwbGFjZSBJUCBuZXR3b3Jr cyBieSBNUExTLVRQIG5ldHdvcmtzIChlLmcuIEUxb3ZlclBXb3Zlck1QTC1UUCksIE1QTFMtVFAg bmV0d29yayBpcyBhdCBzYW1lIHBvc2l0aW9uIGluIHRoZSBzdGFjayBhcyBJUCBuZXR3b3JrIGlz LCB3aHkgY2FuIElQIG5ldHdvcmsgaGF2ZSBFLU5OSSBidXQgTVBMUy1UUCBjYW5ub3Q/IA0KCQ0K CVJlZ2FyZCwgDQoJU3VodWkgDQoJDQo8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbT4gDQrlj5Hku7bk uro6ICBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgDQoNCjIwMDktMDQtMjggMTQ6NDMgDQoNCg0K DQrmlLbku7bkuroNCjxoaGVsdm9vcnRAY2hlbGxvLm5sPiwgPGFkcmlhbkBvbGRkb2cuY28udWs+ LCA8YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20+IA0K5oqE6YCBDQptcGxzLXRwQGlldGYu b3JnIA0K5Li76aKYDQpSZTogW21wbHMtdHBdIEFJUy9GREkgKHdhcyBBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggICAgICAgIHJlcXVpcmVtZW50cykNCg0KDQoNCg0KCQ0K DQoNCgkNCgkNCgkNCgkNCglIdXViIHdyb3RlIDI3IEFwcmlsIDIwMDkgMjI6MjcNCgk+IA0KCT4g SGkgQWRyaWFuLA0KCT4gDQoJPiBZb3Ugd3JvdGU6DQoJPiANCgk+ID4gSXNuJ3QgdGhlIHNvbHV0 aW9uIGhlcmUgdGhlIHNhbWUgYXMgdGhlIG9uZSBJIHByb3Bvc2VkIGZvciAiVENNIj8NCgk+IA0K CT4gSW5kZWVkLCBhbmQgdGhhdCB3ZSBkbyBub3QgaGF2ZSB0byBhcm91bmQgaW4gY2lyY2xlcyBh Ym91dCBUQ00uDQoJPiANCgk+IEhvdyBhYm91dDoNCgk+IHRoZSByZXF1aXJlbWVudCBpcyB0aGF0 IGEgc2VydmVyIGxheWVyIHNoYWxsIGluZm9ybSBpdHMgY2xpZW50cw0KCT4gdGhhdCBpdCBoYXMg ZGV0ZWN0ZWQgYSBzZXJ2aWNlIGludGVydXB0aW9uLCB0aGlzIHRvIGVuc3VyZSB0aGF0DQoJPiB0 aGUgY2xpZW50cyBjYW4gaW5oaWJpdCAodW5uZWNlc3NhcnkpIGFsYXJtcy4NCgkNCglOSD0+IFRo aXMgb25seSBhcHBsaWVzIGlmIHRoZSBjbGllbnQvc2VydmVyIGJpbmRpbmcgaXMgZml4ZWQuICBB bmQgb2YNCgljb3Vyc2Ugd2F5IGJhY2sgaW4gdGhlIDcwcyB3aGVuIGJpbmFyeSBhbGwgMXMgcG9w cGVkIG91dCBvZiB0aGUgZmFpbGVkDQoJVFRMIGxvZ2ljIGludG8gdGhlIFBESCB0cmFuc3BvcnQg aGllcmFyY2h5IHRoaXMgd2FzIHRydWUuICBBbHNvOiBubw0KCWxhYmVscyBoZXJlIGFuZCBubyBj bGllbnQgdHJhZmZpYyB1bml0cyB0byBjcmVhdGUuICAgDQoJDQoJV2hlcmUgdGhlIGNsaWVudCBj YW4gZHluYW1pY2FsbHkgYmUgcmUtcm91dGVkIGluIHJlc3BvbnNlIHRvIGEgc2VydmVyDQoJZmFp bHVyZSB0aGUgcHJvcG9zZWQgdGV4dCBpcyBub3QgdmFsaWQuICBJdCBpcyBhbHNvIG5vdCBuZWNl c3NhcnkgdGhhdA0KCXRoZSBzZXJ2ZXIgaGFzIHRvIGtlZXAgdHJhY2sgb2Ygd2hlcmUgaXRzIGNs aWVudCB0cmFmZmljIHJvdXRpbmdzIGhhdmUNCgltb3ZlZCB0by4gIEZvciBleGFtcGxlLCBpZiBJ IGNyZWF0ZSB0aGUgdG9wb2xvZ3kgb2YgYW4gSVAgbGF5ZXIgbmV0d29yaw0KCXdpdGggbGlua3Mg cHJvdmlkZWQgYnkgU0RILCBFdGhlcm5ldCwgQVRNLCBPVE4sIGV0YyBzZXJ2ZXJzLCBhbmQgZWFj aCBvZg0KCXRoZXNlIHNlcnZlciBsaW5rcyBpcyBwcm92aWRlZCBieSBhIGRpZmZlcmVudCBvcGVy YXRvciwgdGhlbiB3aHkgc2hvdWxkDQoJdGhlIHNlcnZlcnMgbmVlZCBoYXZlIGtub3dsZWRnZSBv ZiB3aGVyZSB0aGUgSVAgZmxvd3MgaGF2ZSBtb3ZlZCB0byBpbg0KCXJlc3BvbnNlIHRvIGEgc2Vy dmVyIGxheWVyIGZhaWx1cmUgd2hlbiB0aGUgbmV3IHJvdXRlcyBoYXZlIGJlZW4NCgljYWxjdWxh dGVkIGJ5IHRoZSBJR1AgaW4gdGhlIElQIGxheWVyIG5ldHdvcms/ICBJIGNhbiBhcHBseSB0aGUg c2FtZQ0KCWxvZ2ljIHRvIGFuIFNWQy1iYXNlZCBjby1wcy9jby1jcyBtb2RlIGNsaWVudC4uLi5p bmRlZWQgdGhlIGNvLWNzIG1vZGUNCglQU1ROIGlzIGxpa2UgdGhpcy4NCgkNCglUaGVzZSBvYnNl cnZhdGlvbnMgbWFrZSBpdCBxdWl0ZSBjbGVhciB0byBtZSBhdCBsZWFzdCB0aGF0IGp1c3QgY29w eWluZw0KCXRoZSBBSVMgYmVoYXZpb3VyIG9mIHRoZSBvbGQgdHJhbnNwb3J0IGhpZXJhcmNoaWVz IHRoYXQgaGFkIGZpeGVkDQoJY2xpZW50L3NlcnZlciByZWxhdGlvbnNoaXBzIGlzIG5vdCBhIHNl bnNpYmxlIHRoaW5nIHRvIGRvLg0KCQ0KCUlNTyB0aGUgb25seSBlc3NlbnRpYWwgRFAgT0FNIHJl cXVpcmVtZW50IGlzIHRoYXQgZWFjaCBsYXllciBuZXR3b3JrDQoJc2hvdWxkIGJlIHNlbGYtc3Vm ZmljaWVudCB3cnQgT0FNIGFuZCBub3QgcmVseSBvbiBhbnkgc2VydmVyIGxheWVyDQoJcHJpbWl0 aXZlcyBiZWluZyBwYXNzZWQgdXB3YXJkcy4NCgkNCglNb3Jlb3ZlciwgaXQgc2hvdWxkIGFsc28g YmUgbm90ZWQgdGhhdCAoaSkgdGhlIGRlZmVjdHMgdGhhdCBjYW4gb2NjdXIgaW4NCgllYWNoIG9m IHRoZSAzIG5ldHdvcmsgbW9kZXMgYXJlIG5vdCB0aGUgc2FtZSBhbmQgKGlpKSB0aGVpciBPQU0N CglyZXF1aXJlbWVudHMgYXJlIG5vdCBpZGVudGljYWxseSB0aGUgc2FtZS4gU28gdGhlIE9BTSB0 aGF0IGFwcGxpZXMgdG8NCgl0aGUgY2wtcHMgbW9kZSAoZWcgSVApIGlzIG5vdCB0aGUgc2FtZSBh cyB0aGUgT0FNIHRoYXQgYXBwbGllcyB0byB0aGUNCgljby1wcyBtb2RlIChlZyBNUExTLVRQKSBh bmQgbmVpdGhlciBvZiB0aGVzZSBpcyBpZGVudGljYWxseSB0aGUgc2FtZSBhcw0KCXRoZSBPQU0g dGhhdCBhcHBsaWVzIHRvIHRoZSBjby1jcyBtb2RlIChlZyBTREgpLg0KCQ0KCU5vdGUgLSBUaGUg b25seSBwb2ludCBiZWluZyBjb25zaWRlcmVkIGhlcmUgaXMgdGhlIHJlYWwgY2xpZW50IGFuZA0K CXNlcnZlciB0cmFmZmljIHJlbGF0aW9uc2hpcC4gIFRoZSBjcmVhdGlvbiBvZiBhIGhpZXJhcmNo eSBvZiBUQ00NCglzdWJsYXllcnMgaXMgYSBzZXBhcmF0ZSB0b3BpYy4gIEZ1cnRoZXIsIGl0IGlz IHF1aXRlIGNsZWFyIGZyb20gYSBzaW1wbGUNCgl0ZWNobmljYWwgYW5hbHlzaXMgdGhhdCBhbnkg bm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIGhhcyBubyBuZWVkIGZvcg0KCUUtTk5JIHBlZXItcGFy dGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0aW5nIHBhcnRpZXMuICBTbw0K CXRoaXMgaXMgYWxzbyBhIHNlcGFyYXRlIGlzc3VlLiAgSG93ZXZlciwgSSBwcm9wb3NlIHRoYXQg dGhpcyBsYXR0ZXINCglwb2ludCBiZSBjYXB0dXJlZCBpbiB0aGUgTVBMUy1UUCByZXF1aXJlbWVu dHMgZHJhZnQgZHVlIHRvIGl0cw0KCXN0YW5kLWFsb25lIGFuZCBnZW5lcmljIGltcG9ydGFuY2Us IGllIHRoaXMgYXBwbGllcyB0byBtb3JlIHRoYW4ganVzdCBEUA0KCU9BTS4gIEJlbiBjYW4geW91 IHBsZWFzZSBjb25zaWRlciB0aGlzIHBvaW50IGFzL3doZW4gdGhlIE1QTFMtVFANCglyZXF1aXJl bWVudHMgZHJhZnQgaXMgdXBkYXRlZC4NCgkNCglyZWdhcmRzLCBOZWlsDQoJDQoJPiBDaGVlcnMs IEh1dWIuDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CgltcGxzLXRwIG1haWxpbmcgbGlzdA0KCW1wbHMtdHBAaWV0Zi5vcmcNCglodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N CglUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQoJDQoJDQoJLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgla VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQoJVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KCVRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoJWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVu dGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNl Y3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KCVRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBh ZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCglU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS4NCg0K ------_=_NextPart_001_01C9C95C.D4138268 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03MTgyNjM4MDUtMzAwNDIwMDk+PEZPTlQgDQpmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5UaGFua3MgU3VodWk8L0ZPTlQ+ PC9TUEFOPjwvRElWPjxCUj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjODAwMDAwIDJweCBzb2xp ZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVy IGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICA8SFIgdGFiSW5kZXg9LTE+DQogIDxG T05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gc3UuaHVpQHp0ZS5jb20uY24gDQog IFttYWlsdG86c3UuaHVpQHp0ZS5jb20uY25dIDxCUj48Qj5TZW50OjwvQj4gMzAgQXByaWwgMjAw OSAwMzowMDxCUj48Qj5Ubzo8L0I+IA0KICBIYXJyaXNvbixOLE5laWwsQ1hNIFI8QlI+PEI+Q2M6 PC9CPiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyANCiAgTml2ZW4tamVua2lucyxCLEJlbixETUYgUjsg aGhlbHZvb3J0QGNoZWxsby5ubDsgbXBscy10cEBpZXRmLm9yZzsgDQogIG1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4g562U5aSNOiBSRTogUkU6IFJlOiBbbXBscy10 cF0gQUlTL0ZESSANCiAgKHdhcyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBh dGggDQpyZXF1aXJlbWVudHMpPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+PC9ESVY+DQog IDxESVY+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+SGkgTmVpbCw8L0ZPTlQ+IDxC Uj48QlI+PEZPTlQgDQogIGZhY2U9c2Fucy1zZXJpZj48Rk9OVCBzaXplPTI+SSB0aGluayBJIG1p c3VuZGVyc3Rvb2QgdGhlIHdvcmRzIOKAmHRvcC1vZi1zdGFjayANCiAgbmV0d29ya+KAmSAsIEl0 IGRvZXNu4oCZdCBtZWFuIGEgbmV0d29yayBpcyBhY3R1YWxseSBhdCB0b3Agb2YgdGhlIHN0YWNr LCBzbyBubyANCiAgbWF0dGVyIHdoYXQgbGF5ZXIgSVAgbmV0d29yayBpcyBhY3R1YWxseSBhdCwg SVAgbmV0d29yayBpcyBhbHdheXMgYSANCiAg4oCYdG9wLW9mLXN0YWNrIG5ldHdvcmvigJkgYmVj YXVzZSBpdCBjYW4g4oCYc3VwcG9ydCBleHRlcm5hbCBtZXNzYWdlL2ZpbGUvc3RyZWFtIA0KICBh cHBsaWNhdGlvbnPigJkuIElzIG15IHVuZGVyc3RhbmRpbmcgcmlnaHQ/PFNQQU4gY2xhc3M9NzE4 MjYzODA1LTMwMDQyMDA5PjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAw MDAwPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9O VCBmYWNlPXNhbnMtc2VyaWY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTcxODI2MzgwNS0zMDA0 MjAwOT48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMD48L0ZPTlQ+ PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1zYW5z LXNlcmlmPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz03MTgyNjM4MDUtMzAwNDIwMDk+PEZPTlQg DQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDA+Tkg9Jmd0OyANCiAgWWVzLjwv Rk9OVD4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8U1BBTiANCiAgY2xhc3M9NzE4 MjYzODA1LTMwMDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAg DQogIHNpemU9Mj4mbmJzcDtUaGVyZSBpcyBwcm9iYWJseSBhIGJldHRlciB0ZXJtIGZvciBpdCwg YnV0IGl0IHdhcyB0aGUgZXhwcmVzc2lvbiANCiAgdGhhdCBmaXJzdCBjYW1lIHRvIG1pbmQgd2hl biBJIHdhbnRlZCBhIHNob3J0aGFuZCB3YXkgdG8gDQogIGRlZmluZTo8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxODI2MzgwNS0zMDA0MjAwOT48Rk9OVCBmYWNlPSJD b21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+LSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3RoZSBuZXR3b3JrIHRoYXQmbmJzcDtkaXJlY3RseSBzdXBwb3J0cyANCiAgZXh0ZXJu YWwgYXBwbGljYXRpb25zJm5ic3A7PC9GT05UPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNv bG9yPSM4MDAwMDAgDQogIHNpemU9Mj4tJm5ic3A7IHRvcC1vZi1zdGFjay48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxODI2MzgwNS0zMDA0MjAwOT48Rk9OVCBmYWNl PSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+LSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3RoZSAmbmJzcDtuZXR3b3JrIHRoYXQgbW9kdWxhdGVzIHRoZSBFTSB3YXZlIA0K ICBvbiBtZXRhbGxpYy9vcHRpY2FsL3JhZGlvIG1lZGlhIC0gYm90dG9tLW9mLXN0YWNrPC9GT05U PjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03MTgyNjM4MDUtMzAwNDIwMDk+PEZP TlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPjxTUEFOIGNs YXNzPTcxODI2MzgwNS0zMDA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0j ODAwMDAwIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KICA8RElWPjxTUEFOIGNsYXNzPTcxODI2MzgwNS0zMDA0MjAwOT48Rk9OVCBmYWNlPSJDb21p YyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9NzE4MjYzODA1 LTMwMDQyMDA5PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNp emU9Mj5Ob3RlJm5ic3A7LSBzb21lIG5ldHdvcmsgdGVjaG5vbG9naWVzIGNhbm5vdCBjdXJyZW50 bHkgZnVsZmlsIGVpdGhlciBvZiANCiAgdGhlc2Ugcm9sZXMuLi4uaW5kZWVkIE1QTFMgaXMgbGlr ZSANCiAgdGhpcy4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjxCUj48L0RJVj48L0ZPTlQ+PC9TUEFOPg0K ICA8RElWPjxTUEFOIGNsYXNzPTcxODI2MzgwNS0zMDA0MjAwOT48Rk9OVCBmYWNlPSJDb21pYyBT YW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+Qm90aCB0aGVzZSBuZXR3b3JrcyBtdXN0 IGJlIHByZXNlbnQgaW4gYWxsIHByYWN0aWNhbCBuZXR3b3JraW5nIA0KICBzaXR1YXRpb25zOjwv Rk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NzE4MjYzODA1LTMwMDQyMDA5 PjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj4tJm5i c3A7Jm5ic3A7Jm5ic3A7IGlmIHRoZSBmb3JtZXIgaXMgbm90IHByZXNlbnQgdGhlIG5ldHdvcmtp bmcgb2YgdGhlIA0KICBsb3dlciBsYXllcnMgaXMgc2VydmluZyBubyBwdXJwb3Nlczs8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxODI2MzgwNS0zMDA0MjAwOT48Rk9O VCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+LSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2lmIHRoZSBsYXR0ZXIgaXMgbm90IHByZXNlbnQgd2UgY2Fubm90IHNl bmQgDQogIGluZm9ybWF0aW9uIGFjcm9zcyBnZW9ncmFwaGljIGRpc3RhbmNlLi4uLi4uYW5kIGp1 c3QgYXMgSSBhbmQgRGVib3JhaCBoYXZlIA0KICByZXBlYXRlZGx5IHBvaW50ZWQgb3V0IHRoZSBt ZXJlIHRoYXQgdGhlcmUgaXMgcGh5c2ljYWwgaW50ZXJmYWNlL2Nvbm5lY3Rpb24gDQogIGhlcmUg ZG9lcyAqbm90KiBtZWFuIHRoaXMgaXMgYW4gRS1OTkkuJm5ic3A7PC9GT05UPjwvU1BBTj48L0RJ Vj4NCiAgPERJVj48U1BBTiBjbGFzcz03MTgyNjM4MDUtMzAwNDIwMDk+PEZPTlQgZmFjZT0iQ29t aWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NzE4MjYzODA1LTMwMDQyMDA5PjxGT05UIGZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQogIHNpemU9Mj5BbiBFLU5OSSBtdXN0IGNv bnNpZGVyIGFsbCBEUCBhbmQgQ1AgY29tcG9uZW50cyB0aGF0IGFyZSB1c2VkIGJ5IGFuIA0KICBv cGVyYXRpbmcgcGFydHkgaW4gdGhlaXIgb3duIGRvbWFpbiBmb3Igc29tZSBuZXR3b3JrIG1vZGUv dGVjaG5vbG9neSBYLi4uLi5zbyANCiAgdGhpcyBpcyBtdWNoIG1vcmUgdGhhbiBzaW1wbHkgT0FN LiZuYnNwOyBJbiBwYXJ0aWN1bGFyIGl0IG11c3QgY29uc2lkZXIgdGhlIERQIA0KICBpbnRlcndv cmtpbmcgb2YgdGhlIGVuZC1zeXN0ZW0gYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMg dGhhdCBzdXBwb3J0IA0KICBleHRlcm5hbCBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9u cywgYW5kIGlmIHRoZXNlIGFyZSAqbm90KiBwcmVzZW50IHRoZW4gDQogIG5ldHdvcmsgWCBNVVNU IGJlIHN1cHBvcnRpbmcgYSBoaWdoZXIgbGF5ZXIgbmV0d29yayBZIGJ5IGRlZmluaXRpb24uJm5i c3A7IFdlIA0KICB0aGVyZWZvcmUgb2JzZXJ2ZSB0aGF0IHBlZXItcGFydGl0aW9uIGludGVyd29y a2luZyBhdCBuZXR3b3JrIFggaXMgbm90IA0KICBuZWNlc3NhcnkuJm5ic3A7IE5ldHdvcmsgWCZu YnNwO2NhbiBiZSBmdWxseSB0ZXJtaW5hdGVkIGF0IHRoZSBpbnRlcndvcmtpbmcgDQogIHBvaW50 IGFuZCBuZXR3b3JrIFkgcGFzc2VkIHRyYW5zcGFyZW50bHkuJm5ic3A7IFRoZSBhYm92ZSBpcyBy ZWN1cnNpdmUgdXB3YXJkcyANCiAgdW50aWwgd2UgY29tZSB0byB0aGUgcmVhbCB0b3Atb2Ytc3Rh Y2sgbmV0d29yayBhbmQgaXQgaXMgaGVyZSB0aGF0IEUtTk5JcyBhcmUgDQogIGVzc2VudGlhbC4u Li4uYW5kIGluZGVlZCB0aGlzIGlzIGV4YWN0bHkgd2hhdCB3ZSBzZWUgZm9yIHRoZSBwdWJsaWMg bmV0d29ya3MgDQogIG9mIHRoZSBJbnRlcm5ldCBhbmQgdGhlIFBTVE4uPC9GT05UPjwvU1BBTj48 L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03MTgyNjM4MDUtMzAwNDIwMDk+PEZPTlQgZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAw MCBzaXplPTI+PC9GT05UPjxCUj48Rk9OVCANCiAgZmFjZT1zYW5zLXNlcmlmPjxGT05UIHNpemU9 Mj5CdXQgSSBzdGlsbCBjYW5ub3QgYWdyZWUgdGhlIGFzc2VydGlvbiB0aGF0IOKAmGFueSANCiAg bm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIGhhcyBubyBuZWVkIGZvciBFLU5OSSBwZWVyLXBhcnRp dGlvbiB3b3JraW5nIGJldHdlZW4gDQogIGRpZmZlcmVudCBvcGVyYXRpbmcgcGFydGllc+KAmS4g QXMgeW91IHNhaWQgU0RIIGlzIG5vdCBhIHRvcC1vZi1zdGFjayBuZXR3b3JrLCANCiAgYnV0IFZD NCBjb25uZWN0aW9ucyBjYW4gcGFzcyB0aHJvdWdoIG11bHRpIG9wZXJhdG9y4oCZcyBkb21haW5z LCBzbyB0aGUgDQogIGludGVyZmFjZSBiZXR3ZWVuIGRpZmZlcmVudCBkb21haW5zIGlzIEUtTk5J LiZuYnNwOzxTUEFOIA0KICBjbGFzcz03MTgyNjM4MDUtMzAwNDIwMDk+PEZPTlQgZmFjZT0iQ29t aWMgU2FucyBNUyIgDQogIGNvbG9yPSM4MDAwMDA+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+ PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9c2Fucy1zZXJpZj48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9NzE4MjYzODA1LTMwMDQyMDA5PjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5z IE1TIiBjb2xvcj0jODAwMDAwPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPXNhbnMtc2VyaWY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTcxODI2MzgwNS0zMDA0MjAwOT48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9 IzgwMDAwMD5OSD0mZ3Q7IE5vLCB0aGlzIGlzIG5vdCBjb3JyZWN0LiZuYnNwOyBXZSANCiAgY2Fu IG9mIGNvdXJzZSBjcmVhdGUgRS1OTklzIGZvciBhbnkgbmV0d29yay9tb2RlIHdlIGxpa2UsIGJ1 dCB3aGF0IEkgYW0gDQogIHNob3dpbmcgaXMgdGhhdCB0aGlzIGlzIG5vdCB0ZWNobmljYWxseSBu ZWNlc3NhcnkgZm9yIG5ldHdvcmtzIHRoYXQgYXJlIG5vdCANCiAgdG9wLW9mLXN0YWNrLiZuYnNw OyBJbiBmYWN0IGl0IGlzIGFjdHVhbGx5IG11Y2ggbW9yZSBzZXJpb3VzIHRoYW4gc2ltcGx5ICJu b3QgDQogIG5lY2Vzc2FyeSIsIGJlY2F1c2Ugd2hlbiB5b3UgY3JlYXRlIHN1Y2ggcGVlci1wYXJ0 aXRpb25zIGJldHdlZW4gZGlmZmVyZW50IA0KICBwYXJ0aWVzIHlvdSBhcmUgZm9yY2luZyB0aGVt IHRvIGV2b2x2ZSB0aGVpciBuZXR3b3JrcyAodGhhdCBoYXZlIHN1Y2ggcGVlciANCiAgcGFydGl0 aW9ucykgaW4gbG9jay1zdGVwIChhbmQgdGhlcmUgYXJlIGFsc28gcmVndWxhdG9yeSBmYWN0b3Jz IHRvIGNvbnNpZGVyIA0KICBoZXJlIC0gYWxzbyBzZWUgQXNpZGUgYmVsb3cpLiZuYnNwOyZuYnNw OyBGb3IgdGhlIHZhc3QgbWFqb3JpdHkgb2YgcHJhY3RpY2FsIA0KICBzaXR1YXRpb25zIGEgY2xp ZW50L3NlcnZlciByZWxhdGlvbnNoaXAgaXMgbW9yZSByZWxldmFudCwgc2FmZXImbmJzcDthbmQg DQogIGltcG9ydGFudC48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz03MTgyNjM4MDUt MzAwNDIwMDk+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDA+PC9G T05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 c2Fucy1zZXJpZj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9NzE4MjYzODA1LTMwMDQyMDA5PjxG T05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwPlRoaXMgc2l0dWF0aW9u IHdvdWxkIGJlIGV2ZW4gbW9yZSANCiAgdW5hY2NlcHRhYmxlIHNob3VsZCBzdWNoIHBlZXItcGFy dGl0aW9ucyBiZSBiZXR3ZWVuIGRpZmZlcmVudCANCiAgbW9kZXMvdGVjaG5vbG9naWVzLCBlZyBF dGhlcm5ldCBhbmQgTVBMUyBpbnRlcndvcmtpbmcuJm5ic3A7IFRoaXMgaXMgbW9zdCANCiAgZGVm aW5pdGVseSBub3QgYSBnb29kIGlkZWEgYW5kIHdlIGluIEJUIHdpbGwgbm90IHN1cHBvcnQgdGhp cy4gDQogIDwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPXNhbnMtc2VyaWY+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCAN CiAgc2l6ZT0yPjxTUEFOIGNsYXNzPTcxODI2MzgwNS0zMDA0MjAwOT48L1NQQU4+PC9GT05UPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPXNhbnMtc2VyaWY+PEZPTlQgZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAgc2l6ZT0yPjxTUEFOIGNsYXNzPTcx ODI2MzgwNS0zMDA0MjAwOT5Bc2lkZT0mZ3Q7IFRoaXMgZG9lcyBub3QgcHJldmVudCANCiAgb3Bl cmF0aW5nIHBhcnRpZXMgaGF2aW5nIHByaXZhdGUgYmlsYXRlcmFsIHBlZXItcGFydGl0aW9uIHJl bGF0aW9uc2hpcHMgaW4gDQogIHNvbWUgbm9uIHRvcC1vZi1zdGFjayBuZXR3b3JrIHRlY2hub2xv Z3kuJm5ic3A7Jm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhpcyB3b3VsZCANCiAgbmVlZCB0byBjb25z aWRlciBhbnkgbGVnYWwvY29tbWVyY2lhbCByZWd1bGF0b3J5IGZyYW1ld29yayB0aGF0IGlzIGlu IGZvcmNlIA0KICB3aGVyZSB0aGlzIGlzIGJlaW5nIGNvbnNpZGVyZWQuPC9TUEFOPjwvRk9OVD48 L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1zYW5zLXNlcmlmPjxGT05UIHNpemU9Mj48 U1BBTiBjbGFzcz03MTgyNjM4MDUtMzAwNDIwMDk+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMg TVMiIGNvbG9yPSM4MDAwMDA+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElW Pg0KICA8RElWPjxGT05UIGZhY2U9c2Fucy1zZXJpZj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9 NzE4MjYzODA1LTMwMDQyMDA5PjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9ydGYgZm9ybWF0IC0t Pg0KICA8UD48Qj48U1BBTiBsYW5nPWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPk5laWwg SGFycmlzb248QlI+PC9GT05UPjxGT05UIA0KICBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwMDAgc2l6 ZT0yPkNoaWVmIE5ldHdvcmsgT3BlcmF0aW9ucyBTdHJhdGVnaXN0PEJSPkJUIA0KICBJbm5vdmF0 ZTwvRk9OVD48QlI+PEJSPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDAwMCBzaXplPTI+VGVs OiArNDQgKDApIDEgDQogIDYwNCA4MjAgMDUyPEJSPkVtYWlsOiA8L0ZPTlQ+PC9TUEFOPjwvQj48 QSANCiAgaHJlZj0ibWFpbHRvOm5laWwuMi5oYXJyaXNvbkBidC5jb20iPjxCPjxTUEFOIGxhbmc9 ZW4tZ2I+PFU+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDAwMCBzaXplPTI+bmVpbC4y LmhhcnJpc29uQGJ0LmNvbTwvRk9OVD48L1U+PC9TUEFOPjwvQj48L0E+PEI+PFNQQU4gDQogIGxh bmc9ZW4tZ2I+PEJSPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDAwMCBzaXplPTI+V2ViOiA8 L0ZPTlQ+PC9TUEFOPjwvQj48QSANCiAgaHJlZj0iaHR0cDovL3d3dy5idC5jb20vIj48Qj48U1BB TiBsYW5nPWVuLWdiPjxVPjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwMDAgc2l6ZT0y Pnd3dy5idC5jb208L0ZPTlQ+PC9VPjwvU1BBTj48L0I+PC9BPjxCPjxTUEFOIA0KICBsYW5nPWVu LWdiPjwvU1BBTj48L0I+IDxCUj48U1BBTiBsYW5nPWVuLWdiPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0xPlRoaXMgZW1haWwgDQogIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUg cHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuPEJSPkl0J3MgDQogIG1lYW50IG9ubHkgZm9yIHRo ZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUg DQogIGludGVuZGVkPEJSPnJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcs IGRpc3RyaWJ1dGluZyBvciB1c2luZyANCiAgdGhpcyBpbmZvcm1hdGlvbjxCUj5pcyBwcm9oaWJp dGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgDQogIHBsZWFzZSBs ZXQgbWUga25vdyBpbW1lZGlhdGVseTxCUj5vbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92ZS4gVGhh bmsgeW91LjxCUj5XZSANCiAgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29y ZCB5b3VyIGVtYWlscy48L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4gDQogIGxhbmc9ZW4tZ2I+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTE+QnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgDQogIHBsYzxC Uj5SZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKPEJS PlJlZ2lzdGVyZWQgaW4gDQogIEVuZ2xhbmQgbm86IDE4MDAwMDA8L0ZPTlQ+PC9TUEFOPiA8L1A+ PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ29taWMgU2Fu cyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+PC9GT05UPjxCUj48Rk9OVCANCiAgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj5SZWdhcmRzLDwvRk9OVD4gPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiAN CiAgc2l6ZT0yPlN1aHVpLjwvRk9OVD4gPEJSPjxCUj48QlI+PEJSPjwvRElWPg0KICA8VEFCTEUg d2lkdGg9IjEwMCUiPg0KICAgIDxUQk9EWT4NCiAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgIDxU RCB3aWR0aD0iMjYlIj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQogICAgICAgIHNpemU9MT48Qj4m bHQ7bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZndDs8L0I+IDwvRk9OVD4NCiAgICAgICAgPFA+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4yMDA5LTA0LTI5IDE4OjIxPC9GT05UPiA8L1A+DQog ICAgICA8VEQgd2lkdGg9IjczJSI+DQogICAgICAgIDxUQUJMRSB3aWR0aD0iMTAwJSI+DQogICAg ICAgICAgPFRCT0RZPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAgPFRE Pg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTE+5pS25Lu25Lq6PC9GT05UPjwvRElWPg0KICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTE+Jmx0O3N1Lmh1aUB6dGUuY29tLmNuJmd0OzwvRk9OVD4gDQogICAg ICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgICA8VEQ+DQogICAgICAgICAgICAgIDxE SVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7mioTpgIE8L0ZPTlQ+ PC9ESVY+DQogICAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4mbHQ7 YWRyaWFuQG9sZGRvZy5jby51ayZndDssIA0KICAgICAgICAgICAgICAmbHQ7YmVuamFtaW4ubml2 ZW4tamVua2luc0BidC5jb20mZ3Q7LCANCiAgICAgICAgICAgICAgJmx0O2hoZWx2b29ydEBjaGVs bG8ubmwmZ3Q7LCAmbHQ7bXBscy10cEBpZXRmLm9yZyZndDssIA0KICAgICAgICAgICAgICAmbHQ7 bXBscy10cC1ib3VuY2VzQGlldGYub3JnJmd0OzwvRk9OVD4gDQogICAgICAgICAgPFRSIHZBbGln bj10b3A+DQogICAgICAgICAgICA8VEQ+DQogICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7kuLvpopg8L0ZPTlQ+PC9ESVY+DQogICAgICAg ICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT5SRTogUkU6IFJlOiBbbXBscy10 cF0gQUlTL0ZESSANCiAgICAgICAgICAgICAgKHdhcyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg dHJhbnNwb3J0IHBhdGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAgICAgICAgICAgICZuYnNw O3JlcXVpcmVtZW50cyk8L0ZPTlQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPg0KICAgICAgICA8 VEFCTEU+DQogICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAg ICAgICAgICAgPFREPg0KICAgICAgICAgICAgPFREPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48 L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PEJSPjxCUj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2Fu cyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+VGhhbmtzIFN1aHVpLi4uLi4uc29ycnkgSSBtaXNz ZWQgDQogIHlvdXIgc3BlY2lmaWMgcXVlc3Rpb24uLi4uaGF2ZSBhIGxvb2sgaW4tbGluZSBhbmQg c2VlIGlmIHRoaXMgaGVscHMuPC9GT05UPiANCiAgPEJSPjxCUj4NCiAgPEhSPg0KICA8Rk9OVCBm YWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IHN1Lmh1aUB6dGUuY29tLmNuIA0KICBbbWFp bHRvOnN1Lmh1aUB6dGUuY29tLmNuXSA8Qj48QlI+U2VudDo8L0I+IDI5IEFwcmlsIDIwMDkgMTA6 MzE8Qj48QlI+VG86PC9CPiANCiAgSGFycmlzb24sTixOZWlsLENYTSBSPEI+PEJSPkNjOjwvQj4g YWRyaWFuQG9sZGRvZy5jby51azsgDQogIE5pdmVuLWplbmtpbnMsQixCZW4sRE1GIFI7IGhoZWx2 b29ydEBjaGVsbG8ubmw7IG1wbHMtdHBAaWV0Zi5vcmc7IA0KICBtcGxzLXRwLWJvdW5jZXNAaWV0 Zi5vcmc8Qj48QlI+U3ViamVjdDo8L0I+IOetlOWkjTogUkU6IFJlOiBbbXBscy10cF0gQUlTL0ZE SSAod2FzIA0KICBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWly ZW1lbnRzKTwvRk9OVD48Rk9OVCANCiAgc2l6ZT0zPjxCUj48L0ZPTlQ+PEJSPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PEJSPkhpIE5laWzvvIw8L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mz4g PEJSPjwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5UaGFua3MgZm9yIHlv dXIgcmFwaWQgDQogIHJlcGx5LjwvRk9OVD48Rk9OVCBzaXplPTM+IDwvRk9OVD48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5JIGFtIA0KICBjb25mdXNlZCBieSB5b3VyIGNvbW1lbnRz LCBhcmUgeW91IHN1Z2dlc3RpbmcgRXZlcnl0aGluZ292ZXJJUG92ZXJNUExTLVRQPyANCiAgQUZB SUssIE1QTFMtVFAgY2FuIGNhcnJ5IG1hbnkga2luZHMgb2YgY2xpZW50cywgbm90IGp1c3QgSVAu SW4gbXkgZXhhbXBsZSwgDQogIEUxb3ZlclBXb3Zlck1QTFMtVFAsIHRoZXJlIGlzIG5vIElQIGxh eWVyIGF0IGFsbC48L0ZPTlQ+PEZPTlQgc2l6ZT0zPiANCiAgPC9GT05UPjxGT05UIGZhY2U9IkNv bWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05U IA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj4mbmJzcDsgPC9G T05UPjxCUj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXpl PTI+Tkg9Jmd0OyBGdWxseSB1bmRlcnN0YW5kLiAmbmJzcDtJIA0KICB3YXMgZ2l2aW5nIElQIGFz IGFuICpleGFtcGxlKiBvZiBhIHRlY2hub2xvZ3kgdGhhdCBjYW4gc3VwcG9ydCByZWFsIGV4dGVy bmFsIA0KICBhcHBsaWNhdGlvbnMgYmVjYXVzZSBpdCBoYXMgbWVzc2FnZS9maWxlL3N0cmVhbSBh cHBsaWNhdGlvbiBhZGFwdGF0aW9uIA0KICBmdW5jdGlvbnMgaW4gdGhlIGZvcm0gb2YgVURQL1RD UC9SVFAuICZuYnNwOyBJbiB0aGUgY2FzZSBvZiBFMSB0aGF0IHlvdSBub3RlIA0KICAoYXMgRTFv dmVyUFdvdmVyTVBMUy1UUCkgeW91IGhhdmUgdG8gYXNrIHlvdXJzZWxmIHdoYXQgc3BlY2lmaWMg KmV4dGVybmFsKiANCiAgYXBwbGljYXRpb25zIGRvZXMgdGhlIEUxIHN1cHBvcnQgaGVyZT8uLi4u LmFsd2F5cyByZW1lbWJlcmluZyB0aGF0ICphbnkqIA0KICBuZXR3b3JraW5nIHRlY2hub2xvZ3kg TVVTVCB1bHRpbWF0ZWx5IHN1cHBvcnQgc29tZSBmb3JtIG9mICpleHRlcm5hbGx5IA0KICBzb3Vy Y2VkKiBpbmZvcm1hdGlvbiBzb3VyY2UgZWxzZSBpdCBpcyBub3Qgc2VydmluZyBhbnkgcHVycG9z ZS4gJm5ic3A7U28ganVzdCANCiAgc3VwcG9ydGluZyBFMSBvbiBpdHMgb3duIGRvZXMgbm90IHBy b3ZpZGUgdGhpcy4uLi5mb3IgZXhhbXBsZSBhc2sgeW91cnNlbGYgaG93IA0KICB2b2ljZSBvciBh bnkgdHlwZSBvZiBtZXNzYWdlL2ZpbGUgZGF0YSBnZXRzIGNhcnJpZWQgYnkgdGhlIEUxLjwvRk9O VD4gDQogIDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7PC9GT05UPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PEJSPkFuZCB5b3UgZG9u4oCZdCANCiAgYW5zd2VyIG15IHF1ZXN0aW9uOiBJUCBp cyBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGluIHRoZSBjYXNlIG9mIA0KICBFMW92ZXJQV292ZXJJ UCwgd2h5IGRvZXNuJ3QgTVBMUy1UUCBiZSBhIHRvcC1vZi1zdGFjayBuZXR3b3JrIGluIHRoZSBj YXNlIG9mIA0KICBFMW92ZXJQV292ZXJNUExTLVRQPyBUaGV5IGFyZSBhdCB0aGUgc2FtZSBwb3Np dGlvbiBpbiB0aGUgc3RhY2ssIGFuZCBJIHRoaW5rIA0KICBFMSBpcyDigJhyZWFsIGV4dGVybmFs IHN0cmVhbSBhcHBsaWNhdGlvbnPigJk8L0ZPTlQ+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIg DQogIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPiA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8 L0ZPTlQ+IDxCUj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBz aXplPTI+Tkg9Jmd0OyBUaGUgcG9pbnQgaGVyZSBpcyB0aGF0ICphbnkqIA0KICBuZXR3b3JrIG1v ZGUvdGVjaG5vbG9neSAoYmUgaXQgY2wtcHMsIGNvLXBzIG9yIGNvLWNzKSBjYW4gYWN0IGFzIHRo ZSBzZXJ2ZXIgDQogIGZvciBhbnkgb3RoZXIgbW9kZS90ZWNobm9sb2d5LiAmbmJzcDtIb3dldmVy LCBub3QgYWxsIHRlY2hub2xvZ2llcyBjYW4gc3VwcG9ydCANCiAgZXh0ZXJuYWwgYXBwbGljYXRp b25zLi4uLi50byBzdXBwb3J0IHRoZXNlIHRoZSB0ZWNobm9sb2d5IG11c3QgaGF2ZSANCiAgYXBw bGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMgZm9yIHRoZSBtZXNzYWdlL2ZpbGUvc3RyZWFt IGluZm9ybWF0aW9uIA0KICBzb3VyY2VzIHRoYXQgYXJlIGdlbmVyYXRlZCBpbiBleHRlcm5hbCBD UEUsIGVnIHBob25lLCBQQywgZXRjLjwvRk9OVD4gDQogIDxCUj48Rk9OVCBzaXplPTM+Jm5ic3A7 PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCANCiAg c2l6ZT0yPk1vc3QgdGVjaG5vbG9naWVzIGRvIG5vdCBoYXZlIHRoZXNlIGV4dGVybmFsIGFwcGxp Y2F0aW9uIGFkYXB0YXRpb24gDQogIGZ1bmN0aW9ucyBhbmQgc28gdGhlIG9ubHkgam9iIHRoZXkg Y2FuIGRvIGlzIGNyZWF0ZSB0aGUgdG9wb2xvZ3kgb2Ygb3RoZXIgDQogIGxheWVyIG5ldHdvcmtz LjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgDQog IHNpemU9Mj4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj5TbyANCiAgeWVzIHdlIGNhbiB1c2UgSVAgKGNsLXBzKSB0byBjYXJy eSBTREggVkM0IChjby1jcykgaWYgd2Ugd2FudC4uLi4uLi5wcm9iYWJseSANCiAgbm90IGEgZ29v ZCBpZGVhIGJ1dCBpdCBpcyBmb3Igc3VyZSBwb3NzaWJsZS48L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8 L0ZPTlQ+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0y PiZuYnNwO0hvd2V2ZXIsIGFuIFNESCBWQzQgbmV0d29yayANCiAgY2Fubm90ICpkaXJlY3RseSog c3VwcG9ydCBlaXRoZXIgdm9pY2Ugb3IgZGF0YSBidXQgYW4gSVAgbmV0d29yayANCiAgY2FuLi4u Li5iZWNhdXNlIElQIGhhcyBVRFAvVENQL1JUUCBhcHBsaWNhdGlvbnMgYWRhcHRhdGlvbnMgYW5k IFNESCBWQzQgZG9lcyANCiAgbm90IGhhdmUgdGhlc2UuICZuYnNwO0hhdmluZyBzYWlkIHRoYXQs IHRoZXJlIGlzIGluIHByaW5jaXBsZSBubyByZWFzb24gd2h5IA0KICBhbnkgbW9kZS90ZWNobm9s b2d5IChldmVuIFNESCBWQzQpIGNhbm5vdCBzdXBwb3J0IGV4dGVybmFsIG1lc3NhZ2UvZmlsZS9z dHJlYW0gDQogIGFwcGxpY2F0aW9ucy4uLi4uLml0cyBqdXN0IHRoYXQgZm9yIG1vc3QgdGVjaG5v bG9naWVzIHRoZXNlIGhhdmUgbmV2ZXIgYmVlbiANCiAgc3BlY2lmaWVkIGJlY2F1c2UgdGhleSB3 ZXJlIG9ubHkgZXZlciBpbnRlbmRlZCB0byBwcm92aWRlIGEgJ25ldHdvcmsgYnVpbGRlcicgDQog IHRyYW5zcG9ydCByb2xlLjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+IDxC Uj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+QXNp ZGU9Jmd0OyBJZiBhIHRlY2hub2xvZ3kgWCBjYW4gDQogIHN1cHBvcnQgbWVzc2FnZS9maWxlL3N0 cmVhbSBhcHBsaWNhdGlvbnMgZGlyZWN0bHkgdGhlbiBoZXJlIHdlIHdvdWxkIG1vc3QgDQogIGRl ZmluaXRlbHkgaGF2ZSB0byBjb25zaWRlciBwZWVyLWludGVyd29ya2luZyB0ZWNobm9sb2d5IFgg d2l0aCBib3RoIElQIA0KICAoSW50ZXJuZXQpIGFuZCBQU1ROICh2b2ljZSBjYXNlIG9ubHkpLiAm bmJzcDtJbiBhbGwgb3RoZXIgY2FzZXMgKGllIHdoZXJlIA0KICB0ZWNobm9sb2d5IFggaXMgbm90 IHRvcC1vZi1zdGFjaywgaWUgZG9lcyBub3QgaGF2ZSBtZXNzYWdlL2ZpbGUvc3RyZWFtIA0KICBh cHBsaWNhdGlvbiBhZGFwdGF0aW9uIGZ1bmN0aW9ucykgdGhlcmUgaXMgbm8gbmVlZCBmb3IgcGVl ci1pbnRlcndvcmtpbmcgaXQgDQogIHdpdGggYW55IG90aGVyIHRlY2hub2xvZ3ksIGluY2x1ZGlu ZyBJUCAoSW50ZXJuZXQpIGFuZCBQU1ROLjwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTM+Jm5i c3A7PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIA0KICBm YWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj5Zb3VyIGZpbmFsIHBvaW50 ICgiPC9GT05UPjxGT05UIA0KICBmYWNlPUFyaWFsIHNpemU9Mj5JIHRoaW5rIEUxIGlzIOKAmHJl YWwgZXh0ZXJuYWwgc3RyZWFtIA0KICBhcHBsaWNhdGlvbnPigJkiPC9GT05UPjxGT05UIGZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPiApIGlzIG5vdCANCiAgc3RyaWN0 bHkgY29ycmVjdCBidXQgSSBjYW4gZnVsbHkgdW5kZXJzdGFuZCB3aHkgeW91IHNheSB0aGlzLiAm bmJzcDtFMSBiZWxvbmdzIA0KICB0byB0aGUgY28tY3MgbW9kZS4gJm5ic3A7V2hlbiB5b3UgYW5h bHlzZSB0aGlzIChhcyBpcyBkb25lIGluIEcuODAwLCB3aGljaCANCiAgZXhwbGFpbnMgd2h5IHRo ZSAzIG5ldHdvcmsgbW9kZXMgYXJpc2UgZnJvbSBpbmZvcm1hdGlvbi9zeXN0ZW1zIHRoZW9yeSAN CiAgY29uc2lkZXJhdGlvbnMpIHlvdSBmaW5kIHRoYXQgaW4gdGhlIHRpbWUgZGltZW5zaW9uIHRo ZSBjby1jcyBtb2RlIHBhcnRpdGlvbnMgDQogIHJlc291cmNlICh0aW1lKSB1cCBpbnRvIHJlZ3Vs YXIgdGltZSBzbGljZXMuLi4uc28gdGhpcyBtZWFucyBib3RoIHRoZSBzdGFydCANCiAgZXBvY2gg KGFuIGltcGxpY2l0IGxhYmVsKSBhbmQgKG1vc3QgY3J1Y2lhbGx5KSBpdHMgZHVyYXRpb24gYXJl IGZpeGVkLiANCiAgJm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4g PEJSPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIA0KICBjb2xvcj0jODAwMDAwIHNpemU9Mj5X aXRob3V0IGdvaW5nIGludG8gbWFqb3IgZGV0YWlsIGhlcmUgKEkgaGF2ZSBwYXBlciBvbiANCiAg dGhpcyBJIGNhbiBzZW5kIHlvdSBpZiB5b3Ugd2FudC4uLmp1c3QgYXNrKSB3aGF0IHRoaXMgbWVh bnMgaXMgdGhhdCB0aGUgY28tY3MgDQogIG1vZGUgaXMgdGhlIHVsdGltYXRlICdzbW9vdGhlci9z aGFwZXInIGZvciBjbGllbnQgdHJhZmZpYy4uLi4uLnNvIGFzIHlvdSANCiAgcmlnaHRseSBvYnNl cnZlIHRoaXMgbG9va3MgbGlrZSBhIHN0cmVhbSBjYXNlLiAmbmJzcDtJdCdzIG5vdCBhIHNwZWNp ZmljIA0KICBleHRlcm5hbCBhcHBsaWNhdGlvbiBob3dldmVyIGxpa2UgaHVtYW4gdm9pY2Ugb3Ig dmlkZW8gKHRoZXNlIG11c3QgZ2VuZXJhdGUgDQogIHJlYWwgKmluZm9ybWF0aW9uKiB0aGF0IGNv bW11bmljYXRpbmcgcGFydGllcyB1bmRlcnN0YW5kKSBidXQgaXQgZm9yIHN1cmUgaGFzIA0KICB0 aGUgQ0JSIGJlaGF2aW91ciBvZiBhIHN0cmVhbS4gPC9GT05UPjxCUj48Rk9OVCBzaXplPTM+Jm5i c3A7PC9GT05UPiA8QlI+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgc2l6ZT0yPkJUVyB0aGUgcmVhc29uIHRoZSBjby1jcyBtb2RlIGhhcyANCiAgYmVlbiBlbmR1 cmluZ2x5IHN1Y2Nlc3NmdWwgYXMgYSB0cmFuc3BvcnQgbmV0d29yayBpcyBiZWNhdXNlIGl0IHBy b3ZpZGVzIA0KICAqdHJhbnNwYXJlbmN5KiB0byBhbGwgY2xpZW50cyAod2hpY2ggaXMgZXhhY3Rs eSB0aGUgc2ltaWxhciBiZWhhdmlvdXIgb2YgYSANCiAgc3RyZWFtIGFzIHlvdSBub3RlKSwgaWU8 L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBz aXplPTI+LSAmbmJzcDsgJm5ic3A7YWxsIGNsaWVudCBiaXRzIHRyZWF0ZWQgZXF1YWxseSAoYSBy ZWFsbHkga2V5IHBvaW50IA0KICB0aGlzLCBhcyB0aGlzIG1lYW5zIGl0IHByb3ZpZGVzIGVxdWFs ICdpbXBvcnRhbmNlJyB0cmVhdG1lbnQgb2YgdGhlIHVsdGltYXRlIA0KICBoaWdoZXIgbGV2ZWwg KGFuZCB1bnNlZW4vdW5rbm93biBieSB0aGUgY28tY3MgdHJhbnNwb3J0IG5ldHdvcmspIA0KICBt ZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyk8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJD b21pYyBTYW5zIE1TIiANCiAgY29sb3I9IzgwMDAwMCBzaXplPTI+LSAmbmJzcDsgJm5ic3A7Y2xp ZW50IGJpdCBvcmRlcmluZyBpcyBwcmVzZXJ2ZWQ8L0ZPTlQ+IA0KICA8QlI+PEZPTlQgZmFjZT0i Q29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+LSAmbmJzcDsgJm5ic3A7ZG9lcyBu b3QgDQogIHRyeSBhbiBpbmZlciBtZWFuaW5nIG9mIGNsaWVudCBiaXRzIG5vciBjaGFuZ2UgdGhl bTwvRk9OVD4gPEJSPjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAw IHNpemU9Mj4tICZuYnNwOyAmbmJzcDtlbnN1cmVzIHRoZSB0cmFmZmljIA0KICBiZWhhdmlvdXIg b2YgY2xpZW50IFggY2Fubm90IGltcGFjdCB0aGUgcGVyZm9ybWFuY2UgZXhwZXJpZW5jZWQgYnkg cGFydHkgDQogIFkuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxG T05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIA0KICBjb2xvcj0jODAwMDAwIHNpemU9Mj4mbmJzcDs8 L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgY29sb3I9IzgwMDAwMCBz aXplPTI+cmVnYXJkcywgTmVpbDwvRk9OVD48Rk9OVCBzaXplPTM+IDxCUj48L0ZPTlQ+PEZPTlQg DQogIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PEJSPlJlZ2FyZHMsPC9GT05UPjxGT05UIHNpemU9 Mz4gPC9GT05UPjxGT05UIA0KICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5TdWh1aS48L0ZP TlQ+PEZPTlQgc2l6ZT0zPiA8QlI+PEJSPjwvRk9OVD4NCiAgPFRBQkxFIHdpZHRoPSIxMDAlIj4N CiAgICA8VEJPRFk+DQogICAgPFRSIHZBbGlnbj10b3A+DQogICAgICA8VEQgd2lkdGg9IjE4JSI+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgICBzaXplPTE+PEI+Jmx0O25laWwuMi5oYXJy aXNvbkBidC5jb20mZ3Q7PC9CPiA8L0ZPTlQ+DQogICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTE+MjAwOS0wNC0yOSAxNDo0MDwvRk9OVD48Rk9OVCBzaXplPTM+IA0KICAgICAg ICA8L0ZPTlQ+PC9QPg0KICAgICAgPFREIHdpZHRoPSI4MSUiPjxCUj4NCiAgICAgICAgPFRBQkxF IHdpZHRoPSIxMDAlIj4NCiAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgPFRSIHZBbGlnbj10 b3A+DQogICAgICAgICAgICA8VEQgd2lkdGg9IjUlIj4NCiAgICAgICAgICAgICAgPERJViBhbGln bj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuaUtuS7tuS6ujwvRk9OVD48L0RJ Vj4NCiAgICAgICAgICAgIDxURCB3aWR0aD0iOTQlIj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQog ICAgICAgICAgICAgIHNpemU9MT4mbHQ7c3UuaHVpQHp0ZS5jb20uY24mZ3Q7PC9GT05UPjxGT05U IHNpemU9Mz4gPC9GT05UPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgICAg PFREPg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTE+5oqE6YCBPC9GT05UPjwvRElWPg0KICAgICAgICAgICAgPFREPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTE+Jmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7LCANCiAgICAgICAg ICAgICAgJmx0O2JlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tJmd0OywgDQogICAgICAgICAg ICAgICZsdDtoaGVsdm9vcnRAY2hlbGxvLm5sJmd0OywgJmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7 LCANCiAgICAgICAgICAgICAgJmx0O21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyZndDs8L0ZPTlQ+ PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+DQogICAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAg ICAgICA8VEQ+DQogICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5z LXNlcmlmIHNpemU9MT7kuLvpopg8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICA8VEQ+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9MT5SRTogUmU6IFttcGxzLXRwXSBBSVMvRkRJICh3YXMgDQog ICAgICAgICAgICAgIEFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCAmbmJz cDsgJm5ic3A7ICZuYnNwOyANCiAgICAgICAgICAgICAgJm5ic3A7cmVxdWlyZW1lbnRzKTwvRk9O VD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PEJSPg0KICAgICAgICA8VEFCTEUgd2lkdGg9IjEw MCUiPg0KICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAg ICAgICAgIDxURCB3aWR0aD0iNTAlIj4NCiAgICAgICAgICAgIDxURCB3aWR0aD0iNTAlIj48L1RS PjwvVEJPRFk+PC9UQUJMRT48QlI+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjxGT05UIA0KICBz aXplPTM+PEJSPjxCUj48L0ZPTlQ+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9Izgw MDAwMCANCiAgc2l6ZT0yPjxCUj5UaGFua3MgU2h1aHVpLDwvRk9OVD48Rk9OVCBzaXplPTM+IDxC Uj4mbmJzcDs8L0ZPTlQ+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgc2l6ZT0yPjxCUj5EbyBub3QgY29uZnVzZSBwaHlzaWNhbCANCiAgaW50ZXJjb25uZWN0IHdp dGggRS1OTkkuLi4uLkknbGwgY29tZSBiYWNrIG9uIHRoaXMgc2hvcnRseSB3aGVuIGRpc2N1c3Np bmcgdGhlIA0KICBib3R0b20tb2Ytc3RhY2sgc2VjdGlvbiBsYXllci48L0ZPTlQ+PEZPTlQgc2l6 ZT0zPiA8QlI+Jm5ic3A7PC9GT05UPjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xv cj0jODAwMDAwIHNpemU9Mj48QlI+VGhlIGZpcnN0IHRoaW5nIHRvIHVuZGVyc3RhbmQgaXMgDQog IHRoYXQgKmFsbCogbmV0d29ya3MgYXJlIHRoZXJlIHRvIHVsdGltYXRlbHkgc3VwcG9ydCBvbmUg cHVycG9zZS4uLi4uYW5kIHRoYXQgDQogIGlzIHRvIGFsbG93IGNvbW11bmljYXRpb25zIGJldHdl ZW4gcGFydGllcyB0aGF0IGFyZSAqZXh0ZXJuYWwqIHRvIHRoZSANCiAgbmV0d29ya3MuICZuYnNw O1NvIGV2ZXJ5dGhpbmcgd2UgZG8gaW4gbmV0d29ya2luZyBpcyB0aGVyZSB0byB1bHRpbWF0ZWx5 IA0KICBzdXBwb3J0IHRoaXMgb2JqZWN0aXZlLiAmbmJzcDtXaGF0IHRoaXMgbWVhbnMgaXMgdGhh dCB0aGUgRFAgb2Ygc29tZSBuZXR3b3JrIA0KICAod2hhdCBJIGNhbGwgdGhlIHRvcC1vZi1zdGFj ayBuZXR3b3JrKSBNVVNUIGJlIHByb3ZpZGluZyBhZGFwdGF0aW9uIGZ1bmN0aW9ucyANCiAgZm9y IHRoZXNlIGV4dGVybmFsIGFwcGxpY2F0aW9ucy4uLi4uLi5hbmQgdGhlc2UgY2FuIGdlbmVyaWNh bGx5IGJlIGNsYXNzaWZpZWQgDQogIGFzIG1lc3NhZ2VzLCBmaWxlcyBhbmQgc3RyZWFtcy4gPC9G T05UPjxGT05UIHNpemU9Mz48QlI+Jm5ic3A7PC9GT05UPjxGT05UIA0KICBmYWNlPSJDb21pYyBT YW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj48QlI+V2UgY2FuIHNlZSB0aGF0IElQIGlzIGEg DQogIHRvcC1vZi1zdGFjayBuZXR3b3JrIGFzIGl0IGhhcyBVRFAvVENQL1JUUCAoZm9yIGV4YW1w bGUpIGFkYXB0YXRpb25zLiANCiAgJm5ic3A7QVRNIHdhcyBhbHNvIG9uY2UgKH45MHMpIGludGVu ZGVkIHRvIGJlIGEgdG9wLW9mLXN0YWNrIG5ldHdvcmsgYW5kIGl0IA0KICBoYWQgaXRzIG93biBh cHBsaWNhdGlvbiBhZGFwdGF0aW9ucyBpbiB0aGUgZm9ybSBvZiBBQUxzLiAmbmJzcDtBdCBvbmUg c3RhZ2UgDQogIHRoZXJlIHdlcmUgNSBvZiB0aGVzZSwgYnV0IGluIHByYWN0aWNlIG9ubHkgYSBj b3VwbGUgd2VyZSByZWFsbHkgc3VjY2Vzc2Z1bCANCiAgYmVjYXVzZSBvZiB0aGUgZ2VuZXJpYyBu YXR1cmUgb2YgbWVzc2FnZS9maWxlL3N0cmVhbSBjbGFzc2lmaWNhdGlvbi4gJm5ic3A7VGhlIA0K ICBQU1ROIGlzIGFsc28gdG9wLW9mLXN0YWNrLCBhbmQgaXRzIGFwcGxpY2F0aW9uIGFkYXB0YXRp b24gd2FzIG1haW5seSBmb3Igdm9pY2UgDQogIChzdHJlYW0pIHN1cHBvcnQuPC9GT05UPjxGT05U IHNpemU9Mz4gPEJSPiZuYnNwOzwvRk9OVD48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2FucyBNUyIg Y29sb3I9IzgwMDAwMCBzaXplPTI+PEJSPk1vc3Qgb3RoZXIgbmV0d29ya3MgZG8gbm90IGhhdmUg DQogIHRoZXNlIGFwcGxpY2F0aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zLi4uLnNvIHRoZXkgZG8g bm90IGRpcmVjdGx5IHN1cHBvcnQgDQogIGFwcGxpY2F0aW9ucy4gJm5ic3A7V2hhdCB0aGlzIG1l YW5zIGluIHByYWN0aWNlIGlzIHRoYXQgdGhlc2UgbmV0d29ya3MgKGEgbGlzdCANCiAgd2hpY2gg aW5jbHVkZXMgUERILCBTREgsIE9UTiwgRXRoZXJuZXQsIE1QTFMpIE1VU1QgY2FycnkgYSBmdXJ0 aGVyIGxheWVyIA0KICBuZXR3b3JrIGFib3ZlIHRoZW0gdGhhdCBpcyB0b3Atb2Ytc3RhY2suLi4u bGlrZSBJUC4gJm5ic3A7VGhlcmUgaXMgbm8gY2hvaWNlIA0KICBpbiB0aGUgbWF0dGVyIGhlcmUu ICZuYnNwO1NvIHdoaWxzdCB3ZSBtaWdodCBzYXkgdGhhdCBhbiBNUExTIG5ldHdvcmsgaXMgDQog IGNhcnJ5aW5nIGFuIEUxIFBXIHRoZSBFMSBlbnRpdHkgbXVzdCBpbiB0dXJuIGJlIGNhcnJ5aW5n IHNvbWUgb3RoZXIgDQogIHRvcC1vZi1zdGFjayBuZXR3b3JrIChsaWtlIElQIG9yIFBTVE4pLCBl bHNlIGl0IGlzIHNlcnZpbmcgbm8gdWx0aW1hdGUgDQogIHB1cnBvc2UuPC9GT05UPjxGT05UIHNp emU9Mz4gPEJSPiZuYnNwOzwvRk9OVD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgY29s b3I9IzgwMDAwMCBzaXplPTI+PEJSPk5vdyBpbiBvcmRlciB0byB0cmFuc21pdCBpbmZvcm1hdGlv biBvdmVyIGdlb2dyYXBoaWMgDQogIGRpc3RhbmNlIHdlIG11c3QgbW9kdWxhdGUgYW4gRU0gd2F2 ZSBvbiBzb21lIG1ldGFsbGljL29wdGljYWwvcmFkaW8gDQogIG1lZGlhLi4uLnRoaXMgaXMgdGhl IGJvdHRvbS1vZi1zdGFjayBzZWN0aW9uIGxheWVyLiAmbmJzcDtUaGVzZSBhcmUgaGlnaCBiaXQg DQogIHJhdGUgdHJhbnNwb3J0IHBpcGVzIHdob3NlIGZ1bmN0aW9uIGlzIHRvIHByb3ZpZGUgdHJh bnNwYXJlbnQgKHdoaWNoIEkgaGF2ZSANCiAgZGVmaW5lZCBwcmV2aW91c2x5KSB0cmFuc3BvcnQg dG8gd2hhdGV2ZXIgY2xpZW50IGxheWVycyBuZXR3b3JrcyBzaXQgYWJvdmUgDQogIHRoZW0uLi4u YW5kIHdoZXJlLCBhcyBJIG5vdGVkIGFib3ZlLCB0aGVyZSBNVVNUIGJlIGEgdG9wLW9mLXN0YWNr IG5ldHdvcmsgDQogIHByZXNlbnQgYXMgdGhlIHVsdGltYXRlIGxheWVyIG5ldHdvcmsgY2xpZW50 IGVsc2UgdGhlcmUgaXMgbm90IGV4dGVybmFsIHBhcnR5IA0KICBjb21tdW5pY2F0aW9uIHBvc3Np YmxlLjwvRk9OVD48Rk9OVCBzaXplPTM+IDxCUj4mbmJzcDs8L0ZPTlQ+PEZPTlQgDQogIGZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjxCUj5TbyB3aGVuIHdlIGNvbm5l Y3QgdG9nZXRoZXIgMiANCiAgdG9wLW9mLXN0YWNrIG5ldHdvcmtzIHdlIGRvIHNvIGF0IGEgc2Vj dGlvbiBsYXllciB3aGljaCBpcyBpbnZhcmlhYmx5IGNhcnJ5aW5nIA0KICBhIHZlcnkgbGFyZ2Ug YWdncmVnYXRlIG9mIGFwcGxpY2F0aW9ucy4uLi4uYW5kIG9mIGNvdXJzZSB0aGVzZSBhcHBsaWNh dGlvbnMgDQogIGNhbiBiZSBhIHRpbWUgdmFyeWluZyBtaXggb2YgbWVzc2FnZS9maWxlL3N0cmVh bSBjYXNlcyB3aXRoIGEgc2V0IG9mIHVua25vd24gDQogICh0byB0aGUgc2VjdGlvbiBsYXllcikg aW1wb3J0YW5jZSdzIChlcmdvIHdoeSB0cmFuc3BhcmVuY3kgaXMgYW4gZXNzZW50aWFsIA0KICBy ZXF1aXJlbWVudCBpbiB0cmFuc3BvcnQgbmV0d29ya3MpLjwvRk9OVD48Rk9OVCBzaXplPTM+IDxC Uj4mbmJzcDs8L0ZPTlQ+PEZPTlQgDQogIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAw MDAgc2l6ZT0yPjxCUj5UaGUgcmVhbCBFLU5OSXMgKHdoaWNoIGNvbnNpZGVycyANCiAgYm90aCBE UCBhbmQgQ1AgY29tcG9uZW50cy4uLi53ZSBuZXZlciB1c3VhbGx5IHBlZXIgdGhlIE1QLCBhbmQg d2UgcmVzdHJpY3QgdGhlIA0KICBzY29wZSBvZiB0aGUgQ1ApIGV4aXN0IGluIHRoZSB0b3Atb2Yt c3RhY2sgbGF5ZXIgbmV0d29yay4gJm5ic3A7VGhlIHNlY3Rpb24gDQogIGxheWVyIGludGVyY29u bmVjdCBpcyBhIGR1bWIgRFAgcGlwZS4uLml0IGp1c3Qgc2hpZnRzIGJpdHMgdHJhbnNwYXJlbnRs eSBhbmQgDQogIG1haW50YWlucyB0aGVpciBvcmRlcmluZy4gJm5ic3A7VGhlcmUgaXMgbm8gY29u Y2VwdCBvZiBDUCAob3IgTVApIHBlZXJpbmcgb24gDQogIHRoZXNlIGJvdHRvbS1vZi1zdGFjayBz ZWN0aW9uIGxheWVyIGludGVyY29ubmVjdHMuPC9GT05UPjxGT05UIHNpemU9Mz4gDQogIDwvRk9O VD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj48QlI+QXNp ZGU9Jmd0OyBJbiBzb21lIA0KICBjb3VudHJpZXMgdGhlc2UgaW50ZXJjb25uZWN0cyBoYXZlIHRv IGJlIGNhcmVmdWxseSBzcGVjaWZpZWQgaW4gb3JkZXIgdG8gDQogIGRpc3Rpbmd1aXNoIHJlZ3Vs YXRlZCBhbmQgdW5yZWd1bGF0ZWQgc2VydmljZXMuLi4uLnNvIHRoZXJlIGFyZSBpbXBvcnRhbnQg DQogIGxlZ2FsL2NvbW1lcmNpYWwgY29uc2lkZXJhdGlvbnMgaGVyZSwgaXQgaXMgbm90IHNpbXBs eSBhIHRlY2huaWNhbCANCiAgaXNzdWUuPC9GT05UPjxGT05UIHNpemU9Mz4gPEJSPiZuYnNwOzwv Rk9OVD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiANCiAgY29sb3I9IzgwMDAwMCBzaXplPTI+ PEJSPldlIGNhbiBvZiBjb3Vyc2UgY3JlYXRlIEUtTk5JcyBpbiBub24gdG9wLW9mLXN0YWNrIA0K ICBsYXllciBuZXR3b3JrcyAod2UgY2FuIGRvIG1hbnkgdGhpbmdzIHRoYXQgYXJlIG5vdCB1c2Vm dWwpLiAmbmJzcDtTbyBsZXRzIA0KICBhc3N1bWUgd2UgZG8gdGhpcy4uLi4uYW5kIGxldHMgYXNz dW1lIHdlIGNob29zZSBNUExTIHNpbmNlIHlvdSBtZW50aW9uIHRoaXMgaW4gDQogIHRoZSBtYWls IGJlbG93LiA8L0ZPTlQ+PEZPTlQgc2l6ZT0zPjxCUj4mbmJzcDs8L0ZPTlQ+PEZPTlQgDQogIGZh Y2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjxCUj5Ob3cgaG93IGRvIGV4 dGVybmFsIHBhcnRpZXMgd2hvIA0KICB3aXNoIHRvIGNvbW11bmljYXRlIGludGVyZmFjZSB3aXRo IHRoaXMgTVBMUyBuZXR3b3JrPyAmbmJzcDtDYW4geW91IHN1cHBvcnQgDQogIGFsbCB0eXBlcyBv ZiBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyAqZGlyZWN0bHkqIGludG8gTVBMUz8g Jm5ic3A7SW4gDQogIHByaW5jaXBsZSB5b3UgY291bGQgaWYgeW91IGFsbG93ZWQgTVBMUyB0byBo YXZlIGVuZCBzeXN0ZW0gYXBwbGljYXRpb24gDQogIGFkYXB0YXRpb25zIHN1Y2ggYXMgVURQL1RD UC9SVFAgb3IgdGhlIGxpa2UuICZuYnNwO0J1dCB0aGVzZSBkb24ndCBleGlzdCANCiAgdG9kYXks IGFuZCBpbiB0aGUgbW9zdCB1c3VhbCBjYXNlIHRoZSBNUExTIG5ldHdvcmsgd2lsbCBjYXJyeSBh biBJUCBsYXllciANCiAgbmV0d29yayBiZWNhdXNlIHRoaXMgY2FuIHN1cHBvcnQgdGhlIG1lc3Nh Z2UvZmlsZS9zdHJlYW0gDQogIGFwcGxpY2F0aW9ucy48L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8QlI+ Jm5ic3A7PC9GT05UPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIA0KICBjb2xvcj0jODAwMDAw IHNpemU9Mj48QlI+V2UgY2FuIGdvIHRocm91Z2ggZXhhY3RseSB0aGUgc2FtZSBhbmFseXNpcyB3 aXRoIGFueSANCiAgbmV0d29yayB0aGF0IGlzIG5vdCB0b3Atb2Ytc3RhY2ssIGVnIEV0aGVybmV0 LiAmbmJzcDtBbmQgd2hlbiB5b3UgZG8gdGhpcyB3aGF0IA0KICB5b3UgcmVhbGlzZSBpcyB0aGF0 IGFsdGhvdWdoIHdlIGNhbiBjcmVhdGUgcGVlciBpbnRlcndvcmtpbmcgb2YgTVBMUyAob3IgDQog IHdoYXRldmVyKSB0aGlzIGhhcyBub3QgcmVhbGx5IGhlbHBlZCBzaW5jZSB3ZSBtaWdodCBhcyB3 ZWxsIGhhdmUganVzdCANCiAgdGVybWluYXRlZCB0aGUgTVBMUyBuZXR3b3JrIGFuZCBwYXNzZWQg dGhlIElQIGxheWVyIGFjcm9zcy48L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mz4gPEJSPiZuYnNwOzwv Rk9OVD48Rk9OVCBmYWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jODAwMDAwIA0KICBzaXplPTI+ PEJSPk5vdyB0aGUgYWJvdmUgYmVjb21lcyBldmVuIG1vcmUgc3RyaWtpbmcgaW4gaXRzIGltcG9y dGFuY2UgaWYgeW91IA0KICBjb25zaWRlciBwZWVyIGludGVyd29ya2luZyBvZiAyIGRpZmZlcmVu dCBub24gdG9wLW9mLXN0YWNrIG5ldHdvcmtzLi4uLmxldHMgDQogIHBpY2sgTVBMUyBhbmQgRXRo ZXJuZXQgYmVjYXVzZSB0aGF0IGlzIHdoYXQgaXMgb2Z0ZW4gbWVudGlvbmVkLiANCiAgJm5ic3A7 PC9GT05UPjxGT05UIHNpemU9Mz4gPEJSPiZuYnNwOzwvRk9OVD48Rk9OVCBmYWNlPSJDb21pYyBT YW5zIE1TIiANCiAgY29sb3I9IzgwMDAwMCBzaXplPTI+PEJSPldoYXQgd2UgaGF2ZSB0byBkbyBu b3cgYXQgdGhlIEUtTk5JcyBiZXR3ZWVuIEV0aGVybmV0IA0KICBhbmQgTVBMUyBpcyBnbyB0aHJv dWdoIGVhY2ggRFAgYW5kIENQIGNvbXBvbmVudCBhbmQgZG8gYSAncHJvdG9jb2wgY29udmVyc2lv bicgDQogIGV4ZXJjaXNlIHdoZXJlIHJlcXVpcmVkLi4uLi4uYW5kIHRoZSBmaXJzdCBwcm9ibGVt IHlvdSB3aWxsIGVuY291bnRlciBpcyB0aGF0IA0KICB0aGVyZSB3aWxsIGJlIGxvdHMgb2YgZnVu Y3Rpb25hbCBtaXNtYXRjaC4gJm5ic3A7TW9yZW92ZXIgaWYgb25lIG9yIGJvdGggb2YgDQogIHRo ZSBuZXR3b3JrcyBjYW4gc3VwcG9ydCBtdWx0aXBsZSBDUCB0eXBlcyBsaWtlIE1QTFMgY2FuLCBl ZyBSU1ZQLVRFIA0KICBzaWduYWxsaW5nLCBMRFAgc2lnbmFsbGluZywgQkdQNCAnc2lnbmFsbGlu ZycsIE9TUEYgcm91dGluZywgSVMtSVMgDQogIHJvdXRpbmcuLi4uLmFuZCBJIGNvdWxkIGxpc3Qg c2ltaWxhciBmb3IgRXRoZXJuZXQuLi4uLnlvdSBhcmUgZ29pbmcgdG8gaGF2ZSB0byANCiAgY29u c2lkZXIgZWFjaCBwYWlyaW5nIGNhc2UgaW4gdHVybi4gJm5ic3A7QSBsb3Qgb2Ygd29yay48L0ZP TlQ+PEZPTlQgc2l6ZT0zPiANCiAgPEJSPiZuYnNwOzwvRk9OVD48Rk9OVCBmYWNlPSJDb21pYyBT YW5zIE1TIiBjb2xvcj0jODAwMDAwIHNpemU9Mj48QlI+QW5kIHdoZW4gDQogIHlvdSBoYXZlIGRv bmUgYWxsIHRoaXMgeW91IGFzayB0aGUgcXVlc3Rpb24gJ3doYXQgaXMgaXQgdGhhdCBjYXJyaWVz IHRoZSByZWFsIA0KICBleHRlcm5hbCBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9ucyBp biB0aGUgRFAgaGVyZT8nLi4uLi4uLmFuZCBub3cgeW91IA0KICBmaW5kIG5vIG5hdGl2ZSBzdXBw b3J0IGZvciB0aGVzZSBpbiBNUExTIG9yIEV0aGVybmV0LCBidXQgd2hhdCB3ZSBkbyBmaW5kIGlz IA0KICB0aGF0IGJvdGggb2YgdGhlbSBhcmUgY2FycnlpbmcgSVAgYmVjYXVzZSB0aGlzIGRvZXMg c3VwcG9ydCB0aGUgZXh0ZXJuYWwgDQogIGFwcGxpY2F0aW9ucy4gJm5ic3A7Tm93IGF0IHRoaXMg cG9pbnQgd2UgaGF2ZSBkaXNjb3ZlcmVkIHdoYXQgaXMgdGhlIGNvbW1vbiANCiAgdGhpbmcgYmV0 d2VlbiBNUExTIGFuZCBFdGhlcm5ldC4uLi5pdCBpcyB0aGUgdG9wLW9mLXN0YWNrIElQIGxheWVy IG5ldHdvcmsuIA0KICAmbmJzcDtBbmQgc28gd2UgdWx0aW1hdGVseSByZWFsaXNlIHdlIGNvdWxk IGhhdmUgc2F2ZSBvdXJzZWx2ZXMgYSBsb2FkIG9mIA0KICB1bm5lY2Vzc2FyeSB3b3JrIGJ5IHNp bXBseSB0ZXJtaW5hdGluZyB0aGUgTVBMUyBhbmQgRXRoZXJuZXQgbGF5ZXIgbmV0d29yayBhdCAN CiAgdGhlIGludGVyd29ya2luZyBwb2ludCBhbmQganVzdCBwYXNzZWQgdGhlIElQIGxheWVyIG5l dHdvcmsgDQogIGFjcm9zcy48L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8QlI+Jm5ic3A7PC9GT05UPjxG T05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIA0KICBjb2xvcj0jODAwMDAwIHNpemU9Mj48QlI+U29y cnkgSSd2ZSBoYWQgdG8gZ28gdGhyb3VnaCBhbGwgdGhpcyB5ZXQgYWdhaW4gKGVzcCANCiAgZm9y IGFsbCB0aGUgZm9sa3MgdGhhdCBoYXZlIGFscmVhZHkgdW5kZXJzdG9vZCB0aGUgcG9pbnQpIGJ1 dCBJIGRvIGhvcGUgaXRzIA0KICBjbGVhciBub3cgYW5kIHdlIGNhbiBwdXQgdGhpcyBpc3N1ZSB0 byBiZWQuPC9GT05UPjxGT05UIHNpemU9Mz4gDQogIDxCUj4mbmJzcDs8L0ZPTlQ+PEZPTlQgZmFj ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzgwMDAwMCBzaXplPTI+PEJSPnJlZ2FyZHMsIA0KICBO ZWlsPC9GT05UPjxGT05UIHNpemU9Mz4gPEJSPjxCUj48L0ZPTlQ+DQogIDxIUj4NCiAgPEZPTlQg ZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBzdS5odWlAenRlLmNvbS5jbiANCiAgW21h aWx0bzpzdS5odWlAenRlLmNvbS5jbl0gPEI+PEJSPlNlbnQ6PC9CPiAyOSBBcHJpbCAyMDA5IDAz OjIyPEI+PEJSPlRvOjwvQj4gDQogIEhhcnJpc29uLE4sTmVpbCxDWE0gUjxCPjxCUj5DYzo8L0I+ IGFkcmlhbkBvbGRkb2cuY28udWs7IA0KICBOaXZlbi1qZW5raW5zLEIsQmVuLERNRiBSOyBoaGVs dm9vcnRAY2hlbGxvLm5sOyBtcGxzLXRwQGlldGYub3JnOyANCiAgbXBscy10cC1ib3VuY2VzQGll dGYub3JnPEI+PEJSPlN1YmplY3Q6PC9CPiDnrZTlpI06IFJlOiBbbXBscy10cF0gQUlTL0ZESSAo d2FzIA0KICBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggcmVxdWlyZW1l bnRzKTwvRk9OVD48Rk9OVCANCiAgc2l6ZT0zPjxCUj48L0ZPTlQ+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48QlI+PEJSPkhpIE5laWwsPC9GT05UPjxGT05UIA0KICBzaXplPTM+IDwvRk9O VD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj48QlI+4oCYaXQgaXMgcXVpdGUgY2xl YXIgZnJvbSBhIA0KICBzaW1wbGUgdGVjaG5pY2FsIGFuYWx5c2lzIHRoYXQgYW55IG5vbiB0b3At b2Ytc3RhY2sgbmV0d29yayBoYXMgbm8gbmVlZCBmb3IgDQogIEUtTk5JIHBlZXItcGFydGl0aW9u IHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0aW5nIHBhcnRpZXMu4oCZPC9GT05UPjxG T05UIA0KICBzaXplPTM+IDwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj48 QlI+SSBjYW5ub3QgYWdyZWUgdGhpcyANCiAgc3RhdGVtZW50LiA8QlI+Rm9yIGV4YW1wbGUsIHRo ZXJlIGFyZSB0d28gSVAgbmV0d29ya3MgYmVsb25naW5nIHRvIHR3byANCiAgb3BlcmF0b3JzLCBh IEUxIGlzIHRyYW5zcG9ydGVkIGZyb20gQSBuZXR3b3JrIHRvIEIgbmV0d29yayAoZS5nLiANCiAg RTFvdmVyUFdvdmVySVAgKSwgSVAgcGFja2V0KG5vdCBFMSkgcGFzcyBhY3Jvc3MgZm9ybSBBIHRv IEIgYXQgYm9yZGVyIG5vZGUsIHNvIA0KICB0aGVyZSBpcyBhIEUtTk5JIGJldHdlZW4gdGhlc2Ug Jm5ic3A7dHdvIElQIG5ldHdvcmsuIEluIHRoaXMgY2FzZSwgaXMgSVAgYSANCiAgdG9wLW9mLXN0 YWNrIG5ldHdvcms/PC9GT05UPjxGT05UIHNpemU9Mz4gPC9GT05UPjxGT05UIGZhY2U9c2Fucy1z ZXJpZiANCiAgc2l6ZT0yPjxCUj5Ob3cgbGV0IHVzIHJlcGxhY2UgSVAgbmV0d29ya3MgYnkgTVBM Uy1UUCBuZXR3b3JrcyAoZS5nLiANCiAgRTFvdmVyUFdvdmVyTVBMLVRQKSwgTVBMUy1UUCBuZXR3 b3JrIGlzIGF0IHNhbWUgcG9zaXRpb24gaW4gdGhlIHN0YWNrIGFzIElQIA0KICBuZXR3b3JrIGlz LCB3aHkgY2FuIElQIG5ldHdvcmsgaGF2ZSBFLU5OSSBidXQgTVBMUy1UUCBjYW5ub3Q/PC9GT05U PjxGT05UIA0KICBzaXplPTM+IDwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxC Uj48QlI+UmVnYXJkLDwvRk9OVD48Rk9OVCANCiAgc2l6ZT0zPiA8L0ZPTlQ+PEZPTlQgZmFjZT1z YW5zLXNlcmlmIHNpemU9Mj48QlI+U3VodWk8L0ZPTlQ+PEZPTlQgc2l6ZT0zPiANCiAgPEJSPjwv Rk9OVD4NCiAgPFRBQkxFIHdpZHRoPSIxMDAlIj4NCiAgICA8VEJPRFk+DQogICAgPFRSIHZBbGln bj10b3A+DQogICAgICA8VEQgd2lkdGg9IjI2JSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAg ICAgICBzaXplPTE+PEI+Jmx0O25laWwuMi5oYXJyaXNvbkBidC5jb20mZ3Q7PC9CPiA8QlI+5Y+R 5Lu25Lq6OiANCiAgICAgICAgJm5ic3A7bXBscy10cC1ib3VuY2VzQGlldGYub3JnPC9GT05UPjxG T05UIHNpemU9Mz4gPC9GT05UPg0KICAgICAgICA8UD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0xPjIwMDktMDQtMjggMTQ6NDM8L0ZPTlQ+PEZPTlQgc2l6ZT0zPiANCiAgICAgICAgPC9GT05U PjwvUD4NCiAgICAgIDxURCB3aWR0aD0iNzMlIj48QlI+DQogICAgICAgIDxUQUJMRSB3aWR0aD0i MTAwJSI+DQogICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAg ICAgICAgICAgPFREIHdpZHRoPSI2JSI+DQogICAgICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7mlLbku7bkuro8L0ZPTlQ+PC9ESVY+DQogICAg ICAgICAgICA8VEQgd2lkdGg9IjkzJSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICAgICAgICAg ICAgICBzaXplPTE+Jmx0O2hoZWx2b29ydEBjaGVsbG8ubmwmZ3Q7LCAmbHQ7YWRyaWFuQG9sZGRv Zy5jby51ayZndDssIA0KICAgICAgICAgICAgICAmbHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0Bi dC5jb20mZ3Q7PC9GT05UPjxGT05UIHNpemU9Mz4gPC9GT05UPg0KICAgICAgICAgIDxUUiB2QWxp Z249dG9wPg0KICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0 PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+5oqE6YCBPC9GT05UPjwvRElWPg0KICAgICAg ICAgICAgPFREPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+bXBscy10cEBpZXRmLm9yZzwv Rk9OVD48Rk9OVCANCiAgICAgICAgICAgICAgc2l6ZT0zPiA8L0ZPTlQ+DQogICAgICAgICAgPFRS IHZBbGlnbj10b3A+DQogICAgICAgICAgICA8VEQ+DQogICAgICAgICAgICAgIDxESVYgYWxpZ249 cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT7kuLvpopg8L0ZPTlQ+PC9ESVY+DQog ICAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT5SZTogW21wbHMtdHBd IEFJUy9GREkgKHdhcyANCiAgICAgICAgICAgICAgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRy YW5zcG9ydCBwYXRoICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAgICAgICAgICAgICAmbmJzcDty ZXF1aXJlbWVudHMpPC9GT05UPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48Rk9OVCANCiAgICAg ICAgc2l6ZT0zPjxCUj48L0ZPTlQ+PEJSPg0KICAgICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0K ICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICAg IDxURCB3aWR0aD0iNTAlIj4NCiAgICAgICAgICAgIDxURCB3aWR0aD0iNTAlIj48L1RSPjwvVEJP RFk+PC9UQUJMRT48QlI+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjxGT05UIA0KICBzaXplPTM+ PEJSPjxCUj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjxUVD48QlI+PEJSPkh1dWIgd3JvdGUgMjcgQXBy aWwgMjAwOSANCiAgMjI6Mjc8QlI+Jmd0OyA8QlI+Jmd0OyBIaSBBZHJpYW4sPEJSPiZndDsgPEJS PiZndDsgWW91IHdyb3RlOjxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KICAmZ3Q7IElzbid0IHRoZSBzb2x1 dGlvbiBoZXJlIHRoZSBzYW1lIGFzIHRoZSBvbmUgSSBwcm9wb3NlZCBmb3IgIlRDTSI/PEJSPiZn dDsgDQogIDxCUj4mZ3Q7IEluZGVlZCwgYW5kIHRoYXQgd2UgZG8gbm90IGhhdmUgdG8gYXJvdW5k IGluIGNpcmNsZXMgYWJvdXQgDQogIFRDTS48QlI+Jmd0OyA8QlI+Jmd0OyBIb3cgYWJvdXQ6PEJS PiZndDsgdGhlIHJlcXVpcmVtZW50IGlzIHRoYXQgYSBzZXJ2ZXIgDQogIGxheWVyIHNoYWxsIGlu Zm9ybSBpdHMgY2xpZW50czxCUj4mZ3Q7IHRoYXQgaXQgaGFzIGRldGVjdGVkIGEgc2VydmljZSAN CiAgaW50ZXJ1cHRpb24sIHRoaXMgdG8gZW5zdXJlIHRoYXQ8QlI+Jmd0OyB0aGUgY2xpZW50cyBj YW4gaW5oaWJpdCAodW5uZWNlc3NhcnkpIA0KICBhbGFybXMuPEJSPjxCUj5OSD0mZ3Q7IFRoaXMg b25seSBhcHBsaWVzIGlmIHRoZSBjbGllbnQvc2VydmVyIGJpbmRpbmcgaXMgDQogIGZpeGVkLiAm bmJzcDtBbmQgb2Y8QlI+Y291cnNlIHdheSBiYWNrIGluIHRoZSA3MHMgd2hlbiBiaW5hcnkgYWxs IDFzIHBvcHBlZCANCiAgb3V0IG9mIHRoZSBmYWlsZWQ8QlI+VFRMIGxvZ2ljIGludG8gdGhlIFBE SCB0cmFuc3BvcnQgaGllcmFyY2h5IHRoaXMgd2FzIHRydWUuIA0KICAmbmJzcDtBbHNvOiBubzxC Uj5sYWJlbHMgaGVyZSBhbmQgbm8gY2xpZW50IHRyYWZmaWMgdW5pdHMgdG8gY3JlYXRlLiAmbmJz cDsgDQogIDxCUj48QlI+V2hlcmUgdGhlIGNsaWVudCBjYW4gZHluYW1pY2FsbHkgYmUgcmUtcm91 dGVkIGluIHJlc3BvbnNlIHRvIGEgDQogIHNlcnZlcjxCUj5mYWlsdXJlIHRoZSBwcm9wb3NlZCB0 ZXh0IGlzIG5vdCB2YWxpZC4gJm5ic3A7SXQgaXMgYWxzbyBub3QgDQogIG5lY2Vzc2FyeSB0aGF0 PEJSPnRoZSBzZXJ2ZXIgaGFzIHRvIGtlZXAgdHJhY2sgb2Ygd2hlcmUgaXRzIGNsaWVudCB0cmFm ZmljIA0KICByb3V0aW5ncyBoYXZlPEJSPm1vdmVkIHRvLiAmbmJzcDtGb3IgZXhhbXBsZSwgaWYg SSBjcmVhdGUgdGhlIHRvcG9sb2d5IG9mIGFuIA0KICBJUCBsYXllciBuZXR3b3JrPEJSPndpdGgg bGlua3MgcHJvdmlkZWQgYnkgU0RILCBFdGhlcm5ldCwgQVRNLCBPVE4sIGV0YyANCiAgc2VydmVy cywgYW5kIGVhY2ggb2Y8QlI+dGhlc2Ugc2VydmVyIGxpbmtzIGlzIHByb3ZpZGVkIGJ5IGEgZGlm ZmVyZW50IA0KICBvcGVyYXRvciwgdGhlbiB3aHkgc2hvdWxkPEJSPnRoZSBzZXJ2ZXJzIG5lZWQg aGF2ZSBrbm93bGVkZ2Ugb2Ygd2hlcmUgdGhlIElQIA0KICBmbG93cyBoYXZlIG1vdmVkIHRvIGlu PEJSPnJlc3BvbnNlIHRvIGEgc2VydmVyIGxheWVyIGZhaWx1cmUgd2hlbiB0aGUgbmV3IA0KICBy b3V0ZXMgaGF2ZSBiZWVuPEJSPmNhbGN1bGF0ZWQgYnkgdGhlIElHUCBpbiB0aGUgSVAgbGF5ZXIg bmV0d29yaz8gJm5ic3A7SSBjYW4gDQogIGFwcGx5IHRoZSBzYW1lPEJSPmxvZ2ljIHRvIGFuIFNW Qy1iYXNlZCBjby1wcy9jby1jcyBtb2RlIGNsaWVudC4uLi5pbmRlZWQgdGhlIA0KICBjby1jcyBt b2RlPEJSPlBTVE4gaXMgbGlrZSB0aGlzLjxCUj48QlI+VGhlc2Ugb2JzZXJ2YXRpb25zIG1ha2Ug aXQgcXVpdGUgY2xlYXIgDQogIHRvIG1lIGF0IGxlYXN0IHRoYXQganVzdCBjb3B5aW5nPEJSPnRo ZSBBSVMgYmVoYXZpb3VyIG9mIHRoZSBvbGQgdHJhbnNwb3J0IA0KICBoaWVyYXJjaGllcyB0aGF0 IGhhZCBmaXhlZDxCUj5jbGllbnQvc2VydmVyIHJlbGF0aW9uc2hpcHMgaXMgbm90IGEgc2Vuc2li bGUgDQogIHRoaW5nIHRvIGRvLjxCUj48QlI+SU1PIHRoZSBvbmx5IGVzc2VudGlhbCBEUCBPQU0g cmVxdWlyZW1lbnQgaXMgdGhhdCBlYWNoIA0KICBsYXllciBuZXR3b3JrPEJSPnNob3VsZCBiZSBz ZWxmLXN1ZmZpY2llbnQgd3J0IE9BTSBhbmQgbm90IHJlbHkgb24gYW55IHNlcnZlciANCiAgbGF5 ZXI8QlI+cHJpbWl0aXZlcyBiZWluZyBwYXNzZWQgdXB3YXJkcy48QlI+PEJSPk1vcmVvdmVyLCBp dCBzaG91bGQgYWxzbyBiZSANCiAgbm90ZWQgdGhhdCAoaSkgdGhlIGRlZmVjdHMgdGhhdCBjYW4g b2NjdXIgaW48QlI+ZWFjaCBvZiB0aGUgMyBuZXR3b3JrIG1vZGVzIA0KICBhcmUgbm90IHRoZSBz YW1lIGFuZCAoaWkpIHRoZWlyIE9BTTxCUj5yZXF1aXJlbWVudHMgYXJlIG5vdCBpZGVudGljYWxs eSB0aGUgDQogIHNhbWUuIFNvIHRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvPEJSPnRoZSBjbC1wcyBt b2RlIChlZyBJUCkgaXMgbm90IHRoZSBzYW1lIGFzIA0KICB0aGUgT0FNIHRoYXQgYXBwbGllcyB0 byB0aGU8QlI+Y28tcHMgbW9kZSAoZWcgTVBMUy1UUCkgYW5kIG5laXRoZXIgb2YgdGhlc2UgaXMg DQogIGlkZW50aWNhbGx5IHRoZSBzYW1lIGFzPEJSPnRoZSBPQU0gdGhhdCBhcHBsaWVzIHRvIHRo ZSBjby1jcyBtb2RlIChlZyANCiAgU0RIKS48QlI+PEJSPk5vdGUgLSBUaGUgb25seSBwb2ludCBi ZWluZyBjb25zaWRlcmVkIGhlcmUgaXMgdGhlIHJlYWwgY2xpZW50IA0KICBhbmQ8QlI+c2VydmVy IHRyYWZmaWMgcmVsYXRpb25zaGlwLiAmbmJzcDtUaGUgY3JlYXRpb24gb2YgYSBoaWVyYXJjaHkg b2YgDQogIFRDTTxCUj5zdWJsYXllcnMgaXMgYSBzZXBhcmF0ZSB0b3BpYy4gJm5ic3A7RnVydGhl ciwgaXQgaXMgcXVpdGUgY2xlYXIgZnJvbSBhIA0KICBzaW1wbGU8QlI+dGVjaG5pY2FsIGFuYWx5 c2lzIHRoYXQgYW55IG5vbiB0b3Atb2Ytc3RhY2sgbmV0d29yayBoYXMgbm8gbmVlZCANCiAgZm9y PEJSPkUtTk5JIHBlZXItcGFydGl0aW9uIHdvcmtpbmcgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0 aW5nIHBhcnRpZXMuIA0KICAmbmJzcDtTbzxCUj50aGlzIGlzIGFsc28gYSBzZXBhcmF0ZSBpc3N1 ZS4gJm5ic3A7SG93ZXZlciwgSSBwcm9wb3NlIHRoYXQgdGhpcyANCiAgbGF0dGVyPEJSPnBvaW50 IGJlIGNhcHR1cmVkIGluIHRoZSBNUExTLVRQIHJlcXVpcmVtZW50cyBkcmFmdCBkdWUgdG8gDQog IGl0czxCUj5zdGFuZC1hbG9uZSBhbmQgZ2VuZXJpYyBpbXBvcnRhbmNlLCBpZSB0aGlzIGFwcGxp ZXMgdG8gbW9yZSB0aGFuIGp1c3QgDQogIERQPEJSPk9BTS4gJm5ic3A7QmVuIGNhbiB5b3UgcGxl YXNlIGNvbnNpZGVyIHRoaXMgcG9pbnQgYXMvd2hlbiB0aGUgDQogIE1QTFMtVFA8QlI+cmVxdWly ZW1lbnRzIGRyYWZ0IGlzIHVwZGF0ZWQuPEJSPjxCUj5yZWdhcmRzLCBOZWlsPEJSPjxCUj4mZ3Q7 IA0KICBDaGVlcnMsIEh1dWIuPEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPEJSPm1wbHMtdHAgDQogIG1haWxpbmcgDQogIGxpc3Q8QlI+bXBscy10cEBp ZXRmLm9yZzxCUj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8 L1RUPjwvRk9OVD48Rk9OVCANCiAgc2l6ZT0zPjxCUj48QlI+PC9GT05UPjxGT05UIA0KICBzaXpl PTM+PFRUPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxCUj5aVEUgDQogIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IA0KICBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyAN CiAgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIA0KICBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQogIG90aGVycy48QlI+VGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgDQogIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCiAgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIA0KICBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgDQogIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48QlI+VGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gDQogIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt LjwvVFQ+PC9GT05UPjxGT05UIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48QlI+PEZPTlQgDQogIHNp emU9Mz48VFQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08QlI+WlRFIA0KICBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSANCiAgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQog IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSANCiAgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0KICBvdGhlcnMuPEJSPlRoaXMgZW1h aWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5k IA0KICBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgDQogIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCiAgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIA0KICB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuPEJSPlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIA0KICBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48 QlI+PC9UVD48L0ZPTlQ+PEJSPjxCUj48UFJFPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1Nl Y3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFp bmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7 cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9u LiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29u ZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJl Jm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDth bmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3Nl Jm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDth bnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJl Jm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJz cDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUm bmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQm bmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7 bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVz c2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7 YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3Bh bSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9QUkU+PC9C TE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C9C95C.D4138268-- From jingr@ties.itu.ch Wed Apr 29 23:35:17 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847D03A6EC2 for ; Wed, 29 Apr 2009 23:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4i7OXFbXyDz for ; Wed, 29 Apr 2009 23:35:16 -0700 (PDT) Received: from protext01.itu.ch (protext01.itu.ch [156.106.192.41]) by core3.amsl.com (Postfix) with ESMTP id 5B6003A6E0B for ; Wed, 29 Apr 2009 23:35:16 -0700 (PDT) Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Apr 2009 08:36:38 +0200 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1241073397554; Thu, 30 Apr 2009 08:36:37 +0200 Received: from ties.itu.ch (ties.itu.ch [156.106.192.33]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id n3U6aZgY214294; Thu, 30 Apr 2009 08:36:36 +0200 (MEST) Received: from localhost (tokaj.itu.ch [156.106.192.34]) by ties.itu.ch (8.14.3/8.14.3) with ESMTP id n3U6aZ7p290355; Thu, 30 Apr 2009 08:36:35 +0200 (CEST) Received: from 156.106.192.159 ( [156.106.192.159]) as user jingr@ties.itu.ch by gold.itu.ch with HTTP; Thu, 30 Apr 2009 08:36:35 +0200 Message-ID: <1241073395.49f946f31420d@gold.itu.ch> Date: Thu, 30 Apr 2009 08:36:35 +0200 From: ruiquan.jing@ties.itu.int To: mpls-tp@ietf.org, maarten.vissers@huawei.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 156.106.192.159 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (mail6.itu.ch [156.106.192.22]); Thu, 30 Apr 2009 08:36:37 +0200 (MEST) X-OriginalArrivalTime: 30 Apr 2009 06:36:38.0257 (UTC) FILETIME=[03AD5610:01C9C95E] Subject: Re: [mpls-tp] Interworking X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:35:17 -0000 Hi Maarten, Please see inline. -----Original Message----- From: Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: Thursday, April 30, 2009 12:55 PM To: ruiquan.jing@ties.itu.int; mpls-tp@ietf.org Subject: RE: [mpls-tp] Interworking Hi Jing, The difference between (3) and (4) is the following: (3) all services are supported via the EVC layer; i.e. the EVC layer is the service/channel layer and starts/ends at the UNI-N ports. The PW is a SS-PW layer and monitors p2p EVC link connections. PE nodes switch/bridge only EVC signals (as all customer service signals are supported via EVCs). ------ (4) the p2p and p2mp services are supported via the PW layer (MS-PW) and the rmp and mp2mp services are supported via the EVC layer; i.e. the PW layer is the service/channel layer for p2p/p2mp services and for those services start/end at the UNI-N ports, while the EVC layer is the service/channel layer for rmp/mp2mp services and for those services start/end at the UNI-N ports. Jingrq->So you mean for the rmp and mp2mp services, we don't need PW layers. I think there are two problems with this approach. Firstly, this is different from the practice of VPLS in MPLS network. Secondly, I think there are scalability problem in core network without PW layers. Rmp/mp2mp customer services (Ethernet) are either clients of the EVC layer, or peer with the EVC layer. P2p/p2mp customer services (PDH, SDH, ATM, Ethernet, ..) are clients fo the PW layer (and may in future also peer with the PW layer). PE nodes will be able to switch/bridge both PW and EVC signals. Switch fabrics must support as such PW switching and Ethernet bridging/switching. PW connections terminate on the UNI-N ports for the case of p2p/p2mp services. PW connections terminate on the NNI ports for the case of rmp/mp2mp services. ------ Interconnecting a MPLS-TP domain according to layer stack (4) with an Ethernet domain with layer stack (5) via an 802.3 interface results in the following for rmp/mp2mp services (Ethernet E-Tree, E-LAN): (5) (4) ----------------------------------- | EVC EVC EVC | ---------------------------------------- | EVP | | 802.3 | | PW | ------------ --------- ------------ | T.Media | | LSP | ------------ ------------ | T.Media | ------------ Jingrq-> I think above layer stack should be the common one for all the services, not only for EVC, but for all the services (PDH CES, ATM, SDH CES, ..) Best Regards Jing Ruiquan From benjamin.niven-jenkins@bt.com Thu Apr 30 00:06:40 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C8D3A6C7D for ; Thu, 30 Apr 2009 00:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV848bs4fC57 for ; Thu, 30 Apr 2009 00:06:38 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 789113A686A for ; Thu, 30 Apr 2009 00:06:38 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 08:08:00 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Apr 2009 07:08:00 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 30 Apr 2009 08:07:57 +0100 From: Ben Niven-Jenkins To: Maarten Vissers , Message-ID: Thread-Topic: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) Thread-Index: AcnIsXcTm9FBL9rkQFC9YRk9CsewQgAQmpvQABW/9iAABeCJ2g== In-Reply-To: <002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Apr 2009 07:08:00.0107 (UTC) FILETIME=[6558DBB0:01C9C962] Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:06:40 -0000 Eh? Tom & Nurit (and I) agree that SPs should speak for themselves on what their requirements are for MPLS-TP. I am supporting PDH, Ethernet and ATM services over my MPLS network today and my MPLS network does not perform AIS insertion at all so I do not see how a lack of AIS in MPLS (or MPLS-TP) impacts those standards. Maybe the issue is between an understanding of the theoretical and of the practical. As stated, in practice I am supporting the network types above without problems even though the MPLS network supporting them does not support AIS. Let's not confuse things and let's not scare monger huge changes that IMO do not exist. Ben On 30/04/2009 05:26, "Maarten Vissers" wrote: > We are discussing a change of a general fault management principle. This > change will impact the following recommendations: G.806 (generic), G.7710 > (generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN), > G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and G.8121/G.8112/G.8151 > (MPLS-TP). This proposed change has implications beyond the scope of MPLS-TP > and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: woensdag 29 april 2009 19:57 > To: ext Thomas Nadeau > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) > > I agree! > > -----Original Message----- > From: ext Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Wednesday, April 29, 2009 1:01 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) > > > It would be best is these "Tier-1 SPs" would comment directly on > the > list or contribute to the requirements draft. > > --Tom > > > On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) > wrote: > >> Neil, >> Thanks for the very good explanation. It really helps me to understand >> better the context of the long discussion. >> Personally I got many feedbacks from Tier-1 SPs that they would like >> to >> have the capability to suppress alarms in a packet transport >> environment. Their requirement was that if a server layer (e.g. MPLS- >> TP >> link) fails, there is a way to notify the client layer (e.g. LSPs) in >> order to be able to suppress alarms at the client layer that may >> result >> from the fault at the server layer (e.g. MPLS-TP link). >> Isn't it a logical and reasonable requirement in a transport profile? >> Also I saw general requirements for inter-layer fault correlation. So >> can I understand from your mail that you are not happy from such a >> requirement as well? >> Best regards, >> Nurit >> >> >> >> -----Original Message----- >> From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: Tuesday, April 28, 2009 11:07 AM >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); >> Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional >> transportpathrequirements) >> >> Nurit, >> >> I believe the reason we need this discussion is that there is an >> unstated assumption here that the client/server relationship is fixed. >> However, if the client can dynamically change its routing in >> response to >> link failures in its topology (because some server layer network has >> failed....which may or may not belong to the same operating party as >> the >> client) then there is no fixed client/server relationship. >> >> Refer to my post earlier today and consider what this means in the >> case >> of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs >> mode >> client layer network. The key point here is the *routing process* in >> the client is independent of the server layer network....so there is >> not >> a fixed client/server relationship. Further, there is also no >> requirement for the server to keep track of where its client traffic >> routings are at any epoch.....indeed why should it in the general case >> where these are independent layer networks? >> >> So the only OAM requirement that is critical is that the OAM of the >> client and server layer networks are independent. It is thus not >> sensible to make client layer alarm supression a 'requirement' >> here...in >> fact if this is in the OAM requirements then it is technically wrong >> and >> should be removed IMO. >> >> regards, Neil >>> -----Original Message----- >>> From: mpls-tp-bounces@ietf.org >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >>> Nurit (NSN - IL/Hod HaSharon) >>> Sent: 28 April 2009 08:46 >>> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >>> transportpathrequirements) >>> >>> If we agree that the requirement is included, so why do we >>> keep with the >>> endless discussions on this requirement? >>> >>> -----Original Message----- >>> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >>> Sent: Tuesday, April 28, 2009 10:44 AM >>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); >>> hhelvoort@chello.nl; Adrian >>> Farrel >>> Cc: mpls-tp@ietf.org >>> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional >>> transport >>> pathrequirements) >>> >>> I think that the requirements are defined in section 2.2.8 of >>> draft-ietf-mpls-tp-oam-requirements-01 >>> >>> Italo >>> >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org >>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, >>>> Nurit (NSN - IL/Hod HaSharon) >>>> Sent: Tuesday, April 28, 2009 6:56 AM >>>> To: hhelvoort@chello.nl; Adrian Farrel >>>> Cc: mpls-tp@ietf.org >>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >>>> transport pathrequirements) >>>> >>>> Huub, >>>> I think that the requirement is to provide a mechanism to suppress >>>> alarms in the networks, to ensure that alarms that may be >>> generated by >>>> client layers as a result of a failure condition in the >>>> server layer may >>>> be suppressed. >>>> Every thing else is a solution, etc. >>>> I propose to phrase the requirement appropriately and conclude the >>>> discussion on this in the context of the requirements (until we are >>>> getting to the solution phase). >>>> This requirement is included in the OAM requirement draft. >>>> Best regards, >>>> NUrit >>>> >>>> >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >>>> Behalf Of ext Huub van Helvoort >>>> Sent: Tuesday, April 28, 2009 12:27 AM >>>> To: Adrian Farrel >>>> Cc: mpls-tp@ietf.org >>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated >>> bidirectional transport >>>> path requirements) >>>> >>>> Hi Adrian, >>>> >>>> You wrote: >>>> >>>>> Isn't the solution here the same as the one I proposed for "TCM"? >>>> >>>> Indeed, and that we do not have to around in circles about TCM. >>>> >>>> How about: >>>> the requirement is that a server layer shall inform its clients >>>> that it has detected a service interuption, this to ensure that >>>> the clients can inhibit (unnecessary) alarms. >>>> >>>> Cheers, Huub. >>>> >>>> -- >>>> ================================================================ >>>> http://www.van-helvoort.eu/ >>>> ================================================================ >>>> Always remember that you are unique...just like everyone else... >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From BETTS01@nortel.com Thu Apr 30 05:32:35 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57ADA3A6DDB for ; Thu, 30 Apr 2009 05:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui3spIzWrdsz for ; Thu, 30 Apr 2009 05:32:33 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 802103A6AD6 for ; Thu, 30 Apr 2009 05:32:33 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3UCWtQ28181 for ; Thu, 30 Apr 2009 12:32:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 08:33:44 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516F9607C@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) Thread-Index: AcnIsXcTm9FBL9rkQFC9YRk9CsewQgAQmpvQABW/9iAAAOdA0AAPrgAA References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> From: "Malcolm Betts" To: Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:32:35 -0000 ad hoc MPLS-TP co chair hat on: All, the agreement between the IETF and the ITU is that the IETF will develop MPLS-TP to fully meet the requirements of the transport network. Clearly the requirements for MPLS-TP cannot and will not retroactively change the requirements and functionality already deployed in transport network. A few days (and probably a few hundred messages) ago I thought we had reached convergence on this issue. We need to separate the requirement from the implementation. AIS is an implementation with an implicit requirement. >From the perspective of the requirements: When a MPLS-TP equipment (or node) detects a loss of CC messages it MUST be able to determine if that loss is caused by a fault that's a) in the local node or locally terminated link: or b) a fault in a remote node or remotely terminated link. The mechanism used to provide this local/remote fault distinction SHOULD be highly reliable. This is the function performed by AIS in PDH/SDH networks. When we start working on the solutions draft we can decide how this requirement can be met, we may also consider if the complexity of the implementation is such that meeting this requirement is not a good "engineering decision" - e.g. the implementation would not yield a highly reliable result. I will draft provide some draft text for the OAM requirements draft to reflect this. So for the moment can we please focus the discussion on the requirement. I hope that this will allow us to close this point with respect to the requirement. Malcolm Betts ad hoc MPLS-TP co chair Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam) Sent: Thursday, April 30, 2009 12:59 AM To: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) All I can say is that the impact of this proposed change is very serious.=20 Doesn't MPLS-TP suppose to meet the ITU-T transport requirements instead of changing the ITU-T transport requirements? Regards, Kam > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Maarten Vissers > Sent: Thursday, April 30, 2009 12:27 AM > To: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > We are discussing a change of a general fault management principle. This > change will impact the following recommendations: G.806 (generic), G.7710 > (generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN), > G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and > G.8121/G.8112/G.8151 > (MPLS-TP). This proposed change has implications beyond the scope of MPLS- > TP > and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: woensdag 29 april 2009 19:57 > To: ext Thomas Nadeau > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated > bidirectionaltransportpathrequirements) >=20 > I agree! >=20 > -----Original Message----- > From: ext Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Wednesday, April 29, 2009 1:01 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > transportpathrequirements) >=20 >=20 > It would be best is these "Tier-1 SPs" would comment directly on the=20 > list or contribute to the requirements draft. >=20 > --Tom >=20 >=20 > On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) > wrote: >=20 > > Neil, > > Thanks for the very good explanation. It really helps me to understand > > better the context of the long discussion. > > Personally I got many feedbacks from Tier-1 SPs that they would like > > to have the capability to suppress alarms in a packet transport=20 > > environment. Their requirement was that if a server layer (e.g. MPLS- > > TP > > link) fails, there is a way to notify the client layer (e.g. LSPs) in > > order to be able to suppress alarms at the client layer that may=20 > > result from the fault at the server layer (e.g. MPLS-TP link). > > Isn't it a logical and reasonable requirement in a transport profile? > > Also I saw general requirements for inter-layer fault correlation. So > > can I understand from your mail that you are not happy from such a=20 > > requirement as well? > > Best regards, > > Nurit > > > > > > > > -----Original Message----- > > From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Tuesday, April 28, 2009 11:07 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; adrian@olddog.co.uk > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > > > > Nurit, > > > > I believe the reason we need this discussion is that there is an=20 > > unstated assumption here that the client/server relationship is fixed. > > However, if the client can dynamically change its routing in=20 > > response to link failures in its topology (because some server layer > > network has failed....which may or may not belong to the same=20 > > operating party as the > > client) then there is no fixed client/server relationship. > > > > Refer to my post earlier today and consider what this means in the=20 > > case of a cl-ps IP client layer network or a some SVC-based=20 > > co-ps/co-cs mode client layer network. The key point here is the=20 > > *routing process* in > > the client is independent of the server layer network....so there is > > not a fixed client/server relationship. Further, there is also no=20 > > requirement for the server to keep track of where its client traffic > > routings are at any epoch.....indeed why should it in the general case > > where these are independent layer networks? > > > > So the only OAM requirement that is critical is that the OAM of the=20 > > client and server layer networks are independent. It is thus not=20 > > sensible to make client layer alarm supression a 'requirement' > > here...in > > fact if this is in the OAM requirements then it is technically wrong > > and should be removed IMO. > > > > regards, Neil > >> -----Original Message----- > >> From: mpls-tp-bounces@ietf.org > >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > >> - IL/Hod HaSharon) > >> Sent: 28 April 2009 08:46 > >> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > >> Cc: mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > >> transportpathrequirements) > >> > >> If we agree that the requirement is included, so why do we keep=20 > >> with the endless discussions on this requirement? > >> > >> -----Original Message----- > >> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > >> Sent: Tuesday, April 28, 2009 10:44 AM > >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > >> Adrian Farrel > >> Cc: mpls-tp@ietf.org > >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > >> transport > >> pathrequirements) > >> > >> I think that the requirements are defined in section 2.2.8 of > >> draft-ietf-mpls-tp-oam-requirements-01 > >> > >> Italo > >> > >>> -----Original Message----- > >>> From: mpls-tp-bounces@ietf.org > >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit=20 > >>> (NSN - IL/Hod HaSharon) > >>> Sent: Tuesday, April 28, 2009 6:56 AM > >>> To: hhelvoort@chello.nl; Adrian Farrel > >>> Cc: mpls-tp@ietf.org > >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > >>> transport pathrequirements) > >>> > >>> Huub, > >>> I think that the requirement is to provide a mechanism to suppress > >>> alarms in the networks, to ensure that alarms that may be > >> generated by > >>> client layers as a result of a failure condition in the server=20 > >>> layer may be suppressed. > >>> Every thing else is a solution, etc. > >>> I propose to phrase the requirement appropriately and conclude the > >>> discussion on this in the context of the requirements (until we are > >>> getting to the solution phase). > >>> This requirement is included in the OAM requirement draft. > >>> Best regards, > >>> NUrit > >>> > >>> > >>> -----Original Message----- > >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > >>> Behalf Of ext Huub van Helvoort > >>> Sent: Tuesday, April 28, 2009 12:27 AM > >>> To: Adrian Farrel > >>> Cc: mpls-tp@ietf.org > >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated > >> bidirectional transport > >>> path requirements) > >>> > >>> Hi Adrian, > >>> > >>> You wrote: > >>> > >>>> Isn't the solution here the same as the one I proposed for "TCM"? > >>> > >>> Indeed, and that we do not have to around in circles about TCM. > >>> > >>> How about: > >>> the requirement is that a server layer shall inform its clients=20 > >>> that it has detected a service interuption, this to ensure that=20 > >>> the clients can inhibit (unnecessary) alarms. > >>> > >>> Cheers, Huub. > >>> > >>> -- > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> http://www.van-helvoort.eu/=20 > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> Always remember that you are unique...just like everyone else... > >>> _______________________________________________ > >>> mpls-tp mailing list > >>> mpls-tp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>> _______________________________________________ > >>> mpls-tp mailing list > >>> mpls-tp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>> > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > >> > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From gnewsome@ieee.org Thu Apr 30 06:15:05 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E243A6B3D for ; Thu, 30 Apr 2009 06:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4Nc8xvHDRk7 for ; Thu, 30 Apr 2009 06:15:03 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id A20CF3A71DC for ; Thu, 30 Apr 2009 06:15:03 -0700 (PDT) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 3E2E613220; Thu, 30 Apr 2009 09:16:03 -0400 (EDT) Received: from [192.168.1.35] (unknown [72.169.170.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 553151321B; Thu, 30 Apr 2009 09:15:57 -0400 (EDT) Message-ID: <49F9A482.5020603@ieee.org> Date: Thu, 30 Apr 2009 09:15:46 -0400 From: George Newsome User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Lam, Hing-Kam $Kam$" References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net> <002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 0E2EF61A-3589-11DE-9BB2-D766E3C8547C-03525878!a-sasl-quonix.pobox.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:15:05 -0000 Lam, Hing-Kam (Kam) wrote: > All I can say is that the impact of this proposed change is very > serious. > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements instead > of changing the ITU-T transport requirements? > > Hi Kam, AIS, which we are so very comfortable with, is a solution to a rather poorly stated requirement. The requirement is to distinguish between local faults (things that can be fixed here) and remote faults (things that have to be fixed elsewhere). PDH (and SDH/OTN) emits bits whatever the state of the incoming signal and in the days of TTL, an open input was pulled up to 1. So extremely old PDH equipment, emitted a stream of all 1's when its input was open. This allowed a convenient simple distinction between a valid traffic signal, which has at least some 0's in it, and a remote failed signal. It also provided a signal which checked the media between regenerators, and coincidentally, was propagated downstream for free. And so we got AIS. It wasn't introduced to do stuff; it was just there as a result of an open input. Today we are trying to capture the requirements that the AIS implementation satisfies ,so that we do not repeat the common mistake of copying SDH solutions directly into a fundamentally different technology. mpls-tp is not about changing what a transport network does, but it is quite fundamentally changing how it does it. Regards, George From John.E.Drake2@boeing.com Thu Apr 30 06:30:28 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E7328C147 for ; Thu, 30 Apr 2009 06:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkdTZTnR8d1S for ; Thu, 30 Apr 2009 06:30:27 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 9204E3A6E52 for ; Thu, 30 Apr 2009 06:30:27 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3UDVhQO025989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 06:31:44 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3UDVhkP029170; Thu, 30 Apr 2009 08:31:43 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3UDVRaP028711; Thu, 30 Apr 2009 08:31:43 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 06:31:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 06:31:33 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <49F9A482.5020603@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) Thread-Index: AcnJleFGBDuvlMtyQB+gZCfSszjZhQAAe1MQ References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> <49F9A482.5020603@ieee.org> From: "Drake, John E" To: "George Newsome" , "Lam, Hing-Kam (Kam)" X-OriginalArrivalTime: 30 Apr 2009 13:31:35.0161 (UTC) FILETIME=[FB636690:01C9C997] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:30:28 -0000 George, An excellent note. Thanks, John=20 > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org]=20 > Sent: Thursday, April 30, 2009 6:16 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was=20 > Associatedbidirectionaltransportpathrequirements) >=20 > Lam, Hing-Kam (Kam) wrote: > > All I can say is that the impact of this proposed change is very=20 > > serious. > > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements=20 > > instead of changing the ITU-T transport requirements? > >=20 > > > Hi Kam, >=20 > AIS, which we are so very comfortable with, is a solution to=20 > a rather poorly stated requirement. The requirement is to=20 > distinguish between local faults (things that can be fixed=20 > here) and remote faults (things that have to be fixed elsewhere). >=20 > PDH (and SDH/OTN) emits bits whatever the state of the=20 > incoming signal and in the days of TTL, an open input was=20 > pulled up to 1. So extremely old PDH equipment, emitted a=20 > stream of all 1's when its input was open. >=20 > This allowed a convenient simple distinction between a valid=20 > traffic signal, which has at least some 0's in it, and a=20 > remote failed signal.=20 > It also provided a signal which checked the media between=20 > regenerators, and coincidentally, was propagated downstream for free. >=20 > And so we got AIS. It wasn't introduced to do stuff; it was=20 > just there as a result of an open input. >=20 > Today we are trying to capture the requirements that the AIS=20 > implementation satisfies ,so that we do not repeat the common=20 > mistake of copying SDH solutions directly into a=20 > fundamentally different technology. >=20 > mpls-tp is not about changing what a transport network does,=20 > but it is quite fundamentally changing how it does it. >=20 > Regards, >=20 > George > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From BETTS01@nortel.com Thu Apr 30 06:50:35 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D329C3A6F55 for ; Thu, 30 Apr 2009 06:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaYQfos2ojb9 for ; Thu, 30 Apr 2009 06:50:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2F8073A6E23 for ; Thu, 30 Apr 2009 06:50:33 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3UDpKV24817; Thu, 30 Apr 2009 13:51:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 09:51:18 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> In-Reply-To: <51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) Thread-Index: AcnJleFGBDuvlMtyQB+gZCfSszjZhQAAe1MQAABcwcA= References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com><49F9A482.5020603@ieee.org> <51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> From: "Malcolm Betts" To: "Drake, John E" , "George Newsome" , "Lam, Hing-Kam (Kam)" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:50:35 -0000 George,=20 I agree, a good historical perspective of how, in transport networks we have arrived in the state where AIS is an implementation with an implicit requirement rooted in TDM networks. The discussion on MPLS-TP has forced us to separate out the requirement (local vs. remote fault) from the implementation - insert all "1"s" in TDM signals. Given that MPLS-TP will be used in a transport network I see no reason to change the requirement. However, as you point out, the inherent differences between TDM and packet networks forces us to consider alternate implementations - all "1's" is not a valid packet signal..... So as I suggested in my previous post can we agree on the requirement. We can then discuss the implementation. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E Sent: Thursday, April 30, 2009 9:32 AM To: George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) George, An excellent note. Thanks, John=20 > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Thursday, April 30, 2009 6:16 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) >=20 > Lam, Hing-Kam (Kam) wrote: > > All I can say is that the impact of this proposed change is very=20 > > serious. > > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements=20 > > instead of changing the ITU-T transport requirements? > >=20 > > > Hi Kam, >=20 > AIS, which we are so very comfortable with, is a solution to a rather=20 > poorly stated requirement. The requirement is to distinguish between=20 > local faults (things that can be fixed > here) and remote faults (things that have to be fixed elsewhere). >=20 > PDH (and SDH/OTN) emits bits whatever the state of the incoming signal > and in the days of TTL, an open input was pulled up to 1. So extremely > old PDH equipment, emitted a stream of all 1's when its input was=20 > open. >=20 > This allowed a convenient simple distinction between a valid traffic=20 > signal, which has at least some 0's in it, and a remote failed signal. > It also provided a signal which checked the media between=20 > regenerators, and coincidentally, was propagated downstream for free. >=20 > And so we got AIS. It wasn't introduced to do stuff; it was just there > as a result of an open input. >=20 > Today we are trying to capture the requirements that the AIS=20 > implementation satisfies ,so that we do not repeat the common mistake=20 > of copying SDH solutions directly into a fundamentally different=20 > technology. >=20 > mpls-tp is not about changing what a transport network does, but it is > quite fundamentally changing how it does it. >=20 > Regards, >=20 > George > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From IBryskin@advaoptical.com Thu Apr 30 07:18:42 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8DB3A6826 for ; Thu, 30 Apr 2009 07:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+UJYz9rB80u for ; Thu, 30 Apr 2009 07:18:41 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [213.70.90.131]) by core3.amsl.com (Postfix) with ESMTP id 29D113A680E for ; Thu, 30 Apr 2009 07:18:40 -0700 (PDT) Received: from muc-srv-mimesweeper.advaoptical.com (muc-srv-mimesweeper.advaoptical.com [10.200.0.15]) by mail.advaoptical.com (8.14.1/8.14.1) with ESMTP id n3UEJmg1030580 for ; Thu, 30 Apr 2009 16:19:48 +0200 Received: from muc-srv-exhub.advaoptical.com (muc-srv-exhub.advaoptical.com) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 30 Apr 2009 16:20:04 +0200 Received: from atl-srv-exgen.atl.advaoptical.com (172.16.5.27) by muc-srv-exhub.advaoptical.com (172.20.1.44) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Apr 2009 16:19:47 +0200 Received: from atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) by atl-srv-exgen.atl.advaoptical.com ([172.16.5.27]) with mapi; Thu, 30 Apr 2009 10:19:46 -0400 From: Igor Bryskin To: Malcolm Betts , "Drake, John E" , George Newsome , "Lam, Hing-Kam (Kam)" Date: Thu, 30 Apr 2009 10:19:44 -0400 Thread-Topic: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) Thread-Index: AcnJleFGBDuvlMtyQB+gZCfSszjZhQAAe1MQAABcwcAAAKNjIA== Message-ID: <052C67B4ED558D41BBDEA7CA9FC6DCDC145B345CEF@atl-srv-exgen.atl.advaoptical.com> References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com><49F9A482.5020603@ieee.org> <51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:18:42 -0000 I completely agree with George and Malcolm. There is one thing to say=20 a) we don't like AIS in MPLS-TP the way it is implemented in SDH=20 and quite different thing to say b) we don't like AIS in MPLS-TP because it brings nothing but complexity an= d confusion=20 My vote would be "Yes" to the requirements for MPLS-TP LSP layer:=20 a) to notify its clients about failures detected in the MPLS-TP LSP layer; b) to honor such notifications from its own server(s) by (temporarily) supp= ressing recovery operations in the MPLS-TP LSP layer that would occur in th= e absence of such notifications. Igor=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Malcolm Betts Sent: Thursday, April 30, 2009 9:51 AM To: Drake, John E; George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequ= irements) George,=20 I agree, a good historical perspective of how, in transport networks we have arrived in the state where AIS is an implementation with an implicit requirement rooted in TDM networks. The discussion on MPLS-TP has forced us to separate out the requirement (local vs. remote fault) from the implementation - insert all "1"s" in TDM signals. Given that MPLS-TP will be used in a transport network I see no reason to change the requirement. However, as you point out, the inherent differences between TDM and packet networks forces us to consider alternate implementations - all "1's" is not a valid packet signal..... So as I suggested in my previous post can we agree on the requirement. We can then discuss the implementation. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E Sent: Thursday, April 30, 2009 9:32 AM To: George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) George, An excellent note. Thanks, John=20 > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Thursday, April 30, 2009 6:16 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) >=20 > Lam, Hing-Kam (Kam) wrote: > > All I can say is that the impact of this proposed change is very=20 > > serious. > > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements=20 > > instead of changing the ITU-T transport requirements? > >=20 > > > Hi Kam, >=20 > AIS, which we are so very comfortable with, is a solution to a rather=20 > poorly stated requirement. The requirement is to distinguish between=20 > local faults (things that can be fixed > here) and remote faults (things that have to be fixed elsewhere). >=20 > PDH (and SDH/OTN) emits bits whatever the state of the incoming signal > and in the days of TTL, an open input was pulled up to 1. So extremely > old PDH equipment, emitted a stream of all 1's when its input was=20 > open. >=20 > This allowed a convenient simple distinction between a valid traffic=20 > signal, which has at least some 0's in it, and a remote failed signal. > It also provided a signal which checked the media between=20 > regenerators, and coincidentally, was propagated downstream for free. >=20 > And so we got AIS. It wasn't introduced to do stuff; it was just there > as a result of an open input. >=20 > Today we are trying to capture the requirements that the AIS=20 > implementation satisfies ,so that we do not repeat the common mistake=20 > of copying SDH solutions directly into a fundamentally different=20 > technology. >=20 > mpls-tp is not about changing what a transport network does, but it is > quite fundamentally changing how it does it. >=20 > Regards, >=20 > George > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From benjamin.niven-jenkins@bt.com Thu Apr 30 07:21:42 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54FC3A6F61 for ; Thu, 30 Apr 2009 07:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wv7U3TjgjBP for ; Thu, 30 Apr 2009 07:21:37 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id DB3363A6EAA for ; Thu, 30 Apr 2009 07:21:32 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 15:22:53 +0100 Received: from 10.215.40.75 ([10.215.40.75]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Apr 2009 14:22:53 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 30 Apr 2009 15:22:51 +0100 From: Ben Niven-Jenkins To: Malcolm Betts , Message-ID: Thread-Topic: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) Thread-Index: AcnIsXcTm9FBL9rkQFC9YRk9CsewQgAQmpvQABW/9iAAAOdA0AAPrgAAAAR7mQc= In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516F9607C@zcarhxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Apr 2009 14:22:53.0854 (UTC) FILETIME=[266EABE0:01C9C99F] Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:21:43 -0000 Malcolm, As always the approach you propose is reasonable and I support it (i.e. We specify the functional requirements not the solution at this stage). I look forward to your proposed text for the OAM requirements. Thanks Ben On 30/04/2009 13:33, "Malcolm Betts" wrote: > ad hoc MPLS-TP co chair hat on: > > All, the agreement between the IETF and the ITU is that the IETF will > develop MPLS-TP to fully meet the requirements of the transport network. > Clearly the requirements for MPLS-TP cannot and will not retroactively > change the requirements and functionality already deployed in transport > network. > > > A few days (and probably a few hundred messages) ago I thought we had > reached convergence on this issue. We need to separate the requirement > from the implementation. AIS is an implementation with an implicit > requirement. > > From the perspective of the requirements: > > When a MPLS-TP equipment (or node) detects a loss of CC messages it > MUST be able to determine if that loss is caused by a fault that's a) in > the local node or locally terminated link: or b) a fault in a remote > node or remotely terminated link. The mechanism used to provide this > local/remote fault distinction SHOULD be highly reliable. > > This is the function performed by AIS in PDH/SDH networks. > > When we start working on the solutions draft we can decide how this > requirement can be met, we may also consider if the complexity of the > implementation is such that meeting this requirement is not a good > "engineering decision" - e.g. the implementation would not yield a > highly reliable result. > > I will draft provide some draft text for the OAM requirements draft to > reflect this. So for the moment can we please focus the discussion on > the requirement. I hope that this will allow us to close this point with > respect to the requirement. > > > Malcolm Betts > ad hoc MPLS-TP co chair > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Lam, Hing-Kam (Kam) > Sent: Thursday, April 30, 2009 12:59 AM > To: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) > > All I can say is that the impact of this proposed change is very > serious. > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements instead > of changing the ITU-T transport requirements? > > Regards, > Kam > >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf >> Of Maarten Vissers >> Sent: Thursday, April 30, 2009 12:27 AM >> To: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] AIS/FDI (was Associated >> bidirectionaltransportpathrequirements) >> >> We are discussing a change of a general fault management principle. > This >> change will impact the following recommendations: G.806 (generic), > G.7710 >> (generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN), >> G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and >> G.8121/G.8112/G.8151 >> (MPLS-TP). This proposed change has implications beyond the scope of > MPLS- >> TP >> and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15. >> >> Regards, >> Maarten >> >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf >> Of Sprecher, Nurit (NSN - IL/Hod HaSharon) >> Sent: woensdag 29 april 2009 19:57 >> To: ext Thomas Nadeau >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] AIS/FDI (was Associated >> bidirectionaltransportpathrequirements) >> >> I agree! >> >> -----Original Message----- >> From: ext Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Wednesday, April 29, 2009 1:01 PM >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon) >> Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >> transportpathrequirements) >> >> >> It would be best is these "Tier-1 SPs" would comment directly on > the >> list or contribute to the requirements draft. >> >> --Tom >> >> >> On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) >> wrote: >> >>> Neil, >>> Thanks for the very good explanation. It really helps me to > understand >>> better the context of the long discussion. >>> Personally I got many feedbacks from Tier-1 SPs that they would like > >>> to have the capability to suppress alarms in a packet transport >>> environment. Their requirement was that if a server layer (e.g. > MPLS- >>> TP >>> link) fails, there is a way to notify the client layer (e.g. LSPs) > in >>> order to be able to suppress alarms at the client layer that may >>> result from the fault at the server layer (e.g. MPLS-TP link). >>> Isn't it a logical and reasonable requirement in a transport > profile? >>> Also I saw general requirements for inter-layer fault correlation. > So >>> can I understand from your mail that you are not happy from such a >>> requirement as well? >>> Best regards, >>> Nurit >>> >>> >>> >>> -----Original Message----- >>> From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>> Sent: Tuesday, April 28, 2009 11:07 AM >>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); >>> Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > adrian@olddog.co.uk >>> Cc: mpls-tp@ietf.org >>> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional >>> transportpathrequirements) >>> >>> Nurit, >>> >>> I believe the reason we need this discussion is that there is an >>> unstated assumption here that the client/server relationship is > fixed. >>> However, if the client can dynamically change its routing in >>> response to link failures in its topology (because some server layer > >>> network has failed....which may or may not belong to the same >>> operating party as the >>> client) then there is no fixed client/server relationship. >>> >>> Refer to my post earlier today and consider what this means in the >>> case of a cl-ps IP client layer network or a some SVC-based >>> co-ps/co-cs mode client layer network. The key point here is the >>> *routing process* > in >>> the client is independent of the server layer network....so there is > >>> not a fixed client/server relationship. Further, there is also no >>> requirement for the server to keep track of where its client traffic > >>> routings are at any epoch.....indeed why should it in the general > case >>> where these are independent layer networks? >>> >>> So the only OAM requirement that is critical is that the OAM of the >>> client and server layer networks are independent. It is thus not >>> sensible to make client layer alarm supression a 'requirement' >>> here...in >>> fact if this is in the OAM requirements then it is technically wrong > >>> and should be removed IMO. >>> >>> regards, Neil >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org >>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > >>>> - IL/Hod HaSharon) >>>> Sent: 28 April 2009 08:46 >>>> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel >>>> Cc: mpls-tp@ietf.org >>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >>>> transportpathrequirements) >>>> >>>> If we agree that the requirement is included, so why do we keep >>>> with the endless discussions on this requirement? >>>> >>>> -----Original Message----- >>>> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] >>>> Sent: Tuesday, April 28, 2009 10:44 AM >>>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; >>>> Adrian Farrel >>>> Cc: mpls-tp@ietf.org >>>> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional >>>> transport >>>> pathrequirements) >>>> >>>> I think that the requirements are defined in section 2.2.8 of >>>> draft-ietf-mpls-tp-oam-requirements-01 >>>> >>>> Italo >>>> >>>>> -----Original Message----- >>>>> From: mpls-tp-bounces@ietf.org >>>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit >>>>> (NSN - IL/Hod HaSharon) >>>>> Sent: Tuesday, April 28, 2009 6:56 AM >>>>> To: hhelvoort@chello.nl; Adrian Farrel >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional >>>>> transport pathrequirements) >>>>> >>>>> Huub, >>>>> I think that the requirement is to provide a mechanism to suppress > >>>>> alarms in the networks, to ensure that alarms that may be >>>> generated by >>>>> client layers as a result of a failure condition in the server >>>>> layer may be suppressed. >>>>> Every thing else is a solution, etc. >>>>> I propose to phrase the requirement appropriately and conclude the > >>>>> discussion on this in the context of the requirements (until we > are >>>>> getting to the solution phase). >>>>> This requirement is included in the OAM requirement draft. >>>>> Best regards, >>>>> NUrit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] > On >>>>> Behalf Of ext Huub van Helvoort >>>>> Sent: Tuesday, April 28, 2009 12:27 AM >>>>> To: Adrian Farrel >>>>> Cc: mpls-tp@ietf.org >>>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated >>>> bidirectional transport >>>>> path requirements) >>>>> >>>>> Hi Adrian, >>>>> >>>>> You wrote: >>>>> >>>>>> Isn't the solution here the same as the one I proposed for "TCM"? >>>>> >>>>> Indeed, and that we do not have to around in circles about TCM. >>>>> >>>>> How about: >>>>> the requirement is that a server layer shall inform its clients >>>>> that it has detected a service interuption, this to ensure that >>>>> the clients can inhibit (unnecessary) alarms. >>>>> >>>>> Cheers, Huub. >>>>> >>>>> -- >>>>> ================================================================ >>>>> http://www.van-helvoort.eu/ >>>>> ================================================================ >>>>> Always remember that you are unique...just like everyone else... >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From neil.2.harrison@bt.com Thu Apr 30 07:23:11 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6609E3A69B7 for ; Thu, 30 Apr 2009 07:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV5QCQpmd-jN for ; Thu, 30 Apr 2009 07:23:09 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 41B8F3A6F61 for ; Thu, 30 Apr 2009 07:23:09 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 15:24:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 15:24:18 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C047E2BD7@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516F9607C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) Thread-Index: AcnIsXcTm9FBL9rkQFC9YRk9CsewQgAQmpvQABW/9iAAAOdA0AAPrgAAAARyjsA= From: To: , X-OriginalArrivalTime: 30 Apr 2009 14:24:31.0333 (UTC) FILETIME=[6088C950:01C9C99F] Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:23:11 -0000 I support your proposal Malcolm. regards, Neil =20 Neil Harrison Chief Network Operations Strategist BT Innovate Tel: +44 (0) 1 604 820 052 Email: neil.2.harrison@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Malcolm Betts > Sent: 30 April 2009 13:34 > To: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI=20 > (wasAssociatedbidirectionaltransportpathrequirements) >=20 > ad hoc MPLS-TP co chair hat on: >=20 > All, the agreement between the IETF and the ITU is that the IETF will > develop MPLS-TP to fully meet the requirements of the=20 > transport network. > Clearly the requirements for MPLS-TP cannot and will not retroactively > change the requirements and functionality already deployed in=20 > transport > network. >=20 >=20 > A few days (and probably a few hundred messages) ago I thought we had > reached convergence on this issue. We need to separate the=20 > requirement > from the implementation. AIS is an implementation with an implicit > requirement. >=20 > From the perspective of the requirements: >=20 > When a MPLS-TP equipment (or node) detects a loss of CC messages it > MUST be able to determine if that loss is caused by a fault=20 > that's a) in > the local node or locally terminated link: or b) a fault in a remote > node or remotely terminated link. The mechanism used to provide this > local/remote fault distinction SHOULD be highly reliable. >=20 > This is the function performed by AIS in PDH/SDH networks. >=20 > When we start working on the solutions draft we can decide how this > requirement can be met, we may also consider if the complexity of the > implementation is such that meeting this requirement is not a good > "engineering decision" - e.g. the implementation would not yield a > highly reliable result. >=20 > I will draft provide some draft text for the OAM requirements draft to > reflect this. So for the moment can we please focus the discussion on > the requirement. I hope that this will allow us to close this=20 > point with > respect to the requirement. >=20 >=20 > Malcolm Betts > ad hoc MPLS-TP co chair > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Lam, Hing-Kam (Kam) > Sent: Thursday, April 30, 2009 12:59 AM > To: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) >=20 > All I can say is that the impact of this proposed change is very > serious.=20 > Doesn't MPLS-TP suppose to meet the ITU-T transport=20 > requirements instead > of changing the ITU-T transport requirements? >=20 > Regards, > Kam >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf > > Of Maarten Vissers > > Sent: Thursday, April 30, 2009 12:27 AM > > To: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > We are discussing a change of a general fault management principle. > This > > change will impact the following recommendations: G.806 (generic), > G.7710 > > (generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN), > > G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and > > G.8121/G.8112/G.8151 > > (MPLS-TP). This proposed change has implications beyond the scope of > MPLS- > > TP > > and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15. > >=20 > > Regards, > > Maarten > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf > > Of Sprecher, Nurit (NSN - IL/Hod HaSharon) > > Sent: woensdag 29 april 2009 19:57 > > To: ext Thomas Nadeau > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated > > bidirectionaltransportpathrequirements) > >=20 > > I agree! > >=20 > > -----Original Message----- > > From: ext Thomas Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: Wednesday, April 29, 2009 1:01 PM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > Cc: neil.2.harrison@bt.com; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > transportpathrequirements) > >=20 > >=20 > > It would be best is these "Tier-1 SPs" would comment directly on > the=20 > > list or contribute to the requirements draft. > >=20 > > --Tom > >=20 > >=20 > > On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) > > wrote: > >=20 > > > Neil, > > > Thanks for the very good explanation. It really helps me to > understand > > > better the context of the long discussion. > > > Personally I got many feedbacks from Tier-1 SPs that they=20 > would like >=20 > > > to have the capability to suppress alarms in a packet transport=20 > > > environment. Their requirement was that if a server layer (e.g. > MPLS- > > > TP > > > link) fails, there is a way to notify the client layer (e.g. LSPs) > in > > > order to be able to suppress alarms at the client layer that may=20 > > > result from the fault at the server layer (e.g. MPLS-TP link). > > > Isn't it a logical and reasonable requirement in a transport > profile? > > > Also I saw general requirements for inter-layer fault correlation. > So > > > can I understand from your mail that you are not happy=20 > from such a=20 > > > requirement as well? > > > Best regards, > > > Nurit > > > > > > > > > > > > -----Original Message----- > > > From: ext neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > Sent: Tuesday, April 28, 2009 11:07 AM > > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > > > Italo.Busi@alcatel-lucent.it; hhelvoort@chello.nl; > adrian@olddog.co.uk > > > Cc: mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional > > > transportpathrequirements) > > > > > > Nurit, > > > > > > I believe the reason we need this discussion is that there is an=20 > > > unstated assumption here that the client/server relationship is > fixed. > > > However, if the client can dynamically change its routing in=20 > > > response to link failures in its topology (because some=20 > server layer >=20 > > > network has failed....which may or may not belong to the same=20 > > > operating party as the > > > client) then there is no fixed client/server relationship. > > > > > > Refer to my post earlier today and consider what this=20 > means in the=20 > > > case of a cl-ps IP client layer network or a some SVC-based=20 > > > co-ps/co-cs mode client layer network. The key point here is the=20 > > > *routing process* > in > > > the client is independent of the server layer=20 > network....so there is >=20 > > > not a fixed client/server relationship. Further, there=20 > is also no=20 > > > requirement for the server to keep track of where its=20 > client traffic >=20 > > > routings are at any epoch.....indeed why should it in the general > case > > > where these are independent layer networks? > > > > > > So the only OAM requirement that is critical is that the=20 > OAM of the=20 > > > client and server layer networks are independent. It is thus not=20 > > > sensible to make client layer alarm supression a 'requirement' > > > here...in > > > fact if this is in the OAM requirements then it is=20 > technically wrong >=20 > > > and should be removed IMO. > > > > > > regards, Neil > > >> -----Original Message----- > > >> From: mpls-tp-bounces@ietf.org > > >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher,=20 > Nurit (NSN >=20 > > >> - IL/Hod HaSharon) > > >> Sent: 28 April 2009 08:46 > > >> To: ext BUSI ITALO; hhelvoort@chello.nl; Adrian Farrel > > >> Cc: mpls-tp@ietf.org > > >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional > > >> transportpathrequirements) > > >> > > >> If we agree that the requirement is included, so why do we keep=20 > > >> with the endless discussions on this requirement? > > >> > > >> -----Original Message----- > > >> From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] > > >> Sent: Tuesday, April 28, 2009 10:44 AM > > >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 > hhelvoort@chello.nl;=20 > > >> Adrian Farrel > > >> Cc: mpls-tp@ietf.org > > >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > >> transport > > >> pathrequirements) > > >> > > >> I think that the requirements are defined in section 2.2.8 of > > >> draft-ietf-mpls-tp-oam-requirements-01 > > >> > > >> Italo > > >> > > >>> -----Original Message----- > > >>> From: mpls-tp-bounces@ietf.org > > >>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit=20 > > >>> (NSN - IL/Hod HaSharon) > > >>> Sent: Tuesday, April 28, 2009 6:56 AM > > >>> To: hhelvoort@chello.nl; Adrian Farrel > > >>> Cc: mpls-tp@ietf.org > > >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional=20 > > >>> transport pathrequirements) > > >>> > > >>> Huub, > > >>> I think that the requirement is to provide a mechanism=20 > to suppress >=20 > > >>> alarms in the networks, to ensure that alarms that may be > > >> generated by > > >>> client layers as a result of a failure condition in the server=20 > > >>> layer may be suppressed. > > >>> Every thing else is a solution, etc. > > >>> I propose to phrase the requirement appropriately and=20 > conclude the >=20 > > >>> discussion on this in the context of the requirements (until we > are > > >>> getting to the solution phase). > > >>> This requirement is included in the OAM requirement draft. > > >>> Best regards, > > >>> NUrit > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] > On > > >>> Behalf Of ext Huub van Helvoort > > >>> Sent: Tuesday, April 28, 2009 12:27 AM > > >>> To: Adrian Farrel > > >>> Cc: mpls-tp@ietf.org > > >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated > > >> bidirectional transport > > >>> path requirements) > > >>> > > >>> Hi Adrian, > > >>> > > >>> You wrote: > > >>> > > >>>> Isn't the solution here the same as the one I proposed=20 > for "TCM"? > > >>> > > >>> Indeed, and that we do not have to around in circles about TCM. > > >>> > > >>> How about: > > >>> the requirement is that a server layer shall inform its clients=20 > > >>> that it has detected a service interuption, this to ensure that=20 > > >>> the clients can inhibit (unnecessary) alarms. > > >>> > > >>> Cheers, Huub. > > >>> > > >>> -- > > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>> http://www.van-helvoort.eu/=20 > > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>> Always remember that you are unique...just like everyone else... > > >>> _______________________________________________ > > >>> mpls-tp mailing list > > >>> mpls-tp@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > > >>> _______________________________________________ > > >>> mpls-tp mailing list > > >>> mpls-tp@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > > >>> > > >> _______________________________________________ > > >> mpls-tp mailing list > > >> mpls-tp@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls-tp > > >> > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From nurit.sprecher@nsn.com Thu Apr 30 07:36:38 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604DB3A6F97 for ; Thu, 30 Apr 2009 07:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FyQpUIwkORF for ; Thu, 30 Apr 2009 07:36:37 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9F20F3A6E98 for ; Thu, 30 Apr 2009 07:35:53 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3UEb4ai026764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 16:37:04 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3UEb3iM003207; Thu, 30 Apr 2009 16:37:03 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 16:37:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 16:36:57 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A75129@DEMUEXC014.nsn-intra.net> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) Thread-Index: AcnJleFGBDuvlMtyQB+gZCfSszjZhQAAe1MQAABcwcAAAcM3EA== References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com><49F9A482.5020603@ieee.org><51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Malcolm Betts" , "Drake, John E" , "George Newsome" , "Lam, Hing-Kam (Kam)" X-OriginalArrivalTime: 30 Apr 2009 14:37:03.0390 (UTC) FILETIME=[20CB93E0:01C9C9A1] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:36:38 -0000 Malcolm, Thanks for trying resolving the issue. I propose you first go over the requirement which is already specified in the MPLS-TP requirement draft on "Alarm Notification". IMO, it specifies a requirement which is in the sprit of what was written in your e-mail and not do not refer to any implementation. Best regards, Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Malcolm Betts Sent: Thursday, April 30, 2009 4:51 PM To: Drake, John E; George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) George,=20 I agree, a good historical perspective of how, in transport networks we have arrived in the state where AIS is an implementation with an implicit requirement rooted in TDM networks. The discussion on MPLS-TP has forced us to separate out the requirement (local vs. remote fault) from the implementation - insert all "1"s" in TDM signals. Given that MPLS-TP will be used in a transport network I see no reason to change the requirement. However, as you point out, the inherent differences between TDM and packet networks forces us to consider alternate implementations - all "1's" is not a valid packet signal..... So as I suggested in my previous post can we agree on the requirement. We can then discuss the implementation. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E Sent: Thursday, April 30, 2009 9:32 AM To: George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) George, An excellent note. Thanks, John=20 > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Thursday, April 30, 2009 6:16 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) >=20 > Lam, Hing-Kam (Kam) wrote: > > All I can say is that the impact of this proposed change is very=20 > > serious. > > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements=20 > > instead of changing the ITU-T transport requirements? > >=20 > > > Hi Kam, >=20 > AIS, which we are so very comfortable with, is a solution to a rather=20 > poorly stated requirement. The requirement is to distinguish between=20 > local faults (things that can be fixed > here) and remote faults (things that have to be fixed elsewhere). >=20 > PDH (and SDH/OTN) emits bits whatever the state of the incoming signal > and in the days of TTL, an open input was pulled up to 1. So extremely > old PDH equipment, emitted a stream of all 1's when its input was=20 > open. >=20 > This allowed a convenient simple distinction between a valid traffic=20 > signal, which has at least some 0's in it, and a remote failed signal. > It also provided a signal which checked the media between=20 > regenerators, and coincidentally, was propagated downstream for free. >=20 > And so we got AIS. It wasn't introduced to do stuff; it was just there > as a result of an open input. >=20 > Today we are trying to capture the requirements that the AIS=20 > implementation satisfies ,so that we do not repeat the common mistake=20 > of copying SDH solutions directly into a fundamentally different=20 > technology. >=20 > mpls-tp is not about changing what a transport network does, but it is > quite fundamentally changing how it does it. >=20 > Regards, >=20 > George > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From Martin.Vigoureux@alcatel-lucent.com Thu Apr 30 07:39:25 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97D43A6E64 for ; Thu, 30 Apr 2009 07:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.853 X-Spam-Level: X-Spam-Status: No, score=-3.853 tagged_above=-999 required=5 tests=[AWL=-1.604, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivdJAJJdmOHM for ; Thu, 30 Apr 2009 07:39:24 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 725AD3A68CB for ; Thu, 30 Apr 2009 07:39:24 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3UEeik0003486 for ; Thu, 30 Apr 2009 16:40:45 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 16:40:45 +0200 Message-ID: <49F9B86D.60805@alcatel-lucent.com> Date: Thu, 30 Apr 2009 16:40:45 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com><49F9A482.5020603@ieee.org><51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> <077E41CFFD002C4CAB7DFA4386A53264A75129@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A75129@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Apr 2009 14:40:45.0493 (UTC) FILETIME=[A52DCE50:01C9C9A1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:39:25 -0000 exactly, and it has been there for some time. It is however perfectible and following this week mead call I'll rework it a bit, using Malcolm's help of course ;-) -m Sprecher, Nurit (NSN - IL/Hod HaSharon) a �crit : > Malcolm, > Thanks for trying resolving the issue. > I propose you first go over the requirement which is already specified > in the MPLS-TP requirement draft on "Alarm Notification". > IMO, it specifies a requirement which is in the sprit of what was > written in your e-mail and not do not refer to any implementation. > Best regards, > Nurit > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of ext Malcolm Betts > Sent: Thursday, April 30, 2009 4:51 PM > To: Drake, John E; George Newsome; Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] > AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) > > George, > > I agree, a good historical perspective of how, in transport networks we > have arrived in the state where AIS is an implementation with an > implicit requirement rooted in TDM networks. > > The discussion on MPLS-TP has forced us to separate out the requirement > (local vs. remote fault) from the implementation - insert all "1"s" in > TDM signals. > > Given that MPLS-TP will be used in a transport network I see no reason > to change the requirement. > > However, as you point out, the inherent differences between TDM and > packet networks forces us to consider alternate implementations - all > "1's" is not a valid packet signal..... > > So as I suggested in my previous post can we agree on the requirement. > We can then discuss the implementation. > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Drake, John E > Sent: Thursday, April 30, 2009 9:32 AM > To: George Newsome; Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI > (wasAssociatedbidirectionaltransportpathrequirements) > > George, > > An excellent note. > > Thanks, > > John > >> -----Original Message----- >> From: George Newsome [mailto:gnewsome@ieee.org] >> Sent: Thursday, April 30, 2009 6:16 AM >> To: Lam, Hing-Kam (Kam) >> Cc: mpls-tp@ietf.org >> Subject: Re: [mpls-tp] AIS/FDI (was >> Associatedbidirectionaltransportpathrequirements) >> >> Lam, Hing-Kam (Kam) wrote: >>> All I can say is that the impact of this proposed change is very >>> serious. >>> Doesn't MPLS-TP suppose to meet the ITU-T transport requirements >>> instead of changing the ITU-T transport requirements? >>> >>> >> Hi Kam, >> >> AIS, which we are so very comfortable with, is a solution to a rather >> poorly stated requirement. The requirement is to distinguish between >> local faults (things that can be fixed >> here) and remote faults (things that have to be fixed elsewhere). >> >> PDH (and SDH/OTN) emits bits whatever the state of the incoming signal > >> and in the days of TTL, an open input was pulled up to 1. So extremely > >> old PDH equipment, emitted a stream of all 1's when its input was >> open. >> >> This allowed a convenient simple distinction between a valid traffic >> signal, which has at least some 0's in it, and a remote failed signal. >> It also provided a signal which checked the media between >> regenerators, and coincidentally, was propagated downstream for free. >> >> And so we got AIS. It wasn't introduced to do stuff; it was just there > >> as a result of an open input. >> >> Today we are trying to capture the requirements that the AIS >> implementation satisfies ,so that we do not repeat the common mistake >> of copying SDH solutions directly into a fundamentally different >> technology. >> >> mpls-tp is not about changing what a transport network does, but it is > >> quite fundamentally changing how it does it. >> >> Regards, >> >> George >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From BETTS01@nortel.com Thu Apr 30 07:41:37 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6C13A69C2 for ; Thu, 30 Apr 2009 07:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meshw4y4UM4u for ; Thu, 30 Apr 2009 07:41:36 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E6CBE3A693E for ; Thu, 30 Apr 2009 07:41:35 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3UEgtV16323; Thu, 30 Apr 2009 14:42:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 10:42:38 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516F963AF@zcarhxm2.corp.nortel.com> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A75129@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) Thread-Index: AcnJleFGBDuvlMtyQB+gZCfSszjZhQAAe1MQAABcwcAAAcM3EAAAXpYA References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com><49F9A482.5020603@ieee.org><51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> <077E41CFFD002C4CAB7DFA4386A53264A75129@DEMUEXC014.nsn-intra.net> From: "Malcolm Betts" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:41:37 -0000 Working on the text right now....=20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com]=20 Sent: Thursday, April 30, 2009 10:37 AM To: Betts, Malcolm (CAR:X632); Drake, John E; George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) Malcolm, Thanks for trying resolving the issue. I propose you first go over the requirement which is already specified in the MPLS-TP requirement draft on "Alarm Notification". IMO, it specifies a requirement which is in the sprit of what was written in your e-mail and not do not refer to any implementation. Best regards, Nurit -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Malcolm Betts Sent: Thursday, April 30, 2009 4:51 PM To: Drake, John E; George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements) George,=20 I agree, a good historical perspective of how, in transport networks we have arrived in the state where AIS is an implementation with an implicit requirement rooted in TDM networks. The discussion on MPLS-TP has forced us to separate out the requirement (local vs. remote fault) from the implementation - insert all "1"s" in TDM signals. Given that MPLS-TP will be used in a transport network I see no reason to change the requirement. However, as you point out, the inherent differences between TDM and packet networks forces us to consider alternate implementations - all "1's" is not a valid packet signal..... So as I suggested in my previous post can we agree on the requirement. We can then discuss the implementation. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E Sent: Thursday, April 30, 2009 9:32 AM To: George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) George, An excellent note. Thanks, John=20 > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Thursday, April 30, 2009 6:16 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) >=20 > Lam, Hing-Kam (Kam) wrote: > > All I can say is that the impact of this proposed change is very=20 > > serious. > > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements=20 > > instead of changing the ITU-T transport requirements? > >=20 > > > Hi Kam, >=20 > AIS, which we are so very comfortable with, is a solution to a rather=20 > poorly stated requirement. The requirement is to distinguish between=20 > local faults (things that can be fixed > here) and remote faults (things that have to be fixed elsewhere). >=20 > PDH (and SDH/OTN) emits bits whatever the state of the incoming signal > and in the days of TTL, an open input was pulled up to 1. So extremely > old PDH equipment, emitted a stream of all 1's when its input was=20 > open. >=20 > This allowed a convenient simple distinction between a valid traffic=20 > signal, which has at least some 0's in it, and a remote failed signal. > It also provided a signal which checked the media between=20 > regenerators, and coincidentally, was propagated downstream for free. >=20 > And so we got AIS. It wasn't introduced to do stuff; it was just there > as a result of an open input. >=20 > Today we are trying to capture the requirements that the AIS=20 > implementation satisfies ,so that we do not repeat the common mistake=20 > of copying SDH solutions directly into a fundamentally different=20 > technology. >=20 > mpls-tp is not about changing what a transport network does, but it is > quite fundamentally changing how it does it. >=20 > Regards, >=20 > George > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From hhelvoort@chello.nl Thu Apr 30 07:52:13 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7D83A6848 for ; Thu, 30 Apr 2009 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrUoI0X4ecwS for ; Thu, 30 Apr 2009 07:52:08 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 49A6C3A6F7F for ; Thu, 30 Apr 2009 07:52:07 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090430145327.TRCR15840.viefep11-int.chello.at@edge05.upc.biz>; Thu, 30 Apr 2009 16:53:27 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge05.upc.biz with edge id lqtR1b0733KDBhC05qtTci; Thu, 30 Apr 2009 16:53:27 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49F9BB65.3030601@chello.nl> Date: Thu, 30 Apr 2009 16:53:25 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Newsome References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net> <002101c9c94b$d998f4e0$6802a8c0@china.huawei.com> <49F9A482.5020603@ieee.org> In-Reply-To: <49F9A482.5020603@ieee.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:52:13 -0000 Hi George, I can imagine that you lost track in all messages. You replied to Kam: >> All I can say is that the impact of this proposed change is very >> serious. Doesn't MPLS-TP suppose to meet the ITU-T transport >> requirements instead >> of changing the ITU-T transport requirements? >> >> > Hi Kam, > > AIS, which we are so very comfortable with, is a solution to a rather > poorly stated requirement. The requirement is to distinguish between > local faults (things that can be fixed here) and remote faults (things > that have to be fixed elsewhere). I have already proposed text in a reply to Adrian. because AIS is not mentioned you may have missed that. You are just starting another round of discussions. > PDH (and SDH/OTN) emits bits whatever the state of the incoming signal > and in the days of TTL, an open input was pulled up to 1. So extremely > old PDH equipment, emitted a stream of all 1's when its input was open. I already replied to Neil that AIS is a (deliberate) consequent action to a number of possible defects, e.g. loss of clock, loss of lock, loss of signal, loss of frame. BTW: DS3 AIS is *NOT* an all ONEs signal. > This allowed a convenient simple distinction between a valid traffic > signal, which has at least some 0's in it, and a remote failed signal. > It also provided a signal which checked the media between regenerators, > and coincidentally, was propagated downstream for free. > > And so we got AIS. It wasn't introduced to do stuff; it was just there > as a result of an open input. No, see above. > Today we are trying to capture the requirements that the AIS > implementation satisfies ,so that we do not repeat the common mistake of > copying SDH solutions directly into a fundamentally different technology. There were already several attempts to provide text, did you miss those? De groeten, Huub. ----------------- > mpls-tp is not about changing what a transport network does, but it is > quite fundamentally changing how it does it. > > Regards, > > George > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From John.E.Drake2@boeing.com Thu Apr 30 08:33:58 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7933A6F75 for ; Thu, 30 Apr 2009 08:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.916 X-Spam-Level: X-Spam-Status: No, score=-3.916 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRCqPtAi3X28 for ; Thu, 30 Apr 2009 08:33:56 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 02CF23A6A71 for ; Thu, 30 Apr 2009 08:33:55 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3UFZ5H5024730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2009 08:35:05 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3UFZ4ZQ020235; Thu, 30 Apr 2009 10:35:04 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3UFYtQ5019521; Thu, 30 Apr 2009 10:35:02 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 08:34:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 08:34:56 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01B0A5B6@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) Thread-Index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJAABtoogAAkDyVAAA3bmWAANZqDYA== References: <008701c9c89b$4ef8bce0$6c02a8c0@china.huawei.com> From: "Drake, John E" To: "BRUNGARD, DEBORAH A, ATTLABS" , "Maarten Vissers" X-OriginalArrivalTime: 30 Apr 2009 15:34:58.0114 (UTC) FILETIME=[37E46220:01C9C9A9] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:33:58 -0000 Deborah, I agree completely. As you point out, there can be interfaces between = peer networks that support the same technologies (e.g., ATM-ATM, FR-FR, = SDH-SDH, MPLS-MPLS, etc), and these interfaces are typically termed = NNIs. What Maarten seems to be doing is conflating NNIs and interworking = functions between heterogeneous non-top of stack technologies, which = have nothing whatever to do with NNIs and which may or may not be = possible, but aren't worth the trouble. Thanks, John > -----Original Message----- > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 > Sent: Wednesday, April 29, 2009 8:06 AM > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in=20 > circles(Re:Associated bidirectional transport path requirements) >=20 > Maarten, >=20 > =20 >=20 > I only have confirmed that what you have given as an example=20 > of an ENNI below is G707 and G704. You missed the point. This=20 > is a typical ITU interface standard. It can be used as an=20 > INNI, ENNI, or UNI. Since you are twisting words, I=A1=AFll try to=20 > be clearer. >=20 > =20 >=20 > Yes, we need interface standards. If we have standards and=20 > have defined the technology properly, we do not need your=20 > =A1=B0interworking ENNI=A1=B1. You have twisted the definition of a=20 > standard interface used between (hopefully) all equipment,=20 > within a domain and between domains, to rationalize your=20 > =A1=B0ENNI=A1=B1. Two operators (or Forum) agreeing on a physical=20 > encapsulation, J1, vlans, or label to be used may be=20 > described in the industry as interworking, but then it can be=20 > said that every interface is interworking. The fiber=20 > connectors are interworking. Instead of saying, I=A1=AFm=20 > connecting the fiber, we will say, we are interworking the=20 > fiber. This is silly. Rather than use a much hyped=20 > non-specific term, here, in ITU and IETF, we should be specific.=20 >=20 > =20 >=20 > The ENNI/UNIs defined in MPLS Forum and MEF are a profile of=20 > existing standards. They provide a consistent interpretation=20 > of an existing standard for the members of the Forum (i.e.=20 > improved readability for the members, as we all know, ITU=20 > Recommendations and IETF RFCs are often not standalone=20 > documents or not easy reading for non-involved readers). It=20 > is questionable for IETF or ITU to define an ENNI or UNI as=20 > it will be difficult for all the members to agree =A8C otherwise=20 > all the options should not be in the original standard if=20 > they were not needed. >=20 > =20 >=20 > Connecting two networks together using a standard physical=20 > layer is not really an ENNI (as Neil has said over and over).=20 > If we start defining UNI/ENNI/INNI for all the technologies=20 > in ITU and IETF, we will have an operational nightmare. >=20 > =20 >=20 > Deborah >=20 > =20 >=20 > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > Sent: Wednesday, April 29, 2009 3:23 AM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] We appear to be going around in=20 > circles (Re:Associated bidirectional transport path requirements) >=20 > =20 >=20 > Deborah, >=20 > =20 >=20 > Thank you for confirming that we can speak about ENNI for=20 > non-IP layer interconnects. As you indicate, an ENNI also=20 > exists when we interconnect two SDH admin domains via an STM-N. >=20 > =20 >=20 > Do you also agree that we can speak about an ENNI when we=20 > interconnect a Metro/Carrier Ethernet Network admin domain A=20 > with a Metro/Carrier Etherent Network admin domain B via an=20 > 802.3 interface over which the EVC layer is transported? >=20 > =20 >=20 > Regards, >=20 > Maarten >=20 > =20 >=20 > ________________________________ >=20 > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > Sent: dinsdag 28 april 2009 17:52 > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] We appear to be going around in=20 > circles (Re:Associated bidirectional transport path requirements) >=20 > Exactly =A8C G707 defined the ENNI for SDH and G703/G704 for=20 > PDH. The PHY and framing is defined (per layer). This=20 > definition is very different from your earlier email. It does=20 > not require supporting PDH<->SDH interworking, or PDH OAM in=20 > SDH, or OAM interworking between a client/server as one of=20 > your earlier emails required: >=20 > =20 >=20 > >For this case it is necessary to develop ETH<>PW(client) layer >=20 > > network >=20 > > interworking specifications. To limit the complexity of=20 > such layer >=20 > > network interworking, it is beneficial to select the=20 > MPLS-TP PW OAM >=20 > > to >=20 > > use the Y.7131 OAM PDUs as proposed in=20 > draft-bhh-mpls-tp-oam-y1731.=20 >=20 > > I.e. >=20 > > both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs >=20 > =20 >=20 > The interconnection of equipment (at one layer) should not=20 > put any restrictions on other layers. >=20 > =20 >=20 > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > Sent: Tuesday, April 28, 2009 7:01 AM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] We appear to be going around in=20 > circles (Re:Associated bidirectional transport path requirements) >=20 > =20 >=20 > Deborah, >=20 > =20 >=20 > > And the UNI/ENNI being discussed there is not comparable to=20 > your definition. >=20 > =20 >=20 > I be more then happy if you give me alternative terms to UNI and ENNI. >=20 > =20 >=20 > Just use the example of a customer requesting a 2 Mbit/s=20 > service from the SDH network, of which the first customer=20 > location is located behind the network of operator A and the=20 > second endpoint is located behind the network of operator B.=20 > Operator A and B interconnect via a STM-1 interface with each=20 > other. The customer connects via a 2 Mbit/s G.703 interface=20 > with the networks of operator A and B. >=20 > =20 >=20 > What term should I use for the interconnect of the customer=20 > to the networks of operator A and B? >=20 > I.e. if it is not possible to call this the "UNI", what=20 > should it be called then? >=20 > =20 >=20 > What term should I use for the interconnect of the networks=20 > of operator A and B? >=20 > I.e. if it is not possible to call this the "ENNI", what=20 > should it be called then? >=20 > =20 >=20 > Thanks for your help. >=20 > Regards, >=20 > Maarten >=20 > PS. Note that G.8012 defines UNI as follows: "An interface=20 > that is used for the interconnection of customer equipment=20 > with a network element of the transport network." >=20 > =20 >=20 > ________________________________ >=20 > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > Sent: maandag 27 april 2009 23:00 > To: Greg Mirsky; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] We appear to be going around in=20 > circles (Re:Associated bidirectional transport path requirements) >=20 > Maarten, >=20 > =20 >=20 > I think you have oversimplified the discussion in MEF and in=20 > so doing have inaccurately summarized. As Greg says, MEF is=20 > oriented towards services (SLA/SLS) and they also recognize=20 > that some operators only need simple troubleshooting tools.=20 > Considering the on-going discussion in MEF, for the service=20 > operators group, it is questionable if Y1731 should be used=20 > by MPLS-TP as a baseline as it is considered inadequate. And=20 > I don=A1=AFt see AT&T=A1=AFs requirements as any different from BT. I=20 > think we should follow Adrian=A1=AFs and Ben=A1=AFs proposal to define = > the actual requirements for MPLS-TP before replicating other=20 > technologies=A1=AF solutions. >=20 > =20 >=20 > And the UNI/ENNI being discussed there is not comparable to=20 > your definition. >=20 > =20 >=20 > Deborah >=20 > =20 >=20 > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky > Sent: Monday, April 27, 2009 2:47 PM > To: Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in=20 > circles (Re:Associated bidirectional transport path requirements) >=20 > =20 >=20 > Dear Maarten, > you definitely know but I'd note that MEF formulates=20 > requirements for Carrier Ethernet as a service, i.e. client=20 > layer of a transport network, not requirements for the=20 > transport network as server layer. Thus requirements=20 > expressed by SPs at MEF are not applicable or transitive, in=20 > my view, to MPLS-TP, at least not automatically.=20 >=20 > Regards, > Greg Mirsky >=20 > 2009/4/27 Maarten Vissers >=20 > Tom, >=20 > This AIS discussion has been held in previous technologies as=20 > well, e.g. > Ethernet OAM. > The result was that AIS insertion is optional and that=20 > Ethernet equipment (see G.8021) can be configured to insert=20 > Ethernet AIS or to not insert Ethernet AIS. >=20 >=20 > > Do you see our (BT's) requirements to be very divergent=20 > from those of > other operators participating in this effort? >=20 > I see the requirements for OAM that have been expressed in=20 > this mpls-tp discussion by BT representatives to be different=20 > from the requirements expressed by other operator=20 > representatives. For example > draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives=20 > of DT, FT, KPN, KDDI and CT. I also see that the OAM=20 > requirements defined in MEF (with input from e.g. AT&T and=20 > Verizon) be different from those expressed by BT=20 > representatives. I see that MEF is requesting to support in=20 > Y.1731 frame loss counting for more then one priority level;=20 > i.e. an extension of the existing capability that support=20 > frame loss counting for a single priority (i.e. a case of=20 > more OAM, not less OAM). >=20 > I see that the operators active in MEF (e.g. AT&T, Verizon,=20 > Sprint) have created and are creating Ethernet UNI, Ethernet=20 > E-NNI and Ethernet Virtual UNI specifications, while=20 > representatives of BT state that there can't be "UNI" or=20 > "E-NNI" interfaces associated with packet transport networks,=20 > as those networks are "not top of stack". I see that many=20 > operators require compliance with MEF specifications,=20 > including the Ethernet UNI specification. >=20 > I see that e.g. KPN provides a Wholesale Broadband Access=20 > (WBA) service via rooted-multipoint EVCs, which EVCs=20 > terminate outside the KPN network (refer to=20 > http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html=20 > and=20 > http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Acces > s_Service.html > ); i.e. a peer-interconnection case and a potential case for=20 > TCM, a case which according to BT representatives does not exist. >=20 > I see that the "message, file, stream" concepts are key to=20 > BT's considerations, while I don't see any of that=20 > contributed by other operators. When I look at the telecom=20 > network stack (see attached slide), then message, file stream=20 > are important concepts at Layer 3 (NGN) where those represent=20 > the characteristics of the main services (data, voice,=20 > video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the=20 > important services at Layer 2 (PTN). This raises the question=20 > what the scope of MPLS-TP is for you: > A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which=20 > has to support the IP based Layer 3 Services/Channel layer > B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which=20 > has to support the EVC based Layer 2 Services/Channel layer. >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: vrijdag 24 april 2009 15:35 > To: Maarten Vissers >=20 > Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org > Subject: Re: [mpls-tp] We appear to be going around in circles (Re: > Associated bidirectional transport path requirements) >=20 >=20 > Maartin, >=20 > > Ben, > > > > Your company is one of the many operators in the world, and=20 > the number=20 > > of nodes outside your network is factors larger then the number of=20 > > nodes inside your network. My experience is that different=20 > operators=20 > > have different sets of requirements. Manufacturers have to=20 > support the=20 > > superset of those requirements. Each operator will then deploy the=20 > > subset of provided features that fits its needs (and turn=20 > off or don't=20 > > use the others). Your company for some years has been=20 > asking for less,=20 > > other operators have been asking for more. Manufacturers thus build=20 > > their products with lots of configurability to support all=20 > variations. >=20 > Do you see our (BT's) requirements to be very=20 > divergent from those of other operators participating in this=20 > effort? Unless our requirements are very different, I am=20 > confident vendors will build (or have built) their devices=20 > based on our (sensible) requirements. >=20 > > It is my opinion that we should not remove well established=20 > features=20 > > like AIS, TCM, frame loss counting, delay measurement,=20 > loopback, etc=20 > > before the majority of operators have agreed that such features are=20 > > not longer necessary. >=20 > Again, that is your opinion, which frankly seems to=20 > diverge from what other operators have expressed.=20 > Furthermore, let me recommend that you get out of the habit=20 > of telling your customers (or potential ones), what they=20 > require after they have been plainly clear about what they want. > Unless you think we don't know what we are talking about. Is=20 > this perhaps the case? >=20 > --Tom >=20 >=20 >=20 >=20 > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > > Behalf Of Ben Niven-Jenkins > > Sent: vrijdag 24 april 2009 0:14 > > To: mpls-tp@ietf.org > > Subject: [mpls-tp] We appear to be going around in circles (Re: > > Associated > > bidirectional transport path requirements) > > > > Colleagues, > > > > The current debates appear to be going around in circles=20 > and achieving=20 > > nothing of value IMO. Two major operators have expressed their=20 > > opinions and no operator that I can see has disagreed with those=20 > > opinions. > > > > I apologise for being direct (and possibly rude) but I am getting=20 > > tired of being told by folks who do not represent operators what=20 > > functionality I need or should have in my networks. > > > > To put some context on BT's comments in these threads: > > I have the largest MPLS network in the UK. > > I have one of the largest MPLS networks globally delivering=20 > service to > > 173 countries with over 200 000 customer ports I have (off=20 > the top of=20 > > my > > head) > > at least another 10 MPLS networks in specific countries covering at=20 > > least 3 continents delivering dedicated services to=20 > particular market=20 > > segments. > > > > I have an extremely large SDH network in the UK consisting=20 > of over 30=20 > > 000 switches and supporting in excess of 1 million circuits. > > I have an extremely large SDH network globally delivering=20 > service in=20 > > 110 countries. > > > > I would like to think my BT colleagues and I might know a little=20 > > something about building large scale networks and the=20 > requirements of=20 > > those networks and the needs of the customers that I=20 > deliver services=20 > > to. > > > > Can we please stop these circular arguments which are IMO going=20 > > nowhere and focus on the task in hand which is defining the=20 > > requirements (and later > > solutions) being asked for by myself, my company and my=20 > colleagues in=20 > > other operators on this list. > > > > Thanks > > Ben > > > > > > -- > > > > Ben Niven-Jenkins > > IP, Data & Content Architect > > Network Infrastructure Architecture, BT > > > > E-mail: benjamin.niven-jenkins@bt.com > > Office: +44 (0)1473 648225 > > Mobile: +44 (0)7918 077205 > > Fax: +44 (0)1332 578827 > > > > British Telecommunications plc. Registered office: 81=20 > Newgate Street=20 > > London > > EC1A 7AJ Registered in England no: 1800000 > > > > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn" > > wrote: > > > >> ben: > >> I understand your meaning, you still wish to resign and=20 > make a more=20 > >> reliable and effective, easy to operator and easy to manage packet=20 > >> transport network like me. but why not apply this SDH/SONET in the=20 > >> future maybe the following cause: > >> 1 it adopted circuit switching techonogy to bring lower=20 > useful of=20 > >> the resource than PTN network; > >> 2 it can't bear all kinds of traffics like PTN networks it noted=20 > >> that we can't apply SDH/SONET network in the future not because it=20 > >> have a complex OAM functions. while more people like to move the=20 > >> advantages of the OAM functions in SDH/SONET to PTN networks. and=20 > >> AIS/FDI function is a kind of OAM functions of SDH/SONET .=20 > we should=20 > >> use and extend the AIS/FDI functions to MPLS-TP ; > >> > >> best regards > >> liu > >> > >> > >> > >> Ben Niven-Jenkins > >> 2009-04-23 07:58 > >> > >> =CA=D5=BC=FE=C8=CB > >> , "BRUNGARD, DEBORAH A, ATTLABS" > >> > >> =B3=AD=CB=CD > >> > >> =D6=F7=CC=E2 > >> Re: [mpls-tp] Associated bidirectional transport path requirements > >> > >> > >> > >> > >> > >> > >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn"=20 > > >> wrote: > >> > >>> Deborah: > >>> maybe what you said is right. but I can't completely agree your > >> opinions. > >>> IMO. mpls-tp is regard as transport network like SDH/SONET. so it=20 > >>> should have AIS/FDI fuctions as SDH/SONET. > >>> > >>> do you think so. > >> > >> No we must assess the requirements for packet transport networks=20 > >> supporting the needs of operators today and in the future. We must=20 > >> not blindly recreate SDH/SONET. If we do so without=20 > consideration to=20 > >> how operators' needs and requirements may have evolved=20 > (and continue=20 > >> to evolve in future) we will have failed IMO and I would severely=20 > >> question the value of the work we will have produced. If we just=20 > >> recreate SDH/SONET then what is the purpose of the work an=20 > operator=20 > >> would be better off just deploying existing SDH/SONET equipment. > >> > >> > >> Ben > >> > >> > >> > >> > >> > >> -------------------------------------------------------- > >> ZTE Information Security Notice: The information contained in this=20 > >> mail is solely property of the sender's organization. This mail=20 > >> communication is confidential. Recipients named above are=20 > obligated=20 > >> to maintain secrecy and are not permitted to disclose the=20 > contents of=20 > >> this > > communication to others. > >> This email and any files transmitted with it are confidential and=20 > >> intended solely for the use of the individual or entity to=20 > whom they=20 > >> are addressed. If you have received this email in error=20 > please notify=20 > >> the originator of the message. Any views expressed in this message=20 > >> are those of the individual sender. > >> This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > =20 >=20 >=20 From John.E.Drake2@boeing.com Thu Apr 30 09:17:55 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0434228C14F for ; Thu, 30 Apr 2009 09:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, J_BACKHAIR_33=1, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlO9XlasDDA4 for ; Thu, 30 Apr 2009 09:17:52 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id CE3793A67F7 for ; Thu, 30 Apr 2009 09:17:52 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3UGJ8eg023504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2009 09:19:09 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3UGJ8XY015704; Thu, 30 Apr 2009 11:19:08 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3UGJ5aF015567; Thu, 30 Apr 2009 11:19:08 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 09:19:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 09:19:05 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01B0A5DC@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) Thread-Index: AcnHaUi3bakoAIwsT+eoBzK6EtFy/wAEAgAAAB1zIJAABtoogAAkDyVAAA3bmWAANZqDYAABbiMw References: <008701c9c89b$4ef8bce0$6c02a8c0@china.huawei.com> From: "Drake, John E" To: "Drake, John E" , "BRUNGARD, DEBORAH A, ATTLABS" , "Maarten Vissers" X-OriginalArrivalTime: 30 Apr 2009 16:19:06.0753 (UTC) FILETIME=[629A9F10:01C9C9AF] Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:17:55 -0000 Hi, As an example of the difference between an NNI and an interworking = function, see the following: http://www.ipmplsforum.org/frame/Approved/FRF.2/FRF_2_2-final.pdf http://www.ipmplsforum.org/frame/Approved/FRF.8/FRF.8.2.pdf=20 with which David and Andy may have some familiarity. Thanks, John=20 > -----Original Message----- > From: Drake, John E=20 > Sent: Thursday, April 30, 2009 8:35 AM > To: BRUNGARD, DEBORAH A, ATTLABS; Maarten Vissers > Cc: mpls-tp@ietf.org > Subject: RE: [mpls-tp] We appear to be going around in=20 > circles(Re:Associated bidirectional transport path requirements) >=20 > Deborah, >=20 > I agree completely. As you point out, there can be=20 > interfaces between peer networks that support the same=20 > technologies (e.g., ATM-ATM, FR-FR, SDH-SDH, MPLS-MPLS, etc),=20 > and these interfaces are typically termed NNIs. >=20 > What Maarten seems to be doing is conflating NNIs and=20 > interworking functions between heterogeneous non-top of stack=20 > technologies, which have nothing whatever to do with NNIs and=20 > which may or may not be possible, but aren't worth the trouble. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > > Sent: Wednesday, April 29, 2009 8:06 AM > > To: Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] We appear to be going around in=20 > > circles(Re:Associated bidirectional transport path requirements) > >=20 > > Maarten, > >=20 > > =20 > >=20 > > I only have confirmed that what you have given as an example of an=20 > > ENNI below is G707 and G704. You missed the point. This is=20 > a typical=20 > > ITU interface standard. It can be used as an INNI, ENNI, or=20 > UNI. Since=20 > > you are twisting words, I=A1=AFll try to be clearer. > >=20 > > =20 > >=20 > > Yes, we need interface standards. If we have standards and have=20 > > defined the technology properly, we do not need your = =A1=B0interworking=20 > > ENNI=A1=B1. You have twisted the definition of a standard=20 > interface used=20 > > between (hopefully) all equipment, within a domain and between=20 > > domains, to rationalize your =A1=B0ENNI=A1=B1. Two operators (or=20 > Forum) agreeing=20 > > on a physical encapsulation, J1, vlans, or label to be used may be=20 > > described in the industry as interworking, but then it can be said=20 > > that every interface is interworking. The fiber connectors are=20 > > interworking. Instead of saying, I=A1=AFm connecting the fiber, we = will=20 > > say, we are interworking the fiber. This is silly. Rather=20 > than use a=20 > > much hyped non-specific term, here, in ITU and IETF, we should be=20 > > specific. > >=20 > > =20 > >=20 > > The ENNI/UNIs defined in MPLS Forum and MEF are a profile of=20 > > existing standards. They provide a consistent interpretation=20 > > of an existing standard for the members of the Forum (i.e.=20 > > improved readability for the members, as we all know, ITU=20 > > Recommendations and IETF RFCs are often not standalone=20 > > documents or not easy reading for non-involved readers). It=20 > > is questionable for IETF or ITU to define an ENNI or UNI as=20 > > it will be difficult for all the members to agree =A8C otherwise=20 > > all the options should not be in the original standard if=20 > > they were not needed. > >=20 > > =20 > >=20 > > Connecting two networks together using a standard physical=20 > > layer is not really an ENNI (as Neil has said over and over).=20 > > If we start defining UNI/ENNI/INNI for all the technologies=20 > > in ITU and IETF, we will have an operational nightmare. > >=20 > > =20 > >=20 > > Deborah > >=20 > > =20 > >=20 > > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > > Sent: Wednesday, April 29, 2009 3:23 AM > > To: BRUNGARD, DEBORAH A, ATTLABS > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] We appear to be going around in=20 > > circles (Re:Associated bidirectional transport path requirements) > >=20 > > =20 > >=20 > > Deborah, > >=20 > > =20 > >=20 > > Thank you for confirming that we can speak about ENNI for=20 > > non-IP layer interconnects. As you indicate, an ENNI also=20 > > exists when we interconnect two SDH admin domains via an STM-N. > >=20 > > =20 > >=20 > > Do you also agree that we can speak about an ENNI when we=20 > > interconnect a Metro/Carrier Ethernet Network admin domain A=20 > > with a Metro/Carrier Etherent Network admin domain B via an=20 > > 802.3 interface over which the EVC layer is transported? > >=20 > > =20 > >=20 > > Regards, > >=20 > > Maarten > >=20 > > =20 > >=20 > > ________________________________ > >=20 > > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > > Sent: dinsdag 28 april 2009 17:52 > > To: Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] We appear to be going around in=20 > > circles (Re:Associated bidirectional transport path requirements) > >=20 > > Exactly =A8C G707 defined the ENNI for SDH and G703/G704 for=20 > > PDH. The PHY and framing is defined (per layer). This=20 > > definition is very different from your earlier email. It does=20 > > not require supporting PDH<->SDH interworking, or PDH OAM in=20 > > SDH, or OAM interworking between a client/server as one of=20 > > your earlier emails required: > >=20 > > =20 > >=20 > > >For this case it is necessary to develop ETH<>PW(client) layer > >=20 > > > network > >=20 > > > interworking specifications. To limit the complexity of=20 > > such layer > >=20 > > > network interworking, it is beneficial to select the=20 > > MPLS-TP PW OAM > >=20 > > > to > >=20 > > > use the Y.7131 OAM PDUs as proposed in=20 > > draft-bhh-mpls-tp-oam-y1731.=20 > >=20 > > > I.e. > >=20 > > > both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs > >=20 > > =20 > >=20 > > The interconnection of equipment (at one layer) should not=20 > > put any restrictions on other layers. > >=20 > > =20 > >=20 > > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > > Sent: Tuesday, April 28, 2009 7:01 AM > > To: BRUNGARD, DEBORAH A, ATTLABS > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] We appear to be going around in=20 > > circles (Re:Associated bidirectional transport path requirements) > >=20 > > =20 > >=20 > > Deborah, > >=20 > > =20 > >=20 > > > And the UNI/ENNI being discussed there is not comparable to=20 > > your definition. > >=20 > > =20 > >=20 > > I be more then happy if you give me alternative terms to=20 > UNI and ENNI. > >=20 > > =20 > >=20 > > Just use the example of a customer requesting a 2 Mbit/s=20 > > service from the SDH network, of which the first customer=20 > > location is located behind the network of operator A and the=20 > > second endpoint is located behind the network of operator B.=20 > > Operator A and B interconnect via a STM-1 interface with each=20 > > other. The customer connects via a 2 Mbit/s G.703 interface=20 > > with the networks of operator A and B. > >=20 > > =20 > >=20 > > What term should I use for the interconnect of the customer=20 > > to the networks of operator A and B? > >=20 > > I.e. if it is not possible to call this the "UNI", what=20 > > should it be called then? > >=20 > > =20 > >=20 > > What term should I use for the interconnect of the networks=20 > > of operator A and B? > >=20 > > I.e. if it is not possible to call this the "ENNI", what=20 > > should it be called then? > >=20 > > =20 > >=20 > > Thanks for your help. > >=20 > > Regards, > >=20 > > Maarten > >=20 > > PS. Note that G.8012 defines UNI as follows: "An interface=20 > > that is used for the interconnection of customer equipment=20 > > with a network element of the transport network." > >=20 > > =20 > >=20 > > ________________________________ > >=20 > > From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > > Sent: maandag 27 april 2009 23:00 > > To: Greg Mirsky; Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: RE: [mpls-tp] We appear to be going around in=20 > > circles (Re:Associated bidirectional transport path requirements) > >=20 > > Maarten, > >=20 > > =20 > >=20 > > I think you have oversimplified the discussion in MEF and in=20 > > so doing have inaccurately summarized. As Greg says, MEF is=20 > > oriented towards services (SLA/SLS) and they also recognize=20 > > that some operators only need simple troubleshooting tools.=20 > > Considering the on-going discussion in MEF, for the service=20 > > operators group, it is questionable if Y1731 should be used=20 > > by MPLS-TP as a baseline as it is considered inadequate. And=20 > > I don=A1=AFt see AT&T=A1=AFs requirements as any different from BT. = I=20 > > think we should follow Adrian=A1=AFs and Ben=A1=AFs proposal to = define=20 > > the actual requirements for MPLS-TP before replicating other=20 > > technologies=A1=AF solutions. > >=20 > > =20 > >=20 > > And the UNI/ENNI being discussed there is not comparable to=20 > > your definition. > >=20 > > =20 > >=20 > > Deborah > >=20 > > =20 > >=20 > > From: mpls-tp-bounces@ietf.org=20 > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky > > Sent: Monday, April 27, 2009 2:47 PM > > To: Maarten Vissers > > Cc: mpls-tp@ietf.org > > Subject: Re: [mpls-tp] We appear to be going around in=20 > > circles (Re:Associated bidirectional transport path requirements) > >=20 > > =20 > >=20 > > Dear Maarten, > > you definitely know but I'd note that MEF formulates=20 > > requirements for Carrier Ethernet as a service, i.e. client=20 > > layer of a transport network, not requirements for the=20 > > transport network as server layer. Thus requirements=20 > > expressed by SPs at MEF are not applicable or transitive, in=20 > > my view, to MPLS-TP, at least not automatically.=20 > >=20 > > Regards, > > Greg Mirsky > >=20 > > 2009/4/27 Maarten Vissers > >=20 > > Tom, > >=20 > > This AIS discussion has been held in previous technologies as=20 > > well, e.g. > > Ethernet OAM. > > The result was that AIS insertion is optional and that=20 > > Ethernet equipment (see G.8021) can be configured to insert=20 > > Ethernet AIS or to not insert Ethernet AIS. > >=20 > >=20 > > > Do you see our (BT's) requirements to be very divergent=20 > > from those of > > other operators participating in this effort? > >=20 > > I see the requirements for OAM that have been expressed in=20 > > this mpls-tp discussion by BT representatives to be different=20 > > from the requirements expressed by other operator=20 > > representatives. For example > > draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives=20 > > of DT, FT, KPN, KDDI and CT. I also see that the OAM=20 > > requirements defined in MEF (with input from e.g. AT&T and=20 > > Verizon) be different from those expressed by BT=20 > > representatives. I see that MEF is requesting to support in=20 > > Y.1731 frame loss counting for more then one priority level;=20 > > i.e. an extension of the existing capability that support=20 > > frame loss counting for a single priority (i.e. a case of=20 > > more OAM, not less OAM). > >=20 > > I see that the operators active in MEF (e.g. AT&T, Verizon,=20 > > Sprint) have created and are creating Ethernet UNI, Ethernet=20 > > E-NNI and Ethernet Virtual UNI specifications, while=20 > > representatives of BT state that there can't be "UNI" or=20 > > "E-NNI" interfaces associated with packet transport networks,=20 > > as those networks are "not top of stack". I see that many=20 > > operators require compliance with MEF specifications,=20 > > including the Ethernet UNI specification. > >=20 > > I see that e.g. KPN provides a Wholesale Broadband Access=20 > > (WBA) service via rooted-multipoint EVCs, which EVCs=20 > > terminate outside the KPN network (refer to=20 > > http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html=20 > > and=20 > > http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Acces > > s_Service.html > > ); i.e. a peer-interconnection case and a potential case for=20 > > TCM, a case which according to BT representatives does not exist. > >=20 > > I see that the "message, file, stream" concepts are key to=20 > > BT's considerations, while I don't see any of that=20 > > contributed by other operators. When I look at the telecom=20 > > network stack (see attached slide), then message, file stream=20 > > are important concepts at Layer 3 (NGN) where those represent=20 > > the characteristics of the main services (data, voice,=20 > > video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the=20 > > important services at Layer 2 (PTN). This raises the question=20 > > what the scope of MPLS-TP is for you: > > A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which=20 > > has to support the IP based Layer 3 Services/Channel layer > > B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which=20 > > has to support the EVC based Layer 2 Services/Channel layer. > >=20 > > Regards, > > Maarten > >=20 > >=20 > > -----Original Message----- > > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: vrijdag 24 april 2009 15:35 > > To: Maarten Vissers > >=20 > > Cc: 'Ben Niven-Jenkins'; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] We appear to be going around in circles (Re: > > Associated bidirectional transport path requirements) > >=20 > >=20 > > Maartin, > >=20 > > > Ben, > > > > > > Your company is one of the many operators in the world, and=20 > > the number=20 > > > of nodes outside your network is factors larger then the=20 > number of=20 > > > nodes inside your network. My experience is that different=20 > > operators=20 > > > have different sets of requirements. Manufacturers have to=20 > > support the=20 > > > superset of those requirements. Each operator will then=20 > deploy the=20 > > > subset of provided features that fits its needs (and turn=20 > > off or don't=20 > > > use the others). Your company for some years has been=20 > > asking for less,=20 > > > other operators have been asking for more. Manufacturers=20 > thus build=20 > > > their products with lots of configurability to support all=20 > > variations. > >=20 > > Do you see our (BT's) requirements to be very=20 > > divergent from those of other operators participating in this=20 > > effort? Unless our requirements are very different, I am=20 > > confident vendors will build (or have built) their devices=20 > > based on our (sensible) requirements. > >=20 > > > It is my opinion that we should not remove well established=20 > > features=20 > > > like AIS, TCM, frame loss counting, delay measurement,=20 > > loopback, etc=20 > > > before the majority of operators have agreed that such=20 > features are=20 > > > not longer necessary. > >=20 > > Again, that is your opinion, which frankly seems to=20 > > diverge from what other operators have expressed.=20 > > Furthermore, let me recommend that you get out of the habit=20 > > of telling your customers (or potential ones), what they=20 > > require after they have been plainly clear about what they want. > > Unless you think we don't know what we are talking about. Is=20 > > this perhaps the case? > >=20 > > --Tom > >=20 > >=20 > >=20 > >=20 > > > Regards, > > > Maarten > > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On=20 > > > Behalf Of Ben Niven-Jenkins > > > Sent: vrijdag 24 april 2009 0:14 > > > To: mpls-tp@ietf.org > > > Subject: [mpls-tp] We appear to be going around in circles (Re: > > > Associated > > > bidirectional transport path requirements) > > > > > > Colleagues, > > > > > > The current debates appear to be going around in circles=20 > > and achieving=20 > > > nothing of value IMO. Two major operators have expressed their=20 > > > opinions and no operator that I can see has disagreed with those=20 > > > opinions. > > > > > > I apologise for being direct (and possibly rude) but I am getting=20 > > > tired of being told by folks who do not represent operators what=20 > > > functionality I need or should have in my networks. > > > > > > To put some context on BT's comments in these threads: > > > I have the largest MPLS network in the UK. > > > I have one of the largest MPLS networks globally delivering=20 > > service to > > > 173 countries with over 200 000 customer ports I have (off=20 > > the top of=20 > > > my > > > head) > > > at least another 10 MPLS networks in specific countries=20 > covering at=20 > > > least 3 continents delivering dedicated services to=20 > > particular market=20 > > > segments. > > > > > > I have an extremely large SDH network in the UK consisting=20 > > of over 30=20 > > > 000 switches and supporting in excess of 1 million circuits. > > > I have an extremely large SDH network globally delivering=20 > > service in=20 > > > 110 countries. > > > > > > I would like to think my BT colleagues and I might know a little=20 > > > something about building large scale networks and the=20 > > requirements of=20 > > > those networks and the needs of the customers that I=20 > > deliver services=20 > > > to. > > > > > > Can we please stop these circular arguments which are IMO going=20 > > > nowhere and focus on the task in hand which is defining the=20 > > > requirements (and later > > > solutions) being asked for by myself, my company and my=20 > > colleagues in=20 > > > other operators on this list. > > > > > > Thanks > > > Ben > > > > > > > > > -- > > > > > > Ben Niven-Jenkins > > > IP, Data & Content Architect > > > Network Infrastructure Architecture, BT > > > > > > E-mail: benjamin.niven-jenkins@bt.com > > > Office: +44 (0)1473 648225 > > > Mobile: +44 (0)7918 077205 > > > Fax: +44 (0)1332 578827 > > > > > > British Telecommunications plc. Registered office: 81=20 > > Newgate Street=20 > > > London > > > EC1A 7AJ Registered in England no: 1800000 > > > > > > > > > On 23/04/2009 07:23, "liu.guoman@zte.com.cn"=20 > > > > wrote: > > > > > >> ben: > > >> I understand your meaning, you still wish to resign and=20 > > make a more=20 > > >> reliable and effective, easy to operator and easy to=20 > manage packet=20 > > >> transport network like me. but why not apply this=20 > SDH/SONET in the=20 > > >> future maybe the following cause: > > >> 1 it adopted circuit switching techonogy to bring lower=20 > > useful of=20 > > >> the resource than PTN network; > > >> 2 it can't bear all kinds of traffics like PTN=20 > networks it noted=20 > > >> that we can't apply SDH/SONET network in the future not=20 > because it=20 > > >> have a complex OAM functions. while more people like to move the=20 > > >> advantages of the OAM functions in SDH/SONET to PTN=20 > networks. and=20 > > >> AIS/FDI function is a kind of OAM functions of SDH/SONET .=20 > > we should=20 > > >> use and extend the AIS/FDI functions to MPLS-TP ; > > >> > > >> best regards > > >> liu > > >> > > >> > > >> > > >> Ben Niven-Jenkins > > >> 2009-04-23 07:58 > > >> > > >> =CA=D5=BC=FE=C8=CB > > >> , "BRUNGARD, DEBORAH A, ATTLABS" > > >> > > >> =B3=AD=CB=CD > > >> > > >> =D6=F7=CC=E2 > > >> Re: [mpls-tp] Associated bidirectional transport path=20 > requirements > > >> > > >> > > >> > > >> > > >> > > >> > > >> On 21/04/2009 02:59, "liu.guoman@zte.com.cn"=20 > > > > >> wrote: > > >> > > >>> Deborah: > > >>> maybe what you said is right. but I can't completely agree your > > >> opinions. > > >>> IMO. mpls-tp is regard as transport network like=20 > SDH/SONET. so it=20 > > >>> should have AIS/FDI fuctions as SDH/SONET. > > >>> > > >>> do you think so. > > >> > > >> No we must assess the requirements for packet transport networks=20 > > >> supporting the needs of operators today and in the=20 > future. We must=20 > > >> not blindly recreate SDH/SONET. If we do so without=20 > > consideration to=20 > > >> how operators' needs and requirements may have evolved=20 > > (and continue=20 > > >> to evolve in future) we will have failed IMO and I would=20 > severely=20 > > >> question the value of the work we will have produced. If we just=20 > > >> recreate SDH/SONET then what is the purpose of the work an=20 > > operator=20 > > >> would be better off just deploying existing SDH/SONET equipment. > > >> > > >> > > >> Ben > > >> > > >> > > >> > > >> > > >> > > >> -------------------------------------------------------- > > >> ZTE Information Security Notice: The information=20 > contained in this=20 > > >> mail is solely property of the sender's organization. This mail=20 > > >> communication is confidential. Recipients named above are=20 > > obligated=20 > > >> to maintain secrecy and are not permitted to disclose the=20 > > contents of=20 > > >> this > > > communication to others. > > >> This email and any files transmitted with it are=20 > confidential and=20 > > >> intended solely for the use of the individual or entity to=20 > > whom they=20 > > >> are addressed. If you have received this email in error=20 > > please notify=20 > > >> the originator of the message. Any views expressed in=20 > this message=20 > > >> are those of the individual sender. > > >> This message has been scanned for viruses and Spam by=20 > ZTE Anti-Spam > > > system. > > > > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > > =20 > >=20 > >=20 From BETTS01@nortel.com Thu Apr 30 12:56:58 2009 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA42C3A6ABF for ; Thu, 30 Apr 2009 12:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl2RmYb5XTo3 for ; Thu, 30 Apr 2009 12:56:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 857293A6AB5 for ; Thu, 30 Apr 2009 12:56:57 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3UJw0V28235; Thu, 30 Apr 2009 19:58:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 15:57:28 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516F96ABB@zcarhxm2.corp.nortel.com> In-Reply-To: <060801c9c9c9$085382f0$18fa88d0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) Thread-Index: AcnJleFGBDuvlMtyQB+gZCfSszjZhQAAe1MQAABcwcAACvhXgAACKWPg References: <077E41CFFD002C4CAB7DFA4386A53264A423B6@DEMUEXC014.nsn-intra.net><002101c9c94b$d998f4e0$6802a8c0@china.huawei.com><49F9A482.5020603@ieee.org> <51661468CBD1354294533DA79E85955A01B0A55C@XCH-SW-5V2.sw.nos.boeing.com> <0BDFFF51DC89434FA33F8B37FCE363D516F96230@zcarhxm2.corp.nortel.com> <060801c9c9c9$085382f0$18fa88d0$@com> From: "Malcolm Betts" To: , "Drake, John E" , "George Newsome" , "Lam, Hing-Kam (Kam)" Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:56:58 -0000 Agree, I think this is already covered in the MPLS-TP OAM requirements draft.=20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Shahram Davari [mailto:davarish@yahoo.com]=20 Sent: Thursday, April 30, 2009 3:23 PM To: Betts, Malcolm (CAR:X632); 'Drake, John E'; 'George Newsome'; 'Lam, Hing-Kam (Kam)' Cc: mpls-tp@ietf.org Subject: RE: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) Hi Malcom, Isn't it a requirement to distinguish between a layer failure or its serve layer failure? Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Malcolm Betts Sent: April-30-09 9:51 AM To: Drake, John E; George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) George,=20 I agree, a good historical perspective of how, in transport networks we have arrived in the state where AIS is an implementation with an implicit requirement rooted in TDM networks. The discussion on MPLS-TP has forced us to separate out the requirement (local vs. remote fault) from the implementation - insert all "1"s" in TDM signals. Given that MPLS-TP will be used in a transport network I see no reason to change the requirement. However, as you point out, the inherent differences between TDM and packet networks forces us to consider alternate implementations - all "1's" is not a valid packet signal..... So as I suggested in my previous post can we agree on the requirement. We can then discuss the implementation. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Drake, John E Sent: Thursday, April 30, 2009 9:32 AM To: George Newsome; Lam, Hing-Kam (Kam) Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements) George, An excellent note. Thanks, John=20 > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Thursday, April 30, 2009 6:16 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] AIS/FDI (was > Associatedbidirectionaltransportpathrequirements) >=20 > Lam, Hing-Kam (Kam) wrote: > > All I can say is that the impact of this proposed change is very=20 > > serious. > > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements=20 > > instead of changing the ITU-T transport requirements? > >=20 > > > Hi Kam, >=20 > AIS, which we are so very comfortable with, is a solution to a rather=20 > poorly stated requirement. The requirement is to distinguish between=20 > local faults (things that can be fixed > here) and remote faults (things that have to be fixed elsewhere). >=20 > PDH (and SDH/OTN) emits bits whatever the state of the incoming signal > and in the days of TTL, an open input was pulled up to 1. So extremely > old PDH equipment, emitted a stream of all 1's when its input was=20 > open. >=20 > This allowed a convenient simple distinction between a valid traffic=20 > signal, which has at least some 0's in it, and a remote failed signal. > It also provided a signal which checked the media between=20 > regenerators, and coincidentally, was propagated downstream for free. >=20 > And so we got AIS. It wasn't introduced to do stuff; it was just there > as a result of an open input. >=20 > Today we are trying to capture the requirements that the AIS=20 > implementation satisfies ,so that we do not repeat the common mistake=20 > of copying SDH solutions directly into a fundamentally different=20 > technology. >=20 > mpls-tp is not about changing what a transport network does, but it is > quite fundamentally changing how it does it. >=20 > Regards, >=20 > George > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp